[Bug sanitizer/55561] New: TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 Bug #: 55561 Summary: TSAN crashes for Fortran Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@mat.ethz.ch CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org, ja...@gcc.gnu.org, k...@gcc.gnu.org Current trunk crashes if -fsanitize=thread is used for Fortran programs. This is contrary to -fsanitize=address, which seems to work (PR55341). I think there would be quite some interest in having -fsanitize=thread to work for OMP'ed Fortran programs. cat test.f90 J=0 !$OMP PARALLEL DO DO I=1,10 J=J+1 ENDDO WRITE(6,*) J END gfortran -fopenmp -fsanitize=thread test.f90 test.f90:7:0: internal compiler error: Segmentation fault END ^ 0x98cc1f crash_signal ../../gcc/gcc/toplev.c:334 0x6718e0 contains_struct_check ../../gcc/gcc/tree.h:3784 0x6718e0 build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**) ../../gcc/gcc/builtins.c:11206 0x672f82 build_call_expr(tree_node*, int, ...) ../../gcc/gcc/builtins.c:11256 0x9a0d76 tsan_finish_file() ../../gcc/gcc/tsan.c:316 Please submit a full bug report,
[Bug c++/33911] attribute deprecated vs. templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911 --- Comment #7 from Victor Gaydov victor at enise dot org 2012-12-02 08:16:04 UTC --- I also have experienced bug 7. I'm porting a project that uses std::auto_ptr in several places to c++11. However, there are no deprecated warnings because it happened that every unit uses auto_ptr once. If there is a workaround, may be it can be added to c++11 deprecated classes?
[Bug other/55560] fesetround(FE_DOWNWARD) causes cos() to return values outside the range of -1 to +1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55560 --- Comment #2 from pj at ecstaticlyrics dot com 2012-12-02 09:10:35 UTC --- GNU C Library (Ubuntu EGLIBC 2.15-0ubuntu20) stable release version 2.15 I downloaded glibc 2.16, but it encounters an error while compiling.
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #1 from Dmitry Vyukov dvyukov at google dot com 2012-12-02 09:21:19 UTC --- Note that ThreadSanitizer does not understand Fortran/OpenMP synchronization, so most likely it won't be useful anyway.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #147 from Jan Hubicka hubicka at ucw dot cz 2012-12-02 09:23:09 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #146 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-12-02 07:36:02 UTC --- (In reply to comment #145) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #144 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-12-01 12:39:30 UTC --- It looks like there is a LTO code-size regression on trunk: (size of libxul.so, build without elfhack): gcc lto/pgo : size: 42204584 | Kraken bench: 2723.9ms +/- 0.9% About LTO+PGO please be sure that you have the Teresa's fix from this Friday in your tree. Yes, my tree already included this fix and also the fix from bug 1. Please try to reduce HOT_BB_COUNT_WS_PERMILLE to 990. I also see some regressions on some SPEC benchmarks (such as GCC) and this helps. If it doesn't it would be nice to know what value is needed for comparable size. gcc : size: 34072808 | Kraken bench: 2804.3ms +/- 1.6% Is LTO w/o PGO bigger than previous builds? Couldn't tell, because it doesn't link: /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: hidden symbol 'pixman_add_triangles' in /var/tmp/moz-build-dir/toolkit/library/../../gfx/cairo/libpixman/src/pixman-trap.o is referenced by DSO /usr/lib64/libcairo.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /tmp/cc0oq4BG.ltrans1.ltrans.o: requires dynamic R_X86_64_PC32 reloc against '_ZN12SkAnnotationC1ER23SkFlattenableReadBuffer' which may overflow at runtime; recompile with -fPIC /tmp/cc0oq4BG.ltrans0.ltrans.o:cc0oq4BG.ltrans0.o:function SharedStub: error: undefined reference to 'PrepareAndDispatch' /tmp/cc0oq4BG.ltrans1.ltrans.o:cc0oq4BG.ltrans1.o:function SkAnnotation::CreateProc(SkFlattenableReadBuffer) [clone .local.7828.1055099]: error: undefined reference to 'SkAnnotation::SkAnnotation(SkFlattenableReadBuffer)' collect2: error: ld returned 1 exit status The undefined reference to PrepareAndDispatch is easily fixed by an __attribute__ ((used)). Do you have an idea on how to fix the SkAnnotation::SkAnnotation(SkFlattenableReadBuffer) issue? Hmm, I remember seeing this one, too. I will check. Honza
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-02 09:30:17 UTC --- (In reply to comment #1) Note that ThreadSanitizer does not understand Fortran/OpenMP synchronization, so most likely it won't be useful anyway. I was assuming that it would do just fine, as OMP in gcc is just built on pthreads ? I believe that Fortran and C are relatively similar from a middle-end perspective.
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #3 from Dmitry Vyukov dvyukov at google dot com 2012-12-02 09:35:41 UTC --- Well, then maybe it will work. But we did not do anything special for Fortran and OpenMP, and did not do any testing.
[Bug c++/33911] attribute deprecated vs. templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-02 09:56:41 UTC --- Personally, I'm not aware of any wa, if somebody finds one, please add it here, thanks.
[Bug middle-end/55555] [4.8 Regression] miscompilation at -O2 (tree-pre?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2012-12-02 09:59:35 UTC --- Hmm, this seems to be caused by Forced statement unreachable: pretmp_516 = coef_x[pretmp_515]; Forced statement unreachable: pretmp_513 = coef_x[pretmp_512]; Forced statement unreachable: pretmp_479 = coef_x[pretmp_478]; I am not exactly fortran guru. Can someone double check that there are no out of bounds accesses into these? Honza
[Bug middle-end/55555] [4.8 Regression] miscompilation at -O2 (tree-pre?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-02 10:11:34 UTC --- (In reply to comment #4) Hmm, this seems to be caused by Forced statement unreachable: pretmp_516 = coef_x[pretmp_515]; Forced statement unreachable: pretmp_513 = coef_x[pretmp_512]; Forced statement unreachable: pretmp_479 = coef_x[pretmp_478]; I am not exactly fortran guru. Can someone double check that there are no out of bounds accesses into these? Honza I'm pretty sure there are no out-of-bounds. In particular coef_x is easy to check, it is only used as coef_x(:,lxp) where lxp is the loop bound 0..lp consistent with its def. Of course maybe the FE does something inconsistent ? Also this runs fine: fortran -O0 -fsanitize=address PR5.f90 ; ./a.out
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org 2012-12-02 10:28:10 UTC --- Note that tsan currently requires to use -pie linker flag (and either -fPIC or -fPIE compiler flag). Obviously, your failure happens before the run-time library has a chance to crash.
[Bug middle-end/55555] [4.8 Regression] miscompilation at -O2 (tree-pre?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #6 from Jan Hubicka hubicka at ucw dot cz 2012-12-02 11:03:53 UTC --- I'm pretty sure there are no out-of-bounds. In particular coef_x is easy to check, it is only used as coef_x(:,lxp) where lxp is the loop bound 0..lp consistent with its def. Of course maybe the FE does something inconsistent ? Also this runs fine: fortran -O0 -fsanitize=address PR5.f90 ; ./a.out Hmm, I saw similar weird cases generated by the frontend. coef_x is array of 8 elements real(kind=8) coef_x[8]; in loop analyzis we do: Induction variable (integer(kind=8)) 4 + 4 * iteration does not wrap in statement pretmp_516 = coef_x[pretmp_515]; in loop 4. Statement pretmp_516 = coef_x[pretmp_515]; is executed at most 0 (bounded by 0) + 1 times in loop 4. This is true, pretmp_512 would be 8 at the second iteration of the loop. later we conclude Loop 4 iterates 1 times. Loop 4 iterates at most 1 times. BB: 9, after_exit: 0 size: 0 # DEBUG lxp = lxp_4 size: 0 _137 = (integer(kind=8)) lxp_4; size: 1 _140 = _137 + pretmp_508; size: 1 _142 = *pol_x_141(D)[_140]; size: 1 _143 = _137 * 4; size: 1 _144 = _143 + -1; BB: 10, after_exit: 0 size: 1 _146 = S.25_279 + _144; size: 1 _150 = _142 * prephitmp_520; size: 1 _151 = _150 + prephitmp_517; size: 1 coef_x[_146] = _151; size: 1 S.25_153 = S.25_279 + 1; size: 1 ivtmp_162 = ivtmp_91 - 1; size: 2 if (ivtmp_162 == 0) goto bb12 or bb11 BB: 11, after_exit: 0 size: 1 pretmp_515 = _144 + S.25_153; size: 1 pretmp_516 = coef_x[pretmp_515]; size: 1 pretmp_518 = S.25_153 + -1; size: 1 pretmp_519 = s[pretmp_518]; BB: 12, after_exit: 0 size: 0 # DEBUG lxp = lxp_4 + 1 size: 1 ivtmp_109 = ivtmp_163 - 1; size: 2 if (ivtmp_109 == 0) goto bb 13 or exit BB: 13, after_exit: 1 size: 1 lxp_154 = lxp_4 + 1; size: 0 pretmp_506 = (integer(kind=8)) lxp_154; size: 1 pretmp_509 = pretmp_506 * 4; size: 1 pretmp_510 = pretmp_509 + -1; size: 1 pretmp_512 = pretmp_510 + 1; size: 1 pretmp_513 = coef_x[pretmp_512]; Unrolled loop 4 completely (duplicated 1 times). Exit condition of peeled iterations was eliminated. Last iteration exit edge was proved true. So the curious statements are in bb11. Adding unreachable calls makes CSE to eventually turn condition in the second copy of BB10 to always just to BB 12 that seem all right to me. Perhaps cascaded unrolling confuse some of the exits... Honza
[Bug tree-optimization/55559] Marshalling double through union with inlines, incorrect behavior with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2012-12-02 11:15:37 UTC --- Doesn't depend on that extended initializer, a pure C version fails for me at -O1 and above with gcc 4.4.7, 4.5.4, 4.6.3, 4.7.2, and trunk, while 4.3.6 works.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #148 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-12-02 11:57:27 UTC --- (In reply to comment #147) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #146 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-12-02 07:36:02 UTC --- (In reply to comment #145) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #144 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-12-01 12:39:30 UTC --- It looks like there is a LTO code-size regression on trunk: (size of libxul.so, build without elfhack): gcc lto/pgo : size: 42204584 | Kraken bench: 2723.9ms +/- 0.9% About LTO+PGO please be sure that you have the Teresa's fix from this Friday in your tree. Yes, my tree already included this fix and also the fix from bug 1. Please try to reduce HOT_BB_COUNT_WS_PERMILLE to 990. I also see some regressions on some SPEC benchmarks (such as GCC) and this helps. If it doesn't it would be nice to know what value is needed for comparable size. Unfortunately it doesn't help much, because with --param hot-bb-count-ws-permille=990 the size is only 0.25% smaller: (With --param) : 42098856 (Without ) : 42204584 I will try smaller values later.
[Bug c++/33911] attribute deprecated vs. templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33911 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2012-12-02 12:38:03 UTC --- (In reply to comment #5) Not planning to work on this soon since there's a reasonable workaround. Jason, that workaround is only for function templates, not class templates, right? It's odd that the warning works for class templates except on the first instantiation (PR 7)
[Bug target/55562] New: [4.8 Regression] FAIL: gcc.dg/sms-* on powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55562 Bug #: 55562 Summary: [4.8 Regression] FAIL: gcc.dg/sms-* on powerpc*-*-* Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: dje@gmail.com, hubi...@ucw.cz, pthau...@us.ibm.com Host: powerpc*-*-* Target: powerpc*-*-* Build: powerpc*-*-* The following tests FAIL: gcc.dg/sms-1.c scan-rtl-dump-times sms SMS succeeded 1 FAIL: gcc.dg/sms-10.c scan-rtl-dump-times sms SMS succeeded 1 FAIL: gcc.dg/sms-3.c execution test FAIL: gcc.dg/sms-5.c execution test FAIL: gcc.dg/sms-6.c execution test FAIL: gcc.dg/sms-7.c execution test FAIL: gfortran.dg/sms-2.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/sms-2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test have started to fail between revisions 192894 (OK, see http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg02911.html) and 192975 (FAIL, see http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg03059.html ).
[Bug target/55562] [4.8 Regression] FAIL: gcc.dg/sms-* on powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55562 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-02 CC|dje.gcc at gmail dot com|dje at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from David Edelsohn dje at gcc dot gnu.org 2012-12-02 14:14:19 UTC --- Confirmed.
Re: [Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
Please try to reduce HOT_BB_COUNT_WS_PERMILLE to 990. I also see some regressions on some SPEC benchmarks (such as GCC) and this helps. If it doesn't it would be nice to know what value is needed for comparable size. Unfortunately it doesn't help much, because with --param hot-bb-count-ws-permille=990 the size is only 0.25% smaller: (With --param) : 42098856 (Without ) : 42204584 I will try smaller values later. Hmm, that sounds like quite bad news - the histogram code was supposed to help in such cases. I will try to fix the non-PGO case and lets try to compare how PGO/non-PGO compare first. If you could put somewhere the -fdump-ipa-inline dump, I will try to check if there is something obviously wrong. In worst case we can resort to combining both heuristics - i.e. keeping the hot_bb_fraction in addition to histogram code. In fact I planned to do that this way but Teresa removed the old code and I did not see good reason why to keep it. Honza
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #149 from Jan Hubicka hubicka at ucw dot cz 2012-12-02 15:05:52 UTC --- Please try to reduce HOT_BB_COUNT_WS_PERMILLE to 990. I also see some regressions on some SPEC benchmarks (such as GCC) and this helps. If it doesn't it would be nice to know what value is needed for comparable size. Unfortunately it doesn't help much, because with --param hot-bb-count-ws-permille=990 the size is only 0.25% smaller: (With --param) : 42098856 (Without ) : 42204584 I will try smaller values later. Hmm, that sounds like quite bad news - the histogram code was supposed to help in such cases. I will try to fix the non-PGO case and lets try to compare how PGO/non-PGO compare first. If you could put somewhere the -fdump-ipa-inline dump, I will try to check if there is something obviously wrong. In worst case we can resort to combining both heuristics - i.e. keeping the hot_bb_fraction in addition to histogram code. In fact I planned to do that this way but Teresa removed the old code and I did not see good reason why to keep it. Honza
[Bug target/55562] [4.8 Regression] FAIL: gcc.dg/sms-* on powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55562 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-02 15:42:26 UTC --- Indeed. And they aren't in much better shape on IA-64: FAIL: gcc.dg/sms-10.c execution test FAIL: gcc.dg/sms-3.c execution test FAIL: gcc.dg/sms-5.c execution test FAIL: gcc.dg/sms-6.c (internal compiler error) FAIL: gcc.dg/sms-6.c (test for excess errors) WARNING: gcc.dg/sms-6.c compilation failed to produce executable FAIL: gcc.dg/sms-7.c (internal compiler error) FAIL: gcc.dg/sms-7.c (test for excess errors) WARNING: gcc.dg/sms-7.c compilation failed to produce executable FAIL: gcc.dg/sms-9.c (internal compiler error) FAIL: gcc.dg/sms-9.c (test for excess errors) WARNING: gcc.dg/sms-9.c compilation failed to produce executable
[Bug tree-optimization/55559] Marshalling double through union with inlines, incorrect behavior with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2012-12-02 16:04:49 UTC --- Created attachment 28853 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28853 simplified test case in plain C The regression started with Richard Biener's [PATCH] Teach SCCVN/FRE expression insertion, optimize type-punning through unions (final!) patch in r133218: http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00873.html http://gcc.gnu.org/ml/gcc-cvs/2008-03/msg00436.html
[Bug gcov-profile/55551] Revision 193999 breaks lto/profiledbootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1 --- Comment #10 from tejohnson at gcc dot gnu.org 2012-12-02 16:40:34 UTC --- Author: tejohnson Date: Sun Dec 2 16:40:28 2012 New Revision: 194055 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194055 Log: 2012-12-02 Teresa Johnson tejohn...@google.com PR gcov-profile/1 * lto-cgraph.c (merge_profile_summaries): Handle scaled histogram entries that map to the same index. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-cgraph.c
[Bug middle-end/55563] New: OpenMP not marking variable as thread-local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55563 Bug #: 55563 Summary: OpenMP not marking variable as thread-local Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gcc.gnu.org OpenMP threadprivate variables are not marked as thread-local at time when pool storage is chosen. For example, libgomp.c/copyin-1.c int thr = 32; #pragma omp threadprivate (thr) In varasm.c:use_blocks_for_decl_p(), the variable thread is marked as TLS_MODEL_NONE Breakpoint 2, _ZL21use_blocks_for_decl_pP9tree_node (decl=0x701634e0) at /nasfarm/dje/src/src/gcc/varasm.c:1116 1116 return targetm.use_blocks_for_decl_p (decl); (gdb) print decl $9 = (tree) 0x701634e0 (gdb) print debug_tree(decl) var_decl 701634e0 thr type integer_type 700153c0 int public SI size integer_cst 700065e0 constant 32 unit size integer_cst 70006600 constant 4 align 32 symtab 0 alias set -1 canonical type 700153c0 precision 32 min integer_cst 70006900 -2147483648 max integer_cst 70006920 2147483647 pointer_to_this pointer_type 70015ae0 public static SI file copyin-1.c line 8 col 5 size integer_cst 700065e0 32 unit size integer_cst 70006600 4 align 32 initial integer_cst 700f8660 32 $10 = 10 (gdb) print decl-decl_with_vis.tls_model $11 = TLS_MODEL_NONE This does not happen with variables declared with __thread, but does with OpenMP and variables annotated using #pragma. The variable later is transformed to TLS, but wrong choices have been made and the now TLS variable is defined incorrectly in the assembly file.
[Bug bootstrap/54926] [4.8 Regression] Bootstrap comparison failure for various files in libbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2012-12-02 Resolution|FIXED | Ever Confirmed|0 |1 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2012-12-02 17:17:06 UTC --- Comment #3 is incorrect. Thought the configure change to check for -funwind-tables support fixed the compare failure, it turns out it doesn't disable unwind-table support.
[Bug middle-end/55563] OpenMP not marking variable as thread-local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55563 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Target||powerpc-ibm-aix* Status|UNCONFIRMED |NEW Keywords||openmp, wrong-code Last reconfirmed||2012-12-02 CC||jakub at gcc dot gnu.org Host||powerpc-ibm-aix* Ever Confirmed|0 |1 Target Milestone|--- |4.8.0 Build||powerpc-ibm-aix* --- Comment #1 from David Edelsohn dje at gcc dot gnu.org 2012-12-02 17:18:30 UTC --- Confirmed.
[Bug libgomp/55411] OMP threads lose their OMP_WAIT_POLICY when another OMP thread gets destructed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55411 jk3064 jk3064 at arcor dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #7 from jk3064 jk3064 at arcor dot de 2012-12-02 17:26:14 UTC --- Thank you! That fixed it. The omp threads of the 2nd thread obv. still don't copy the policies of the main one, but this would be even counterproductive (you would have ~twice more threads with 100% cpu usage than you got cores). This could only be solved with an either process or OS shared workerpool, what is another topic. So the ticket can be closed :)
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #150 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-12-02 18:03:28 UTC --- For comparison I've just disabled skia and build with LTO only; the size looks good for this case: 31356968
[Bug c++/55564] New: internal error using decltype of a template type parameter for late-specified function result type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55564
Bug #: 55564
Summary: internal error using decltype of a template type
parameter for late-specified function result type
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pub...@alisdairm.net
The following program gives an internal compiler error, when built with the
command line: g++ -std=c++11 main.cpp
//---
template typename T, decltype(sizeof(T)) N
auto array_size(T()[N]) - decltype(N) { return N; }
int main() {
int simple[4] = {};
int result = array_size(simple);
return result;
}
//---
The error I get from my build of gcc is:
main.cpp: In function 'int main()':
main.cpp:1:38: internal compiler error: in dependent_type_p, at cp/pt.c:19249
template typename T, decltype(sizeof(T)) N
^
main.cpp:1:38: internal compiler error: Abort trap: 6
g++-mp-4.8: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6
Build is a recent version obtained from MacPorts, running on the latest Apple
Mountain Lion OS with up to date patches.
g++ -v:
Using built-in specs.
COLLECT_GCC=g++-mp-4.8
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin12/4.8.0/lto-wrapper
Target: x86_64-apple-darwin12
Configured with: ../gcc-4.8-20121125/configure --prefix=/opt/local
--build=x86_64-apple-darwin12
--enable-languages=c,c++,objc,obj-c++,fortran,java
--libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.8
--with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local
--with-cloog=/opt/local --enable-cloog-backend=isl
--disable-cloog-version-check --enable-stage1-checking --disable-multilib
--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts
gcc48 4.8-20121125_0'
Thread model: posix
gcc version 4.8.0 20121125 (experimental) (MacPorts gcc48 4.8-20121125_0)
[Bug middle-end/54838] [4.8 Regression] ICE: in merge_latch_edges, at cfgloop.c:678 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838 --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org 2012-12-02 20:17:16 UTC --- Author: mpolacek Date: Sun Dec 2 20:16:09 2012 New Revision: 194060 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194060 Log: PR54838 Added: trunk/gcc/testsuite/gcc.dg/pr54838.c Modified: trunk/gcc/ChangeLog trunk/gcc/cprop.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/54838] [4.8 Regression] ICE: in merge_latch_edges, at cfgloop.c:678 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org 2012-12-02 20:17:54 UTC --- Fixed.
[Bug target/55565] New: [4.8 regression] FAIL: gcc.target/powerpc/ppc-mov-1.c scan-assembler-not fmr [0-9]+,[0-9]+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55565 Bug #: 55565 Summary: [4.8 regression] FAIL: gcc.target/powerpc/ppc-mov-1.c scan-assembler-not fmr [0-9]+,[0-9]+ Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org Target: powerpc64-*-* Between r190317 and r191083 the test gcc.target/powerpc/ppc-mov-1.c started to fail on powerpc64.
[Bug bootstrap/55566] New: [4.8 regression] [IA64] ICE during bootstrap (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 Bug #: 55566 Summary: [4.8 regression] [IA64] ICE during bootstrap (related to recent vec re-implementation?) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@intrepid.com Created attachment 28854 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28854 build failure: IA64 segv - first seen in r193595 GCC fails to build, due to a segmentation violation while compiling libgcc2 during the bootstrap phase on an IA64 (altix) running SuSE SLES 11.1. The installed gcc compiler is gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973], which is the compiler used to initially build gcc. Bisection indicates that this started to fail with this svn revision. r193595 | dnovillo | 2012-11-17 18:54:30 -0800 (Sat, 17 Nov 2012) | 537 lines This patch rewrites the old VEC macro-based interface into a new one based on the template class 'vec'. The user-visible changes are described in http://gcc.gnu.org/wiki/cxx-conversion/cxx-vec. [...] It has continued to fail subsequent to that commit at least through 2012-11-30. Since about 2012-11-27, the segmentation violations that trace back originating through vec.h persist, but now the failure occurs when compiling a configure test when beginning to build libgcc. This continues to fail for a recent version of gcc trunk (r194044 2012-12-01). An excerpt configure test failure traceback is as follows. conftest.c: In function 'foo': conftest.c:19:1: internal compiler error: Segmentation fault } ^ 0x40b3b33f crash_signal src/gcc/toplev.c:334 0x40466f30 vecdf_ref_d*, va_stack, vl_embed::space(unsigned int) cons t src/gcc/vec.h:842 0x40466f30 vecdf_ref_d*, va_stack, vl_embed::quick_push(df_ref_d* con st) src/gcc/vec.h:947 0x40466f30 vecdf_ref_d*, va_stack, vl_ptr::quick_push(df_ref_d* const ) src/gcc/vec.h:1552 0x40466f30 vecdf_ref_d*, va_stack, vl_ptr::safe_push(df_ref_d* const ) src/gcc/vec.h:1565 0x40466f30 df_ref_create_structure 0x40466f30 df_ref_create_structure src/gcc/df-scan.c:2804 0x40467b3f df_ref_record src/gcc/df-scan.c:2873 0x4046923f df_get_call_refs src/gcc/df-scan.c:3403 [...] More complete logs with trace back are attached.
[Bug bootstrap/55566] [4.8 regression] [IA64] ICE during bootstrap (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #1 from Gary Funck gary at intrepid dot com 2012-12-02 20:32:03 UTC --- Created attachment 28855 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28855 build failure Ia64 segv - continues to fail in r194044 (in libgcc config. test)
[Bug fortran/55567] New: [4.8 regression] FAIL: gfortran.dg/typebound_operator_18.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55567 Bug #: 55567 Summary: [4.8 regression] FAIL: gfortran.dg/typebound_operator_18.f90 -O (test for excess errors) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org spawn /daten/gcc/gcc-20121201/Build/gcc/testsuite/gfortran6/../../gfortran -B/daten/gcc/gcc-20121201/Build/gcc/testsuite/gfortran6/../../ -B/daten/gcc/gcc-20121201/Build/powerpc64-linux/./libgfortran/ /daten/gcc/gcc-20121201/gcc/testsuite/gfortran.dg/typebound_operator_18.f90 -fno-diagnostics-show-caret -O -pedantic-errors -S -m64 -o typebound_operator_18.s /daten/gcc/gcc-20121201/gcc/testsuite/gfortran.dg/typebound_operator_18.f90:11.29: generic :: operator(-) = negative 1 Error: Entity 'negative' at (1) is already present in the interface
[Bug fortran/55567] [4.8 regression] FAIL: gfortran.dg/typebound_operator_18.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55567 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug other/55560] fesetround(FE_DOWNWARD) causes cos() to return values outside the range of -1 to +1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55560 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com 2012-12-02 20:39:23 UTC --- This would have been glibc bug 3976 which was fixed for cos by: commit 804360ed837e3347c9cd9738f25345d2587a1242 Author: Joseph Myers jos...@codesourcery.com Date: Fri Mar 2 20:51:39 2012 + Fix sin, cos, tan in non-default rounding modes (bug 3976).
[Bug fortran/55568] New: [4.8 regression] FAIL: gfortran.dg/allocate_error_4.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55568 Bug #: 55568 Summary: [4.8 regression] FAIL: gfortran.dg/allocate_error_4.f90 -O (test for excess errors) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sch...@linux-m68k.org spawn /daten/gcc/gcc-20121201/Build/gcc/testsuite/gfortran1/../../gfortran -B/daten/gcc/gcc-20121201/Build/gcc/testsuite/gfortran1/../../ -B/daten/gcc/gcc-20121201/Build/powerpc64-linux/./libgfortran/ /daten/gcc/gcc-20121201/gcc/testsuite/gfortran.dg/allocate_error_4.f90 -fno-diagnostics-show-caret -O -pedantic-errors -S -m64 -o allocate_error_4.s /daten/gcc/gcc-20121201/gcc/testsuite/gfortran.dg/allocate_error_4.f90:13.12-32: allocate( encode(1,1)%mask(1),encode(1,2)%mask(1)) 1 2 Error: Allocate-object at (1) also appears at (2) /daten/gcc/gcc-20121201/gcc/testsuite/gfortran.dg/allocate_error_4.f90:14.13-31: deallocate( encode(1,1)%mask,encode(1,2)%mask) 1 2 Error: Allocate-object at (1) also appears at (2)
[Bug fortran/55568] [4.8 regression] FAIL: gfortran.dg/allocate_error_4.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55568 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug bootstrap/55566] [4.8 regression] [IA64] ICE during bootstrap (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #2 from Gary Funck gary at intrepid dot com 2012-12-02 20:43:45 UTC --- The configure options specified are: CC=/usr/bin/gcc CXX=/usr/bin/g++ $src/configure --enable-languages=c,c++ --enable-checking --disable-bootstrap --disable-multilib --disable-libmudflap --disable-libssa --disable-lto --prefix=/eng/upc/dev/gary/gcc-trunk Configure reports: CFLAGS='-g -O2' CFLAGS_FOR_BUILD='-g -O2' CFLAGS_FOR_TARGET='-g -O2' CXXFLAGS='-g -O2' CXXFLAGS_FOR_BUILD='-g -O2' CXXFLAGS_FOR_TARGET='-g -O2'
Re: [Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
Teresa comitted another bugfix just today. So with bit of luck it will work now? I will try to look deeper into it ASAP, but I am just getting ready for trip to USA. Honza
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #151 from Jan Hubicka hubicka at ucw dot cz 2012-12-02 20:52:13 UTC --- Teresa comitted another bugfix just today. So with bit of luck it will work now? I will try to look deeper into it ASAP, but I am just getting ready for trip to USA. Honza
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #152 from Jan Hubicka hubicka at ucw dot cz 2012-12-02 21:09:24 UTC --- Also I suppose you don't have comparsion to 4.7 handy? (I am curious because of inliner heuristic re-tunning) Honza
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-02 21:11:07 UTC --- Are you testing with all the pending unreviewed TSAN fixes? http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01875.html http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02578.html http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00018.html
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #153 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-12-02 21:13:21 UTC --- On 2012.12.02 at 21:09 +, hubicka at ucw dot cz wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #152 from Jan Hubicka hubicka at ucw dot cz 2012-12-02 21:09:24 UTC --- Also I suppose you don't have comparsion to 4.7 handy? (I am curious because of inliner heuristic re-tunning) The LTO/PGO sizes were measured with the newest patch from Teresa already applied. gcc-4.7 lto/pgo: size: 7456 | Kraken bench: 2706.7ms +/- 1.1%
[Bug c++/53814] FAIL: g++.dg/cpp0x/nullptr28.C -std=c++11 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53814 --- Comment #3 from John David Anglin danglin at gcc dot gnu.org 2012-12-02 21:13:57 UTC --- On trunk, n is loaded using generic code to load a misaligned object. So, test doesn't fail.
[Bug sanitizer/55521] many instances of ASAN:SIGSEGV failures in g++ testsuite with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55521 --- Comment #17 from Jack Howarth howarth at nitro dot med.uc.edu 2012-12-02 21:25:32 UTC --- Revised patch posted at http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00084.html. Also tested with a build of xplor-nih (a complex mix of c, c++ and fortran code) which has always had optimization issues with FSF gcc (as xplor-nih has its own heap memory manager routines in fortran). A build of xplor-nih with -fsanitize=address produced 41 failures out of 154 tests but all of the failures emitted AddressSanitizer output (often unknown-crash on address) rather than segfaulting.
[Bug bootstrap/55566] [4.8 regression] [IA64] ICE during bootstrap (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #3 from Gary Funck gary at intrepid dot com 2012-12-02 21:32:14 UTC --- This failure may be related to the use of the installed gcc compiler (gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973]). I tried a gcc 4.7.0 compiler that we built circa Feb, 2012 and it didn't segfault, but rather fails with an apparently unrelated error while compiling 'gmp' (redc_2.c:87:7: error: 'asm' operand requires impossible reload). I will try building svn revision 152973 on an x86-64 box, and see if the problem can be reproduced there.
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-12-02 CC||ebotcazou at gcc dot ||gnu.org Summary|[4.8 regression] [IA64] ICE |[4.8 regression] segfault |during bootstrap (related |during build (related to |to recent vec |recent vec |re-implementation?) |re-implementation?) Ever Confirmed|0 |1 Build||ia64-*-* --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-02 21:39:08 UTC --- This isn't a bootstrap since you pass --disable-bootstrap to configure, rather a simple build, which would indeed point to a problem in the base compiler. Try with another base compiler (4.6.x or more recent 4.7.x). The compiler bootstraps fine for me btw.
[Bug tree-optimization/55569] New: [4.8 Regression] ICE: in check_probability, at basic-block.h:944 with -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55569 Bug #: 55569 Summary: [4.8 Regression] ICE: in check_probability, at basic-block.h:944 with -ftree-vectorize Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28856 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28856 reduced testcase Compiler output: $ gcc -O -ftree-vectorize testcase.C testcase.C: In function 'void test01()': testcase.C:13:1: internal compiler error: in check_probability, at basic-block.h:944 test01 () ^ 0x84ddff check_probability /mnt/svn/gcc-trunk/gcc/basic-block.h:944 0x84ddff inverse_probability /mnt/svn/gcc-trunk/gcc/basic-block.h:972 0x84ddff scale_loop_profile(loop*, int, int) /mnt/svn/gcc-trunk/gcc/cfgloopmanip.c:522 0xd85d4e vect_transform_loop(_loop_vec_info*) /mnt/svn/gcc-trunk/gcc/tree-vect-loop.c:5739 0xd9e426 vectorize_loops() /mnt/svn/gcc-trunk/gcc/tree-vectorizer.c:124 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. $ gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-194017-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-194017-lto-fortran-checking-yes-rtl-df/ --without-cloog --without-ppl Thread model: posix gcc version 4.8.0 20121201 (experimental) (GCC) Tested revisions: r194017 - crash
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #5 from Gary Funck gary at intrepid dot com 2012-12-02 21:45:52 UTC --- Cancel the previous comment regarding the idea that this might be related to using the system installed gcc. The build failed while trying to build gmp, and hadn't gotten to trying compile libgcc yet.
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #6 from Gary Funck gary at intrepid dot com 2012-12-02 21:48:28 UTC --- This isn't a bootstrap since you pass --disable-bootstrap to configure ... Agreed. I didnt' know how to classify this problem. Since the version of 4.7.0 that I used appears incompatible with the version of gmp that we build as a pre-requisite, I will try a 4.6 compiler and see if I get a different result.
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #7 from Gary Funck gary at intrepid dot com 2012-12-02 21:49:49 UTC --- (In reply to comment #4) The compiler bootstraps fine for me btw. Which version of the host compiler did you use to run the initial build step? Which OS and target architecture?
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-02 22:03:42 UTC --- Which version of the host compiler did you use to run the initial build step? This is a 4.5.x compiler configured for ia64-generic-linux-gnu on a RHEL 5.8.
[Bug tree-optimization/55569] [4.8 Regression] ICE: in check_probability, at basic-block.h:944 with -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55569 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-02 Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-12-02 23:14:54 UTC --- Revision 190641 is OK. Revision 193382 gives the ICE. Note that there is no ICE for revision 194020 configured with --enable-checking=release.
[Bug ada/55243] STAMP variable is not defined in t-avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added CC||gjl at gcc dot gnu.org --- Comment #7 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-12-02 23:17:19 UTC --- (In reply to comment #6) The GNAT tools are for the host, they have nothing to do with multilibs. How come the s-avr-mlib Makefile rule gets invoked here? avr-gcc supports around 200 devices. In order to keep the various parts of the compiler in sync, some files are auto-generated from the device description in $(srcdir)/config/avr/avr-mcus.def. $(srcdir)/config/avr/t-avr reads: ... AVR_MCUS = $(srcdir)/config/avr/avr-mcus.def ... # MULTILIB_OPTIONS # MULTILIB_DIRNAMES # MULTILIB_EXCEPTIONS # MULTILIB_MATCHES $(srcdir)/config/avr/t-multilib: s-avr-mlib; @true s-mlib: $(srcdir)/config/avr/t-multilib s-avr-mlib: $(srcdir)/config/avr/genmultilib.awk $(AVR_MCUS) $(AWK) -f $ -v FORMAT=Makefile $ $(AVR_MCUS) tmp-avr-mlib $(SHELL) $(srcdir)/../move-if-change \ tmp-avr-mlib $(srcdir)/config/avr/t-multilib $(STAMP) $@ And in config.gcc there is tmake_file=avr/t-avr avr/t-multilib Thus, the assumption is that AWK, SHELL and STAMP are set correctly and respective tools are available on the build platform.
[Bug c++/55564] 4.8 Regression] internal error using decltype of a template type parameter for late-specified function result type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55564 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-02 Summary|internal error using|4.8 Regression] internal |decltype of a template type |error using decltype of a |parameter for |template type parameter for |late-specified function |late-specified function |result type |result type Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-12-02 23:52:30 UTC --- Seems a regression.
[Bug fortran/55567] [4.8 regression] FAIL: gfortran.dg/typebound_operator_18.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55567 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-03 CC||hp at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-12-03 01:40:10 UTC --- I see it for cris-elf and x86_64-linux too. Introduced with revision r194016, committer cc:ed.
[Bug fortran/55568] [4.8 regression] FAIL: gfortran.dg/allocate_error_4.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55568 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-12-03 CC||hp at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-12-03 01:44:13 UTC --- Like PR55567, this one was introduced with r194016. Maybe mark one as a dup? Leaving that to the committer, cc:ed.
[Bug fortran/55568] [4.8 regression] FAIL: gfortran.dg/allocate_error_4.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55568 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-12-03 01:47:04 UTC --- Oops, both this and the fail in PR55567 are gone at least at r194057.
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 --- Comment #9 from Gary Funck gary at intrepid dot com 2012-12-03 02:02:18 UTC --- (In reply to comment #3) I will try building svn revision 152973 on an x86-64 box, and see if the problem can be reproduced there. I built fully bootstrapped the gcc/g++ compiler based on the 4.3 branch revision 152973 on an x86-64 FC15 platform and couldn't replicate the failure. On the SUES 11.1 IA64 platform, I built the 4.5.4 release compiler from sources via a full bootstrap. There is no segfault. It is looking like this failure is particular to the installed 4.3.4 g++ compiler. If I have time, I might try rebuilding that version on this IA64 system and see if the bug replicates. It seems that this bug report will likely be resolved as works for me, and we'll need to build with the 4.5.4 compiler.
[Bug c/55570] New: Undefined variable in alignment compiler directive causes compiler segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55570
Bug #: 55570
Summary: Undefined variable in alignment compiler directive
causes compiler segfault
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: david.wette...@gmail.com
Created attachment 28857
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28857
.i file that generates compiler segfault
Version:
$ gcc --version
gcc (GCC) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
System Type:
$ uname -a
Linux david-pc 3.6.8-1-ARCH #1 SMP PREEMPT Mon Nov 26 22:10:40 CET 2012 x86_64
GNU/Linux
Compiler command:
gcc -c test.c -o test
Compiler output:
$ gcc -c test.c -o test
test.c:1:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugs.archlinux.org/ for instructions.
C code:
char array[16] __attribute__((aligned (SOME_NOT_DEFINED_MACRO)));
int main() {
return 0;
}
.i file attached.
[Bug sanitizer/55521] many instances of ASAN:SIGSEGV failures in g++ testsuite with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55521 Dmitry Vyukov dvyukov at google dot com changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #18 from Dmitry Vyukov dvyukov at google dot com 2012-12-03 04:08:52 UTC --- (In reply to comment #17) Revised patch posted at http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00084.html. Also tested with a build of xplor-nih (a complex mix of c, c++ and fortran code) which has always had optimization issues with FSF gcc (as xplor-nih has its own heap memory manager routines in fortran). A build of xplor-nih with -fsanitize=address produced 41 failures out of 154 tests but all of the failures emitted AddressSanitizer output (often unknown-crash on address) rather than segfaulting. I guess it's asan signal handler transforms paging faults into unknown-crash on address. But the real asan reports, do they make sense? I mean is it real bugs in user code, or some nonsense?
[Bug ada/55243] STAMP variable is not defined in t-avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-03 06:39:56 UTC --- And in config.gcc there is tmake_file=avr/t-avr avr/t-multilib Thus, the assumption is that AWK, SHELL and STAMP are set correctly and respective tools are available on the build platform. OK, but the question is why this rule is invoked during the gnattools build? Moreover, why does s-avr-mlib need to be rebuilt at this point since it has presumably already been built for the target libraries?
[Bug bootstrap/55566] [4.8 regression] segfault during build (related to recent vec re-implementation?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55566 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-12-03 06:45:32 UTC --- Thanks for the experiment. I think that you just need to always bootstrap the compiler (i.e. don't pass --disable-bootstrap) since it's precisely designed to avoid this kind of problems. For cross-compilers, the trick is to bootstrap a native compiler and use it to build them.
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 --- Comment #26 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-03 06:56:02 UTC --- Author: ktietz Date: Mon Dec 3 06:55:55 2012 New Revision: 194066 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194066 Log: PR target/53912 * pointer-set.c (hash1): Cast from pointer via uintptr_t. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/pointer-set.c
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 --- Comment #27 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-03 06:56:27 UTC --- Author: ktietz Date: Mon Dec 3 06:56:16 2012 New Revision: 194067 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194067 Log: PR target/53912 * pointer-set.c (hash1): Cast from pointer via uintptr_t. Modified: trunk/gcc/ChangeLog trunk/gcc/pointer-set.c
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 --- Comment #28 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-03 07:01:50 UTC --- Author: ktietz Date: Mon Dec 3 07:01:43 2012 New Revision: 194069 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194069 Log: PR target/53912 * tree-dump.c (dump_pointer): Print pointer via HOST_WIDE_INT_PRINT. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/tree-dump.c
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 --- Comment #29 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-03 07:02:26 UTC --- Author: ktietz Date: Mon Dec 3 07:02:17 2012 New Revision: 194070 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194070 Log: PR target/53912 * tree-dump.c (dump_pointer): Print pointer via HOST_WIDE_INT_PRINT. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-dump.c
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 --- Comment #30 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-03 07:04:56 UTC --- Author: ktietz Date: Mon Dec 3 07:04:50 2012 New Revision: 194071 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194071 Log: PR target/53912 * ggc-common.c (POINTER_HASH): Cast from pointer via intptr_t. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/ggc-common.c
[Bug bootstrap/53912] [4.7/4.8 Regression] bootstrap fails using default c++ mode in stage 2 and 3 for native x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53912 --- Comment #31 from Kai Tietz ktietz at gcc dot gnu.org 2012-12-03 07:05:31 UTC --- Author: ktietz Date: Mon Dec 3 07:05:26 2012 New Revision: 194072 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194072 Log: PR target/53912 * ggc-common.c (POINTER_HASH): Cast from pointer via intptr_t. Modified: trunk/gcc/ChangeLog trunk/gcc/ggc-common.c
[Bug fortran/55568] [4.8 regression] FAIL: gfortran.dg/allocate_error_4.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55568 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-12-03 07:17:25 UTC --- Fixed by revision 194052.
[Bug fortran/55567] [4.8 regression] FAIL: gfortran.dg/typebound_operator_18.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55567 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-12-03 07:18:14 UTC --- Fixed by revision 194052.
[Bug sanitizer/55561] TSAN crashes for Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-12-03 07:41:29 UTC --- (In reply to comment #5) Are you testing with all the pending unreviewed TSAN fixes? Ah.. no, I will retest once they are in trunk. Thanks!
