[Bug middle-end/70526] [5/6 Regression] GCC 6 miscompiles Firefox JIT compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526 --- Comment #34 from Vittorio Zecca --- The Intel icpc compiler complains that in the reduced testcase ansi-alias rules are violated. icpc gccerr45.C -Wstrict-aliasing gccerr45.C(77) (col. 32): warning #2102: violation of ansi-alias rules This is line 77: "const LAllocation* value = lir->getOperand(n);"
[Bug c++/71166] [6/7 Regression] ICE with nested constexpr/initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71166 Martin Sebor changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-18 CC||jakub at gcc dot gnu.org, ||msebor at gcc dot gnu.org Blocks||55004 Summary|ICE with nested |[6/7 Regression] ICE with |constexpr/initializer |nested ||constexpr/initializer Ever confirmed|0 |1 Known to fail||6.1.0, 7.0 --- Comment #1 from Martin Sebor --- Confirmed. Both 6.1.0 and 7.0 are affected, 5.3.0 is not. If my bisection script isn't lying it looks like r235033 introduced the ICE. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 [Bug 55004] [meta-bug] constexpr issues
[Bug c++/56671] Gcc uses large amounts of memory and processor power with large C++11 bitsets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56671 Martin Sebor changed: What|Removed |Added CC||gcc-bugzilla at bmevers dot de --- Comment #6 from Martin Sebor --- *** Bug 63728 has been marked as a duplicate of this bug. ***
[Bug c++/63728] Memory exhaustion using constexpr constructors for classes with large array members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63728 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE Known to fail||7.0 --- Comment #2 from Martin Sebor --- I believe this can actually be considered a duplicate of bug 56671. *** This bug has been marked as a duplicate of bug 56671 ***
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 63728, which changed state. Bug 63728 Summary: Memory exhaustion using constexpr constructors for classes with large array members https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63728 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #1 from Senthil Kumar Selvaraj --- A workaround is to disable constant merging (-fno-merge-constants).
[Bug tree-optimization/63586] x+x+x+x -> 4*x in gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63586 --- Comment #8 from kugan at gcc dot gnu.org --- Author: kugan Date: Wed May 18 00:58:45 2016 New Revision: 236356 URL: https://gcc.gnu.org/viewcvs?rev=236356&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2016-05-17 Kugan Vivekanandarajah PR middle-end/63586 * gcc.dg/tree-ssa/pr63586-2.c: New test. * gcc.dg/tree-ssa/pr63586.c: New test. * gcc.dg/tree-ssa/reassoc-14.c: Adjust multiplication count. gcc/ChangeLog: 2016-05-17 Kugan Vivekanandarajah PR middle-end/63586 * tree-ssa-reassoc.c (transform_add_to_multiply): New. (reassociate_bb): Call transform_add_to_multiply. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-14.c trunk/gcc/tree-ssa-reassoc.c
[Bug middle-end/70795] [7 Regression] gcc/libjava/interpret.cc:1948:1: ICE: in binds_to_current_def_p, at symtab.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70795 --- Comment #3 from John David Anglin --- Created attachment 38511 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38511&action=edit Revert r235318 Reverting r235318 restores boot.
[Bug c/18063] Gcc doesn't check overflowed size of structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18063 --- Comment #8 from joseph at codesourcery dot com --- I think we should diagnose the definition of the struct (generally, any construction of a too-large fixed-size type in any context).
[Bug libstdc++/70511] tuple constructor from elements hides copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70511 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ville at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from Jonathan Wakely --- Yes, Ville's change to make that function reject the "self" type should have fixed this.
[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 --- Comment #12 from Jerry DeLisle --- I have a patch testing for this. I am not sure this is a regression. I see it as far back as 4.5. I don't have any earlier builds. My thinking is that since this is an ICE on invalid code, I don't want to bother with backports, unless this is just really burning someone somehow.
[Bug rtl-optimization/71148] [7 Regression] Compile time hog w/ -O3 -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71148 Eric Botcazou changed: What|Removed |Added Severity|normal |critical --- Comment #3 from Eric Botcazou --- Can we do something quickly here, either fixing or reverting? This is killing one of our nightly testers.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 54579, which changed state. Bug 54579 Summary: missed optimization: ASR idiom https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54579 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/54579] missed optimization: ASR idiom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54579 Mikhail Maltsev changed: What|Removed |Added Status|NEW |RESOLVED CC||miyuki at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Mikhail Maltsev --- We already fold (-a - 1) into ~a, so the transformation for PR55299 should work for this case too. I added the mentioned test case to gcc/testsuite/gcc.dg/fold-notshift-1.c.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 55299, which changed state. Bug 55299 Summary: missed optimization: ASR idiom https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55299 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/55299] missed optimization: ASR idiom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55299 Mikhail Maltsev changed: What|Removed |Added Status|NEW |RESOLVED CC||miyuki at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Mikhail Maltsev --- Fixed for GCC 7.
[Bug tree-optimization/54579] missed optimization: ASR idiom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54579 --- Comment #2 from Mikhail Maltsev --- Author: miyuki Date: Tue May 17 20:50:22 2016 New Revision: 236344 URL: https://gcc.gnu.org/viewcvs?rev=236344&root=gcc&view=rev Log: Fold bit_not through ASR and rotate gcc/ PR tree-optimization/54579 PR middle-end/55299 * match.pd (~(~X >> Y), ~(~X >>r Y), ~(~X <
[Bug middle-end/55299] missed optimization: ASR idiom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55299 --- Comment #3 from Mikhail Maltsev --- Author: miyuki Date: Tue May 17 20:50:22 2016 New Revision: 236344 URL: https://gcc.gnu.org/viewcvs?rev=236344&root=gcc&view=rev Log: Fold bit_not through ASR and rotate gcc/ PR tree-optimization/54579 PR middle-end/55299 * match.pd (~(~X >> Y), ~(~X >>r Y), ~(~X <
[Bug target/69401] gcc 5.3.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69401 --- Comment #3 from Thomas Petazzoni --- Created attachment 38510 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38510&action=edit Pre-processed source code
[Bug target/69401] gcc 5.3.0 on microblaze: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69401 --- Comment #2 from Thomas Petazzoni --- This still happens with gcc 6.1. With gcc 6.1: - The file can be built with no optimization, with and without -fPIC - The file can be built in -O2 or -O3 without -fPIC - The compiler aborts when either -O2 or -O3 is used in combination with -fPIC I will attach an updated version of the pre-processed file, which can be used with gcc 6. The previous version of flann was causing some unrelated build failures with gcc 6.
[Bug c++/70613] -fabi-version docs don't match implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70613 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jim Wilson --- > What about GCC 6 and the trunk? Shouldn't this apply for those branches > too? In fact if it does apply then this patch should have been applied > there first rather than directly to the 5 branch? It is a backport of a patch from trunk that was added before the gcc-6 branch was made. It fixes a problem caused by the previous backport of incomplete patches to the gcc-5 branch. So no fix is required on trunk or gcc-6.
[Bug c/71115] Missing warning: excess elements in struct initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71115 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #6 from Manuel López-Ibáñez --- (In reply to Martin Sebor from comment #5) > Confirmed. Similarly to other bug reports involving warnings and macros > defined in system headers this too is caused by -Wno-system-headers and the > macro NULL being defined in system headers. Perhaps this is relevant (from https://gcc.gnu.org/wiki/DiagnosticsGuidelines) In cases where we want to emit diagnostics about a token that is located in a macro that is itself defined in system header, for example, for the NULL macro, using the original location of the token will suppress the diagnostic (unless -Wsystem-header). Instead, one should use: source_location loc = expansion_point_location_if_in_system_header (original_location);
[Bug c++/70613] -fabi-version docs don't match implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70613 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #6 from Andrew Pinski --- (In reply to Jim Wilson from comment #5) > Fixed for gcc-5.4. What about GCC 6 and the trunk? Shouldn't this apply for those branches too? In fact if it does apply then this patch should have been applied there first rather than directly to the 5 branch?
[Bug c++/69793] ICE on invalid code in "cp_lexer_peek_nth_token"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69793 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini --- Mine.
[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146 --- Comment #11 from Marek Polacek --- Author: mpolacek Date: Tue May 17 20:00:41 2016 New Revision: 236343 URL: https://gcc.gnu.org/viewcvs?rev=236343&root=gcc&view=rev Log: PR ipa/71146 * tree-inline.c (expand_call_inline): Call maybe_remove_unused_call_args. * g++.dg/ipa/pr71146.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr71146.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug middle-end/70526] [5/6 Regression] GCC 6 miscompiles Firefox JIT compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526 --- Comment #33 from rguenther at suse dot de --- On May 17, 2016 8:55:26 PM GMT+02:00, guido at trentalancia dot net wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526 > >guido at trentalancia dot net changed: > > What|Removed |Added > > CC||guido at trentalancia dot net > >--- Comment #32 from guido at trentalancia dot net --- >Comment 14 (suggestion to use the -fno-schedule-insns2 compiler flag) >might >provide a possible workaround in relation to the problem which is >hitting >firefox. > >Comment 15 (suggestion to use the -fno-sched-last-insn-heuristic >compiler flag) >surely does not provide a possible workaround in relation to the >problem which >is hitting firefox. Use -fno-strict-aliasing Richard.
[Bug libstdc++/70511] tuple constructor from elements hides copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70511 --- Comment #2 from Ivan Le Lann --- It seems that this has been "fixed". Fedora 24, using "gcc (GCC) 6.1.1 20160510 (Red Hat 6.1.1-2)" gives me the intuitive behavior. I did a local revert of this this commit https://github.com/gcc-mirror/gcc/commit/f388e6c088a34248c4332c8ce1bd41a1b8c2f368 and got the reported behavior back. Regards, Ivan
[Bug c++/71167] New: Long typenames produce extremely hard to read diagnostics and slow down compilation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71167 Bug ID: 71167 Summary: Long typenames produce extremely hard to read diagnostics and slow down compilation time Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vittorio.romeo at outlook dot com Target Milestone: --- Long typenames, usually generated by heavy template metaprogramming code, result in errors that are extremely hard to read and parse. Furthermore, they slow down compilation time significantly. Here's a benchmark and example from the boost::di project: http://melpon.org/wandbox/permlink/7Fh0u2oaQbDmkNV0 The benchmark shows: * How unnecessarily long and hard-to-understand errors are. * How typename erasure techniques can improve compilation times (define TYPENAME_ERASURE to see compilation time improvements). I've encountered this same issue in one of my projects (ECST) - errors were impossible to understand before GCC 6 was released. GCC 6's produced errors pinpoint the issue more accurately, but still produce an enormous amount of unnecessary output. I think this is primarily a defect in error reporting. A flag to control long typename output would be desired and possibly necessary for projects that require the generation of long typenames. I also think that having compilation times speed up when erasing typenames signals some sort of potential compilation optimization for long typenames. P.S.: clang has similar issues. Links: boost::di -> https://github.com/boost-experimental/di ECST -> https://github.com/SuperV1234/ecst
[Bug middle-end/70526] [5/6 Regression] GCC 6 miscompiles Firefox JIT compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526 guido at trentalancia dot net changed: What|Removed |Added CC||guido at trentalancia dot net --- Comment #32 from guido at trentalancia dot net --- Comment 14 (suggestion to use the -fno-schedule-insns2 compiler flag) might provide a possible workaround in relation to the problem which is hitting firefox. Comment 15 (suggestion to use the -fno-sched-last-insn-heuristic compiler flag) surely does not provide a possible workaround in relation to the problem which is hitting firefox.
[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461 --- Comment #11 from Gerhard Steinmetz --- ... some more variations with slightly different "line breaks" : $ cat z6.f program p integer x x = 0 if ( x > &0 ) continue !end $ gfortran-6 z6.f f951: internal compiler error: free_expr0(): Bad expr type $ cat z7.f program p integer x x = 0 if ( x > 0 & ) continue !end $ gfortran-6 z7.f z7.f:4:19: if ( x > 0 1 Error: Syntax error in IF-expression at (1) f951: Error: Unexpected end of file in ‘z7.f’ --- $ cat z8.f program p integer x x = 0 if ( &.true. ) continue !end $ gfortran-6 z8.f f951: internal compiler error: free_expr0(): Bad expr type $ cat z9.f program p integer x x = 0 if ( .true. ) & continue !end $ gfortran-6 z9.f z9.f:4:72: if ( .true. ) 1 Error: Cannot assign to a named constant at (1) f951: Error: Unexpected end of file in ‘z9.f’ --- $ cat za.f program p integer x x = 0 if ( .true. ) x = x + & 1 !end $ gfortran-6 za.f za.f:4:72: if ( .true. ) x = x + 1 Error: Syntax error in expression at (1) f951: Error: Unexpected end of file in ‘za.f’
[Bug c++/70613] -fabi-version docs don't match implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70613 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.4 --- Comment #5 from Jim Wilson --- Fixed for gcc-5.4.
[Bug c++/70613] -fabi-version docs don't match implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70613 --- Comment #4 from Jim Wilson --- Author: wilson Date: Tue May 17 18:42:16 2016 New Revision: 236339 URL: https://gcc.gnu.org/viewcvs?rev=236339&root=gcc&view=rev Log: Make -fabi-version docs match the implementation. gcc/ PR c++/70613 * doc/invoke.texi (-fabi-version): Document version 9. (-Wabi): Document version 9. Mention version 8 is default for GCC 5.1. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/doc/invoke.texi
[Bug c++/70466] [ICE on invalid code in tree check: expected constructor, have parm_decl in convert_like_real, at cp/call.c:6371 with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70466
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Summary|ICE on invalid code in tree |[ICE on invalid code in
|check: expected |tree check: expected
|constructor, have parm_decl |constructor, have parm_decl
|in convert_like_real, at|in convert_like_real, at
|cp/call.c:6371 with |cp/call.c:6371 with
|-std=c++11 |-std=c++11
--- Comment #3 from Jason Merrill ---
A well-formed variant that was accepted by 4.5 (so this is a regression):
template < class T, class S >
struct A
{
explicit A (...) {}
};
template < class T, class S >
A < T, S > foo (T (S::*f) ())
{
return A < T, S > (f);
}
struct B
{
void bar () {}
};
int
main ()
{
foo (&B::bar);
return 0;
}
[Bug rtl-optimization/69008] gcc emits unneeded memory access when passing trivial structs by value (ARM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69008
Michael Collison changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #3 from Michael Collison ---
Changed to component rtl optimization. Occurs on other targets as well. On
MIPS, for example, generates two redundant store to memory at -O2:
(insn 5 23 6 (set (mem/c:SI (reg/f:SI 29 $sp) [1 t+0 S4 A32])
(reg:SI 4 $4)) bugzilla_69008.c:7 310 {*movsi_internal}
(nil))
(insn 6 5 18 (set (mem/c:SI (plus:SI (reg/f:SI 29 $sp)
(const_int 4 [0x4])) [1 t+4 S4 A32])
(reg:SI 5 $5)) bugzilla_69008.c:7 310 {*movsi_internal}
(nil))
(insn 18 6 30 (use (reg/i:SI 2 $2)) bugzilla_69008.c:9 -1
(nil))
(note 30 18 27 NOTE_INSN_EPILOGUE_BEG)
(insn 27 30 32 (clobber (reg:SI 28 $28)) bugzilla_69008.c:9 -1
(nil))
(insn 32 27 29 (sequence [
(jump_insn 28 27 17 (simple_return) bugzilla_69008.c:9 629
{*simple_return}
(nil)
-> simple_return)
(insn 17 28 29 (set (reg/i:SI 2 $2)
(plus:SI (reg:SI 4 $4)
(reg:SI 5 $5))) 13 {*addsi3}
(nil))
]) bugzilla_69008.c:9 -1
(nil))
[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153 --- Comment #7 from Andrew Pinski --- Created attachment 38509 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38509&action=edit Full fix which needs full testing I think I have a full fix. Basically there is no reason why we can't expand directly to the LSE instruction directly instead of doing a split after reload. This exposes the NOT and NEG (for MINUS) early on which then gets optimized like normal RTL. I have not done a bootstrap/test yet but I can do it on a machine which has LSE support in a few minutes.
[Bug c/18063] Gcc doesn't check overflowed size of structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18063
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2005-09-18 01:37:52 |2016-5-17
CC||msebor at gcc dot gnu.org
Known to fail||3.4.2, 5.3.0, 6.1.0, 7.0
--- Comment #7 from Martin Sebor ---
Reconfirmed with today's trunk (7.0), 6.1.0, and all prior supported versions.
It seems that it shouldn't be too hard to diagnose either the definition of the
struct or the sizeof expression.
$ cat uu.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -Wall
-Wextra -Wpedantic -m32 uu.c && ./a.out
struct a {
char x[0x7fff];
char b[0x7fff];
char c[3];
};
int main()
{
__builtin_printf ("%zu\n", sizeof (struct a));
_Static_assert (sizeof (struct a) > sizeof ((struct a*)0)->x, "");
}
uu.c: In function ‘main’:
uu.c:10:37: warning: expression in static assertion is not an integer constant
expression [-Wpedantic]
_Static_assert (sizeof (struct a) > sizeof ((struct a*)0)->x, "");
~~^~
uu.c:10:3: error: static assertion failed: ""
_Static_assert (sizeof (struct a) > sizeof ((struct a*)0)->x, "");
^~
[Bug c++/71166] New: ICE with nested constexpr/initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71166
Bug ID: 71166
Summary: ICE with nested constexpr/initializer
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: max at duempel dot org
Target Milestone: ---
Created attachment 38508
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38508&action=edit
A source file which reproduces the problem
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.1.1-3'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.1.1 20160511 (Debian 6.1.1-3)
Compile the attached source with "g++ -c foo.cxx":
/tmp/foo.cxx: In constructor 'constexpr BarContainer::BarContainer()':
/tmp/foo.cxx:8:8: in constexpr expansion of 'Bar()'
/tmp/foo.cxx:5:22: in constexpr expansion of 'MakeFoo()'
/tmp/foo.cxx:8:8: internal compiler error: in cxx_eval_call_expression, at
cp/constexpr.c:1449
struct BarContainer {
^~~~
0x6f9649 cxx_eval_call_expression
../../src/gcc/cp/constexpr.c:1449
0x6fab6f cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3556
0x6fae5d cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3616
0x6fc651 cxx_eval_store_expression
../../src/gcc/cp/constexpr.c:3123
0x6fa39c cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3633
0x6f9f08 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3901
0x6fa185 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3672
0x6fa185 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3672
0x6fab90 cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:4014
0x6f92d2 cxx_eval_call_expression
../../src/gcc/cp/constexpr.c:1494
0x6fab6f cxx_eval_constant_expression
../../src/gcc/cp/constexpr.c:3556
0x6fd1f6 cxx_eval_outermost_constant_expr
../../src/gcc/cp/constexpr.c:4121
0x6fec81 maybe_constant_init(tree_node*, tree_node*)
../../src/gcc/cp/constexpr.c:4439
0x69b07e build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int)
../../src/gcc/cp/init.c:4176
0x6eb43d cp_gimplify_expr(tree_node**, gimple**, gimple**)
../../src/gcc/cp/cp-gimplify.c:591
0x8d62b5 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.c:10196
0x8d9cb6 gimplify_stmt(tree_node**, gimple**)
../../src/gcc/gimplify.c:5688
0x8d6aa8 gimplify_cleanup_point_expr
../../src/gcc/gimplify.c:5464
0x8d6aa8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../src/gcc/gimplify.c:10652
0x8d9cb6 gimplify_stmt(tree_node**, gimple**)
../../src/gcc/gimplify.c:5688
[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #10 from Marek Polacek --- Thanks a lot, I'll take the PR & post the patch.
[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146 --- Comment #9 from Jan Hubicka --- Aha, this is because we do not re-evaulate the predicates for inlined edges and in the inline order we first inline into thunk and then inline thunk. This results in some extra work done by tree-inline but is harmless. So the patch is OK
[Bug c++/71165] New: std::array with aggregate initialization generates huge code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71165
Bug ID: 71165
Summary: std::array with aggregate initialization generates
huge code
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: personalmountains at gmail dot com
Target Milestone: ---
[mostly copied from a thread on stackoverflow at
http://stackoverflow.com/questions/37260097]
This code takes several seconds to compile and produces a 52,776 byte
executable:
#include
#include
int main()
{
constexpr std::size_t size = 4096;
struct S
{
float f;
S() : f(0.0f) {}
};
std::array a = {}; // <-- note aggregate initialization
for (auto& e : a)
std::cerr << e.f;
return 0;
}
Increasing 'size' seems to increase compilation time and executable size
linearly. I cannot reproduce this behaviour with either clang 3.5 or Visual C++
2015. Using -Os makes no difference. I've reproduced this on g++ 4.9.2 and
5.3.1, but 6.1 also seems to do the same thing.
$ time g++ -O2 -std=c++11 test.cpp
real0m4.178s
user0m4.060s
sys 0m0.068s
Inspecting the assembly code reveals that the initialization of 'a' is
unrolled, generating 4096 movl instructions:
main:
.LFB1313:
.cfi_startproc
pushq %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
subq$16384, %rsp
.cfi_def_cfa_offset 16400
movl$0x, (%rsp)
movl$0x, 4(%rsp)
movq%rsp, %rbx
movl$0x, 8(%rsp)
movl$0x, 12(%rsp)
movl$0x, 16(%rsp)
[...skipping 4000 lines...]
movl$0x, 16376(%rsp)
movl$0x, 16380(%rsp)
This only happens when T has a non-trivial constructor and the array is
initialized using {}. If I do any of the following, g++ generates a simple
loop:
1) Remove S::S();
2) Remove S::S() and initialize S::f in-class;
3) Remove the aggregate initialization (= {});
4) Compile without -O2.
Bugs 59659, 56671 may be relevant. In particular, some of the test cases in bug
59659 seem to still be failing.
[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #8 from Jan Hubicka --- Thanks, Marek, I am looking into it now - the calls in thunk are unconditional, so I would expect the call in thunk to be unreachable iff the call of thunk is unreachable and in that case we should have redirected the thunk itself into __builtin_unreachable. So it seems there is something fishy going on. It may just be artifact on how we drop the conditions when they exceed the threshold. Honza
[Bug target/70860] [nvptx] Revisit cfun->machine->doing_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70860 --- Comment #2 from Thomas Schwinge --- Author: tschwinge Date: Tue May 17 16:08:37 2016 New Revision: 236326 URL: https://gcc.gnu.org/viewcvs?rev=236326&root=gcc&view=rev Log: [PR target/70860] [nvptx] Handle NULL cfun in nvptx_libcall_value Backport GCC trunk r235748: gcc/ PR target/70860 * config/nvptx/nvptx.c (nvptx_libcall_value): Handle NULL cfun. (nvptx_function_value): Assert non-NULL cfun. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/nvptx/nvptx.c
[Bug c/71115] Missing warning: excess elements in struct initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71115
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-05-17
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||4.8.2, 4.9.3, 5.3.0, 6.1.0,
||7.0
--- Comment #5 from Martin Sebor ---
Confirmed. Similarly to other bug reports involving warnings and macros
defined in system headers this too is caused by -Wno-system-headers and the
macro NULL being defined in system headers.
$ cat uu.c && /build/gcc-trunk-svn/gcc/xgcc -B /build/gcc-trunk-svn/gcc -S
-Wsystem-headers -o/dev/null uu.c
#include
const char* a[1] = { "", NULL };
In file included from uu.c:1:0:
uu.c:3:26: warning: excess elements in array initializer
const char* a[1] = { "", NULL };
^
uu.c:3:26: note: (near initialization for ‘a’)
[Bug tree-optimization/71120] [6/7 Regression] Aliasing "struct sockaddr_storage" produces invalid code due to SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71120 Martin Jambor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #3 from Martin Jambor --- I will have a look
[Bug tree-optimization/71120] [6/7 Regression] Aliasing "struct sockaddr_storage" produces invalid code due to SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71120
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
Summary|[6/7 Regression] Aliasing |[6/7 Regression] Aliasing
|"struct sockaddr_storage" |"struct sockaddr_storage"
|produces invalid code |produces invalid code due
||to SRA
--- Comment #2 from Richard Biener ---
Actually the issue is that SRA decomposes the aggregate assignment in a way
leaving the "interesting" piece out. sin_addr.s_addr is at offset 4 bytes
and 4 bytes in size while the scalarization
ss$ss_family_13 = MEM[(struct sockaddr_storage *)&ss3];
ss$__ss_align_4 = MEM[(struct sockaddr_storage *)&ss3 + 8B];
fails to cover that area. It scalarizes
struct sockaddr_storage
{
sa_family_t ss_family;
unsigned long int __ss_align;
char __ss_padding[(128 - (2 * sizeof (unsigned long int)))];
};
but the actual data is of type
struct sockaddr_in
{
sa_family_t sin_family;
in_port_t sin_port;
struct in_addr sin_addr;
unsigned char sin_zero[sizeof (struct sockaddr) -
(sizeof (unsigned short int)) -
sizeof (in_port_t) -
sizeof (struct in_addr)];
};
so somehow it applies "strict aliasing" rules when fully scalarizing the
block copy. That needs to be fixed (with -fno-strict-aliasing an
aggregate copy needs to copy all padding). In this case the scalarization
is also very inefficiently using chars around the calloc call which
will force us to spill all the regs anyway.
All this worked in GCC 5 because somehow we didn't consider to scalarize
ss in the end:
Candidate (4191): ss
Rejected (4190): not aggregate: l
! Disqualifying ss - No scalar replacements to be created.
but I think we're just lucky here. Relevant accesses should be built from
the aggregate assignment
l_11->addr = ss;
which is again of sockaddr_storage type. sockaddr_storage should really have
the may_alias attribute (but in this case this won't help I think).
To recap, with -fno-strict-aliasing the code is valid and should work.
With -fstrict-aliasing the code is bogus and should use memcpy and not
aggregate assignment for both ss = *ss2 and l->addr = ss.
[Bug target/49244] __sync or __atomic builtins will not emit 'lock bts/btr/btc'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244
--- Comment #20 from dhowells at redhat dot com ---
Here's a further underoptimisation with -Os:
bool foo_test_and_change_bit(unsigned long *p)
{
return test_and_change_bit(83, p);
}
is compiled to:
0015 :
15: f0 48 0f ba 7f 08 13lock btcq $0x13,0x8(%rdi)
1c: 0f 92 c0setb %al
1f: c3 retq
However, the bit number on BTCQ is an imm8, so the displacement on the memory
operand is unnecessary if the bit number will fit inside the imm8.
[Bug fortran/70856] [6/7 Regression] ICE with -fopenacc in get_constraint_for_ssa_var, at tree-ssa-structalias.c:2952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70856
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #7 from Martin Liška ---
(In reply to Richard Biener from comment #6)
> (In reply to vries from comment #5)
> > before icf, we have:
> > ...
> > static real(kind=4) A.4[2] = {1.0e+0, 2.0e+0};
> > static real(kind=4) A.1[2] = {1.0e+0, 2.0e+0};
> > ...
> >
> > Then icf does:
> > ...
> > Semantic equality hit:A.4->A.1
> > Assembler symbol names:A.4.3435->A.1.3429
> > Unified; Variable alias has been created.
> > ...
> >
> > And after icf, we have:
> > ...
> > static real(kind=4) A.4[2] = {1.0e+0, 2.0e+0};
> > static real(kind=4) A.1[2];
> > ...
> >
> > What openacc does, is run ipa-pta before and after icf.
> >
> > The compilation succeeds with -fno-ipa-icf.
>
> Hmm, indeed running ICF after IPA PTA invalidates points-to info (eventually
> even causing wrong-code). There is nothing ICF can do here (it would need
> to adjust all points-to bitmaps).
>
> Note that this is true also for non-IPA PTA info.
>
> The wrong-code possibilities (given that we only merge readonly decls in ICF)
> restrict themselves to equality/inequality compares which constitute an area
> in ICF that is fishy anyway.
>
> That said - if ICF would adjust DECL_PT_UID then a testcase like
>
> static const int a[] = { 1, 2, 3, 4 };
> static const int b[] = { 1, 2, 3, 4 };
>
> bool isA (int *p) { return p == a; }
> bool isB (int *p) { return p == b; }
> int main()
> {
> if (! (isA (a) || isB (a)))
> abort ();
> }
In the following sample, we do not merge because of:
"Not unifying; adress of original and alias may be compared."
>
> could start to abort (it's a bit tricky and would involve some disabling
> of some CCP I guess).
>
> Honza, Martin - I suppose if we start to comare DECL_PT_UID in ICF then
> this effectively disables ICF of variables. Any ideas besides adjusting
> DECL_PT_UID in ICF and hoping for the best (on the wrong-code issue)?
I would expect that we'll kill majority of merges of variables.
Well, using the obvious patch:
diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index dda5cac..3c04b5a 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -2258,6 +2258,8 @@ sem_variable::merge (sem_item *alias_item)
varpool_node::create_alias (alias_var->decl, decl);
alias->resolve_alias (original);
+ if (DECL_PT_UID_SET_P (original->decl))
+ SET_DECL_PT_UID (alias->decl, DECL_PT_UID (original->decl));
if (dump_file)
fprintf (dump_file, "Unified; Variable alias has been created.\n\n");
The ICE has gone. However, I can't imagine if it can have any negative
consequences?
Martin
[Bug target/70981] [7 regression] gcc.target/i386/avx512f-vprord-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70981 Kirill Yukhin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-17 CC||kyukhin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Kirill Yukhin --- Confirmed.
[Bug libgcc/70720] moxie-rtems stanza does not include crti/crtn extra_parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70720 Joel Sherrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Joel Sherrill --- Fix should be on all branches.
[Bug c++/71164] New: tree check fail at cp/pt.c:12961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71164 Bug ID: 71164 Summary: tree check fail at cp/pt.c:12961 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 38507 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38507&action=edit gzipped C++ source code The attached source code, when compiled by gcc dated 20160516, does this: /home/dcb/rpmbuild/BUILD/freefem++-3.46/mpich/download/include/hpddm/include/operator.hpp:60:18: internal compiler error: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:12961 template typename std::enable_if::type>::value, bool>::type ^ 0x110a135 tree_vec_elt_check_failed(int, int, char const*, int, char const*) ../../src/trunk/gcc/tree.c:9950 0x6995f3 tree_vec_elt_check(tree_node const*, int, char const*, int, char const*) ../../src/trunk/gcc/tree.h:3472 0x6c9209 tsubst(tree_node*, tree_node*, int, tree_node*) ../../src/trunk/gcc/cp/pt.c:12961 0x6c228d tsubst_template_arg ../../src/trunk/gcc/cp/pt.c:10374
[Bug sanitizer/71158] ICE in tree_to_uhwi with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71158 Martin Sebor changed: What|Removed |Added Blocks||16994 --- Comment #3 from Martin Sebor --- There are problems in this area. See also bug 69487 and bug 58646. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 [Bug 16994] [meta-bug] VLA and C++
[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153 --- Comment #6 from ktkachov at gcc dot gnu.org --- (In reply to ktkachov from comment #5) > In the foo_clear_bit_unlock case combine tries to match: > (parallel [ > (set (mem/v:DI (reg:DI 88) [-1 S8 A64]) > (unspec_volatile:DI [ > (and:DI (not:DI (reg:DI 85 [ mask ])) > (mem/v:DI (reg:DI 88) [-1 S8 A64])) > (const_int 3 [0x3]) > ] UNSPECV_ATOMIC_OP)) > (clobber (scratch:DI)) > ]) > > which are exactly the semantics of ldclrl but our patterns don't match that But adding a pattern for that to atomics.md doesn't work because the MEM rtx here is volatile and combine performs recog after initialising with init_recog_no_volatile (). Changing that call to just init_recog () in combine_instructions allows this to recognise (but is, of course, not the right way to do this)
[Bug bootstrap/71134] GCC fails to build with in-tree dependencies: missing libopcodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71134 --- Comment #3 from Dan Collins --- https://gcc.gnu.org/install/download.html states that you can "unpack the binutils distribution either in the same directory or a separate one"
[Bug bootstrap/71134] GCC fails to build with in-tree dependencies: missing libopcodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71134 --- Comment #2 from Dan Collins --- https://gcc.gnu.org/install/download.html states that you can "unpack the binutils distribution either in the same directory or a separate one" On Tue, May 17, 2016 at 4:38 AM, rguenth at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71134 > > Richard Biener changed: > >What|Removed |Added > > > Status|UNCONFIRMED |RESOLVED > Resolution|--- |INVALID > > --- Comment #1 from Richard Biener --- > Dropping in binutils is not supported. > > -- > You are receiving this mail because: > You reported the bug.
[Bug middle-end/70526] [5/6 Regression] GCC 6 miscompiles Firefox JIT compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526
--- Comment #31 from Vittorio Zecca ---
It seems the following is related to the FF compilation issue:
The program runs differently depending on the optimization level.
With gcc 5.3.0 runs same regardless of the optimization level.
// g++ -Os/-O2/-O3/-Ofast
// 5.3.0 OK
// 6.1 & 7 FAIL
// 70526
#include
#include
template
struct AlignedStorage2
{
union U
{
char mBytes[sizeof(T)];
uint64_t mDummy;
} u;
const T* addr() const { return reinterpret_cast(u.mBytes); }
T* addr() { return static_cast(static_cast(u.mBytes)); }
};
enum MIRType { MIRType_Object, MIRType_Value, MIRType_None };
struct Register {
uint32_t reg_;
static Register FromCode(uint32_t i) {
Register r = { i };
return r;
}
uint32_t code() const { return reg_; }
};
class TypedOrValueRegister
{
MIRType type_;
AlignedStorage2 typed;
__attribute__((noinline)) Register& dataTyped() { return *typed.addr(); }
public:
TypedOrValueRegister()
: type_(MIRType_None) {}
TypedOrValueRegister(MIRType type, Register reg)
: type_(type)
{
dataTyped() = reg;
}
Register typedReg() const { return *typed.addr(); }
};
class ConstantOrRegister
{
TypedOrValueRegister reg_;
public:
ConstantOrRegister(TypedOrValueRegister reg) : reg_(reg) {}
TypedOrValueRegister reg() const { return reg_; }
};
class LAllocation
{
public:
__attribute__((noinline)) bool isConstant() const { return false; }
};
class LInstruction {
LAllocation alloc;
public:
virtual __attribute__((noinline)) LAllocation* getOperand(size_t n)
{ return &alloc; }
};
__attribute__((noinline)) Register
ToAnyRegister(const LAllocation* a)
{
return Register::FromCode(10);
}
__attribute__((noinline)) ConstantOrRegister
ToConstantOrRegister(LInstruction* lir, size_t n, MIRType type) {
if (type == MIRType_Value)
return TypedOrValueRegister();
const LAllocation* value = lir->getOperand(n);
if (value->isConstant())
return TypedOrValueRegister();
return TypedOrValueRegister(type, ToAnyRegister(value));
}
int main() {
LInstruction lir;
ConstantOrRegister cr = ToConstantOrRegister(&lir, 0, MIRType_Object);
if (cr.reg().typedReg().code() != 10)
fprintf(stderr, "Fail\n");
return 0;
}
[Bug tree-optimization/71031] [6/7 Regression] ICE in extract_range_from_binary_expr_1, at tree-vrp.c:2535 w/ -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71031 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153 --- Comment #5 from ktkachov at gcc dot gnu.org --- In the foo_clear_bit_unlock case combine tries to match: (parallel [ (set (mem/v:DI (reg:DI 88) [-1 S8 A64]) (unspec_volatile:DI [ (and:DI (not:DI (reg:DI 85 [ mask ])) (mem/v:DI (reg:DI 88) [-1 S8 A64])) (const_int 3 [0x3]) ] UNSPECV_ATOMIC_OP)) (clobber (scratch:DI)) ]) which are exactly the semantics of ldclrl but our patterns don't match that
[Bug ipa/71146] [7 Regression] error: __builtin_unreachable or __builtin_trap call with arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71146 --- Comment #7 from Marek Polacek --- I'm afraid I can't really answer that. I can see that while inline_small_functions -> inline_call -> inline_merge_summary -> remap_edge_summaries -> edge_set_predicate determine that for (gdb) p e->caller $29 = (gdb) p e->callee $30 = false_predicate_p (predicate) is true so we redirect caller to __builtin_unreachable. If it helps: $ c++filt <<< _ZThn8_N1C13OnReadSegmentEPKciPi non-virtual thunk to C::OnReadSegment(char const*, int, int*) Does that explain anything? Should I post the patch? (It regtested fine.)
[Bug sanitizer/71163] ICE in get_ubsan_type_info_for_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71163 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- This should be fixed for GCC 7 and GCC 6.
[Bug sanitizer/71163] New: ICE in get_ubsan_type_info_for_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71163
Bug ID: 71163
Summary: ICE in get_ubsan_type_info_for_type
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail 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
Target Milestone: ---
This one seems to be fixed in trunk, I am opening it just in case:
/* gcc -fsanitize=undefined */
/*p.c: In function ‘foo’:
* p.c:15:6: internal compiler error: in get_ubsan_type_info_for_type, at
ubsan.c:305
* void foo(int n)
* ^~~
*0xba9f60 get_ubsan_type_info_for_type
*../../gcc-7-235689/gcc/ubsan.c:305
*0xba9f60 ubsan_type_descriptor(tree_node*, ubsan_print_style)
*../../gcc-7-235689/gcc/ubsan.c:454
*0xbaa4ec ubsan_expand_bounds_ifn(gimple_stmt_iterator*)
*../../gcc-7-235689/gcc/ubsan.c:692
*0xbb01d9 execute
*../../gcc-7-235689/gcc/sanopt.c:696
*/
void foo(int n)
{
struct S
{
int i[n];
} ;
struct S s[1];
int k=0;
s[k];
}
[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #11) > "g++ -E -" compiles as C (see PR 67023) Oops, I mean it preprocesses as C, of course :) > It's till set: s/till/still/
[Bug middle-end/70526] [5/6 Regression] GCC 6 miscompiles Firefox JIT compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526 --- Comment #30 from rguenther at suse dot de --- On Tue, 17 May 2016, zeccav at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526 > > Vittorio Zecca changed: > >What|Removed |Added > > CC||zeccav at gmail dot com > > --- Comment #29 from Vittorio Zecca --- > It still fails on gcc 6.1 and 7. > And it inhibits building of firefox with default options. As far as I understand this is a firefox bug.
[Bug target/70809] [AArch64] aarch64_vmls pattern should be rejected if -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70809 --- Comment #4 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue May 17 13:08:01 2016 New Revision: 236321 URL: https://gcc.gnu.org/viewcvs?rev=236321&root=gcc&view=rev Log: [AArch64] PR target/70809: Delete aarch64_vmls pattern Backport from mainline 2016-05-17 Kyrylo Tkachov PR target/70809 * config/aarch64/aarch64-simd.md (aarch64_vmls): Delete. * gcc.target/aarch64/pr70809_1.c: New test. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/aarch64/pr70809_1.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/aarch64/aarch64-simd.md branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2005-12-31 03:19:52 |2016-5-17
--- Comment #11 from Jonathan Wakely ---
(In reply to Jan van Dijk from comment #10)
> Has this been (partly) fixed in the meantime? The OP's test program compiles
> just fine with:
>
> g++ (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064]
> g++ (SUSE Linux) 5.3.1 20160412 [gcc-5-branch revision 234894]
> g++ (GCC) 7.0.0 20160516 (experimental)
> x86_64-w64-mingw32.shared-g++ (GCC) 4.9.3
It's not fixed, but we reduced the internal header dependencies so that
no longer includes
Try:
#include
using namespace std;
const double M_PI = 3.1415;
int main()
{
double pi = M_PI;
}
In file included from /home/jwakely/gcc/7/include/c++/7.0.0/cmath:45:0,
from /home/jwakely/gcc/7/include/c++/7.0.0/random:38,
from g.cc:1:
g.cc:4:14: error: expected unqualified-id before numeric constant
const double M_PI = 3.1415;
^
g.cc: In function ‘int main()’:
g.cc:8:12: warning: unused variable ‘pi’ [-Wunused-variable]
double pi = M_PI;
^~
> I also see that GNU_SOURCE is no longer implicitly defined. At least, I do
> not
> see that in the output of "g++ -dM -E - < /dev/null" anymore.
>
> Are there any remaining issues, or should this report be closed?
"g++ -E -" compiles as C (see PR 67023)
It's till set:
$ g++ -x c++ -E -dM -
[Bug middle-end/70526] [5/6 Regression] GCC 6 miscompiles Firefox JIT compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70526 Vittorio Zecca changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #29 from Vittorio Zecca --- It still fails on gcc 6.1 and 7. And it inhibits building of firefox with default options.
[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71161 --- Comment #7 from Ilya Enkovich --- (In reply to rguent...@suse.de from comment #6) > Well, the fact that libgo has a lot of execute fails doesn't point to > libsanitizer. Maybe to split-stack support, who knows. > > What is special about r236090 that would change behavior of glibc? I'm really surprised with this fallback. r236090 slightly extends STV and allows 64bit integer constants processing on xmm registers. I suppose particular glibc headers might just trigger some rare case and result in wrong code.
[Bug tree-optimization/71132] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71132 --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue May 17 12:53:30 2016 New Revision: 236320 URL: https://gcc.gnu.org/viewcvs?rev=236320&root=gcc&view=rev Log: 2016-05-17 Richard Biener PR tree-optimization/71132 * tree-loop-distribution.c (create_rdg_cd_edges): Pass in loop. Only add control dependences for blocks in the loop. (build_rdg): Adjust. (generate_code_for_partition): Return whether loop should be destroyed and delay that. (distribute_loop): Likewise. (pass_loop_distribution::execute): Record loops to be destroyed and perform delayed destroying of loops. * gcc.dg/torture/pr71132.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr71132.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-loop-distribution.c
[Bug tree-optimization/71132] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71132 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug target/71162] New: powerpc64 __atomics should probably emit bne- after stdcx.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71162
Bug ID: 71162
Summary: powerpc64 __atomics should probably emit bne- after
stdcx.
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Target Milestone: ---
On powerpc64, __atomic_fetch_or(), for example, emits a BNE instruction after
the STDCX. instruction to work out whether it needs to retry. For example,
compiling this:
static __always_inline
bool iso_test_and_set_bit(long bit, volatile unsigned long *addr, int memorder)
{
unsigned long mask = 1UL << (bit & (64 - 1));
unsigned long old;
addr += bit >> 6;
old = __atomic_fetch_or(addr, mask, memorder);
return old & mask;
}
long iso_t_a_s(long bit, volatile unsigned long *addr)
{
return iso_test_and_set_bit(bit, addr, __ATOMIC_SEQ_CST);
}
produces this:
00e4 <.iso_t_a_s>:
e4: 7c 00 04 ac hwsync
e8: 54 6a 06 be clrlwi r10,r3,26
ec: 7c 63 36 74 sradi r3,r3,6
f0: 39 20 00 01 li r9,1
f4: 78 63 1f 24 rldicr r3,r3,3,60
f8: 7d 29 50 36 sld r9,r9,r10
fc: 7c 84 1a 14 add r4,r4,r3
100: 7c 60 20 a8 ldarx r3,0,r4
104: 7c 6a 4b 78 or r10,r3,r9
108: 7d 40 21 ad stdcx. r10,0,r4
10c: 40 82 ff f4 bne 100 <.iso_t_a_s+0x1c>
110: 4c 00 01 2c isync
114: 7d 29 18 38 and r9,r9,r3
118: 30 69 ff ff addic r3,r9,-1
11c: 7c 63 49 10 subfe r3,r3,r9
120: 4e 80 00 20 blr
with gcc-6.1.1 targetted at powerpc64-linux-gnu and -Os.
Hopefully the need to retry is unlikely, so BNE- should probably be emitted
rather than BNE.
[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71161 --- Comment #6 from rguenther at suse dot de --- On Tue, 17 May 2016, ienkovich at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71161 > > --- Comment #5 from Ilya Enkovich --- So > do all of r236090 related failures are reproducible with glibc 2.11.3 > only? I only tried 2.11.3 and 2.18 (no intermediate versions), yes. > IIUC the problem most probably hides in sanitizer runtime libraries and you > can't make preprocessed testcase reproducible with other Glibc, right? Well, the fact that libgo has a lot of execute fails doesn't point to libsanitizer. Maybe to split-stack support, who knows. What is special about r236090 that would change behavior of glibc?
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 --- Comment #9 from Marc Glisse --- (In reply to rguent...@suse.de from comment #8) > Not that I like this proposal at all (given it changes function arg > evaluation order on x86_64). Does it? "the function is evaluated before all its arguments, but any pair of arguments (from the argument list) is indeterminately sequenced" The notation a(b1, b2, b3) means that there is no particular order between b1 and b2, otherwise it would be written a(b, c, d).
[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71161 --- Comment #5 from Ilya Enkovich --- So do all of r236090 related failures are reproducible with glibc 2.11.3 only? IIUC the problem most probably hides in sanitizer runtime libraries and you can't make preprocessed testcase reproducible with other Glibc, right?
[Bug target/70809] [AArch64] aarch64_vmls pattern should be rejected if -ffp-contract=off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70809 --- Comment #3 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue May 17 12:15:05 2016 New Revision: 236318 URL: https://gcc.gnu.org/viewcvs?rev=236318&root=gcc&view=rev Log: [AArch64] PR target/70809: Delete aarch64_vmls pattern PR target/70809 * config/aarch64/aarch64-simd.md (aarch64_vmls): Delete. * gcc.target/aarch64/pr70809_1.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr70809_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64-simd.md trunk/gcc/testsuite/ChangeLog
[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71161 --- Comment #4 from Richard Biener --- Created attachment 38506 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38506&action=edit testresults
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 --- Comment #8 from rguenther at suse dot de --- On Tue, 17 May 2016, glisse at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 > > --- Comment #7 from Marc Glisse --- > (In reply to Richard Biener from comment #6) > > C11 6.5.16/3 suggests that the LHS "operand" is evaluated in unspecified > > order. > > It seems that C++ is moving towards specifying the order > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r1.pdf > > I don't remember the status exactly, but I think this is going more or > less as is into C++17. I interpret the 5. b @= a example in "4 A Solution" as applying to assignment and op-assignment like +=. So the gimplifier change would agree with this (phew). Not that I like this proposal at all (given it changes function arg evaluation order on x86_64).
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 --- Comment #7 from Marc Glisse --- (In reply to Richard Biener from comment #6) > C11 6.5.16/3 suggests that the LHS "operand" is evaluated in unspecified > order. It seems that C++ is moving towards specifying the order http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r1.pdf I don't remember the status exactly, but I think this is going more or less as is into C++17.
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104 --- Comment #6 from Richard Biener --- C11 6.5.16/3 suggests that the LHS "operand" is evaluated in unspecified order. 6.5.2.2/10 says function argument "operands" are evaluated before the actual call (which denotes a sequence point) and the rest are "indeterminately sequenced" with respect to the call. This means that the following patch should be valid (not requiring to spill the load of the pointer would improve code-gen as well). Let's see if it passes testing. Index: gcc/gimplify.c === --- gcc/gimplify.c (revision 236309) +++ gcc/gimplify.c (working copy) @@ -4708,10 +4708,6 @@ gimplify_modify_expr (tree *expr_p, gimp that is what we must do here. */ maybe_with_size_expr (from_p); - ret = gimplify_expr (to_p, pre_p, post_p, is_gimple_lvalue, fb_lvalue); - if (ret == GS_ERROR) -return ret; - /* As a special case, we have to temporarily allow for assignments with a CALL_EXPR on the RHS. Since in GIMPLE a function call is a toplevel statement, when gimplifying the GENERIC expression @@ -4729,6 +4725,10 @@ gimplify_modify_expr (tree *expr_p, gimp if (ret == GS_ERROR) return ret; + ret = gimplify_expr (to_p, pre_p, post_p, is_gimple_lvalue, fb_lvalue); + if (ret == GS_ERROR) +return ret; + /* In case of va_arg internal fn wrappped in a WITH_SIZE_EXPR, add the type size as argument to the call. */ if (TREE_CODE (*from_p) == WITH_SIZE_EXPR)
[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71161 --- Comment #3 from Richard Biener --- Updating to r236315, the fix for PR71114 doesn't fix it. I'm going to attach testresults after all testing finished.
[Bug lto/71089] [7 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71089 --- Comment #7 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71089 > > --- Comment #6 from Markus Trippelsdorf --- > (In reply to Jan Hubicka from comment #5) > > Hi, > > I reproduced the firefox ICE now (it needs -O3 instead of default flags). I > > am testing > > the following patch which fixes some confusion between thunk and non-thunk > > inline clones > > (there can be both, because we can first inline thunk, then inline into > > thunk and then > > inline the whole thing again) > > The segfault is gone, but I still see the ICE: > > lto1: internal compiler error: in lto_output_node, at lto-cgraph.c:473 I reproduce it too, I am looking into it now. I have also patch to fix the metrics to tell inliner that thunks are really cheap. Without this patch we inline a lot of thunks and seem to trip some itneresting cases for partitioning. Honza
[Bug lto/71159] [7 regression] ICE in lto_output_edge() lto-cgraph.c:263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71159 --- Comment #4 from Dmitry G. Dyachenko --- (In reply to Jan Hubicka from comment #3) > Sorry, got it wrong way around. > Index: lto-cgraph.c > === > --- lto-cgraph.c(revision 236275) > +++ lto-cgraph.c(working copy) > @@ -259,7 +259,7 @@ lto_output_edge (struct lto_simple_outpu >streamer_write_gcov_count_stream (ob->main_stream, edge->count); > >bp = bitpack_create (ob->main_stream); > - uid = (!gimple_has_body_p (edge->caller->decl) > + uid = (!gimple_has_body_p (edge->caller->decl) || > edge->caller->thunk.thunk_p > ? edge->lto_stmt_uid : gimple_uid (edge->call_stmt) + 1); >bp_pack_enum (&bp, cgraph_inline_failed_t, > CIF_N_REASONS, edge->inline_failed); r236310 + patch PASS. Thank you!
[Bug lto/71089] [7 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71089 --- Comment #6 from Markus Trippelsdorf --- (In reply to Jan Hubicka from comment #5) > Hi, > I reproduced the firefox ICE now (it needs -O3 instead of default flags). I > am testing > the following patch which fixes some confusion between thunk and non-thunk > inline clones > (there can be both, because we can first inline thunk, then inline into > thunk and then > inline the whole thing again) The segfault is gone, but I still see the ICE: lto1: internal compiler error: in lto_output_node, at lto-cgraph.c:473 0x10594813 lto_output_node ../../gcc/gcc/lto-cgraph.c:473 0x10594813 output_symtab() ../../gcc/gcc/lto-cgraph.c:1021 0x105acb6f lto_output() ../../gcc/gcc/lto-streamer-out.c:2386 0x106365db write_lto ../../gcc/gcc/passes.c:2452 0x1063be17 ipa_write_optimization_summaries(lto_symtab_encoder_d*) ../../gcc/gcc/passes.c:2656 0x1017d743 do_stream_out ../../gcc/gcc/lto/lto.c:2294 0x1018c88b stream_out ../../gcc/gcc/lto/lto.c:2358 0x1018c88b lto_wpa_write_files ../../gcc/gcc/lto/lto.c:2475 0x1018c88b do_whole_program_analysis ../../gcc/gcc/lto/lto.c:3157 0x1018c88b lto_main() ../../gcc/gcc/lto/lto.c:3317
[Bug lto/71159] [7 regression] ICE in lto_output_edge() lto-cgraph.c:263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71159 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug tree-optimization/71104] [7 Regression] ICE: verify_ssa failed (with vfork / error: definition in block 3 does not dominate use in block 7 )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
--- Comment #5 from Richard Biener ---
Interesting one. Not that I think we previously handled this "correctly":
:
foo ();
:
p.0 = p;
:
D.1765 = vfork ();
*p.0 = D.1765;
return;
:
ABNORMAL_DISPATCHER (0);
so we keep p.0 in a register around the vfork call and only as we are lucky
and use eax which we need to spill around vfork it works.
The original testcase has the same issue and in GCC 6 was gimplified to
bar ()
{
struct globals * ptr.0;
int D.1766;
foo (0);
ptr.0 = ptr;
{
int pid;
pid = vfork ();
{
if (pid < 0) goto ; else goto ;
:
foo (0);
:
}
D.1766 = pid;
}
ptr.0->helper_pid = D.1766;
The only solution to fix the ICE I see is to dig into the RHS to find a
possible ECF_RETURNS_TWICE call before gimplifying the LHS in
gimplify_modify_expr and turn off ->into_ssa in that case.
Not sure if it would be ok to swap LHS and RHS gimplification here
(RHS is gimplified to a CALL_EXPR first, but at least its arguments
are already gimplified there). I'll need to lookup the standard for
sequence points here.
[Bug lto/71089] [7 Regression] Failed to build 483.xalancbmk in SPEC CPU 2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71089
--- Comment #5 from Jan Hubicka ---
Hi,
I reproduced the firefox ICE now (it needs -O3 instead of default flags). I am
testing
the following patch which fixes some confusion between thunk and non-thunk
inline clones
(there can be both, because we can first inline thunk, then inline into thunk
and then
inline the whole thing again)
Index: ipa-inline-transform.c
===
--- ipa-inline-transform.c (revision 236275)
+++ ipa-inline-transform.c (working copy)
@@ -587,9 +587,10 @@ preserve_function_body_p (struct cgraph_
gcc_assert (symtab->global_info_ready);
gcc_assert (!node->alias && !node->thunk.thunk_p);
- /* Look if there is any clone around. */
- if (node->clones && !node->clones->thunk.thunk_p)
-return true;
+ /* Look if there is any non-thunk clone around. */
+ for (node = node->clones; node; node = node->next_sibling_clone)
+if (!node->thunk.thunk_p)
+ return true;
return false;
}
Index: lto-cgraph.c
===
--- lto-cgraph.c(revision 236275)
+++ lto-cgraph.c(working copy)
@@ -259,7 +259,7 @@ lto_output_edge (struct lto_simple_outpu
streamer_write_gcov_count_stream (ob->main_stream, edge->count);
bp = bitpack_create (ob->main_stream);
- uid = (!gimple_has_body_p (edge->caller->decl)
+ uid = (!gimple_has_body_p (edge->caller->decl) ||
edge->caller->thunk.thunk_p
? edge->lto_stmt_uid : gimple_uid (edge->call_stmt) + 1);
bp_pack_enum (&bp, cgraph_inline_failed_t,
CIF_N_REASONS, edge->inline_failed);
Index: lto-streamer-in.c
===
--- lto-streamer-in.c (revision 236275)
+++ lto-streamer-in.c (working copy)
@@ -952,20 +952,21 @@ fixup_call_stmt_edges (struct cgraph_nod
fixup_call_stmt_edges_1 (orig, stmts, fn);
if (orig->clones)
for (node = orig->clones; node != orig;)
- {
- fixup_call_stmt_edges_1 (node, stmts, fn);
- if (node->clones)
- node = node->clones;
- else if (node->next_sibling_clone)
- node = node->next_sibling_clone;
- else
- {
- while (node != orig && !node->next_sibling_clone)
- node = node->clone_of;
- if (node != orig)
- node = node->next_sibling_clone;
- }
- }
+ if (!node->thunk.thunk_p)
+ {
+ fixup_call_stmt_edges_1 (node, stmts, fn);
+ if (node->clones)
+ node = node->clones;
+ else if (node->next_sibling_clone)
+ node = node->next_sibling_clone;
+ else
+ {
+ while (node != orig && !node->next_sibling_clone)
+ node = node->clone_of;
+ if (node != orig)
+ node = node->next_sibling_clone;
+ }
+ }
}
[Bug target/71106] MIPS: Unaligned load/store instructions are not used to access a variable with an aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71106 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-17 Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- > Index: gcc/expr.c > === > --- gcc/expr.c (revision 236309) > +++ gcc/expr.c (working copy) > @@ -4654,9 +4654,7 @@ expand_assignment (tree to, tree from, b > >/* Handle misaligned stores. */ >mode = TYPE_MODE (TREE_TYPE (to)); > - if ((TREE_CODE (to) == MEM_REF > - || TREE_CODE (to) == TARGET_MEM_REF) > - && mode != BLKmode > + if (mode != BLKmode >&& !mem_ref_refers_to_non_mem_p (to) >&& ((align = get_object_alignment (to)) > < GET_MODE_ALIGNMENT (mode)) > > would fix that. Without pruning some of the "pessimistic" handling in > get_object_alignment this will likely result in some code-gen regressions > though. > > Index: gcc/builtins.c > === > --- gcc/builtins.c (revision 236309) > +++ gcc/builtins.c (working copy) > @@ -339,7 +339,7 @@ get_object_alignment_2 (tree exp, unsign > Do so only if get_pointer_alignment_1 did not reveal absolute > alignment knowledge and if using that alignment would > improve the situation. */ > - if (!addr_p && !known_alignment > + if (!addr_p > && TYPE_ALIGN (TREE_TYPE (exp)) > align) > align = TYPE_ALIGN (TREE_TYPE (exp)); >else The above change only affects indirect references as bases though, so I'm not sure whether it will do anything here. The expander change looks OK to me if we want to support this kind of nonsense on strict-alignment platforms.
[Bug tree-optimization/71132] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu with “seg fault”
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71132 --- Comment #3 from Richard Biener --- So the issue is that loop distribution computes control dependences in the function once and queries them after processing some loops already (in this case removing a loop and replacing it with a builtin memset). In this case this leads to the loop header being control dependent on the exit test of the memset loop (sth that doesn't require the endless loop we have here).
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 Ilya Enkovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Ilya Enkovich --- Fixed
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 --- Comment #22 from Ilya Enkovich --- Author: ienkovich Date: Tue May 17 09:28:15 2016 New Revision: 236315 URL: https://gcc.gnu.org/viewcvs?rev=236315&root=gcc&view=rev Log: gcc/ PR target/71114 * config/i386/i386.c (dimode_scalar_chain::convert_op): Fix insertion point for instructions generated by validize_mem. gcc/testsuite/ PR target/71114 * gcc.target/i386/pr70799-1.c: Fix scan for Darwin. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr70799-1.c
[Bug lto/71159] [7 regression] ICE in lto_output_edge() lto-cgraph.c:263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71159 --- Comment #3 from Jan Hubicka --- Sorry, got it wrong way around. Index: lto-cgraph.c === --- lto-cgraph.c(revision 236275) +++ lto-cgraph.c(working copy) @@ -259,7 +259,7 @@ lto_output_edge (struct lto_simple_outpu streamer_write_gcov_count_stream (ob->main_stream, edge->count); bp = bitpack_create (ob->main_stream); - uid = (!gimple_has_body_p (edge->caller->decl) + uid = (!gimple_has_body_p (edge->caller->decl) || edge->caller->thunk.thunk_p ? edge->lto_stmt_uid : gimple_uid (edge->call_stmt) + 1); bp_pack_enum (&bp, cgraph_inline_failed_t, CIF_N_REASONS, edge->inline_failed);
[Bug lto/71159] [7 regression] ICE in lto_output_edge() lto-cgraph.c:263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71159 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka --- Does this help? Index: lto-cgraph.c === --- lto-cgraph.c(revision 236275) +++ lto-cgraph.c(working copy) @@ -259,7 +259,7 @@ lto_output_edge (struct lto_simple_outpu streamer_write_gcov_count_stream (ob->main_stream, edge->count); bp = bitpack_create (ob->main_stream); - uid = (!gimple_has_body_p (edge->caller->decl) + uid = (!gimple_has_body_p (edge->caller->decl) && !edge->caller->thunk.thunk_p ? edge->lto_stmt_uid : gimple_uid (edge->call_stmt) + 1); bp_pack_enum (&bp, cgraph_inline_failed_t, CIF_N_REASONS, edge->inline_failed); I suppose when we inline thunk but also inline into thunk we may end up having wrong lookup for stmt uid here.
[Bug sanitizer/71160] libasan: Backport support for malloc within dlsym
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71160 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Tue May 17 09:17:54 2016 New Revision: 236314 URL: https://gcc.gnu.org/viewcvs?rev=236314&root=gcc&view=rev Log: PR sanitizer/71160 * asan/asan_malloc_linux.cc: Cherry pick upstream r254395 and r269633. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/asan/asan_malloc_linux.cc
[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71161 --- Comment #2 from Dominique d'Humieres --- > Probably dup of PR 71114. Does the patch in comment PR 71114#c13 work for you? It should be PR 71114#c15 (PR 71114#c13 is broken).
[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71161 --- Comment #1 from Uroš Bizjak --- Probably dup of PR 71114. Does the patch in comment PR 71114#c13 work for you?
[Bug target/71153] aarch64 LSE __atomic_fetch_and() generates inversion for constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71153 --- Comment #4 from dhowells at redhat dot com --- That looks better here: 007c : 7c: d2a00801mov x1, #0x40 // #4194304 80: f8611001ldclrl x1, x1, [x0] 84: d65f03c0ret But foo_clear_bit_unlock() still contains the double MVN instructions. From the patch you posted, I take it that only affects constant integer parameters.
[Bug c++/71105] [6/7 regression] lambas with default captures improperly have function pointer conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71105 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.2 Summary|[6 regression] lambas with |[6/7 regression] lambas |default captures improperly |with default captures |have function pointer |improperly have function |conversions |pointer conversions
[Bug target/71106] MIPS: Unaligned load/store instructions are not used to access a variable with an aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71106 Richard Biener changed: What|Removed |Added Target||mips CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Richard Biener --- I think that is "expected" behavior for strict-aling targets that do not provide a movmisalign handler. But newer GCC (like GCC 6 you used) should behave correctly here. The issue seems to be that the misalign handling is restricted to indirect references in expand_assignment. Thus Index: gcc/expr.c === --- gcc/expr.c (revision 236309) +++ gcc/expr.c (working copy) @@ -4654,9 +4654,7 @@ expand_assignment (tree to, tree from, b /* Handle misaligned stores. */ mode = TYPE_MODE (TREE_TYPE (to)); - if ((TREE_CODE (to) == MEM_REF - || TREE_CODE (to) == TARGET_MEM_REF) - && mode != BLKmode + if (mode != BLKmode && !mem_ref_refers_to_non_mem_p (to) && ((align = get_object_alignment (to)) < GET_MODE_ALIGNMENT (mode)) would fix that. Without pruning some of the "pessimistic" handling in get_object_alignment this will likely result in some code-gen regressions though. Index: gcc/builtins.c === --- gcc/builtins.c (revision 236309) +++ gcc/builtins.c (working copy) @@ -339,7 +339,7 @@ get_object_alignment_2 (tree exp, unsign Do so only if get_pointer_alignment_1 did not reveal absolute alignment knowledge and if using that alignment would improve the situation. */ - if (!addr_p && !known_alignment + if (!addr_p && TYPE_ALIGN (TREE_TYPE (exp)) > align) align = TYPE_ALIGN (TREE_TYPE (exp)); else
[Bug target/71161] [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71161 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug target/71161] New: [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71161 Bug ID: 71161 Summary: [7 Regression] Lots of ASAN and libgo runtime FAILs after r236090 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org CC: ienkovich at gcc dot gnu.org Target Milestone: --- Target: i?86-*-* I have bisected the issue that I experience a lot of -m32 bit testing FAILs on x86_64, mostly ASAN runtime errors and libgo execute FAILs. I bisected this to r236090 using make check-gcc RUNTESTFLAGS="--target_board=unix/-m32 asan.exp=global-overflow-1.c" and a build with bootstrap disabled on x86_64-linux with glibc 2.11.3 and binutils 2.24. I do not see those FAILs on a machine with glibc 2.18 and binutils 2.25. IIRC using newer binutils doesn't resolve the issue. The issue makes multilib testing on my primary dev machine useless :/
[Bug target/71114] [7 Regression] Several test suite failures on x86_64-apple-darwin* after revision r236090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71114 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug c++/71117] [6/7 Regression] Overeager application of conversion to function pointer during overload resolution of call to function object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71117 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |6.2 Summary|[6.1 regression] Overeager |[6/7 Regression] Overeager |application of conversion |application of conversion |to function pointer during |to function pointer during |overload resolution of call |overload resolution of call |to function object |to function object
