porting problem again: ICE in add_clobbers
I am still porting gcc v4.1.2 to a new risc architecture, and this
time my problem is that when compiling with -O2 turned on, every insn
with a (use ..) side effect expression, eg.
(define_expand "sibcall"
[(parallel [(call (match_operand 0 "" "")
(match_operand 1 "" ""))
(use (match_operand 2 "" ""))
(use (match_operand 3 "" ""))])]
"TARGET_SIBCALL"
{
if (operands[3] == NULL_RTX)
operands[3] = const0_rtx;
internal_expand_sibcall (0, XEXP (operands[0], 0), operands[1]);
DONE;
})
causes the compiler to fail with an internal compiler error in add_clobbers.
I have looked at it in gdb and it fails on reaching the
gcc_unreachable() in add_clobbers, which happens because add_clobbers
is called (at combine.c:9576) with an insn_code_number that it does
not recognize.
Everything works fine when optimization is turned off. What is it that
gcc does differently when optimizing, that might cause this to happen?
Link tests after GCC_NO_EXECUTABLES
libstdc++ tries to avoid link tests when configured with newlib. But I saw this when working on bfin port gcc: checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/home/jie/blackfin-sources/build43/gcc_build-4.3' make: *** [all] Error 2 I got this when building bfin-elf-gcc with patched gcc and newlib in the same tree. I found LT_SYS_DLOPEN_SELF does link tests for shl_load after GCC_NO_EXECUTABLES. The call path is "libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT -> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF How about the patch below, which uses LT_SYS_DLOPEN_SELF only when not cross compiling. Jie * libtool.m4 (_LT_LANG_C_CONFIG): Only use LT_SYS_DLOPEN_SELF when not cross compiling. Index: libtool.m4 === --- libtool.m4 (revision 128569) +++ libtool.m4 (working copy) @@ -5117,7 +5117,9 @@ _LT_LINKER_SHLIBS($1) _LT_SYS_DYNAMIC_LINKER($1) _LT_LINKER_HARDCODE_LIBPATH($1) - LT_SYS_DLOPEN_SELF + if test "$cross_compiling" = no; then +LT_SYS_DLOPEN_SELF + fi _LT_CMD_STRIPLIB # Report which library types will actually be built
Re: Link tests after GCC_NO_EXECUTABLES
Jie Zhang wrote: libstdc++ tries to avoid link tests when configured with newlib. But I saw this when working on bfin port gcc: checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/home/jie/blackfin-sources/build43/gcc_build-4.3' make: *** [all] Error 2 I got this when building bfin-elf-gcc with patched gcc and newlib in the same tree. I found LT_SYS_DLOPEN_SELF does link tests for shl_load after GCC_NO_EXECUTABLES. The call path is "libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT -> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF I saw something similar, but managed to make it go away. I don't remember how exactly (this kind of issue seems to happen to me all the time, for different reasons each time), but I think the actual problem was that you need to ensure that gcc_no_link doesn't get set. That's a test somewhat earlier in configure. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Signed division with rounding towards -infinity (and floating point rounding)
Hello,
Apologies if this has already been covered; I've searched the archives
and not found anything.
I have some code that needs to perform signed division by a power of two
with rounding towards minus infinity, i.e. it requires an arithmetic
right shift. Now in the C specification, right shifting a signed
integer is implementation defined. gcc's behaviour is implement this as
a right shift, but it's possible that the code will be compiled on
different platforms where the implemented behaviour is different.
What I'm looking for is a way of expressing myself that will always give
the correct behaviour on all c99 implementations, but that gcc will
recognise as being equivalent to an arithmetic right shift, and hence
implement as such.
The most concise form that I've found so far is:
const int d = 8; // 16, 32 etc
x = y / d - ((y % d < 0) ? 1 : 0)
although this still produces rather longer code (see example below).
On a similar point, is there a good way get floats rounded to the
nearest integer value rather than truncated. The following give the
correct rounding behaviour (I'm only interested in +ve values),
x = (int) (f + 0.5)
although gets compiled as an addition of 0.5 followed by a truncation
(again, see example).
Please note that I'm not expecting gcc to recognise these specific
cases, I'm just wondering if logic has been built in to recognise
certain specific constructs and optimise them appropriately.
Regards,
Chris
Example follows:
# gcc -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.1.2
--enable-ssp --disable-libssp --disable-libgcj --with-slibdir=/lib
--with-system-zlib --enable-shared --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --program-suffix=-4.1
--enable-version-specific-runtime-libs --without-system-libunwind
--with-cpu=generic --host=i586-suse-linux
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)
# cat div.c
#include
int div8(int x) { return (x / 8) - ((x % 8 < 0) ? 1 : 0); }
int sft3(int x) { return x>>3; }
int trnc(double d) { return (int) d; }
int rnd(double d) { return (int) (d + 0.5); }
int main (void) {
int x = -5;
fprintf(stderr, "%d\n", div8(x));
fprintf(stderr, "%d\n", div8(x));
fprintf(stderr, "%d\n", trnc(42.6));
fprintf(stderr, "%d\n", rnd(42.6));
return 0;
}
# gcc -O3 --save-temps div.c
#cat div.s
.file "div.c"
.text
.p2align 4,,15
.globl div8
.type div8, @function
div8:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %edx
popl%ebp
movl%edx, %ecx
sarl$31, %ecx
shrl$29, %ecx
leal(%ecx,%edx), %edx
movl%edx, %eax
andl$7, %edx
subl%ecx, %edx
sarl$3, %eax
shrl$31, %edx
subl%edx, %eax
ret
.size div8, .-div8
.p2align 4,,15
.globl sft3
.type sft3, @function
sft3:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
popl%ebp
sarl$3, %eax
ret
.size sft3, .-sft3
.p2align 4,,15
.globl trnc
.type trnc, @function
trnc:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
fnstcw -2(%ebp)
fldl8(%ebp)
movzwl -2(%ebp), %eax
movb$12, %ah
movw%ax, -4(%ebp)
fldcw -4(%ebp)
fistpl -8(%ebp)
fldcw -2(%ebp)
movl-8(%ebp), %eax
leave
ret
.size trnc, .-trnc
.section.rodata.cst4,"aM",@progbits,4
.align 4
.LC1:
.long 1056964608
.text
.p2align 4,,15
.globl rnd
.type rnd, @function
rnd:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
fnstcw -2(%ebp)
flds.LC1
faddl 8(%ebp)
movzwl -2(%ebp), %eax
movb$12, %ah
movw%ax, -4(%ebp)
fldcw -4(%ebp)
fistpl -8(%ebp)
fldcw -2(%ebp)
movl-8(%ebp), %eax
leave
ret
.size rnd, .-rnd
.section.rodata.str1.1,"aMS",@progbits,1
.LC3:
.string "%d\n"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
leal4(%esp), %ecx
andl$-16, %esp
pushl -4(%ecx)
pushl %ebp
movl%esp, %ebp
pushl %ecx
subl$20, %esp
movl$-1, 8(%esp)
movl$.LC3, 4(%esp)
movlstderr, %eax
movl%eax, (%esp)
callfprintf
movl$-1, 8(%esp)
movl$.LC3, 4(%esp
Re: Link tests after GCC_NO_EXECUTABLES
Bernd Schmidt wrote: Jie Zhang wrote: libstdc++ tries to avoid link tests when configured with newlib. But I saw this when working on bfin port gcc: checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking for shl_load... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1 make[1]: Leaving directory `/home/jie/blackfin-sources/build43/gcc_build-4.3' make: *** [all] Error 2 I got this when building bfin-elf-gcc with patched gcc and newlib in the same tree. I found LT_SYS_DLOPEN_SELF does link tests for shl_load after GCC_NO_EXECUTABLES. The call path is "libstdc++-v3/configure.ac" AM_PROG_LIBTOOL -> "libtool.m4" LT_INIT -> _LT_SETUP -> _LT_LANG_C_CONFIG -> LT_SYS_DLOPEN_SELF I saw something similar, but managed to make it go away. I don't remember how exactly (this kind of issue seems to happen to me all the time, for different reasons each time), but I think the actual problem was that you need to ensure that gcc_no_link doesn't get set. That's a test somewhat earlier in configure. But by design if gcc_no_link = no, link tests should be avoided. Jie
Re: Signed division with rounding towards -infinity (and floating point rounding)
Christopher Key wrote: > I have some code that needs to perform signed division by a power of two > with rounding towards minus infinity, i.e. it requires an arithmetic > right shift. Now in the C specification, right shifting a signed > integer is implementation defined. Because C may be compiled for ints other than 2's complement. Perhaps you could use pre-processing to specialize for 2's complement for most of your targets. > On a similar point, is there a good way get floats rounded to the > nearest integer value rather than truncated. The following give the > correct rounding behaviour (I'm only interested in +ve values), > > x = (int) (f + 0.5) > I don't see how this is similar, unless you are harking back to the early days of BASIC when there were 2's complement floating point implementations. IEEE standards ruled that out over 20 years ago. Even among those 2's complement implementations which did exist, the results varied for -1. < f < -.5. If you use this only for positive f, the case for which most people would consider this wrong is where f takes odd integral values, so your code will increment the result. But you said this is OK, so where is the problem? Why not use the lrint() and related C intrinsics?
Re: Link tests after GCC_NO_EXECUTABLES
Bernd Schmidt wrote: Jie Zhang wrote: But by design if gcc_no_link = no, link tests should be avoided. ??? I would have thought gcc_no_link = yes means link tests are avoided. Oops, I meant gcc_no_link = yes. Jie
Re: Link tests after GCC_NO_EXECUTABLES
Jie Zhang wrote: But by design if gcc_no_link = no, link tests should be avoided. ??? I would have thought gcc_no_link = yes means link tests are avoided. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Re: Link tests after GCC_NO_EXECUTABLES
Jie Zhang wrote: Bernd Schmidt wrote: Jie Zhang wrote: But by design if gcc_no_link = no, link tests should be avoided. ??? I would have thought gcc_no_link = yes means link tests are avoided. Oops, I meant gcc_no_link = yes. Stupid double negatives. Okay, so then your problem is that gcc_no_link=yes. Find out why it's setting that. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Re: Link tests after GCC_NO_EXECUTABLES
On Tue, Sep 18, 2007 at 03:27:18PM +0200, Bernd Schmidt wrote: > Jie Zhang wrote: > > Bernd Schmidt wrote: > >> Jie Zhang wrote: > >>> But by design if gcc_no_link = no, link tests should be avoided. > >> > >> ??? I would have thought gcc_no_link = yes means link tests are avoided. > >> > > Oops, I meant gcc_no_link = yes. > > Stupid double negatives. Okay, so then your problem is that gcc_no_link=yes. > > Find out why it's setting that. It always does for newlib. The libtool tests are relatively recent (from some recent autotools upgrade). I believe this particular error comes from using --enable-shared on a newlib target. -- Daniel Jacobowitz CodeSourcery
Re: Link tests after GCC_NO_EXECUTABLES
Rask Ingemann Lambertsen wrote:
On Tue, Sep 18, 2007 at 07:55:45PM +0800, Jie Zhang wrote:
libstdc++ tries to avoid link tests when configured with newlib. But I
saw this when working on bfin port gcc:
From config.log:
/home/rask/build/gcc-bfin-unknown-elf/gcc/../ld/ld-new:
cannot open linker script file bf532.ld: No such file or directory
$ grep -F -e bf532.ld gcc/config/bfin/*
gcc/config/bfin/elf.h:%{!T*:%{!msim:%{mcpu=bf531:-Tbf531.ld}%{mcpu=bf532:-Tbf532.ld}
\
gcc/config/bfin/elf.h:%{!mcpu=*:-Tbf532.ld}}}"
The file bf532.ld is nowhere to be found in gcc or newlib/libgloss.
I have not pushed out our recent newlib/libgloss changes to upstream
yet. Currently you could get latest blackfin port newlib/libgloss from
http://blackfin.uclinux.org/gf/project/toolchain/scmsvn
But if it cannot find bf532.ld, it should avoid further link tests.
Jie
Re: Link tests after GCC_NO_EXECUTABLES
On Tue, Sep 18, 2007 at 07:55:45PM +0800, Jie Zhang wrote:
> libstdc++ tries to avoid link tests when configured with newlib. But I
> saw this when working on bfin port gcc:
>From config.log:
/home/rask/build/gcc-bfin-unknown-elf/gcc/../ld/ld-new:
cannot open linker script file bf532.ld: No such file or directory
$ grep -F -e bf532.ld gcc/config/bfin/*
gcc/config/bfin/elf.h:%{!T*:%{!msim:%{mcpu=bf531:-Tbf531.ld}%{mcpu=bf532:-Tbf532.ld}
\
gcc/config/bfin/elf.h:%{!mcpu=*:-Tbf532.ld}}}"
The file bf532.ld is nowhere to be found in gcc or newlib/libgloss.
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
Re: Link tests after GCC_NO_EXECUTABLES
Jie Zhang wrote: Bernd Schmidt wrote: Jie Zhang wrote: Bernd Schmidt wrote: Jie Zhang wrote: But by design if gcc_no_link = no, link tests should be avoided. ??? I would have thought gcc_no_link = yes means link tests are avoided. Oops, I meant gcc_no_link = yes. Stupid double negatives. Okay, so then your problem is that gcc_no_link=yes. Find out why it's setting that. bfin-elf-gcc -mfdpic failed to link a simple test case because code is put into L1 instruction sram and data is put into L1 data sram, but Blackfin immediate offset load instruction cannot access GOT since the gap between instruction sram and data sram is too large. Using -msim as default will pass this test case and build gcc without problem but I would like bfin-elf-gcc target hardware board by default. Any chance we could target it in such a way as to not put everything in L1 by default? I think it's stupid to have configure tests failing for such a reason. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Two quick C++ performace inquiries
Hello,
I assume that this is the correct mailing list to ask this, as opposed
to a Cpp list, since it appears to me that this is compiler-related.
1)
class foo
{
int priv;
public:
void bar();
};
Supposing i am writing the definition of foo::bar, and i want to change
the private member priv. Is "this->priv=1" equal to "priv=1", as far as
performance goes? I assume that since there is an explicit dereference
of *this, there is no performance overhead so both would be equal,
however i could not locate any documentation on this (and typing "this"
on search engines does not weild the best results...). Is this correct?
(I am asking because of a suggested policy to refer to members of
classes with "this->", in an effort to distinguish them from
non-members, something like priv_)
2)
#undef DEBUG_FLAG
void foo()
{
#ifdef DEBUG_FLAG
DoSomeStuff();
#endif
}
inline void bar()
{
#ifdef DEBUG_FLAG
DoSomeStuff();
#endif
}
int main(...)
{
foo();
bar();
}
Consider the foo function, where after the pre-compiler step, the
compiler would know that the body of a given function is empty. Is the
call to that function included in the built .o? (call/ret, possibly
push/pop, etc). I am asking because such a thing would add (usually?)
unnecessary overhead.
Also, in the inlined empty function case. This should (always?) be
expanded to a no-op (and thus eliminated) from the .o object, the way i
see it. But again, i could not find any confirmation. Is this correct?
(What i try to achieve by this is to have debugging functionality added
that completely vanishes from the executable after i compile it with
different options. I would maintain the calls to debugging functions to
the performance-critical parts, in hope that they are recognised as
empty and not add any performance penalty)
Thank you for your time,
Ioannis.
Re: Link tests after GCC_NO_EXECUTABLES
Daniel Jacobowitz wrote: On Tue, Sep 18, 2007 at 03:27:18PM +0200, Bernd Schmidt wrote: Jie Zhang wrote: Bernd Schmidt wrote: Jie Zhang wrote: But by design if gcc_no_link = no, link tests should be avoided. ??? I would have thought gcc_no_link = yes means link tests are avoided. Oops, I meant gcc_no_link = yes. Stupid double negatives. Okay, so then your problem is that gcc_no_link=yes. Find out why it's setting that. It always does for newlib. The libtool tests are relatively recent (from some recent autotools upgrade). Yes, It was added by http://sourceware.org/ml/binutils/2007-05/msg00247.html Jie
RE: Two quick C++ performace inquiries
On 18 September 2007 14:59, Ioannis Gyftos wrote: > Hello, > > I assume that this is the correct mailing list to ask this, as opposed > to a Cpp list, since it appears to me that this is compiler-related. But this isn't a mailing list for general how-to-use-the compiler questions, this is a mailing list for how to write and modify the internals of the compiler. The mailing list you're looking for is gcc-help; please ask there. cheers, DaveK -- Can't think of a witty .sigline today
Re: Link tests after GCC_NO_EXECUTABLES
Bernd Schmidt wrote: Jie Zhang wrote: Bernd Schmidt wrote: Jie Zhang wrote: But by design if gcc_no_link = no, link tests should be avoided. ??? I would have thought gcc_no_link = yes means link tests are avoided. Oops, I meant gcc_no_link = yes. Stupid double negatives. Okay, so then your problem is that gcc_no_link=yes. Find out why it's setting that. bfin-elf-gcc -mfdpic failed to link a simple test case because code is put into L1 instruction sram and data is put into L1 data sram, but Blackfin immediate offset load instruction cannot access GOT since the gap between instruction sram and data sram is too large. Using -msim as default will pass this test case and build gcc without problem but I would like bfin-elf-gcc target hardware board by default. Use -fPIC as default is not good, since -fpic is enough for any real applications. So I would like to avoid link test for shl_load when GCC_NO_EXECUTABLES. Jie
Re: porting problem again: ICE in add_clobbers
I have investigated it further, and thought I'd add it to my question.
I have tried compiling with all optimization flags turned on manually
(list included below) and that compiles just fine. That leads me to
think that what is causing the bug is some undocumented optimization,
triggered only if optimize > 0. Unfortunately, this is checked for all
over the source, and I still have no idea where to start looking, so
if anyone recognizes this, please let me know!
My original question is included below. The optimization switches I've
turned on are:
-falign-functions -falign-jumps -falign-loops -falign-labels
-freorder-blocks -fdefer-pop -fdelayed-branch
-fguess-branch-probability -fcprop-registers -floop-optimize
-fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce
-ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra
-ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time
-fmerge-constants -fthread-jumps -fcrossjumping
-foptimize-sibling-calls -fcse-follow-jumps -fcse-skip-blocks -fgcse
-fgcse-lm -fgcse-sm -fgcse-las -fexpensive-optimizations
-fstrength-reduce -frerun-cse-after-loop -frerun-loop-opt
-fcaller-saves -fpeephole2 -fschedule-insns -fschedule-insns2
-fsched-interblock -fsched-spec -fregmove -fstrict-aliasing
-fdelete-null-pointer-checks -freorder-functions -ftree-vrp -ftree-pre
-fomit-frame-pointer -fforce-mem
On 9/18/07, Tomas Svensson <[EMAIL PROTECTED]> wrote:
> I am still porting gcc v4.1.2 to a new risc architecture, and this
> time my problem is that when compiling with -O2 turned on, every insn
> with a (use ..) side effect expression, eg.
>
> (define_expand "sibcall"
> [(parallel [(call (match_operand 0 "" "")
> (match_operand 1 "" ""))
> (use (match_operand 2 "" ""))
> (use (match_operand 3 "" ""))])]
> "TARGET_SIBCALL"
> {
> if (operands[3] == NULL_RTX)
> operands[3] = const0_rtx;
>
> internal_expand_sibcall (0, XEXP (operands[0], 0), operands[1]);
> DONE;
> })
>
> causes the compiler to fail with an internal compiler error in add_clobbers.
>
> I have looked at it in gdb and it fails on reaching the
> gcc_unreachable() in add_clobbers, which happens because add_clobbers
> is called (at combine.c:9576) with an insn_code_number that it does
> not recognize.
>
> Everything works fine when optimization is turned off. What is it that
> gcc does differently when optimizing, that might cause this to happen?
>
Re: porting problem again: ICE in add_clobbers
"Tomas Svensson" <[EMAIL PROTECTED]> writes:
> I am still porting gcc v4.1.2 to a new risc architecture, and this
> time my problem is that when compiling with -O2 turned on, every insn
> with a (use ..) side effect expression, eg.
>
> (define_expand "sibcall"
> [(parallel [(call (match_operand 0 "" "")
> (match_operand 1 "" ""))
> (use (match_operand 2 "" ""))
> (use (match_operand 3 "" ""))])]
> "TARGET_SIBCALL"
> {
> if (operands[3] == NULL_RTX)
> operands[3] = const0_rtx;
>
> internal_expand_sibcall (0, XEXP (operands[0], 0), operands[1]);
> DONE;
> })
>
> causes the compiler to fail with an internal compiler error in add_clobbers.
>
> I have looked at it in gdb and it fails on reaching the
> gcc_unreachable() in add_clobbers, which happens because add_clobbers
> is called (at combine.c:9576) with an insn_code_number that it does
> not recognize.
>
> Everything works fine when optimization is turned off. What is it that
> gcc does differently when optimizing, that might cause this to happen?
Sounds like your insn is not recognized. That means that there is no
define_insn in your MD file which matches the insn you are generating.
Note that the pattern you show for the define_expand is documentation
only; because your code inclues DONE, the pattern is not actually
used. You didn't show which insn was actually generated. Most likely
there is no define_insn for that insn.
Ian
Re: Link tests after GCC_NO_EXECUTABLES
Bernd Schmidt wrote: Jie Zhang wrote: bfin-elf-gcc -mfdpic failed to link a simple test case because code is put into L1 instruction sram and data is put into L1 data sram, but Blackfin immediate offset load instruction cannot access GOT since the gap between instruction sram and data sram is too large. Using -msim as default will pass this test case and build gcc without problem but I would like bfin-elf-gcc target hardware board by default. Any chance we could target it in such a way as to not put everything in L1 by default? I think it's stupid to have configure tests failing for such a reason. But then we need add sdram initialization code into crt files, which is usually provided by applications when needed. Jie
Newbie questions about gcc / glibc
Hello, I have a bunch of command line programs and I am trying to support Windows, Linux and an older version of Solaris. I got the same version of gcc working on all 3 platforms. Now the problem is that I can't get getopt_long to work which is provided by getopt.h. I don't know much about how all of these things glue together or whether it is the compiler, c library, or the operating system which is supposed to provide some of these functions. I saw getopt.h, getopt.c, and getopt1.c in my gcc directory under libiberty. What are these for? Is getopt supposed to be part of gcc or part of glibc? Thanks, ~Eric
Re: Newbie questions about gcc / glibc
> I saw getopt.h, getopt.c, and getopt1.c in my gcc directory under > libiberty. What are these for? Those are for building gcc itself. They're not normally used by applications, unless you want to import all of libiberty into your application. Normally, glibc provides the getopt family of functions.
Re: Newbie questions about gcc / glibc
"Frederich, Eric P21322" <[EMAIL PROTECTED]> writes: > I have a bunch of command line programs and I am trying to support > Windows, Linux and an older version of Solaris. > I got the same version of gcc working on all 3 platforms. > > Now the problem is that I can't get getopt_long to work which is > provided by getopt.h. > I don't know much about how all of these things glue together or whether > it is the compiler, c library, or the operating system which is supposed > to provide some of these functions. > > I saw getopt.h, getopt.c, and getopt1.c in my gcc directory under > libiberty. > What are these for? Is getopt supposed to be part of gcc or part of > glibc? This is the wrong mailing list. This mailing list is for people develping gcc itself. For questions about using gcc, please use [EMAIL PROTECTED] Please send any followup questions to gcc-help or to some other appropriate mailing list. Thanks. getopt is part of the C library. gcc does not provide a C library. gcc includes copies of getopt_long for internal use. That code is used by gcc itself, not by programs which use gcc. You can find copies of getopt_long for your program in the gnulib package on savannah.gnu.org. Please note the licensing requirements shown there. Ian
Re: Link tests after GCC_NO_EXECUTABLES
On Tue, Sep 18, 2007 at 10:19:37PM +0800, Jie Zhang wrote: > Rask Ingemann Lambertsen wrote: > >The file bf532.ld is nowhere to be found in gcc or newlib/libgloss. > > > I have not pushed out our recent newlib/libgloss changes to upstream > yet. Currently you could get latest blackfin port newlib/libgloss from > > http://blackfin.uclinux.org/gf/project/toolchain/scmsvn Thanks. With that, I instead get: /home/rask/build/gcc-bfin-unknown-elf/gcc/../ld/ld-new: crt532.o: No such file: No such file or directory -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
Re: Signed division with rounding towards -infinity (and floating point rounding)
Tim Prince wrote: > Christopher Key wrote: > > >> I have some code that needs to perform signed division by a power of two >> with rounding towards minus infinity, i.e. it requires an arithmetic >> right shift. Now in the C specification, right shifting a signed >> integer is implementation defined. >> > Because C may be compiled for ints other than 2's complement. Perhaps > you could use pre-processing to specialize for 2's complement for most > of your targets. > Indeed so. It's presumably quite simple to implement a preprocessor macro to detect whether the target system is 2's complement or not. Does this guarantee however that a right shift on a signed value will be implemented as a arithmetic shift? > >> On a similar point, is there a good way get floats rounded to the >> nearest integer value rather than truncated. The following give the >> correct rounding behaviour (I'm only interested in +ve values), >> >> x = (int) (f + 0.5) >> >> > I don't see how this is similar, unless you are harking back to the > early days of BASIC when there were 2's complement floating point > implementations. IEEE standards ruled that out over 20 years ago. Even > among those 2's complement implementations which did exist, the results > varied for -1. < f < -.5. If you use this only for positive f, the case > for which most people would consider this wrong is where f takes odd > integral values, so your code will increment the result. But you said > this is OK, so where is the problem? > > Why not use the lrint() and related C intrinsics? > Sorry, perhaps didn't make myself clear. In both case, I want behaviour that can expressed very tersely in assembler, but not equivalently so in c. What I was wanting to write is code that will do as intended under any c(99) implementation, but that gcc can see as being equivalent to its terse assembler implementation. The first case is slightly different in that I can express what I want (i.e. y = x>>d) and have it compile to suitable assembler, but the code isn't guaranteed to behave as desired on an arbitrary compiler. using rint() is an alternative, although I was put off for one reason. As this is library code, I don't want to change the global execution state (is this the correct term) without restoring it afterwards, and I didn't really want to add fegetround() and fesetround() wrappers around various bits of code. Regards, Chris
Re: porting problem again: ICE in add_clobbers
Tomas Svensson wrote: I have tried compiling with all optimization flags turned on manually (list included below) and that compiles just fine. That leads me to think that what is causing the bug is some undocumented optimization, triggered only if optimize > 0. There is no optimization at all without -O, no matter how many -f options you use. What you want to do is -O -fno-foo -fno-bar etc. However, we do not have -f options for every optimization, so there is no guarantee that this will identify the optimization pass that exposes the bug in your port. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Link tests after GCC_NO_EXECUTABLES
On Tue, Sep 18, 2007 at 06:09:18PM +0200, Rask Ingemann Lambertsen wrote: > On Tue, Sep 18, 2007 at 10:19:37PM +0800, Jie Zhang wrote: > > Rask Ingemann Lambertsen wrote: > > >The file bf532.ld is nowhere to be found in gcc or newlib/libgloss. > > > > > I have not pushed out our recent newlib/libgloss changes to upstream > > yet. Currently you could get latest blackfin port newlib/libgloss from > > > > http://blackfin.uclinux.org/gf/project/toolchain/scmsvn > >Thanks. With that, I instead get: > > /home/rask/build/gcc-bfin-unknown-elf/gcc/../ld/ld-new: > crt532.o: No such file: No such file or directory I sorted that out by using your config/bfin/elf.h, but there's something weird. The first time configure runs, it will complain about GCC_NO_EXECUTABLES but there's no (obvious) clue as to why in config.log. If I run make again, it begins to build libstdc++ but fails with this: Making all in libsupc++ make[4]: Entering directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/libsupc++' /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /home/rask/build/gcc-bfin-unknown-elf/./gcc/xgcc -shared-libgcc -B/home/rask/build/gcc-bfin-unknown-elf/./gcc -nostdinc++ -L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/src -L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/src/.libs -nostdinc -B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/ -isystem /home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/targ-include -isystem /n/12/rask/src/all/newlib/libc/include -B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libgloss/bfin -L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libgloss/libnosys -L/n/12/rask/src/all/libgloss/bfin -B/usr/local/bfin-unknown-elf/bin/ -B/usr/local/bfin-unknown-elf/lib/ -isystem /usr/local/bfin-unknown-elf/include -isystem /usr/local/bfin-unknown-elf/sys-include -L/home/rask/build/gcc-bfin-unknown-elf/./ld -I/n/12/rask/src/all/libstdc++-v3/../gcc -I/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/include/bfin-unknown-elf -I/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/include -I/n/12/rask/src/all/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2-c -o array_type_info.lo /n/12/rask/src/all/libstdc++-v3/libsupc++/array_type_info.cc /bin/sh: ../libtool: No such file or directory make[4]: *** [array_type_info.lo] Error 127 make[4]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/libsupc++' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf' make: *** [all] Error 2 I don't know why this happens to bfin and not to the other newlib targets. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
Re: bootstrap failure on ppc64-linux: ICE in set_variable_part
Kenneth Zadeck <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> I think this is a latent bug in var-tracking.c. It's getting confused
>> by the negative offsets in:
>>
>> (insn:HI 17 47 19 4 /tmp/foo.c:11 (set (reg:DI 26 26 [orig:124 tmp+-7 ]
>> [124])
>> (lshiftrt:DI (reg:DI 31 31 [orig:141 value ] [141])
>> (const_int 56 [0x38]))) 292 {*lshrdi3_internal1} (nil))
>>
>> (insn:HI 19 17 21 4 /tmp/foo.c:11 (set (reg:DI 27 27 [orig:125 tmp+-6 ]
>> [125])
>> (lshiftrt:DI (reg:DI 31 31 [orig:141 value ] [141])
>> (const_int 48 [0x30]))) 292 {*lshrdi3_internal1} (nil))
>>
>> where the registers have come from paradoxical subregs of QImode registers.
>> (DSE itself didn't create those; combine did. DSE just created DImode
>> shift instructions.)
>>
>> FWIW, the part of the patch that exposed the bug as the change from
>> "access_bytes < UNITS_PER_WORD" to "access_bytes <= UNITS_PER_WORD".
>> Your testcase passes if we change that back.
>>
> i would prefer that the above change be reverted and the rest of the
> patch left in.
OK, thanks. It's almost 24hrs since the regression was reported,
and Janis says that no-one's found a fix yet, so I've installed the
mini-reversion below as preapproved.
Richard
gcc/
* dse.c (find_shift_sequence): Temporarily revert to forbidding
word shifts.
Index: gcc/dse.c
===
--- gcc/dse.c (revision 128585)
+++ gcc/dse.c (working copy)
@@ -1407,7 +1407,7 @@ find_shift_sequence (rtx read_reg,
justify the value we want to read but is available in one insn on
the machine. */
- for (; access_size <= UNITS_PER_WORD; access_size *= 2)
+ for (; access_size < UNITS_PER_WORD; access_size *= 2)
{
rtx target, new_reg;
enum machine_mode new_mode;
MIPS atomic memory operations (A.K.A PR 33479).
Richard, There seems to be a small problem with the MIPS atomic memory operations patch I recently committed (http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01290.html), in that on a dual CPU machine it does not quite work. You can look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33479#c3 for more information. Here is the code in question (from mips.h): #define MIPS_COMPARE_AND_SWAP(SUFFIX, OP) \ "%(%<%[sync\n" \ "1:\tll" SUFFIX "\t%0,%1\n" \ "\tbne\t%0,%2,2f\n" \ "\t" OP "\t%@,%3\n" \ "\tsc" SUFFIX "\t%@,%1\n" \ "\tbeq\t%@,%.,1b\n" \ "\tnop\n" \ "2:%]%>%)" I guess my basic question is: Should MIPS_COMPARE_AND_SWAP have a 'sync' after the 'sc'? I would have thought that 'sc' made the write visible to all CPUs, but on the SB1 it appears not to be the case. If we do need to add another 'sync' should it go in the delay slot of the branch? I would say yes because we would expect the branch to rarely taken. Any feedback from linux-mips people is also solicited. Thanks, David Daney
Re: MIPS atomic memory operations (A.K.A PR 33479).
On Tue, Sep 18, 2007 at 05:12:48PM -0700, David Daney wrote: > I guess my basic question is: Should MIPS_COMPARE_AND_SWAP have a 'sync' > after > the 'sc'? I would have thought that 'sc' made the write visible to all CPUs, > but on the SB1 it appears not to be the case. Yes, a barrier of some sort is definitely necessary. I believe the SB1 is weakly ordered, and the architecture spec permits both strong and weak ordering; but it's been a while since I tried this. -- Daniel Jacobowitz CodeSourcery
Re: Link tests after GCC_NO_EXECUTABLES
Rask Ingemann Lambertsen wrote: /home/rask/build/gcc-bfin-unknown-elf/gcc/../ld/ld-new: crt532.o: No such file: No such file or directory I sorted that out by using your config/bfin/elf.h, but there's something weird. The first time configure runs, it will complain about GCC_NO_EXECUTABLES but there's no (obvious) clue as to why in config.log. If I run make again, it begins to build libstdc++ but fails with this: Making all in libsupc++ make[4]: Entering directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/libsupc++' /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /home/rask/build/gcc-bfin-unknown-elf/./gcc/xgcc -shared-libgcc -B/home/rask/build/gcc-bfin-unknown-elf/./gcc -nostdinc++ -L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/src -L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/src/.libs -nostdinc -B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/ -isystem /home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/newlib/targ-include -isystem /n/12/rask/src/all/newlib/libc/include -B/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libgloss/bfin -L/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libgloss/libnosys -L/n/12/rask/src/all/libgloss/bfin -B/usr/local/bfin-unknown-elf/bin/ -B/usr/local/bfin-unknown-elf/lib/ -isystem /usr/local/bfin-unknown-elf/include -isystem /usr/local/bfin-unknown-elf/sys-include -L/home/rask/build/gcc-bfin-unknown-elf/./ld -I/n/12/rask/src/all/libstdc++-v3/../gcc -I/home/r ask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/include/bfin-unknown-elf -I/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/include -I/n/12/rask/src/all/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2-c -o array_type_info.lo /n/12/rask/src/all/libstdc++-v3/libsupc++/array_type_info.cc /bin/sh: ../libtool: No such file or directory make[4]: *** [array_type_info.lo] Error 127 make[4]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3/libsupc++' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf/bfin-unknown-elf/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/home/rask/build/gcc-bfin-unknown-elf' make: *** [all] Error 2 I don't know why this happens to bfin and not to the other newlib targets. I guess it might be caused by different multilib settings in our local (not FSF) newlib and FSF gcc. I have committed a patch in FSF gcc which makes FSF gcc use the same multilib setting as our local gcc. Sorry about that. Please try again. Jie
RE: Two quick C++ performace inquiries
Apologies for using the wrong mailing list. Thanks for your time! Ioannis
