Re: -flto / -flto-partition=none question on ia64-hp-hpux11.23

[Richard Guenther]

On Tue, Mar 1, 2011 at 12:27 AM, Steve Ellcey  wrote:
> On Mon, 2011-02-28 at 23:56 +0100, Richard Guenther wrote:
>
>> The gcc_personality is provided by libgcc_s I think, it's what you
>> get when compiling C code with -fexceptions and install
>> cleanup handlers.
>>
>> It seems that LTO comes to the conclusion that the C++ specific
>> personality is not necessary but the generic one suffices.  But
>> that should still be provided by the original link libraries.
>>
>> Richard.
>
> The libgcc_s on the ia64-hp-hpux* platform, at least when built using
> the system unwind library, does not have a gcc personality function and
> so far it has not needed one.  It seems odd that LTO would choose to use
> a C personality function on a fully C++ program.  Is there someway I can
> override that and force LTO to use the C++ personality function on C++
> programs?

There is currently no way to force this for a particular target.

> It looks like this is coming from lto_eh_personality in lto.c through
> the use of lhd_gcc_personality.

It comes from the fact that we delay choosing a personality function
for functions that are happy with any personality.  There is
the function_needs_eh_personality () function that decides this.
If you force that to never return eh_personality_any but
eh_personality_lang this optimization would not happen.

Note that the missing personality function in libgcc_s is a bug though
as rth notes.

Richard.

>
> Steve Ellcey
> s...@cup.hp.com
>
>

Re: Triplet for ARM Linux HardFP ABI, again

[Andrew Stubbs]

On 21/02/11 10:12, Guillem Jover wrote:

This was already discussed in this list some time ago [0]. But it came
up again when restarting the discussion for the proposed new armhf port
for Debian.

   [0]

My arguments for why a distinct triplet is needed can be found in [1],
it's a big long though. Most of the points there revolve around the
fact that we rely on the toolchains as configured by_default_  to
produce the expected output targetting a concrete architecture, it
also has implications for the file system paths.

   [1]

It seems from reading the past discussion on this list that the main
objection was that the triplet should not be used to decide what
floating point ABI to use in gcc. No problem with that!


Up front, let me say I disagree with the previous finding that the 
triplet isn't the right place for this kind of thing. It's clear to me 
that there's plenty of prior art here, and it would work for us very 
nicely, thank you very much. That said, there are down-sides to 
target-triplets (not least that once you've chosen one, you find 
yourself stuck with it for backward compatibility, even after it makes 
no sense any more), and many people seem to believe it would be better 
if they had never been invented, so .


I fail to see how abusing the OS/ABI field is any better than abusing 
the vendor field?


The patch you posted is surely just the tip of the iceberg - there are 
thousands of packages in Debian, and any one of them might need 
adjustment to cope with this change.


When I proposed a new triplet before, in the thread you referenced 
above, I proposed having an 'official' name that everyone would agree 
on. That would have been disruptive. Your triplet would be unofficial, 
so I would say it would be hard to justify all that disruption. In the 
worst case, third parties would start to use your unofficial triplet 
inconditionally, and would need fixing up to work with anything that is 
not Debian.


In July's thread, it was decided (sort of) that the compiler should not 
choose its (micro-)configuration based on the triplet. I didn't really 
agree with that, but there it is. You've decided to stick with that, and 
have the triplet influence only your build-system. Surely that's exactly 
what the 'vendor' field is for? It seems like (it has to be) a 
vendor-specific configuration to me.


Adjusting the vendor field should not break any of those thousands of 
packages (although, no doubt there'll be the odd one or two). It will 
give you your differentiated pathnames. It will tell your build-system 
what to do. Why do it the hard way if there is no advantage?


Andrew

Re: gcc-4.5/4.4: Bug in .subreg1 pass?

[Denis Chertykov]

2011/2/28 Georg-Johann Lay :
> Denis Chertykov schrieb:
>>
>> 2011/2/26 Georg-Johann Lay :
>>
>>> Ok, this is the patch I meant:
>>>
>>> http://gcc.gnu.org/viewcvs?view=revision&revision=86842
>>>
>>> it allows just Pmode in r29:r28 because of some spill failures in PR15417
>>> and PR12017.
>>
>> It was a stupid workaround.
>> I think that the problem exists anyway because it's not a port problem.
>>
>> Denis.
>
> PR41894 is yet another variation of the problem.
>
> Removong the restricting code like so
>
> int
> avr_hard_regno_mode_ok (int regno, enum machine_mode mode)
> {
>  /* Disallow QImode in stack pointer regs.  */
>  if ((regno == REG_SP || regno == (REG_SP + 1)) && mode == QImode)
>    return 0;
>
> -  /* The only thing that can go into registers r28:r29 is a Pmode.  */
> -  if (regno == REG_Y && mode == Pmode)
> -    return 1;
> -
> -  /* Otherwise disallow all regno/mode combinations that span r28:r29.
> -  */
> -  if (regno <= (REG_Y + 1) && (regno + GET_MODE_SIZE (mode)) >= (REG_Y +
> 1))
> -    return 0;
> -
>  if (mode == QImode)
>    return 1;
>
>  /* Modes larger than QImode occupy consecutive registers.  */
>  if (regno + GET_MODE_SIZE (mode) > FIRST_PSEUDO_REGISTER)
>    return 0;
>
>  /* All modes larger than QImode should start in an even register.  */
>  return !(regno & 1);
> }
>
> leads to correct code.
>
> But I don't understand enough of reload/inerts of fp elimination to estimate
> all undesired side effects.
>
> Maybe someone with more insight in reload can comment on this issue?

As I remeber, this is not a port bug. It was a reload bug.
According to documentation avr_hard_regno_mode_ok must be:
int
avr_hard_regno_mode_ok (int regno, enum machine_mode mode)
{
  /* All modes larger than QImode should start in an even register.  */
  return !(regno & 1);
}

Denis.

Re: -flto / -flto-partition=none question on ia64-hp-hpux11.23

[Steve Ellcey]

On Tue, 2011-03-01 at 11:10 +0100, Richard Guenther wrote:

> It comes from the fact that we delay choosing a personality function
> for functions that are happy with any personality.  There is
> the function_needs_eh_personality () function that decides this.
> If you force that to never return eh_personality_any but
> eh_personality_lang this optimization would not happen.
> 
> Note that the missing personality function in libgcc_s is a bug though
> as rth notes.
> 
> Richard.

Yes, if I change function_needs_eh_personality () to return
eh_personality_lang instead of eh_personality_any then the test passes.

According to PR 20095 the reason for not implementing
__gcc_personality_v0 is that the HP unwind library does not implement
_UA_END_OF_STACK which is a GCC extension to the standard IA64 unwind
ABI and the HP-UX system unwind does not support it so the only way
to implement __gcc_personality_v0 is to use the GCC libunwind instead of
the HP-UX system one.

Steve Ellcey
s...@cup.hp.com

[ARM] Cortex-M3 multiply costs

[Alexandre Pereira Nunes]

AFAIK, Cortex-M3 has single-cycle multiply, right?
I'm seeing gcc 4.5.2 prefering to do a lot (up to 5) of adds w/ shifts
in places where a single mult would suffice.
If I'm interpreting it right, where are the costs computed?
Thanks!
Alexandre

Re: -flto / -flto-partition=none question on ia64-hp-hpux11.23

[Ian Lance Taylor]

Steve Ellcey  writes:

> According to PR 20095 the reason for not implementing
> __gcc_personality_v0 is that the HP unwind library does not implement
> _UA_END_OF_STACK which is a GCC extension to the standard IA64 unwind
> ABI and the HP-UX system unwind does not support it so the only way
> to implement __gcc_personality_v0 is to use the GCC libunwind instead of
> the HP-UX system one.

I don't understand this point.  It's true that gcc's unwind library will
pass _UA_END_OF_STACK to the stop function passed to
_Unwind_ForcedUnwind if the unwind library returns _URC_END_OF_STACK.
But I don't see what that has to do with __gcc_personality_v0.
__gcc_personality_v0 does not generate or look for _UA_END_OF_STACK, nor
should it, as it is not a stop function passed to _Unwind_ForcedUnwind.

Ian

gcc-4.4-20110301 is now available

[gccadmin]

Snapshot gcc-4.4-20110301 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110301/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch 
revision 170599

You'll find:

 gcc-4.4-20110301.tar.bz2 Complete GCC (includes all of below)

  MD5=bf2951cb5cf2121507cad3f43a6278dc
  SHA1=0605a1cd6697bc5f192a778eb1d398bca5de80dd

 gcc-core-4.4-20110301.tar.bz2C front end and core compiler

  MD5=5edf8c44fc1c56db5a42430cb021c608
  SHA1=43f303fdf1f5cbbf7591efc237224712f34f3d3c

 gcc-ada-4.4-20110301.tar.bz2 Ada front end and runtime

  MD5=7ff6d5b2b591a58a8ea0ada070799049
  SHA1=6288b23e21d0c421f1191ad681abef973573be64

 gcc-fortran-4.4-20110301.tar.bz2 Fortran front end and runtime

  MD5=dec1ecccb777fcb8035fbf220dbcde3f
  SHA1=951ffb5b83ebc6f353766ea348614c92816a556d

 gcc-g++-4.4-20110301.tar.bz2 C++ front end and runtime

  MD5=f2ba4f70709dd50e3b807b777c018eb7
  SHA1=4ad19668f7f275c7bbd3bb75c654a35f20bf9316

 gcc-go-4.4-20110301.tar.bz2  Go front end and runtime

  MD5=4403480e6de065698de0c77da3bb0b03
  SHA1=f540193a02b635c74857fbfc1d7dd1afb2dddbd5

 gcc-java-4.4-20110301.tar.bz2Java front end and runtime

  MD5=6768080bf613a0ee0b5c2409e249f4dd
  SHA1=81968eab2633f10f5ca097fe10ee8dfaab7df421

 gcc-objc-4.4-20110301.tar.bz2Objective-C front end and runtime

  MD5=62f339fbd47f3c618f2c3dfb1de3a6e9
  SHA1=8280733eb2b856773e74c5e4a82577b3991dd860

 gcc-testsuite-4.4-20110301.tar.bz2   The GCC testsuite

  MD5=b9dba21894edf2e928317945691c898c
  SHA1=001fd1a19e58b69cf9ca09924ebcf59834046cd7

Diffs from 4.4-20110222 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: -flto / -flto-partition=none question on ia64-hp-hpux11.23

[Steve Ellcey]

On Tue, 2011-03-01 at 13:45 -0800, Ian Lance Taylor wrote:
> Steve Ellcey  writes:
> 
> > According to PR 20095 the reason for not implementing
> > __gcc_personality_v0 is that the HP unwind library does not implement
> > _UA_END_OF_STACK which is a GCC extension to the standard IA64 unwind
> > ABI and the HP-UX system unwind does not support it so the only way
> > to implement __gcc_personality_v0 is to use the GCC libunwind instead of
> > the HP-UX system one.
> 
> I don't understand this point.  It's true that gcc's unwind library will
> pass _UA_END_OF_STACK to the stop function passed to
> _Unwind_ForcedUnwind if the unwind library returns _URC_END_OF_STACK.
> But I don't see what that has to do with __gcc_personality_v0.
> __gcc_personality_v0 does not generate or look for _UA_END_OF_STACK, nor
> should it, as it is not a stop function passed to _Unwind_ForcedUnwind.
> 
> Ian

I guess it isn't related directly to __gcc_personality_v0.  If I include
unwind-c.c in the ia64-hp-hpux11.23 build then I get the C personality
function and the pr33572.C test passes with -flto.  The reason we didn't
include this file before (in response to PR 20095) was that even if we
added unwind-c.c to the build, it didn't fix gcc.dg/cleanup-5.c.  That
test still fails with a segfault in the HP-UX unwind library (In
_Unwind_ForcedUnwind).

So maybe we should include unwind-c.c to fix the -flto failures.

Steve Ellcey
s...@cup.hp.com

Liqin Chen now maintainer of SCORE port

[Mark Mitchell]

Liqin --

The GCC SC has appointed you the maintainer of the SCORE back-end.

Congratulations!

As we've discussed previously, the mere fact that there is a maintainer
for a port does not imply that the port will not be deprecated or
removed.  So, I hope that you will be able to actively maintain the port
from this point forward.

Please remember to update the MAINTAINERS file.

Thank you,

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

new libjava bootstrap failure

[Jack Howarth]

   Is anyone else building java with lto-bootstrap? At r170606 I am seeing a 
bootstrap
failure which appears as...

/bin/sh ./libtool --tag=CXX   --mode=compile 
/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc/xgcc -shared-libgcc 
-B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/./gcc -nostdinc++ 
-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libstdc++-v3/src
 
-L/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/x86_64-apple-darwin10.7.0/libstdc++-v3/src/.libs
 -B/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/bin/ 
-B/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/lib/ -isystem 
/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/include -isystem 
/sw/lib/gcc4.6/x86_64-apple-darwin10.7.0/sys-include-DHAVE_CONFIG_H -I. 
-I../../../gcc-4.6-20110301/libjava -I./include -I./gcj  
-I../../../gcc-4.6-20110301/libjava -Iinclude 
-I../../../gcc-4.6-20110301/libjava/include 
-I../../../gcc-4.6-20110301/libjava/classpath/include -Iclasspath/include 
-I../../../gcc-4.6-20110301/libjava/classpath/native/fdlibm 
-I../../../gcc-4.6-20110301/libjava/../boehm-gc/include -I../boehm-gc/include  
-I../../../gcc-4.6-20110301/libjava/libltdl 
-I../../../gcc-4.6-20110301/libjava/libltdl 
-I../../../gcc-4.6-20110301/libjava/.././libjava/../gcc  
-I../../../gcc-4.6-20110301/libjava/../libffi/include -I../libffi/include 
-I/sw/include -fno-rtti -fnon-call-exceptions  -fdollars-in-identifiers 
-Wswitch-enum -D_FILE_OFFSET_BITS=64 -fomit-frame-pointer -Wextra -Wall 
-D_GNU_SOURCE -DPREFIX="\"/sw/lib/gcc4.6\"" 
-DTOOLEXECLIBDIR="\"/sw/lib/gcc4.6/lib\"" -DJAVA_HOME="\"/sw/lib/gcc4.6\"" 
-DBOOT_CLASS_PATH="\"/sw/lib/gcc4.6/share/java/libgcj-4.6.0.jar\"" 
-DJAVA_EXT_DIRS="\"/sw/lib/gcc4.6/share/java/ext\"" 
-DGCJ_ENDORSED_DIRS="\"/sw/lib/gcc4.6/share/java/gcj-endorsed\"" 
-DGCJ_VERSIONED_LIBDIR="\"/sw/lib/gcc4.6/lib/gcj-4.6.0-12\"" 
-DPATH_SEPARATOR="\":\"" -DECJ_JAR_FILE="\"/sw/lib/gcc4.6/share/java/ecj.jar\"" 
-DLIBGCJ_DEFAULT_DATABASE="\"/sw/lib/gcc4.6/lib/gcj-4.6.0-12/classmap.db\"" 
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL="\"gcj-4.6.0-12/classmap.db\"" -g -O2 -MT 
jni-libjvm.lo -MD -MP -MF $depbase.Tpo -c -o jni-libjvm.lo 
../../../gcc-4.6-20110301/libjava/jni-libjvm.cc &&\
mv -f $depbase.Tpo $depbase.Plo
make[4]: *** No rule to make target `.deps/gij.Plo'.  Stop.
make[3]: *** [all-multi] Error 2
make[3]: *** Waiting for unfinished jobs

Could this be related to the recent lto-streamer changes? I am using...

../gcc-4.6-20110301/configure --prefix=/sw --prefix=/sw/lib/gcc4.6 
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.6/info 
--with-build-config=bootstrap-lto --enable-stage1-languages=c,lto 
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --enable-build-with-cxx 
--with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw 
--with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include 
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.6 --enable-checking=yes 
--enable-cloog-backend=isl

on x86_64-apple-darwin10 with 'make -j 8'. Oddly, after the failed bootstrap, 
if I just use 'make'
the build completes successfully.
  Jack

Re: new libjava bootstrap failure

[Dave Korn]

On 02/03/2011 03:23, Jack Howarth wrote:
>Is anyone else building java with lto-bootstrap? At r170606 I am seeing a 
> bootstrap
> failure which appears as...

> make[4]: *** No rule to make target `.deps/gij.Plo'.  Stop.
> make[3]: *** [all-multi] Error 2
> make[3]: *** Waiting for unfinished jobs
> 
> Could this be related to the recent lto-streamer changes?

  Seems more likely something went wrong earlier, while making
configure-target-libjava; config.status is supposed to create blank dummy
dependency files to get the build going.

  Any trace of that earlier failure?  Does running "rm .deps/gij.Plo &&
./config.status Makefile depfiles" in the failing directory regenerate
.deps/gij.Plo with the content "# dummy"?

> on x86_64-apple-darwin10 with 'make -j 8'. Oddly, after the failed bootstrap, 
> if I just use 'make'
> the build completes successfully.

  The .Plo files are generated as a side-effect of compiling the .o files, so
one of the "unfinished jobs" was presumably busy compiling gij.lo which is a
target that there is a separate pattern rule to cause to build.  So next time
you compiled, the required .Plo file was already there.

cheers,
  DaveK

Re: new libjava bootstrap failure

[Jack Howarth]

On Wed, Mar 02, 2011 at 04:58:41AM +, Dave Korn wrote:
> On 02/03/2011 03:23, Jack Howarth wrote:
> >Is anyone else building java with lto-bootstrap? At r170606 I am seeing 
> > a bootstrap
> > failure which appears as...
> 
> > make[4]: *** No rule to make target `.deps/gij.Plo'.  Stop.
> > make[3]: *** [all-multi] Error 2
> > make[3]: *** Waiting for unfinished jobs
> > 
> > Could this be related to the recent lto-streamer changes?
> 
>   Seems more likely something went wrong earlier, while making
> configure-target-libjava; config.status is supposed to create blank dummy
> dependency files to get the build going.
> 
>   Any trace of that earlier failure?  Does running "rm .deps/gij.Plo &&
> ./config.status Makefile depfiles" in the failing directory regenerate
> .deps/gij.Plo with the content "# dummy"?
> 
> > on x86_64-apple-darwin10 with 'make -j 8'. Oddly, after the failed 
> > bootstrap, if I just use 'make'
> > the build completes successfully.
> 
>   The .Plo files are generated as a side-effect of compiling the .o files, so
> one of the "unfinished jobs" was presumably busy compiling gij.lo which is a
> target that there is a separate pattern rule to cause to build.  So next time
> you compiled, the required .Plo file was already there.
> 
> cheers,
>   DaveK

Dave,
   I tried again without --enable-build-with-cxx and it worked. I'll see if I 
can
reproduce it again with --enable-build-with-cxx.
   Jack

Re: new libjava bootstrap failure

[Dave Korn]

On 02/03/2011 05:10, Jack Howarth wrote:

>I tried again without --enable-build-with-cxx and it worked. I'll see if I 
> can
> reproduce it again with --enable-build-with-cxx.

  Bizarre.  Can't see how that would be related, but you never know what kind
of odd knock-on effects a bug can have...

  If you want to understand in detail the mechanism for dependency tracking in
automake, and the logic behind not having any rules to build the .Plo files,
having them appear as side-effects of a compile, and having to create dummies
first, see:

 http://mad-scientist.net/make/autodep.html

although note that where that recommends using "-include" (under "Avoiding
``No rule to make target ...'' Errors") to ignore would-be errors from trying
to include non-existent files, we use an unprefixed include directive to read
them in our Makefiles, and rely on config.status to generate empty ones first
time round.  I'm not sure why we do that differently.

cheers,
  DaveK

Re: new libjava bootstrap failure

[Ralf Wildenhues]

Hello Dave,

* Dave Korn wrote on Wed, Mar 02, 2011 at 06:28:15AM CET:
>  http://mad-scientist.net/make/autodep.html
> 
> although note that where that recommends using "-include" (under
> "Avoiding ``No rule to make target ...'' Errors") to ignore would-be
> errors from trying to include non-existent files, we use an unprefixed
> include directive to read them in our Makefiles, and rely on
> config.status to generate empty ones first time round.  I'm not sure
> why we do that differently.

That's because non-GNU makes don't have facilities to include a file
only if it is present, and with the current machinery, a non-present
file always indicates a bug (or previous error) and having errors be
loud is a good thing for debugging.

Jack, the actual issue you're seeing might well be the result of some
missing dependency.  With parallel build failures, it is most important
to see output from make, back to at least the first error that happened.
That can be arbitrarily far back, and in GCC it is not uncommon to have
it happen a few thousand lines before the end of the log.  Please save
such logs for future reports.

Thanks,
Ralf

Re: how can I write a right V32QI Unpack Low Data insn pattern?

[Liu]

On Tue, Mar 1, 2011 at 7:29 AM, Ian Lance Taylor  wrote:
> Liu  writes:
>
>> I write a v16hi mode Unpack Low Data insn pattern and it is OK. v8si
>> and v4di modes are OK, too.
>> But the v32qi mode Unpack Low Data insn pattern get error like:
>> ../../gcc-4.5.1/gcc/config/mips/hr.md:509: error: expected identifier
>> or '(' before 'goto'
>> ../../gcc-4.5.1/gcc/config/mips/hr.md:511: error: expected '=', ',',
>> ';', 'asm' or '__attribute__' before ':' token
>> anyone will tell me what's wrong with my code?
>
> Looks like something in a .h file has #define'd something that your .md
> file is using.  I can't tell what it is from the code fragment here.  If
> it's not obvious, you are going to have to look at the generated file,
> and possibly even the preprocessed version of the generated file.
>
> Ian
>

hi Ian, thank you for reply.

I didn't find something in a.h has #define used by my .md file.
but I find error at insn-recog.c.
When I delete all "#line xxx" in insn-recog.c, compile it as:
gcc -c  -g -O0 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition
-Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5.1/gcc
-I../../gcc-4.5.1/gcc/. -I../../gcc-4.5.1/gcc/../include
-I../../gcc-4.5.1/gcc/../libcpp/include -I/cross-tools/include
-I/cross-tools/include  -I../../gcc-4.5.1/gcc/../libdecnumber
-I../../gcc-4.5.1/gcc/../libdecnumber/dpd -I../libdecnumber
-I/cross-tools/include  -I/cross-tools/include -DCLOOG_PPL_BACKEND
insn-recog.c -o insn-recog.o

I get a lot of errors like this:
insn-recog.c: In function 'recog_21':
insn-recog.c:24754: error: expected expression before '{' token
insn-recog.c:24760: error: expected expression before '|' token
insn-recog.c:24766: error: expected expression before '}' token
insn-recog.c:24766: error: expected ')' before '}' token
insn-recog.c:24766: error: expected ')' before '}' token
insn-recog.c:24766: error: expected ';' before '}' token
insn-recog.c:24108: error: label 'ret0' used but not defined
insn-recog.c:24104: error: label 'L9397' used but not defined
insn-recog.c: At top level:
insn-recog.c:24766: error: expected identifier or '(' before ']' token
insn-recog.c:24767: error: expected identifier or '(' before 'if'
insn-recog.c:24769: error: expected identifier or '(' before 'goto'
insn-recog.c:24771: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24773: error: expected identifier or '(' before 'if'
insn-recog.c:24775: error: expected identifier or '(' before 'goto'
insn-recog.c:24777: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24778: error: stray '\177' in program
insn-recog.c:24779: error: expected identifier or '(' before 'if'
insn-recog.c:24781: error: expected identifier or '(' before 'goto'
insn-recog.c:24783: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24784: error: stray '\200' in program
insn-recog.c:24785: error: expected identifier or '(' before 'if'
insn-recog.c:24791: error: expected identifier or '(' before 'goto'
insn-recog.c:24793: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24795: error: expected identifier or '(' before 'if'
insn-recog.c:24797: error: expected identifier or '(' before 'goto'
insn-recog.c:24799: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24809: error: expected identifier or '(' before 'goto'
insn-recog.c:24811: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24813: error: expected identifier or '(' before 'if'
insn-recog.c:24818: error: expected identifier or '(' before 'goto'
insn-recog.c:24820: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24822: error: expected identifier or '(' before 'if'
insn-recog.c:24825: error: expected identifier or '(' before 'goto'
insn-recog.c:24827: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24829: error: expected identifier or '(' before 'if'
insn-recog.c:24834: error: expected identifier or '(' before 'goto'
insn-recog.c:24836: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24842: error: expected identifier or '(' before 'goto'
insn-recog.c:24844: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24846: error: expected identifier or '(' before 'if'
insn-recog.c:24851: error: expected identifier or '(' before 'goto'
insn-recog.c:24853: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':' token
insn-recog.c:24855: error: expected identifier or '(' before 'if'
insn-recog.c:24858: error: expected identifier or '(' before 'goto'
insn-recog.c:24860: error: expected '=', ',', ';', 'asm' or
'__attribute__' before ':