This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: Incorrect code on PowerPC
- To: Gary Thomas <gdt at linuxppc dot org>
- Subject: Re: Incorrect code on PowerPC
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 05 Jan 1999 01:57:48 -0700
- cc: egcs-bugs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <XFMail.990104121057.gdt@linuxppc.org>you write:
> This bug makes compiling the latest GTK/GNOME packages fail. I have
> extracted a piece of one of the GTK library files and isolated it to
> a single function.
>
> The attached file contains the source, ".i", ".s" files, along with
> an explanation of why the code is incorrect. I can send the files from
> "-da" separately, but they are really large.
Excellent. We may need one or more of the -da files at some point. But
let's wait until we know which ones.
> Questions:
> Is there some document I can read which will help me to better
> understand these [dump] files?
The gcc documentation describes the RTL format in detail. It's not terribly
complicated once you get used to the basic concepts.
> Also, a correlation of which file gets generated when and how the
> various -Ox options affect this would be useful.
:-) Much of this is also in the gcc documentation. The major passes will
create dump files. Various passes are enabled by different -Ox options as
described in the manual.
> Is there any [portable] way to get some indication in the ".s" file
> of the corresponding C source lines?
For human consumption? I often include -g and scan the stabs debug symbols
since they include line #s. Similarly for dwarf targets, though I'm less
adept at reading dwarf debug symbols.
jeff