[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot med.uc.edu --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Andrew Pinski from comment #3) Still does not matter, the compiler is broken and should be reported to Apple. The time for work around in broken compilers is so 90s and really should not be done. This is clang being broken and really should be fixed there instead. Is the object here to burn all bridges with the darwin target and leave those users only the option of using llvm based compilers as of gcc 4.10? While I realize you are all frustrated with the abandonment of post-GPLv2 tools in darwin., this action simply makes it extremely easy for Apple to depreciate their ancient gas assembler in the next Xcode for darwin14 since Apple can rightly say that FSF gcc no longer bootstraps on darwin anyway. I am certain that gas will be depreciated from some future darwin but hopefully will be replaced by a stand-alone assembler based on the clang built-in assembler. However, if FSF gcc starts to get overly self-self-rightous about the compiler details of clang, we might as well fold up our tents on the darwin target. ps Be careful what you wish for. I just updated the llvm34-3.4.1-0e package in fink to use the openmp svn trunk and a back port of the current clang-omp github based on clang 3.4. The resulting clang/clang++ compilers have excellent OpenMP performance defaulted to -fopenmp as -liomp5 rather than -lgomp. http://fink.9193.n7.nabble.com/llvm34-3-4-1-0e-and-OpenMP3-1-Validation-tt46118.html While you are still lucky that there has been little effort on a fortran llvm-based compiler, the rest is a work in rapid progress. So go ahead and dismiss that user base if that is what you desire.
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 --- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu --- I would also add that you are playing with fire here. Currently no company has a motivation to expend money or resources for fortran development on llvm as long as FSF gcc is buildable. If you start removing competing compilers from bootstrapping FSF gcc, it is much more likely that someone will fund such a llvm-based fortran compiler project. You may get some short-term satisfaction from walling off FSF-gcc from clang, the long-term outcome for the FSF gcc project might not be so happy.
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 --- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Andrew Pinski from comment #8) Is the object here to burn all bridges with the darwin target and leave those users only the option of using llvm based compilers as of gcc 4.10? Well they burned a bridge with saying to the user of their front-end they support GNU C when they do not. Well it is kind of late in the game to decide that this is a show-stopper for supporting any target which uses clang as the system compiler. At this point closing bug reports and refusing to even discuss a simple workaround via preprocessor statements in FSF gcc bugzilla just looks petty.
[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu --- Created attachment 31452 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31452action=edit assembly file for gcc.dg/atomic/c11-atomic-exec-5.c -O0 on darwin12
[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305 --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu --- Created attachment 31451 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31451action=edit preprocessed source for gcc.dg/atomic/c11-atomic-exec-5.c -O0 on darwin12
[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305 --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu --- Added preprocessed source and assembly file generated with... /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131216/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libatomic/ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libatomic/.libs -latomic -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -std=c11 -pedantic-errors -pthread -D_POSIX_C_SOURCE=200809L -lm -m32 -o ./c11-atomic-exec-5.exe --save-temps on x86_64-apple-darwin12. Can someone confirm that we have both support for floating-point exceptions and the required hook on darwin? If so, I suspect we are tickling a pthread bug on darwin.
[Bug java/59455] New: gcj ICEs at r205857 during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59455 Bug ID: 59455 Summary: gcj ICEs at r205857 during bootstrap Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu Current gcc trunk at r205857 fails to bootstrap on x86_64-apple-darwin12 using... ../gcc-4.9-20131210/configure --prefix=/sw --prefix=/sw/lib/gcc4.9 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.9/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.9 The failures occurs when the gcj built is used at... Making all in classpath Making all in lib true top_builddir=.. top_srcdir=../../../../../../gcc-4.9-20131210/libjava/classpath /bin/sh ./gen-classlist.sh standard Adding java source files from srcdir '/sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131210/libjava/classpath'. Adding java source files from VM directory /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131210/libjava Adding java source files from VM directory /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava Adding generated files in builddir '..'. make[6]: Nothing to be done for `all'. Making all in doc Making all in api make[7]: Nothing to be done for `all'. make[7]: Nothing to be done for `all-am'. Making all in external Making all in sax make[7]: Nothing to be done for `all'. Making all in w3c_dom make[7]: Nothing to be done for `all'. Making all in relaxngDatatype make[7]: Nothing to be done for `all'. Making all in jsr166 make[7]: Nothing to be done for `all'. make[7]: Nothing to be done for `all-am'. Making all in include make all-am make[7]: Nothing to be done for `all-am'. Making all in native Making all in fdlibm make[7]: Nothing to be done for `all'. Making all in jni Making all in classpath make[8]: Nothing to be done for `all'. /bin/sh ../../scripts/check_jni_methods.sh make[7]: Nothing to be done for `all-am'. Making all in resource make[6]: Nothing to be done for `all'. Making all in scripts make[6]: Nothing to be done for `all'. Making all in tools Makefile:840: warning: overriding commands for target `gjdoc' Makefile:758: warning: ignoring old commands for target `gjdoc' make all-am Makefile:840: warning: overriding commands for target `gjdoc' Makefile:758: warning: ignoring old commands for target `gjdoc' make[7]: Nothing to be done for `all-am'. true DO=all multi-do # make Making all in testsuite make[5]: Nothing to be done for `all'. /bin/sh ./libtool --tag=GCJ --mode=compile /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/gcj -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/ -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/ -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/ -B/sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/bin/ -B/sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/lib/ -isystem /sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/include -isystem /sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/sys-include -m32 -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../../gcc-4.9-20131210/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m32 -c -o java/awt/image.lo -fsource-filename=/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/classpath/lib/classes -MT java/awt/image.lo -MD -MP -MF java/awt/image.deps @java/awt/image.list libtool: compile: /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/gcj -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/ -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/ -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/ -B/sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/bin/ -B/sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/lib/ -isystem /sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/include -isystem /sw/lib/gcc4.9/x86_64-apple-darwin12.5.0/sys-include -m32 -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../../gcc-4.9-20131210/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m32 -c -fsource-filename=/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/classpath/lib/classes -MT java/awt/image.lo -MD -MP -MF java/awt/image.deps @java/awt/image.list -fno-common -o java/awt/.libs/image.o /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131210/libjava/classpath/java/awt/image/SinglePixelPackedSampleModel.java: In class 'java.awt.image.SinglePixelPackedSampleModel': /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu --- /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/jc1 /var/tmp//ccSlyCZfjx -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase ccSlyCZfjx -mmacosx-version-min=10.8.5 -m32 -mtune=generic -auxbase-strip java/awt/.libs/image.o -g -O2 -Wno-deprecated -version -ffilelist-file -ffloat-store -fomit-frame-pointer -fencoding=UTF-8 -fbootstrap-classes -fsource-filename=/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libjava/classpath/lib/classes -fno-common -fbootclasspath=./:../../../../gcc-4.9-20131210/libjava/classpath/lib/ -faux-classpath ccSlyCZfjx.zip -MD_ -MT java/awt/image.lo -MF java/awt/image.deps -o ccSlyCZfjx.s
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Jack Howarth from comment #3) /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/jc1 /var/tmp//ccSlyCZfjx -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions -fkeep-inline-functions -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase ccSlyCZfjx -mmacosx-version-min=10.8.5 -m32 -mtune=generic -auxbase-strip java/awt/.libs/image.o -g -O2 -Wno-deprecated -version -ffilelist-file -ffloat-store -fomit-frame-pointer -fencoding=UTF-8 -fbootstrap-classes -fsource-filename=/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64- apple-darwin12.5.0/i386/libjava/classpath/lib/classes -fno-common -fbootclasspath=./:../../../../gcc-4.9-20131210/libjava/classpath/lib/ -faux-classpath ccSlyCZfjx.zip -MD_ -MT java/awt/image.lo -MF java/awt/image.deps -o ccSlyCZfjx.s opps, that actually was -mtune=core2 but -mtune=generic also segfaults jc1.
[Bug sanitizer/59456] New: libsanitizer can't bootstrap on darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59456 Bug ID: 59456 Summary: libsanitizer can't bootstrap on darwin10 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org The bootstrap of current gcc trunk on x86_64-apple-darwin10 fails with... /bin/sh ../libtool --tag=CXX --mode=compile /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs -B/sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/bin/ -B/sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/lib/ -isystem /sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/include -isystem /sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/sys-include-D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../gcc-4.9-20131210/libsanitizer/sanitizer_common -I ../../../../gcc-4.9-20131210/libsanitizer/include -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-apple-darwin10.8.0 -I../../../../gcc-4.9-20131210/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -MT sanitizer_platform_limits_posix.lo -MD -MP -MF .deps/sanitizer_platform_limits_posix.Tpo -c -o sanitizer_platform_limits_posix.lo ../../../../gcc-4.9-20131210/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc libtool: compile: /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libstdc++-v3/src -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin10.8.0/libstdc++-v3/libsupc++/.libs -B/sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/bin/ -B/sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/lib/ -isystem /sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/include -isystem /sw/lib/gcc4.9/x86_64-apple-darwin10.8.0/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I. -I../../../../gcc-4.9-20131210/libsanitizer/sanitizer_common -I ../../../../gcc-4.9-20131210/libsanitizer/include -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-apple-darwin10.8.0 -I../../../../gcc-4.9-20131210/libsanitizer/../libstdc++-v3/libsupc++ -g -O2 -MT sanitizer_platform_limits_posix.lo -MD -MP -MF .deps/sanitizer_platform_limits_posix.Tpo -c ../../../../gcc-4.9-20131210/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc -fno-common -DPIC -o .libs/sanitizer_platform_limits_posix.o ../../../../gcc-4.9-20131210/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:763:39: error: ‘EOWNERDEAD’ was not declared in this scope extern const int errno_EOWNERDEAD = EOWNERDEAD; ^ make[4]: *** [sanitizer_platform_limits_posix.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all-stage1-target-libsanitizer] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 using Xcode 4.2 and... ../gcc-4.9-20131210/configure --prefix=/sw --prefix=/sw/lib/gcc4.9 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.9/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.9
[Bug tree-optimization/59445] [4.9 Regression] ICE in add_old_iv_candidates, at tree-ssa-loop-ivopts.c:2541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59445 --- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu --- Added Jeff Law since he reviewed and approved the offending patch.
[Bug sanitizer/59369] New: c-c++-common/asan/pr59063-[1,2].c fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369 Bug ID: 59369 Summary: c-c++-common/asan/pr59063-[1,2].c fails on darwin Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org The new c-c++-common/asan/pr59063-1.c and c-c++-common/asan/pr59063-2.c test cases fail at all optimization levels on x86_64-apple-darwin13 due to the absence of monotonic clock support or librt on darwin. The failures are of the form... Executing on host: /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/ -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -fdiagnostics-color=never -O0-lm -m32 -o ./pr59063-1.exe(timeout = 300) spawn /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/ -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -lm -m32 -o ./pr59063-1.exe^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:4:26: error: unknown type name 'clockid_t'^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c: In function 'main':^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:7:8: error: 'clock_gettime' undeclared (first use in this function)^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:7:8: note: each undeclared identifier is reported only once for each function it appears in^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:10:23: error: 'CLOCK_MONOTONIC' undeclared (first use in this function)^M compiler exited with status 1 output is: /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:4:26: error: unknown type name 'clockid_t'^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c: In function 'main':^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:7:8: error: 'clock_gettime' undeclared (first use in this function)^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:7:8: note: each undeclared identifier is reported only once for each function it appears in^M /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:10:23: error: 'CLOCK_MONOTONIC' undeclared (first use in this function)^M FAIL: c-c++-common/asan/pr59063-1.c -O0 (test for excess errors) Excess errors: /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:4:26: error: unknown type name 'clockid_t' /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:7:8: error: 'clock_gettime' undeclared (first use in this function) /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131202/gcc/testsuite/c-c++-common/asan/pr59063-1.c:10:23: error: 'CLOCK_MONOTONIC' undeclared (first use in this function) UNRESOLVED: c-c++-common/asan/pr59063-1.c -O0 compilation failed to produce executable
[Bug sanitizer/59369] c-c++-common/asan/pr59063-[1,2].c fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369
--- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu ---
From
http://stackoverflow.com/questions/5167269/clock-gettime-alternative-in-mac-os-x,
the following code would work on darwin, but I'm not sure if the test is still
valid...
/* { dg-do run } */
#ifdef __MACH__
#define CLOCK_MONOTONIC 0
#include sys/time.h
static int weak_gettime (int clk_id, struct timespec *tp)
__attribute__((__weakref__(clock_gettime)));
int clock_gettime(int clk_id, struct timespec* tp) {
struct timeval now;
int rv = gettimeofday(now, NULL);
if (rv) return rv;
tp-tv_sec = now.tv_sec;
tp-tv_nsec = now.tv_usec * 1000;
return 0;
}
#else
#include time.h
static int weak_gettime (clockid_t clk_id, struct timespec *tp)
__attribute__((__weakref__(clock_gettime)));
#endif
int main() {
if (!clock_gettime)
return 0;
struct timespec ts;
return weak_gettime(CLOCK_MONOTONIC, ts);
}
[Bug target/59305] New: gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305 Bug ID: 59305 Summary: gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu The new gcc.dg/atomic/c11-atomic-exec-5.c execution test fails on x86_64-apple-darwin13 for all optimization levels... Running /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131126/gcc/testsuite/gcc.dg/atomic/atomic.exp ... WARNING: program timed out. FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O0 execution test WARNING: program timed out. FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O1 execution test WARNING: program timed out. FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O2 execution test WARNING: program timed out. FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O3 -fomit-frame-pointer execution test WARNING: program timed out. FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O3 -fomit-frame-pointer -funroll-loops execution test WARNING: program timed out. FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test WARNING: program timed out. FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O3 -g execution test WARNING: program timed out. FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -Os execution test WARNING: program timed out. FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O2 -flto -flto-partition=none execution test WARNING: program timed out. FAIL: gcc.dg/atomic/c11-atomic-exec-5.c -O2 -flto execution test for gcc trunk at r205392 built with... Using built-in specs. COLLECT_GCC=gcc-fsf-4.9 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.9/libexec/gcc/x86_64-apple-darwin13.0.0/4.9.0/lto-wrapper Target: x86_64-apple-darwin13.0.0 Configured with: ../gcc-4.9-20131126/configure --prefix=/sw --prefix=/sw/lib/gcc4.9 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.9/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.9 Thread model: posix gcc version 4.9.0 20131126 (experimental) (GCC)
[Bug sanitizer/59148] FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test on darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148
--- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu ---
(In reply to Alexander Potapenko from comment #3)
GCC emits calls to __strcpy_chk and __strncpy_chk in this test, which
happens because of source fortification being on by default on Darwin.
In Clang we're passing -D_FORTIFY_SOURCE=0 when compiling with
-fsanitize=address.
I've checked that manually adding -D_FORTIFY_SOURCE=0 fixes
strncpy-overflow-1.c
Jack, can you please make the changes in the GCC driver?
Yes, I can confirm that...
Index: gcc/testsuite/c-c++-common/asan/strncpy-overflow-1.c
===
--- gcc/testsuite/c-c++-common/asan/strncpy-overflow-1.c(revision 205290)
+++ gcc/testsuite/c-c++-common/asan/strncpy-overflow-1.c(working copy)
@@ -1,5 +1,5 @@
/* { dg-do run } */
-/* { dg-options -fno-builtin-malloc -fno-builtin-strncpy } */
+/* { dg-options -D_FORTIFY_SOURCE=0 -fno-builtin-malloc -fno-builtin-strncpy
} */
/* { dg-shouldfail asan } */
#include string.h
suppresses the problem. I can also confirm with current llvm/compiler-rt/clang
3.4 branch that...
/sw/opt/llvm-3.4/bin/clang -fsanitize=address -g -fdiagnostics-color=never -O0
-fno-builtin-malloc -fno-builtin-strncpy -lm -m64 -D_FORTIFY_SOURCE=2 -o
./strncpy-overflow-1.exe strncpy-overflow-1.c
also produces a binary that 'fails' by 'passing'.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #22 from Jack Howarth howarth at nitro dot med.uc.edu --- Verified as fixed at r204847 on x86_64-apple-darwin13.
[Bug sanitizer/59148] New: FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test on darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148 Bug ID: 59148 Summary: FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test on darwin13 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org At r204847, on x86_64-apple-darwin13, the following regressions remain... === gcc tests === Running target unix/-m32 FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test === gcc Summary for unix/-m32 === # of expected passes324 # of unexpected failures1 # of unsupported tests101 Running target unix/-m64 FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test === gcc Summary for unix/-m64 === # of expected passes324 # of unexpected failures1 # of unsupported tests101 === gcc Summary === # of expected passes648 # of unexpected failures2 # of unsupported tests202 /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc version 4.9.0 20131115 (experimental) (GCC) Compiler version: 4.9.0 20131115 (experimental) (GCC) Platform: x86_64-apple-darwin13.0.0 configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.9 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.9/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.9 The failures appear as... Executing on host: /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131115/gcc/testsuite/c-c++-common/asan/strncpy-overflow-1.c -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -fno-builtin-malloc -fno-builtin-strncpy -lm -m32 -o ./strncpy-overflow-1.exe(timeout = 300) spawn /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131115/gcc/testsuite/c-c++-common/asan/strncpy-overflow-1.c -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -fno-builtin-malloc -fno-builtin-strncpy -lm -m32 -o ./strncpy-overflow-1.exe^M PASS: c-c++-common/asan/strncpy-overflow-1.c -O0 (test for excess errors) Setting LD_LIBRARY_PATH to :/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc:/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/.libs::/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc:/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/.libs:/usr/local/NMRPipe/nmrbin.mac/lib spawn [open ...]^M FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test If I compile the failing test case with... /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131115/gcc/testsuite/c-c++-common/asan/strncpy-overflow-1.c -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -fno-builtin-malloc -fno-builtin-strncpy -lm -m32 -mmacosx-version-min=10.8 -o ./strncpy-overflow-1.exe it still 'FAILS' by passing, but if I move that strncpy-overflow-1.exe binary to a x86_64-apple-darwin12 box with the same build of gcc trunk on the x86_64-apple-darwin12 target, it works as expected... % ./strncpy-overflow-1.exe = ==16663==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x01c00759 at pc 0xd501d bp 0xbff428a8 sp 0xbff42488 WRITE of size 10 at 0x01c00759 thread T0 #0 0xd501c (/sw/lib/gcc4.9/lib/i386/libasan.1.dylib+0x1101c) #1 0xbed41 (/Users/howarth/./strncpy-overflow-1.exe+0x1d41) #2 0x99852724 (/usr/lib/system/libdyld.dylib+0x2724) #3 0x0
[Bug sanitizer/59148] FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test on darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59148 --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu --- Also confirmed that if you compile the failing test case using current llvm/clang svn with... /sw/opt/llvm-3.4/bin/clang -fsanitize=address -g -fdiagnostics-color=never -O0 -fno-builtin-malloc -fno-builtin-strncpy -lm -m32 -o ./strncpy-overflow-1.exe strncpy-overflow-1.c or /sw/opt/llvm-3.4/bin/clang -fsanitize=address -g -fdiagnostics-color=never -O0 -fno-builtin-malloc -fno-builtin-strncpy -lm -m64 -o ./strncpy-overflow-1.exe strncpy-overflow-1.c that the test case fails as expected.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Alexander Potapenko from comment #8) Clang's libclang_rt.asan_osx_dynamic.dylib depends on the Foundation framework. When I remove that dependency, ASanified programs crash on the same env_ptr assertion. Should we just add a CoreFoundation linkage to the creation of libasan.1.dylib in FSF gcc instead?
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Alexander Potapenko from comment #10) This might help, but we don't actually need that dependency. Instead libsanitizer should be updated to r194573. Okay, I assume the missing linkage should be a trivial change like... Index: libsanitizer/asan/Makefile.am === --- libsanitizer/asan/Makefile.am(revision 204618) +++ libsanitizer/asan/Makefile.am(working copy) @@ -43,7 +43,11 @@ libasan_la_LIBADD = $(top_builddir)/sani endif libasan_la_LIBADD += $(LIBSTDCXX_RAW_CXX_LDFLAGS) +if USING_MAC_INTERPOSE +libasan_la_LDFLAGS = -framework CoreFoundation -version-info `grep -v '^\#' $(srcdir)/libtool-version` -lpthread -ldl +else libasan_la_LDFLAGS = -version-info `grep -v '^\#' $(srcdir)/libtool-version` -lpthread -ldl +endif libasan_preinit.o: asan_preinit.o cp $ $@
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #13 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Alexander Potapenko from comment #12) That was Foundation, not sure if CoreFoundation also works. Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at r204750 suppresses all of the failures in asan.exp on x86_64-apple-darwin12. Retesting with -Wl,-framework,Foundation.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #15 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Alexander Potapenko from comment #14) I think one of the frameworks depends on another one, please make sure to pick the latter one if that's true. Also add a comment denoting this is a dirty workaround. On Nov 13, 2013 9:38 PM, howarth at nitro dot med.uc.edu gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #13 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Alexander Potapenko from comment #12) That was Foundation, not sure if CoreFoundation also works. Linking libasan against -Wl,-framework,CoreFoundation for gcc trunk at r204750 suppresses all of the failures in asan.exp on x86_64-apple-darwin12. Retesting with -Wl,-framework,Foundation. -- You are receiving this mail because: You are on the CC list for the bug. The Foundation framework is already linked against the CoreFoundation framework. I've confirmed that linking libasan against -Wl,-framework,Foundation alone (as is done by llvm) is sufficient to suppress the asan.exp failures. This change will duplicate the linkage used by llvm for the asan shared library. Posted proposed patch at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01499.html,
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #17 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Alexander Potapenko from comment #16) I've actually removed the Foundation linkage from LLVM today. Unfortunately, that is impossible to test here. A remerge of llvm libsanitizer at 194597 with gcc trunk at r204752 bootstraps on x86_64-apple-darwin12 but shows lots of new test suite failures in asan.exp... FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern test, is dyld: Symbol not found: __ZN11__sanitizer10Symbolizer21symbolizer_allocator_E Referenced from: /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libsanitizer/asan/.libs/libasan.1.dylib Expected in: flat namespace in /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin12.5.0/i386/libsanitizer/asan/.libs/libasan.1.dylib , should match READ of size 1 at 0x[0-9a-f]+ thread T0.*( | )#0 0x[0-9a-f]+ (in _*main ([^ ]*global-overflow-1.c:20|[^ ]*:0)|[(])[^ ]*( | ).*0x[0-9a-f]+ is located 0 bytes to the right of global variable.*YYY[^ ]* of size 10[^ ]*( | ) Shouldn't llvm's libsanitizer be better synced with FSF gcc's at this point?
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #18 from Jack Howarth howarth at nitro dot med.uc.edu --- Created attachment 31212 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31212action=edit fix from llvm svn
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994
--- Comment #19 from Jack Howarth howarth at nitro dot med.uc.edu ---
(In reply to Jack Howarth from comment #18)
Created attachment 31212 [details]
fix from llvm svn
The fix from llvm svn applied to gcc trunk at r204752 produces...
Native configuration is x86_64-apple-darwin12.5.0
=== g++ tests ===
Running target unix/-m32
=== g++ Summary for unix/-m32 ===
# of expected passes481
# of unsupported tests132
Running target unix/-m64
=== g++ Summary for unix/-m64 ===
# of expected passes481
# of unsupported tests132
=== g++ Summary ===
# of expected passes962
# of unsupported tests264
/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++
version 4.9.0 20131113 (experimental) (GCC)
=== gcc tests ===
Running target unix/-m32
=== gcc Summary for unix/-m32 ===
# of expected passes326
# of unsupported tests101
Running target unix/-m64
=== gcc Summary for unix/-m64 ===
# of expected passes326
# of unsupported tests101
=== gcc Summary ===
# of expected passes652
# of unsupported tests202
/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc version 4.9.0
20131113 (experimental) (GCC)
Compiler version: 4.9.0 20131113 (experimental) (GCC)
Platform: x86_64-apple-darwin12.5.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.9 --mandir=/sw/share/man
--infodir=/sw/lib/gcc4.9/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.9
for make -k check RUNTESTFLAGS=asan.exp --target_board=unix'{-m32,-m64}'
[Bug other/49892] Error in configure test xgcc in x86_64-apple-darwin11.0.0/libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49892 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Andrew Pinski from comment #3) Bug in the compiler originally used so closing as invalid. Just to note that Apple finally back ported the llvm-gcc bug fix in Xcode 4.6.1 or later upon their switch from llvm-gcc to clang as the default compiler.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu --- Current llvm trunk is broken at the moment on darwin, but using a build from Oct 29th, I have no issues with the failing test case under clang... % /sw/opt/llvm-3.4/bin/clang -O1 -fsanitize=address -fno-builtin-memset -g -fdiagnostics-color=never -O0 -m64 global-overflow-1.c % ./a.out = ==81836==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000103d991ea at pc 0x103d98b76 bp 0x7fff5be686d0 sp 0x7fff5be686c8 READ of size 1 at 0x000103d991ea thread T0 ==81836==WARNING: Trying to symbolize code, but external symbolizer is not initialized! #0 0x103d98b75 (/Users/howarth/./a.out+0x11b75) #1 0x7fff8a4237e0 (/usr/lib/system/libdyld.dylib+0x27e0) #2 0x0 0x000103d991ea is located 54 bytes to the left of global variable 'main.ZZZ' from 'global-overflow-1.c' (0x103d99220) of size 10 0x000103d991ea is located 0 bytes to the right of global variable 'main.YYY' from 'global-overflow-1.c' (0x103d991e0) of size 10 SUMMARY: AddressSanitizer: global-buffer-overflow ??:0 ?? Shadow bytes around the buggy address: 0x1000207b31e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000207b31f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000207b3200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000207b3210: 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 0x1000207b3220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =0x1000207b3230: 00 00 00 00 00 02 f9 f9 f9 f9 f9 f9 00[02]f9 f9 0x1000207b3240: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00 0x1000207b3250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000207b3260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000207b3270: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000207b3280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone:fb Freed heap region: fd Stack left redzone:f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return:f5 Stack use after scope: f8 Global redzone:f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==81836==ABORTING
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Jack Howarth from comment #4) This was a test of recent clang's -fsanitize=address on x86_64-apple-darwin12.
[Bug sanitizer/58994] asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu --- On x86_64-apple-darwin11, at r204551, I only see the single failure of… FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test at both -m32 and -m64. More interestingly, if I compile the -m64 test case… /sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131107/gcc/testsuite/c-c++-common/asan/global-overflow-1.c -B/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/./libsanitizer/asan/ -L/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/x86_64-apple-darwin11.4.2/./libsanitizer/asan/.libs -fsanitize=address -g -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -fno-builtin-memset -lm -m64 -o ./global-overflow-1.exe , place it in the same directory as the libasan.1.dylib, libgcc_s.1.dylib and libstdc++.6.dylib shared libraries and execute… # setenv DYLD_LIBRARY_PATH . # ./global-overflow-1.exe = ==64301==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000102eaf1ea at pc 0x102eaed1c bp 0x7fff62aad740 sp 0x7fff62aad738 READ of size 1 at 0x000102eaf1ea thread T0 #0 0x102eaed1b (/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/testsuite/gcc/temp/./global-overflow-1.exe+0x10d1b) #1 0x102eaec7f (/sw/src/fink.build/gcc49-4.9.0-1000/darwin_objdir/gcc/testsuite/gcc/temp/./global-overflow-1.exe+0x10c7f) #2 0x0 0x000102eaf1ea is located 0 bytes to the right of global variable 'YYY' from '/sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131107/gcc/testsuite/c-c++-common/asan/global-overflow-1.c' (0x102eaf1e0) of size 10 0x000102eaf1ea is located 54 bytes to the left of global variable 'ZZZ' from '/sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20131107/gcc/testsuite/c-c++-common/asan/global-overflow-1.c' (0x102eaf220) of size 10 Shadow bytes around the buggy address: 0x1000205d5de0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000205d5df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000205d5e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000205d5e10: 04 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00 0x1000205d5e20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =0x1000205d5e30: 00 00 00 00 00 02 f9 f9 f9 f9 f9 f9 00[02]f9 f9 0x1000205d5e40: f9 f9 f9 f9 00 02 f9 f9 f9 f9 f9 f9 00 00 00 00 0x1000205d5e50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000205d5e60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000205d5e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x1000205d5e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone:fb Freed heap region: fd Stack left redzone:f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return:f5 Stack use after scope: f8 Global redzone:f9 Global init order: f6 Poisoned by user: f7 ASan internal: fe ==64301==ABORTING it works as expected on darwin11. If I move this directory of files built under darwin11 to a darwin12 machine, the same binaries produce the failure… % setenv DYLD_LIBRARY_PATH . % ./global-overflow-1.exe ==65680==AddressSanitizer CHECK failed: ../../../../gcc-4.9-20131107/libsanitizer/sanitizer_common/sanitizer_mac.cc:146 ((env_ptr)) != (0) (0x0, 0x0) My initial guess would be that the stricter ASLR could be in play but compiling the test case with -Wl,-no_pie doesn't suppress the error on darwin12/13.
[Bug sanitizer/58994] New: asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58994 Bug ID: 58994 Summary: asan.exp regressions on x86_64 darwin at -m64 but not -m32 at r204372 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org With the remerge of libsanitizer, the following test cases fail on x86_64-apple-darwin12 at -m64 but not at -m32 (which shows no regressions)… Native configuration is x86_64-apple-darwin12.5.0 === g++ tests === Running target unix/-m32 === g++ Summary for unix/-m32 === # of expected passes473 # of unsupported tests132 Running target unix/-m64 FAIL: c-c++-common/asan/global-overflow-1.c -O0 execution test FAIL: c-c++-common/asan/global-overflow-1.c -O1 execution test FAIL: c-c++-common/asan/global-overflow-1.c -O2 execution test FAIL: c-c++-common/asan/global-overflow-1.c -O3 -fomit-frame-pointer execution test FAIL: c-c++-common/asan/global-overflow-1.c -O3 -g execution test FAIL: c-c++-common/asan/global-overflow-1.c -Os execution test FAIL: c-c++-common/asan/global-overflow-1.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/global-overflow-1.c -O2 -flto execution test FAIL: c-c++-common/asan/heap-overflow-1.c -O0 execution test FAIL: c-c++-common/asan/heap-overflow-1.c -O1 execution test FAIL: c-c++-common/asan/heap-overflow-1.c -O2 execution test FAIL: c-c++-common/asan/heap-overflow-1.c -O3 -fomit-frame-pointer execution test FAIL: c-c++-common/asan/heap-overflow-1.c -O3 -g execution test FAIL: c-c++-common/asan/heap-overflow-1.c -Os execution test FAIL: c-c++-common/asan/heap-overflow-1.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/heap-overflow-1.c -O2 -flto execution test FAIL: c-c++-common/asan/memcmp-1.c -O0 execution test FAIL: c-c++-common/asan/memcmp-1.c -O1 execution test FAIL: c-c++-common/asan/memcmp-1.c -O2 execution test FAIL: c-c++-common/asan/memcmp-1.c -O3 -fomit-frame-pointer execution test FAIL: c-c++-common/asan/memcmp-1.c -O3 -g execution test FAIL: c-c++-common/asan/memcmp-1.c -Os execution test FAIL: c-c++-common/asan/memcmp-1.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/memcmp-1.c -O2 -flto execution test FAIL: c-c++-common/asan/null-deref-1.c -O0 execution test FAIL: c-c++-common/asan/null-deref-1.c -O1 execution test FAIL: c-c++-common/asan/null-deref-1.c -O2 execution test FAIL: c-c++-common/asan/null-deref-1.c -O3 -fomit-frame-pointer execution test FAIL: c-c++-common/asan/null-deref-1.c -O3 -g execution test FAIL: c-c++-common/asan/null-deref-1.c -Os execution test FAIL: c-c++-common/asan/null-deref-1.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/null-deref-1.c -O2 -flto execution test FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O0 execution test FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O1 execution test FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O2 execution test FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O3 -fomit-frame-pointer execution test FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O3 -g execution test FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -Os execution test FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/sanity-check-pure-c-1.c -O2 -flto execution test FAIL: c-c++-common/asan/sleep-before-dying-1.c -O2 execution test FAIL: c-c++-common/asan/sleep-before-dying-1.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/sleep-before-dying-1.c -O2 -flto execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O0 execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O1 execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O2 execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O3 -fomit-frame-pointer execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O3 -g execution test FAIL: c-c++-common/asan/stack-overflow-1.c -Os execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/stack-overflow-1.c -O2 -flto execution test FAIL: c-c++-common/asan/strip-path-prefix-1.c -O2 execution test FAIL: c-c++-common/asan/strip-path-prefix-1.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/strip-path-prefix-1.c -O2 -flto execution test FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 execution test FAIL: c-c++-common/asan/strncpy-overflow-1.c -O1 execution test FAIL: c-c++-common/asan/strncpy-overflow-1.c -O2
[Bug plugins/58445] New: dragonegg needs plugin/include/config/i386/stringop.def and plugin/include/config/i386/x86-tune.def installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58445 Bug ID: 58445 Summary: dragonegg needs plugin/include/config/i386/stringop.def and plugin/include/config/i386/x86-tune.def installed Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu Currently gcc trunk breaks the build of the dragonegg 3.4svn plugin with the error... /sw/opt/llvm-3.4/bin/clang++ -c -I/sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/include/x86 -I/sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/include/darwin -g -DENABLE_BUILD_WITH_CXX -DENABLE_LTO -I/sw/include -I/sw/opt/llvm-3.4/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-rtti -MD -MP -DIN_GCC -DLLVM_VERSION=\3.4svn\ -DTARGET_TRIPLE=\x86_64-apple-darwin12.5.0\ -DGCC_MAJOR=4 -DGCC_MINOR=9 -DGCC_MICRO=0 -I/sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/include -isystem/sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include -DENABLE_BUILD_WITH_CXX -Wall -Wextra -DENABLE_LLVM_PLUGINS -I/sw/opt/llvm-3.4/include -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wnon-virtual-dtor -O3 -DNDEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS /sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/src/Aliasing.cpp In file included from /sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/src/Aliasing.cpp:48: In file included from /sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include/tm.h:13: In file included from /sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include/options.h:8: /sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include/config/i386/i386-opts.h:37:10: fatal error: 'stringop.def' file not found #include stringop.def ^ 1 error generated. ...and if /sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include/config/i386/stringop.def is present with... /sw/opt/llvm-3.4/bin/clang++ -c -I/sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/include/x86 -I/sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/include/darwin -g -DENABLE_BUILD_WITH_CXX -DENABLE_LTO -I/sw/include -I/sw/opt/llvm-3.4/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-rtti -MD -MP -DIN_GCC -DLLVM_VERSION=\3.4svn\ -DTARGET_TRIPLE=\x86_64-apple-darwin12.5.0\ -DGCC_MAJOR=4 -DGCC_MINOR=9 -DGCC_MICRO=0 -I/sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/include -isystem/sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include -DENABLE_BUILD_WITH_CXX -Wall -Wextra -DENABLE_LLVM_PLUGINS -I/sw/opt/llvm-3.4/include -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wnon-virtual-dtor -O3 -DNDEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS /sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/src/Aliasing.cpp In file included from /sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/src/Aliasing.cpp:48: In file included from /sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include/tm.h:17: /sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include/config/i386/i386.h:270:10: fatal error: 'x86-tune.def' file not found #include x86-tune.def The new stringop.def and x86-tune.def files in gcc/config/i386 should be installed in the plugin/include/config/i386 subdirectory. The config/i386/stringop.def file was introduced with the commit... http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9b868067b84b43c4094bdbe0ff0e0285c5b63d44 and the config/i386/x86-tune.def was introduced with the commit... http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=db01d63a78959f0437107d350ed900bca8a40c08
[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Iain Sandoe from comment #10) what's the expectation/status here? I see that these test-cases still fail on x86_64-darwin12, with the latest XCode tools. These failures are still present in darwin13. Also, I see these failures are also present in current gcc trunk on x86_64-unknown-freebsd8.4 and i386-unknown-freebsd10.0. It might be interesting to find out why these fail on freebsd.
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #24 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to David Fang from comment #22) Do one of these apple libunwind sources (0.30, 0.35.1) correspond to what's bundled in libgcc_s in darwin8,9,10? http://opensource.apple.com/tarballs/libunwind/ No. The libunwind sources are the replacement compact and compatibility unwinders that Apple introduced in 10.7. You will see that the 0.30 release first appears at http://www.opensource.apple.com/release/mac-os-x-107/. Note that if you look at http://www.opensource.apple.com/source/libgcc/libgcc-13/stub.c from 10.6.8, you will see that the unwinder calls resided in libgcc_s up to 10.5 after which they were subsumed into libSystem. I am unclear if the subsumed unwinder calls in 10.6.x were based on the code from libgcc but these certainly aren't based on libunwind. Since Apple never released the source code for theses files, it is difficult to know their heritage in 10.6.x. Also see... http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025894.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-September/025898.html
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot med.uc.edu --- Comment #16 from Jack Howarth howarth at nitro dot med.uc.edu --- Trunk still ICEs on x86_64-apple-darwin12... /sw/src/fink.build/gcc49-4.9.0-1000/gcc-4.9-20130906/libobjc/sendmsg.c:848:1: internal compiler error: in check_rtl, at lra.c:2034 } ^ using... r202335 | hubicka | 2013-09-06 10:39:17 -0400 (Fri, 06 Sep 2013) | 3 lines * i386.c (ix86_hard_regno_mode_ok): AVX modes are valid only when AVX is enabled.
[Bug target/58269] [4.9 Regression] ICE when building libobjc on x86_64-apple-darwin* after revision 201915
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58269 --- Comment #20 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Iain Sandoe from comment #19) The full commit where this was added to llvm is at http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/153081 and references http://software.intel.com/en-us/intel-isa-extensions (and I assume http://download-software.intel.com/sites/default/files/319433-015.pdf).
[Bug target/44107] gcc emits frame (epilogue) info incompatible with the darwin {8,9}-unwinder,10-compacter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107 --- Comment #20 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Iain Sandoe from comment #19) Yes. It might be a more profitable use of time to work on moving from the compatibility unwinder onto the newer compact unwinder for modern darwin.
[Bug plugins/57852] New: lib/plugin-support.exp incorrectly sets PLUGINCC to compilers in prev-gcc breaks testing on lean bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57852 Bug ID: 57852 Summary: lib/plugin-support.exp incorrectly sets PLUGINCC to compilers in prev-gcc breaks testing on lean bootstrap Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu After switching my normal gcc48 packaging build to use lean bootstraps, I noticed a number of test suite failures like... FAIL: gcc.dg/plugin/selfassign.c compilation FAIL: gcc.dg/plugin/ggcplug.c compilation FAIL: gcc.dg/plugin/one_time_plugin.c compilation FAIL: gcc.dg/plugin/start_unit_plugin.c compilation FAIL: gcc.dg/plugin/finish_unit_plugin.c compilation this is due to PLUGIN_CC being set to the compilers in the prev-gcc subdirectory rather than those in the gcc subdirectory as seen from one of the failing tests.. Executing on build: /sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/./prev-gcc/xg++ -B/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc4.8/x86_64-apple-darwin13.0.0/bin/ -nostdinc++ -B/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/prev-x86_64-apple-darwin13.0.0/libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/prev-x86_64-apple-darwin13.0.0/libstdc++-v3/libsupc++/.libs -I/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/prev-x86_64-apple-darwin13.0.0/libstdc++-v3/include/x86_64-apple-darwin13.0.0 -I/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/prev-x86_64-apple-darwin13.0.0/libstdc++-v3/include -I/sw/src/fink.build/gcc48-4.8.1-1000/gcc-4.8.1/libstdc++-v3/libsupc++ -L/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/prev-x86_64-apple-darwin13.0.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/prev-x86_64-apple-darwin13.0.0/libstdc++-v3/libsupc++/.libs -g -O2 /sw/src/fink.build/gcc48-4.8.1-1000/gcc-4.8.1/gcc/testsuite/gcc.dg/plugin/selfassign.c -I. -I/sw/src/fink.build/gcc48-4.8.1-1000/gcc-4.8.1/gcc/testsuite -I/sw/src/fink.build/gcc48-4.8.1-1000/gcc-4.8.1/gcc/testsuite/../../gcc -I/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/gcc/testsuite/gcc/../../../gcc -I/sw/src/fink.build/gcc48-4.8.1-1000/gcc-4.8.1/gcc/testsuite/../../include -I/sw/src/fink.build/gcc48-4.8.1-1000/gcc-4.8.1/gcc/testsuite/../../libcpp/include -I/sw/include -I/sw/include -I/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/gcc/testsuite/gcc/../../../intl -O -DIN_GCC -fPIC -shared -undefined dynamic_lookup -o selfassign.so (timeout = 300) set_ld_library_path_env_vars: ld_library_path=:/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/gcc:/sw/src/fink.build/gcc48-4.8.1-1000/darwin_objdir/x86_64-apple-darwin13.0.0/i386/libsanitizer/asan/.libs FAIL: gcc.dg/plugin/selfassign.c compilation Please set PLUGIN_CC to the final build of the compilers in the gcc subdirectory.
[Bug target/57792] fixincludes doesn't honor the use of --with-sysroot during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Summary|--with-native-system-header |fixincludes doesn't honor |-dir confuses -isysroot |the use of --with-sysroot ||during bootstrap --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu --- The removal of the SDK from / on darwin exposes a defect in fixincludes. The fixinc.in hardcodes /usr/include without any attempt to detect if the bootstrap has been invoked with the --with-sysroot configure option. On darwin13, one currently has to hack around this defect with... perl -pi -e 's|/usr/include|`xcrun --show-sdk-path`/usr/include|g' fixincludes/fixinc.in before executing… --prefix=/sw --prefix=/sw/lib/gcc4.8 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --enable-checking=release --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk This bootstraps normally and produces a compiler with a functional -isysroot compiler option (i.e. the directory passed to -isysroot is appended to /). Some mechanism needs to be added to allow the use of --with-sysroot in the bootstrap to be detected in the fixincludes/fixinc.in shell script and, if --with-sysroot is in use, the path to the sysroot prefixed to /usr/include at… # # # # # # # # # # # # # # # # # # # # # # # Search each input directory for broken header files. # This loop ends near the end of the file. # if test $# -eq 0 then INPUTLIST=/usr/include else INPUTLIST=$@ fi
[Bug target/57792] fixincludes doesn't honor the use of --with-sysroot during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu ---
(In reply to Bruce Korb from comment #2)
Paolo did the config stuff, with Kaveh's help.
However, Jack Howarth may be in a better position to
make a patch since I do not have an Apple development
system.
I would think that we want some permutation of the following code from
gcc/configure.ac added to fixincludes/configure.ac…
AC_ARG_WITH(sysroot,
[AS_HELP_STRING([[--with-sysroot[=DIR]]],
[search for usr/lib, usr/include, et al, within DIR])],
[
case ${with_sysroot} in
yes) TARGET_SYSTEM_ROOT='${exec_prefix}/${target_noncanonical}/sys-root' ;;
*) TARGET_SYSTEM_ROOT=$with_sysroot ;;
esac
TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\$(TARGET_SYSTEM_ROOT)\'
CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
case ${TARGET_SYSTEM_ROOT} in
${test_prefix}|${test_prefix}/*|\
${test_exec_prefix}|${test_exec_prefix}/*|\
'${prefix}'|'${prefix}/'*|\
'${exec_prefix}'|'${exec_prefix}/'*)
t=$TARGET_SYSTEM_ROOT_DEFINE -DTARGET_SYSTEM_ROOT_RELOCATABLE
TARGET_SYSTEM_ROOT_DEFINE=$t
;;
esac
], [
TARGET_SYSTEM_ROOT=
TARGET_SYSTEM_ROOT_DEFINE=
CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include'
])
AC_SUBST(TARGET_SYSTEM_ROOT)
AC_SUBST(TARGET_SYSTEM_ROOT_DEFINE)
AC_SUBST(CROSS_SYSTEM_HEADER_DIR)
as well as associated changes to fixincludes/Makefile.in and
fixincludes/fixinc.in to have TARGET_SYSTEM_ROOT passed to and used by the
generated fixincludes/fixin shell script. I would be happy to test any proposed
fix along those lines (but I am unclear on how complex the additions to
fixincludes/configure.ac need to be to handle cross compiles, etc).
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Summary|fixincludes doesn't honor |toplevel configure should |the use of --with-sysroot |enable |during bootstrap|--with-sysroot=`xcrun ||--show-sdk-path` for ||darwin13 and later --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu --- Sorry for the noise. The addition of… --with-sysroot=`xcrun --show-sdk-path` in fact does allow fixincludes to find the buried usr/include. I'm not sure what other option I was passing that prevented that from working before. I have switched this PR to an enhancement request for modifying the top level configure.ac to pass… --with-sysroot=`xcrun --show-sdk-path` for darwin13 or later. I am unclear how this can be done considering that the top level configure.ac doesn't mention --with-sysroot. However I am sure we should be passing it down from there to insure that all of the other configure files get that option set.
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu ---
I am really surprised the following change if insufficient to replace manually
passing…
--with-sysroot=`xcrun --show-sdk-path`
to configure on the command line for darwin13...
Index: configure.ac
===
--- configure.ac(revision 200683)
+++ configure.ac(working copy)
@@ -2848,6 +2848,13 @@ if test x${is_cross_compiler} = xyes ; t
target_configargs=--with-cross-host=${host_noncanonical}
${target_configargs}
fi
+case ${target} in
+ x86_64-*-darwin13*)
+target_configargs=--with-sysroot=\`xcrun --show-sdk-path`\
${target_configargs}
+;;
+esac
+
+
# Default to --enable-multilib.
if test x${enable_multilib} = x ; then
target_configargs=--enable-multilib ${target_configargs}
Index: configure
===
--- configure (revision 200683)
+++ configure (working copy)
@@ -7414,6 +7414,13 @@ if test x${is_cross_compiler} = xyes ; t
target_configargs=--with-cross-host=${host_noncanonical}
${target_configargs}
fi
+case ${target} in
+ x86_64-*-darwin13*)
+target_configargs=--with-sysroot=\`xcrun --show-sdk-path`\
${target_configargs}
+;;
+esac
+
+
# Default to --enable-multilib.
if test x${enable_multilib} = x ; then
target_configargs=--enable-multilib ${target_configargs}
This patch (without explicitly passing --with-sysroot to configure) results in
the fixincludes complaining about not finding /usr/include again but the
top-level config.log shows target_configargs has
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk on it.
Should I be appending --with-sysroot=\`xcrun --show-sdk-path`\ to different
variable instead?
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 --- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu --- (In reply to Jack Howarth from comment #5) The same change of adding --with-sysroot=\`xcrun --show-sdk-path`\ to build_configargs also fails when fix_includes tries to find /usr/include. Strangely, adding --with-sysroot=\`xcrun --show-sdk-path`\ to host_configargs allows fixincludes to find the headers but then dies in stage2 with the cryptic error… Configuring stage 2 in ./intl Configuring stage 2 in ./libiberty Configuring stage 2 in ./libbacktrace Configuring stage 2 in ./libdecnumber make[4]: Nothing to be done for `all'. make[3]: Nothing to be done for `all'. configure: loading cache ../config.cache configure: loading cache ../config.cache configure: loading cache ../config.cache configure: loading cache ../config.cache configure: error: `CC' has changed since the previous run:
[Bug target/57792] toplevel configure should enable --with-sysroot=`xcrun --show-sdk-path` for darwin13 and later
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
--- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu ---
(In reply to Jack Howarth from comment #6)
My mistake in mixing host_configargs and build_configargs. The following patch
works fine…
Index: configure.ac
===
--- configure.ac(revision 200683)
+++ configure.ac(working copy)
@@ -2848,6 +2848,13 @@ if test x${is_cross_compiler} = xyes ; t
target_configargs=--with-cross-host=${host_noncanonical}
${target_configargs}
fi
+# Pass --with-sysroot on darwin without SDK in /
+case ${target} in
+ x86_64-*-darwin1[[3-9]]*)
+host_configargs=--with-sysroot=\`xcrun --show-sdk-path`\
${host_configargs}
+;;
+esac
+
# Default to --enable-multilib.
if test x${enable_multilib} = x ; then
target_configargs=--enable-multilib ${target_configargs}
[Bug target/57753] FSF gcc bootstrap needs to use xcrun to bootstrap post-darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu --- Actually, FSF gcc doesn't know about the SDKROOT path that xcrun sets. A change similar to… http://permalink.gmane.org/gmane.comp.compilers.clang.scm/56103 needs to be implemented on darwin so that FSF checks for the SDKROOT environmental and uses it to find usr/include.
[Bug target/57792] New: --with-native-system-header-dir confuses -isysroot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792 Bug ID: 57792 Summary: --with-native-system-header-dir confuses -isysroot Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu The removal of the SDK from / (i.e. no /usr/include or /System/Library/Frameworks/*.framework/Headers directories) breaks the fixincludes step of the bootstrap on darwin. The only current workaround appears to be using the --with-native-system-header-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk/usr/include however this causes -isysroot in the resulting compiler to malfunction so that… /sw/lib/gcc4.8/bin/gcc-fsf-4.8 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk himenoBMTxpa.c searches… ignoring nonexistent directory /Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk/usr/include Oddly executing the non-sensical… /sw/lib/gcc4.8/bin/gcc-fsf-4.8 -isysroot / himenoBMTxpa.c works because the search path becomes… /Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk/usr/include I assume no one ever tested --with-native-system-header-dir with -ixysroot before.
[Bug target/57753] New: FSF gcc bootstrap needs to use xcrun to bootstrap post-darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753 Bug ID: 57753 Summary: FSF gcc bootstrap needs to use xcrun to bootstrap post-darwin12 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu The WWDC What’s New in the LLVM Compiler video on https://developer.apple.com/wwdc/videos/ indicated that the SDK will be moved out of / on future releases after Mountain Lion and that the proper way to find the headers, previously in /usr/include and /System/Library/Frameworks/*.framework/Headers is to use the xcrun tool on darwin to access the compiler... xcrun provides a means to locate or invoke coexistence- and platform-aware developer tools from the com- mand-line, without requiring users to modify makefiles or otherwise take inconvenient measures to support multiple Xcode tool chains. The tool xcode-select is used to specify which installation of Xcode is used, and may be overridden by the DEVELOPER_DIR environment variable. The SDK defaults to the boot system OS SDK, and can be specified by the SDKROOT environment variable or the -sdk option (which takes precedences over SDKROOT). So the configure scripts for bootstrapping on darwin will need to be adjusted to call compilers during the build using the xcrun command... xcrun tool_name [tool_arguments] We don't need to pass '-sdk SDK' as xcrun defaults to the deployment SDK. FYI, this change can be tested on Mac OS X 10.7/10.8 using Xcode 4.6.3 by performing the following steps... sudo mv /usr/include /usr/include.off sudo mv /System/Library/Frameworks/CoreFoundation.framework/Headers /System/Library/Frameworks/CoreFoundation.framework/Headers.off Note that the CoreFoundation.framework headers are used by the libasan build on darwin.
[Bug target/57753] FSF gcc bootstrap needs to use xcrun to bootstrap post-darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu --- I should also note that removal of SDK from / isn't as bad as it sounds. In general, most builds can puzzle out the location of the necessary headers. However, FSF gcc is a complex build (especially regarding the fix includes step) and in the absence of using xrcun, something like... darwinvers=`sw_vers -productVersion | cut -d. -f1-2` if [[ $darwinvers 10.8 ]]; then if [ -d /Library/Developer/CommandLineTools ]; then configure CPPFLAGS=-O2 -g -isysroot `xcode-select --print-path`/SDKs/MacOSX$darwinvers.sdk --with-native-system-header-dir=`xcode-select --print-path`/SDKs/MacOSX$darwinvers.sdk/usr/include CXXFLAGS=-O2 -g -iframework `xcode-select --print-path`/SDKs/MacOSX$darwinvers.sdk/System/Library/Frameworks else configure CPPFLAGS=-O2 -g -isysroot `xcode-select --print-path`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX$darwinvers.sdk --with-native-system-header-dir=`xcode-select --print-path`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX$darwinvers.sdk/usr/include CXXFLAGS=-O2 -g -iframework `xcode-select --print-path`/Platforms/MacOSX.platform/Developer/SDKs/MacOSX$darwinvers.sdk/System/Library/Frameworks fi else configure fi has to be used. Note that using xrcun eliminates the need for end-user to define where the SDK resides (i.e. in Xcode.app or Command Line Tools) as well as avoiding the need to define which exact SDK release to use.
[Bug target/57753] FSF gcc bootstrap needs to use xcrun to bootstrap post-darwin12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753 --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu --- Okay, the bootstrap without headers outside of the SDK can be simplified on darwin to… ./configure -with-native-system-header-dir=`xcrun --show-sdk-path`/usr/include CXX_FOR_BUILD=xcrun g++ CC_FOR_BUILD=xcrun gcc CXXFLAGS=-O2 -g -iframework `xcrun --show-sdk-path`/System/Library/Frameworks
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #18 from Jack Howarth howarth at nitro dot med.uc.edu --- Do we have any idea why this problem is latent with --checking=release and --checking=yes but is triggered by --disable-checking?
[Bug java/57424] extra multilib subdirectory level at r199345
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57424
--- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu ---
This problem is caused by following change in gcc trunk. In gcc-4_8-branch, the
generated Makefile in darwin_objdir/x86_64-apple-darwin12.3.0/i386/libjava/gcj
has...
dbexecdir = $(libdir)/i386/gcj-4.8.1-14
where libdir is...
libdir = ${exec_prefix}/lib
whereas now in gcc trunk we have...
dbexecdir = $(toolexeclibdir)/i386/gcj-4.9.0-14
where toolexeclibdir is...
toolexeclibdir = $(libdir)/i386
hence the duplication of i386 in the path.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot med.uc.edu --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu --- Are these failures limited to 'make bootstrap-lean' on your machines? What happens if you just use 'make' without arguments.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu --- The trigger for this bug is the use of --disable-checking. The linker crash doesn't occur when --enable-checking=release or --enable-checking=yes is passed to configure instead.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu --- I've opened radar://14005298, linker crash when building FSF gcc with --disable-checking with a standalone test case of the failing linkage of cc1.
[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438 --- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu --- The darwin linker developer's analysis of the failing linkage of cc1 is below... The assertion is about the file libbackend.a(varasm.o). There are overlapping FDEs. If you run dwarfdump in verify mode, it will complain about it to:: [/tmp/newlinkerbug/lib] dwarfdump --eh-frame --verify varasm.o -- File: varasm.o (x86_64) -- Verifying EH Frame... error: FDE row for address 0x5900 is not in the FDE address range. 0x20e0: FDE length: 0x001c CIE_pointer: 0x start_addr: 0x5900 __Z24default_no_named_sectionPKcjP9tree_node range_size: 0x (end_addr = 0x5900) DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop Instructions: 0x5900: CFA=rsp+8 rip=[rsp] 1 errors found in EH frame for varasm.o (x86_64). Dumping the whole file, there is an FD for a zero length function, so two FDEs have the same function start address: 0x20e0: FDE length: 0x001c CIE_pointer: 0x start_addr: 0x5900 __Z24default_no_named_sectionPKcjP9tree_node range_size: 0x (end_addr = 0x5900) DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop DW_CFA_nop Instructions: 0x5900: CFA=rsp+8 rip=[rsp] 0x2100: FDE alength: 0x006c CIE_pointer: 0x start_addr: 0x5900 __Z24default_no_named_sectionPKcjP9tree_node range_size: 0x0154 (end_addr = 0x5a54) Instructions: 0x5900: CFA=rsp+8 rip=[rsp]
[Bug java/57424] New: extra multilib subdirectory level at r199345
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57424 Bug ID: 57424 Summary: extra multilib subdirectory level at r199345 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu At r199345, on x86_64-apple-darwin12, I am finding that installation subdirectory for the multilib of gcj-4.9.0-14 is now installed in... /sw/src/fink.build/root-gcc49-4.9.0-1000/sw/lib/gcc4.9/lib/i386/i386/ instead of the expected... /sw/src/fink.build/root-gcc49-4.9.0-1000/sw/lib/gcc4.9/lib/i386/ I assume this is unintended failout from r199221.
[Bug c++/56835] std::promise seems broken on 10.8 lion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56835 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu 2013-04-09 20:33:39 UTC --- I can't reproduce this crash with the fink build of gcc 4.8.0 on x86_64-apple-darwin12. Notice that MacPorts is building the their gcc48 package with additional change of... https://trac.macports.org/browser/trunk/dports/lang/gcc48/files/libstdc%2B%2B-configure-timespec.patch to get the _GLIBCXX_USE_CLOCK_MONOTONIC defined in config.h. This is claimed to be in order to get libstdc++ to use nanosleep. However, a different fix was checked in... r192335 | redi | 2012-10-10 19:12:10 -0400 (Wed, 10 Oct 2012) | 6 lines 2012-10-10 Jack Howarth howa...@bromo.med.uc.edu Jonathan Wakely jwakely@gmail.com * config/os/bsd/darwin/os_defines.h: Define _GLIBCXX_USE_NANOSLEEP and _GLIBCXX_USE_SCHED_YIELD. * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_TIME): Add comment. which results in nanosleep being used on darwin by default... % cd /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.3.0/libstdc++-v3/src/c++11 % nm thread.o | grep nanosleep U _nanosleep
[Bug c++/56835] std::promise seems broken on 10.8 lion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56835 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2013-04-09 22:55:27 UTC --- IMHO, this should be closed as invalid since MacPorts is applying unnecessary and invalid patches to gcc 4.8.0.
[Bug c++/56835] std::promise seems broken on 10.8 lion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56835 --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu 2013-04-09 22:57:00 UTC --- This has been filed with MacPorts as https://trac.macports.org/ticket/38732
[Bug plugins/56754] some missing plugin headers during installation in gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2013-03-28 17:47:41 UTC --- This issue blocks building dragonegg svn against FSF gcc 4.8.0... c++ -c -I/sw/src/fink.build/dragonegg-gcc48-3.3-0/dragonegg-3.3/include/x86 -I/sw/src/fink.build/dragonegg-gcc48-3.3-0/dragonegg-3.3/include/darwin -g -DENABLE_BUILD_WITH_CXX -DENABLE_LTO -I/sw/include -I/sw/opt/llvm-3.3/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-rtti -MD -MP -DIN_GCC -DLLVM_VERSION=\3.3svn\ -DTARGET_TRIPLE=\x86_64-apple-darwin12.3.0\ -DGCC_MAJOR=4 -DGCC_MINOR=8 -DGCC_MICRO=0 -I/sw/src/fink.build/dragonegg-gcc48-3.3-0/dragonegg-3.3/include -isystem/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin12.3.0/4.8.0/plugin/include -Wall -Wextra -DENABLE_LLVM_PLUGINS -I/sw/opt/llvm-3.3/include -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wnon-virtual-dtor -O3 -DNDEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS /sw/src/fink.build/dragonegg-gcc48-3.3-0/dragonegg-3.3/src/Backend.cpp /sw/src/fink.build/dragonegg-gcc48-3.3-0/dragonegg-3.3/src/Backend.cpp:83:10: fatal error: 'target.h' file not found #include target.h // For targetm. ^ 1 error generated.
[Bug other/56721] New: libffi.info installed in share/info collides with that from libffi itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56721 Bug #: 56721 Summary: libffi.info installed in share/info collides with that from libffi itself Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu The libffi in gcc 4.8.0 installs a libffi.info file in share/info which collides with that from a standalone installation of libffi. Is that intended?
[Bug other/56721] libffi.info installed in share/info collides with that from libffi itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56721 --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2013-03-25 14:24:55 UTC --- Will http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00853.html go into both gcc 4.9 and 4.8.1?
[Bug target/54407] FAIL: 30_threads/condition_variable/54185.cc execution test program timed out on powerpc-apple-darwin9 and x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54407 --- Comment #18 from Jack Howarth howarth at nitro dot med.uc.edu 2013-03-11 14:51:01 UTC --- (In reply to comment #17) Jack, I see at http://gcc.gnu.org/ml/gcc-testresults/2012-11/msg00331.html that you have tested a fix for this PR. I have tested that it skips the test on powerpc-apple-darwin9 and x86_64-apple-darwin10. Have you submitted it? I posted this patch back in Oct as... http://gcc.gnu.org/ml/libstdc++/2012-10/msg00111.html Mike wanted a comment about an associated radar which doesn't exist. As far as I know this bug was fixed in the pthread rewrites for darwin11 and later.
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu 2013-03-05 13:43:57 UTC --- This failure has re-appeared at r196444 on x86_64-apple-darwin12... FAIL: g++.dg/debug/dwarf2/thunk1.C -std=gnu++98 scan-assembler-times LFB3 5 FAIL: g++.dg/debug/dwarf2/thunk1.C -std=gnu++11 scan-assembler-times LFB3 5
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #10 from Jack Howarth howarth at nitro dot med.uc.edu 2013-03-05 13:48:03 UTC --- Created attachment 29584 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29584 m32 thunk1.s -std=gnu++98 on x86_64-apple-darwin12 at r196444 Generated with... /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/../../xg++ -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130304/gcc/testsuite/g++.dg/debug/dwarf2/thunk1.C -fno-diagnostics-show-caret -nostdinc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/include/x86_64-apple-darwin12.2.0 -I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/i386/libstdc++-v3/include -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130304/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130304/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130304/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -g -fpic -fno-dwarf2-cfi-asm -S -m32 -o thunk1.s
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu 2013-03-05 15:01:55 UTC --- (In reply to comment #11) It seems that darwin doesn't do PIC the way ELF targets do, so this test should be skipped. I also confirmed this with stock gcc trunk (to verify that it was unrelated to the proposed fix for PR target/51784 at http://gcc.gnu.org/ml/gcc-bugs/2013-02/msg00468.html).
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363
--- Comment #15 from Jack Howarth howarth at nitro dot med.uc.edu 2013-03-05
16:55:07 UTC ---
(In reply to comment #14)
(In reply to comment #13)
What is supposed to be tested? Should the whole test skipped on darwin or
only
the dg-final?
The whole test; the test is verifying that the x86 PIC thunk doesn't have
debug
info, but Darwin doesn't emit that thunk.
Any idea how to disable this on darwin? While...
// { dg-do compile { target { { i?86-*-* || x86_64-*-* } { ! *-*-darwin* } }
} }
parses in dejagnu, the required...
// { dg-do compile { target { { i?86-*-* || x86_64-*-* } { ! *-*-darwin* }
ia32 } } }
doesn't...
ERROR: g++.dg/debug/dwarf2/thunk1.C -std=gnu++98: syntax error in target
selector target i?86-*-* || x86_64-*-*! *-*-darwin*ia32 for
dg-do 2 compile { target { { i?86-*-* || x86_64-*-* } { ! *-*-darwin* } {
ia32 } } }
[Bug debug/53363] g++.dg/debug/dwarf2/thunk1.C FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53363 --- Comment #17 from Jack Howarth howarth at nitro dot med.uc.edu 2013-03-05 22:20:33 UTC --- (In reply to comment #16) If it's easier to just disable the dg-final, that's fine too. Patch posted at http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00210.html. Can you commit it?
[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #10 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-22 15:19:19 UTC --- Posted patches of remaining bootstrap fixes for gcc-4_7-branch and gcc-4_6-branch... http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01059.html http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01060.html
[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258 --- Comment #7 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-22 02:01:10 UTC --- Created attachment 29520 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29520 patch to fix gcc-4_7-branch bootstrap against texinfo 5.0 Current gcc-4_7-branch still fails to bootstrap against texinfo 5.0 due to additional instances of @itemx. The attached patch fixes these and bootstraps on x86_64-apple-darwin12.
[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258 --- Comment #8 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-22 02:03:14 UTC --- Created attachment 29521 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29521 backport of gcc-4_7-branch fixes to gcc-4_6-branch The attached patch backports the additional fixes to gcc-4_6-branch.
[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Attachment #29521|0 |1 is obsolete|| --- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-22 04:59:53 UTC --- Created attachment 29522 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29522 complete gcc-4_6-branch fixes for bootstrap against texinfo 5.0 One additional fix (present in gcc-4_7-branch and trunk) is required for bootstrapping gcc-4_6-branch against texinfo 5.0. Tested on x86_64-apple-darwin11.
[Bug sanitizer/55938] g++.dg/asan/deep-stack-uaf-1.C fails at r195092 on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55938 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-16 02:04:15 UTC --- Fixed in current gcc trunk.
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #40 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-12 14:00:15 UTC --- (In reply to comment #23) #1 afaict, the asan pass happens in the middle of the gcc optimization flow. imho it should happen as late as possible so that the instrumentation happens on fully optimized code. I can confirm this is the case from my experiments compiling xplor-nih with -fsanitize=address. This code is habitually miscompiled by gfortran at the higher optimizations levels. The addition of the -fsanitize=address flag to the build suppresses most of the xplor-nih testsuite failures indicating that it has changed the code optimization in gfortran. Is there any chance of moving the asan pass or is that definitely stage 1 material?
[Bug sanitizer/55309] gcc's address-sanitizer 66% slower than clang's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55309 --- Comment #42 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-12 14:41:56 UTC --- (In reply to comment #41) FYI, most of the codegen issues with xplor-nih compiled with gfortran can be suppressed with -fno-tree-vectorize at -O3 (hence my interest in a function libasan on darwin).
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #50 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-11 17:54:44 UTC --- (In reply to comment #47) Created attachment 29396 [details] revised patch to revert r184293 while fixing PR55693 Bootstrap regtesting underway on ppc darwin9, x86_64 darwin10 with Xcode 4.2 and x86_64 darwin12 with Xcode 4.6. Iain confirmed off-list that the proposed patch to remove the dummy function bootstraps on i686 drawin9 without regressions in the tm and libitm testsuite.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #47 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-08 14:39:11 UTC --- Created attachment 29396 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29396 revised patch to revert r184293 while fixing PR55693 Bootstrap regtesting underway on ppc darwin9, x86_64 darwin10 with Xcode 4.2 and x86_64 darwin12 with Xcode 4.6.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #48 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-08 14:40:20 UTC --- (In reply to comment #47) Created attachment 29396 [details] revised patch to revert r184293 while fixing PR55693 Bootstrap regtesting underway on ppc darwin9, x86_64 darwin10 with Xcode 4.2 and x86_64 darwin12 with Xcode 4.6. Reverting the dummy function addition to libgcc/config/darwin-crt-tm.c to be precise.
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693
--- Comment #49 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-08
18:17:50 UTC ---
The patch in comment 47 produces no regressions in gcc for...
make -k check RUNTESTFLAGS=tm.exp --target_board=unix'{-m32,-m64}'
and none in libitm for...
make -k check RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
on powerpc-apple-darwin9 with Xcode 3.1.4, x86_64-apple-darwin10 with Xcode 4.2
and x86_64-apple-darwin12 with Xcode 4.6. So it seems we may not need the dummy
functions at all.
[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #43 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-07 13:45:45 UTC --- (In reply to comment #42) On x86_64-apple-darwin12, while the proposed patch from Comment 42 bootstraps fine, it does produce a new regression at -m64... Executing on host: /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ -fno-diagnostics-show-caret -O2 -mcmodel=large -c -m64 -o pr49866.o /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130206/gcc/testsuite/gcc.target/i386/pr49866.c (timeout = 300) /var/tmp//ccgCyUt7.s:11:junk `@PLTOFF' after expression^M /var/tmp//ccgCyUt7.s:14:junk `@PLTOFF' after expression^M /var/tmp//ccgCyUt7.s:17:junk `@PLTOFF' after expression^M /var/tmp//ccgCyUt7.s:48:junk `@PLTOFF' after expression^M compiler exited with status 1 output is: /var/tmp//ccgCyUt7.s:11:junk `@PLTOFF' after expression^M /var/tmp//ccgCyUt7.s:14:junk `@PLTOFF' after expression^M /var/tmp//ccgCyUt7.s:17:junk `@PLTOFF' after expression^M /var/tmp//ccgCyUt7.s:48:junk `@PLTOFF' after expression^M FAIL: gcc.target/i386/pr49866.c (test for excess errors)
[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #44 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-07 13:49:36 UTC --- Created attachment 29385 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29385 assembly file for failing gcc.target/i386/pr49866.c compilation at -m64 Compiled with... /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/gcc/ -fno-diagnostics-show-caret -O2 -mcmodel=large -c -m64 -o pr49866.o /sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20130206/gcc/testsuite/gcc.target/i386/pr49866.c --save-temps
[Bug target/51784] PIC register not correctly preserved in nested funcs / with non-local goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51784 --- Comment #46 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-07 16:27:41 UTC --- (In reply to comment #42) Full regression test results on x86_64-apple-darwin12 are at... http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00745.html
[Bug libitm/55693] [4.8 Regression] libitm.c++/eh-1.C execution test fails on darwin from r193271
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55693 --- Comment #44 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-07 19:33:24 UTC --- Created attachment 29389 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29389 revised patch to fix darwin10 under Xcode 4.2 The attached patch removes the !defined (__MACH__) hacks from libitm/alloc_cpp.cc and libitm/eh_cpp.cc so that the symbols for _ZdlPv*, etc can be found on darwin10 with Xcode 4.2 (which doesn't set HAVE_ELF_STYLE_WEAKREF in configure but also doesn't define the weak dummy functions because of fast c++ weak-symbol coalescing). Bootstrap regression tested for tm.exp and libitm subdirectory on x86_64-apple-darwin10 with Xcode 4.2 and x86_64-apple-darwin12 with Xcode 4.6. Can someone test darwin9 and x86_64-apple-darwin10 with Xcode 3.2.6 to make sure that the linker bug mentioned in the previous patch (http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00851.html) doesn't re-appear?
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #50 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-04 17:24:40 UTC --- (In reply to comment #49) I agree with Jakub: it's better to return back to the qsort version of the patch, since it fixes ASan as well, but also provides better support for priorities in general. Posted final qsort version of the patch to gcc-patches. http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00120.html
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #47 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-03 15:16:50 UTC --- posted proposed patch and regression testresults at... http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00055.html http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00251.html
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #37 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-02
15:31:37 UTC ---
typedef struct GTY(()) ctor_record {
rtx symbol;
int priority; /* constructor priority */
int position; /* original position */
};
fails with...
../../gcc-4.8-20130201/gcc/config/darwin.c:90: parse error: expected '(', ')',
'GTY', or an identifier, have ';'
../../gcc-4.8-20130201/gcc/config/darwin.c:92: type `va_gc' previously defined
../../gcc-4.8-20130201/gcc/rtl.h:239: previously defined here
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #39 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-02 18:16:39 UTC --- While testing whether the single qsort was sufficient, the origin of the problem on darwin was clarified. In machopic_asm_out_constructor, after the vec_safe_push, the constructors are output as... new_elt.position = 0 new_elt.priority = 65535 new_elt.position = 1 new_elt.priority = 99 which my current patch reorders as... elt-position = 1 elt-priority = 99 elt-position = 0 priority = 65535 since darwin sets #undef SUPPORTS_INIT_PRIORITY #define SUPPORTS_INIT_PRIORITY 0 in gcc/config/darwin.h, all constructors are set to #define DEFAULT_INIT_PRIORITY 65535 in gcc/collect2.c. So all of the constructors emitted are actually of a 'higher' priority and that is why I had to reverse the sort on priority from what Jakub suggested in Comment 34. FYI, darwin doesn't compile code with priorities on constructors/destructors so they will always the default init priority... initpri2.C:5:38: error: constructor priorities are not supported
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #41 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-02 20:11:07 UTC --- Created attachment 29338 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29338 alternative approach of only inserting asan static constructor in front
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Attachment #29338|0 |1 is obsolete|| --- Comment #42 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-02 20:11:54 UTC --- Created attachment 29339 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29339 alternative approach of only inserting asan static constructor in front
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #43 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-02 20:19:40 UTC --- (In reply to comment #40) Actually I think we should junk sorting entirely and use the alternative approach of the patch in Comment 42. That approach should have no impact on the ordering of constructors when -fsanitize=address isn't in use. When -fsanitize=address is used, as the ctors vector is loaded up, the asan constructors will be inserted in the front of the vector.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #44 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-02 20:41:15 UTC --- (In reply to comment #40) Doesn't the test case I showed in Comment 28 qualify as working across translaional units? That test case still compiles and runs fine with -fsanitize=address using the patch from Comment 42 but is broken in stock gcc trunk.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #45 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-02 22:53:59 UTC --- (In reply to comment #40) Also the impact of the proposed patch in Comment 42 could be limited even further by using... if (flag_asan priority == 99) as the test for inserting the constructors in front of the vector queue of constructors.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
--- Comment #46 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-03
00:10:02 UTC ---
(In reply to comment #40)
Also with the patch in Comment 42, the failing test case converted into a
shared library loaded via dlopen works fine...
% cat libcov.C
struct c18 {
virtual void bar() { }
};
c18 ret;
% cat covmain_dl.C
#include stdio.h
#include stdlib.h
#include dlfcn.h
int main () {
void *lib_handle;
lib_handle = dlopen(./libcov.dylib, RTLD_LAZY);
if (!lib_handle)
{
fprintf(stderr, %s\n, dlerror());
exit(1);
}
dlclose(lib_handle);
}
% ./dist/bin/g++-fsf-4.8 -shared -fsanitize=address covmain_dl.C
% ./dist/bin/g++-fsf-4.8 -fsanitize=address covmain_dl.C
% ./a.out
%
This also works for a libcov.C compiled into a shared module loaded in
covmain_dl.C as libcov.so...
% ./dist/bin/g++-fsf-4.8 -bundle -fsanitize=address -o libcov.so libcov.C
% ./dist/bin/g++-fsf-4.8 -fsanitize=address covmain_dl.C
% a.out
%
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #31 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-01 16:46:35 UTC --- FYI, the proof of concept patch from Comment 27 produces no regressions in the testsuite on x86_64-apple-darwin12... http://gcc.gnu.org/ml/gcc-testresults/2013-02/msg00070.html
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #32 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-01 21:22:06 UTC --- Created attachment 29332 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29332 first attempt at va_gc implementation The attached patch is a first attempt at replacing the dynamic array with a va_gc vector. Unfortunately, this code only bootstraps fine as long the line... ctors-qsort (sort_by_ctor_priority); is commented out. With the qsort enabled, the bootstrap fails with... configure: error: cannot compute suffix of object files: cannot compile in the stage1-bubble. Reversing the comparison in sort_by_ctor_priority has no effect. The previous array based patch successfully used a call to... qsort(ctors, ctor_index+1, sizeof(ctor_record), compare_ctor_priority); Is the same qsort used in the vec implementation? Is there any examples for calling qsort for vectors with all four parameters?
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #33 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-01 21:45:42 UTC --- Replacing the... ctors-qsort (sort_by_ctor_priority); with... qsort(ctors, ctor_index+1, sizeof(ctor_record), sort_by_ctor_priority); appears to solve the bootstrap issues. Mike Stump suggested that we use the stable_sort from c++ to achieve the sort in one pass. Is it possible to pass a va_gc to stable_sort? In particular, how do we get first and last positions to pass as described in http://www.cplusplus.com/reference/algorithm/stable_sort/?
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #35 from Jack Howarth howarth at nitro dot med.uc.edu 2013-02-02 05:51:31 UTC --- Created attachment 29334 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29334 working va_gc implementation
[Bug bootstrap/50342] gcc/configure fails on Mac OS X Lion/Xcode 4.1 with recent GCCs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50342 --- Comment #15 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-31 21:00:22 UTC --- (In reply to comment #14) The original problem doesn't occur with gcc version 4.8.0 20130131 (experimental) [trunk revision 195611] (GCC), built with GNAT GPL 2012. Probably fixed at http://gcc.gnu.org/viewcvs?view=revisionrevision=182378.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #23 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-31 22:01:39 UTC --- Created attachment 29323 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29323 proposed patch for dynamic allocation Proposed patch for ctor reversal in a dynamic array. Still need to address the fact that rtx in coretypes.h is... struct rtx_def; typedef struct rtx_def *rtx; so I guess struct ctor_record should be saving the contents of the struct rtx_def instead.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #24 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-31 22:22:50 UTC --- Suspect we need to use... ctors[ctor_index].symbol = copy_rtx(symbol); in machopic_asm_out_constructor although I am unclear on what need need to do to release the memory for this copy in at the end of finalize_ctors.
[Bug sanitizer/55617] static constructors are not being instrumented correctly on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617 --- Comment #25 from Jack Howarth howarth at nitro dot med.uc.edu 2013-01-31 22:25:45 UTC --- (In reply to comment #24) Suspect we need to use... ctors[ctor_index].symbol = copy_rtx(symbol); in machopic_asm_out_constructor although I am unclear on what need need to do to release the memory for this copy in at the end of finalize_ctors. Perhaps we just need to add... free(ctors[i].symbol); after we assemble_integer with the ctors[i].symbol in finalize_ctors?
