RE: Help required - ICE in GCC for my target
Hi Delorie Thank you very much for your reply. I have made the changes as you have mentioned, but I am getting same error. Could you please guide where I can look into Thanking you in advance Regards Shrirang Khisti KPIT Cummins Infosystems Ltd. -Original Message- From: DJ Delorie [mailto:[EMAIL PROTECTED] Sent: Thursday, December 01, 2005 11:40 AM To: Shrirang Khishti Cc: gcc@gcc.gnu.org Subject: Re: Help required - ICE in GCC for my target > I have also provided RTL's for "extendpsisi" and "truncsipsi" (for > converting between PSI and SI modes). You need extendpsisi2, truncsipsi2, and zero_extendpsisi2. The m32c port uses PSI for pointers also; you can use it as an example.
gcc-4.2-20051201 is now available
Snapshot gcc-4.2-20051201 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20051201/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 107813 You'll find: gcc-4.2-20051201.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20051201.tar.bz2 C front end and core compiler gcc-ada-4.2-20051201.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20051201.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20051201.tar.bz2 C++ front end and runtime gcc-java-4.2-20051201.tar.bz2 Java front end and runtime gcc-objc-4.2-20051201.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20051201.tar.bz2The GCC testsuite Diffs from 4.1-20051112 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
successfully built and installed GCC version 4.0.2 on i686-pc-linux-gnu Debian Sarge 3.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 successfully built and installed GCC version 4.0.2 on i686-pc-linux-gnu Debian Sarge 3.1 all languages enabled # ./config.guess i686-pc-linux-gnu # ./gcc-4.0.2 -v Es werden eingebaute Spezifikationen verwendet. Ziel: i686-pc-linux-gnu Konfiguriert mit: /home/abf/Downloads/source/gcc/gcc-4.0.2/configure - --prefix=/home/abf/gcc --program-suffix=-4.0.2 Thread-Modell: posix gcc-Version 4.0.2 All languages configured # /etc/issue Debian GNU/Linux 3.1 # dpkg -l libc6 libc6 2.3.2.ds1-22 # Kernel 2.6.14.2 #1 PREEMPT -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDjsNOBbKstp7vXlgRAt7ZAKC/wE9UBokR+NMVjr0VovgnP3wxJwCeKVbr q5skmaD8ZIgdarrdRgQ8AWo= =2U/r -END PGP SIGNATURE-
Re: SVN Problem?
svn switch --relocate {svn://,svn+ssh://[EMAIL PROTECTED]/svn/gcc
Thanks. I doubt I would have come up with that one on my own! :-)
Oh, that's just shell expansion for
svn switch --relocate svn://gcc.gnu.org/svn/gcc \
svn+ssh://[EMAIL PROTECTED]/svn/gcc
BTW Dan, though Jeff did not see it, the error message you get if you
just do
svn switch svn+ssh://[EMAIL PROTECTED]/svn/gcc
does not hint at relocate. Maybe it will be moot once we switch to
svn+ssl and nobody will check out svn:// trees, still it can be an
improvement.
Thanks,
paolo
GCC-3.4.6 status
Hi, gcc-3_4-branch is open again for regression-fix patches only. Thanks, -- Gaby
[4.0 Regression + Patch] PR23282
Hi, PR23282 is a wrong code generation bug that shows up in trivial C code (see comment 2) at -O1. Since a few weeks, there has been a small patch attached to the PR (tested on mainline/4.1 since june see PR22442) that also fixes the problem for 4.0 (I tested _4_0_1_release). I think that that patch should go in the 4.0 branch before 4.0.3 is released Is there anybody with svn write permission and a few spare minutes ?? Thanks, Joost
weakref and static
The 'weakref' attribute is defined in terms of aliases. Now,
if the user writes
void foo(void) { }
void bar(void) __attribute__((alias ("foo")));
then that causes 'bar' to be defined. Other translation units can use
'bar'. If 'weakref' is to define an alias, it should behave the same
way.
Unfortunately, it can't do that; Mach-O (on Darwin) doesn't support
aliases in the object file at all, and even ELF doesn't support
aliases to symbols outside the current .o. The easiest solution to
this is to require that weakrefs must be 'static', because the name
that they define is not visible outside this translation unit.
There's an additional wrinkle, which is although this name is
'static', it is also 'weak' because it can be NULL. So we have
introduced a new concept, a static weak name. Fortunately it is
limited to just this one case.
I couldn't fully test this patch because weakrefs still don't seem to
be working properly on Darwin. However, the testcases do compile
successfully.
Sorry I didn't say anything earlier about Alexandre's proposal, I
thought that it implied that in fact ELF did have this capability.
What do people think?
Obviously this should be settled before 4.1 ships...
--
- Geoffrey Keating <[EMAIL PROTECTED]>
===File ~/patches/gcc-weakrefstatic-0.patch=
Index: gcc/ChangeLog
2005-12-01 Geoffrey Keating <[EMAIL PROTECTED]>
* doc/extend.texi (Function Attributes): Mention that an alias
attribute creates a definition for the thing it's attached to.
Change the documentation for weakref to say that the thing
it's attached to must be static.
... other changes
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 107814)
+++ gcc/doc/extend.texi (working copy)
@@ -1554,7 +1554,7 @@
void f () __attribute__ ((weak, alias ("__f")));
@end smallexample
-declares @samp{f} to be a weak alias for @samp{__f}. In C++, the
+defines @samp{f} to be a weak alias for @samp{__f}. In C++, the
mangled name for the target must be used. It is an error if @samp{__f}
is not defined in the same translation unit.
@@ -2376,12 +2376,12 @@
@code{weakref} is equivalent to @code{weak}.
@smallexample
-extern int x() __attribute__ ((weakref ("y")));
+static int x() __attribute__ ((weakref ("y")));
/* is equivalent to... */
-extern int x() __attribute__ ((weak, weakref, alias ("y")));
+static int x() __attribute__ ((weak, weakref, alias ("y")));
/* and to... */
-extern int x() __attribute__ ((weakref));
-extern int x() __attribute__ ((alias ("y")));
+static int x() __attribute__ ((weakref));
+static int x() __attribute__ ((alias ("y")));
@end smallexample
A weak reference is an alias that does not by itself require a
@@ -2396,6 +2396,9 @@
declaring it as weak, compiling the two separate translation units and
performing a reloadable link on them.
+At present, a declaration to which @code{weakref} is attached can
+only be @code{static}.
+
@item externally_visible
@cindex @code{externally_visible} attribute.
This attribute, attached to a global variable or function nullify
Index: gcc/testsuite/gcc.dg/attr-weakref-1.c
===
--- gcc/testsuite/gcc.dg/attr-weakref-1.c (revision 107814)
+++ gcc/testsuite/gcc.dg/attr-weakref-1.c (working copy)
@@ -26,37 +26,32 @@
typedef int vtype;
extern vtype wv1;
-extern vtype Wv1a __attribute__((weakref ("wv1")));
+static vtype Wv1a __attribute__((weakref ("wv1")));
static vtype *pv1a USED = &Wv1a;
-extern vtype Wv1b __attribute__((weak, weakref, alias ("wv1")));
-static vtype *pv1b USED = &Wv1b;
-extern vtype Wv1c __attribute__((weakref));
-extern vtype Wv1c __attribute__((alias ("wv1")));
-static vtype *pv1c USED = &Wv1c;
vtype gv2;
-extern vtype Wv2a __attribute__((weakref ("gv2")));
+static vtype Wv2a __attribute__((weakref ("gv2")));
static vtype *pv2a USED = &Wv2a;
static vtype lv3;
-extern vtype Wv3a __attribute__((weakref ("lv3")));
+static vtype Wv3a __attribute__((weakref ("lv3")));
static vtype *pv3a USED = &Wv3a;
extern vtype uv4;
-extern vtype Wv4a __attribute__((weakref ("uv4")));
+static vtype Wv4a __attribute__((weakref ("uv4")));
static vtype *pv4a USED = &Wv4a;
static vtype *pv4 USED = &uv4;
-extern vtype Wv5a __attribute__((weakref ("uv5")));
+static vtype Wv5a __attribute__((weakref ("uv5")));
static vtype *pv5a USED = &Wv5a;
extern vtype uv5;
static vtype *pv5 USED = &uv5;
-extern vtype Wv6a __attribute__((weakref ("wv6")));
+static vtype Wv6a __attribute__((weakref ("wv6")));
static vtype *pv6a USED = &Wv6a;
extern vtype wv6;
-extern vtype Wv7a __attribute__((weakref ("uv7")));
+static vtype Wv7a __attribute__((weakref ("uv7")));
static vtype* USED fv7 (void) {
return &Wv7a;
}
@@ -69,71 +64,69 @@
static vtype* USED fv8a (void) {
return &uv8;
}
-extern vtype Wv8a __attribute__((weakref ("uv8")));
+
fold_build1 (NOP_EXPR, ...) vs. fold_build1 (CONVERT_EXPR, ...)
It looks like it is safe to exchange both of them (the first one for sure)
to fold_convert (...) due to the fact that fold_unary handles NOP_EXPR
the same way than CONVERT_EXPR apart from cases that look like oversights,
f.i.
/* Convert (T1)((T2)X op Y) into (T1)X op Y, for pointer types T1
and
T2 being pointers to types of the same size. */
if (POINTER_TYPE_P (type)
&& BINARY_CLASS_P (arg0)
&& TREE_CODE (TREE_OPERAND (arg0, 0)) == NOP_EXPR
&& POINTER_TYPE_P (TREE_TYPE (TREE_OPERAND (arg0, 0
{
or
case ABS_EXPR:
...
else if (TREE_CODE (arg0) == NOP_EXPR
&& TREE_CODE (type) == REAL_TYPE)
{
tree targ0 = strip_float_extensions (arg0);
if (targ0 != arg0)
return fold_convert (type, fold_build1 (ABS_EXPR,
TREE_TYPE (targ0),
targ0));
}
or
/* Simplify ((int)c & 0377) into (int)c, if c is unsigned char. */
if (TREE_CODE (arg1) == INTEGER_CST && TREE_CODE (arg0) == NOP_EXPR
&& TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (arg0, 0
{
etc.
In fact, I remember a plan of merging NOP_EXPR and CONVERT_EXPR.
Is this correct?
Thanks,
Richard.
Re: Help required - ICE in GCC for my target
> Could you please guide where I can look into You're going to have to just debug it.
Re: Torbjorn's ieeelib.c
> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes: > On Tue, Nov 29, 2005 at 12:42:36PM -0800, Mark Mitchell wrote: >> RTH is listed as the author of a lot of those bits, so perhaps he knows >> more? > The glibc bits handle ieee quad format, whereas I don't believe > that Torbajorn's does. I don't recall if Torbajorn's code allows > for emulation of all rounding modes or exception bits. > But I suspect that Torbajorn's code compiles down smaller, which > is likely to be helpful to the folk that actually need it. BTW, I think glibc's code does not support 16-bit architectures. >> The GLIBC bits claim to be LGPL'd, so that would indeed need a change to >> include them in libgcc. > I wouldn't expect that to be a problem. There was a thread discussing all this, when I was interested in doing the work. I mailed rms directly, and he said it was ok to use the glibc bits in gcc regardless of the LGPL/GPL disparity. Aldy
Re: Torbjorn's ieeelib.c
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes: > Richard Henderson wrote: >> The glibc bits handle ieee quad format, whereas I don't believe >> that Torbajorn's does. I don't recall if Torbajorn's code allows >> for emulation of all rounding modes or exception bits. > I believe it does not. >> But I suspect that Torbajorn's code compiles down smaller, which >> is likely to be helpful to the folk that actually need it. > I think both size and speed are important, but, yes, size is an issue. > I would certainly expect that many embedded users would want to be able > to disable rounding-mode and/or exception support to save code size, > although there are probably also users that would make use of support > for these features. Torbajorn's code does not handle rounding/expection.
MS1 backend not listed in backends.html
Hi Aldy, The MS1 backend is not listed in http://gcc.gnu.org/backends.html. Could you please add it? Gr. Steve
Re: Torbjorn's ieeelib.c
Aldy Hernandez wrote: > There was a thread discussing all this, when I was interested in doing > the work. I mailed rms directly, and he said it was ok to use the > glibc bits in gcc regardless of the LGPL/GPL disparity. Do you happen to have a pointer, or a copy of that message? If that route ends up making the most sense, then it would be nice to have our ducks in a row. As for the 16-bit issue, I don't think that's necessarily an all-or-nothing switch; the most likely route of progress would be to add ieeelib.c/glibc soft-fp and then gradually migrate targets that wanted to migrate. Joseph is comparing the two alternatives with fp-bit.c, and I'd expect he'll have an opinion about which is best. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Torbjorn's ieeelib.c
BTW, here is the original thread I had started: http://gcc.gnu.org/ml/gcc/2003-04/msg00695.html > > There was a thread discussing all this, when I was interested in doing > > the work. I mailed rms directly, and he said it was ok to use the > > glibc bits in gcc regardless of the LGPL/GPL disparity. > > Do you happen to have a pointer, or a copy of that message? If that > route ends up making the most sense, then it would be nice to have our > ducks in a row. Argh... I've grepped all over my harddrive, but can't find it. But I *am* sure I sent a mail to rms explaining the whole thing, and he responded positively. Perhaps he can remember the conversation? Sorry.
Re: Torbjorn's ieeelib.c
Aldy Hernandez wrote: > Argh... I've grepped all over my harddrive, but can't find it. But > I *am* sure I sent a mail to rms explaining the whole thing, and he > responded positively. Perhaps he can remember the conversation? Thanks for looking. I can ask him, if that route looks best. At this point, we have convincing ieeelib.c numbers, but I don't think we have GLIBC soft-fp data yet. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: MS1 backend not listed in backends.html
On Thu, Dec 01, 2005 at 04:18:20PM +0100, Steven Bosscher wrote: > Hi Aldy, > > The MS1 backend is not listed in http://gcc.gnu.org/backends.html. > Could you please add it? This is what I have. Nathan, how does this look to you? Index: backends.html === RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v retrieving revision 1.31 diff -c -p -r1.31 backends.html *** backends.html 20 Jul 2005 23:29:43 - 1.31 --- backends.html 1 Dec 2005 17:30:17 - *** mcore| ?FI gm d s *** 87,92 --- 87,93 mips | Q CB qr p bda s mmix | HM Q Cq p b a e mn10300 | ?? c g s + ms1 | S F B d pa | ? Q CBD qrm da e pdp11|L I cpf me rs6000 | Q Cqr da
Re: MS1 backend not listed in backends.html
Aldy Hernandez wrote: On Thu, Dec 01, 2005 at 04:18:20PM +0100, Steven Bosscher wrote: Hi Aldy, The MS1 backend is not listed in http://gcc.gnu.org/backends.html. Could you please add it? This is what I have. Nathan, how does this look to you? I think the line should be + ms1 | S F B p g bd nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: MS1 backend not listed in backends.html
> I think the line should be > + ms1 | S F B p g bd Argh, I misread "does not" for "does". Ok, committing the following. Index: backends.html === RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v retrieving revision 1.31 diff -c -p -r1.31 backends.html *** backends.html 20 Jul 2005 23:29:43 - 1.31 --- backends.html 1 Dec 2005 17:49:53 - *** mcore| ?FI gm d s *** 87,92 --- 87,93 mips | Q CB qr p bda s mmix | HM Q Cq p b a e mn10300 | ?? c g s + ms1 | S F B p g bd pa | ? Q CBD qrm da e pdp11|L I cpf me rs6000 | Q Cqr da
Re: new c++ restrictions?
Jack Howarth wrote: For the last few months, gcc 4.1 has had problems compling the following code in posRMSDPot.cc in xplor-nih... without a full test case we have no clue. nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: [C++] cp_token::type and cp_token::keyword
Gabriel Dos Reis wrote:
> In cp/parser.c:cp_parser_declaration(), we have the following code
>
> /* Try to figure out what kind of declaration is present. */
> token1 = *cp_lexer_peek_token (parser->lexer);
>
> if (token1.type != CPP_EOF)
> token2 = *cp_lexer_peek_nth_token (parser->lexer, 2);
> else
> token2.type = token2.keyword = RID_MAX;
>
> It looks to me like the last line is a typo for
>
> {
> token2.type = CPP_EOF;
> token2.keyword = RID_MAX;
> }
Yes. The obvious patch is pre-approved.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Declaration of flags in 4.0.2
Hi, Where're these flags defined in 4.0.2? flag_syntax_only flag_mudflap "grep -inr ." in the source root didn't return any declarations. Thx. Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
Re: Declaration of flags in 4.0.2
"Domagoj Flanks" <[EMAIL PROTECTED]> writes: > Where're these flags defined in 4.0.2? > > flag_syntax_only > flag_mudflap They are defined in the file common.opt. Ian
gcc-4.0-20051201 is now available
Snapshot gcc-4.0-20051201 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20051201/ 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 107831 You'll find: gcc-4.0-20051201.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20051201.tar.bz2 C front end and core compiler gcc-ada-4.0-20051201.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20051201.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20051201.tar.bz2 C++ front end and runtime gcc-java-4.0-20051201.tar.bz2 Java front end and runtime gcc-objc-4.0-20051201.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20051201.tar.bz2The GCC testsuite Diffs from 4.0-20051124 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.
ARM spurious load
The following code snippet produces code that loads a register, r5,
from memory, but never uses the value. The code is correct though, so
not a major issue. In addition, it never uses r3 or r12, which are
"free" registers, in that they don't have to be saved by the callee.
For a one line function that essentially returns a constant, the
generated code spills a lot of registers that it needn't. The
generated code ought to resemble "ldr r0, =constant0; ldr r1,
=constant1; b lr". This code was generated using arm-elf-gcc -mthumb
-O2.
Please cc me in your reply. Cheers,
Shaun
arm-elf-gcc (GCC) 4.0.2
#define USER_STACK 0x210
static long long rdp_getenv(void)
{
// Return the command line in r0 and the stack in r1.
return ((long long unsigned)USER_STACK << 32) | (int)"";
}
02001644 :
2001644: b570push{r4, r5, r6, lr}
2001646: 4a04ldr r2, [pc, #16] (2001658 <.text+0x1658>)
2001648: 4d04ldr r5, [pc, #16] (200165c <.text+0x165c>)
200164a: 4e05ldr r6, [pc, #20] (2001660 <.text+0x1660>)
200164c: 17d4asrsr4, r2, #31
200164e: 1c21addsr1, r4, #0
2001650: 4331orrsr1, r6
2001652: 1c10addsr0, r2, #0
2001654: bd70pop {r4, r5, r6, pc}
[the literal pool follows here]
Documentation for 4.0.2
Hi, Any chances that the GCC Internals documentation will be updated any time soon? http://gcc.gnu.org/onlinedocs/gccint/ There have been a lot of changes in GCC and it's hard to figure out the code by reading the old documentation and the new incomplete 4.0.2 draft. Thx. Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
Re: fold_build1 (NOP_EXPR, ...) vs. fold_build1 (CONVERT_EXPR, ...)
On Thu, 1 Dec 2005, Richard Guenther wrote: > It looks like it is safe to exchange both of them (the first one for sure) > to fold_convert (...) due to the fact that fold_unary handles NOP_EXPR > the same way than CONVERT_EXPR apart from cases that look like oversights, > ... > In fact, I remember a plan of merging NOP_EXPR and CONVERT_EXPR. Doh! I follow gcc-patches more closely than the gcc list, so I saw your post there first and replied without cross-posting. For those interested in the topic, my thoughts are at: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00124.html Roger --
FAIL: gcc.dg/sparc-ret.c scan-assembler
Aurora SPARC Linux release 2.0b2 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: binutils-2.15.92.0.2-5.sparc bison-1.875c-2.sparc dejagnu-1.4.4-2.noarch expect-5.42.1-1.sparc gcc-3.4.2-6.fc3.sparc gcc4-4.0.0-0.8sparc.sparc glibc-2.3.3-99.sparcv9 glibc-devel-2.3.3-99.sparc glibc-headers-2.3.3-99.sparc glibc-kernheaders-2.6-20sparc.sparc gmp-4.1.4-3sparc.sparc gmp-devel-4.1.4-3sparc.sparc kernel-2.6.13-1.1603sp8.sparc64 package kernel-devel is not installed package kernel-smp is not installed libgcc-3.4.2-6.fc3.sparc libstdc++-3.4.2-6.fc3.sparc libstdc++-devel-3.4.2-6.fc3.sparc make-3.80-5.sparc nptl-devel-2.3.3-99.sparcv9 tcl-8.4.7-2.sparc LAST_UPDATED: Thu Dec 1 05:58:03 UTC 2005 (revision 107802) Platform: sparc-unknown-linux-gnu configure flags: sparc-linux --enable-__cxa_atexit --enable-shared --disable-multilib --enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang I just got this failure on gcc trunk: Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trunk/objdir32/gcc/ /usr/local/src/trunk/gcc/gcc/testsuite/gcc.dg/sparc-loop-1.c -O2 -ffast-math -fno-show-column -S -o sparc-loop-1.s(timeout = 1200) PASS: gcc.dg/sparc-loop-1.c (test for excess errors) UNSUPPORTED: gcc.dg/sparc-reg-1.c Executing on host: /usr/local/src/trunk/objdir32/gcc/xgcc -B/usr/local/src/trunk/objdir32/gcc/ /usr/local/src/trunk/gcc/gcc/testsuite/gcc.dg/sparc-ret.c -mcpu=ultrasparc -O -fno-show-column -S -o sparc-ret.s(timeout = 1200) PASS: gcc.dg/sparc-ret.c (test for excess errors) FAIL: gcc.dg/sparc-ret.c scan-assembler return[ \t]*%i7\\+8\n[^\n]*ld[ \t]*\\[%sp\\+96\\] PASS: gcc.dg/sparc-ret.c scan-assembler return[ \t]*%i7\\+8\n[^\n]*nop Any ideas why? Would you like me to provide any more information, just let me know what and perhaps how... -- Cheers, /ChJ
