[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #22 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-30 09:03:15 UTC --- (In reply to comment #18) The obvious solution to this seems to be that also the OMP runtime (libgomp) must be compiled with '-fsanitize=thread. If I do that, it appears to work. That's cool, I will try to do some more testing. Good idea! I did do some more testing, and the combination '-fsanitize=thread -fopenmp' was really very useful. Apart from the libgomp-related warning discussed here and PR40362, everything worked well, and I was able to find a couple of correctly identified OMP bugs in our code that would have been (in part) very difficult to find without the tool. I'll also allow us to start an automatic regression tester for our OMP code, which is something we didn't manage so far. I would be great to get this combination to work out-of-the-box.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #23 from Dmitry Vyukov dvyukov at google dot com 2012-12-30 09:57:44 UTC --- (In reply to comment #22) I did do some more testing, and the combination '-fsanitize=thread -fopenmp' was really very useful. Apart from the libgomp-related warning discussed here and PR40362, everything worked well, and I was able to find a couple of correctly identified OMP bugs in our code that would have been (in part) very difficult to find without the tool. I'll also allow us to start an automatic regression tester for our OMP code, which is something we didn't manage so far. I would be great to get this combination to work out-of-the-box. Wow! Great news! I am not really a gcc hacker. Perhaps Jakub or Dodji can help. It would be interesting to run some OpenMP test suite with tsan to test libgomp better (various schedules and clause types -- section, task, single, etc). Later we may want to instrument libgomp in one way or another to provide better detection and reporting.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #24 from Dmitry Vyukov dvyukov at google dot com 2012-12-30 10:11:27 UTC --- For testing you can comment out first 2 lines of gomp_ptrlock_get(). That should fix the race in libgomp. It's not a good fix form performance pov, but should be OK for testing.
[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-30 CC||mpolacek at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-12-30 10:54:03 UTC --- Confirmed.
[Bug middle-end/55797] [4.8 Regression] ICE: verify_cgraph_node failed: edge has no corresponding call_stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55797 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org 2012-12-30 12:16:15 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revisionrevision=193157
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #25 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-30 14:52:51 UTC --- (In reply to comment #24) For testing you can comment out first 2 lines of gomp_ptrlock_get(). That should fix the race in libgomp. It's not a good fix form performance pov, but should be OK for testing. Thanks.. it turns out that gomp_ptrlock_get is actually used from gcc/libgomp/config/linux/ptrlock.h:74 on linux... is it still sufficient to comment the first if condition only and keep the atomic_compare_exchange, or should one directly have the 'return gomp_ptrlock_get_slow' ?
[Bug rtl-optimization/55829] New: [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:3069 with -msse3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55829 Bug #: 55829 Summary: [4.8 Regression] ICE: in curr_insn_transform, at lra-constraints.c:3069 with -msse3 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 29063 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29063 reduced testcase Compiler output: $ gcc -O2 -msse3 -fno-expensive-optimizations testcase.c testcase.c: In function 'sse3_test': testcase.c:31:1: internal compiler error: in curr_insn_transform, at lra-constraints.c:3069 } ^ 0x8f26fb curr_insn_transform /mnt/svn/gcc-trunk/gcc/lra-constraints.c:3069 0x8f3f4c lra_constraints(bool) /mnt/svn/gcc-trunk/gcc/lra-constraints.c:3504 0x8e36ff lra(_IO_FILE*) /mnt/svn/gcc-trunk/gcc/lra.c:2280 0x89a538 do_reload /mnt/svn/gcc-trunk/gcc/ira.c:4624 0x89a538 rest_of_handle_reload /mnt/svn/gcc-trunk/gcc/ira.c:4737 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. $ /mnt/svn/gcc-trunk/binary-latest/bin/gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-194730-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-194730-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.8.0 20121227 (experimental) (GCC) Tested revisions: r194730 - crash
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #26 from Dmitry Vyukov dvyukov at google dot com 2012-12-30 17:07:01 UTC --- (In reply to comment #25) (In reply to comment #24) For testing you can comment out first 2 lines of gomp_ptrlock_get(). That should fix the race in libgomp. It's not a good fix form performance pov, but should be OK for testing. Thanks.. it turns out that gomp_ptrlock_get is actually used from gcc/libgomp/config/linux/ptrlock.h:74 on linux... is it still sufficient to comment the first if condition only and keep the atomic_compare_exchange, or should one directly have the 'return gomp_ptrlock_get_slow' ? Ah, I was looking at config/posix/ptrlock. For config/linux/ptrlock the changes are: if ((uintptr_t) *ptrlock 2) return *ptrlock; \/\/\/\/\/\/\/\/\/\/\/\/ uintptr_t v = (uintptr_t)__atomic_load(ptrlock, MEMMODEL_ACQUIRE); if (v 2) return v; return *ptrlock; \/\/\/\/\/\/\/\/\/\/\/\/ return __atomic_load(ptrlock, MEMMODEL_ACQUIRE); Also loads of intptr needs to be done with __atomic_load(MEMMODEL_RELAXED). and do_spin() needs to load *addr with __atomic_load(MEMMODEL_RELAXED) as well.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #27 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-30 19:57:24 UTC --- (In reply to comment #24) For testing you can comment out first 2 lines of gomp_ptrlock_get(). That should fix the race in libgomp. It's not a good fix form performance pov, but should be OK for testing. I found that the routines in config/posix can be used instead of the config/linux by configuring gcc with '--disable-linux-futex' . With your suggestion above, I still get warnings (absent in the linux case) from the following testcase: [vjoost@nanosim-s03 bugs]$ cat test_23.f90 INTEGER :: i,j,OMP_GET_THREAD_NUM !$OMP PARALLEL PRIVATE(i,j) j=OMP_GET_THREAD_NUM() !$OMP DO DO i=1,10 !$OMP CRITICAL(xxx) !$OMP END CRITICAL(xxx) ! !$OMP CRITICAL(yyy) ! !$OMP END CRITICAL(yyy) END DO !$OMP END PARALLEL END [vjoost@nanosim-s03 bugs]$ gfortran -fsanitize=thread -fopenmp -gdwarf-3 -O1 -fPIE -pie test_23.f90 [vjoost@nanosim-s03 bugs]$ export OMP_NUM_THREADS=4 ; ./a.out == WARNING: ThreadSanitizer: data race (pid=29039) Read of size 1 at 0x7d020003d050 by thread 1: #0 pthread_mutex_lock ??:0 (libtsan.so.0+0x0001a863) #1 GOMP_critical_name_start /data/vjoost/gnu/gcc_exp/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/config/posix/mutex.h:44 (libgomp.so.1+0x5e5d) #2 MAIN__._omp_fn.0 /data/vjoost/gnu/bugs/test_23.f90:6 (exe+0x0dcc) #3 gomp_thread_start /data/vjoost/gnu/gcc_exp/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:116 (libgomp.so.1+0xc6b2) Previous write of size 8 at 0x7d020003d050 by main thread: #0 gomp_barrier_wait_end /data/vjoost/gnu/gcc_exp/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/config/posix/bar.c:93 (libgomp.so.1+0xe691) #1 gomp_malloc /data/vjoost/gnu/gcc_exp/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/alloc.c:36 (libgomp.so.1+0x5cba) #2 GOMP_critical_name_start /data/vjoost/gnu/gcc_exp/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/critical.c:71 (libgomp.so.1+0x5e79) #3 MAIN__._omp_fn.0 /data/vjoost/gnu/bugs/test_23.f90:6 (exe+0x0dcc) #4 MAIN__ /data/vjoost/gnu/bugs/test_23.f90:2 (exe+0x0e43) #5 __libc_start_main ??:0 (libc.so.6+0x0037a121ecdc) Location is heap block of size 40 at 0x7d020003d050 allocated by main thread: #0 malloc ??:0 (libtsan.so.0+0x0001839e) #1 gomp_malloc /data/vjoost/gnu/gcc_exp/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/alloc.c:36 (libgomp.so.1+0x5cba) #2 GOMP_critical_name_start /data/vjoost/gnu/gcc_exp/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/critical.c:71 (libgomp.so.1+0x5e79) #3 MAIN__._omp_fn.0 /data/vjoost/gnu/bugs/test_23.f90:6 (exe+0x0dcc) #4 MAIN__ /data/vjoost/gnu/bugs/test_23.f90:2 (exe+0x0e43) #5 __libc_start_main ??:0 (libc.so.6+0x0037a121ecdc) Thread 1 (tid=29040, running) created at: #0 pthread_create ??:0 (libtsan.so.0+0x0001a298) #1 gomp_team_start /data/vjoost/gnu/gcc_exp/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:440 (libgomp.so.1+0xd000) #2 GOMP_parallel_start /data/vjoost/gnu/gcc_exp/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108 (libgomp.so.1+0xabb7) #3 MAIN__ /data/vjoost/gnu/bugs/test_23.f90:2 (exe+0x0e39) #4 __libc_start_main ??:0 (libc.so.6+0x0037a121ecdc) == ThreadSanitizer: reported 1 warnings
[Bug c/55830] New: inline and __attribute__((always_inline)) treated differently for unused-function warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55830 Bug #: 55830 Summary: inline and __attribute__((always_inline)) treated differently for unused-function warning Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: bro...@gcc.gnu.org Consider the case of a header file containing definitions of static inline functions, included in a number of source files (which may not use all of the defined functions), compiled with C99 and -Wall -Wextra. If the functions are defined as static inline, GCC will mask the unused function warning. However, if the functions are defined as static __attribute__((always_inline)), then GCC will omit unused function warnings whenever one of them is not used in a given source file. This really should be consistent, and it would be ideal to maintain the no-warning behavior and have that apply to both cases.
[Bug c/55830] inline and __attribute__((always_inline)) treated differently for unused-function warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55830 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-12-30 21:42:28 UTC --- IIRC always_inline really needs inline also.
[Bug c/55830] inline and __attribute__((always_inline)) treated differently for unused-function warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55830 --- Comment #2 from Brooks Moses brooks at gcc dot gnu.org 2012-12-30 21:46:02 UTC --- Created attachment 29064 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29064 Minimal test case The attached test case illustrates the problem. When compiled with -Wall -Wextra -Werror, it reports: bug55830.c:6:44: warning: 'bar' defined but not used However, it does not report a similar warning for 'foo'.
[Bug c/55830] inline and __attribute__((always_inline)) treated differently for unused-function warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55830 --- Comment #3 from Brooks Moses brooks at gcc dot gnu.org 2012-12-30 21:50:08 UTC --- Andrew: Oh, interesting. So perhaps this is really a failure to warn (or error?) for a case where __attribute__((always_inline)) isn't used with inline, and a case of missing documentation on the always_inline attribute? FWIW, the additional inline certainly doesn't seem to be needed in practice for GCC to inline the code.
[Bug c/55830] inline and __attribute__((always_inline)) treated differently for unused-function warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55830 --- Comment #4 from Andreas Schwab sch...@linux-m68k.org 2012-12-30 22:12:28 UTC --- static alone already makes a function eligible for inlining.
