This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ACATS
- From: "John R. Shannon" <john at johnrshannon dot com>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 29 Apr 2004 10:39:34 -0600
- Subject: Re: ACATS
- Organization: johnrshannon.com
- References: <NUTMEGPuYnYJbXmZoGA000000ca@NUTMEG.CAM.ARTIMI.COM>
- Reply-to: john at johnrshannon dot com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
An answer to "What's actually at .L123 ?" :
.LC123:
.long 1
.long 1
.long 1
.long 1
.long 1
.long 1
.long 1
.long 1
.long 1
.long 1
.long 1
.long 1
.long 1
.long 1
.long 1
.data
.align 16
.LC68:
.quad .LC124
.quad .LC59
.section .rodata
.align 8
Replacing LC124 with LC123 in LC68 fixes the problem and allows the test case
(this is one of the ACATS tests) to pass.
P.S.:
gcc -v
Reading specs from /usr/pkg/tasking/lib/gcc/x86_64--netbsdelf2.0/3.4.0/specs
Configured
with: /home/drochner/netbsd/pkg/wip/gcc-3.4-ada/work.x86_64/gcc-3.4.0/configure
- --enable-languages=c,ada --prefix=/usr/pkg/tasking
- --host=x86_64--netbsdelf2.0
Thread model: posix
gcc version 3.4.0
Same test works in ix86 -- netbsdelf2.0
On Thursday 29 April 2004 10:18 am, Dave Korn wrote:
> > -----Original Message-----
> > From: gcc-owner On Behalf Of John R. Shannon
> > Sent: 29 April 2004 16:59
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Thank you. I have a case of '.L124' being reference where it
> > should be '.L123'.
>
> Ouch. Grep the source for ASM_OUTPUT_INTERNAL_LABEL where the second
> parameter is "L", and you'll see that these are generated in
> final_scan_insn in final.c, using CODE_LABEL_NUMBER (insn). However
> defaults.h also implements default definitions of ASM_OUTPUT_ADDR_VEC_ELT
> and
> ASM_OUTPUT_DEBUG_LABEL from ASM_OUTPUT_INTERNAL_LABEL. So your problem may
> be specifically related either to switch....case constructs, or to debug
> info, or your problem may be more generic. What's actually at .L123 ?
>
> The problem seems likely to be that either the CODE_LABEL_NUMBER field of
> the insn is getting stomped on, or something is damaging the operand of the
> reference in the label_ref. It might become clear which by following the
> rtl dumps through the various stages; or it might be something you can
> locate easily by setting a watchpoint or two with gdb. I'd suspect
> something going wrong when insns get deleted, myself.
>
>
>
> cheers,
> DaveK
- --
John R. Shannon
john@johnrshannon.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)
iEYEARECAAYFAkCRL8cACgkQOKbCxya4HYv6nACeJyvvE8dhCNPyVpE/O3Z1DxPb
VhQAn0WR6m0cru8OW9WLaAtkmy8hGa/g
=eXNv
-----END PGP SIGNATURE-----