-disable-fixincludes doesn't quite work, minor
-disable-libgcc and/or -disable-fixincludes are useful, depending on your goal. Like if you just want to compile C to assembly or object files. It fails, but only after doing what I want anyway. make[2]: *** No rule to make target `../build-sparc-sun-solaris2.10/fixincludes/fixinc.sh', needed by `stmp-fixinc'. Stop. gmake[2]: Leaving directory `/home/jkrell/obj/gcc.sparc/gcc' gmake[1]: *** [all-gcc] Error 2 Definitely not a big deal. $HOME/src/gcc-4.5.0/configure -without-gnu-ld -with-ld=/usr/ccs/bin/ld -without-gnu-as -with-as=/usr/ccs/bin/as -disable-nls -disable-fixincludes -verbose -disable-libgcc -disable-bootstrap gmake (I'd still like -disable-intl; I always just delete that directory. -disable-intl /might/ work, I should try it again. I'd also like -without-libiconv, which I'm sure doesn't work. This way the resulting gcc doesn't require libiconv, which isn't on all systems. I have automation to patch out the libiconv use.) - Jay
RE: pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction
It might also be necessary to configure for i586-sun-solaris2.10 instead of
i586-solaris2.10.
Something I read said you can use various shorter forms, and I like the idea
for convenience and to avoid those "pc"s and "unknown"s,
but this seems to have bitten me a number of times, not just today.
Anyway, it is working for me, configure -without-gnu-as i586-sun-solaris2.10,
having applied Rainer's change to a 4.3 tree.
(Yes, I'd like to upgrade.)
It seems using GNU as might still be slightly preferred in order to move data
(jump tables) out of .text and into read only data, like, you know, "the less
that is executable, the more secure". Though for locality, .text might be
better.
For now I'm erring toward using what is more often present in the same location.
I should have just waited till I tested with 4.5, that would have shut me up. :)
Thanks,
- Jay
> From: jay.kr...@cornell.edu
> To: pins...@gmail.com
> CC: gcc@gcc.gnu.org
> Subject: RE: pic+64bit+sun assembler+unwind-tables => illegal cross section
> subtraction
> Date: Mon, 10 May 2010 03:17:40 +
>
>
> Fix in 4.4.0.
>
> I was getting:
>
> .LASFDE1:
> .long .LASFDE1-.Lframe1
> .long .LFB2-. <<<
> .long .LFE2-.LFB2
>
> 4.5.0 configured right:
>
> .LASFDE1:
> .long .LASFDE1-.Lframe1
> .long .l...@rel <<<
> .long .LFE0-.LFB0
>
> dw2_asm_output_encoded_addr_rtx =>
>
> #ifdef ASM_OUTPUT_DWARF_PCREL
> ASM_OUTPUT_DWARF_PCREL (asm_out_file, size, XSTR (addr, 0));
> #else
> dw2_assemble_integer (size, gen_rtx_MINUS (Pmode, addr, pc_rtx));
> #endif
>
>
> C:\src\gcc-4.4.0\gcc\config\i386\sol2-10.h(45):#define
> ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
> C:\src\gcc-4.5.0\gcc\config\i386\sol2-10.h(46):#define
> ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
>
>
> #define ASM_OUTPUT_DWARF_PCREL(FILE, SIZE, LABEL) \
> do { \
> fputs (integer_asm_op (SIZE, FALSE), FILE); \
> assemble_name (FILE, LABEL); \
> fputs (SIZE == 8 ? "@rel64" : "@rel", FILE); \
> } while (0)
> #endif
>
> 2009-01-29 Rainer Orth
> * config/i386/sol2-10.h [!HAVE_AS_IX86_DIFF_SECT_DELTA]
> (ASM_OUTPUT_DWARF_PCREL): Define.
>
> http://gcc.gnu.org/viewcvs?view=revision&revision=143758
>
>
> Thanks,
> - Jay
>
>
>
>> From: jay.kr...@cornell.edu
>> To: pins...@gmail.com
>> CC: gcc@gcc.gnu.org
>> Subject: RE: pic+64bit+sun assembler+unwind-tables => illegal cross section
>> subtraction
>> Date: Mon, 10 May 2010 01:02:29 +
>>
>>
>> Ah, good point. I don't think my "real" scenario did that though.
>> I'll investigate more. Networking problems were?are hampering download 4.5.0
>> and
>> build and configure it.
>>
>> I did come up with Makefile:
>>
>> Assemble = $(shell if test -x /opt/csw/gnu/as ; then echo /opt/csw/gnu/as ; \
>> elif test -x /usr/sfw/bin/gas ; then echo /usr/sfw/bin/gas ; \
>> else echo "unable to find GNU assembler" ; fi )
>>
>> :) which addresses why I wasn't using GNU as.
>>
>> (Yes, I've heard of autoconf.)
>>
>> Thanks, later,
>> - Jay
>>
>>
>>
>>> From: pins...@gmail.com
>>> To: jay.kr...@cornell.edu
>>> Subject: Re: pic+64bit+sun assembler+unwind-tables => illegal cross section
>>> subtraction
>>> Date: Sun, 9 May 2010 17:48:04 -0700
>>> CC: gcc@gcc.gnu.org
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On May 9, 2010, at 5:42 PM, Jay K wrote:
>>>
I haven't tried 4.5.0 yet.
-bash-4.1$ /opt/csw/gcc4/bin/g++ -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --
exec-prefix=/op
t/csw/gcc4
>>>
>>>
>>>
--with-gnu-as
>>>
>>>
>>> You configured gcc to build with the gnu as but then run with it so
>>> what do you expect.
>>>
>>>
--with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/
usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-
prefix=/opt/
csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-
awt=xlib --e
nable-libada --enable-libssp --enable-objc-gc --enable-threads=posix
--enable-st
age1-languages=c --enable-languages=ada,c,c++,fortran,java,objc
Thread model: posix
gcc version 4.3.3 (GCC)
/opt/csw/gcc4/bin/g++ 1.cpp -fPIC -S -m64
"1.s", line 117 : Warning: Illegal subtraction - symbols from
different sections: ".LFB2", ".DOT-2"
"1.s", line 120 : Warning: Illegal subtraction - symbols from
different sections: ".LLSDA2", ".DOT-3"
void F1();
void F2()
{
try { F1(); } catch(...) {F2(); }
}
/usr/ccs/bin/as -xarch=amd64 1.s
or similar:
-bash-4.1$ cat 2.c
void F1() { }
/opt/csw/gcc4/bin/gcc -fPIC -S -funwind-tables -m64 2.c
/usr/ccs/bin/as -xarch=amd64 2.s
Assembler: 2.c
"2.s", line 38 : Warning: Illegal subtraction - symbols from
different sections: ".LFB2", ".DOT-1"
I'm aware of this thr
Re: Compile times for gcc with ppl/cloog backened?
On Sun, May 9, 2010 at 3:22 AM, Richard Guenther wrote: > On Sun, May 9, 2010 at 5:09 AM, ajmcello wrote: >> I've got a quad core 3.2Ghz FreeBSD-8 system with 8GB of ram. I >> compiled and installed Cloog-PPL and PPL, mpfr, gmp, mpc, polylib, >> etc. I'm using make -j 4, and my gcc compile has been going for about >> 24 hours. Is this normal or did something go terribly wrong? It is >> still building, but each file uses about 20-30 hours of CPU time to >> build (according to top). I think this is the 3rd compile. After the >> first, I recompiled all of my tools (binutils, coreutils, etc) with >> the new gcc and then started the build over. This last one, I think >> stage1 and stage2 went by relatively quick, but the 3rd and final >> stage has been taking forever. I wrote a test program and compiled it >> with prev-gcc/xgcc with no arguments, and it took about 5 seconds. >> Just curious. >> >> Here's my runtime options. Thanks. >> >> >> ./configure --prefix=/usr/gnu \ >> --disable-werror \ >> --disable-ppl-version-check \ >> --disable-cloog-version-check \ >> --enable-cxx \ >> --enable-shared \ >> --enable-static \ >> --enable-bootstrapp \ >> --enable-lto \ >> --enable-objc-gc \ >> --enable-gold \ >> --enable-stage1-checking=all \ > > Well - that's not a very good idea ;) Just drop that piece. > > Richard. > Hahahhaa. That was it. I removed polylib and rebuilt all my sources, still was slow. Leaving off stage1 checking was the ticket. On another note, I had a problem with lto, gcc would error out with some kind of libelf read error when using -flto. I specified the path to the latest libelf install, which I put in /usr/gnu, and I also set LD_LIBRARY_PATH to include /usr/gnu/lib first, but still no go. It kept wanting to use the older version FreeBSD had in /usr/lib. So I I reinstalled libelf to /usr/lib after moving the old libelf and that fixed it. libiconv had the same problem, so I had to do the same thing that I did for the libelf problem..
RE: pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction
On Mon, 10 May 2010, Jay K wrote: It seems using GNU as might still be slightly preferred in order to move data (jump tables) out of .text and into read only data, like, you know, "the less that is executable, the more secure". Though for locality, .text might be better. Note that you can also try to ping Oracle with this pointer: http://bugs.sun.com/view_bug.do?bug_id=6832717 -- Marc Glisse
32 Bit Backend with 3 Registers
Hi,
I have a problem to compile the libgcc2 with a new gcc backend.
I have a little processor with 4 registers A X Y and R0(0) with 32 Bit.
R0(0) is the stackpointer and Y is the basepointer.
So i only have the registers A and X to calculate.
It always gave me an error that there are to less spill registers,
when trying to compile the the _mulvsi3 function of the libgcc2.
So I tried to add more registers, which are R1(0), R2(0), R3(0), R4(0)
and R5(0) with 32 Bit length.
The problem is that this registers cant calculate anything they are only
to hold values.
They can be written as example with mov R1(0), A and read with mov A, R1(0).
I implemented an new register class for this R.. registers and added the
mov instruvtion to the movsi
pattern. And now I get an error at the negdi2 function of the libgcc2,
this means it doesn't compile as
far as the first version with less registers.
Regards
Egge-B
Here is the Error massage and the .h and .md file
-4.4.1/build/./gcc/ -B/home/user/test/local/hicovec/bin/
-B/home/user/test/local/hicovec/lib/ -isystem
/home/user/test/local/hicovec/include -isystem
/home/user/test/local/hicovec/sys-include -g -O2 -O2 -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -isystem ./include -g -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../.././gcc
-I../.././../libgcc -I../.././../libgcc/. -I../.././../libgcc/../gcc
-I../.././../libgcc/../include -DHAVE_CC_TLS -o _negdi2.o -MT _negdi2.o
-MD -MP -MF _negdi2.dep -DL_negdi2 -c ../.././../libgcc/../gcc/libgcc2.c \
cc1: Warnung: Zielsystem unterstützt keine Testausgaben
cc1: Warnung: Zielsystem unterstützt keine Testausgaben
cc1: Warnung: Zielsystem unterstützt keine Testausgaben
../.././../libgcc/../gcc/libgcc2.c: In Function »__negdi2«:
../.././../libgcc/../gcc/libgcc2.c:76: intern Compiler-Error: in
refers_to_regno_for_reload_p, at reload.c:6440
//bein .md file
***
;; from avr
(define_attr "cc" "none,set_cz,set_z,compare,clobber"
(const_string "clobber")) ;clobber by default
(define_constants
[(A_REGNUM 0)
(X_REGNUM 1)
(BP_REGNUM 2)
(SP_REGNUM 3)
]
)
(define_mode_iterator SIF [SI SF])
;;(define_predicate "register_axy_or_0"
;; (ior
;; (match_operand 0 "register_operand")
;; (and (match_code "const_int")
;;(match_test "op == const0_rtx"
;defines the Register Class for Register A
(define_predicate "register_a"
(match_operand 0 "register_operand")
{
unsigned int regno;
regno = REGNO(op);
return regno == 0;
})
;;EGGE
;;defines the Register Class for ARITH_REGS (AXY)
(define_predicate "register_axy"
(match_operand 0 "register_operand")
{
unsigned int regno;
if (GET_CODE (op) == SUBREG)
op = SUBREG_REG (op);
regno = REGNO (op);
//printf("%d\t",regno);
return true;
return (regno >= FIRST_PSEUDO_REGISTER || (regno>=0 && regno<=3));
})
(define_predicate "register_axy0"
(ior(match_operand 0 "register_axy")
(and(match_code "const_int")
(match_test "op == const0_rtx"
(define_predicate "nonmemory_axyi"
(ior(match_operand 0 "register_axy")
(match_operand 0 "immediate_operand")))
;;Egge end
; ARITH Operations
(define_insn "addsi3"
[(set (match_operand:SI 0 "register_axy" "=a")
(plus:SI
(match_operand:SI 1 "register_axy0" "a0")
(match_operand:SI 2 "nonmemory_axyi" "ai")))]
""
"add %0, %1, %2; %0 = %1 + %2"
[(set_attr "cc" "set_cz")])
(define_insn "subsi3"
[(set (match_operand:SI 0 "register_axy" "=a")
(minus:SI
(match_operand:SI 1 "register_axy0" "a")
(match_operand:SI 2 "nonmemory_axyi" "ai")))
]
""
"sub %0, %1, %2; %0 = %1 - %2"
[(set_attr "cc" "set_cz")])
(define_insn "negsi2"
[(set (match_operand:SI 0 "register_axy" "=a")
(neg:SI (match_operand:SI 1 "nonmemory_axyi" "ai")))]
""
"sub %0, 0, %1; %0 = -%1"
[(set_attr "cc" "set_cz")])
(define_insn "cmpsi"
[(set (cc0)
(compare
(match_operand:SI 0 "register_axy" "a")
(match_operand:SI 1 "nonmemory_axyi" "ai")))]
""
"sub 0, %0, %1; %0 < %1?"
[(set_attr "cc" "compare")])
(define_insn "tstsi"
[(set (cc0)
(match_operand:SI 0 "register_axy" "a"))]
""
"sub 0, %0, 0; %0 != 0?"
[(set_attr "cc" "compare")])
(define_insn "*rev_tstsi"
[(set (cc0)
(compare (const_int 0)
(match_operand:SI 0 "register_axy" "a")))]
""
"sub 0, 0, %0; 0 != %0?"
[(set_attr "cc" "compare")])
(define_insn "andsi3"
[(set (match_operand:SI 0 "register_axy" "=a")
(and:SI
(match_operand:SI 1 "register_axy0" "a0")
(match_operand:SI 2 "nonmemory_axyi" "ai")))
]
""
"and %0, %1, %2; %0 = %1 & %2"
[(set_attr
alias of hidden function
On x86_64-apple-darwin10, we fail the lto testcase...
/sw/src/fink.build/gcc46-4.5.999-20100508/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.5.999-20100508/darwin_objdir/gcc/ -O0 -fwhopr -c
-o c_lto_20081222_1.o
/sw/src/fink.build/gcc46-4.5.999-20100508/gcc-4.6-20100508/gcc/testsuite/gcc.dg/lto/20081222_1.c
/sw/src/fink.build/gcc46-4.5.999-20100508/gcc-4.6-20100508/gcc/testsuite/gcc.dg/lto/20081222_1.c:14:21:
error: only weak aliases are supported in this configuration
The test case is..
cat 20081222_0.h
int x();
cat 20081222_1.c
#include "20081222_0.h"
/* Actually, call "x" "INT_X", and make it hidden. */
extern __typeof (x) x
__asm__ ("INT_x")
__attribute__ (( __visibility__ ("hidden")));
int x ()
{
return 7;
}
/* Make an externally-visible symbol "X" that's an alias for INT_x. */
extern __typeof (x) EXT_x
__asm__ ("x")
__attribute__ ((__alias__ ("INT_x")));
This compiles fine under Fedora 10 linux...
gcc -O0 -c -o c_lto_20081222_1.o 20081222_1.c
where as on x86_64-apple-darwin10 we get...
gcc -O0 -c -o c_lto_20081222_1.o 20081222_1.c
20081222_1.c:16: error: only weak aliases are supported in this configuration
Changing the last line of 20081222_1.c to "__attribute__ ((weak, __visibility__
("hidden")));"
changes the error on darwin to...
gcc -O0 -c -o c_lto_20081222_1.o 20081222_1.c
20081222_1.c:16: error: ‘EXT_x’ aliased to undefined symbol ‘INT_x’
The fact that we pass testsuite/g++.old-deja/g++.ext/attrib5.C...
// { dg-do run { xfail alpha*-dec-osf* i?86-pc-cygwin } }
// Test that attributes weak and alias coexist.
// { dg-require-weak "" }
// { dg-require-alias "" }
extern "C" {
void _f () { }
void f () __attribute__((weak, alias ("_f")));
}
int main ()
{
f ();
}
would seem to suggest that darwin has functional weak alias support.
Are there any standards in effect which would dictate that
the alias of a hidden function is valid? I find the logic of
that a bit worrisome and wonder if it is really defined behavior.
Thanks in advance for any comments.
Jack
CLI-FE merge 4.3 to 4.5
Hello, We have just merged the branch st/cli-fe (a gcc front end for CLI) from a 4.3 realse to 4.5. This merge has broken the compiler and for a simple helloworld test it fails with the error cil1: internal compiler error: in execute_one_pass, at passes.c:1525 This error is reporting that the 'cfun' variable is not set correctly. I have observed that IPA passes are being executed (even when i attempt to turn them off with the relevant -fno-ipa-* flags). Setting of both cfun and current_function_declaration remains the same now as before the merge (with the exception that we now use the updated API for set_cfun). I have three questions: 1. What is the correct behaviour for a FE in terms of setting the global variables cfun and current_function_declaration? 2. It seems that the new api for set_cfun has some side effects on optimization flags? is this correct? 3. How should DECL_FUNCTION_SPECIFIC_ OPTIMIZATION be controled, should the front end be setting these per function? (I am looking to avoid IPA passes for now) Thank you in advance, Kevin
Re: alias of hidden function
On 10/05/2010 14:30, Jack Howarth wrote: > Are there any standards in effect which would dictate that > the alias of a hidden function is valid? Visiblity doesn't apply to functions, it applies to symbols. Symbols are textual names with a linked value that exist in object files. The compiler emits assembler source that directs the assembler to output an object file containing the code for the function x, and for two symbols that both have the value of the address of x (but neither of which is actually called "x"). The visibility of one of these symbols is set to hidden; the visibility of the other is not. It is not the function that is hidden, only (one of the two) symbols pointing at that function. (Also, it's not hidden from the compiler, or indeed the static linker, but only from the runtime loader, in any case.) cheers, DaveK
Re: alias of hidden function
On Mon, May 10, 2010 at 04:17:26PM +0100, Dave Korn wrote: > On 10/05/2010 14:30, Jack Howarth wrote: > > > Are there any standards in effect which would dictate that > > the alias of a hidden function is valid? > > Visiblity doesn't apply to functions, it applies to symbols. Symbols are > textual names with a linked value that exist in object files. The compiler > emits assembler source that directs the assembler to output an object file > containing the code for the function x, and for two symbols that both have the > value of the address of x (but neither of which is actually called "x"). The > visibility of one of these symbols is set to hidden; the visibility of the > other is not. It is not the function that is hidden, only (one of the two) > symbols pointing at that function. > > (Also, it's not hidden from the compiler, or indeed the static linker, but > only from the runtime loader, in any case.) > > cheers, > DaveK Dave, The darwin linker maintainer suggested that the alias attribute might not be supported in their gcc. Their on-line documentation seems to be silent on the issue. However I do notice the following on powerpc-apple-darwin9... gcc -O0 -c -o c_lto_20081222_1.o 20081222_1.c 20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x' 20081222_1.c:16: warning: alias definitions not supported in Mach-O; ignored gcc-4.2 -O0 -c -o c_lto_20081222_1.o 20081222_1.c 20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x' So it appears that may be the case for the older gcc 4.0.1 compiler in darwin but they would have appeared to have added support in the newer Apple gcc 4.2.1 compiler. Interestingly, with the alias marked as weak, I get... gcc-4.2 -O0 -v -c -o c_lto_20081222_1.o 20081222_1.c Using built-in specs. Target: powerpc-apple-darwin9 Configured with: /var/tmp/gcc_42/gcc_42-5574~1/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0 --program-prefix= --host=powerpc-apple-darwin9 --target=powerpc-apple-darwin9 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5574) /usr/libexec/gcc/powerpc-apple-darwin9/4.2.1/cc1 -quiet -v -D__DYNAMIC__ 20081222_1.c -fPIC -quiet -dumpbase 20081222_1.c -mmacosx-version-min=10.5.8 -auxbase-strip c_lto_20081222_1.o -O0 -version -o /var/tmp//ccfwMpMN.s ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/powerpc-apple-darwin9/4.2.1/../../../../powerpc-apple-darwin9/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/powerpc-apple-darwin9/4.2.1/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. GNU C version 4.2.1 (Apple Inc. build 5574) (powerpc-apple-darwin9) compiled by GNU C version 4.2.1 (Apple Inc. build 5574). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c54eb6db87684e4d5a5bb9ad02c2b2c4 20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x' which I assume means this error message is coming from the compiler and not the linker. So it still unclear to me if this is a bug in the alias attribute support in gcc for darwin or in darwin's assembler or linker. Jack
Re: alias of hidden function
On 10/05/2010 16:19, Jack Howarth wrote: > Compiler executable checksum: c54eb6db87684e4d5a5bb9ad02c2b2c4 > 20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x' > > which I assume means this error message is coming from the compiler and not > the linker. So it still unclear to me if this is a bug in the alias attribute > support in gcc for darwin or in darwin's assembler or linker. I get the same on COFF, so it isn't the assembler or linker, and visibility is a red herring, therefore it must be a problem in the compiler's understanding of aliases; QED, I would have thought. Haven't had time to dig deeper yet. (On COFF with GAS, the compiler uses a .set directive to implement the alias.) The error comes from finish_aliases_1 in varasm.c, where it is suppressed in the case of a weakref. I don't know why. cheers, DaveK
Re: alias of hidden function
On 10/05/2010 17:16, Dave Korn wrote: > On 10/05/2010 16:19, Jack Howarth wrote: > >> Compiler executable checksum: c54eb6db87684e4d5a5bb9ad02c2b2c4 >> 20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x' > The error comes from finish_aliases_1 in varasm.c, where it is suppressed in > the case of a weakref. I don't know why. Well, I can infer that it would be because it's legitimate not to define a weak symbol. I guess the problem might be that find_decl_and_mark_needed when called on EXT_x gets confused by the combination of an asm decl as well as an alias maybe? cheers, DaveK
Re: -disable-fixincludes doesn't quite work, minor
Jay K writes: > -disable-libgcc and/or -disable-fixincludes are useful, depending on your > goal. > > Like if you just want to compile C to assembly or object files. > > > It fails, but only after doing what I want anyway. > > make[2]: *** No rule to make target > `../build-sparc-sun-solaris2.10/fixincludes/fixinc.sh', needed by > `stmp-fixinc'. Stop. > gmake[2]: Leaving directory `/home/jkrell/obj/gcc.sparc/gcc' > gmake[1]: *** [all-gcc] Error 2 Thanks for pointing these things out. However, I hope you are filing bug reports about these issues you are raising. Problems which are only reported to the mailing list will be reliably lost and forgotten. If you want them to be fixed, please open bug reports. Thanks. Ian
Re: C++0x Memory model and gcc
On 05/10/2010 12:39 AM, Ian Lance Taylor wrote: Albert Cohen writes: I agree. Or even, =c++0x or =gnu++0x On the other hand, I fail to see the differen between =single and =fast, and the explanation about "the same memory word" is not really relevant as memory models typically tell you about concurrent accesses to "different memory words". What I was thinking is that the difference between =single and =fast is that =single permits store speculation. The difference between =fast and =safe/=conformant is that =fast permits writing to a byte by loading a word, changing the byte, and storing the word; in particular, =fast permits write combining in cases where =safe does not. Memory models may not talk about memory words, but they exist nevertheless. Ian I've changed the documentation and code to --params suggestion and the following, for now. we can work out the exact wording and other options later. -fmemory-model=c++0x- Disable data races as per architectural requirements to match the standard. -fmemory-model=safe- Disable all data race introductions. (enforce all 4 internal restrictions.) -fmemory-model=single - Enable all data races introductions, as they are today. (relax all 4 internal restrictions.) Andrew
Re: profile mode output analysis (call stacks to source code mapping)
On Fri, May 7, 2010 at 7:09 AM, Karel Gardas wrote: > with recent fixes into profile mode I've succeed even using it for > MICO[1] on OpenSolaris platform. Is there any tool which > translates call stacks to humans or is there any documentation/hint > how to use generated call stack information to find out appropriate > place in the source code? Mapping code addresses to function names and line numbers is system dependent. That's one reason why line numbers are not produced by the profile mode directly. If you are using binutils, this should give you precise line number information for debug binaries. addr2line -e addr1 addr2 ... If you don't have debug information or the debug information is imprecise, you should still be able to map addresses to function names: addr2line -f -e addr1 addr2 ... Other useful addr2line options are -i (print inlined stacks) and -C (demangle C++ names). Silvius
optimizing a DSO
I am trying to speedup the load and startup time of a shared library.
After reading Ulrich Drepper's paper on "How to write shared libraries",
it seems that the easiest thing to try would be to reduce the number of
symbols that are globally visible. After carefully adding
__attribute__((visibility ("default"))) to only the symbols that should
be globally visible and using the gcc option -fvisibility=hidden to hide
all symbols by default, I managed to reduce the number of globally
visible symbols. But now, it seems that even though the number of
symbols needing relocation has decreased, the cost of searching for a
symbol in the "optimized" dso has gone up. Here is the output from
"eu-readelf -I" before and after reducing the number of globally visible
symbols. It seems that the cost of both successful and unsuccessful
lookup has gone up. I haven't yet done any profiling but I am guessing
that my runtime symbol lookup cost will go up. Is this to be expected?
BEFORE:
Histogram for bucket list length in section [ 1] '.gnu.hash' (total of
4099 buckets):
Addr: 0x0158 Offset: 0x000158 Link to section: [ 2] '.dynsym'
Symbol Bias: 652
Bitmask Size: 4096 bytes 26% bits set 2nd hash shift: 15
Length Number % of total Coverage
01123 27.4%
11470 35.9% 28.1%
2 955 23.3% 64.7%
3 3919.5% 87.1%
4 1323.2% 97.2%
5 230.6% 99.4%
6 50.1%100.0%
Average number of tests: successful lookup: 1.617107
unsuccessful lookup: 1.274945
AFTER:
Histogram for bucket list length in section [ 1] '.gnu.hash' (total of
2053 buckets):
Addr: 0x0158 Offset: 0x000158 Link to section: [ 2] '.dynsym'
Symbol Bias: 652
Bitmask Size: 4096 bytes 21% bits set 2nd hash shift: 15
Length Number % of total Coverage
0 288 14.0%
1 576 28.1% 14.7%
2 575 28.0% 44.1%
3 367 17.9% 72.2%
4 1658.0% 89.0%
5 643.1% 97.2%
6 160.8% 99.6%
7 20.1%100.0%
Average number of tests: successful lookup: 1.916007
unsuccessful lookup: 1.90794
Re: alias of hidden function
On Mon, May 10, 2010 at 05:20:22PM +0100, Dave Korn wrote: > On 10/05/2010 17:16, Dave Korn wrote: > > On 10/05/2010 16:19, Jack Howarth wrote: > > > >> Compiler executable checksum: c54eb6db87684e4d5a5bb9ad02c2b2c4 > >> 20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x' > > > The error comes from finish_aliases_1 in varasm.c, where it is suppressed > > in > > the case of a weakref. I don't know why. > > Well, I can infer that it would be because it's legitimate not to define a > weak symbol. I guess the problem might be that find_decl_and_mark_needed when > called on EXT_x gets confused by the combination of an asm decl as well as an > alias maybe? > > cheers, > DaveK Dave, When I pointed out to the darwin linker maintainer that their gcc 4.0.1 compiler produced an error message... > gcc-4.0 -O0 -c -o c_lto_20081222_1.o 20081222_1.c > 20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x' > 20081222_1.c:16: warning: alias definitions not supported in Mach-O; > ignored but that for the newer Apple gcc 4.2.1 compiler (and FSF gcc) we don't get the 'warning: alias definitions not supported in Mach-O' warning, his reply was... -- My understanding is the mach-o file format does not have a way to encode aliases. The weak alias case works sometimes, because the compiler just ignores the alias part and just makes a weak def of the function with the aliased name. --- I also found http://gcc.gnu.org/ml/gcc/2005-12/msg9.html where Geoffrey Keating indicates that Mach-O doesn't support aliases in the object file at all. Jack ps I am still trying to find the patch that removed the warning "alias definitions not upported in Mach-O" from Apple's gcc since that might have some useful comments on the current situation.
RE: -disable-fixincludes doesn't quite work, minor
Ok if I do both or the emails are just annoying? I find that bugs are often ignored just as well (but not lost/forgotten, granted. :) ) Thanks, - Jay > To: jay.kr...@cornell.edu > CC: gcc@gcc.gnu.org > Subject: Re: -disable-fixincludes doesn't quite work, minor > From: i...@google.com > Date: Mon, 10 May 2010 09:50:01 -0700 > > Jay K writes: > >> -disable-libgcc and/or -disable-fixincludes are useful, depending on your >> goal. >> >> Like if you just want to compile C to assembly or object files. >> >> >> It fails, but only after doing what I want anyway. >> >> make[2]: *** No rule to make target >> `../build-sparc-sun-solaris2.10/fixincludes/fixinc.sh', needed by >> `stmp-fixinc'. Stop. >> gmake[2]: Leaving directory `/home/jkrell/obj/gcc.sparc/gcc' >> gmake[1]: *** [all-gcc] Error 2 > > > Thanks for pointing these things out. However, I hope you are filing > bug reports about these issues you are raising. Problems which are > only reported to the mailing list will be reliably lost and forgotten. > If you want them to be fixed, please open bug reports. Thanks. > > Ian
Re: optimizing a DSO
Vivek Verma writes:
> I am trying to speedup the load and startup time of a shared
> library. After reading Ulrich Drepper's paper on "How to write shared
> libraries", it seems that the easiest thing to try would be to reduce
> the number of symbols that are globally visible. After carefully
> adding __attribute__((visibility ("default"))) to only the symbols
> that should be globally visible and using the gcc option
> -fvisibility=hidden to hide all symbols by default, I managed to
> reduce the number of globally visible symbols. But now, it seems that
> even though the number of symbols needing relocation has decreased,
> the cost of searching for a symbol in the "optimized" dso has gone
> up. Here is the output from "eu-readelf -I" before and after reducing
> the number of globally visible symbols. It seems that the cost of both
> successful and unsuccessful lookup has gone up. I haven't yet done any
> profiling but I am guessing that my runtime symbol lookup cost will go
> up. Is this to be expected?
This question is not appropriate for the mailing list gcc@gcc.gnu.org,
which is for gcc development. It would be appropriate for the mailing
list gcc-h...@gcc.gnu.org. It might be better placed on the mailing
list binut...@sourceware.org (see http://sourceware.org/binutils/ )
(assuming you are using the GNU binutils) or perhaps a glibc related
mailing list (assuming you are using glibc).
The most obvious change in your data is that the number of hash
buckets dropped from 4099 to 2053. It's entirely possible that you
were close to the boundary of when the linker decides to increase the
number of hash buckets. That issue has nothing at all to do with gcc;
it is the linker which decides the size of the dynamic hash table.
Ian
Re: -disable-fixincludes doesn't quite work, minor
Jay K writes: > Ok if I do both or the emails are just annoying? As far as I'm concerned, it's fine to do both. > I find that bugs are often ignored just as well (but not lost/forgotten, > granted. :) ) Agreed on both counts. Ian
Re: a peculiar fpload problem on an inferior processor
On Sat, May 8, 2010 at 2:52 PM, Amker.Cheng wrote: >> Ah, I forgot pro/epilogue generation, but I think that's the only other >> thing that happens after reload. That is a special case: it has to generate >> strict rtl that directly matches the insns it wants. You'll probably have to >> arrange for it to save at least one GPR early enough in the prologue sequence >> to be able to use it as a temp for your FP moves, and similar in the epilogue >> sequence. > Sorry to disturb again, concerning this problem, There is another case have to be handled. the reload pass also takes care of call saved registers by generating save/restore insns, which might generate direct fpload/fpstore instructions. (in save_call_clobbered_regs, etc.) I see no way to keep GPR for this case, except using the temporary register of the ABI, and it seems safe in this case since the temp register are only used around calling insn. Actually I am not very sure about this. Any suggestion? Thanks. -- Best Regards.
Re: ARM Neon Tests Failing on non-Neon Target
Richard Earnshaw wrote: > Speaking of which, we should probably formally deprecate the old arm-elf > derived targets in 4.6 so that we can remove them in 4.7. > Similarly, we should deprecate support for the FPA on ARM. I agree. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Is it safe to use $t0 when handling call clobbered registers (on MIPS)
Hi : I'm working on a fpu which cannot work fpload insns right, so I have to use a GPR reg as temp reg to first load mem into GPR then move GPR into fpu register. I have handled most cases but the case gcc handling call clobbered fpu registers. since it is in reload pass, I have no available GPR to use here. I'm wondering whether I could use temporary registers such as $t0...$t9 in this case. It's safe as far as I can see, since the save/restore operation is around calling insn, and there are MIPS_PROLOGUE_TEMP and MIPS_EPILOGUE_TEMP which used in the prologue/epilogue cases. but I am not very sure about it, Any suggestion? Thank you all. -- Best Regards.
Re: C++0x Memory model and gcc
Andrew MacLeod writes: > -fmemory-model=single - Enable all data races introductions, as they > are today. (relax all 4 internal restrictions.) One could still use this mode with a multi-threaded program as long as explicit synchronization is done, right? -Miles -- Road, n. A strip of land along which one may pass from where it is too tiresome to be to where it is futile to go.
Re: optimizing a DSO
On Mon, May 10, 2010 at 05:15:51PM -0700, Ian Lance Taylor wrote: > The most obvious change in your data is that the number of hash > buckets dropped from 4099 to 2053. It's entirely possible that you > were close to the boundary of when the linker decides to increase the > number of hash buckets. That issue has nothing at all to do with gcc; > it is the linker which decides the size of the dynamic hash table. And you can use -Wl,-O1 (pass -O1 to the linker) to let the linker determine optimal size of the hash table (minimum number of collisions for reasonably sized section). Note that .gnu.hash section uses a Bloom filter and stores computed hash values in the table, so for many lookups the filter will result in no comparison being done at all and for most collisions the expensive comparison of symbol names isn't done either. So, even when readelf reports higher number of collisions, have you actually meassured a slowdown in symbol lookup? Jakub
