Fwd: LatticeMico32 support in GCC 4.5
Hi, Do you have news regarding this? Thanks Sébastien -- Forwarded message -- From: Sébastien Bourdeauducq Date: Tue, 8 Sep 2009 20:46:01 +0200 Subject: LatticeMico32 support in GCC 4.5 To: g...@gnu.org Hi, Would you mind including support for the LatticeMico32 soft processor in the upcoming GCC 4.5 series? We at Milkymist [1] develop a free system-on-chip design [2] that uses the Mico32 processor and having out-of-the box Mico32 support in GCC would help software development on this free SoC platform. Support for Mico32 is already included in recent binutils releases. A patch [3] was submitted to the GCC mailing list last December, that we are currently using with GCC 4.4. It seems pretty stable as it allows us to compile a working Linux kernel [4]. Looking forward to your positive answer, Sébastien Bourdeauducq [1] http://www.milkymist.org [2] http://www.milkymist.org/doc/paper_overview.pdf [3] http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01024/lm32.patch [4] http://lekernel.net/blog/?p=540
Re: Not using DECL_VALUE_EXPR for callee-copied parameters?
On Mon, Sep 14, 2009 at 3:52 AM, John David Anglin wrote: > Hi Martin, > >> Having said that, if anybody has problems with this patch going in, >> please speak out now rather than later. > > I very much appreciate the work you have done on this problem. However, > the patch doesn't work as expected. I get multiple comparison failures > with this change on hppa-unknown-linux-gnu and hppa2.0w-hp-hpux11.11. While in long-term it might be good to make DECL_VALUE_EXPR a debuginfo only thing in short term the better approach would be to have a special gimplifier state that turns on DECL_VALUE_EXPR treatment (which would be off by default and thus during force_gimple_operand). The documentation of DECL_VALUE_EXPR should be adjusted accordingly of course. Richard. > Dave > -- > J. David Anglin dave.ang...@nrc-cnrc.gc.ca > National Research Council of Canada (613) 990-0752 (FAX: > 952-6602) >
Re: RFC: cgraph/lowering vs. finish_file for GCC/UPC rewrites?
On Mon, Sep 14, 2009 at 3:18 AM, Gary Funck wrote:
>
> Recently, we have been working on upgrading GCC/UPC (see
> http://gccupc.org) to the GCC trunk. Previously,
> we've sync'ed with the latest stable release, but
> now we want to stay more current.
>
> When built with GCC versions 4.0 through 4.3, we used
> the gimplify language hook, LANG_HOOKS_GIMPLIFY_EXPR,
> to rewrite trees that refer to UPC constructs and UPC
> shared variable references - converting them into
> non-UPC, gimplified, tree structures. This worked
> well, though we did need to extend the language hook
> to include a gimplify test predicate and fallback
> so that we can rewrite modify_expr's involving UPC
> shared variables as the target:
>
> int
> upc_gimplify_expr (tree *expr_p,
> gimple_seq *pre_p, gimple_seq *post_p,
> bool (* gimple_test_f) (tree),
> int fallback)
>
> Working with the latest GCC 4.5 snapshot, we have run
> into a problem that leads me to believe that the current
> approach will no longer work with the 4.5/trunk
> version of GCC.
>
> In prior GCC versions, the gimplify pass was called
> before the call graph pass. This meant that we could
> safely employ the gimplify language hook to perform
> the rewrites, which may emit inlined runtime calls.
>
> An example UPC-related rewrite is to transform
> UPC shared variable references into runtime calls.
> This program:
>
> shared int x;
> shared int y;
>
> int main()
> {
> x = y;
> }
>
> might be translated into something like:
>
> int main()
> {
> int y_tmp = upc_get_int(upc_shared_addr(&y));
> upc_put_int(upc_shared_addr(&x), &y_tmp);
> }
>
> The definitions of the runtime functions upc_put_int()
> and upc_get_int() are found in a pre-included header
> file (the UPC driver adds a -include switch on the
> command line).
>
> Depending upon optimization level and compile time
> switches - calls to the UPC runtime functions can
> be implemented as either inlined function calls or
> conventional calls to pre-compiled library routines.
> At optimization levels above -O0, most of the UPC
> runtime is inlined, by default.
>
> With the new/current organization of the
> compilation/call graph passes, we end up with the
> surprising result that the inlined runtime function
> definitions "disappear" before UPC's gimplify pass
> can refer to them. That's because the call graph
> pass noticed that the inline runtime functions were
> declared, but not referenced (yet). The gimplify pass
> is then run against the remaining function bodies,
> but the UPC runtime functions are no longer available.
>
> One workaround for this issue might be to mark the
> runtime functions, in a fashion similar to ctors/dtors
> so that the call graph pass won't eliminate them.
> I'm unsure if that will get the inlining aspects of
> those routines right, and it might retain unused
> function definitions in the form of compiled
> non-inlined code.
>
> GOMP appears to use a "lowering" pass that runs after
> the call graph and gimplify passes. It calls runtime
> routines via builtin function definitions, ensuring
> that the function definitions won't go away. However,
> it looks to me as if GOMP does not inline those
> runtime functions?
>
> OBJC implements some post-processing in the
> finish_file() hook routine, which in turn calls
> objc_finish_file(). That may be a reasonable place
> to relocate UPC's tree rewrites, but that leads to
> a few questions:
>
> Can gimplify_expr() be safely called on the same tree
> more than once? The question comes up because the
> simplest thing is to retain the current infrastructure
> where UPC rewrites occur in the gimplify language
> hook. The second gimplify pass will redo some
> work, calling out to the UPC language hook again,
> but since all UPC constructs have been rewritten and
> gimplified, there will be no additional work done,
> besides the traversal.
>
> How about an alternative approach that implements a
> custom tree-walk inside finish_file() (that is similar
> in structure to that implemented in omp-low.c).
> Is this rewrite routine allowed to selectively
> gimplify parts of the tree and/or to create temp
> variables managed by the code in gimplify.c?
>
> Is the description above, of the interactions
> between the cgraph, gimplify and lowering passes
> correct?
>
> What approach would you recommend for the
> implementation of UPC tree re-writes that will
> support calls to the runtime (that are inlined,
> if applicable)?
Without reading all the details of your mail I suggest that you
perform a custom walk over the function bodies right before
the frontend calls cgraph_finalize_compilation_unit () that
performs the necessary lowering (and function creation) to
GENERIC. The C++ frontend already does this during its
genericize phase to transform frontend specific trees to
middle-end GENERIC trees.
Richard.
> thanks,
>
> - Gary
>
Re: Add my name to Write-after-Approval List
Paolo Bonzini wrote: 4) some might fall under 2 or 3. Actually just one; he used to be at QNX, couldn't find any data after 2005 on qnx.com but I'm CCing him: >gp (Graeme Peterson )2003-08-063 Graeme left QNX back in 2006. He removed himself from the MAINTAINERS file: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00513.html Regards, Ryan Mansfield
Re: Add my name to Write-after-Approval List
On 09/14/2009 02:13 PM, Ryan Mansfield wrote: Paolo Bonzini wrote: 4) some might fall under 2 or 3. Actually just one; he used to be at QNX, couldn't find any data after 2005 on qnx.com but I'm CCing him: > gp (Graeme Peterson ) 2003-08-06 3 Graeme left QNX back in 2006. He removed himself from the MAINTAINERS file: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00513.html Thanks---I should have checked that, sorry. Paolo
Supporting FP cmp lib routines
Hi all, I am doing a GCC port for a 32bit target in GCC 4.4.0. The target uses hand coded floating point compare routines. Generally the function returns the values in the general purpose registers. But these fp cmp routines return the result in the Status Register itself. So there is no need to have compare instruction after the function call for FP compare. Is there a way to let GCC know that the result for FP compare are stored in the Status Register so that GCC generates directly a jump operation? How can i implement this? Regards, Shafi
How to split 40bit data types load/store?
Hello all, I am doing a port for a 32bit target in GCC 4.4.0. I have to support a 40bit data (_Accum) in the port. The target has 40bit registers which is a GPR and works as 32bit reg in other modes. The load and store for _Accum happens in two step. The lower 32bit in one instruction and the upper 8bit in the next instruction. I want to split the instruction after reload. I tired to have a pattern (for load) like this: (define_insn "fn_load_ext_sa" [(set (unspec:SA [(match_operand:DA 0 "register_operand" "")] UNSPEC_FN_EXT) (match_operand:SA 1 "memory_operand" ""))] (define_insn "fn_load_sa" [(set (unspec:SA [(match_operand:DA 0 "register_operand" "")] UNSPEC_FN) (match_operand:SA 1 "memory_operand" ""))] The above patterns works for O0. But with optimizations i am getting ICE. It seems that GCC won't accept unspec object in destination operand. So how can split the pattens for the load and store for these data types? Regards, Shafi
József! -> W2E98 <- az Ön promóciós kódja
Az üzenet címzettje: József Czibere Azért kapja ezt az e-mail, mert rajta van az Eurorest Akciók korábbi résztvevőinek listáján. --- Üdvözöljük József! Olvassa el ezt az üzenetet, és tudja meg, hogy még az idén eltölthet további 3 hétvégét az Eurorest hotelekben. Természetesen, a szállás a hotelekben és panziókban most is INGYENES LESZ! | Az Ön promóciós kódja: W2E98 | A promóciós kód érvényessége: 3 nap | A promóció weblapja: |http://eurorest.org/?lng=hu&id=a04&zn=B7329 | | Jegyezze meg a promóciós kódját. Ezzel a kóddal tudja átvenni | az Önnek szánt, kivételes csomagot, amelynek tartalma: | ::: 3 DARAB, KÉTSZEMÉLYES WEEKEND Eurorest hotelcsekk ::: = Arra gondoltunk, hogy jót tenne Önnek, ha még az idén kiszakadhatna egy kicsit a mindennapi taposómalomból. El tudjuk képzelni, hogy nehéz hosszabb szabadságra elutaznia. De mire valók a hétvégék? Meghívjuk, hogy vegyen részt a limitált számú, hétvégi hotelcsekkek emissziójában. Ez az első ilyen emisszió az Eurorest több mint tíz éves történetében! Csak Önön múlik, hogy ezek közül a hétvégi csekkek közül jut-e Önnek is. Készítettünk Önnek egy 3 hotelcsekkből álló csomagot. Minden csekk 2 személy jogosít arra, hogy eltöltsön 3 éjszakát az Eurorest hotelekben. A csekket felhasználhatja három különböző, hétvégi utazásra, vagy azt is megteheti, hogy összevonja őket, egy akár 9 napig tartó üdülésre. hotelcsekkek, amiket kap, 2009.12.31-ig érvényesek. Kattintson most az alábbi linkre, és adja meg a címet, ahol át szeretné venni a három hétvégi Eurorest hotelcsekkből álló csomagot. Kattintson ide: http://eurorest.org/?lng=hu&id=a04&zn=B7329 Figyelem! A limitált, hétvégi hotelcsekkek kizárólag az Eurorest Akcióknak azokhoz a korábbi résztvevőinek szólnak, akik promóciós kódot kaptak. Amikor kitölti az űrlapot az Eurorest Akció weblapján, ne felejtse beírni a kódot az erre szánt mezőbe. Az Eurorest hotelcsekket egy kedvezménykártyához lehet hasonlítani. A csekktulajdonosok az ellátásért fizetnek a hotelben. Cserébe elengedik nekik a szállásra jutó díjat. Így egy csomó pénzt meg tudnak takarítani, vagy sokkal magasabb színvonalú hotelben szállhatnak meg, mint általában. --- Példák a megtakarításra--- Hévíz / Zala / Magyarország "Fit" Spa & Wellness Hotel a megtakarítás akár 27000 Ft lehet két fő 3 napi tartózkodása esetén --- Csehország / Prága "Bridge" Hotel *** a megtakarítás akár 18500 Ft lehet két fő 3 napi tartózkodása esetén --- Magyarország / Zala / Zalakaros "Venus" Hotel *** a megtakarítás akár 24000 Ft lehet két fő 3 napi tartózkodása esetén --- Üdvözletünket küldjük, és már most kellemes pihenést kívánunk! Zespół Eurorest === Ha a továbbiakban nem szeretne több promóciós információt kapni az Euroresttől, kérjük, kattintson erre a linkre: http://eurorest.org/?id=19&er=...@gcc.gnu.org
Re: Supporting FP cmp lib routines
Another thing to look at, since you have hand-written routines and may be able to specify that e.g. only a subset of the normal call clobbered registers are actually modified, is to leave the call as a "compare" insn. Something like (define_insn "*cmpsf" [(set (reg:CC status-reg) (compare:CC (match_operand:SF 0 "register_operand" "R0") (match_operand:SF 1 "register_operand" "R1"))) (clobber (reg:SI r2)) (clobber (reg:SI r3))] "" "call __compareSF" [(set_attr "type" "call")]) Where the R0 and R1 constraints resolve to the input registers for the routine. Depending on your ISA and ABI, you may not even need to split this pattern post-reload. r~
Re: enable-build-with-cxx bootstrap compare broken by r149964
On 08/31/2009 12:57 AM, Jerry Quinn wrote: On Thu, 2009-08-27 at 00:24 -0400, Jason Merrill wrote: Do you know why r149964 makes a difference? I understand now. The patch changed the anonymous namespace name to use get_file_function_name in all cases, where previously we were using the same name in all translation units. This was necessary to avoid treating types in the anonymous namespace in two different translation units as equivalent for typeinfo comparison. Your patch deals with the fake anonymous namespace inserted for mangling, but doesn't deal with real anonymous namespaces, which will be incorrectly treated as identical with your patch. I think the way to go with this is to revert the compiler bits of r149964, not mess with mangle.c at all, and insert the initial * if the typeinfo name won't have TREE_PUBLIC set, since that's precisely the property we want to mirror in comparison. Jason
Re: i370 port
Paul Edwards wrote:
> int
> i370_branch_dest (branch)
> rtx branch;
> {
> rtx dest = SET_SRC (PATTERN (branch));
> int dest_uid;
> int dest_addr;
>
> /* first, compute the estimated address of the branch target */
> if (GET_CODE (dest) == IF_THEN_ELSE)
> dest = XEXP (dest, 1);
> dest = XEXP (dest, 0);
This is set up only to handle direct branches of the form
(set (pc) (label_ref ...))
and indirect branches of the form
(set (pc) (if_then_else (...) (label_ref ...) (pc)))
but *not* indirect branches of the form
(set (pc) (if_then_else (...) (pc) (label_ref ...)))
This latter form is accepted by the "negated conditional
jump instructions in the i370.md file, like so:
(define_insn ""
[(set (pc)
(if_then_else (eq (cc0)
(const_int 0))
(pc)
(label_ref (match_operand 0 "" ""
; (clobber (reg:SI 14))
]
""
"*
{
check_label_emit ();
mvs_check_page (0, 4, 0);
if (i370_short_branch(insn) || mvs_check_label (CODE_LABEL_NUMBER
(operands[0])))
{
Therefore, the i370_branch_dest routine needs to handle
those as well. Probably something along the following lines:
if (GET_CODE (dest) == IF_THEN_ELSE)
{
if (GET_CODE (XEXP (dest, 1) == LABEL_REF)
dest = XEXP (dest, 1);
else
dest = XEXP (dest, 2);
}
gcc_assert (GET_CODE (dest) == LABEL_REF);
dest = XEXP (dest, 0);
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Re: How to split 40bit data types load/store?
On 09/14/2009 07:24 AM, Mohamed Shafi wrote: Hello all, I am doing a port for a 32bit target in GCC 4.4.0. I have to support a 40bit data (_Accum) in the port. The target has 40bit registers which is a GPR and works as 32bit reg in other modes. The load and store for _Accum happens in two step. The lower 32bit in one instruction and the upper 8bit in the next instruction. I want to split the instruction after reload. I tired to have a pattern (for load) like this: (define_insn "fn_load_ext_sa" [(set (unspec:SA [(match_operand:DA 0 "register_operand" "")] UNSPEC_FN_EXT) (match_operand:SA 1 "memory_operand" ""))] (define_insn "fn_load_sa" [(set (unspec:SA [(match_operand:DA 0 "register_operand" "")] UNSPEC_FN) (match_operand:SA 1 "memory_operand" ""))] Unspec on the left-hand-side isn't something that's supposed to happen, and is more than likely the cause of your problems. Try moving the unspec to the right-hand-side like: (set (reg:SI reg) (mem:SI addr)) (set (reg:SA reg) (unspec:SA [(reg:SI reg) (mem:QI addr)] UNSPEC_ACCUM_INSERT)) and (set (mem:SI addr) (reg:SI reg)) (set (mem:QI addr) (unspec:QI [(reg:SA reg)] UNSPEC_ACCUM_EXTRACT)) Note that after reload it's perfectly acceptable for a hard register to appear with the different SI and SAmodes. It's probably not too hard to define this with zero_extract sequences instead of unspecs, but given that these only appear after reload, it may not be worth the effort. r~
Constraints and reload
Dear all, I was working on simplifying the movdi in my port and I had put : [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,o") (match_operand:DI 1 "general_operand" "r,i,o,r"))] However, due to constraints on the offset that is allowed, I: - Added the check of the offset in the expand - Added the check of the offset in the definition of the instruction - Changed the constraints to: [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,R") (match_operand:DI 1 "general_operand" "r,i,R,r"))] Where R checks if the operand is a memory operand and if the offset is correct. Once I did that, in one case of my regression tests, I received the error: asm operand requires impossible reload However, if I generate what I get in the first version, all the moves seem to be correct anyway. My theory is that reload needs the o EVEN IF what it will be trying to do is illegal and it will figure that out and finally generate the right thing afterwards. Thus, why the o is necessary and not the R. Is this correct? Thanks, Jean Christophe Beyler
Re: i370 port
Paul Edwards wrote: Just one comment on this particular point: > 4. There is one thing that doesn't have proper ASCII to EBCDIC > translation being done - the __FUNCTION__ builtin. It looks this was indeed a bug that was fixed for GCC 4.0.0: http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01773.html (note that there were some minor revisions to the patch before it was committed). Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: Supporting FP cmp lib routines
On 09/14/2009 06:59 AM, Mohamed Shafi wrote: Is there a way to let GCC know that the result for FP compare are stored in the Status Register so that GCC generates directly a jump operation? How can i implement this? There is no way to do this via the standard libcall sequence. In order to implement this, you'll want to build the function calls yourself, directly from the cbranch expanders. Have a look at alpha_emit_xfloating_libcall for ideas. You'll want to make sure that that your status register is set up as the return value of the call pattern, i.e. (set (reg:CC status-reg) (call:CC (mem (symbol_ref "fp-compare-routine" That should be about all you need to get things working. r~
Re: Constraints and reload
On 09/14/2009 12:18 PM, Jean Christophe Beyler wrote: [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,R") (match_operand:DI 1 "general_operand" "r,i,R,r"))] Where R checks if the operand is a memory operand and if the offset is correct. Did you use define_memory_constraint for R, or just define_constraint? If the former, it's a bug in reload; if the later, that's the problem. r~
Re: RFC: cgraph/lowering vs. finish_file for GCC/UPC rewrites?
On 09/14/09 11:52:11, Richard Guenther wrote: > Without reading all the details of your mail I suggest that you > perform a custom walk over the function bodies right before > the frontend calls cgraph_finalize_compilation_unit () that > performs the necessary lowering (and function creation) to > GENERIC. The C++ frontend already does this during its > genericize phase to transform frontend specific trees to > middle-end GENERIC trees. Richard, thanks. Will take a look at how C++ handles things. - Gary
gnat regressions on sparc, mips and x86
Hi, I have re-run GNAT/RTEMS on a number of targets for 4.3.4, 4.4.1 and the SVN head. I kept the binutils, gdb, newlib and RTEMS the same. The SVN head has a lot of new failures for SPARC, MIPS, and x86. The SPARC and MIPS have the same number of failures (319) so I assume the same underlying cause. The x86 has gone from about 20 failures which are mostly deficiencies in qemu FPU accuracy to about 225 with many indicating hardware exceptions. And FWIW I was unable to build ARM on the head. :( I am attaching my summary notes but would appreciate any feedback. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 NOTE: c380004 requires large stack? powerpc/psim + 4.3.4 - 2 fails: c380004 c974013 + 4.4.1 - 2 fails: c380004 c974013 + SVN (4.5.0 20090910 r151592) - 2 fails: c380004 c974013 sparc/sis = + 4.3.4 - 2 fails: c380004 c974013 + 4.4.1 - 2 fails: c380004 c974013 + SVN (4.5.0 20090910 r151592) - 319 fails: including c380004 c974013 mips/jmr3904 + 4.3.4 - 3 fails: c380004 cxf3a01 cxf3a02 cxf3a01, cxf3a02 - read of unmapped address + 4.4.1 - 1 fails: c380004 + SVN (4.5.0 20090910 r151592) - 319 fails: many unhandled exception 9 arm/edb7312 === + 4.3.4 - ? did it build + 4.4.1 - ? did it build + SVN (4.5.0 20090910 r151592) - bug box i386/pc386 == + 4.3.4 - 54 fails: c380004 plus many hardware exceptions + 4.4.1 - 20 fails: c380004 plus c953002 - ran too long (has output) cc1307b - ran too long (but no output) cxg2002 cxg2003 cxg2004 cxg2006 cxg2007 cxg2010 cxg2011 cxg2012 cxg2013 cxg2014 cxg2015 cxg2016 cxg2017 cxg2018 cxg2019 cxg2020 cxg2021 - Qemu has problems with FPU simulation and fails. The pass on real hardware. + SVN (4.5.0 20090910 r151592) - 225 fails, many hardware exceptions
