gcc-trunk bootstrap failure in libjava on i686-pc-cygwin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 gcc-trunk revision 149297 configured with ../../../../src/gcc-4.5.0/configure - --prefix=/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin - --with-gmp=/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin - --with-mpfr=/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin - --with-mpc=/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin - --with-ppl=/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin - --with-cloog=/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin --with-gnu-as - --with-as=/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/bin/as.exe --with-gnu-ld - --with-ld=/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/bin/ld.exe - --enable-bootstrap --enable-checking=release --enable-threads=posix - --disable-werror --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ - --enable-libgomp --with-host-libstdcxx=-lstdc++ shows link failure "undefined reference to `_dlmmap'" and "undefined reference to `_dlmunmap'" /bin/sh ./libtool --tag=CXX --mode=link /home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/./gcc/xgcc - -shared-libgcc -B/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/./gcc - -nostdinc++ - -L/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/i686-pc-cygwin/libstdc++-v3/src - -L/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/i686-pc-cygwin/libstdc++-v3/src/.libs - -B/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/bin/ - -B/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/lib/ -isystem /opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/include -isystem /opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/sys-include - -L/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/i686-pc-cygwin/libjava - -ffloat-store -fomit-frame-pointer -Usun -g -O2 - -Wl,--version-script=../../../../../../src/gcc-4.5.0/libjava/libgcj.ver -o libgcj-tools.la -rpath /opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/lib -rpath /opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/lib -version-info `grep -v '^#' ../../../../../../src/gcc-4.5.0/libjava/libtool-version` - -Wl,-Bsymbolic-functions classpath/tools/libgcj_tools_la-tools.lo libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries libtool: link: /opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/bin/ar rc .libs/libgcj-tools.a classpath/tools/libgcj_tools_la-tools.o libtool: link: /opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/bin/ranlib .libs/libgcj-tools.a libtool: link: ( cd ".libs" && rm -f "libgcj-tools.la" && ln -s "../libgcj-tools.la" "libgcj-tools.la" ) /bin/sh ./libtool --tag=GCJ --mode=link /home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/./gcc/gcj - -B/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/i686-pc-cygwin/libjava/ - -B/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/./gcc/ - -B/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/bin/ - -B/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/lib/ -isystem /opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/include -isystem /opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/sys-include - -L/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/i686-pc-cygwin/libjava - -ffloat-store -fomit-frame-pointer -Usun -g -O2 -o jv-convert.exe - --main=gnu.gcj.convert.Convert -rpath /opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/lib -shared-libgcc - -L/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/i686-pc-cygwin/libjava/.libs libgcj.la libtool: link: /home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/./gcc/gcj - -B/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/i686-pc-cygwin/libjava/ - -B/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/./gcc/ - -B/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/bin/ - -B/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/lib/ -isystem /opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/include -isystem /opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/i686-pc-cygwin/sys-include - -ffloat-store -fomit-frame-pointer -Usun -g -O2 -o .libs/jv-convert.exe - --main=gnu.gcj.convert.Convert -shared-libgcc - -L/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/i686-pc-cygwin/libjava/.libs - -L/home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/i686-pc-cygwin/libjava ./.libs/libgcj.a -ldl -L/opt/devel/gnu/gcc/gcc-4.5.0/i686-pc-cygwin/lib ./.libs/libgcj.a(closures.o): In function `release_unused_segments': /home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/i686-pc-cygwin/libffi/../../../../../../src/gcc-4.5.0/libffi/src/dlmalloc.c:3575: undefined reference to `_dlmunmap' ./.libs/libgcj.a(closures.o): In function `mmap_alloc': /home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/i686-pc-cygwin/libffi/../../../../../../src/gcc-4.5.0/libffi/src/dlmalloc.c:3156: undefined reference to `_dlmmap' ./.libs/libgcj.a(closures.o): In function `sys_alloc': /home/rainer/software/build/i686-pc-cygwin/gcc-4.5.0/gcc/i686-pc-cygwin/libffi/../../../../../../src/gcc-4.5.0/libffi
Can GCC scheduler take advantage of mutually exclusive predicated blocks?
Hello, Our GCC port & VLIW target processor support predication. However, I don't see the GCC schedule two mutually exclusive blocks (from IF and ELSE ) in a way that they are independent from each other. I am wondering if this is a problem of our porting and I missed some tricks , or it is current limitation of GCC. Thanks, Bingfeng Mei Broadcom Uk
VTA compilation speed comparison
Hi!
This is a follow-up to the compile time memory consumption comparison I've
posted on Friday.
As I forgot to note the start wall time in each directory, the wall time
figures don't include the first compiled file (so TRAMP3D isn't included,
being a one testcase only directory) and VARIOUS numbers aren't either,
because I've been compiling that directory in two steps.
Other than wall time the numbers are for TOTAL lines from time-stats {sum,max}
*.time_report
scripts, variable tracking lines from that and sum of all other lines.
As can be seen from the numbers, on C and some C++ code VTA has almost no
effect on compile time in passes other than vartrack (which is certainly
slower, more stuff is tracked), for heavily inlined code like tramp3d
VTA is somewhat slower even outside of vartrack pass.
Wall time (difference between mtime of the last file and first file in the
directory):
-O0-m64 -O0-m32 -O1-m64 -O1-m32 -O2-m64 -O2-m32 -O3-m64
-O3-m32 -Os-m64 -Os-m32
GCC tr...@148582 wall 598 574 913 883 117211281384
134710521040
GCC v...@149180 wall 599 565 997 975 124412221496
139111181075
v...@149180/tr...@148582100.17% 98.43% 109.20% 110.42% 106.14% 108.33%
108.09% 103.27% 106.27% 103.37%
FF3D tr...@148582 wall 349 332 471 479 599 603 675
682 445 450
FF3D v...@149180 wall 349 336 514 531 666 683 755
743 470 467
v...@149180/tr...@148582100.00% 101.20% 109.13% 110.86% 111.19% 113.27%
111.85% 108.94% 105.62% 103.78%
MICO tr...@148582 wall 542 356 669 457 747 528 804
574 661 467
MICO v...@149180 wall 549 358 713 496 805 577 864
600 656 485
v...@149180/tr...@148582101.29% 100.56% 106.58% 108.53% 107.76% 109.28%
107.46% 104.53% 99.24% 103.85%
SPEC2K tr...@148582wall 170 169 248 248 307 314 386
385 286 294
SPEC2K v...@149180 wall171 169 263 268 334 336
416 409 249 304
v...@149180/tr...@148582100.59% 100.00% 106.05% 108.06% 108.79% 107.01%
107.77% 106.23% 87.06% 103.40%
DLV tr...@148582 wall 74 70 106 107 131 133 141
140 91 93
DLV v...@149180 wall 74 71 118 120 146 148 154
156 99 100
v...@149180/tr...@148582100.00% 101.43% 111.32% 112.15% 111.45% 111.28%
109.22% 111.43% 108.79% 107.53%
TOTAL time (^ TOTAL lines from time-stats {sum,max} *.time_report):
-O0-m64 -O0-m32 -O1-m64 -O1-m32 -O2-m64 -O2-m32 -O3-m64
-O3-m32 -Os-m64 -Os-m32
GCC sum g...@148582 403.80 382.38 700.53 673.51 936.03 898.78 1150.50
1118.36 837.34 825.97
GCC sum v...@149180 402.72 375.63 779.90 760.71 1022.73 1001.32 1258.63
1163.10 904.53 867.20
99.73% 98.23% 111.33% 112.95% 109.26% 111.41% 109.40%
104.00% 108.02% 104.99%
GCC max g...@148582 18.73 15.52 62.01 49.53 81.66 66.83 87.85
81.35 85.12 67.60
GCC max v...@149180 19.06 14.61 63.61 53.25 84.92 70.20 101.49
71.17 88.68 70.37
101.76% 94.14% 102.58% 107.51% 103.99% 105.04% 115.53%
87.49% 104.18% 104.10%
FF3D sum g...@148582266.31 251.09 375.34 384.27 493.05 500.32 568.00
576.90 350.51 358.17
FF3D sum v...@149180266.45 253.73 414.90 432.42 561.99 580.29 643.95
634.90 373.19 375.93
100.05% 101.05% 110.54% 112.53% 113.98% 115.98% 113.37%
110.05% 106.47% 104.96%
FF3D max g...@14858213.37 12.92 25.06 26.98 35.63 36.71 43.63
42.17 24.55 26.06
FF3D max v...@14918013.36 13.18 29.32 30.88 41.35 42.41 51.48
48.61 28.00 28.52
99.93% 102.01% 117.00% 114.46% 116.05% 115.53% 117.99%
115.27% 114.05% 109.44%
MICO sum g...@148582410.69 268.40 527.87 361.55 602.86 429.43 657.87
474.02 521.99 372.92
MICO sum v...@149180415.93 270.33 570.76 398.85 661.67 478.53 713.74
499.64 523.19 392.57
101.28% 100.72% 108.13% 110.32% 109.76% 111.43% 108.49%
105.40% 100.23% 105.27%
MICO max g...@14858214.16 13.10 23.77 23.01 32.87 32.99 36.87
36.52 24.31 24.89
MICO max v...@14918014.73 13.14 26.03 26.83 36.08 35.71 38.81
38.98 24.82 26.13
104.03% 100.31% 109.51% 116.60% 109.77% 108.24% 105.26%
106.74% 102.10% 104.98%
SPEC2K sum g...@148582 113.53 111.75 180.40 182.72 242.60 244.81 315.16
314.37 220.52 228.59
SPEC2K sum v...@149180 114.83 111.88 199.14 202.55 267.37 269.40 343.29
338.20 197.20 241.66
101.15% 100.12% 110.39% 110.85% 110.21% 110.04% 108.93%
107.58% 89.42% 105.72%
SPEC2K max g...@148582 1.771.763.363.4
VTA IL size comparison
Hi!
And here is IL size comparison, where ILsize is:
tree/-O0: sum of non-empty lines in *t.ssa dumps for all sources in the
directory
tree/-O{1,2,3,s}sum of non-empty lines in *t.uncprop dumps for all sources in
the directory
rtl:sum of lines with ( in 1st column in *r.alignments dumps for
all sources in the directory
-O0-m64 -O0-m32 -O1-m64 -O1-m32 -O2-m64 -O2-m32 -O3-m64
-O3-m32 -Os-m64 -Os-m32
GCC tr...@148582 tree 5893253 5510130 4633676 4375725 4584302 4323132 5421218
5107663 4070754 3827748
GCC v...@149180 tree 5893253 5510130 5074743 4804116 5017853 4744241 5976974
5645208 4425867 4171593
v...@149180/tr...@148582100.00% 100.00% 109.52% 109.79% 109.46% 109.74%
110.25% 110.52% 108.72% 108.98%
GCC tr...@148582 rtl6811872 6456958 4592506 4701806 4514273 4675215 5234538
5400189 3938765 4362578
GCC v...@149180 rtl 6811872 6456958 5005824 5104169 4914430 5067393 5739177
5892088 4273726 4689434
v...@149180/tr...@148582100.00% 100.00% 109.00% 108.56% 108.86% 108.39%
109.64% 109.11% 108.50% 107.49%
FF3D tr...@148582 tree 2392550 2344689 1957501 1966199 2157284 2149682 2452448
2427672 1171010 1157438
FF3D v...@149180 tree 2392550 2344689 2587570 2571873 3003105 2976057 3657238
3629239 1516499 1493055
v...@149180/tr...@148582100.00% 100.00% 132.19% 130.80% 139.21% 138.44%
149.13% 149.49% 129.50% 129.00%
FF3D tr...@148582 rtl 3404093 3239650 1607525 1917906 1705382 1952234 2018573
2257943 1057894 1307372
FF3D v...@149180 rtl 3404093 3239650 2215627 2506322 2518475 2754024 3151221
3398657 1379097 162
v...@149180/tr...@148582100.00% 100.00% 137.83% 130.68% 147.68% 141.07%
156.11% 150.52% 130.36% 124.51%
MICO tr...@148582 tree 2762598 2076735 2139527 1599012 2270729 1717646 2464787
1885967 1558063 1193186
MICO v...@149180 tree 2762598 2076735 2533508 1869281 2654502 1992996 2909617
2214194 1755467 1339025
v...@149180/tr...@148582100.00% 100.00% 118.41% 116.90% 116.90% 116.03%
118.05% 117.40% 112.67% 112.22%
MICO tr...@148582 rtl 3151113 2282493 1704626 1458846 1678263 1448777 1823247
1576078 1273735 1238043
MICO v...@149180 rtl 3151113 2282493 2085559 1720179 2049142 1715820 2252895
1894317 1469047 1382728
v...@149180/tr...@148582100.00% 100.00% 122.35% 117.91% 122.10% 118.43%
123.56% 120.19% 115.33% 111.69%
SPEC2K tr...@148582 tree1776473 1757248 1298470 1276654 1321438 1294515
1678000 1616487 1251804 1230765
SPEC2K v...@149180 tree 1776473 1757248 1427694 1405545 1455981 1428657
1872231 1808063 1370928 1349734
v...@149180/tr...@148582100.00% 100.00% 109.95% 110.10% 110.18% 110.36%
111.58% 111.85% 109.52% 109.67%
SPEC2K tr...@148582 rtl 1855373 1845353 1230136 1340522 1258702 1394028 1571868
1706831 1149485 1338236
SPEC2K v...@149180 rtl1855373 1845353 1342191 1452864 1376049 1512332
1732526 1867200 1259763 1448796
v...@149180/tr...@148582100.00% 100.00% 109.11% 108.38% 109.32% 108.49%
110.22% 109.40% 109.59% 108.26%
TRAMP3D tr...@148582 tree 275269 274346 279614 251066 247188 241435
255313 243612 147422 141801
TRAMP3D v...@149180 tree 275269 274346 521064 485097 487328 486643
525837 517895 302433 296995
v...@149180/tr...@148582100.00% 100.00% 186.35% 193.21% 197.15% 201.56%
205.96% 212.59% 205.15% 209.44%
TRAMP3D tr...@148582 rtl439802 424296 88 223360 193720 213572
201673 219181 130507 152787
TRAMP3D v...@149180 rtl 439802 424296 445441 439322 409531 433672
437528 459232 269425 291400
v...@149180/tr...@148582100.00% 100.00% 200.39% 196.69% 211.40% 203.06%
216.95% 209.52% 206.44% 190.72%
DLV tr...@148582 tree 540575 531998 534088 531073 504988 503295 529447
522153 273747 267836
DLV v...@149180 tree 540575 531998 723814 717992 692535 689318 735935
726014 360789 352740
v...@149180/tr...@148582100.00% 100.00% 135.52% 135.20% 137.14% 136.96%
139.00% 139.04% 131.80% 131.70%
DLV tr...@148582 rtl767603 729129 417516 461036 398209 438234 425596
457521 228357 273553
DLV v...@149180 rtl 767603 729129 601120 641995 581810 620402 626988
656787 314247 357545
v...@149180/tr...@148582100.00% 100.00% 143.98% 139.25% 146.11% 141.57%
147.32% 143.55% 137.61% 130.70%
VARIOUS tr...@148582 tree 654327 653127 800961 809774 836987 840178
870934 862115 566547 649454
VARIOUS v...@149180 tree 654327 653127 1056726 1077079 1121143 1128359
1211314 1202772 719296 827815
v...@149180/tr...@148582100.00% 100.00% 131.93% 133.01% 133.95% 134.30%
139.08% 139.51% 126.96% 127.46%
VARIOUS tr...@148582 rtl1103152 1158232 852570 993679 851459 1048228
877808 1075550 645325 927493
VARIOUS v...@149180 rtl 1103152 1158232 1097178 1249515 1123078 1324149
1183833 1383532 789664 1098042
v...@149180/tr...@148582100.00% 100.00% 128.69% 125.75%
Internal Representation
Hello, I looked at the part of the documentation about function bodies and I wonder something : is there a way to get the function calls from it ? Because I'd like to make a call graph which represent function and the functions it calls. Thank you. Nicolas COLLIN
Re: gcc-trunk bootstrap failure in libjava on i686-pc-cygwin
Rainer Emrich wrote: > shows link failure "undefined reference to `_dlmmap'" and "undefined reference > to `_dlmunmap'" Sorry, I got distracted from this one for a bit. I'm working on a fix. cheers, DaveK
Status of LTO merge to mainline
I am working on the last 60 testsuite failures on x86_64, but I'm sure there will be other failures in other architectures. My merge plan is: 1- Fix the remaining failures on x86_64. This includes fixing thunks for vararg functions which I plan to address as outlined in http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00953.html 2- Fix open PRs against the LTO branch. There are 28 open bugs against the branch. I need to triage them to see which ones may already be fixed. 3- Enable pass_ipa_free_lang_data by default. This is the pass that removes all references to front end trees from GIMPLE, implicitly breaking debugging information. My current plan is to implement Richi's and Cary's idea of generating debug info early. 4- Test on primary and secondary platforms. What is the current suggested list of platforms? The items that need active development are #1 and #3. For #1, I think I can have all the failures fixed in 2-3 weeks. I do not have a good estimate for #3 since I do not really know how much work this will entail (Richi? Cary? would you have a rough estimate for this?). Any and all help I can get with #2 and #4 will be appreciated. For #2, I need to triage the reports to see which ones can be closed already. For #4, it should be a matter of testing the branch with: $ svn co svn://gcc.gnu.org/svn/gcc/branches/lto $ mkdir bld && cd bld $ ../lto/configure --enable-lto && make && make -k check Thanks. Diego.
Re: Internal Representation
You must be looking at old documentation or something. Call's are represented by GIMPLE_CALL_STMT (or CALL_EXPR in older GCC'en). There has been a callgraph for quite a long time (see cgraph*.c and cgraph*.h) On Tue, Jul 7, 2009 at 7:26 AM, Nicolas COLLIN wrote: > Hello, > I looked at the part of the documentation about function bodies and I wonder > something : is there a way to get the function calls from it ? Because I'd > like to make a call graph which represent function and the functions it > calls. > Thank you. > > Nicolas COLLIN >
Re: Internal Representation
Nicolas COLLIN writes: > I looked at the part of the documentation about function bodies and I > wonder something : is there a way to get the function calls from it ? > Because I'd like to make a call graph which represent function and the > functions it calls. gcc builds a call graph. See cgraph.h. Ian
Re: Status of LTO merge to mainline
On Tue, Jul 7, 2009 at 6:09 AM, Diego Novillo wrote: > 4- Test on primary and secondary platforms. What is the current > suggested list of platforms? > > Any and all help I can get with #2 and #4 will be appreciated. > For #2, I need to triage the reports to see which ones can be > closed already. For #4, it should be a matter of testing the > branch with: > I have been testing LTO on Linux/ia32 and Linux/x86-64. I had to disable LTO test on Linux/ia64 since it miscompiled several Java testcases into infinite loops. I can try to find out which checkin caused this if needed. -- H.J.
Re: Status of LTO merge to mainline
On Tue, Jul 7, 2009 at 09:31, H.J. Lu wrote: > I have been testing LTO on Linux/ia32 and Linux/x86-64. > I had to disable LTO test on Linux/ia64 since it miscompiled > several Java testcases into infinite loops. I can try to find out > which checkin caused this if needed. Thanks, that would be interesting. It's odd that Java is miscompiled by the branch since LTO does not work with it, but there are some changes in default codepaths, so it's worth tracking those down. Diego.
Re: Status of LTO merge to mainline
On Tue, Jul 7, 2009 at 3:31 PM, H.J. Lu wrote: > On Tue, Jul 7, 2009 at 6:09 AM, Diego Novillo wrote: > >> 4- Test on primary and secondary platforms. What is the current >> suggested list of platforms? >> >> Any and all help I can get with #2 and #4 will be appreciated. >> For #2, I need to triage the reports to see which ones can be >> closed already. For #4, it should be a matter of testing the >> branch with: >> > > I have been testing LTO on Linux/ia32 and Linux/x86-64. > I had to disable LTO test on Linux/ia64 since it miscompiled > several Java testcases into infinite loops. I can try to find out > which checkin caused this if needed. I do SPEC 2000 runs on x86_64 triggered by changes on the branch. See http://gcc.opensuse.org/SPEC/CFP/sb-haydn-df-64/recent.html http://gcc.opensuse.org/SPEC/CINT/sb-haydn-df-64/recent.html Richard.
Re: preprocessors & GCC plugins
2009/7/6 Basile STARYNKEVITCH : > Hello All > > I would suppose that the preprocessor (ie libcpp) might be enhanced to use > plugins. I can see several scenarii for them: > > 1. a plugin could enhance the way #include directives are processed > > 2. a plugin could add additional builtin macros, like __COUNTER__, which > would be specific to the plugin. > > 3. a plugin could add extra CPP directives (like #ident) > > What do you think? Probably 1 is harder to implement than 2 or 3, but I am > not very familiar with libcpp/ > > The http://gcc.gnu.org/ml/gcc/2009-07/msg9.html mail suggested me the > plugins could be useful in the preprocessor. > > Currently, there is no plugin specific code inside libcpp/ It might be useful, but I would wait a bit before implementing it if is not critical. Lets first see how plugins get used. For example, whether the linux distributions will ship a 4.5 with plugins support. > Regards. > Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: Can GCC scheduler take advantage of mutually exclusive predicated blocks?
On 07/07/2009 02:21 AM, Bingfeng Mei wrote: Hello, Our GCC port& VLIW target processor support predication. However, I don't see the GCC schedule two mutually exclusive blocks (from IF and ELSE ) in a way that they are independent from each other. I am wondering if this is a problem of our porting and I missed some tricks , or it is current limitation of GCC. It can, but the test is fairly weak. See conditions_mutex_p in sched-deps.c. This could probably be enhanced... r~
random numbers
how do I generate random numbers in a f77 program? Ed Crosbie
Re: random numbers
ecrosbie wrote: how do I generate random numbers in a f77 program? Ed Crosbie
optimizer hints for critical sections
It would be nice to have optimizer hints useful for critical sections - sections that should be optimized at the expense of code surrounding it. pthread_mutex_lock(&m); critical section; pthread_mutex_unlock(&m); Things like spilling registers, .p2align, jumps that the compiler need to insert etc, should here preferably be outside the critical section. I imagine this could be done by giving pthread_mutex_lock() weak variants of __attribute__((cold)) before the function and ((hot)) after, and the inverse for pthread_mutex_unlock(). Whether an exit point is hot or not can depend on the result code though. E.g. pthread_mutex_trylock(&m) would be hot only when returning 0. Well, so is pthread_mutex_lock, but there it makes sense to default to "hot" if the error code is not checked or if the compiler cannot figure out how the error code is used. Such a default is likely wrong for trylock. -fprofile-use may not work right for these optimizations. If anything, it may pessimize a critical section which is not entered often because the surrounding code works at avoiding entry into it. __builtin_expect() may not help either since it is not branches at the function call as such that need to be optimized, but also e.g. where to insert an unconditional jump which needs to be put somewhere - inside or outside the critical section, regardless of branches or no branches. The compiler already can optimize entry into the critical section somewhat if the program branches on whether entry succeeded. Does not help near exit from a critical section though. And it would be nice to optimize it when there is no profile data or __builtin_expect. These hints should not be too strong - do not pessimize too much at the outside of the critical section, since there may be nested critical sections. There are some other cases which could use this too. E.g. execvp() is likely "cold" on return but not on entry. The manual suggests e.g. perror could be "cold", but that's not right for the branch leading up to execvp - since it's just the return which is unlikely. In that regard, it'd also be useful to have an attribute or something which just cancels out __attribute__((cold)) but does not make anything "hot". -- Hallvard
Re: random numbers
ecrosbie wrote: how do I generate random numbers in a f77 program? Ed Crosbie This subject isn't topical on the gcc development forum. If you wish to use a gnu Fortran random number generator, please consider gfortran, which implements the language standard random number facility. http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gfortran/ questions might be asked on the gfortran list (follow-up set) or comp.lang.fortran In addition, you will find plenty of other advice by using your web browser.
gcc-4.4-20090707 is now available
Snapshot gcc-4.4-20090707 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090707/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 149354 You'll find: gcc-4.4-20090707.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090707.tar.bz2 C front end and core compiler gcc-ada-4.4-20090707.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090707.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090707.tar.bz2 C++ front end and runtime gcc-java-4.4-20090707.tar.bz2 Java front end and runtime gcc-objc-4.4-20090707.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090707.tar.bz2The GCC testsuite Diffs from 4.4-20090630 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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.
