build error from trunk sources
Hello, I am trying the build the crx-elf target gcc compiler tools from gcc trunk sources, but the below error message displayed. Could any one suggest the reason for build fail? ===Error log In file included from /trunk/gcc/sel-sched-dump.c:37: /trunk/gcc/sel-sched-ir.h:93: error: expected specifier-qualifier-list before âds_tâ /trunk/gcc/sel-sched-ir.h:137: error: expected specifier-qualifier-list before âds_tâ /trunk/gcc/sel-sched-ir.h:239: error: expected specifier-qualifier-list before âdeps_tâ /trunk/gcc/sel-sched-ir.h:280: error: expected specifier-qualifier-list before âdeps_tâ /trunk/gcc/sel-sched-ir.h:369: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âsched_lists_poolâ /trunk/gcc/sel-sched-ir.h: In function â_list_allocâ: /trunk/gcc/sel-sched-ir.h:374: warning: implicit declaration of function âpool_allocâ /trunk/gcc/sel-sched-ir.h:374: error: âsched_lists_poolâ undeclared (first use in this function) === Thanks Swami
Re: Instrument-functions: possible also for function exit via exception?
On Friday 29 August 2008 23:04:15 you wrote: > On Fri, Aug 29, 2008 at 2:36 AM, Tim München > > <[EMAIL PROTECTED]> wrote: > > is it somehow possible to also be notified if a function/method is left > > with a 'throw'? Or, would it be possible to patch gcc like that? I had a > > quick look into function.c but it seems not to be as straight-forward as > > the entry/exit instrumentation (What is probably the reason it isn't > > implemented yet). Or is it even impossible for some reason? > > In 4.0 and above -finstruction-functions actually emits the exit > function call for exceptions too, it is wrapped in a "finally" clause. > > Thanks, > Andrew Pinski Hi, sorry, I accidentially didn't reply to the list the last time; so once again: is it possible to backport this new behaviour to gcc 3.4.x ? (I am currently using gcc 3.4.6). I'd have a look in the differences between gcc 3.4 and 4.x, but maybe you know already that this is difficult/improbable/already done... Thanks, Tim
Re: build error from trunk sources
Building trunk rev. 139857 on linux/x86_64, I get the following failure: ... cc1: warnings being treated as errors /home/local/jweil/gcc44/trunk/gcc/sel-sched-ir.c:946: error: 'cmp_v_in_regset_pool' defined but not used ... Cheers, Janus 2008/9/1 M R Swami Reddy <[EMAIL PROTECTED]>: > Hello, > > I am trying the build the crx-elf target gcc compiler tools from gcc trunk > sources, but the below error message displayed. > > Could any one suggest the reason for build fail? > > ===Error log > In file included from /trunk/gcc/sel-sched-dump.c:37: > /trunk/gcc/sel-sched-ir.h:93: error: expected specifier-qualifier-list > before āds_tā > /trunk/gcc/sel-sched-ir.h:137: error: expected specifier-qualifier-list > before āds_tā > /trunk/gcc/sel-sched-ir.h:239: error: expected specifier-qualifier-list > before ādeps_tā > /trunk/gcc/sel-sched-ir.h:280: error: expected specifier-qualifier-list > before ādeps_tā > /trunk/gcc/sel-sched-ir.h:369: error: expected ā=ā, ā,ā, ā;ā, āasmā or > ā__attribute__ā before āsched_lists_poolā > /trunk/gcc/sel-sched-ir.h: In function ā_list_allocā: > /trunk/gcc/sel-sched-ir.h:374: warning: implicit declaration of function > āpool_allocā > /trunk/gcc/sel-sched-ir.h:374: error: āsched_lists_poolā undeclared (first > use in this function) > === > > Thanks > Swami
Re: Instrument-functions: possible also for function exit via exception?
Sent from my iPhone On Sep 1, 2008, at 4:22, Tim München <[EMAIL PROTECTED] wuppertal.de> wrote: On Friday 29 August 2008 23:04:15 you wrote: On Fri, Aug 29, 2008 at 2:36 AM, Tim München <[EMAIL PROTECTED]> wrote: is it somehow possible to also be notified if a function/method is left with a 'throw'? Or, would it be possible to patch gcc like that? I had a quick look into function.c but it seems not to be as straight- forward as the entry/exit instrumentation (What is probably the reason it isn't implemented yet). Or is it even impossible for some reason? In 4.0 and above -finstruction-functions actually emits the exit function call for exceptions too, it is wrapped in a "finally" clause. Thanks, Andrew Pinski Hi, sorry, I accidentially didn't reply to the list the last time; so once again: is it possible to backport this new behaviour to gcc 3.4.x ? (I am currently using gcc 3.4.6). I'd have a look in the differences between gcc 3.4 and 4.x, but maybe you know already that this is difficult/improbable/already done... This code was rewritten for tree-ssa; so it is not possible to merge it back without the whole tree-ssa code merged back. If I was you, I would move forward as 3.4 is no longer maintained. Likewise for 4.0 and 4.1. Thanks, Tim
Re: build error from trunk sources
Janus Weil wrote:
Building trunk rev. 139857 on linux/x86_64, I get the following failure:
...
cc1: warnings being treated as errors
/home/local/jweil/gcc44/trunk/gcc/sel-sched-ir.c:946: error:
'cmp_v_in_regset_pool' defined but not used
I will commit the following as obvious once bootstrap finishes. Sorry
for the breakage.
Andrey
2008-09-01 Andrey Belevantsev <[EMAIL PROTECTED]>
* sel-sched-ir.c (cmp_v_in_regset_pool): Surround with
#ifdef ENABLE_CHECKING.
Index: gcc/sel-sched-ir.c
===
*** gcc/sel-sched-ir.c (revision 139859)
--- gcc/sel-sched-ir.c (working copy)
*** return_regset_to_pool (regset rs)
*** 939,944
--- 939,945
regset_pool.v[regset_pool.n++] = rs;
}
+ #ifdef ENABLE_CHECKING
/* This is used as a qsort callback for sorting regset pool stacks.
X and XX are addresses of two regsets. They are never equal. */
static int
*** cmp_v_in_regset_pool (const void *x, con
*** 946,951
--- 947,953
{
return *((const regset *) x) - *((const regset *) xx);
}
+ #endif
/* Free the regset pool possibly checking for memory leaks. */
void
Fwd: QUERY : ARM inline code in Thumb file?
2008/8/27 Aaron P. D'Souza <[EMAIL PROTECTED]>
>
> hello:
>
> one small question regarding use of ARM inline assembly code in a
> C file that has been compiled for Thumb mode.
>
> is it possible to use ARM assembly code from within a C file that
> has been compiled for Thumb and Thumb interworking?
The easiest way would be to just write an assembler file with:
.global function_f
.arm
function_f:
mrs r0, cpsr
msr cpsr_c, r0
bx lr
... if you provide the correct cpu and interwork flags during the
assemble/link phases, this will get interworking veeners and thus will
be called correctly from both arm and thumb code.
If that's not an option, then you probably would need to do something like this:
void function_f(void)
{
register int x;
#ifdef __thumb__
register int y;
#endif
asm volatile (
#ifdef __thumb__
".align 2\n"
"bx pc\n"
"nop\n"
".arm\n"
#endif
"mrs %0, cpsr \n\t"
"msr cpsr_c, %0\n\t"
#ifdef __thumb__
"add %1, pc, #1\n"
"bx %1\n"
#endif
: "=r" (x)
#ifdef __thumb__
, "=r" (y)
#endif
);
}
objc build error
/home/dave/gnu/gcc-4.4/objdir/./prev-gcc/xgcc -B/home/dave/gnu/gcc-4.4/objdir/./prev-gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.4.0/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DOBJCPLUS -I../../gcc/gcc/objc -I../../gcc/gcc/cp -fno-common -DHAVE_CONFIG_H -I. -Iobjcp -I../../gcc/gcc -I../../gcc/gcc/objcp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I. -Iobjcp -I../../gcc/gcc -I../../gcc/gcc/objcp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc/gcc/objc/objc-act.c -o objcp/objcp-act.o ../../gcc/gcc/objc/objc-act.c: In function 'build_typed_selector_reference': ../../gcc/gcc/objc/objc-act.c:2634: error: too many arguments to function 'build _array_ref'../../gcc/gcc/objc/objc-act.c: In function 'build_selector_reference': ../../gcc/gcc/objc/objc-act.c:2653: error: too many arguments to function 'build_array_ref' ../../gcc/gcc/objc/objc-act.c:2667: error: too many arguments to function 'build_array_ref' ../../gcc/gcc/objc/objc-act.c: In function 'objc_substitute_decl': ../../gcc/gcc/objc/objc-act.c:3053: error: too many arguments to function 'build_array_ref' Testing? Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
old but current libiberty/strsignal vs. cygwin
strsignal problems on target=Cygwin have been kicking around for years.
This is a libiberty issue.
Maybe offtopic for gcc.
Or maybe the right place.
?
(and gcc vs. gcc-patches, similar, opening a bug seems too
heavyweight when an analysis/fix is (mostly) in hand..)
native cygwin (build=host=target=cygwin, or at least target=cygwin)
gcc 4.3.2 (recently released)
+ binutils 2.18
+ cygwin-snapshot-20080822-1
This is winsup and newlib.
+ gmp 4.2.3, mpfr, 2.3.1
once nice unified tree
some or all slightly patched -- to fix build problems
The error is:
# /src/gcc/libiberty/strsignal.c:408: error: conflicting types for 'strsignal'
# const char *
# strsignal (int signo)
#
# /src/gcc/newlib/libc/include/string.h:79: error: previous declaration of
'strsignal' was here
# char *_EXFUN(strsignal, (int __signo));
#
# make[1]: Leaving directory
`/obj/gcc.1/i686-pc-cygwin/i686-pc-cygwin/i686-pc-cygwin/libiberty'
It's a bit involved.
libiberty endeavors to avoid probing for strsignal, and provide its own,
for a cygwin target, in order for cygwin's strsignal to be libiberty's
strsignal.
That's what the comments say, and I believe they match the code (shown below).
That is, the probe would succeed, thereby not contributing the very
implementation needed.
However back in 2004, cygwin got its own strsignal:
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/strsig.cc?cvsroot=src
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/Makefile.in.diff?r1=1.153&r2=1.154&cvsroot=src
Current libiberty though:
http://gcc.gnu.org/svn/gcc/trunk/libiberty/configure.ac
if test -z "${setobjs}"; then
case "${host}" in
*-*-cygwin*)
# The Cygwin library actually uses a couple of files from
# libiberty when it is built. If we are building a native
# Cygwin, and we run the tests, we will appear to have these
# files. However, when we go on to build winsup, we will wind up
# with a library which does not have the files, since they should
# have come from libiberty.
# We handle this by removing the functions the winsup library
# provides from our shell variables, so that they appear to be
# missing.
# DJ - only if we're *building* cygwin, not just building *with* cygwin
if test -n "${with_target_subdir}"
then
funcs="`echo $funcs | sed -e 's/random//'`"
AC_LIBOBJ([random])
vars="`echo $vars | sed -e 's/sys_siglist//'`"
checkfuncs="`echo $checkfuncs | sed -e 's/strsignal//' -e 's/psignal//'`"
fi
;;
This appears outdated.
Try changing it to:
checkfuncs="`echo $checkfuncs | sed -e 's/psignal//'`"
That does not fix the problem however.
Though I presume it is reasonable.
That does doesn't run, I think, because of of setjobs (though my sh/test
isn't strong enough to be certain...ugh):
if test -n "${with_target_subdir}"; then
# We are being configured as a target library. AC_REPLACE_FUNCS
# may not work correctly, because the compiler may not be able to
# link executables. Note that we may still be being configured
# native.
# If we are being configured for newlib, we know which functions
# newlib provide and which ones we will be expected to provide.
if test "x${with_newlib}" = "xyes"; then
...
setobjs=yes
fi
Instead see here, same file:
case "${host}" in
*-*-cygwin* | *-*-mingw*)
AC_DEFINE(HAVE_SYS_ERRLIST)
AC_DEFINE(HAVE_SYS_NERR)
;;
esac
and change it to:
case "${host}" in
*-*-mingw*)
AC_DEFINE(HAVE_SYS_ERRLIST)
AC_DEFINE(HAVE_SYS_NERR)
;;
*-*-cygwin*)
AC_DEFINE(HAVE_SYS_ERRLIST)
AC_DEFINE(HAVE_SYS_NERR)
#
# Cygwin used to use libiberty's strsignal, but
# got its own in 2004.
#
AC_DEFINE(HAVE_STRSIGNAL)
;;
esac
I'm still testing this but it does seem to be two smoking guns.
The first one shot a blank but I doubt I'll find a third. :)
Nobody builds gcc + cygwin in an integrated tree?
I wish I could integrate more into The One Tree.
I so dislike everything being separate..
Can someone vet and apply these changes? Thanks.
In the meantime, I wrap up my build with something that applies
various patches and workarounds (attached).
Similarly, this is kind of yucky but I guess ok:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: warning: au
to-importing has been activated without --enable-auto-import specified on the co
mmand line.
This should work unless it involves constant data structures referencing symbols
from auto-imported DLLs.Info: resolving _sys_nerr by linking to __imp__sys_nerr
(auto-import)
Info: resolving _sys_errlist by linking to __imp__sys_errlist (auto-import)
This is probably libiberty/strerror.c.
Must it declare them itself? Always?
Configure it and only declare if not otherwise declared?
Might be general goodness to avoid declaring stuff one's self?
Or declare them __declspec(dllimport) on Cygwin (or whatever is the gcc equiv).
Thanks,
- Jay
#! /usr/b
