headers
Ishikawa | 1 Jul 2003 02:06
Picon

Re: Req: Disable I18N/L10N translation for gcc -print-search-dirsoutput.

Zack Weinberg wrote:
> 
> Neil Booth <neil <at> daikokuya.co.uk> writes:
> 
> >> Request: Disable I18N/L10N translation for gcc -print-search-dirs output.
> >>
> >>      Please don't change the output of
> >>
> >>      gcc -print-search-dirs
> >>
> >>      depending on the LC_ALL environment variable setting.
> >>      That is, keep the output from the modification done
> >>      by I18N/L10N scheme.
> >
> > I disagree.  The script is broken and that is what should be fixed,
> > either by improving its output recognition or by setting the
> > appropriate environment variables so it can reasonably expect
> > the output it is seeking.
> 
> It would probably be a good idea to add more -print options, or simply
> document existing -print options, which print just the one thing that
> a script is looking for, with no tag strings to confuse the issue.
> 
> gcc -print-include-search-dirs
>     -print-lib-search-dirs
>     -print-bin-search-dirs
> 
> Like that.
> 
> zw
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brian R. Gaeke | 1 Jul 2003 02:30
Picon

fix-header crash (gcc 3.3.1 20030630)


Hi,

In the process of trying to build a cross compiler from i686-pc-linux-gnu
to sparcv9-sun-solaris2, I caused fix-header to crash.  My machine is
running Red Hat Linux release 7.3 (Valhalla) and its compiler is gcc
version 2.96 20000731 (Red Hat Linux 7.3 2.96-113).  I reduced the test
case significantly; although the result looks kind of silly, it does
seem to cause a crash, and it appears at the end of my message. I am
using fix-header from the latest gcc snapshot (see subj.)

To reproduce, I run:

------------------------------------------------------------------------------
764 neo> ./fix-header barf.test.h barf.test.h barf.test.h
barf.test.h: OK, nothing needs to be done.
Segmentation fault (core dumped)
------------------------------------------------------------------------------

The backtrace seems to suggest that something the C runtime wanted has
been trod upon by a bad pointer access:

------------------------------------------------------------------------------
barf.test.h: OK, nothing needs to be done.

Program received signal SIGSEGV, Segmentation fault.
0x400a076e in chunk_free () from /lib/libc.so.6
(gdb) where
#0  0x400a076e in chunk_free () from /lib/libc.so.6
#1  0x400a0548 in free () from /lib/libc.so.6
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marty Hauff | 1 Jul 2003 02:55
Picon
Picon
Favicon

Re: Would you help me?

Check out "Porting GCC for Dunces" by Hans-Peter Nilsson.  It has a
section under "Random Remarks" about how a port should be approached -
might be helpful.

Marty Moose

>>> "wang mars" <hikermars <at> msn.com> 06/29/03 20:53 PM >>>
Hello, dear all:

        My name is Marco. I am a postgraduate researching in compiler. 
Because GCC is so powerful that all the professors I know

    suggested me to research in GCC and learn how to port GCC to any new

targets or processors. Because I am a beginner, I wonder

    what kind of help could I get from you? I have read the document
about 
GCC internal on the web site for several times, it did a lot 

    of help for me to understand GCC internal. But when I really started
to 
port it to the new target, I was still confused about how and 

    what to begin. Now I am still tracing GCC, but I think if you could 
give me some suggestions or the details about how to port GCC 

    or any document that you suggest me to read or anything you can, it 
will do me a lot of favor and make it easier for me to research
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott Robert Ladd | 1 Jul 2003 03:12
Favicon

Re: C99 features

Shaun Jackman wrote:
> Sorry, I should have been more specific. I'm looking for information
> about C99 itself. [snip]  I'd just like a summary of each
> feature added: a couple sentences and a code fragment would be perfect.
> Do you know of such a resource?

Try http://home.tiscalinet.ch/t_wolf/tw/c/c9x_changes.html.

..Scott

--

-- 
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Permalink | Reply | 0 comments |
headers
graydon hoare | 1 Jul 2003 03:47
Picon
Favicon

Re: some profiling numbers

Zack Weinberg <zack <at> codesourcery.com> writes:

> > it can produce many more profiles, and annotated sources, yes. no
> > call graphs in the current release, but that will be
> > forthcoming. part of the idea with producing these reports was to
> > show the general technique and encourage those people interested in
> > performance tuning to give the profiler a try for
> > themselves. there's an endless list of experiments and results one
> > might want to run, and I can only run so many of them.
> 
> I'm interested in trying some experiments myself, but I have never
> managed to get oprofile to work, and you already have the setup.

phew! ok, so I've made the following changes to my experiment setup:

- configured with --disable-checking
- removed gcc/c-parse.c and gcc/cp/parse.[ch] before building
- selected a different set of compilers (3.0, 3.1, 3.2, 3.3, HEAD)
- rebuilt all the compilers with "make bootstrap"

and I've re-collected the linux kernel build sample set for each
compiler, dumped all the sample output, and all the annotated sources
for files which saw any samples at all. the results are rather large
(about 300mb of annotated source) but that means there's lots of stuff
to look through. who knokws, maybe optimization can be
parallelized. I've posted it all on:

http://www.off.net/~graydon/gcc

the data is obviously in a more "raw" form, so should be more amenable
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ishikawa | 1 Jul 2003 04:02
Picon

Re: GCC gprof statistics

Zack Weinberg wrote:
> 
> Ishikawa <ishikawa <at> yk.rim.or.jp> writes:
> 
> > Once I get the latest CVS files in place,
> > I will produce
> >  - --print-search-dirs variants as suggested by Zack,
> >  - create a few experimental compilation speedup patches(2-3 %),
> >    which I believe will be helpful since for_each_rtx is rather small
> >    and called so many times in cc1 run,
> >  - and finally, will begin working on diagnostics.c format
> >    specifier thing again as suggested by Zack.
> >    (The last one will need people's input since I am not
> >     sure how the file is organized and I just read
> >    the description of portable VA_OPEN(), VA_CLOSE() macros, etc...
> 
> We're very glad to have you join the team.
> 
> It would be a good idea to start the ball rolling on copyright
> assignment paperwork now.  Please follow the instructions in the
> attached document.
> 

I sent it out.

> The good news is you can forget about VA_OPEN/VA_CLOSE; GCC 3.4 will
> require a C89 bootstrap compiler, so the normal <stdarg.h> primitives
> can be used instead.
> 
Sounds good!
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Edelsohn | 1 Jul 2003 04:57
Picon
Favicon

Re: GCC 3.3 build on AIX 5.2, ICE

>>>>> Alexy Khrabrov writes:

Alexy> Hmmm, I was thinking of putting a correct stdlib.h on an include path
Alexy> earlier than the broken one, then messing with configure to look at
Alexy> that fixed include path...  Doable?

	Maybe.

Alexy> xlc_r -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-3.3/libiberty/../include  
../../gcc-3.3/libiberty/objalloc.c -o objalloc.o

	Please read the installation instructions: you need to bootstrap
with "cc", not "xlc" or "xlc_r".

David
Permalink | Reply | 0 comments |
headers
Robert Dewar | 1 Jul 2003 05:01

Re: [tree-ssa] Computed gotos

> Yes, me too. The fortran version is called an assigned goto. Some confusion 
> is inevitable as Fortran also has a "computed goto", but that's different, 
> and trivially translatable into a select statement.

OK, my confusion then sorry. Why on earth is the C version called a computed
goto, that sure is a confused terminology, but I guess one that is familiar
in the GNU C world. I will take off my Fortran hat :-)
Permalink | Reply | 15 comments |
headers
Jeff Sturm | 1 Jul 2003 05:08

Re: gcc-3.3 CVS failing during libjava compile with: ./.libs/libgcj.so: undefined reference to `__gcc_personality_v0'

On 30 Jun 2003, Martin Schlemmer wrote:
> ./.libs/libgcj.so: undefined reference to `__gcc_personality_v0'

You'll see the same if you link a C program using cleanups with
-shared-libgcc -fexceptions.  The symbol isn't exported by libgcc_s.so.

I'd guess you need something like the following.

Jeff

Index: libgcc-std.ver
===================================================================
RCS file: /cvs/gcc/gcc/gcc/libgcc-std.ver,v
retrieving revision 1.21
diff -c -p -r1.21 libgcc-std.ver
*** libgcc-std.ver      7 May 2003 22:11:33 -0000       1.21
--- libgcc-std.ver      1 Jul 2003 03:06:40 -0000
*************** GCC_3.3 {
*** 183,188 ****
--- 183,190 ----
    _Unwind_Backtrace
    _Unwind_Resume_or_Rethrow
    _Unwind_SjLj_Resume_or_Rethrow
+   __gcc_personality_v0
+   __gcc_personality_sj0
  }

  %inherit GCC_3.4 GCC_3.3
(Continue reading)

Permalink | Reply | 6 comments |
headers
Kaveh R. Ghazi | 1 Jul 2003 06:06
Picon
Favicon

New bootstrap failures with remaining clk_* uses

Neil,

Your recent patch broke bootstrap on at least solaris2 and probably
several other platforms because you didn't catch uses of clk_* in the
config directory.  E.g. I needed this on solaris2:

diff -rup orig/egcc-CVS20030630/gcc/config/sol2.h egcc-CVS20030630/gcc/config/sol2.h
--- orig/egcc-CVS20030630/gcc/config/sol2.h	2003-06-16 09:44:20.000000000 -0400
+++ egcc-CVS20030630/gcc/config/sol2.h	2003-06-30 23:54:10.060239000 -0400
 <at>  <at>  -66,7 +66,7  <at>  <at>  Boston, MA 02111-1307, USA.  */
 	/* For C++ we need to add some additional macro	\
 	   definitions required by the C++ standard	\
 	   library.  */					\
-	if (c_language == clk_cplusplus)		\
+	if (c_dialect_cxx())				\
 	  {						\
 	    builtin_define ("_XOPEN_SOURCE=500");	\
 	    builtin_define ("_LARGEFILE_SOURCE=1");	\

I see about 15-20 others remain.  Would you please fix them all?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			ghazi <at> caip.rutgers.edu
Permalink | Reply | 1 comment |

Gmane