RFC: Updating boehm-gc to verion 7.2 (alpha 5)
Hello, I would like to update boehm-gc in gcc's tree to more recent version (7.2 - alpha 5). It has shown now that we wait for x64 windows support of boehm-gc more then one year. This blocks the waiting patches for libjava support for this target and some other features depending on boehm-gc. Additional I saw that recently more and more not upstream pushed patches getting applied to boehm-gc, which of course makes an update even more worse. So, I would like to know how boehm-gc shall be handled on gcc's tree. Is the gcc tree version a fork for itself and shall be maintained seperately? Or, shall the patches of boehm-gc done locally to gcc's tree sent upstream? Additionally, I would like to know if the boehm-gc version 7.2 (alpha 5) would be acceptable for gcc's tree? I spoke with Ivan Maidanski (the current version of latest snapshot of BDWGC - nowadays maintained tree for it is to be found on sourceforge) and he would be accepting patches for boehm-gc, so that gcc's version and upstream BGC getting again in synch. Regards, Kai
Re: RFC: Updating boehm-gc to verion 7.2 (alpha 5)
On 04/01/2011 10:05 AM, Kai Tietz wrote: > I would like to update boehm-gc in gcc's tree to more recent version > (7.2 - alpha 5). It has shown now that we wait for x64 windows > support of boehm-gc more then one year. This blocks the waiting > patches for libjava support for this target and some other features > depending on boehm-gc. Additional I saw that recently more and more > not upstream pushed patches getting applied to boehm-gc, which of > course makes an update even more worse. So, I would like to know how > boehm-gc shall be handled on gcc's tree. Is the gcc tree version a > fork for itself and shall be maintained seperately? Or, shall the > patches of boehm-gc done locally to gcc's tree sent upstream? Please send everything upstream. Once that's done we can copy the upstream branch directly into gcc. There may be problems with the testsuite, but we can deal with them as they arise. Andrew.
Assertion failure during IRA (df_scan.c)
With the changed IRA there occurs assertion failure of some inline
asm, find precompiled source attached. Seem as if something goes wrong
with FP elimination. The precompiled source is from avr-libc and
compiled fine with older versions/revisions.
avr-gcc 4.7.0 as of SVN 171824, configured
../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.6 --enable-languages=c,c++
--disable-libssp --disable-libada --disable-nls --disable-shared
(gdb) set args -quiet -v -iprefix
/local/gnu/build/gcc-4.6-avr/gcc/../lib/gcc/avr/4.7.0/ -isystem
/mnt/nfs/home/georg/gnu/build/gcc-4.6-avr/gcc/include -isystem
/mnt/nfs/home/georg/gnu/build/gcc-4.6-avr/gcc/include-fixed strtod-i.c
-quiet -dumpbase strtod-i.c -auxbase strtod-i -Os -version -o strtod-i.s
(gdb) cd ~/test
(gdb) r
GNU C (GCC) version 4.7.0 20110401 (experimental) (avr)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2
[...]
End of search list.
GNU C (GCC) version 4.7.0 20110401 (experimental) (avr)
compiled by GNU C version 4.3.2 [gcc-4_3-branch revision 141291], GMP
version 5.0.1, MPFR version 3.0.0-p8, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: fb8553d013d52c3a76f93f359d3bc754
strtod-i.c: In function 'strtod':
strtod-i.c:834:106: error: can't find a register in class
'POINTER_REGS' while reloading 'asm'
strtod-i.c:834:106: error: 'asm' operand has impossible constraints
strtod-i.c:482:5: error: 'asm' operand has impossible constraints
Breakpoint 1, fancy_abort (file=0x87d7b80
"../../../gcc.gnu.org/trunk/gcc/df-scan.c", line=2841,
function=0x87d826f "df_ref_record") at
../../../gcc.gnu.org/trunk/gcc/diagnostic.c:893
(gdb) bt
#0 fancy_abort (file=0x87d7b80
"../../../gcc.gnu.org/trunk/gcc/df-scan.c", line=2841,
function=0x87d826f "df_ref_record") at
../../../gcc.gnu.org/trunk/gcc/diagnostic.c:893
#1 0x081e275b in df_ref_record (cl=DF_REF_REGULAR,
collection_rec=0xbfffe46c, reg=0xb7c67ae0, loc=0xb7e57c44,
bb=0xb7ddfc80, insn_info=0x890aacc, ref_type=DF_REF_REG_DEF,
ref_flags=32800) at ../../../gcc.gnu.org/trunk/gcc/df-scan.c:2841
#2 0x081e2f77 in df_uses_record (collection_rec=0xbfffe46c,
loc=, ref_type=DF_REF_REG_MEM_LOAD,
bb=0xb7ddfc80, insn_info=0x890aacc, flags=0) at
../../../gcc.gnu.org/trunk/gcc/df-scan.c:3243
#3 0x081e2e20 in df_uses_record (collection_rec=0xbfffe46c,
loc=, ref_type=DF_REF_REG_USE, bb=0xb7ddfc80,
insn_info=0x890aacc, flags=) at
../../../gcc.gnu.org/trunk/gcc/df-scan.c:3124
#4 0x081e3a86 in df_insn_refs_collect (collection_rec=0xbfffe46c,
bb=0xb7ddfc80, insn_info=0x890aacc) at
../../../gcc.gnu.org/trunk/gcc/df-scan.c:3451
#5 0x081e6a4a in df_bb_refs_record (bb_index=33, scan_insns=1 '\001')
at ../../../gcc.gnu.org/trunk/gcc/df-scan.c:3585
#6 0x081e6c63 in df_scan_blocks () at
../../../gcc.gnu.org/trunk/gcc/df-scan.c:680
#7 0x08331deb in rest_of_handle_ira () at
../../../gcc.gnu.org/trunk/gcc/ira.c:3746
#8 0x08397014 in execute_one_pass (pass=0x887bde0) at
../../../gcc.gnu.org/trunk/gcc/passes.c:1555
#9 0x0839730d in execute_pass_list (pass=0x887bde0) at
../../../gcc.gnu.org/trunk/gcc/passes.c:1610
#10 0x08397320 in execute_pass_list (pass=0x887c0e0) at
../../../gcc.gnu.org/trunk/gcc/passes.c:1611
#11 0x08478bca in tree_rest_of_compilation (fndecl=0xb7e06000) at
../../../gcc.gnu.org/trunk/gcc/tree-optimize.c:422
#12 0x08618ef6 in cgraph_expand_function (node=0xb7dfd264) at
../../../gcc.gnu.org/trunk/gcc/cgraphunit.c:1575
#13 0x0861bf89 in cgraph_optimize () at
../../../gcc.gnu.org/trunk/gcc/cgraphunit.c:1634
#14 0x0861c48d in cgraph_finalize_compilation_unit () at
../../../gcc.gnu.org/trunk/gcc/cgraphunit.c:1095
#15 0x080b6720 in c_write_global_declarations () at
../../../gcc.gnu.org/trunk/gcc/c-decl.c:9879
#16 0x08414eee in toplev_main (argc=19, argv=0xbfffe854) at
../../../gcc.gnu.org/trunk/gcc/toplev.c:591
#17 0x08152572 in main (argc=-1209708932, argv=0x0) at
../../../gcc.gnu.org/trunk/gcc/main.c:36
(gdb) frame 1
#1 0x081e275b in df_ref_record (cl=DF_REF_REGULAR,
collection_rec=0xbfffe46c, reg=0xb7c67ae0, loc=0xb7e57c44,
bb=0xb7ddfc80, insn_info=0x890aacc, ref_type=DF_REF_REG_DEF,
ref_flags=32800) at ../../../gcc.gnu.org/trunk/gcc/df-scan.c:2841
(gdb) p reg
$1 = (rtx) 0xb7c67ae0
(gdb) pr
(mem/c:HI (plus:HI (reg/f:HI 32 __SP_L__)
(const_int 1 [0x1])) [8 %sfp+1 S2 A8])
(gdb) p *current_pass
$2 = {type = RTL_PASS, name = 0x87ee735 "ira", gate = 0x832d2f0
, execute = 0x83318a0 , sub = 0x0, next
= 0x887c120, static_pass_number = 194, tv_id = TV_NONE,
properties_required = 0, properties_provided = 0, properties_destroyed
= 0, todo_flags_start = 524288, todo_flags_finish = 3}
(gdb)
However, df_scan.c reads
static void
df_ref_record (enum df_ref_class cl,
struct df_collection_rec *collection_rec,
Re: RFC: Updating boehm-gc to verion 7.2 (alpha 5)
2011/4/1 Andrew Haley :
> On 04/01/2011 10:05 AM, Kai Tietz wrote:
>
>> I would like to update boehm-gc in gcc's tree to more recent version
>> (7.2 - alpha 5). It has shown now that we wait for x64 windows
>> support of boehm-gc more then one year. This blocks the waiting
>> patches for libjava support for this target and some other features
>> depending on boehm-gc. Additional I saw that recently more and more
>> not upstream pushed patches getting applied to boehm-gc, which of
>> course makes an update even more worse. So, I would like to know how
>> boehm-gc shall be handled on gcc's tree. Is the gcc tree version a
>> fork for itself and shall be maintained seperately? Or, shall the
>> patches of boehm-gc done locally to gcc's tree sent upstream?
>
> Please send everything upstream. Once that's done we can copy
> the upstream branch directly into gcc.
>
> There may be problems with the testsuite, but we can deal with
> them as they arise.
>
> Andrew.
>
Ok, I've posted the diffs to Ivan. I separated them into two pieces.
One all before testsuite patch (was last recent one) and the other
changes. Due the fact that a lot of files in boehm-gc have changed
places, I think it is better that Ivan does the diff here manually, as
it is sometime hard to find where file has gone, or if it is still
present.
Regards,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: RFC: Updating boehm-gc to verion 7.2 (alpha 5)
Kai, > Ok, I've posted the diffs to Ivan. I separated them into two pieces. > One all before testsuite patch (was last recent one) and the other > changes. Due the fact that a lot of files in boehm-gc have changed > places, I think it is better that Ivan does the diff here manually, as > it is sometime hard to find where file has gone, or if it is still > present. there's also the question if the testsuite is appropriate for upstream at all. It refers to files from gcc/testsuite/lib right now, which are obviously not present in vanillay DejaGnu, so it may be better to keep that GCC-private. Perhaps it would be good to call for some sort of boehm-gc 7.2 testing before the upgrade since boehm-gc has always been quite sensitive and version 7 hasn't seen as much exposure to different platforms as version 6 has. Otherwise, I expect large amounts of fallout from such an upgrade. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: How can I increase the default alignment of complex float?
On Thu, 31 Mar 2011, H.J. Lu wrote: > Hi, > > I'd like to bump the default alignment of complex float from 4 byte > to 8 byte. ADJUST_ALIGNMENT doesn't work since SC is a stand > mode. Is that OK to update mode_base_align directly? What do you mean by "default alignment"? You can't change the alignment in ABI terms, or that returned by alignof; the alignment of complex types is required to be the same as that of "an array type containing exactly two elements of the corresponding real type". -- Joseph S. Myers jos...@codesourcery.com
Re: How can I increase the default alignment of complex float?
On Fri, Apr 1, 2011 at 4:49 AM, Joseph S. Myers wrote: > On Thu, 31 Mar 2011, H.J. Lu wrote: > >> Hi, >> >> I'd like to bump the default alignment of complex float from 4 byte >> to 8 byte. ADJUST_ALIGNMENT doesn't work since SC is a stand >> mode. Is that OK to update mode_base_align directly? > > What do you mean by "default alignment"? You can't change the alignment > in ABI terms, or that returned by alignof; the alignment of complex types > is required to be the same as that of "an array type containing exactly > two elements of the corresponding real type". > My ABI uses 8byte alignment for SCmode. How can I do that? -- H.J.
Re: How can I increase the default alignment of complex float?
On Fri, 1 Apr 2011, H.J. Lu wrote: > On Fri, Apr 1, 2011 at 4:49 AM, Joseph S. Myers > wrote: > > On Thu, 31 Mar 2011, H.J. Lu wrote: > > > >> Hi, > >> > >> I'd like to bump the default alignment of complex float from 4 byte > >> to 8 byte. ADJUST_ALIGNMENT doesn't work since SC is a stand > >> mode. Is that OK to update mode_base_align directly? > > > > What do you mean by "default alignment"? You can't change the alignment > > in ABI terms, or that returned by alignof; the alignment of complex types > > is required to be the same as that of "an array type containing exactly > > two elements of the corresponding real type". > > > > My ABI uses 8byte alignment for SCmode. How can I do that? That is not a valid ABI for ISO C, supposing that SCmode is _Complex float, unless float also uses 8-byte alignment (and the representation of _Complex float must be the same as that of float[2], as well as the alignment, meaning that it would be at least 16 bytes in that case). You can do what you like in registers, or choose to align variables for optimization to more than the ABI-specified alignment, but you need to keep the in-memory representation and alignment of _Complex float the same as that of float[2]. -- Joseph S. Myers jos...@codesourcery.com
Re: How can I increase the default alignment of complex float?
On Fri, Apr 1, 2011 at 5:14 AM, Joseph S. Myers wrote: > On Fri, 1 Apr 2011, H.J. Lu wrote: > >> On Fri, Apr 1, 2011 at 4:49 AM, Joseph S. Myers >> wrote: >> > On Thu, 31 Mar 2011, H.J. Lu wrote: >> > >> >> Hi, >> >> >> >> I'd like to bump the default alignment of complex float from 4 byte >> >> to 8 byte. ADJUST_ALIGNMENT doesn't work since SC is a stand >> >> mode. Is that OK to update mode_base_align directly? >> > >> > What do you mean by "default alignment"? You can't change the alignment >> > in ABI terms, or that returned by alignof; the alignment of complex types >> > is required to be the same as that of "an array type containing exactly >> > two elements of the corresponding real type". >> > >> >> My ABI uses 8byte alignment for SCmode. How can I do that? > > That is not a valid ABI for ISO C, supposing that SCmode is _Complex > float, unless float also uses 8-byte alignment (and the representation of > _Complex float must be the same as that of float[2], as well as the > alignment, meaning that it would be at least 16 bytes in that case). > > You can do what you like in registers, or choose to align variables for > optimization to more than the ABI-specified alignment, but you need to > keep the in-memory representation and alignment of _Complex float the same > as that of float[2]. flloat is still 4 byte aligned. What kinds of bad things will happen if SC is 8 byte aligned and float is 4 byte aligned? -- H.J.
Relational Association Programming Paradigm (URLs)
Online reading http://rapp.sourceforge.net/RAP.PDF http://rapp.sourceforge.net/RAP-C.PDF C example with source http://sourceforge.net/projects/rapp/files/RAP-C/RAP-C.ZIP/download Happy coding, Aaron
realmpfr.h not in PLUGIN_HEADERS?
Helo All,
It seems that, since realmpfr.h is not listed in the PLUGIN_HEADERS in
gcc/Makefile.in, it cannot be used from plugins.
Is there a reason for that, or what? I feel that plugins need to know about
and about the real_from_mpfr & mpfr_from_real functions.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
gcc-4.6-20110401 is now available
Snapshot gcc-4.6-20110401 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110401/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 171857 You'll find: gcc-4.6-20110401.tar.bz2 Complete GCC (includes all of below) MD5=eaaa7ae7bb36556684d0c2fdc26b3146 SHA1=a848062ae9609f7aa12cb6f60af2edb4e8b999f4 gcc-core-4.6-20110401.tar.bz2C front end and core compiler MD5=e172df6f6dae0f74562dbc6ef46a110f SHA1=1ab629951ad3aaa917f2cb1f99a9fe4f2bf9bc33 gcc-ada-4.6-20110401.tar.bz2 Ada front end and runtime MD5=f28b3babfaf069e32456ac7686f880e8 SHA1=f696f0c3c2899bf3a294a3b1ba5a8ea22651eabe gcc-fortran-4.6-20110401.tar.bz2 Fortran front end and runtime MD5=98131246fcf99b8f6db6b679fdee5716 SHA1=9bdc2ca9c01190c2bb4aa157bbf5025e503c8197 gcc-g++-4.6-20110401.tar.bz2 C++ front end and runtime MD5=abc2c018190b9772969311ae384bbb7a SHA1=69f3f8c9d4fc3a793efef439223395b6415a1088 gcc-go-4.6-20110401.tar.bz2 Go front end and runtime MD5=2889c16045728b2d85db504310116ec0 SHA1=96f20434ee77fa5cfccddd6894f9ce0aca192b65 gcc-java-4.6-20110401.tar.bz2Java front end and runtime MD5=b1ba0e8168b5660662a87e90a75a0029 SHA1=20811fddc6465e2046324893ae17542fc1563a97 gcc-objc-4.6-20110401.tar.bz2Objective-C front end and runtime MD5=bb3057f5cd9f613774adba2e5aff75b8 SHA1=1802b0ea91dc3e9a8658e85cf480e799a7e7e382 gcc-testsuite-4.6-20110401.tar.bz2 The GCC testsuite MD5=60b53ff2347d51c0072c66bad7e15425 SHA1=9767085ffd3439587cb35b786d985d7798d8cb6c Diffs from 4.6-20110325 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
i386: load-operate-store-test
Hello All,
I compiled a very simple code on a Intel targets:
int a, b, c, d;
void func1(void)
{
a = a & b;
if(a)
c = d;
}
The assembler generated was (on cygwin 32-bit):
movl_b, %eax
andl_a, %eax
testl %eax, %eax
movl%eax, _a
je L1
movl_d, %eax
movl%eax, _c
L1:
...
The result is similar for 64-bit code.
I understand we could optimize this to (hope not missing anything):
movl_b, %eax
andl%eax, _a
je L1
movl_d, %eax
movl%eax, _c
L1:
...
I took a look at the insns just before "combine" pass and we have:
(insn 5 2 6 2 (set (reg:SI 63 [ a ])
(mem/c/i:SI (symbol_ref:SI ("a") [flags 0x2] 0x7ff6e760 a>) [2 a+0 S4 A32])) test.c:6 50 {*movsi_internal}
(nil))
(insn 6 5 7 2 (set (reg:SI 64 [ b ])
(mem/c/i:SI (symbol_ref:SI ("b") [flags 0x2] 0x7ff6e7c0 b>) [2 b+0 S4 A32])) test.c:6 50 {*movsi_internal}
(nil))
(insn 7 6 8 2 (parallel [
(set (reg:SI 61 [ a.2 ])
(and:SI (reg:SI 64 [ b ])
(reg:SI 63 [ a ])))
(clobber (reg:CC 17 flags))
]) test.c:6 290 {*andsi_1}
(expr_list:REG_DEAD (reg:SI 64 [ b ])
(expr_list:REG_DEAD (reg:SI 63 [ a ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (and:SI (mem/c/i:SI (symbol_ref:SI
("b") [flags 0x2] ) [2 b+0 S4 A32])
(mem/c/i:SI (symbol_ref:SI ("a") [flags 0x2]
) [2 a+0 S4 A32]))
(nil))
(insn 8 7 9 2 (set (mem/c/i:SI (symbol_ref:SI ("a") [flags 0x2]
) [2 a+0 S4 A32])
(reg:SI 61 [ a.2 ])) test.c:6 50 {*movsi_internal}
(nil))
(insn 9 8 10 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 61 [ a.2 ])
(const_int 0 [0]))) test.c:8 2 {*cmpsi_ccno_1}
(expr_list:REG_DEAD (reg:SI 61 [ a.2 ])
(nil)))
---
If I understood correct, gcc could replace insns 5, 7, 8 and 9 by the
insn defined as "*and_2", but it seems "combine" did not tried that.
How gcc could perform such optimization (and similar ones) ? Is a
peephole the most indicated to do that ?
Well, I am new on gcc, so sorry if I am missing something.
best regards,
Alex Rocha Prado
Re: i386: load-operate-store-test
On Fri, Apr 1, 2011 at 8:57 PM, Alex wrote: > If I understood correct, gcc could replace insns 5, 7, 8 and 9 by the insn > defined as "*and_2", but it seems "combine" did not tried that. Yes you missed that combine in GCC only acts on 3 insns at a time. Though that has changed in GCC 4.6 and above so try to look see if the trunk does this optimization. Thanks, Andrew Pinski
Re: i386: load-operate-store-test
Andrew Pinski writes: > On Fri, Apr 1, 2011 at 8:57 PM, Alex wrote: >> If I understood correct, gcc could replace insns 5, 7, 8 and 9 by the insn >> defined as "*and_2", but it seems "combine" did not tried that. > > Yes you missed that combine in GCC only acts on 3 insns at a time. > Though that has changed in GCC 4.6 and above so try to look see if the > trunk does this optimization. FYI, gcc-2.95.4 with -O3 -fomit-frame-pointer -march=pentiumpro generates the following: func1: movl a,%eax andl b,%eax movl %eax,a je .L3 movl d,%eax movl %eax,c .L3: ret
