RE: newlib & libgcov
I don't know why GCC defines inhibit_libc during configuration. Now I
use --with-headers according to another mail's suggestion, this problem
is solved. Thanks.
Bingfeng
-Original Message-
From: Jan Hubicka [mailto:[EMAIL PROTECTED]
Sent: 16 June 2008 02:54
To: Bingfeng Mei
Cc: gcc@gcc.gnu.org
Subject: Re: newlib & libgcov
> Hello,
> In our GCC porting, we use newlib instead of libc. Today I tried to
use
> profiling feedback based optimization with option -fprofile-arcs. But
> the executable doesn't produce .gcda file. I examined the
disassembled
> binary file and found the following functions are basically just dummy
> ones: __gcov_init, __gcov_flush, __gcov_merge_add. I checked
libgcov.c
> that contains these functions and found following code.
>
>
> #if defined(inhibit_libc)
I am not much expert in this area, but the inhibit_libc check here is
mainly to disable gcov functions for freestanding targets that don't
support normal IO. If you use newlib instead of glibc, you still do
have libc, so why inhibit_libc is defined at first place?
Honza
> /* If libc and its header files are not available, provide dummy
> functions. */
>
> #ifdef L_gcov
> void __gcov_init (struct gcov_info *p __attribute__ ((unused))) {}
> void __gcov_flush (void) {}
> #endif
>
> #ifdef L_gcov_merge_add
> void __gcov_merge_add (gcov_type *counters __attribute__ ((unused)),
> unsigned n_counters __attribute__ ((unused))) {}
> #endif
>
> #ifdef L_gcov_merge_single
> void __gcov_merge_single (gcov_type *counters __attribute__
((unused)),
> unsigned n_counters __attribute__ ((unused)))
> {}
> #endif
>
> #ifdef L_gcov_merge_delta
> void __gcov_merge_delta (gcov_type *counters __attribute__
((unused)),
>unsigned n_counters __attribute__ ((unused)))
> {}
> #endif
>
>
> Both -Dinhibit_libc and -DL_gcov are used as shown in our building log
> file. I guess -Dinhibit_libc is added because we used newlibc instead
> of glibc. I tried to grep these functions in newlibc and didn't find
> them. My question is how to enable gcov with newlibc. Do I need to
> write my own versions of them? Any suggestion is greatly appreciated.
>
> Cheers,
> Bingfeng Mei
>
> Broadcom UK
Re: C++ warnings vs. errors
2008/6/16 Jonathan Wakely <[EMAIL PROTECTED]>: > 2008/6/13 Mark Mitchell: >> Jonathan Wakely wrote: >>> >>> Hi Volker, thanks for picking these issues up. I told Manuel I'd >>> review the rest of the remaining pedwarns, but haven't had time to do >>> it either. >> >> Just to chime in here: Volker, I agree with your comments. > > I think we all do :-) > >> Jonathan, Manuel, if you would please make the time to finish this project, >> that would be very much appreciated. We don't want this to be a case where >> we improved the infrastructure of the compiler -- but made the user >> experience worse. > > Absolutely agreed. I'm working on it. Sorry for the delay, until > Volker's mail I didn't realise most of the pedwarns hadn't changed to > permerrors already. If you make a list of pedwarns that should be permerrors and you get a C++ maintainer to review it and agree with it. I will write the patch, bootstrap+test it, adjust any failing testcases, and commit it in your name. Cheers, Manuel.
Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
Hi, When linking a very large (> 100MB executable) application on powerpc-linux with trunk we get linker errors: .../lib/gcc/powerpc-unknown-linux-gnu/4.4.0/crtbegin.o:(.fini+0x0): relocation truncated to fit: R_PPC_REL24 against `.text' .../lib/gcc/powerpc-unknown-linux-gnu/4.4.0/crtend.o:(.init+0x0): relocation truncated to fit: R_PPC_REL24 against `.text' The application itself is compiled with -mlongcall, would adding -mlongcall to crtstuff.c Makefile rule help here? If no, what is the proper solution GCC-wise? Thanks in advance, Laurent
Is this a GCC bug?
Hello,
I encountered a problem in porting GCC (4.3.0) when I tried to make
contructor/destructor work. The following is the error message compiling
crtstuff.c.
../../src/gcc/crtstuff.c: In function 'call___do_global_ctors_aux':
../../src/gcc/crtstuff.c:562: error: expected string literal before '('
token
Line 562 is:
...
CRT_CALL_STATIC_FUNCTION (INIT_SECTION_ASM_OP, __do_global_ctors_aux)
...
The following is how the macro CRT_CALL_STATIC_FUNCTION is defined.
#ifndef CRT_CALL_STATIC_FUNCTION
# define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC) \
static void __attribute__((__used__)) \
call_ ## FUNC (void) \
{ \
asm (SECTION_OP); \
FUNC (); \
FORCE_CODE_SECTION_ALIGN\
asm (TEXT_SECTION_ASM_OP);\
}
#endif
Here is the C code of line 562 after preprocessing in our porting:
static void __attribute__((__used__)) call___do_global_ctors_aux (void)
{ asm ("\t.section\t.init"); __do_global_ctors_aux (); asm
((firepath_fnsc ? "\t.section .textc, \"axC\"" : "\t.section .text,
\"axU\"")); }
The error is because inline asm only accepts string literal, not an
expression. Our definitiion of TEXT_SECTION_ASM_OP is a string depends
on one of our particular targets.
According to GCC internal manual, it is clearly stated that
TEXT_SECTION_ASM_OP can be an expression.
TEXT_SECTION_ASM_OP
A C expression whose value is a string, including spacing, containing
the assembler
operation that should precede instructions and read-only data. Normally
"\t.text"
is right.
So I guess either internal manual or crtstuff.c is wrong. Or I am making
some stupid mistake here. Could someone have a look at this? Thanks in
advance.
Cheers,
Bingfeng Mei
Broadcom UK
Updated comparison of GCC releases
Some people asked me to update GCC release comparison page on http://vmakarov.fedorapeople.org/spec/ I've added 4.3, new target x86_64 and SPECFP2000 for the comparison. You can find it on http://vmakarov.fedorapeople.org/spec/ Vlad
RE: Is this a GCC bug?
I realized I probably need to write CRT_CALL_STATIC_FUNCTION myself.
That should solve the issue.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Bingfeng Mei
Sent: 16 June 2008 14:01
To: gcc@gcc.gnu.org
Subject: Is this a GCC bug?
Hello,
I encountered a problem in porting GCC (4.3.0) when I tried to make
contructor/destructor work. The following is the error message compiling
crtstuff.c.
../../src/gcc/crtstuff.c: In function 'call___do_global_ctors_aux':
../../src/gcc/crtstuff.c:562: error: expected string literal before '('
token
Line 562 is:
...
CRT_CALL_STATIC_FUNCTION (INIT_SECTION_ASM_OP, __do_global_ctors_aux)
...
The following is how the macro CRT_CALL_STATIC_FUNCTION is defined.
#ifndef CRT_CALL_STATIC_FUNCTION
# define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC) \
static void __attribute__((__used__)) \
call_ ## FUNC (void) \
{ \
asm (SECTION_OP); \
FUNC (); \
FORCE_CODE_SECTION_ALIGN\
asm (TEXT_SECTION_ASM_OP);\
}
#endif
Here is the C code of line 562 after preprocessing in our porting:
static void __attribute__((__used__)) call___do_global_ctors_aux (void)
{ asm ("\t.section\t.init"); __do_global_ctors_aux (); asm
((firepath_fnsc ? "\t.section .textc, \"axC\"" : "\t.section .text,
\"axU\"")); }
The error is because inline asm only accepts string literal, not an
expression. Our definitiion of TEXT_SECTION_ASM_OP is a string depends
on one of our particular targets.
According to GCC internal manual, it is clearly stated that
TEXT_SECTION_ASM_OP can be an expression.
TEXT_SECTION_ASM_OP
A C expression whose value is a string, including spacing, containing
the assembler
operation that should precede instructions and read-only data. Normally
"\t.text"
is right.
So I guess either internal manual or crtstuff.c is wrong. Or I am making
some stupid mistake here. Could someone have a look at this? Thanks in
advance.
Cheers,
Bingfeng Mei
Broadcom UK
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
On Mon, Jun 16, 2008 at 01:27:58PM +0200, Laurent GUERBY wrote: > Hi, > > When linking a very large (> 100MB executable) application on > powerpc-linux with trunk we get linker errors: > > .../lib/gcc/powerpc-unknown-linux-gnu/4.4.0/crtbegin.o:(.fini+0x0): > relocation truncated to fit: R_PPC_REL24 against `.text' > .../lib/gcc/powerpc-unknown-linux-gnu/4.4.0/crtend.o:(.init+0x0): > relocation truncated to fit: R_PPC_REL24 against `.text' > > The application itself is compiled with -mlongcall, > would adding -mlongcall to crtstuff.c Makefile rule help here? It ought to. You could also try GNU ld's --relax option, which might also allow you to dispense with -mlongcall for your app. > If no, what is the proper solution GCC-wise? I'll note that this problem is exacerbated by the fact that crtbegin.o defines the destructor function run from .fini and crtend.o defines the constructor run from .init. It really should be the other way around, since this arrangement results in maximmum offset branches, from the .init section located before .text to a function at the end of .text, and from the .fini section located after .text to a function at the beginning of .text. -- Alan Modra Australia Development Lab, IBM
gccbug parser?
Daniel, I've submitted a bug report via gccbug about an hour ago, but so far have neither received a confirmation of the report nor a bounce. Is the gccbug parser at [EMAIL PROTECTED] still operational? Regards. Rainer - Rainer Orth, Faculty of Technology, Bielefeld University
Re: gccbug parser?
I haven't touched it in well over a year. I'll look what's up. On Mon, Jun 16, 2008 at 12:40 PM, Rainer Orth <[EMAIL PROTECTED]> wrote: > Daniel, > > I've submitted a bug report via gccbug about an hour ago, but so far have > neither received a confirmation of the report nor a bounce. Is the gccbug > parser at [EMAIL PROTECTED] still operational? > > Regards. >Rainer > > - > Rainer Orth, Faculty of Technology, Bielefeld University >
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
On Mon, 2008-06-16 at 23:36 +0930, Alan Modra wrote: > On Mon, Jun 16, 2008 at 01:27:58PM +0200, Laurent GUERBY wrote: > > Hi, > > > > When linking a very large (> 100MB executable) application on > > powerpc-linux with trunk we get linker errors: > > > > .../lib/gcc/powerpc-unknown-linux-gnu/4.4.0/crtbegin.o:(.fini+0x0): > > relocation truncated to fit: R_PPC_REL24 against `.text' > > .../lib/gcc/powerpc-unknown-linux-gnu/4.4.0/crtend.o:(.init+0x0): > > relocation truncated to fit: R_PPC_REL24 against `.text' > > > > The application itself is compiled with -mlongcall, > > would adding -mlongcall to crtstuff.c Makefile rule help here? > > It ought to. You could also try GNU ld's --relax option, which might > also allow you to dispense with -mlongcall for your app. You mean adding to config/rs6000/t-linux64 and create config/rs6000/t-linux with: CRTSTUFF_T_CFLAGS += -mlongcalls CRTSTUFF_T_CFLAGS_S += -mlongcalls Would a patch with this be approved on trunk? I noticed another target config/xtensa/t-elf which has something very close: # Build CRT files and libgcc with the "longcalls" option CRTSTUFF_T_CFLAGS += -mlongcalls CRTSTUFF_T_CFLAGS_S += -mlongcalls TARGET_LIBGCC2_CFLAGS += -mlongcalls Is the "TARGET_LIBGCC2_CFLAGS" necessary as well? > > If no, what is the proper solution GCC-wise? > > I'll note that this problem is exacerbated by the fact that crtbegin.o > defines the destructor function run from .fini and crtend.o defines > the constructor run from .init. It really should be the other way > around, since this arrangement results in maximmum offset branches, > from the .init section located before .text to a function at the end > of .text, and from the .fini section located after .text to a function > at the beginning of .text. Too arcane for me :). Let's hope someone else can comment on this. Thanks for your help, I'll get some results tomorrow. Laurent
[bug 19832] - would s.o. help, if I try to develop this enhancement ?
Hi all, a long time ago (in feb. 2005 !) I posted a small patch for a tiny speed-up of gcc. (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19832) According to the latest comment, gcc could be teached to detect such cases in order to optimize it away by itself. I do agree that such cases must not be common and that the corresponding speed improvement in the generated code should be really small, but anyway I was wondering if I could go up to the end of the story I started a few years ago. So, my point is : * do you think that adding such a fonctionality is easy ? (i.e. for someone involded in software development, mostly in C for several years and who has basic knowledge on gcc internals and compilers theory in general) * do you think it would be usefull ? * does someone could give me some ideas on where is the best place to do such a treatment ? * does someone would agree to mentor it ? Christophe Jaillet
gcc-4.1-20080616 is now available
Snapshot gcc-4.1-20080616 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080616/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 136849 You'll find: gcc-4.1-20080616.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20080616.tar.bz2 C front end and core compiler gcc-ada-4.1-20080616.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20080616.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20080616.tar.bz2 C++ front end and runtime gcc-java-4.1-20080616.tar.bz2 Java front end and runtime gcc-objc-4.1-20080616.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20080616.tar.bz2The GCC testsuite Diffs from 4.1-20080609 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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.
Why does loop-35.c store motion testcase fail for AVR?
Help !
gcc.dg/tree-ssa/loop-35.c is a test that looks for "Executing store motion" in
dump-tree-lim-details
As the load and store of memory location should be pulled out of loop.
This works for 3 out of 4 tescases. But on AVR target test3() will fail.
The only difference between this and test1() is that index is unsigned long
rather than int.
Index of char or int work fine.
Why
Even considering pointers and int are only HImode, I cant see why a long
(SImode) should affect this.
void test3(unsigned long b)
{
unsigned i;
/* And here. */
for (i = 0; i < 100; i++)
{
arr[b+8].X += i;
arr[b+9].X += i;
}
}
