Re: Bootstrap Failure Question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/04/11 14:15, Iyer, Balaji V wrote: > Thanks Jeff for your help! > > So, are the errors confined to these files? Or could it be > anywhere? It could be anywhere. That failure means that stage1 and stage2 compilers generated different code for the listed files. That only happens when the stage1 compiler miscompiles the stage2 compiler. > > Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs > warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o > differs Bootstrap comparison failure! gcc/i386-common.o differs > gcc/bitmap.o differs libiberty/timeval-utils.o differs > libiberty/pic/timeval-utils.o differs > > > Is there anything else I can do to pin-point the problem? (like > maybe gdb a certain file or pass a certain flag to get some debug > info) You have to find out why the two compilers generate different code, the first point at which their behavior diverges indicates the code that is being mis-compiled. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOt5R4AAoJEBRtltQi2kC7KBwIAKuvwIeKOyS+nHtPash1W6jf 9b7keHHPg56+cLo6ItcW8SibBPjabpIpEqU269K+qXolMw6kIBWGgs18msXi66Rn 3m3TOKGkXwNE0QS3oDjZdt808zMoP6z10OkKBlrk1ieuksC9NZUXISte9A/NMStV hNsNbzN1gBKsyRiVC434H7l9LxBpMdGNKiLfokmf0Hlnlk+w04Pf5hZQCmiZ/GAH B5I4b9u6yiVqxPqfErRGcNXXMQcAxp7FzLXrBx0ISS7Qdm2HXpAJFSEp0URPL1gU Tt+rpM9uECmEWG2J44+NKuitjwFNOZH02/UYizVbjbYtWdp9edk6Jmw4DgFyFL8= =mv82 -END PGP SIGNATURE-
Re: bootstrap of 4.6.2 on Solaris i386, gone in 60 seconds
> This should probably be on the gcc-help list. I never really know which direction to go as the issues seem to be related to how limits-exprparen.c gets tested. However, no problem, I'll jump ship and get out of this ml. > On 7 November 2011 01:08, Dennis Clarke wrote: >> >> Well, dear GCC users I am now seeing behavior that falls in the arean of >> the bizarre. No sense in talking much about it but here is the error >> message : >> >> /opt/bw/src/GCC/gcc_4.6.2/gcc-4.6.2/intl/configure: line 7353: .: >> ./conf4075subs.sh: file is too large >> configure: error: could not make ./config.status > > Have you checked your ulimit? I was thinking that too! I just recently increased the stack size limit to 16 MB : $ ulimit -a time(seconds)unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes)16384 coredump(blocks) unlimited nofiles(descriptors) 256 vmemory(kbytes) unlimited I am sure "unlimited" will work fine :-\ > And of course disk space? yep, got lots. Thanks for the input. I'll keep working on this until I get a clean bootstrap and if that takes a month, then fine. The results are always worth it and somewhat critical to have a compiler I trust. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: # of unexpected failures 768 ?
> Dennis Clarke writes: > >> Only the new "go" language seems to be a major issue now. > > The implementation of Go in the 4.6 releases does not support Solaris. > > Go on Solaris works on mainline. Well, I would not have seen that coming. I should look more closely at the various README's and changelogs. To be honest, I scrapped my Solaris Sparc resultant compiler here : http://gcc.gnu.org/ml/gcc-testresults/2011-11/msg00683.html ... and am starting over. With no go, and no pun inteneded. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
new mirror site Gcc
Good day! I want to host a new mirror site Gcc. Server name - Latvia ChampGround Server admin - vt.avtm...@gmail.com, Vladimir Server location - Latvia, Riga Server address - champground.com Server protocol - http Connection speed - 100 Mbps Thanks.
Re: Delegating Constructors?
>> It's pending copyright paperwork from the author of the original patch. >> (my copyright paperwork is in order, but since I didn't write all of it, >> there's some crossing t's and dotting i's). >Hmm, has he been contacted recently? The original patch was from ages >ago... >Thanks, >-Miles Jason has contacted Pedro, and Jason's been handling the copyright issues for that patch towards FSF as well. I don't subscribe to the gcc mailing list, if you have questions, please cc me. :)
Re: bootstrap of 4.6.2 on Solaris i386, gone in 60 seconds
Message from Dennis Clarke at 2011-11-07 06:38:47 -- > > Have you checked your ulimit? > >I was thinking that too! I just recently increased the stack size limit to >16 MB : The 'fix' in mainline set it higher: 2011-07-22 Jakub Jelinek PR c++/49756 * gcc.c (main): Call stack_limit_increase (64MB). * toplev.c (toplev_main): Likewise.
Re: bootstrap of 4.6.2 on Solaris i386, gone in 60 seconds
> Message from Dennis Clarke at 2011-11-07 > 06:38:47 -- >> > Have you checked your ulimit? >> >>I was thinking that too! I just recently increased the stack size limit >> to >>16 MB : > > The 'fix' in mainline set it higher: > > 2011-07-22 Jakub Jelinek > > PR c++/49756 > * gcc.c (main): Call stack_limit_increase (64MB). > * toplev.c (toplev_main): Likewise. Well things seem to be working well on sparc and still very poorly on x86 so I am scrapping my whole stack on x86. Starting over one step at a time and carefully looking into testsuite results on every piece as I climb up the requirements. As for sparc, I expect to post good results, minus "go", in about 72 hours. Dennis -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
performance decreased
Hi to all. I want to tell you about a bizarre behavior in executables compiled with gcc 4.2.1 compiler. A few weeks ago i did must to paralelize a lattice boltzmann algorithm using OMP directives (with adding own optimizations) to pass my High-performance computing course. I compile my c programm like this: $gcc -O3 -fopenmp -lm lattice-boltzmann.c -o output In lattice-boltzmann.c code i get the time with 2 calls to :omp_get_wtime(). And then run the output after set OMP_NUM_THREADS value: $export OMP_NUM_THREADS=XXX $./output #without taskset programm With the purpose of measuring the SpedUp by changing the number of threads. I did run fourty times by changing the value OMP_NUM_THREAD from 1 to 40. I run it in a node with 40 cores Xenon.4 Processors with 10 cores each one. The next is time in sec, no speedUP: 3.972002 2.052636 1.430107 1.62 0.938760 0.811720 0.719483 0.666361 0.621093 0.563764 0.546574 0.510918 0.497733 0.481643 0.476792 0.454967 0.476283 0.445797 0.433787 0.426813 0.432890 0.436993 0.401258 0.424988 0.409322 0.416022 0.475070 0.425502 0.414787 0.434697 0.450460 0.428303 0.452609 0.453830 0.450324 0.461843 0.466831 0.464153 0.761500//39 threads 29.927848//40 threads Why performance decreased when the number of threads approaches the number of cores? What version of gcc resolve this behavior? Or How i resolve this behavior? The problem is not in the decreased of performance is in the magnitude with which it does. I compile my c programm like this too (intel64 compiler ver 11.1): $icc -fast -openmp lattice-boltzmann.c -o output The performance also decreases but not in the same magnitude. 0.336723//39 threads 0.756676//40 threads, and not: 14.22 sec for example. I'm not the only one that had this problem, my partners had this problem too. Regards from Argentina!
Re: performance decreased
On 11/07/2011 07:32 PM, Francisco Llaryora wrote: With the purpose of measuring the SpedUp by changing the number of threads. I did run fourty times by changing the value OMP_NUM_THREAD from 1 to 40. I run it in a node with 40 cores Xenon.4 Processors with 10 cores each one. The next is time in sec, no speedUP: First, the email is more appropriate for gcc-help@ as gcc@ is the developer list. Regarding the issue itself: Try OMP_WAIT_POLICY=PASSIVE - cf. http://gcc.gnu.org/onlinedocs/libgomp/OMP_005fWAIT_005fPOLICY.html or any OpenMP documentation. One still expects that the performance decreases if one has more threads than cores, but it should not decrease as much as with ACTIVE. The default value is something in between - it burns wait cycles as with ACTIVE but only for a very short time while with ACTIVE is does so for a much longer time before continuing to wait passively. Note: The comments are for the current version; I am not sure about GCC 4.2.1 - it might well be that the default wait policy wasn't falling back to a passive wait that quickly. Tobias
Re: Potentially merging the transactional-memory branch into mainline.
Could you please fix up whitespace in the patch, at least leading tabs
and trailing whitespace?
On the patch it is easy to do, something like:
sed 's/^+\([\t]*\) \{64\}/+\1\t\t\t\t\t\t\t\t/;s/^+\([\t]*\)
\{32\}/+\1\t\t\t\t/;s/^+\([\t]*\) \{16\}/+\1\t\t/;s/^+\([\t]*\)
\{8\}/+\1\t/;s/^+\(.*[^[:blank:]]\)[[:blank:]]\+$/+\1/;s/^+[[:blank:]]\+$/+/'
patch> patch.whitespace
and then interdiff patch patch.whitespace> whitespace
and review that diff and if appropriate commit to branch before merging?
Easy only for the keepers of incomprehensible sed magic! Thanks for the
script.
Here is the toplevel ChangeLog.tm entry.
* Fix leading tabs and trailing whitespace throughout entire
branch.
Attached is the compressed patch I will commit after I do a full
bootstrap and regtest, as I'm rather queasy of committing even
whitespace changes right now.
This pretty much culminates my responses to reviews of the branch. I
will post a separate status report once the last three patches are
approved (one from rth, one from Torvald, and one from myself). I
believe we have addressed everything that was a blocker.
curr.gz
Description: GNU Zip compressed data
transactional-memory status
Dear Release Managers... We're pretty much done with the merge blockers, and even suggestions that weren't blockers :). The only outstanding patch review is a cleanup by Richard Henderson that is waiting for Richi's review here: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01033.html I am still testing some whitespace changes, but I'm fairly confident in my ability to hit tab and space bar. Is there anything else you require of me? Ideally I'd like a slush, if the merge gets approved. I would do one last trunk->branch, test, apply the global diff to trunk, and ask for a slush while I commit. This is, assuming the merge is authorized. I could also post the last diff before the commit, if it is necessary. What do you guys think?
gcc-trunk build error in OpenBSD on stage3
Hi list. On build gcc-trunk in OpenBSD-5.0 on staget 3 I get the following errors: if [ x"-fpic" != x ]; then \ /home/root/gcc-build/build/gcc-trunk/./prev-gcc/xgcc -B/home/root/gcc-build/build/gcc-trunk/./prev-gcc/ -B/usr/local/i686-pc-openbsd5.0/bin/ -B/usr/local/i686-pc-openbsd5.0/bin/ -B/usr/local/i686-pc-openbsd5.0/lib/ -isystem /usr/local/i686-pc-openbsd5.0/include -isystem /usr/local/i686-pc-openbsd5.0/sys-include-c -DHAVE_CONFIG_H -g -O2 -I. -I../../../src/gcc-trunk/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -fpic ../../../src/gcc-trunk/libiberty/filename_cmp.c -o pic/filename_cmp.o; \ else true; fi ../../../src/gcc-trunk/libiberty/fibheap.c: In function 'fibheap_union': ../../../src/gcc-trunk/libiberty/fibheap.c:151:7: warning: implicit declaration of function 'free' [-Wimplicit-function-declaration] ../../../src/gcc-trunk/libiberty/fibheap.c:151:7: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../../src/gcc-trunk/libiberty/fibheap.c:156:7: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../../src/gcc-trunk/libiberty/fibheap.c:172:3: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../../src/gcc-trunk/libiberty/fibheap.c: In function 'fibheap_extract_min': ../../../src/gcc-trunk/libiberty/fibheap.c:190:7: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../../src/gcc-trunk/libiberty/fibheap.c: In function 'fibheap_replace_key_data': ../../../src/gcc-trunk/libiberty/fibheap.c:220:30: error: 'LONG_MIN' undeclared (first use in this function) ../../../src/gcc-trunk/libiberty/fibheap.c:220:30: note: each undeclared identifier is reported only once for each function it appears in ../../../src/gcc-trunk/libiberty/fibheap.c: In function 'fibheap_delete_node': ../../../src/gcc-trunk/libiberty/fibheap.c:261:36: error: 'LONG_MIN' undeclared (first use in this function) ../../../src/gcc-trunk/libiberty/fibheap.c:265:7: warning: implicit declaration of function 'abort' [-Wimplicit-function-declaration] ../../../src/gcc-trunk/libiberty/fibheap.c:265:7: warning: incompatible implicit declaration of built-in function 'abort' [enabled by default] ../../../src/gcc-trunk/libiberty/fibheap.c: In function 'fibheap_delete': ../../../src/gcc-trunk/libiberty/fibheap.c:277:5: warning: incompatible implicit declaration of built-in function 'free' [enabled by default] ../../../src/gcc-trunk/libiberty/fibheap.c: In function 'fibheap_consolidate': ../../../src/gcc-trunk/libiberty/fibheap.c:368:3: warning: implicit declaration of function 'memset' [-Wimplicit-function-declaration] ../../../src/gcc-trunk/libiberty/fibheap.c:368:3: warning: incompatible implicit declaration of built-in function 'memset' [enabled by default] gmake[3]: *** [fibheap.o] Error 1 gmake[3]: *** Waiting for unfinished jobs In file included from ../../../src/gcc-trunk/libiberty/filename_cmp.c:27:0: ../../../src/gcc-trunk/libiberty/../include/filenames.h:85:6: error: unknown type name 'size_t' ../../../src/gcc-trunk/libiberty/filename_cmp.c: In function 'filename_cmp': ../../../src/gcc-trunk/libiberty/filename_cmp.c:55:3: warning: implicit declaration of function 'strcmp' [-Wimplicit-function-declaration] ../../../src/gcc-trunk/libiberty/filename_cmp.c: At top level: ../../../src/gcc-trunk/libiberty/filename_cmp.c:109:48: error: unknown type name 'size_t' gmake[3]: *** [filename_cmp.o] Error 1 gmake[3]: Leaving directory `/home/root/gcc-build/build/gcc-trunk/libiberty' gmake[2]: *** [all-stage3-libiberty] Error 2 gmake[2]: Leaving directory `/home/root/gcc-build/build/gcc-trunk' gmake[1]: *** [stage3-bubble] Error 2 gmake[1]: Leaving directory `/home/root/gcc-build/build/gcc-trunk' gmake: *** [all] Error 2 stage1 and stage2 pass successfully. in libiberty/config.h macro HAVE_LIMITS_H is undefined. any ideas? Regards, niXman.
Re: gcc-trunk build error in OpenBSD on stage3
niXman writes: > in libiberty/config.h macro HAVE_LIMITS_H is undefined. Look in libiberty/config.log to see why HAVE_LIMITS_H is not defined. Also why HAVE_STDLIB_H is not defined. Ian
Re: failure notice
Diffs between stage2 and stage3. on configure libiberty for stage3 I see this warnings: configure:4962: checking for limits.h configure:4962: /home/root/gcc-build/build/gcc-trunk/./prev-gcc/xgcc -B/home/root/gcc-build/build/gcc-trunk/./prev-gcc/ -B/usr/local/i686-pc-openbsd5.0/bin/ -B/usr/local/i686-pc-openbsd5.0/bin/ -B/usr/local/i686-pc-openbsd5.0/lib/ -isystem /usr/local/i686-pc-openbsd5.0/include -isystem /usr/local/i686-pc-openbsd5.0/sys-include-E conftest.c /home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0: /home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING: symbol(_ZNSt6locale5_Impl11_S_id_ctypeE) size mismatch, relink your program /home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0: /home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING: symbol(_ZNSt6locale5_Impl13_S_id_numericE) size mismatch, relink your program /home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0: /home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING: symbol(_ZNSt6locale5_Impl13_S_id_collateE) size mismatch, relink your program /home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0: /home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING: symbol(_ZNSt6locale5_Impl10_S_id_timeE) size mismatch, relink your program /home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0: /home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING: symbol(_ZNSt6locale5_Impl14_S_id_monetaryE) size mismatch, relink your program /home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0: /home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING: symbol(_ZNSt6locale5_Impl14_S_id_messagesE) size mismatch, relink your program I have never seen such warnings... Therefore, some tests fail. --- /home/nixman/config_correct.h +++ /home/nixman/config_incorrect.h @@ -54,7 +54,7 @@ #define HAVE_DECL_CALLOC 1 /* Define to 1 if you have the declaration of `ffs', and to 0 if you don't. */ -#define HAVE_DECL_FFS 1 +#define HAVE_DECL_FFS 0 /* Define to 1 if you have the declaration of `getenv', and to 0 if you don't. */ @@ -74,7 +74,7 @@ /* Define to 1 if you have the declaration of `sbrk', and to 0 if you don't. */ -#define HAVE_DECL_SBRK 1 +#define HAVE_DECL_SBRK 0 /* Define to 1 if you have the declaration of `snprintf', and to 0 if you don't. */ @@ -96,7 +96,7 @@ /* #undef HAVE_DUP3 */ /* Define to 1 if you have the header file. */ -#define HAVE_FCNTL_H 1 +/* #undef HAVE_FCNTL_H */ /* Define to 1 if you have the `ffs' function. */ #define HAVE_FFS 1 @@ -129,13 +129,13 @@ #define HAVE_INSQUE 1 /* Define to 1 if the system has the type `intptr_t'. */ -#define HAVE_INTPTR_T 1 +/* #undef HAVE_INTPTR_T */ /* Define to 1 if you have the header file. */ -#define HAVE_INTTYPES_H 1 +/* #undef HAVE_INTTYPES_H */ /* Define to 1 if you have the header file. */ -#define HAVE_LIMITS_H 1 +/* #undef HAVE_LIMITS_H */ /* Define to 1 if you have the header file. */ /* #undef HAVE_MACHINE_HAL_SYSINFO_H */ @@ -159,7 +159,7 @@ #define HAVE_MEMMOVE 1 /* Define to 1 if you have the header file. */ -#define HAVE_MEMORY_H 1 +/* #undef HAVE_MEMORY_H */ /* Define to 1 if you have the `memset' function. */ #define HAVE_MEMSET 1 @@ -225,13 +225,13 @@ /* #undef HAVE_SPAWNVPE */ /* Define to 1 if you have the header file. */ -#define HAVE_STDINT_H 1 +/* #undef HAVE_STDINT_H */ /* Define to 1 if you have the header file. */ /* #undef HAVE_STDIO_EXT_H */ /* Define to 1 if you have the header file. */ -#define HAVE_STDLIB_H 1 +/* #undef HAVE_STDLIB_H */ /* Define to 1 if you have the `stpcpy' function. */ /* #undef HAVE_STPCPY */ @@ -252,10 +252,10 @@ #define HAVE_STRERROR 1 /* Define to 1 if you have the header file. */ -#define HAVE_STRINGS_H 1 +/* #undef HAVE_STRINGS_H */ /* Define to 1 if you have the header file. */ -#define HAVE_STRING_H 1 +/* #undef HAVE_STRING_H */ /* Define to 1 if you have the `strncasecmp' function. */ #define HAVE_STRNCASECMP 1 @@ -297,16 +297,16 @@ #define HAVE_SYS_ERRLIST 1 /* Define to 1 if you have the header file. */ -#define HAVE_SYS_FILE_H 1 +/* #undef HAVE_SYS_FILE_H */ /* Define to 1 if you have the header file. */ -#define HAVE_SYS_MMAN_H 1 +/* #undef HAVE_SYS_MMAN_H */ /* Define if you have the sys_nerr variable. */ #define HAVE_SYS_NERR 1 /* Define to 1 if you have the header file. */ -#define HAVE_SYS_PARAM_H 1 +/* #undef HAVE_SYS_PARAM_H */ /* Define to 1 if you have the header file. */ /* #undef HAVE_SYS_PRCTL_H */ @@ -315,16 +315,16 @@ /* #undef HAVE_SYS_PSTAT_H */ /* Define to 1 if you have the header file. */ -#define HAVE_SYS_RESOURCE_H 1 +/* #undef HAVE_SYS_RESOURCE_H */ /* Define if you have the sys_siglist variable. */ #define HAVE_SYS_SIGLIST 1 /* Define to 1 if you have the header file. */ -#define HAVE_SYS_STAT_H 1 +/* #undef HAV
Re: gcc-trunk build error in OpenBSD on stage3
Diffs between stage2 and stage3. on configure libiberty for stage3 I see this warnings: configure:4962: checking for limits.hconfigure:4962: /home/root/gcc-build/build/gcc-trunk/./prev-gcc/xgcc-B/home/root/gcc-build/build/gcc-trunk/./prev-gcc/-B/usr/local/i686-pc-openbsd5.0/bin/-B/usr/local/i686-pc-openbsd5.0/bin/-B/usr/local/i686-pc-openbsd5.0/lib/ -isystem/usr/local/i686-pc-openbsd5.0/include -isystem/usr/local/i686-pc-openbsd5.0/sys-include -E conftest.c/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0:/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING:symbol(_ZNSt6locale5_Impl11_S_id_ctypeE) size mismatch, relink yourprogram/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0:/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING:symbol(_ZNSt6locale5_Impl13_S_id_numericE) size mismatch, relink yourprogram/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0:/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING:symbol(_ZNSt6locale5_Impl13_S_id_collateE) size mismatch, relink yourprogram/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0:/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING:symbol(_ZNSt6locale5_Impl10_S_id_timeE) size mismatch, relink yourprogram/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0:/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING:symbol(_ZNSt6locale5_Impl14_S_id_monetaryE) size mismatch, relink yourprogram/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1:/usr/lib/libstdc++.so.52.0:/home/root/gcc-build/build/gcc-trunk/./prev-gcc/cc1 : WARNING:symbol(_ZNSt6locale5_Impl14_S_id_messagesE) size mismatch, relink yourprogram I have never seen such warnings...Therefore, some tests fail. --- /home/nixman/config_correct.h +++ /home/nixman/config_incorrect.h @@ -54,7 +54,7 @@ #define HAVE_DECL_CALLOC 1 /* Define to 1 if you have the declaration of `ffs', and to 0 if you don't. */ -#define HAVE_DECL_FFS 1 +#define HAVE_DECL_FFS 0 /* Define to 1 if you have the declaration of `getenv', and to 0 if you don't. */ @@ -74,7 +74,7 @@ /* Define to 1 if you have the declaration of `sbrk', and to 0 if you don't. */ -#define HAVE_DECL_SBRK 1 +#define HAVE_DECL_SBRK 0 /* Define to 1 if you have the declaration of `snprintf', and to 0 if you don't. */ @@ -96,7 +96,7 @@ /* #undef HAVE_DUP3 */ /* Define to 1 if you have the header file. */ -#define HAVE_FCNTL_H 1 +/* #undef HAVE_FCNTL_H */ /* Define to 1 if you have the `ffs' function. */ #define HAVE_FFS 1 @@ -129,13 +129,13 @@ #define HAVE_INSQUE 1 /* Define to 1 if the system has the type `intptr_t'. */ -#define HAVE_INTPTR_T 1 +/* #undef HAVE_INTPTR_T */ /* Define to 1 if you have the header file. */ -#define HAVE_INTTYPES_H 1 +/* #undef HAVE_INTTYPES_H */ /* Define to 1 if you have the header file. */ -#define HAVE_LIMITS_H 1 +/* #undef HAVE_LIMITS_H */ /* Define to 1 if you have the header file. */ /* #undef HAVE_MACHINE_HAL_SYSINFO_H */ @@ -159,7 +159,7 @@ #define HAVE_MEMMOVE 1 /* Define to 1 if you have the header file. */ -#define HAVE_MEMORY_H 1 +/* #undef HAVE_MEMORY_H */ /* Define to 1 if you have the `memset' function. */ #define HAVE_MEMSET 1 @@ -225,13 +225,13 @@ /* #undef HAVE_SPAWNVPE */ /* Define to 1 if you have the header file. */ -#define HAVE_STDINT_H 1 +/* #undef HAVE_STDINT_H */ /* Define to 1 if you have the header file. */ /* #undef HAVE_STDIO_EXT_H */ /* Define to 1 if you have the header file. */ -#define HAVE_STDLIB_H 1 +/* #undef HAVE_STDLIB_H */ /* Define to 1 if you have the `stpcpy' function. */ /* #undef HAVE_STPCPY */ @@ -252,10 +252,10 @@ #define HAVE_STRERROR 1 /* Define to 1 if you have the header file. */ -#define HAVE_STRINGS_H 1 +/* #undef HAVE_STRINGS_H */ /* Define to 1 if you have the header file. */ -#define HAVE_STRING_H 1 +/* #undef HAVE_STRING_H */ /* Define to 1 if you have the `strncasecmp' function. */ #define HAVE_STRNCASECMP 1 @@ -297,16 +297,16 @@ #define HAVE_SYS_ERRLIST 1 /* Define to 1 if you have the header file. */ -#define HAVE_SYS_FILE_H 1 +/* #undef HAVE_SYS_FILE_H */ /* Define to 1 if you have the header file. */ -#define HAVE_SYS_MMAN_H 1 +/* #undef HAVE_SYS_MMAN_H */ /* Define if you have the sys_nerr variable. */ #define HAVE_SYS_NERR 1 /* Define to 1 if you have the header file. */ -#define HAVE_SYS_PARAM_H 1 +/* #undef HAVE_SYS_PARAM_H */ /* Define to 1 if you have the header file. */ /* #undef HAVE_SYS_PRCTL_H */ @@ -315,16 +315,16 @@ /* #undef HAVE_SYS_PSTAT_H */ /* Define to 1 if you have the header file. */ -#define HAVE_SYS_RESOURCE_H 1 +/* #undef HAVE_SYS_RESOURCE_H */ /* Define if you have the sys_siglist variable. */ #define HAVE_SYS_SIGLIST 1 /* Define to 1 if you have the header file. */ -#define HAVE_SYS_STAT_H 1 +/* #undef HAVE_SYS_STAT_H */ /* Define t
Re: transactional-memory status
On Mon, Nov 7, 2011 at 9:58 PM, Aldy Hernandez wrote: > Dear Release Managers... > > We're pretty much done with the merge blockers, and even suggestions that > weren't blockers :). The only outstanding patch review is a cleanup by > Richard Henderson that is waiting for Richi's review here: > > http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01033.html > > I am still testing some whitespace changes, but I'm fairly confident in my > ability to hit tab and space bar. > > Is there anything else you require of me? > > Ideally I'd like a slush, if the merge gets approved. I would do one last > trunk->branch, test, apply the global diff to trunk, and ask for a slush > while I commit. This is, assuming the merge is authorized. I could also > post the last diff before the commit, if it is necessary. > > What do you guys think? I suppose we can freeze for the TM merge once we leave stage1 (thus, in a few hours). If you are ready by then, of course, and the tree isn't too broken. Richard.
Re: transactional-memory status
I suppose we can freeze for the TM merge once we leave stage1 (thus, in a few hours). If you are ready by then, of course, and the tree isn't too broken. Richard. Fine by me. In the meantime we will stabilize things on the branch, merge from trunk, run tests, and have a patch ready to be applied to the trunk once I get the go-ahead by you. Thank you guys for your diligent reviews.
[trans-mem] merge from mainline at revision 181122
No anomalies. No regressions. I will now post the full patchset I would like to post to trunk.
powerpc rs6000_explicit_options change help request
Hi,
powerpc-rtems does not compile on the head due
to what appear to be changes in the way CPU
features are represented for the arguments.
The compilation error is:
/users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c -o rs6000.o
/users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c: In function
‘rs6000_option_override_internal’:
/users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c:2826:3: error:
‘rs6000_explicit_options’ undeclared (first use in this function)
/users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c:2826:3: note:
each undeclared identifier is reported only once for each function it
appears in
At top level:
The code is in rtems.h is currently:
if (TARGET_E500) \
{ \
if (TARGET_HARD_FLOAT && !rs6000_explicit_options.float_gprs) \
rs6000_float_gprs = 1; \
if (rs6000_float_gprs != 0 && !rs6000_explicit_options.spe) \
rs6000_spe = 1; \
if (rs6000_spe && !rs6000_explicit_options.spe_abi) \
rs6000_spe_abi = 1; \
} \
I think that changes to something like:
if (TARGET_E500) \
{ \
if (!global_options_set.x_rs6000_float_gprs) \
rs6000_float_gprs = 1; \
if (!global_options_set.x_rs6000_spe) \
rs6000_spe = 1; \
if (!global_options_set.x_rs6000_spe_abi) \
rs6000_spe_abi = 1; \
} \
That compiles but I wanted a sanity check that it is the right
transformation.
Thanks.
--joel sherrill
Re: powerpc rs6000_explicit_options change help request
On 11/08/2011 04:44 AM, Joel Sherrill wrote:
Hi,
powerpc-rtems does not compile on the head due
to what appear to be changes in the way CPU
features are represented for the arguments.
The compilation error is:
/users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c -o rs6000.o
/users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c: In function
‘rs6000_option_override_internal’:
/users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c:2826:3: error:
‘rs6000_explicit_options’ undeclared (first use in this function)
/users/joel/test-gcc/gcc-svn/gcc/config/rs6000/rs6000.c:2826:3: note:
each undeclared identifier is reported only once for each function it
appears in
At top level:
The code is in rtems.h is currently:
if (TARGET_E500) \
{ \
if (TARGET_HARD_FLOAT && !rs6000_explicit_options.float_gprs) \
rs6000_float_gprs = 1; \
if (rs6000_float_gprs != 0 && !rs6000_explicit_options.spe) \
rs6000_spe = 1; \
if (rs6000_spe && !rs6000_explicit_options.spe_abi) \
rs6000_spe_abi = 1; \
} \
I think that changes to something like:
if (TARGET_E500) \
{ \
if (!global_options_set.x_rs6000_float_gprs) \
rs6000_float_gprs = 1; \
if (!global_options_set.x_rs6000_spe) \
rs6000_spe = 1; \
if (!global_options_set.x_rs6000_spe_abi) \
rs6000_spe_abi = 1; \
} \
That compiles but I wanted a sanity check that it is the right
transformation.
I am not sure, either, but your code matches what other files being
found in GCC trunk.
I so far have been experimenting with a less intrusive patch:
diff --git a/gcc/config/rs6000/rtems.h b/gcc/config/rs6000/rtems.h
index 2c0c73b..6c36e94 100644
--- a/gcc/config/rs6000/rtems.h
+++ b/gcc/config/rs6000/rtems.h
@@ -61,11 +61,11 @@
do { \
if (TARGET_E500) \
{
\
-if (TARGET_HARD_FLOAT && !rs6000_explicit_options.float_gprs) \
+if (TARGET_HARD_FLOAT &&
!global_options_set.x_rs6000_float_gprs) \
rs6000_float_gprs = 1; \
-if (rs6000_float_gprs != 0 && !rs6000_explicit_options.spe)\
+if (rs6000_float_gprs != 0 && !global_options_set.x_rs6000_spe)
\
rs6000_spe = 1; \
-if (rs6000_spe && !rs6000_explicit_options.spe_abi)\
+if (rs6000_spe && !global_options_set.x_rs6000_spe_abi)
\
rs6000_spe_abi = 1; \
}
\
} while(0)
Re: [C++11] Reclaiming fixed-point suffixes for user-defined literals.
On Sun, 6 Nov 2011, Joern Rennecke wrote:
> Quoting David Brown :
>
> > Take an example using a processor I know well, the AVR (it is an 8-bit
> > device, which is a little unusual for gcc). It has an instruction will
> > multiply two "1.7" signed 8-bit integers to get a single 1.15 signed
> > 16-bit integer - basically combining an 8-bit x 8-bit to 16-bit
> > multiply with a left shift. So to do a "signed short _Fract" multiply,
> > you have a single instruction and discard the least significant byte.
> >
> > Simulating the same operation in generic C would be something like :
> >
> > int8_t multShortFract(int8_t a, int8_t b) {
> > int16_t c = (int16_t) a * b;
> > return (c >> 7);
> > }
>
> If you can make up your mind if the result is 8 or 16 bit, generating the
> instruction should be standard fare for the combiner pass.
Looks like a pretty typical Q7 (or Q1.7) multiplication to me
unless I miss something... Would be a nice thing to have those
Q1. formats as native GCC-extension types including
vectorized versions. No, not planning it.
And having intermediate calculations in a wider mode does not
constituate lack of making ones mind up. :)
Though I believe that cast of "a" is ineffective, IIUC.
brgds, H-P
