[Bug c++/70588] [5/6 regression] SIGBUS on a VLA larger than SIZE_MAX / 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70588 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- This IMNSHO doesn't qualify as a regression. It has been an experimental feature that has been intentionally removed because it has been removed from the standard.
[Bug middle-end/70580] [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/if-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70580 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-08 Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/70579] [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/host_data-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70579 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-08 Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/70117] ppc long double isinf() is wrong?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117 --- Comment #17 from Alan Modra --- Author: amodra Date: Fri Apr 8 02:11:52 2016 New Revision: 234821 URL: https://gcc.gnu.org/viewcvs?rev=234821&root=gcc&view=rev Log: PR70117, ppc long double isinf gcc/ PR target/70117 * builtins.c (fold_builtin_classify): For IBM extended precision, look at just the high-order double to test for NaN. (fold_builtin_interclass_mathfn): Similarly for Inf. For isnormal test just the high double for Inf but both doubles for subnormal limit. gcc/testsuite/ * gcc.target/powerpc/pr70117.c: New. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr70117.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog
[Bug c++/70587] 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70587 TC changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|6.0 |5.3.0 Resolution|--- |FIXED --- Comment #3 from TC --- Bah, wrong version field. This should be against 5 (because I was using Coliru), but I neglected to test 6.
[Bug c++/70587] 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70587 --- Comment #2 from Jonathan Wakely --- Once more, with line breaks: when a GNU dialect of a standard is specified, all features supported by the compiler are enabled, even when those features change the meaning of the base standard. As a result, some strict-conforming programs may be rejected.
[Bug c++/70587] 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70587 --- Comment #1 from Jonathan Wakely --- It's rejected in -std=gnu++11 and gnu++14 mode, but not -std=c++11 / c++14, which agrees with the documentation for -std: > when a GNU dialect of a standard is specified, all features supported by the > compiler are enabled, even when those features change the meaning of the base > standard. As a result, some strict-conforming programs may be rejected. Hex literals have been supported as a GNU extension for many years, that's one of the reasons they are being standardized for C++17.
[Bug target/70589] New: PowerPC target attribute/pragma cannot set/disable -mfloat128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70589 Bug ID: 70589 Summary: PowerPC target attribute/pragma cannot set/disable -mfloat128 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- The new -mfloat128 support in PowerPC GCC 6 cannot be set via a target attribute or a target pragma. The reason for this is the __float128 and __ibm128 keywords must be created at program initialization type complete with the appropriate types. If you change the float128 setting to on from being off, the keywords are not created. This was noticed that libgcc's emulation routines did not configure properly when the default for -mfloat128 was set off for PR 70381. As a work around, I will submit a patch shortly to disable -mfloat128 or -mfloat128-hardware from being set via the target attribute or target pragma. However, a longer term fix should be to make it work.
[Bug c++/70588] [5/6 regression] SIGBUS on a VLA larger than SIZE_MAX / 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70588 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Known to work||4.9.3 Keywords||wrong-code Last reconfirmed||2016-04-07 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Depends on||69517 Ever confirmed|0 |1 Known to fail||5.3.0, 6.0 --- Comment #1 from Martin Sebor --- I'm marking this bug as dependent on bug 69517 since it makes sense to address both at the same time and wouldn't do much good if one was fixed but not the other. I'm also working on a patch for both bugs so I'm assigning it to myself. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517 [Bug 69517] [5/6 regression] SEGV on a VLA with excess initializer elements
[Bug c++/70588] New: [5/6 regression] SIGBUS on a VLA larger than SIZE_MAX / 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70588 Bug ID: 70588 Summary: [5/6 regression] SIGBUS on a VLA larger than SIZE_MAX / 2 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Similarly to bug 69517, r218655 (partially) removed from G++ support for "Runtime-sized arrays with automatic storage duration" specified in WG21 N3639 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html), leaving only support for ordinary C VLAs. The support, introduced in r198745 and available in GCC 4.9, included limited detection of common VLA errors such as overflow in the VLA bounds. When compiled with GCC 4.9 in c++1y mode the program below is instrumented by GCC to detect the overflow and throw an exception. However, when compiled with GCC 5 or 6, the same program either crashes at runtime due to the stack overflow or simply runs to completion. This is not a new or surprising discovery but because the problem is distinct from bug 69517 I raise a separate bug for it for the record. $ cat v.c && /home/msebor/build/gcc-4.9.3/gcc/xg++ -B/home/msebor/build/gcc-4.9.3/gcc -L /home/msebor/build/gcc-4.9.3/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -O2 -Wall -Wextra -Wpedantic -std=c++1y -xc++ v.c && ./a.out void g (void*) { } void f (__SIZE_TYPE__ n) { char a[n]; g (a); } int main () { volatile __SIZE_TYPE__ n = __SIZE_MAX__ / 2 + 1; try { f (n); __builtin_printf ("VLA bounds overflow failed to throw\n"); } catch (...) { __builtin_printf ("VLA bounds overflow detected\n"); } } VLA bounds overflow detected $ ~/bin/gcc-5.1.0/bin/g++ -O2 -Wall -Wextra -Wpedantic -std=c++14 -xc++ v.c && ./a.out v.c: In function ‘void f(long unsigned int)’: v.c:5:13: warning: ISO C++ forbids variable length array ‘a’ [-Wvla] char a[n]; ^ VLA bounds overflow failed to throw $ ~/bin/gcc-5.1.0/bin/g++ -Wall -Wextra -Wpedantic -std=c++14 -xc++ v.c && ./a.out v.c: In function ‘void f(long unsigned int)’: v.c:5:13: warning: ISO C++ forbids variable length array ‘a’ [-Wvla] char a[n]; ^ Bus error (core dumped)
[Bug c++/70587] New: 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70587 Bug ID: 70587 Summary: 0e1_p+0 should not be parsed as a single pp-number in C++14 and earlier Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- p/P followed by +/- is not part of the pp-number production in C++ before C++17, but GCC includes them anyway. This results in the following code being erroneously rejected in C++11/14 mode: long double operator""_p(long double) { return {}; } auto x = 0e1_p+0; // should be parsed as 0e1_p + 0 // but parsed as a single pp-number instead and rejected
[Bug c++/70529] Unhelpful diagnostic for hex float literals, inconsistent parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529 --- Comment #9 from joseph at codesourcery dot com --- On Thu, 7 Apr 2016, manu at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529 > > --- Comment #8 from Manuel López-Ibáñez --- > (In reply to Axel Naumann from comment #2) > > You asked for it, so here is my wish list: > > - for C++ < 1z, do not support hexfloats, neither with "unsigned" not > > negative exponents. > > Since "unsigned" exponents are supported by standard C++11, g++ has to support > them. They aren't supported in the sense of being valid floating-literals. It's simply the case that if the 'p' or 'P' is followed by a digit, rather than by '+' or '-', then it forms part of the pp-number whatever standard version is in use (and so none of the lexical complications arise that occur in the p+ / p- / P+ / P- cases, so handling p as an extension is easy).
[Bug fortran/69654] ICE in gfc_trans_structure_assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69654 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #2 from Harald Anlauf --- Slightly reduced test case: Module foo_pointers_class implicit none type :: ty_foo_pointers class(*),pointer :: foo => NULL() end type ty_foo_pointers type :: ty_class_basis end type ty_class_basis End Module foo_pointers_class Module foo_class use foo_pointers_class implicit none type,extends(ty_class_basis) :: ty_foo2 type(ty_foo_pointers) :: foo end type ty_foo2 End Module foo_class Module foo_scripts_mod use foo_class, only: ty_foo2 implicit none contains subroutine foo_script1 type(ty_foo2) :: foo2 Call foo_init2(foo2) end subroutine foo_script1 subroutine foo_init2(self) type(ty_foo2),target :: self end subroutine foo_init2 End Module foo_scripts_mod The ICE goes away when the pointer initialization is removed. I think there are similar (related?) PRs.
[Bug c++/70529] Unhelpful diagnostic for hex float literals, inconsistent parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529 --- Comment #8 from Manuel López-Ibáñez --- (In reply to Axel Naumann from comment #2) > You asked for it, so here is my wish list: > - for C++ < 1z, do not support hexfloats, neither with "unsigned" not > negative exponents. Since "unsigned" exponents are supported by standard C++11, g++ has to support them. > Or support both, as a GCC extention that's enabled by > default - like in the GCC 5 times. Given Joseph comments, it seems the "signed" extension is incompatible with standard C++ < 1z. That is, the same valid program may behave differently whether the extension is enabled or not. > - if you remove support for C++ < 1z, state that hexfloats are unsupported > in C++ < 1z. Only "signed" exponents are unsupported. My patch above tries to catch this case and give a better error message, but it is not as trivial as I thought. > NB: Even if I would buy into the argument that diagnostics are limited by > the tokens, I don't yet see why 'P' ends up being concated to the pp-number > token in C++ < 1z. You have to run g++ (actually, cc1plus) under a debugger to see why. See lex_number. Doing it in a different way would probably break a lot of other things.
[Bug testsuite/70581] [6 regression] gcc.dg/lto/simd-function FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70581 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Thu Apr 7 21:45:26 2016 New Revision: 234817 URL: https://gcc.gnu.org/viewcvs?rev=234817&root=gcc&view=rev Log: PR testsuite/70581 * gcc.dg/lto/simd-function_0.c: New test. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/lto/simd-function_0.c
[Bug c++/70529] Unhelpful diagnostic for hex float literals, inconsistent parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529 --- Comment #7 from Manuel López-Ibáñez --- (In reply to Jakub Jelinek from comment #6) > But that wouldn't make any difference between 0x123p-2 and 0x123p - 2 > (or some of them coming from macro, other not etc.). > So perhaps you want to also check the locus of each of the tokens and find > out if they are actually consecutive in the source. Hm, true. That seems more complicated. Possible, but too complicated for me right now. Perhaps Axel wants to give it a try if he thinks it is important enough. Otherwise, perhaps worth mentioning that signed hexadecimal floats are only available in C++1z in porting_to.html.
[Bug fortran/66643] Missing compilation error for formatted data transfer without format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66643 --- Comment #6 from Dominique d'Humieres --- Note the extra comma in gfortran.dg/integer_exponentiation_6.F90 (see pr60751). Any reason to keep it?
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #17 from Dominique d'Humieres --- Note that the extra comma is used in the following tests: gfortran.dg/array_constructor_49.f90 gfortran.dg/integer_exponentiation_6.F90 gfortran.dg/graphite/pr38083.f90 Any reason to keep it?
[Bug c++/70584] constexpr variables cannot be used as intrinsic arguments where an immediate is expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70584 --- Comment #2 from Andrés Agustín Tiraboschi --- #include int main() { __m128i r; constexpr auto index = 1; enum {index2 = index}; r = _mm_aeskeygenassist_si128(r, index2); } This works also.
[Bug c++/70529] Unhelpful diagnostic for hex float literals, inconsistent parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529 --- Comment #6 from Jakub Jelinek --- But that wouldn't make any difference between 0x123p-2 and 0x123p - 2 (or some of them coming from macro, other not etc.). So perhaps you want to also check the locus of each of the tokens and find out if they are actually consecutive in the source.
[Bug c++/70529] Unhelpful diagnostic for hex float literals, inconsistent parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529 --- Comment #5 from Manuel López-Ibáñez --- (In reply to jos...@codesourcery.com from comment #4) > On Tue, 5 Apr 2016, manu at gcc dot gnu.org wrote: > > > According to the manual, if an extension is not incompatible with the base > > standard, it should not be disabled: > > In general, this extension *is* incompatible with the base standard - > there are cases where a program is valid with both versions of pp-numbers, > but with different semantics. See gcc.dg/c90-hexfloat-2.c, for example. Oh, well, then current status makes sense. > It should be possible to lex according to the selected standard, but track > that a pp-token could be a hex float together with the following two > pp-tokens (+ or - and the exponent with possible suffix) and then handle > things specially if that sequence of pp-tokens ends up getting converted > to tokens. Perhaps something simpler like this could be enough to inform naive users like me? Index: expr.c === --- expr.c (revision 233781) +++ expr.c (working copy) @@ -568,11 +568,26 @@ cpp_classify_number (cpp_reader *pfile, { if (DIGIT_SEP (*str)) SYNTAX_ERROR_AT (virtual_location, "digit separator adjacent to exponent"); else - SYNTAX_ERROR_AT (virtual_location, "exponent has no digits"); + { + if (radix == 16 && !CPP_OPTION (pfile, extended_numbers)) + { + const cpp_token *tok2 = cpp_get_token (parse_in); + const cpp_token *tok3 = cpp_get_token (parse_in); + if ((tok2 == CPP_MINUS || tok2 == CPP_PLUS) + && tok3 == CPP_NUMBER) + { + if (CPP_OPTION (pfile, cplusplus)) + SYNTAX_ERROR_AT (virtual_location, "hexadecimal floating constant with signed exponent requires C99"); + else + SYNTAX_ERROR_AT (virtual_location, "hexadecimal floating constant with signed exponent requires C++1z"); + } + } + SYNTAX_ERROR_AT (virtual_location, "exponent has no digits"); + } } do { seen_digit_sep = DIGIT_SEP (*str); str++; It would be better to say: prog.cc:1:10: error: hexadecimal floating constant with signed exponent requires C++1z auto d = 0x123p-2; ~~^~ but I have no idea how to create ranges dynamically in the new rich_loc world.
[Bug tree-optimization/70586] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70586 --- Comment #2 from Jakub Jelinek --- int a, e, f; short b, c, d; int foo (int x, int y) { return (y == 0 || (x && y == 1)) ? x : x % y; } static short bar (void) { int i = foo (c, f); f = foo (d, 2); int g = foo (b, c); int h = foo (g > 0, c); c = (3 >= h ^ 7) <= foo (i, c); if (foo (e, 1)) return a; return 0; } int main () { bar (); return 0; } I think this goes wrong during ifcombine, will have a look tomorrow.
[Bug tree-optimization/70586] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70586 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-07 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.4 Summary|wrong code at -O2 and -O3 |[4.9/5/6 Regression] wrong |on x86_64-linux-gnu in |code at -O2 and -O3 on |32-bit and 64-bit modes |x86_64-linux-gnu in 32-bit ||and 64-bit modes Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r195751, which means that most likely it has been latent before.
[Bug tree-optimization/70586] New: wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70586 Bug ID: 70586 Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: chengniansun at gmail dot com Target Milestone: --- The following code is miscompiled by the trunk at -O2 and -O3 on x86_64-linux-gnu in 32-bit and 64-bit modes. This also affects gcc-4.8 and later versions. $: gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto --prefix=/usr/local/gcc-trunk --disable-bootstrap Thread model: posix gcc version 6.0.0 20160407 (experimental) [trunk revision 234805] (GCC) $: $: gcc-trunk -w -m32 small.c -O3 ; ./a.out Floating point exception (core dumped) $: gcc-trunk -w -m32 small.c -O2 ; ./a.out Floating point exception (core dumped) $: gcc-trunk -w -m32 small.c -O1 ; ./a.out $: gcc-4.8 -w small.c -O3 ; ./a.out Floating point exception (core dumped) $: gcc-4.7 -w small.c -O3 ; ./a.out $: $: cat small.c int a, e, f; short b, c, d; int fn1(p1, p2) { return p2 == 0 || p1 && p2 == 1 ? p1 : p1 % p2; } static short fn2() { int g, h, i = fn1(c, f); f = fn1(d, 2); g = fn1(b, c); h = fn1(g > 0, c); c = (3 >= h ^ 7) <= fn1(i, c); if (fn1(e, 1)) return a; } int main() { fn2(); return 0; } $:
[Bug c++/70585] New: Bogus 'ambiguous template instantiation' error with partial specializations involving a pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70585 Bug ID: 70585 Summary: Bogus 'ambiguous template instantiation' error with partial specializations involving a pack expansion Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- Repro: template class meow; template struct purr; template struct purr...> {}; template struct purr...> {}; template struct purr>; gcc HEAD 6.0.0 20160407 (experimental) on Wandbox prints: prog.cc:10:17: error: ambiguous template instantiation for 'struct purr >' template struct purr>; ^~~~ prog.cc:6:8: note: candidates are: template struct purr...> [with T = int; Ts = {int}] struct purr...> {}; ^~~~ prog.cc:8:8: note: template struct purr...> [with Ts = {int}] struct purr...> {}; ^~ prog.cc:10:17: error: explicit instantiation of 'struct purr >' before definition of template template struct purr>; ^~~~ Clang compiles this code.
[Bug c++/70584] constexpr variables cannot be used as intrinsic arguments where an immediate is expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70584 --- Comment #1 from Daniel Gutson --- Additional data: an enumerator works: int main() { __m128i r; //constexpr auto index = 1; enum { index = 1 }; r = _mm_aeskeygenassist_si128(r, index); }
[Bug target/70381] On powerpc, -mfloat128 is on by default for all VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70381 Michael Meissner changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2016-04-07 Resolution|FIXED |--- Ever confirmed|0 |1 --- Comment #3 from Michael Meissner --- Unfortunately the fix checked disables building the software emulation functions in libgcc. This is due to #pragma GCC target ("vsx,float128") does not enable the __float128 keyword, so the test fails.
[Bug c++/70529] Unhelpful diagnostic for hex float literals, inconsistent parsing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70529 --- Comment #4 from joseph at codesourcery dot com --- On Tue, 5 Apr 2016, manu at gcc dot gnu.org wrote: > According to the manual, if an extension is not incompatible with the base > standard, it should not be disabled: In general, this extension *is* incompatible with the base standard - there are cases where a program is valid with both versions of pp-numbers, but with different semantics. See gcc.dg/c90-hexfloat-2.c, for example. That case involves pp-numbers such as 0x1p+f that aren't valid to convert to tokens. But you could produce other examples involving concatenation that are valid without hex floats but not with them, e.g.: #define a0x123p b #define concat(x, y) x##y concat(a, 0x123p-2) which is valid without hex floats (expanding to b-2), but invalid with them because of an invalid concatenation. So any extended pp-number syntax that include valid hex floats also introduces errors on valid code. It should be possible to lex according to the selected standard, but track that a pp-token could be a hex float together with the following two pp-tokens (+ or - and the exponent with possible suffix) and then handle things specially if that sequence of pp-tokens ends up getting converted to tokens.
[Bug target/70117] ppc long double isinf() is wrong?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117 --- Comment #16 from joseph at codesourcery dot com --- On Tue, 5 Apr 2016, amodra at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117 > > --- Comment #14 from Alan Modra --- > > if (fmt == &ibm_extended_double) > > No, there is mips_extended_format too. I think that's now unused after the removal of IRIX support, and so should be removed from GCC. (The support for that format in fp-bit.[ch] is also now unused.)
[Bug c++/70584] New: constexpr variables cannot be used as intrinsic arguments where an immediate is expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70584 Bug ID: 70584 Summary: constexpr variables cannot be used as intrinsic arguments where an immediate is expected Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: daniel.gutson at tallertechnologies dot com Target Milestone: --- Created attachment 38216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38216&action=edit test case The following code causes gcc to complain that the last argument should be an 8-bit immediate value: #include int main() { __m128i r; constexpr auto index = 1; r = _mm_aeskeygenassist_si128(r, index); } This fails with -O0 but not with -O3. The arguments to reproduce the issue are: g++ -std=c++14 -msse -msse2 -maes -O0 tst.cpp -o tst I attached the code anyway. FWIW, this works in clang both for -O0 and for -O3. I think that constexpr variables should be valid immediate arguments. This bug affects the development of template metaprograms. If there is agreement that this should be fixed, feel free to assign this to andres.tirabos...@tallertechnologies.com .
[Bug c++/70583] New: [6 Regression] FAIL: g++.old-deja/g++.abi/vtable2.C -std=gnu++98 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70583 Bug ID: 70583 Summary: [6 Regression] FAIL: g++.old-deja/g++.abi/vtable2.C -std=gnu++98 execution test Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/test/gnu/gcc/objdir/g cc/testsuite/g++/../../ /test/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.abi/vta ble2.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/test /gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include/hppa64-hp-hpux11.11 -I/ test/gnu/gcc/objdir/hppa64-hp-hpux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc /libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward -I/tes t/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -fno-s trict-aliasing -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.li bs -B/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -L/test/g nu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs -lm -o ./vtable2.exe PASS: g++.old-deja/g++.abi/vtable2.C -std=gnu++98 (test for excess errors) Setting LD_LIBRARY_PATH to .:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc+ +-v3/src/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs :/test/gnu/gcc/objdir/gcc:.:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++ -v3/src/.libs:/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libstdc++-v3/src/.libs: /test/gnu/gcc/objdir/gcc spawn [open ...] FAIL: g++.old-deja/g++.abi/vtable2.C -std=gnu++98 execution test Test returns 5 and fails in this hunk: if (! CMP_VPTR (vtbl, &S3_s3)) return 5; Breakpoint 1, main () at /test/gnu/gcc/gcc/gcc/testsuite/g++.old-deja/g++.abi/vtable2.C:175 175 if (! CMP_VPTR (vtbl, &S3_s3)) (gdb) p vtbl $1 = (ptrdiff_t *) 0x800101d0 (gdb) p S3_s3 $2 = {} 0x400034c0 (gdb) p &S3_s3 $3 = ( *) 0x400034c0 (gdb) stepi 0x4000366c 175 if (! CMP_VPTR (vtbl, &S3_s3)) (gdb) 0x40003670 175 if (! CMP_VPTR (vtbl, &S3_s3)) (gdb) 0x40003674 175 if (! CMP_VPTR (vtbl, &S3_s3)) (gdb) 0x40003678 175 if (! CMP_VPTR (vtbl, &S3_s3)) (gdb) 0x4000367c 175 if (! CMP_VPTR (vtbl, &S3_s3)) (gdb) 0x40003680 175 if (! CMP_VPTR (vtbl, &S3_s3)) (gdb) 176 return 5; This is with revision 234788. Revision 234427 was okay. Similar fails: FAIL: g++.old-deja/g++.abi/vtable2.C -std=gnu++11 execution test FAIL: g++.old-deja/g++.abi/vtable2.C -std=gnu++14 execution test
[Bug testsuite/70581] [6 regression] gcc.dg/lto/simd-function FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70581 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jakub Jelinek --- > Created attachment 38215 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38215&action=edit > gcc6-pr70581.patch > > Your assembler is too old. Untested fix. Just tried it: with /bin/as, the test becomes unsupported because the avx512f test fails, with gas it passes as before. Thanks. Rainer
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 costinc at gmail dot com changed: What|Removed |Added CC||costinc at gmail dot com --- Comment #23 from costinc at gmail dot com --- I've just been bitten by this. The problem isn't the attribute, it's the on-by-default warning. Why force people to move from one convention of ignoring expression results to another? I've just wasted one hour of my life. On the opposite side of the scale there are people using prettier ways to ignore expression results. I really hope someone, somewhere, was deterred from ignoring a result using a much uglier method than (void) and, because of it, fixed a real bug (this must be the only scenario that favors disallowing (void), deterrence through repugnance, am I wrong?). Note that casting to void seems to be mentioned in the standard precisely for discarding expression results: "Any expression can be explicitly converted to type “cv void.” The expression value is discarded." At best, this warning should be restricted to gnu99 or similar. And if the attribute and it's associated warning are supposed to apply only to important security related code then where is the warning for non-security related code? The warning name pretty clearly relates to the general problem. Isn't that confusing? My 2c: Clang did the right thing. Please, at least make the warning off-by-default.
[Bug c++/70452] [5/6 Regression] Regression in C++ parsing performance between 4.9.3 and 5.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452 --- Comment #14 from Patrick Palka --- trunk is now at Execution times (seconds) phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 1%) wall 1287 kB ( 1%) ggc phase parsing : 1.28 (100%) usr 0.20 (100%) sys 1.48 (99%) wall 156462 kB (99%) ggc |name lookup: 0.03 ( 2%) usr 0.01 ( 5%) sys 0.04 ( 3%) wall 81 kB ( 0%) ggc |overload resolution: 0.04 ( 3%) usr 0.00 ( 0%) sys 0.05 ( 3%) wall 628 kB ( 0%) ggc preprocessing : 0.03 ( 2%) usr 0.04 (20%) sys 0.09 ( 6%) wall 2048 kB ( 1%) ggc parser (global) : 0.02 ( 2%) usr 0.07 (35%) sys 0.06 ( 4%) wall 7735 kB ( 5%) ggc parser function body: 1.23 (96%) usr 0.09 (45%) sys 1.33 (89%) wall 146667 kB (93%) ggc TOTAL : 1.28 0.20 1.49 157759 kB The remaining extra memory and runtime overhead relative to 4.9 is mostly due to the constexpr_call_table which caches the result of each constexpr call that's been evaluated. This table now gets cleared during GC though which in real programs triggers frequently enough that its size won't be a problem.
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #43 from Bernd Schmidt --- I suspect the message Roger quoted was from the earlier version with the printf; that one didn't give a location. I advocate no action until we have a reproducer so we can know what's going on.
[Bug preprocessor/70518] Conditional compilation of #line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70518 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Manuel López-Ibáñez --- (In reply to jos...@codesourcery.com from comment #4) > On Sun, 3 Apr 2016, elyk03 at gmail dot com wrote: > > > Should #line be processed unconditionally? I know the preprocessor has to > > keep > > It should not be processed in skipped blocks. See C11 6.10.1#6 I think that settles it. It might be worth it to open a different PR saying that the caret line should use the real source location and ignore line directives (and linemarkers). That seems hard to fix, though.
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #42 from Manuel López-Ibáñez --- (In reply to Roger Orr from comment #41) > I have seen the message before: for example from a build with revision > > line-map.c: file "/usr/include/asm/sockios.h" left but not entered You can also simply filter every '^# [0-9]' line from the preprocessed output before compiling. There must be some broken linemarker, perhaps as a result of copy-pasting from another preprocessed file. I wonder, don't we give a precise location now for the broken linemarker? Perhaps we should control this with -Wlinemarker, such that people can use -Wno-linemarker. We may have underestimated how much broken code might be out there.
[Bug preprocessor/70518] Conditional compilation of #line directives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70518 --- Comment #4 from joseph at codesourcery dot com --- On Sun, 3 Apr 2016, elyk03 at gmail dot com wrote: > Should #line be processed unconditionally? I know the preprocessor has to > keep It should not be processed in skipped blocks. See C11 6.10.1#6: "Each directive’s condition is checked in order. If it evaluates to false (zero), the group that it controls is skipped: directives are processed only through the name that determines the directive in order to keep track of the level of nested conditionals; the rest of the directives’ preprocessing tokens are ignored, as are the other preprocessing tokens in the group.". This means, for example, that #if 0 #line invalid line directive #endif is valid, whereas that #line directive would not be valid outside #if 0.
[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70573 --- Comment #10 from Jakub Jelinek --- Of course. Patch changing both is preapproved.
[Bug testsuite/70581] [6 regression] gcc.dg/lto/simd-function FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70581 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 38215 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38215&action=edit gcc6-pr70581.patch Your assembler is too old. Untested fix.
[Bug ipa/70582] [6 regression] gcc.dg/attr-weakref-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70582 Rainer Orth changed: What|Removed |Added Target Milestone|--- |6.0
[Bug ipa/70582] [6 regression] gcc.dg/attr-weakref-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70582 --- Comment #1 from Rainer Orth --- Created attachment 38214 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38214&action=edit assembler output
[Bug ipa/70582] New: [6 regression] gcc.dg/attr-weakref-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70582 Bug ID: 70582 Summary: [6 regression] gcc.dg/attr-weakref-1.c FAILs Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Target Milestone: --- Host: i386-pc-solaris2.1[012] Target: i386-pc-solaris2.1[012] Build: i386-pc-solaris2.1[012] After 20160401, gcc.dg/attr-weakref-1.c started to FAIL on Solaris/x86 with /bin/as: FAIL: gcc.dg/attr-weakref-1.c (test for excess errors) WARNING: gcc.dg/attr-weakref-1.c compilation failed to produce executable Excess errors: Assembler: attr-weakref-1.c "/var/tmp//ccUSaysF.s", line 171 : Multiply defined symbol: "Wv3a" I'm attaching the assembler output. When using gas, this still works since .weakref is used there. Most likely caused by the recent patch for PR ipa/68881. Rainer
[Bug target/70581] [6 regression] gcc.dg/lto/simd-function FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70581 Rainer Orth changed: What|Removed |Added Target Milestone|--- |6.0
[Bug target/70581] New: [6 regression] gcc.dg/lto/simd-function FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70581 Bug ID: 70581 Summary: [6 regression] gcc.dg/lto/simd-function FAILs Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: i386-pc-solaris2.1[012] Target: i386-pc-solaris2.1[012] Build: i386-pc-solaris2.1[012] After 20160401, the gcc.dg/lto/simd-function testcase began to FAIL on Solaris/x86 with /bin/as: FAIL: gcc.dg/lto/simd-function c_lto_simd-function_0.o assemble, -fopenmp-simd -O3 -ffast-math -mavx2 -flto -flto-partition=max UNRESOLVED: gcc.dg/lto/simd-function c_lto_simd-function_0.o-c_lto_simd-function_0.o execute -fopenmp-simd -O3 -ffast-math -mavx2 -flto -flto-partition=max UNRESOLVED: gcc.dg/lto/simd-function c_lto_simd-function_0.o-c_lto_simd-function_0.o link -fopenmp-simd -O3 -ffast-math -mavx2 -flto -flto-partition=max Assembler: simd-function_0.c "/var/tmp//ccw.aGWM.s", line 850 : Invalid instruction argument Near line: "vmulps %zmm1, %zmm0, %zmm0" "/var/tmp//ccw.aGWM.s", line 858 : Illegal mnemonic Near line: "vpxord %zmm3, %zmm3, %zmm3" "/var/tmp//ccw.aGWM.s", line 858 : Syntax error Near line: "vpxord %zmm3, %zmm3, %zmm3" "/var/tmp//ccw.aGWM.s", line 860 : Invalid instruction argument Near line: "vmulps %zmm1, %zmm0, %zmm0" "/var/tmp//ccw.aGWM.s", line 863 : Illegal mnemonic Near line: "vpcmpd $4, %zmm3, %zmm2, %k1" "/var/tmp//ccw.aGWM.s", line 863 : Syntax error Near line: "vpcmpd $4, %zmm3, %zmm2, %k1" "/var/tmp//ccw.aGWM.s", line 866 : Illegal mnemonic Near line: "kmovw %k1, %eax" "/var/tmp//ccw.aGWM.s", line 866 : Syntax error Near line: "kmovw %k1, %eax" "/var/tmp//ccw.aGWM.s", line 870 : Invalid instruction argument Near line: "vmovaps %zmm0, -120(%ebp){%k1}" "/var/tmp//ccw.aGWM.s", line 872 : Invalid instruction argument Near line: "vmovaps -120(%ebp), %zmm0" for both 32 and 64-bit. It seems the compiler started to emit avx512f insns despite the -mavx2. Either the testcase needs to be amended requiring the corresponding effective-target, or the compiler fixed not to emit those unless told to... Here's a diff between the assembler outputs from 20160401 and 20160407: --- /homes/ro/simd-function_0.s 2016-04-07 18:05:16.449629000 +0200 +++ simd-function_0.s 2016-04-07 18:06:05.170292167 +0200 [...] @@ -846,6 +846,39 @@ leal-4(%ecx), %esp ret .size _ZGVdM8vv_my_mul, .-_ZGVdM8vv_my_mul + .p2align 4,,15 + .globl _ZGVeN16vv_my_mul + .type _ZGVeN16vv_my_mul, @function +_ZGVeN16vv_my_mul: + vmulps %zmm1, %zmm0, %zmm0 + ret + .size _ZGVeN16vv_my_mul, .-_ZGVeN16vv_my_mul + .p2align 4,,15 + .globl _ZGVeM16vv_my_mul + .type _ZGVeM16vv_my_mul, @function +_ZGVeM16vv_my_mul: + leal4(%esp), %ecx + vpxord %zmm3, %zmm3, %zmm3 + andl$-64, %esp + vmulps %zmm1, %zmm0, %zmm0 + pushl -4(%ecx) + pushl %ebp + vpcmpd $4, %zmm3, %zmm2, %k1 + movl%esp, %ebp + pushl %ecx + kmovw %k1, %eax + subl$308, %esp + testw %ax, %ax + je .L89 + vmovaps %zmm0, -120(%ebp){%k1} +.L89: + vmovaps -120(%ebp), %zmm0 + addl$308, %esp + popl%ecx + popl%ebp + leal-4(%ecx), %esp + ret + .size _ZGVeM16vv_my_mul, .-_ZGVeM16vv_my_mul .comm x,16384,32 .section.rodata .align 4 Rainer
[Bug fortran/70575] write syntax check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70575 Dominique d'Humieres changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Dominique d'Humieres --- *** This bug has been marked as a duplicate of bug 60751 ***
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 Dominique d'Humieres changed: What|Removed |Added CC||valeryweber at hotmail dot com --- Comment #16 from Dominique d'Humieres --- *** Bug 70575 has been marked as a duplicate of this bug. ***
[Bug middle-end/70580] New: [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/if-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70580 Bug ID: 70580 Summary: [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/if-1.c Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- PASSes in trunk.
[Bug middle-end/70579] New: [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/host_data-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70579 Bug ID: 70579 Summary: [gomp4] -O0 execution testing FAILs for libgomp.oacc-c-c++-common/host_data-1.c Product: gcc Version: 6.0 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- PASSes in trunk.
[Bug testsuite/70553] pr70496.c should exclude Thumb only targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70553 --- Comment #1 from Thomas Preud'homme --- Author: thopre01 Date: Thu Apr 7 16:19:20 2016 New Revision: 234811 URL: https://gcc.gnu.org/viewcvs?rev=234811&root=gcc&view=rev Log: 2016-04-07 Thomas Preud'homme gcc/testsuite/ PR testsuite/70553 * gcc.target/arm/pr70496.c: Also require arm_arm_ok effective target. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/pr70496.c
[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70573 --- Comment #9 from Yury Gribov --- Better do the same for halt_on_error-2.
[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70566 --- Comment #9 from ktkachov at gcc dot gnu.org --- Patch posted at: https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00351.html
[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70573 --- Comment #8 from Dominique d'Humieres --- > Right. Dominique, can you check if s/memset/__builtin_memset/g fixes the > issue? The test succeeds with the following patch --- ../_clean/gcc/testsuite/c-c++-common/asan/halt_on_error-1.c 2015-11-23 10:17:05.0 +0100 +++ gcc/testsuite/c-c++-common/asan/halt_on_error-1.c 2016-04-07 18:10:11.0 +0200 @@ -9,7 +9,7 @@ volatile int ten = 10; int main() { char x[10]; - memset(x, 0, ten + 1); + __builtin_memset(x, 0, ten + 1); asm volatile ("" : : : "memory"); volatile int res = x[ten]; x[ten] = res + 3; Thanks.
[Bug c++/70452] [5/6 Regression] Regression in C++ parsing performance between 4.9.3 and 5.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70452 --- Comment #13 from Patrick Palka --- Author: ppalka Date: Thu Apr 7 16:12:05 2016 New Revision: 234810 URL: https://gcc.gnu.org/viewcvs?rev=234810&root=gcc&view=rev Log: Avoid needless unsharing during constexpr evaluation (PR c++/70452) gcc/cp/ChangeLog: PR c++/70452 * constexpr.c (find_constructor): New function. (unshare_constructor): New function. (cxx_eval_call_expression): Use unshare_constructor instead of unshare_expr. (find_array_ctor_elt): Likewise. (cxx_eval_vec_init_1): Likewise. (cxx_eval_store_expression): Likewise. (cxx_eval_constant_expression): Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #41 from Roger Orr --- I have seen the message before: for example from a build with revision line-map.c: file "/usr/include/asm/sockios.h" left but not entered I've only noticed it with builds from gcc-trunk, which I tested with back in Dec/Jan. I saw this message from some compilation but it seemed benign... I have not seen this message with builds from gcc 5.3.0 and before, but it is possible I've simply not noticed as it does gets a bit buried in the build logs.
[Bug target/59683] ICE: in classify_argument, at config/i386/i386.c:6637 with #pragma GCC target("avx512f")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59683 --- Comment #3 from Kirill Yukhin --- This hunk from Jakub's fix for PR61925 makes test working: diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index a41efa4..6aebaed 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -4962,6 +4962,15 @@ static GTY(()) tree ix86_previous_fndecl; void ix86_reset_previous_fndecl (void) { + tree new_tree = target_option_current_node; + cl_target_option_restore (&global_options, TREE_TARGET_OPTION (new_tree)); + if (TREE_TARGET_GLOBALS (new_tree)) +restore_target_globals (TREE_TARGET_GLOBALS (new_tree)); + else if (new_tree == target_option_default_node) +restore_target_globals (&default_target_globals); + else +TREE_TARGET_GLOBALS (new_tree) = save_target_globals_default_opts (); + ix86_previous_fndecl = NULL_TREE; }
[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70573 --- Comment #7 from Yury Gribov --- Right. Dominique, can you check if s/memset/__builtin_memset/g fixes the issue?
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #40 from Bernd Schmidt --- The message previously was a plain printf, not a warning or error so it would not have interrupted compilation. Did you get the message with earlier compilers, or did it start to appear recently?
[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70573 --- Comment #6 from Jakub Jelinek --- Comment on attachment 38213 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38213 Proposed patch Perhaps just use __builtin_memset instead of memset instead?
[Bug target/70574] [5/6 Regression] wrong code with -mavx2, read of partially initialised stack variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70574 --- Comment #2 from Jakub Jelinek --- Actually, I believe the bug is already at fwprop1. We have: (insn 247 246 18 2 (set (reg:DI 301 [ u128_0 ]) (const_int 0 [0])) pr70574.c:7 85 {*movdi_internal} (nil)) (insn 18 247 19 2 (set (reg:QI 115) (not:QI (subreg:QI (reg:DI 301 [ u128_0 ]) 0))) pr70574.c:8 506 {*one_cmplqi2_1} (nil)) ... (insn 31 30 32 2 (set (reg:SI 128) (subreg:SI (reg:QI 115) 0)) pr70574.c:8 86 {*movsi_internal} (nil)) and fwprop1 does: In insn 31, replacing (subreg:SI (reg:QI 115) 0) with (const_int -1 [0x]) Changes to insn 31 not profitable Setting REG_EQUAL note and that turns insn 31 into: (insn 31 29 32 2 (set (reg:SI 128) (subreg:SI (reg:QI 115) 0)) pr70574.c:8 86 {*movsi_internal} (expr_list:REG_EQUAL (const_int -1 [0x]) (expr_list:REG_DEAD (reg:QI 115) (nil (and correctly modifies insn 18 first to (set (reg:QI 115) (const_int -1))). The bug is in the REG_EQUAL note, (subreg:SI (reg:QI 115) 0), a paradoxical subreg of QImode -1, is not equivalent to SImode -1. So, either fwprop should have replaced it the paradoxical subreg with CONST_INT, or it shouldn't add the REG_EQUAL note.
[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70573 --- Comment #5 from Yury Gribov --- Created attachment 38213 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38213&action=edit Proposed patch Ah, so the problem is caused by _FORTIFY_SOURCE being enabled on Darwin by default. This check precedes ASan and causes app to abort too early. Could you test the attached patch?
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 Marek Polacek changed: What|Removed |Added Attachment #38211|0 |1 is obsolete|| --- Comment #1 from Marek Polacek --- Created attachment 38212 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38212&action=edit preprocessed Updated preprocessed file.
[Bug tree-optimization/70577] tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70577 vries at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from vries at gcc dot gnu.org --- Offending commit: https://gcc.gnu.org/ml/gcc-cvs/2016-03/msg00744.html : ... Author: hubicka Date: Wed Mar 30 14:30:57 2016 New Revision: 234572 URL: https://gcc.gnu.org/viewcvs?rev=234572&root=gcc&view=rev Log: * tree-ssa-loop-niter.c (idx_infer_loop_bounds): We can't get realistic estimates here. * tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Use also max_loop_iterations_int. (tree_unswitch_outer_loop): Likewise. * tree-ssa-loop-ivopts.c (avg_loop_niter): Likewise. * tree-vect-loop.c (vect_analyze_loop_2): Likewise. ...
[Bug debug/70578] New: internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 Bug ID: 70578 Summary: internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- Created attachment 38211 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38211&action=edit preprocessed With Target: x86_64-pc-linux-gnu Configured with: /home/marek/src/gcc/configure --enable-languages=c,c++,objc --enable-checking=yes -with-system-zlib --disable-bootstrap --disable-libvtv --disable-libcilkrts --disable-libitm --disable-libgomp --disable-libcc1 --disable-libstdcxx-pch --disable-libssp --disable-isl --disable-libatomic Thread model: posix gcc version 6.0.0 20160407 (experimental) (GCC) I see: $ ./cc1plus -fpreprocessed q.ii -quiet -g3 -gsplit-dwarf -O -w q.ii:763:1: internal compiler error: in output_index_string, at dwarf2out.c:25505 } ^ 0xa09c4e output_index_string(indirect_string_node**, unsigned int*) /home/marek/src/gcc/gcc/dwarf2out.c:25505 0xa1978e void hash_table::traverse_noresize(unsigned int*) /home/marek/src/gcc/gcc/hash-table.h:950 0xa09dd7 output_indirect_strings /home/marek/src/gcc/gcc/dwarf2out.c:25550 0xa0e8d6 dwarf2out_finish /home/marek/src/gcc/gcc/dwarf2out.c:27680 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.
[Bug fortran/70575] write syntax check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70575 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from kargl at gcc dot gnu.org --- Add -std=f95 to your command line. troutmask:sgk[206] gfc6 -c -std=f95 a.f90 a.f90:2:13: write(*,*) , 1 1 Error: GNU Extension: Comma before i/o item list at (1) troutmask:sgk[207]
[Bug c++/69855] Missing diagnostic for overload that only differs by return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69855 Jonathan Wakely changed: What|Removed |Added CC||stackoverflow_dl@gmx-topmai ||l.de --- Comment #3 from Jonathan Wakely --- *** Bug 70414 has been marked as a duplicate of this bug. ***
[Bug c++/70414] Function declaration in other scope: type safety violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70414 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jonathan Wakely --- This is a dup of a bug I opened recently. *** This bug has been marked as a duplicate of bug 69855 ***
[Bug tree-optimization/70577] tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70577 --- Comment #2 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-regression/2016-03/msg00336.html : Regressions on trunk at revision 234600 vs revision 234546
[Bug preprocessor/69650] [6 Regression] ICE in linemap_line_start, at libcpp/line-map.c:803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69650 --- Comment #39 from Roger Orr --- The resolution of this issue causes a problem for me as it results in compilation errors in our build. We are compiling with distcc which AIUI distributes the pre-processed intermediate output. With revision 234480 we get no warnings logged and clean compilation. With revision 234481 we get a number of warnings logged - but this interacts unfortunately with -Werror (which we also set) and so quite a number of our compilations fail. (I cannot as yet detect a pattern with which compilations are affected, but the set is consistent on a rebuild.) I can reproduce the distcc problem by using -E to generate pre-processed source and compiling this. Note: the pre-processed intermediate output does not change between 234480 and 234481, it's the compilation of this pre-processed output that fails. Unfortunately the failing code is proprietary so I am not at liberty to upload the pre-processed output, I have attempted to produce some smaller examples but so far with no success. Could the generation of the warning be made dependent upon a more specific warning flag?
[Bug tree-optimization/70577] New: prefetch.c scan-tree-dump-times aprefetch failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70577 Bug ID: 70577 Summary: prefetch.c scan-tree-dump-times aprefetch failures Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- PASS: gcc.dg/tree-ssa/prefetch-5.c (test for excess errors) FAIL: gcc.dg/tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch "Issued prefetch" 2 FAIL: gcc.dg/tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch "Not prefetching" 1
[Bug c++/70414] Function declaration in other scope: type safety violation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70414 Jaak Ristioja changed: What|Removed |Added CC||jaak at ristioja dot ee --- Comment #3 from Jaak Ristioja --- *** Bug 70576 has been marked as a duplicate of this bug. ***
[Bug c++/70576] G++ compiles and links invalid code when shadowing global function in function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70576 Jaak Ristioja changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jaak Ristioja --- OFTC #gcc [16:54:00] jotik: that the code doesn't get rejected is a bug in gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70414 *** This bug has been marked as a duplicate of bug 70414 ***
[Bug tree-optimization/70577] tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70577 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-07 Ever confirmed|0 |1 --- Comment #1 from vries at gcc dot gnu.org --- Confirmed: https://gcc.gnu.org/ml/gcc-testresults/2016-04/msg00602.html : ... FAIL: gcc.dg/tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch "Issued prefetch" 2 FAIL: gcc.dg/tree-ssa/prefetch-5.c scan-tree-dump-times aprefetch "Not prefetching" 1 ...
[Bug c++/70576] New: G++ compiles and links invalid code when shadowing global function in function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70576 Bug ID: 70576 Summary: G++ compiles and links invalid code when shadowing global function in function scope Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jaak at ristioja dot ee Target Milestone: --- int foo() { return 2; } int main() { int& foo(); foo() = 42; // Segfault } First detected here: https://stackoverflow.com/questions/36477542/what-does-int-foo-mean-in-c Compiles with GCC 4.7.4, 4.8.5, 4.9.3 and 5.3.0 without any warnings with -Wall -Wextra -Wshadow. Clang errors with: test.cpp:3:8: error: functions that differ only in their return type cannot be overloaded int& foo(); ^ test.cpp:1:5: note: previous definition is here
[Bug target/70574] [5/6 Regression] wrong code with -mavx2, read of partially initialised stack variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70574 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-07 CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Target Milestone|--- |5.4 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r210824.
[Bug fortran/70575] New: write syntax check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70575 Bug ID: 70575 Summary: write syntax check Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: valeryweber at hotmail dot com Target Milestone: --- Hi All Should gfortran complain about the syntax of the following code? v gcc version 6.0.0 20160330 (experimental) (GCC) cat t.f90 subroutine foo() write(*,*) , 1 end subroutine foo
[Bug target/64386] ICE: in extract_insn, at recog.c:2327 (unrecognizable insn) with -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64386 Kirill Yukhin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Kirill Yukhin --- Done.
[Bug target/70574] New: [5/6 Regression] wrong code with -mavx2, read of partially initialised stack variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70574 Bug ID: 70574 Summary: [5/6 Regression] wrong code with -mavx2, read of partially initialised stack variable Product: gcc Version: unknown Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Target: x86_64-pc-linux-gnu Created attachment 38210 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38210&action=edit reduced testcase Output: $ gcc -O -fPIC -frerun-cse-after-loop -fno-tree-ccp -mcmodel=medium -mavx2 testcase.c $ valgrind -q ./a.out ==1282== Conditional jump or move depends on uninitialised value(s) ==1282==at 0x400653: main (in /home/zso/gcc-bug/89/a.out) ==1282== Aborted The problem most likely is (intel sytax): ... foo: ... mov DWORD PTR -52[rbp], edi # %sfp, u64_0 mov QWORD PTR -64[rbp], rcx # %sfp, u128_1 1) mov BYTE PTR -48[rbp], -1 # %sfp, vpxor xmm2, xmm2, xmm2# tmp120 2) vpinsrb xmm2, xmm2, BYTE PTR -48[rbp], 1# tmp120, tmp120, %sfp, vmovd xmm4, DWORD PTR -64[rbp]# tmp124, %sfp mov eax, 0 # tmp126, vpinsrb xmm4, xmm4, eax, 1 # tmp125, tmp124, tmp126, 3) vmovd xmm3, DWORD PTR -48[rbp]# tmp129, %sfp ... 1 stores a "byte" -1, 2 reads "byte" -1, 3 reads "dword" -1 (3 bytes of garbage) $ gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-234794-checking-yes-rtl-df-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-234794-checking-yes-rtl-df-nographite Thread model: posix gcc version 6.0.0 20160406 (experimental) (GCC)
[Bug libgomp/69414] [OpenACC] "!$acc update self" does not provide expected result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69414 Thomas Schwinge changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|5.3.0 |5.0 Resolution|--- |FIXED Assignee|jnorris at gcc dot gnu.org |tschwinge at gcc dot gnu.org Target Milestone|--- |5.4 --- Comment #6 from Thomas Schwinge --- In r234806 now also fixed on gcc-5-branch.
[Bug libgomp/69414] [OpenACC] "!$acc update self" does not provide expected result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69414 --- Comment #5 from Thomas Schwinge --- Author: tschwinge Date: Thu Apr 7 11:43:30 2016 New Revision: 234806 URL: https://gcc.gnu.org/viewcvs?rev=234806&root=gcc&view=rev Log: [PR libgomp/69414] Fix handling of subarrays with update directive libgomp/ Backport trunk r234428: 2016-03-23 James Norris Daichi Fukuoka PR libgomp/69414 * oacc-mem.c (delete_copyout, update_dev_host): Fix device address. * testsuite/libgomp.oacc-c-c++-common/update-1.c: Additional tests. * testsuite/libgomp.oacc-c-c++-common/update-1-2.c: Likewise. * testsuite/libgomp.oacc-fortran/update-1.f90: New file. Added: branches/gcc-5-branch/libgomp/testsuite/libgomp.oacc-fortran/update-1.f90 Modified: branches/gcc-5-branch/libgomp/ChangeLog branches/gcc-5-branch/libgomp/oacc-mem.c branches/gcc-5-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/update-1-2.c branches/gcc-5-branch/libgomp/testsuite/libgomp.oacc-c-c++-common/update-1.c
[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70566 ktkachov at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug libstdc++/51749] Including pollutes global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51749 --- Comment #33 from Jonathan Wakely --- Thanks for the info. The locale_t functionality is the main thing that will need work, but it's good to know you were able to get everything else working well.
[Bug libstdc++/70564] Problem with std::experimental::not_fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70564 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-07 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to Rodrigo from comment #0) > which calls _Not_fn(_Not_fn&) since __pred is an lvalue. > However, between these _Not_fn constructors: > > template > explicit > _Not_fn(_Fn2&& __fn) : _M_fn(std::forward<_Fn2>(__fn)) { } > > _Not_fn(const _Not_fn& __fn) = default; > _Not_fn(_Not_fn&& __fn) = default; > > the first one wins and triggers an error. Oops, that constructor needs to be constrained.
[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70566 --- Comment #8 from ktkachov at gcc dot gnu.org --- (In reply to Richard Earnshaw from comment #7) > (In reply to ktkachov from comment #6) > > Ah, on second glance the peephole looks correct in itself, but the second > > branch following the bmi uses an incorrect condition code. > > So we have: > > tst r3, #2 > > bne .L3 > > beq .L6 > > > > being transformed into: > > ldrbr3, [r0]@ zero_extendqisi2 > > lslsr3, r3, #30 > > bmi .L3 > > beq .L6 > > > > > > The beq needs to be updated to be the opposite of bmi. That is, bpl > > Sounds like the peephole is missing a reg-dead check on the condition code > value. Yep, that seems to do the trick. I'll test a patch. Thanks Richard.
[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70566 --- Comment #7 from Richard Earnshaw --- (In reply to ktkachov from comment #6) > Ah, on second glance the peephole looks correct in itself, but the second > branch following the bmi uses an incorrect condition code. > So we have: > tst r3, #2 > bne .L3 > beq .L6 > > being transformed into: > ldrbr3, [r0]@ zero_extendqisi2 > lslsr3, r3, #30 > bmi .L3 > beq .L6 > > > The beq needs to be updated to be the opposite of bmi. That is, bpl Sounds like the peephole is missing a reg-dead check on the condition code value.
[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70573 --- Comment #4 from Dominique d'Humieres --- > Problem is that we don't have access to Darwin hardware. Perhaps you could > get a failing stacktrace via gdb? (lldb) run Process 79186 launched: '/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out' (x86_64) Process 79186 stopped * thread #1: tid = 0x29c6013, 0x7fff9225df06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT frame #0: 0x7fff9225df06 libsystem_kernel.dylib`__pthread_kill + 10 libsystem_kernel.dylib`__pthread_kill: -> 0x7fff9225df06 <+10>: jae0x7fff9225df10; <+20> 0x7fff9225df08 <+12>: movq %rax, %rdi 0x7fff9225df0b <+15>: jmp0x7fff922587cd; cerror_nocancel 0x7fff9225df10 <+20>: retq (lldb) bt * thread #1: tid = 0x29c6013, 0x7fff9225df06 libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT * frame #0: 0x7fff9225df06 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x7fff96b934ec libsystem_pthread.dylib`pthread_kill + 90 frame #2: 0x7fff880276e7 libsystem_c.dylib`abort + 129 frame #3: 0x7fff8802785e libsystem_c.dylib`abort_report_np + 181 frame #4: 0x7fff8804da14 libsystem_c.dylib`__chk_fail + 48 frame #5: 0x7fff8804d9e4 libsystem_c.dylib`__chk_fail_overflow + 16 frame #6: 0x7fff8804da7a libsystem_c.dylib`__memset_chk + 37 frame #7: 0x00010f4f a.out`main + 42 at halt_on_error-1.c:12 frame #8: 0x7fff924055ad libdyld.dylib`start + 1
[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70566 --- Comment #6 from ktkachov at gcc dot gnu.org --- Ah, on second glance the peephole looks correct in itself, but the second branch following the bmi uses an incorrect condition code. So we have: tst r3, #2 bne .L3 beq .L6 being transformed into: ldrbr3, [r0]@ zero_extendqisi2 lslsr3, r3, #30 bmi .L3 beq .L6 The beq needs to be updated to be the opposite of bmi. That is, bpl
[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70573 --- Comment #3 from Yury Gribov --- Problem is that we don't have access to Darwin hardware. Perhaps you could get a failing stacktrace via gdb?
[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70566 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||rearnsha at arm dot com --- Comment #5 from ktkachov at gcc dot gnu.org --- I think the peephole to transform the 1-bit zero_extract + compare-with-zero into an lsls (from a tst-immediate) is not valid for positions other than zero (i.e. when the shift would be by 31). But that case should already be handled by the peephole below it at line 1567 in thumb2.md. So I propose we just delete the one at line 1539. Richard, what do you think?
[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70566 ktkachov at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #4 from ktkachov at gcc dot gnu.org --- The culprit seems to be the peephole in thumb2.md at line 1539. Adding -fno-peephole2 gives the correct behaviour.
[Bug target/70566] [4.9/5/6 Regression] Bad ARM code generated for evaluating unsigned int bitfield value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70566 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target||arm Status|UNCONFIRMED |NEW Known to work||4.8.5 Keywords||wrong-code Last reconfirmed||2016-04-07 Component|c |target CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Summary|Bad ARM code generated for |[4.9/5/6 Regression] Bad |evaluating unsigned int |ARM code generated for |bitfield value |evaluating unsigned int ||bitfield value Target Milestone|--- |4.9.5 Known to fail||4.9.4, 5.3.1, 6.0 --- Comment #3 from ktkachov at gcc dot gnu.org --- Confirmed on active branches. I get MYFUNC printed only when running ./prog 0. At -O0 or with GCC 4.8 I get MYFUNC printed when running both "./prog 0" and "prog 1". So this looks like a regression from 4.9 onwards.
[Bug testsuite/70516] [4.9/5/6 Regression] Regtesting acats hangs on x86_64-apple-darwin15.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70516 --- Comment #6 from Jakub Jelinek --- The thing is that there were no changes in the acats testsuite in the last 1.5 years, and if you say there is no ada process hanging around, it is unlikely gcc/ada changes affect it either.
[Bug c++/66487] sanitizer/warnings for lifetime DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66487 --- Comment #20 from Martin Liška --- (In reply to Jan Hubicka from comment #19) > Martin, I suppose the sanitizer bits can be tracked as enhancement and not > regression. It is a firefox bug so I suppose we can declare this a > non-regression. Sure, maybe I would return to support of MSAN in GCC 7.
[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70573 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-07 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > Could you provide details of the fail? The best I can do from the little I understand is [Book15] f90/bug% gcc6 -fsanitize-recover=address /opt/gcc/_clean/gcc/testsuite/c-c++-common/asan/halt_on_error-1.c [Book15] f90/bug% ./a.out Abort [Book15] f90/bug% printenv ASAN_OPTIONS [Book15] f90/bug% setenv ASAN_OPTIONS "halt_on_error=false" [Book15] f90/bug% ./a.out Abort [Book15] f90/bug% printenv ASAN_OPTIONS halt_on_error=false
[Bug sanitizer/70573] FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70573 Yury Gribov changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #1 from Yury Gribov --- Could you provide details of the fail?
[Bug testsuite/70516] [4.9/5/6 Regression] Regtesting acats hangs on x86_64-apple-darwin15.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70516 --- Comment #5 from Dominique d'Humieres --- > Perhaps just tcl bug on your platform then? > Do you have some revision where you can reliably not reproduce the hang > (say with 100 invocations)? Otherwise I kind of don't understand > the Regression marking. Regtesting all languages on my machine takes between 4 and 5 hours (at -j8), so I never test any revision more than once. I typically do a couple regtestings every day and I have never seen any hanging before March 16 for trunk.
[Bug testsuite/70516] [4.9/5/6 Regression] Regtesting acats hangs on x86_64-apple-darwin15.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70516 --- Comment #4 from Jakub Jelinek --- Perhaps just tcl bug on your platform then? Do you have some revision where you can reliably not reproduce the hang (say with 100 invocations)? Otherwise I kind of don't understand the Regression marking.
[Bug sanitizer/70573] New: FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70573 Bug ID: 70573 Summary: FAIL: c-c++-common/asan/halt_on_error-1.c -O* execution test x86_64-apple-darwin15 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, howarth.at.gcc.testresults at gmail dot com, iains at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin15 Target: x86_64-apple-darwin15 Build: x86_64-apple-darwin15 The test c-c++-common/asan/halt_on_error-1.c fails on darwin at run time. AFAICT the test has never succeeded.
[Bug c++/70572] [4.9/5/6 Regression] ICE on code with decltype (auto) on x86_64-linux-gnu in digest_init_r, at cp/typeck2.c:1103 with -std=c++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70572 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-07 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |4.9.4 Summary|ICE on code with decltype |[4.9/5/6 Regression] ICE on |(auto) on x86_64-linux-gnu |code with decltype (auto) |in digest_init_r, at|on x86_64-linux-gnu in |cp/typeck2.c:1103 with |digest_init_r, at |-std=c++14 |cp/typeck2.c:1103 with ||-std=c++14 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- ICE started with r197248, before that it has been rejected with pr70572.C: In function ‘int foo()’: pr70572.C:3:4: error: expected primary-expression before ‘decltype’ decltype (auto) a = foo; ^ pr70572.C:3:4: error: expected ‘;’ before ‘decltype’
[Bug c++/70571] [6 Regression] ICE on valid code on x86_64-linux-gnu in verify_ctor_sanity, at cp/constexpr.c:2259
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70571 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-07 CC||jakub at gcc dot gnu.org, ||nathan at gcc dot gnu.org Target Milestone|--- |6.0 Summary|ICE on valid code on|[6 Regression] ICE on valid |x86_64-linux-gnu in |code on x86_64-linux-gnu in |verify_ctor_sanity, at |verify_ctor_sanity, at |cp/constexpr.c:2259 |cp/constexpr.c:2259 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r229128, most likely dup of PR70501.