[Bug tree-optimization/64357] New: ICE at -Os on x86_64-linux-gnu in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64357 Bug ID: 64357 Summary: ICE at -Os on x86_64-linux-gnu in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:579 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu The following code causes an ICE when compiled with the current gcc trunk at -Os on x86_64-linux-gnu in both 32-bit and 64-bit modes. It is a regression from 4.9.x. $ gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix gcc version 5.0.0 20141218 (experimental) [trunk revision 218871] (GCC) $ $ gcc-trunk -O1 -c small.c $ gcc-trunk -O2 -c small.c $ gcc-4.9 -Os -c small.c $ $ gcc-trunk -Os -c small.c small.c: In function ‘fn3’: small.c:25:1: internal compiler error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:579 fn3 () ^ 0xbb7c5f check_loop_closed_ssa_use ../../gcc-trunk/gcc/tree-ssa-loop-manip.c:579 0xbb97da verify_loop_closed_ssa(bool) ../../gcc-trunk/gcc/tree-ssa-loop-manip.c:624 0x9a8026 execute_function_todo ../../gcc-trunk/gcc/passes.c:1955 0x9a88b3 execute_todo ../../gcc-trunk/gcc/passes.c:1997 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. $ --- int a, b, c, d, e, f; long long fn1 (int p) { return p ? p : 1; } static int fn2 () { lbl: for (; f;) return 0; for (;;) { for (b = 0; b; ++b) if (d) goto lbl; c = e; } } void fn3 () { for (; a; a = fn1 (a)) { fn2 (); e = 0; } }
[Bug c++/63723] Narrowing conversion allowed in braced init list in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723 --- Comment #8 from Tavian Barnes --- Actually it is a regression: according to http://gcc.godbolt.org/, GCC 4.6.4 compiled it correctly with -std=c++0x and typedef decltype(helper(0)) type; instead of using type = decltype(helper(0)); while still allowing int x{1.0};
[Bug c++/64356] New: Some constexpr expressions not recognized as constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64356 Bug ID: 64356 Summary: Some constexpr expressions not recognized as constexpr Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sneves at dei dot uc.pt Consider the following snippet: template constexpr uint64_t f(const char (&x)[N]) { uint64_t s = 0; #if defined(FAILS) for(uint64_t c : x) s += c; #else for(size_t i = 0; i < N; ++i) s += x[i]; #endif return s; } template constexpr uint64_t g(const char (&x)[N]) { char y[N] = {0}; for(size_t i = 0; i < N; ++i) y[i] = x[i]; #if defined(FAILS) return f(y); #else return f(x); #endif } constexpr auto x = g(__DATE__); When FAILS is defined, GCC (trunk, 20141219) refuses to recognize x as a constant expression, while with FAILS undefined it works as expected. Clang accepts both variants.
[Bug rtl-optimization/63259] Detecting byteswap sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259 --- Comment #13 from Oleg Endo --- (In reply to thopre01 from comment #12) > > That's good, it means the pattern is recognized. Is there an optab defined > for bswap16? Nope. Just this: (define_insn "rotlhi3_8" [(set (match_operand:HI 0 "arith_reg_dest" "=r") (rotate:HI (match_operand:HI 1 "arith_reg_operand" "r") (const_int 8)))] "TARGET_SH1" "swap.b%1,%0" [(set_attr "type" "arith")]) If I remember correctly, there was something that would check whether it can use the rotate pattern instead of a bswaphi2. After adding the following pattern: (define_expand "bswaphi2" [(set (match_operand:HI 0 "arith_reg_dest") (bswap:HI (match_operand:HI 1 "arith_reg_operand")))] "TARGET_SH1" { if (!can_create_pseudo_p ()) FAIL; else { emit_insn (gen_rotlhi3_8 (operands[0], operands[1])); DONE; } }) it looks much better. The cases above work, except for the signed short. On SH the bswap:HI HW insn actually doesn't modify the upper 16 bit of the 32 bit register. What it does is: unsigned int test_0999 (unsigned int a, unsigned int b) { return (a & 0x) | ((a & 0xFF00) >> 8) | ((a & 0xFF) << 8); } I was afraid that using a bswap:HI will result in unnecessary code around it: mov.l.L6,r0 ! r0 = 0x andr4,r0 extu.wr4,r4 swap.br4,r4 rts orr4,r0 In my case, combine is looking for the pattern: Failed to match this instruction: (set (reg:SI 172 [ D.1356 ]) (ior:SI (ior:SI (and:SI (ashift:SI (reg/v:SI 170 [ a ]) (const_int 8 [0x8])) (const_int 65280 [0xff00])) (zero_extract:SI (reg/v:SI 170 [ a ]) (const_int 8 [0x8]) (const_int 8 [0x8]))) (and:SI (reg/v:SI 170 [ a ]) (const_int -65536 [0x] Which should then work. > > Same as the other pattern, can you try to print n->n in hex with this new > limit? My guess is that the pattern is now recognized but fails later for > the same reason as above. With increased limit, the number is/was the same. The bswap:HI expander was missing. Thanks!
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851 --- Comment #13 from Dominique d'Humieres --- > I can confirm that the proposed patch from comment 11 along with the one > from comment 5 eliminates all of the fortran test suite regressions > on x86_64-apple-darwin14 at r218871. Confirmed. Apparently the patch in comment 11 also fixes the cats failures (pr63852), see https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg02352.html. Thanks for the fix.
[Bug target/60563] FAIL: g++.dg/ext/sync-4.C on *-apple-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60563 howarth at bromo dot med.uc.edu changed: What|Removed |Added CC||howarth at bromo dot med.uc.edu --- Comment #10 from howarth at bromo dot med.uc.edu --- (In reply to Iain Sandoe from comment #9) > sadly, this seems to be a ld64 bug - present when using uncompressed EH > (which is the default for GCC on darwin). > Have you opened a radar upstream for this ld64 bug?
[Bug c++/63723] Narrowing conversion allowed in braced init list in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #7 from Paolo Carlini --- Done.
[Bug c++/63723] Narrowing conversion allowed in braced init list in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723 --- Comment #6 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Dec 19 00:02:05 2014 New Revision: 218880 URL: https://gcc.gnu.org/viewcvs?rev=218880&root=gcc&view=rev Log: 2014-12-18 Paolo Carlini PR c++/63723 * g++.dg/cpp0x/sfinae54.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae54.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/63723] Narrowing conversion allowed in braced init list in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-18 Ever confirmed|0 |1 --- Comment #5 from Paolo Carlini --- This isn't a regression, thus for the time being I'm going to simply add a testcase. If you want to argue for a backport, please figure out the commit which fixed the bug and send a message to gcc-patches.
[Bug c++/64105] [4.9/5 Regression] ICE: in strip_typedefs, at cp/tree.c:1326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64105 --- Comment #3 from Jason Merrill --- Author: jason Date: Thu Dec 18 23:53:15 2014 New Revision: 218879 URL: https://gcc.gnu.org/viewcvs?rev=218879&root=gcc&view=rev Log: PR c++/64105 * parser.c (cp_parser_simple_type_specifier): Make auto parameter before -std=c++14 an error. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/59204] Incorrect metaprogram evaluation in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59204 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Paolo Carlini --- Done. Note: in r217250 Jason implemented the resolution of Core/1558.
[Bug c++/59204] Incorrect metaprogram evaluation in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59204 --- Comment #3 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Dec 18 23:43:46 2014 New Revision: 218878 URL: https://gcc.gnu.org/viewcvs?rev=218878&root=gcc&view=rev Log: 2014-12-18 Paolo Carlini PR c++/59204 * g++.dg/cpp0x/sfinae53.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/sfinae53.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/59204] Incorrect metaprogram evaluation in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59204 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-18 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini --- This works in mainline. I'm adding the testcase and closing the bug.
[Bug fortran/64209] [OOP] runtime segfault with CLASS(*), INTENT(OUT) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64209 --- Comment #6 from janus at gcc dot gnu.org --- Here is a reduced test case for the remaining segfault: PROGRAM main IMPLICIT NONE INTEGER :: copy_x(3) CALL copy(1,copy_x) PRINT *, copy_x CONTAINS SUBROUTINE copy(x,a) integer, INTENT(IN) :: x CLASS(*), INTENT(OUT) :: a(:) SELECT TYPE(a); TYPE IS(integer) a(:) = x END SELECT END SUBROUTINE END PROGRAM It's a very similar scheme as in comment #2, only this time we have an array-valued CLASS(*), INTENT(OUT) argument. I think the problem is with _def_init being NULL again. For the array case here the dump shown a line like: a->_vptr->_copy (a->_vptr->_def_init, &a->_data); Again we need a conditional check for _def_init being non-NULL.
[Bug fortran/64209] [OOP] runtime segfault with CLASS(*), INTENT(OUT) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64209 --- Comment #5 from janus at gcc dot gnu.org --- (In reply to janus from comment #4) > The following patch is sufficient to make the reduced test case in comment 2 > work: ... but unfortunately it caused a number of testsuite regressions. The following variant is clean: Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(Revision 218874) +++ gcc/fortran/trans-expr.c(Arbeitskopie) @@ -943,7 +943,7 @@ tree gfc_trans_class_init_assign (gfc_code *code) { stmtblock_t block; - tree tmp; + tree tmp, cond; gfc_se dst,src,memsz; gfc_expr *lhs, *rhs, *sz; @@ -980,6 +980,12 @@ gfc_trans_class_init_assign (gfc_code *code) src.expr = gfc_build_addr_expr (NULL_TREE, src.expr); tmp = gfc_build_memcpy_call (dst.expr, src.expr, memsz.expr); + + cond = fold_build2_loc (input_location, NE_EXPR, boolean_type_node, + src.expr, fold_convert (TREE_TYPE (src.expr), + null_pointer_node)); + tmp = build3_loc (input_location, COND_EXPR, TREE_TYPE (tmp), cond, tmp, +build_empty_stmt (input_location)); } if (code->expr1->symtree->n.sym->attr.optional Still, it does not cure the segfault in comment 0.
[Bug c++/54442] [4.8/4.9 Regression] Const overloads resolution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54442 Volker Reichelt changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.2.0, 4.3.0, 4.4.0 Keywords||ice-on-valid-code Last reconfirmed||2014-12-18 CC||reichelt at gcc dot gnu.org Ever confirmed|0 |1 Summary|Const overloads resolution |[4.8/4.9 Regression] Const |failure |overloads resolution ||failure Target Milestone|--- |4.8.4 Known to fail||4.5.0, 4.6.0, 4.7.0, 4.8.0 --- Comment #5 from Volker Reichelt --- Marc's testcase from comment#2 demonstrates a regression that was introduced in GCC 4.5.0.
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851 --- Comment #12 from howarth at bromo dot med.uc.edu --- I can confirm that the proposed patch from comment 11 along with the one from comment 5 eliminates all of the fortran testsuite regressions on x86_64-apple-darwin14 at r218871.
[Bug c++/64352] [5.0 regression] No SFINAE with deleted function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64352 --- Comment #1 from Jason Merrill --- Author: jason Date: Thu Dec 18 22:22:42 2014 New Revision: 218877 URL: https://gcc.gnu.org/viewcvs?rev=218877&root=gcc&view=rev Log: PR c++/64352 * pt.c (tsubst_copy_and_build): Pass complain to mark_used. Added: trunk/gcc/testsuite/g++.dg/cpp0x/deleted9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/64251] [5 Regression] Chromium build error only with --enable-checking=yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64251 --- Comment #2 from Jason Merrill --- Author: jason Date: Thu Dec 18 22:22:36 2014 New Revision: 218876 URL: https://gcc.gnu.org/viewcvs?rev=218876&root=gcc&view=rev Log: PR c++/64251 * decl2.c (mark_used): Don't mark if in_template_function. Added: trunk/gcc/testsuite/g++.dg/template/non-dependent14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c
[Bug fortran/64209] [OOP] runtime segfault with CLASS(*), INTENT(OUT) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64209 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org --- Comment #4 from janus at gcc dot gnu.org --- The following patch is sufficient to make the reduced test case in comment 2 work: Index: gcc/fortran/trans-expr.c === --- gcc/fortran/trans-expr.c(Revision 218874) +++ gcc/fortran/trans-expr.c(Arbeitskopie) @@ -980,6 +980,9 @@ gfc_trans_class_init_assign (gfc_code *code) src.expr = gfc_build_addr_expr (NULL_TREE, src.expr); tmp = gfc_build_memcpy_call (dst.expr, src.expr, memsz.expr); + + tmp = build3_loc (input_location, COND_EXPR, TREE_TYPE (tmp), +src.expr, tmp, build_empty_stmt (input_location)); } if (code->expr1->symtree->n.sym->attr.optional However, the original test case in comment 0 still segfaults, so there seems to be yet another problem.
[Bug fortran/64355] [4.9/5 Regression] ICE (segfault) in gfc_zero_size_array with -fcoarray=single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64355 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- The problem arises in interface.c at 1210. if (s1->as->type == AS_EXPLICIT) for (i = 0; i < s1->as->rank + s1->as->corank; i++) { shape1 = gfc_subtract (gfc_copy_expr (s1->as->upper[i]), gfc_copy_expr (s1->as->lower[i])); shape2 = gfc_subtract (gfc_copy_expr (s2->as->upper[i]), gfc_copy_expr (s2->as->lower[i])); (gdb) print *s1->as $4 = {rank = 0, corank = 1, type = AS_EXPLICIT, cotype = AS_EXPLICIT, lower = {0x20348b240, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, upper = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, cray_pointee = false, cp_was_assumed = false} (gdb) print *s2->as $5 = {rank = 0, corank = 1, type = AS_EXPLICIT, cotype = AS_EXPLICIT, lower = {0x20348b540, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, upper = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, cray_pointee = false, cp_was_assumed = false} Both s1->as->upper[0] and s2->as->upper[0] are NULL. gfc_copy_expr() returns NULL, so the code is gfc_subtract(NULL, 0x20348b240). Well, gfc_subtract isn't expecting a NULL.
[Bug rtl-optimization/64291] [5 Regression] Miscompile t-div in GMP's testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Marc Glisse --- Thanks!
[Bug fortran/64209] [OOP] runtime segfault with CLASS(*), INTENT(OUT) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64209 --- Comment #3 from janus at gcc dot gnu.org --- -fdump-tree-original shows the following dump of the copy function (with gfortran 4.8): copy (integer(kind=4) & restrict a, struct __class__STAR & restrict b) { { integer(kind=4) * __tmp_INTEGER_4; (void) __builtin_memcpy (b->_data, (void *) b->_vptr->_def_init, (unsigned long) b->_vptr->_size); switch (b->_vptr->_hash) { case 177599:; __tmp_INTEGER_4 = (integer(kind=4) *) b->_data; *__tmp_INTEGER_4 = *a; L.5:; goto L.3; } L.3:; L.2:; L.1:; } } With 4.9 and trunk additional code is initialized for calling a finalizer, but since the failure occurs already with 4.8, the problem must be in here already. Now, the error goes away if one removes the INTENT(OUT). The only thing that changes in the dump is that the __builtin_memcpy call is removed, which means that this line must be the cuplrit. After staring at it for a while, I concluded that the call to __builtin_memcpy itself looks fine. The problem is that the _def_init component is NULL in the case at hand (which can be seen the full dump, not shown here). So I guess all were missing is a line like if (b->_vptr->_def_init != NULL) before the __builtin_memcpy.
[Bug rtl-optimization/64291] [5 Regression] Miscompile t-div in GMP's testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291 --- Comment #6 from Vladimir Makarov --- Author: vmakarov Date: Thu Dec 18 20:49:44 2014 New Revision: 218874 URL: https://gcc.gnu.org/viewcvs?rev=218874&root=gcc&view=rev Log: 2014-12-18 Vladimir Makarov PR rtl-optimization/64291 * lra-remat.c (bad_for_rematerialization_p): Add UNPSEC_VLOATILE. (create_cands): Process only output reload insn with potential cands. 2014-12-18 Vladimir Makarov PR rtl-optimization/64291 * testsuite/gcc.target/i386/pr64291-[12].c: New tests. Added: trunk/gcc/testsuite/gcc.target/i386/pr64291-1.c trunk/gcc/testsuite/gcc.target/i386/pr64291-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-remat.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/64355] [4.9/5 Regression] ICE (segfault) in gfc_zero_size_array with -fcoarray=single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64355 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-18 Known to work||4.8.4 Summary|ICE (segfault) in |[4.9/5 Regression] ICE |gfc_zero_size_array with|(segfault) in |-fcoarray=single|gfc_zero_size_array with ||-fcoarray=single Ever confirmed|0 |1 Known to fail||4.9.3, 5.0 --- Comment #1 from Dominique d'Humieres --- Confirmed on 4.9.3 and trunk (5.0). 4.8.4 compiles the code without error.
[Bug fortran/64355] New: ICE (segfault) in gfc_zero_size_array with -fcoarray=single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64355 Bug ID: 64355 Summary: ICE (segfault) in gfc_zero_size_array with -fcoarray=single Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org The following program ICEs (segfaults) in 0x607cbb gfc_zero_size_array ../../gcc/fortran/arith.c:1637 when compiled with gfortran -fcoarray=single module m type t integer, allocatable :: a(:) end type t end module m program main use m type(t), save :: caf[*] interface subroutine sub1(x) import :: t type(t) :: x[*] end subroutine sub1 end interface call sub1(caf) end program main subroutine sub1(x) use m type(t) :: x[*] end subroutine sub1
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #56 from Francois-Xavier Coudert --- Author: fxcoudert Date: Thu Dec 18 20:12:44 2014 New Revision: 218873 URL: https://gcc.gnu.org/viewcvs?rev=218873&root=gcc&view=rev Log: PR target/61407 * config/darwin-c.c (version_as_macro): Added extra 0 for OS X 10.10 and above. * config/darwin-driver.c (darwin_find_version_from_kernel): Removed kernel version check to avoid incrementing it after every major OS X release. (darwin_default_min_version): Avoid static memory buffer. * gcc.dg/darwin-minversion-1.c: Fixed formatting * gcc.dg/darwin-minversion-2.c: Fixed formatting * gcc.dg/darwin-minversion-3.c: Fixed formatting * gcc.dg/darwin-minversion-4.c: Added test for OS X 10.10 Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/darwin-minversion-4.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/darwin-c.c branches/gcc-4_8-branch/gcc/config/darwin-driver.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/darwin-minversion-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/darwin-minversion-2.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/darwin-minversion-3.c
[Bug lto/64343] [5 Regression] lto compile options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343 --- Comment #5 from Jan Hubicka --- Yep, I am slowly working on that: still need to finish upatin ipa passes for per-function flags (ipa-reference/ipa-icf are two remaining) and we need to figure out what to do with flags that arenot marked Optimization but still affects codegen. Honza > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343 > > --- Comment #4 from Richard Biener --- > Note that we should update the documentation about this change (and throw away > all option handling of optimize/target attribute handled options from > lto-wrapper, > or rather move all of that handling to lto1). > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug fortran/64209] [OOP] runtime segfault with CLASS(*), INTENT(OUT) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64209 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||janus at gcc dot gnu.org Summary|[OOP] copy class(*) |[OOP] runtime segfault with |component from type with a |CLASS(*), INTENT(OUT) dummy |subroutine |argument --- Comment #2 from janus at gcc dot gnu.org --- I could boil it down to this much simpler case: PROGRAM main IMPLICIT NONE INTEGER :: x, y x = 5 CALL copy(x,y) PRINT *,y contains SUBROUTINE copy(a,b) integer, INTENT(IN) :: a CLASS(*), INTENT(OUT) :: b SELECT TYPE(b); TYPE IS(integer) b = a END SELECT END SUBROUTINE END Segfaults with 4.8, 4.9 and trunk. Earlier versions don't support unlimited polymorphism. Had a quick look over the dump, but could not directly see where things go wrong.
[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #8 from Dmitry Vyukov --- Is there any progress on this? Is it fixed? I've hit this issue in ThreadSanitizer. It intercepts __tls_get_addr and then code that uses MOVDQA [rbp] crashes. I remember that I hit it previously in some other context as well.
[Bug c++/60955] [4.9/5 Regression] Erroneous warning about taking address of register with std=c++1y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60955 --- Comment #8 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Dec 18 17:53:55 2014 New Revision: 218871 URL: https://gcc.gnu.org/viewcvs?rev=218871&root=gcc&view=rev Log: /cp 2014-12-18 Paolo Carlini PR c++/60955 * pt.c (struct warning_sentinel): Move it... * cp-tree.h: ... here. * semantics.c (force_paren_expr): Use it. /testsuite 2014-12-18 Paolo Carlini PR c++/60955 * g++.dg/warn/register-parm-1.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/register-parm-1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/61402] -Wsequence-point doesn't notice unsequenced lambda init and function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61402 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|[5 Regression][C++1y] |-Wsequence-point doesn't |Init-capture with side |notice unsequenced lambda |effect not working for some |init and function argument |types | --- Comment #5 from Jason Merrill --- Updating summary.
[Bug c++/64352] [5.0 regression] No SFINAE with deleted function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64352 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-18 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug sanitizer/64354] New: no preprocessor symbol __SANITIZE_THREAD__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64354 Bug ID: 64354 Summary: no preprocessor symbol __SANITIZE_THREAD__ Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: rrh at newrelic dot com 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 compiling gcc -fsanitize=thread does not pre-define preprocessor symbol __SANITIZE_THREAD__ (bad) however, compiling gcc -fsanitize=address does pre-define preprocessor symbol __SANITIZE_ADDRESS__ (good) The situations should be symmetric. I would suggest adding __SANITIZE_THREAD__ rather than deleting __SANITIZE_ADDRESS__.
[Bug c++/64353] New: ICE: in execute_todo, at passes.c:1986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64353 Bug ID: 64353 Summary: ICE: in execute_todo, at passes.c:1986 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: adam at os dot inf.tu-dresden.de The following code generates an ICE: class C { int y, x; void i(); bool __attribute__((const)) xx() { return x; } }; void C::i() { if (xx()) x = 1; } $ g++ -c -O2 t.i t.i: In member function ‘void C::i()’: t.i:12:1: internal compiler error: in execute_todo, at passes.c:1986 } ^ 0xbc7b28 execute_todo ../../gcc/gcc/passes.c:1986 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. $ g++ --version g++ (GCC) 5.0.0 20141218 (experimental) Admittedly the attribute((const)) should not be there. Also, removing 'y' will also not emit an ICE.
[Bug target/64011] Fail to compile pr48335-2.c on big-endian where bit insert instruction supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64011 --- Comment #2 from Jiong Wang --- the problem is we do overflow checking at the start of store_bit_field_1, but that only check the situation where the field lies completely outside the register, while there do have situation where the field lies partialy in the register, we need to adjust bitsize for this partial overflow situation in store_bit_field_using_insv. will send out patch after testing ok
[Bug c++/63889] [5 Regression] Ice with redundant static in class scope constexpr variable template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63889 --- Comment #5 from Jason Merrill --- (In reply to Kai Tietz from comment #4) is_ok has two levels of template parameters: its own and those for A. An instantiation needs to provide both levels of args as well. It seems that we're missing a call to add_outermost_template_args for variable templates.
[Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63851 --- Comment #11 from Martin Liška --- Hello. The problem is caused by missing static-chain in newly created GIMPLE_CALL in expand_thunk: fpi (struct array7_integer(kind=4) & xx1, struct array7_t & yy1) { : fpa (xx1_2(D), yy1_3(D)); [tail call] return; } where: main (integer(kind=4) argc, character(kind=1) * * argv) { ... fpa (&desc.2, &desc.3); [static-chain: &FRAME.7] fpi (&desc.4, &desc.5); [static-chain: &FRAME.7] ... } I've been testing following patch that stops ICF for such kind of situations: diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c index b193200..7faaf56 100644 --- a/gcc/ipa-icf.c +++ b/gcc/ipa-icf.c @@ -685,6 +685,14 @@ sem_function::merge (sem_item *alias_item) return 0; } + if (DECL_STATIC_CHAIN (alias->decl)) +{ + if (dump_file) + fprintf (dump_file, "Thunk creation is risky for static-chain functions.\n\n"); + + return 0; +} + alias->icf_merged = true; ipa_merge_profiles (local_original, alias); alias->create_wrapper (local_original); Thanks, Martin
[Bug c++/64251] [5 Regression] Chromium build error only with --enable-checking=yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64251 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-18 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/64352] New: [5.0 regression] No SFINAE with deleted function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64352 Bug ID: 64352 Summary: [5.0 regression] No SFINAE with deleted function Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Created attachment 34300 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34300&action=edit Minimal testcase Using: g++-trunk (GCC) 5.0.0 20141218 (experimental) Testcase: template struct bool_type { static constexpr bool value = B; }; using true_type = bool_type; using false_type = bool_type; template T&& declval(); template struct void_ { using type = void; }; template using void_t = typename void_::type; template struct _Has_addressof_free: false_type { }; template struct _Has_addressof_free <_Tp, void_t()) )>> : true_type { }; struct foo {}; void operator&(foo) = delete; int main() { static_assert( !_Has_addressof_free::value, "" ); // error: use of deleted function 'void operator&(foo)' static_assert( _Has_addressof_free::value, "" ); } This produces the following: $ g++-trunk -std=c++11 main.cpp main.cpp: In function 'int main()': main.cpp:17:33: error: use of deleted function 'void operator&(foo)' <_Tp, void_t()) )>> ^ main.cpp:21:6: note: declared here void operator&(foo) = delete; ^ main.cpp:27:5: error: static assertion failed: static_assert( _Has_addressof_free::value, "" ); ^ I'm not entirely sure this is a regression, e.g. libstdc++'s testsuite/experimental/optional/observers/2.cc is very similar but passes. I'm working on experimental/optional however and I ended up tripping over this, and I didn't touch the _Has_addressof_* stuff. It is copied (almost) verbatim here, but not the declval/true_type/false_type/[__]void[_t] bits, in case that's of any help. Changing the deleted definition with e.g. a dummy definition ('{}') makes the program compiles as expected.
[Bug rtl-optimization/64291] [5 Regression] Miscompile t-div in GMP's testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64291 --- Comment #5 from Vladimir Makarov --- The bug is new rematerialization sub-pass in LRA. I'll be working on it.
[Bug libstdc++/64351] New: std::uniform_real_distribution(0, 1) returns 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64351 Bug ID: 64351 Summary: std::uniform_real_distribution(0, 1) returns 1 Product: gcc Version: 3.3.6 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: info at jmeng dot de I'm seeing std::uniform_real_distribution(0, 1) return 1 even though the standard seems to say it shouldn't: "A uniform_real_distribution random number distribution produces random numbers x, a ≤ x < b" (I looked at the draft available here: http://www.open-std.org/JTC1/SC22/WG21/ or specifically here: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2011/n3242.pdf) There is a relatively minimal working example you can try here: http://coliru.stacked-crooked.com/a/4ca5b4ac05e990ff Or, if you prefer to see the code directly: // This program outputs 1, but uniform_real_distribution is supposed // to return values in [0, 1) (the half open interval). #include #include #include int main() { std::mt19937 rng(8890); std::uniform_real_distribution dist; uint64_t num_1 = 0; for (uint64_t i = 0; i < 39975715; ++i) { if (dist(rng) == 1.f) ++num_1; } std::cout << num_1 << std::endl; return 0; } Note that there is a related note in this bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43660#c2
[Bug sanitizer/64350] TSAN fails after stress-testing for a while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64350 Dmitry Vyukov changed: What|Removed |Added CC||dvyukov at google dot com --- Comment #1 from Dmitry Vyukov --- I've fixed a bunch of bugs in deadlock detector just few hours ago. Please re-test with these fixes: http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_deadlock_detector.h?r1=224518&r2=224517&pathrev=224518 http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_deadlock_detector.h?r1=224519&r2=224518&pathrev=224519 I've also added a random stress test, and I think I saw your crash during testing. It does not happen for me with the fixes.
[Bug sanitizer/64350] New: TSAN fails after stress-testing for a while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64350 Bug ID: 64350 Summary: TSAN fails after stress-testing for a while Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de 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 Hello, I see this fatal error from the thread sanitizer, after a while of stress-testing. As far as I can tell the application should not hold 64 locks at that time. Any ideas what that could be wrong here? Thanks, Bernd. FATAL: ThreadSanitizer CHECK failed: ../../../../gcc-5-20141214/libsanitizer/sanitizer_common/sanitizer_deadlock_detector.h:65 "((n_all_locks_)) < (((sizeof(all_locks_with_contexts_)/sizeof((all_locks_with_contexts_)[0]" (0x40, 0x40) #0 __tsan::TsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../gcc-5-20141214/libsanitizer/tsan/tsan_rtl_report.cc:42 (libtsan.so.0+0x00071793) #1 __tsan::TsanCheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../gcc-5-20141214/libsanitizer/tsan/tsan_rtl_report.cc:42 (libtsan.so.0+0x0007179b) #2 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../gcc-5-20141214/libsanitizer/sanitizer_common/sanitizer_common.cc:72 (libtsan.so.0+0x000761b3) #3 __sanitizer::DeadlockDetectorTLS<__sanitizer::TwoLevelBitVector<1ul, __sanitizer::BasicBitVector > >::addLock(unsigned long, unsigned long, unsigned int) ../../../../gcc-5-20141214/libsanitizer/sanitizer_common/sanitizer_deadlock_detector.h:65 (libtsan.so.0+0x00079eed) #4 __sanitizer::DeadlockDetector<__sanitizer::TwoLevelBitVector<1ul, __sanitizer::BasicBitVector > >::onLockAfter(__sanitizer::DeadlockDetectorTLS<__sanitizer::TwoLevelBitVector<1ul, __sanitizer::BasicBitVector > >*, unsigned long, unsigned int) ../../../../gcc-5-20141214/libsanitizer/sanitizer_common/sanitizer_deadlock_detector.h:214 (libtsan.so.0+0x00079eed) #5 __sanitizer::DD::MutexAfterLock(__sanitizer::DDCallback*, __sanitizer::DDMutex*, bool, bool) ../../../../gcc-5-20141214/libsanitizer/sanitizer_common/sanitizer_deadlock_detector1.cc:162 (libtsan.so.0+0x00079eed) #6 __tsan::MutexLock(__tsan::ThreadState*, unsigned long, unsigned long, int, bool) ../../../../gcc-5-20141214/libsanitizer/tsan/tsan_rtl_mutex.cc:177 (libtsan.so.0+0x0006e1e5) #7 pthread_mutex_lock ../../../../gcc-5-20141214/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:2993 (libtsan.so.0+0x000354c7) #8 interlockedSet(long*, long) /home/ed/OPCToolboxV5/Source/Core/TBUtil/Platforms.cpp:55 (CPPTestClient+0x00ee1f06) #9 TB5Util::Sync::lock() include/Sync.h:218 (CPPTestClient+0x00810842) [...] #19 pthread_start platforms/linux/opcua_p_thread.c:63 (CPPTestClient+0x00fb7403) #20 __tsan_thread_start_func ../../../../gcc-5-20141214/libsanitizer/tsan/tsan_interceptors.cc:885 (libtsan.so.0+0x00023a69) #21 start_thread (libpthread.so.0+0x7e99) #22 __clone (libc.so.6+0x000f42ec)
[Bug c++/63889] [5 Regression] Ice with redundant static in class scope constexpr variable template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63889 Kai Tietz changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #4 from Kai Tietz --- Issue is that we don't check for static function for template-parameter-count. So for this sample tmpl has 2 arguments, but in fact it has just 1. Not sure where we add this additional argument. We see for the template-decl 'template template ' ... By allowing args being less then expected template arguments, issue is fixed. But in fact we should check template-params - (is_static ? 1 : 0) ... or something like this.
[Bug c++/58972] Lambda can't access private members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972 --- Comment #11 from Ville Voutilainen --- Reduced further: class base { protected: typedef int type; }; template class derive: public base { public: void foo() { struct f_t { f_t(base::type a) {} }; } }; int main() { derive d; d.foo(); }
[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Martin Liška --- Fixed in 5.0.0.
[Bug tree-optimization/64330] [5 Regression] IPA-ICF merges const exported vars that could be addressable in other TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64330 --- Comment #10 from Martin Liška --- Author: marxin Date: Thu Dec 18 13:32:18 2014 New Revision: 218864 URL: https://gcc.gnu.org/viewcvs?rev=218864&root=gcc&view=rev Log: Fix for PR64330. PR tree-optimization/64330 * ipa-icf.c (sem_variable::parse): Add checking for externally visible symbols and do not introduce an alias for an external declaration. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c
[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342 Igor Zamyatin changed: What|Removed |Added CC||izamyatin at gmail dot com, ||vmakarov at redhat dot com --- Comment #1 from Igor Zamyatin --- avx512f-kandnw-1.c and funcspec-5.c seem to be non-PIC related issues. I asked Kirill to look at them. Others are not stability but more performance issues - generated code is less effective than it should be - in one case for some reasons compiler uses callee-saved ebx in PIC mode instead of edx in non-PIC mode and in xmm case compiler uses stack in PIC mode instead of xmm register in non-PIC mode I see that differencies between PIC and non-PIC modes start on reload pass so I'd like Vlad to look at these cases
[Bug c++/60767] use of "using" inside template causes failure in retreive_specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60767 Kai Tietz changed: What|Removed |Added Status|NEW |RESOLVED CC||ktietz at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Kai Tietz --- Duplicate *** This bug has been marked as a duplicate of bug 61198 ***
[Bug c++/61198] Crash when selecting specializations through aliases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61198 Kai Tietz changed: What|Removed |Added CC||zreed1 at gmail dot com --- Comment #5 from Kai Tietz --- *** Bug 60767 has been marked as a duplicate of this bug. ***
[Bug c++/61198] Crash when selecting specializations through aliases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61198 Kai Tietz changed: What|Removed |Added Status|NEW |ASSIGNED CC||ktietz at gcc dot gnu.org --- Comment #4 from Kai Tietz --- This bug is caused in retrieve_specialization by not checking for innermost template arguments if argument-count is bigger then template-argument-count. This is mine.
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 Martin Liška changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #30 from Martin Liška --- Fixed in 5.0.0.
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 --- Comment #29 from Martin Liška --- Author: marxin Date: Thu Dec 18 12:06:34 2014 New Revision: 218861 URL: https://gcc.gnu.org/viewcvs?rev=218861&root=gcc&view=rev Log: Fix for PR bootstrap/63573. PR bootstrap/63573 * tree-inline.c (remap_gimple_stmt): Handle gimple_call_from_thunk_p predicate. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c
[Bug ipa/64146] [5 Regression] ipa-icf breaks gold dynamic_test_2 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64146 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Fixed in 5.0.0.
[Bug ipa/64146] [5 Regression] ipa-icf breaks gold dynamic_test_2 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64146 --- Comment #7 from Martin Liška --- Author: marxin Date: Thu Dec 18 12:02:22 2014 New Revision: 218860 URL: https://gcc.gnu.org/viewcvs?rev=218860&root=gcc&view=rev Log: Fix for PR ipa/64146 PR ipa/64146 * ipa-icf.c (sem_function::merge): Check for decl_binds_to_current_def_p is newly added to merge operation. * g++.dg/ipa/pr64146.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr64146.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/64349] [5 Regression] Bootstrapping Ada fails on darwin(9|10).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349 --- Comment #2 from Iain Sandoe --- Created attachment 34299 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34299&action=edit proper fix. So, the rules on Darwin say that it's OK to access _environ directly from the main executable, but it is NOT OK to access it from a shared libaray. Instead, one should use the _NSGetEnviron() API). === My initial patch works because it allows the symbol to be satisfied at load time by dynamic lookup (it will be found from the exe, I assume). === The patch attached above uses the correct API - and works AFAICT on powerpc-darwin9 and x86_64-darwin12.
[Bug bootstrap/64349] [5 Regression] Bootstrapping Ada fails on darwin(9|10).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-18 CC||iains at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Bootstrapping Ada fails on darwin(9|10) with ld: warning: can't add line info to anonymous symbol __const@0 from s-arit64.o This can be fixed with the following patch from Iain Sandoe --- ../_clean/gcc/ada/gcc-interface/Makefile.in2014-11-26 10:44:12.0 +0100 +++ gcc/ada/gcc-interface/Makefile.in2014-11-26 10:55:45.0 +0100 @@ -2884,6 +2884,7 @@ gnatlib-shared-darwin: -o libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \ $(GNATRTL_NONTASKING_OBJS) $(LIBGNAT_OBJS) \ $(SO_OPTS) \ +-Wl,-undefined,dynamic_lookup \ -Wl,-install_name,@rpath/libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \ $(MISCLIB) cd $(RTSDIR); `echo "$(GCC_FOR_TARGET)" \ @@ -2891,6 +2892,7 @@ gnatlib-shared-darwin: -o libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \ $(GNATRTL_TASKING_OBJS) \ $(SO_OPTS) \ +-Wl,-undefined,dynamic_lookup \ -Wl,-install_name,@rpath/libgnarl$(hyphen)$(LIBRARY_VERSION)$(soext) \ $(THREADSLIB) -Wl,libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) cd $(RTSDIR); $(LN_S) libgnat$(hyphen)$(LIBRARY_VERSION)$(soext) \
[Bug bootstrap/64349] New: [5 Regression] Bootstrapping Ada fails on darwin(9|10).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64349 Bug ID: 64349 Summary: [5 Regression] Bootstrapping Ada fails on darwin(9|10). Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr
[Bug target/64348] [5 Regression] Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64348 Richard Biener changed: What|Removed |Added Keywords||ra CC||vmakarov at gcc dot gnu.org Target Milestone|--- |5.0 Summary|Case scal-to-vec1.c failed |[5 Regression] Case |on arm-linux-gnueabi with |scal-to-vec1.c failed on |-fPIC |arm-linux-gnueabi with ||-fPIC
[Bug lto/64343] [5 Regression] lto compile options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64343 --- Comment #4 from Richard Biener --- Note that we should update the documentation about this change (and throw away all option handling of optimize/target attribute handled options from lto-wrapper, or rather move all of that handling to lto1).
[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug c++/59383] typedef propagation with template base class using the same name is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59383 naup at sfr dot fr changed: What|Removed |Added CC||naup at sfr dot fr --- Comment #1 from naup at sfr dot fr --- This is the same behaviour as in invalid bug 50418. Alas, no diagnostic is required, says the standard, and gcc interpretes **differently** the typedef type wheither the base is template or not. NON TEMPLATE BASE struct A { typedef A this_type; }; template struct B : public A { typedef this_type parent; // this_type is taken as **A** (current context) typedef B this_type; // the two lines make B ill-formed }; TEMPLATE BASE template struct A { typedef A this_type; }; template struct B : public A { typedef this_type parent; // this_type is taken as **B** (after-next-line context) typedef B this_type; // the two lines make B ill-formed };
[Bug sanitizer/64344] [5 Regression] [UBSAN] ICE with -fsanitize=float-cast-overflow [ICE in -fsanitize=float-cast-overflow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64344 Jakub Jelinek changed: What|Removed |Added Attachment #34297|0 |1 is obsolete|| Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-12-18 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- Created attachment 34298 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34298&action=edit gcc5-pr64344.patch Better patch.
[Bug sanitizer/64344] [5 Regression] [UBSAN] ICE with -fsanitize=float-cast-overflow [ICE in -fsanitize=float-cast-overflow]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64344 --- Comment #2 from Jakub Jelinek --- Created attachment 34297 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34297&action=edit gcc5-pr64344.patch Untested fix, but this is getting way too ugly. Furthermore, e.g. void bar (void) { static const int a = 0.5; static const int b = 1e234; } still fails with C. Wonder what was the reason to instrument it so early, supposedly to not miss conversions optimized away during folding, right?
[Bug fortran/64244] [4.8/4.9/5 Regression] ICE at class.c:236 when using non_overridable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64244 --- Comment #15 from janus at gcc dot gnu.org --- (In reply to Ondřej Čertík from comment #14) > I tested it and it seems to be working! The code compiled with > non_overridable on. Great. Thanks for checking. > There are run-time segfaults and array bounds mismatches in our code, > that don't happen with ifort, so I will be slowly isolating those and > reporting them. That would be very helpful (please use separate PRs for those).
[Bug target/64348] New: Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64348 Bug ID: 64348 Summary: Case scal-to-vec1.c failed on arm-linux-gnueabi with -fPIC Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amker at gcc dot gnu.org Case scal-to-vec1.c failed because of ICE on arm-linux-gnueabi with -fPIC. The compilation command line is: ./arm-none-linux-gnueabi-gcc scal-to-vec1.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O3 -S -fPIC -o ./scal-to-vec1.S -mcpu=cortex-a8/a9 -marm Thumb mode is fine, processors like cortex-a7/a15 are fine. The ICE info is like below: /home/binche01/work/oban-work/src/gcc/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c: In function ‘main’: /home/binche01/work/oban-work/src/gcc/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c:86:1: internal compiler error: in split_reg, at lra-constraints.c:4879 0xbad893 split_reg /home/binche01/work/oban-work/src/gcc/gcc/lra-constraints.c:4879 0xbade33 split_if_necessary /home/binche01/work/oban-work/src/gcc/gcc/lra-constraints.c:4983 0xbafb13 inherit_in_ebb /home/binche01/work/oban-work/src/gcc/gcc/lra-constraints.c:5478 0xbb04fc lra_inheritance() /home/binche01/work/oban-work/src/gcc/gcc/lra-constraints.c:5639 0xb9914b lra(_IO_FILE*) /home/binche01/work/oban-work/src/gcc/gcc/lra.c:2303 0xb48738 do_reload /home/binche01/work/oban-work/src/gcc/gcc/ira.c:5402 0xb48b0e execute /home/binche01/work/oban-work/src/gcc/gcc/ira.c:5573 Gcc is configured as below: --target=arm-none-linux-gnueabi --prefix=... --with-sysroot=... --disable-libssp --disable-libmudflap --enable-checking=yes --enable-languages=c,c++ --with-gmp=... --with-mpfr=... --with-mpc=... --with-isl=... --with-cloog=... --disable-libgomp --with-arch=armv7-a It is from thread https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01448.html File this PR for tracking.