[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #23 from Joost VandeVondele
---
(In reply to Easwaran Raman from comment #21)
> Created attachment 30690 [details]
> Proposed patch
I tested this patch on top of the one posted to the mailing list (comment #18),
and this fixes the testcase in #6 and #7. However it does not fix the testcase
reported in PR57923 (marked as dup of this PR, and replicated now for
completeness):
gcc -O3 :
char a;
foo (int **p)
{
int b;
for (;;) {
int c[1] = {};
unsigned *d = &c[0];
for (b=7; b; b--)
**p &= --*d >= a;
}
}
[Bug tree-optimization/58246] [4.7/4.8/4.9 Regression] wrong code at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58246 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.4 Summary|wrong code at -O1 and above |[4.7/4.8/4.9 Regression] |(affecting 4.6, 4.7, 4.8, |wrong code at -O1 and above |and trunk) | --- Comment #1 from Jakub Jelinek --- Started with r145494.
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393
--- Comment #24 from Joost VandeVondele
---
Also the other 'dup' PRs still fail (gcc -O3) . Collecting testcases here:
> cat PR58018.c
int a, b, c, d, e;
void bar (int p)
{
int f = b;
e &= p <= (f ^= 0);
}
void foo ()
{
for (; d; d++)
{
bar (a && c);
bar (0);
bar (1);
}
}
> cat PR58131.c
short a;
int b, c;
int d[1][4][2];
void foo ()
{
int *e;
for (b = 1;; b--)
{
if (*e)
break;
for (c = 2; c >= 0; c--)
{
*e |= d[0][3][b] != a;
int *f = &d[0][3][b];
*f = 0;
}
}
}
[Bug tree-optimization/58246] [4.7/4.8/4.9 Regression] wrong code at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58246 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-27 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- We have: # .MEM_13 = VDEF <.MEM_11> tD.1723[1] = 0; # .MEM_15 = VDEF <.MEM_13> tD.1723[a.0_6] = 0; at mergephi1 and cddce1 decides to delete the first of the two stores as needed for some weird reason: processing: _8 = t[a.0_6]; marking necessary through .MEM_4 stmt t[1] = 1; marking necessary through .MEM_3 stmt t[0] = 1; marking necessary through .MEM_15 stmt t[a.0_6] = 0; processing: t[a.0_6] = 0; processing: t[0] = 1; processing: t[1] = 1; processing: a = 0; Eliminating unnecessary statements: Deleting : t[1] = 0; Removed 1 of 18 statements (5%)
[Bug tree-optimization/58247] [4.9 Regression] ICE in tree_unroll_loops_completely at -O3 (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58247 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|ICE in |[4.9 Regression] ICE in |tree_unroll_loops_completel |tree_unroll_loops_completel |y at -O3 (both 32-bit and |y at -O3 (both 32-bit and |64-bit modes) |64-bit modes)
[Bug tree-optimization/58248] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|wrong code at -O3 on|[4.9 Regression] wrong code |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu --- Comment #1 from Jakub Jelinek --- I get ICE instead, starting with r199048 .
[Bug tree-optimization/58248] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248 --- Comment #2 from Zhendong Su --- Jakub, perhaps you used the testcase from 58247, not the one below? I double checked and still get wrong code on this one.
[Bug tree-optimization/58248] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248 --- Comment #3 from Zhendong Su --- (In reply to Jakub Jelinek from comment #1) > I get ICE instead, starting with r199048 . This means that 58247 is probably indeed a dup of 57592, which also started with r199048 (according to the comment on 57592).
[Bug tree-optimization/58248] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248 --- Comment #4 from Jakub Jelinek --- No, the only change I've made to this testcase was instead of using printf use if (c != 1) __builtin_abort ();. If you can, next time please try to adjust the testcases such that they abort if miscompiled and exit with 0 exit status otherwise, gcc testsuite usually doesn't check for output from the testcases.
[Bug tree-optimization/58248] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248
--- Comment #5 from Zhendong Su ---
(In reply to Jakub Jelinek from comment #4)
> No, the only change I've made to this testcase was instead of using
> printf use if (c != 1) __builtin_abort ();.
I checked the modified test case below:
-
struct S
{
int u;
};
int a = 1, b, c = 1, e, *f, *g;
static struct S d = {6};
void foo (int *p)
{
c &= a != *p;
}
int main ()
{
struct S h = d;
int **i = &f;
*i = g = &b;
for (; h.u; h.u--)
{
for (e = 0; e < 2; e++)
{
foo (*i);
*g = 0 > **i;
}
*f = 0;
}
if (c != 1)
__builtin_abort ();
return 0;
}
-
The log:
$ gcc-trunk -O3 small.c
$ a.out
Aborted (core dumped)
$ gcc-trunk -O2 small.c
$ a.out
$ gcc-4.8 -O3 small.c
$ a.out
$
> If you can, next time please try to adjust the testcases such that they
> abort if miscompiled and exit with 0 exit status otherwise, gcc testsuite
> usually doesn't check for output from the testcases.
Got it; will do.
[Bug tree-optimization/58248] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248 --- Comment #6 from Jakub Jelinek --- Are you sure your gcc isn't configured with --enable-checking=release ? I really get: pr58248.c: In function ‘main’: pr58248.c:14:1: error: definition in block 2 follows the use main () ^ for SSA_NAME: _126 in statement: c.2_78 = _16 & _126; pr58248.c:14:1: internal compiler error: verify_ssa failed
[Bug c++/58249] New: [C++11] internal compiler error with std::vector and deleted copy constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58249 Bug ID: 58249 Summary: [C++11] internal compiler error with std::vector and deleted copy constructor Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: janvidar at extatic dot org Using a std::vector and adding a type where the copy constructor has been deleted causes an internal compiler error. Attached a simple source file that reproduces this on my system (Ubuntu 13.04, amd64) g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3. % g++ -c -std=c++11 -Wall -Wextra bug.cpp ‘ Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Preprocessed source stored into /tmp/cc9w4AfQ.out file, please attach this to your bugreport. If I remove the deleted copy constructor it works correctly as expected. If I change std::vector to std::list I get the following output: % g++ -c -std=c++11 -Wall -Wextra bug.cpp (...) /usr/include/c++/4.7/bits/stl_list.h:115:71: error: use of deleted function ‘Element::Element(const Element&)’ bug.cpp:8:2: error: declared here
[Bug c++/58249] [C++11] internal compiler error with std::vector and deleted copy constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58249 Jan Vidar Krey changed: What|Removed |Added CC||janvidar at extatic dot org --- Comment #1 from Jan Vidar Krey --- Created attachment 30704 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30704&action=edit A simple source file reproducing the problem.
[Bug c++/57086] Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57086 Paolo Carlini changed: What|Removed |Added CC||janvidar at extatic dot org --- Comment #10 from Paolo Carlini --- *** Bug 58249 has been marked as a duplicate of this bug. ***
[Bug c++/58249] [C++11] internal compiler error with std::vector and deleted copy constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58249 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC|janvidar at extatic dot org| Resolution|--- |DUPLICATE --- Comment #2 from Paolo Carlini --- Dup. *** This bug has been marked as a duplicate of bug 57086 ***
[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763 --- Comment #13 from Uroš Bizjak --- Steven, is there anything else you are expecting from me to solve this problem?
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 --- Comment #25 from Joost VandeVondele --- *** Bug 58248 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/58248] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248 Joost VandeVondele changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||Joost.VandeVondele at mat dot ethz ||.ch Resolution|--- |DUPLICATE --- Comment #7 from Joost VandeVondele --- (In reply to Jakub Jelinek from comment #6) > Are you sure your gcc isn't configured with --enable-checking=release ? > I really get: > pr58248.c: In function ‘main’: > pr58248.c:14:1: error: definition in block 2 follows the use > main () > ^ > for SSA_NAME: _126 in statement: > c.2_78 = _16 & _126; > pr58248.c:14:1: internal compiler error: verify_ssa failed which makes it very likely yet another dup of PR57393 *** This bug has been marked as a duplicate of bug 57393 ***
[Bug rtl-optimization/57877] wrong code at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57877 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Component|tree-optimization |rtl-optimization Resolution|--- |FIXED --- Comment #1 from Jakub Jelinek --- This was likely introduced with r200723 and got fixed in r200899.
[Bug rtl-optimization/57876] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57876 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Component|tree-optimization |rtl-optimization Resolution|--- |FIXED --- Comment #1 from Jakub Jelinek --- This was likely introduced with r200723 and got fixed in r200899.
[Bug rtl-optimization/57875] wrong code at -O2 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57875 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Component|tree-optimization |rtl-optimization Resolution|--- |FIXED --- Comment #1 from Jakub Jelinek --- Can't reproduce this, but let's assume it was also introduced with r200723 and got fixed in r200899.
[Bug tree-optimization/57861] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57861 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- This was introduced with r200723 and got fixed in r200899.
[Bug tree-optimization/57860] wrong code for bitwise ops with long long literal on x86_64-linux (32-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57860 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- This was introduced with r200723 and got fixed in r200899.
[Bug tree-optimization/57718] [4.9 Regression] ICE in execute_todo, passes.c:2002 at -O3 (both -m32 & -m64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57718 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE Target Milestone|--- |4.9.0 Summary|ICE in execute_todo,|[4.9 Regression] ICE in |passes.c:2002 at -O3 (both |execute_todo, passes.c:2002 |-m32 & -m64)|at -O3 (both -m32 & -m64) --- Comment #1 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 57393 ***
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 --- Comment #26 from Jakub Jelinek --- *** Bug 57718 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/57860] wrong code for bitwise ops with long long literal on x86_64-linux (32-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57860 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Aug 27 09:24:52 2013 New Revision: 202018 URL: http://gcc.gnu.org/viewcvs?rev=202018&root=gcc&view=rev Log: PR rtl-optimization/57860 PR rtl-optimization/57861 PR rtl-optimization/57875 PR rtl-optimization/57876 PR rtl-optimization/57877 * gcc.c-torture/execute/pr57860.c: New test. * gcc.c-torture/execute/pr57861.c: New test. * gcc.c-torture/execute/pr57875.c: New test. * gcc.c-torture/execute/pr57876.c: New test. * gcc.c-torture/execute/pr57877.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr57860.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57861.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57875.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57876.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57877.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/57861] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57861 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Aug 27 09:24:52 2013 New Revision: 202018 URL: http://gcc.gnu.org/viewcvs?rev=202018&root=gcc&view=rev Log: PR rtl-optimization/57860 PR rtl-optimization/57861 PR rtl-optimization/57875 PR rtl-optimization/57876 PR rtl-optimization/57877 * gcc.c-torture/execute/pr57860.c: New test. * gcc.c-torture/execute/pr57861.c: New test. * gcc.c-torture/execute/pr57875.c: New test. * gcc.c-torture/execute/pr57876.c: New test. * gcc.c-torture/execute/pr57877.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr57860.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57861.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57875.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57876.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57877.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/57877] wrong code at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57877 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Tue Aug 27 09:24:52 2013 New Revision: 202018 URL: http://gcc.gnu.org/viewcvs?rev=202018&root=gcc&view=rev Log: PR rtl-optimization/57860 PR rtl-optimization/57861 PR rtl-optimization/57875 PR rtl-optimization/57876 PR rtl-optimization/57877 * gcc.c-torture/execute/pr57860.c: New test. * gcc.c-torture/execute/pr57861.c: New test. * gcc.c-torture/execute/pr57875.c: New test. * gcc.c-torture/execute/pr57876.c: New test. * gcc.c-torture/execute/pr57877.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr57860.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57861.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57875.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57876.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57877.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/57875] wrong code at -O2 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57875 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Tue Aug 27 09:24:52 2013 New Revision: 202018 URL: http://gcc.gnu.org/viewcvs?rev=202018&root=gcc&view=rev Log: PR rtl-optimization/57860 PR rtl-optimization/57861 PR rtl-optimization/57875 PR rtl-optimization/57876 PR rtl-optimization/57877 * gcc.c-torture/execute/pr57860.c: New test. * gcc.c-torture/execute/pr57861.c: New test. * gcc.c-torture/execute/pr57875.c: New test. * gcc.c-torture/execute/pr57876.c: New test. * gcc.c-torture/execute/pr57877.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr57860.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57861.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57875.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57876.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57877.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/57876] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57876 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Tue Aug 27 09:24:52 2013 New Revision: 202018 URL: http://gcc.gnu.org/viewcvs?rev=202018&root=gcc&view=rev Log: PR rtl-optimization/57860 PR rtl-optimization/57861 PR rtl-optimization/57875 PR rtl-optimization/57876 PR rtl-optimization/57877 * gcc.c-torture/execute/pr57860.c: New test. * gcc.c-torture/execute/pr57861.c: New test. * gcc.c-torture/execute/pr57875.c: New test. * gcc.c-torture/execute/pr57876.c: New test. * gcc.c-torture/execute/pr57877.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr57860.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57861.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57875.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57876.c trunk/gcc/testsuite/gcc.c-torture/execute/pr57877.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug gcov-profile/58250] New: -fprofile-use causes: "warning: -fprefetch-loop-arrays is not supported with -Os"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58250
Bug ID: 58250
Summary: -fprofile-use causes: "warning: -fprefetch-loop-arrays
is not supported with -Os"
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at trippelsdorf dot de
Just noticed this issue during a PGO/LTO Firefox build.
During the -fprofile-use phase I always get the following warning:
warning: -fprefetch-loop-arrays is not supported with -Os [enabled by default]
This is caused by rev.193135:
/* Enable sw prefetching at -O3 for CPUS that prefetching is helpful. */
if (flag_prefetch_loop_arrays < 0
&& HAVE_prefetch
- && optimize >= 3
+ && (optimize >= 3 || flag_profile_use)
&& TARGET_SOFTWARE_PREFETCHING_BENEFICIAL)
flag_prefetch_loop_arrays = 1;
Does the following patch look OK?
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 53f53fd..9955ed4 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1506,7 +1506,7 @@ process_options (void)
/* This combination of options isn't handled for i386 targets and doesn't
make much sense anyway, so don't allow it. */
- if (flag_prefetch_loop_arrays > 0 && optimize_size)
+ if (flag_prefetch_loop_arrays > 0 && optimize_size && !flag_profile_use)
{
warning (0, "-fprefetch-loop-arrays is not supported with -Os");
flag_prefetch_loop_arrays = 0;
[Bug fortran/58146] Array slice bounds checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58146 --- Comment #7 from Mikael Morin --- Patch committed: Author: tkoenig Date: Sun Aug 25 22:55:12 2013 New Revision: 201981 URL: http://gcc.gnu.org/viewcvs?rev=201981&root=gcc&view=rev Log: 2013-08-26 Thomas Koenig PR fortran/58146 * array.c (gfc_ref_dimen_size): If possible, use gfc_dep_difference to calculate array refrence sizes. Fall back to integer code otherwise. * dependency.c (discard_nops). Move up. Also discarde widening integer conversions. (gfc_dep_compare_expr): Use discard_nops. 2013-08-26 Thomas Koenig PR fortran/58146 * gfortran.dg/bounds_check_18.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/dependency.c trunk/gcc/testsuite/ChangeLog
[Bug c++/19817] C++ front-end produces a cast instead of just &a.b (when call the destructor)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19817 Paolo Carlini changed: What|Removed |Added CC|gcc-bugs at gcc dot gnu.org| --- Comment #4 from Paolo Carlini --- Andrew, any idea about the current status of this? Note that maybe_fold_offset_to_component_ref doesn't exist anymore
[Bug fortran/53945] Scalar element of assumed-shape dummy array not recognized as C interoperable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53945 Mikael Morin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mikael at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Mikael Morin --- Seems to be accepted with trunk (upcoming 4.9.0). Closing as FIXED.
[Bug tree-optimization/57521] [4.7/4.8 Regression] wrong code for expressions in loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57521 Richard Biener changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] wrong |wrong code for expressions |code for expressions in |in loop at -O3 |loop at -O3 Known to fail||4.8.1 --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue Aug 27 10:10:34 2013 New Revision: 202019 URL: http://gcc.gnu.org/viewcvs?rev=202019&root=gcc&view=rev Log: 2013-08-27 Richard Biener PR tree-optimization/57521 * tree-if-conv.c (if_convertible_bb_p): Verify that at least one edge is non-critical. (find_phi_replacement_condition): Make sure to use a non-critical edge. Cleanup and remove old bug workarounds. (bb_postdominates_preds): Remove. (if_convertible_loop_p_1): Do not compute post-dominators. (combine_blocks): Do not free post-dominators. (main_tree_if_conversion): Likewise. (pass_data_if_conversion): Add TODO_verify_ssa. * gcc.dg/torture/pr57521.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr57521.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug fortran/49076] [F03] ASSOCIATE: Array descriptor passed to explicit-shaped dummy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49076 Mikael Morin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mikael at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Mikael Morin --- Both testcases from coment #0 and comment #2 now output with 4.8 and trunk(4.9): 3 4 3 4 3 4 Assuming fixed.
[Bug fortran/48959] Dummy procedure: Argument mismatch not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48959 Mikael Morin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mikael at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Mikael Morin --- Both 4.8 and trunk(4.9) now output: comment_0.f90:32.18: call minim(param, mysub, result) 1 Error: Interface mismatch in dummy procedure 'subr' at (1): Shape mismatch in argument 'p' I think that's acceptable as a diagnostic. Closing as FIXED.
[Bug fortran/58146] Array slice bounds checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58146 --- Comment #8 from Mikael Morin --- Related bugs: PR 50548, PR 33906
[Bug c++/13981] Give message about incomplete class that might be implicitly upcasted.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13981 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini --- Mine.
[Bug tree-optimization/58227] [4.9 Regression] wrong code (hangs) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58227 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #4 from Bernd Edlinger --- OK, the latest patch from pr58143 seems to fix the deadlock here too.
[Bug lto/58251] New: -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251 Bug ID: 58251 Summary: -flto causes ICE lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: jpakkane at gmail dot com With Gcc 4.8.1 on Ubuntu Saucy x86-64 I can reliably trigger an ICE. As the issue happens during link, I can't reduce it to a single file test case. The steps to reproduce are these: bzr branch lp:libcolumbus cd libcolumbus mkdir build cd build CXXFLAGS=-flto cmake -DCMAKE_BUILD_TYPE=relwithdebinfo .. make The output is this: Linking CXX shared library columbus.cpython-33m.so lto1: internal compiler error: in splice_child_die, at dwarf2out.c:4706 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. lto-wrapper: /usr/bin/c++ returned 1 exit status /usr/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status You need CMake, libicu-dev, python3-dev and libboost-python-dev to compile the library. The version of libboost-python in Ubuntu Saucy is 1.53.
[Bug middle-end/57219] __builtin_isinf_sign source comments more restrictive than documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57219 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED CC||glisse at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marc Glisse --- r202021 | glisse | 2013-08-27 14:39:21 +0200 (Tue, 27 Aug 2013) | 7 lines 2013-08-27 Marc Glisse PR middle-end/57219 * doc/extend.texi (__builtin_isinf_sign): Restrict the return values to -1, 0 and 1.
[Bug lto/57776] [4.9 Regression] FAIL: gcc.dg/lto/pr56297 c_lto_pr56297_0.o-c_lto_pr56297_1.o link, -flto -fno-common (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57776 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #3 from Richard Biener --- Honza - you promised to look at this alias related fallout.
[Bug tree-optimization/57864] [4.7 Regression] ICE in bitmap_set_replace_value, at tree-ssa-pre.c:862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57864 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-08-27 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.7.4 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Confirmed, mine. I _think_ I have fixed a duplicate of this on trunk/4.8 ...
[Bug tree-optimization/52402] IPA-SRA creates aligned loads from unaligned memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52402 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to fail|4.8.1, 4.9.0| --- Comment #6 from Richard Biener --- So you say that on Epiphany the ABI of the function depends on the actual argument alignment? And this alignment is taken from the _argument_, not the type of the function prototype? Thus, if you call foo () at one point with an aligned T and at one point with an unaligned T then ... what? It seems to me the Epiphany port uses disconnected information at call-site vs. function prologue. [this ought to have been a new bugreport instead of hijacking the old one] Marking the old one as fixed (4.6 is closed now). Please open a new bug.
[Bug c++/57850] [4.8/4.9 Regression] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|Option |[4.8/4.9 Regression] Option |-fdump-translation-unit not |-fdump-translation-unit not |working |working
[Bug c++/58252] New: ice in gimple_get_virt_method_for_binfo with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58252
Bug ID: 58252
Summary: ice in gimple_get_virt_method_for_binfo with -O2
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Created attachment 30705
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30705&action=edit
gzipped C++ source code
I just tried to compile package omniORB-4.1.6-5.fc20 with gcc 4.9 trunk dated
20130826. It said
In file included from irstub.cc:37:0:
../omniORB4/irSK.cc:13580:59: internal compiler error: in
gimple_get_virt_method_for_binfo, at gimple-fold.c:3142
POA_CORBA::AbstractInterfaceDef::~AbstractInterfaceDef() {}
^
0x92e140 gimple_get_virt_method_for_binfo(long, tree_node*)
../../src/trunk/gcc/gimple-fold.c:3141
0x96aed4 record_binfo
../../src/trunk/gcc/ipa-devirt.c:439
0x96ae72 record_binfo
../../src/trunk/gcc/ipa-devirt.c:454
0x96ae72 record_binfo
../../src/trunk/gcc/ipa-devirt.c:454
0x96b0e4 possible_polymorphic_call_targets_1
../../src/trunk/gcc/ipa-devirt.c:474
0x96b123 possible_polymorphic_call_targets_1
../../src/trunk/gcc/ipa-devirt.c:480
0x96c098 possible_polymorphic_call_targets(tree_node*, long, bool*, void**)
../../src/trunk/gcc/ipa-devirt.c:652
0x7de330 possible_polymorphic_call_targets
../../src/trunk/gcc/ipa-utils.h:82
0x7de330 analyze_functions
../../src/trunk/gcc/cgraphunit.c:936
0x7dfa85 finalize_compilation_unit()
../../src/trunk/gcc/cgraphunit.c:2200
0x5f3900 cp_write_global_declarations()
../../src/trunk/gcc/cp/decl2.c:4364
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Preprocessed source code attached. Flag -O2 required.
[Bug c++/58252] ice in gimple_get_virt_method_for_binfo with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58252 Paolo Carlini changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Paolo Carlini --- Honza in CC I would say
[Bug tree-optimization/58253] New: IPA-SRA creates aligned loads from unaligned memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58253 Bug ID: 58253 Summary: IPA-SRA creates aligned loads from unaligned memory Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amylaar at gcc dot gnu.org CC: amylaar at gcc dot gnu.org, jamborm at gcc dot gnu.org, rguenth at gcc dot gnu.org Depends on: 52402 Target: epiphany-*-* +++ This bug was initially created as a clone of Bug #52402 +++ What I see on epiphany (at O2 and above, enabling SRA) for gcc.dg/torture/pr52402.c is that the call of foo.isra.0 in main is done using an aligned type: Breakpoint 5, epiphany_function_arg (cum_v=..., mode=TImode, type=0xb7c5f960, named=true) at /home/amylaar/adapteva/git/sdk/srcw/gcc/config/epiphany/epiphany.c:2177 2177 CUMULATIVE_ARGS cum = *get_cumulative_args (cum_v); (gdb) call debug_tree(type) unit size align 32 symtab 0 alias set 3 canonical type 0xb7bed360 precision 32 min max pointer_to_this > TI size constant 128> unit size constant 16> align 64 symtab 0 alias set 3 canonical type 0xb7c5f960 nunits 4 context pointer_to_this > but when the callee foo.isra.0 was compiled before, it got allegedly passed an unaligned type: Breakpoint 5, epiphany_function_arg (cum_v=..., mode=TImode, type=0xb7c6f300, named=true) at /home/amylaar/adapteva/git/sdk/srcw/gcc/config/epiphany/epiphany.c:2177 2177 CUMULATIVE_ARGS cum = *get_cumulative_args (cum_v); (gdb) call debug_tree(type) unit size align 32 symtab 0 alias set 3 canonical type 0xb7bed360 precision 32 min max pointer_to_this > TI size constant 128> unit size constant 16> align 8 symtab 0 alias set -1 canonical type 0xb7c5f960 nunits 4 context > When passing 64-bit aligned types, the epiphany ABI uses register pair(s) to enable double load-store, thus in this case where r0 has already been used, the argument starts at r2; in the less-aligned case, it starts at r1. Thus, the callee expects the argument in a different place than where it has been put by the caller. Richard Biener: :So you say that on Epiphany the ABI of the function depends on the actual :argument alignment? And this alignment is taken from the _argument_, not :the type of the function prototype? Note, these are the types as passed to TARGET_FUNCTION_ARG. The original function prototype is no longer in the picture because the ipa optimizers have used a cloned/specialized function instead, and the types used when constructing the call are not the same as when generating the callee.
[Bug target/57927] -march=core-avx2 different than -march=native on INTEL Haswell (i7-4700K)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57927 H.J. Lu changed: What|Removed |Added CC||areg.melikadamyan at gmail dot com --- Comment #6 from H.J. Lu --- (In reply to Christian Widmer from comment #4) > Created attachment 30703 [details] > Patch to add Ivy Bridge/Haswell detection > > Here is a short patch adding Ivy Bridge and Haswell detection. Because Ivy > Bridge does not support AVX2 it differs a bit from the suggestion above. Ivy Bridge is core-avx-i, not corei7-avx.
[Bug middle-end/58096] [4.9 Regression] gcc.dg/tree-ssa/attr-alias.c fails with r201439
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58096
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comment #5 from Bernd Edlinger ---
Created attachment 30706
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30706&action=edit
proposed patch
This is probably not really a bug in the compiler.
Obviously the -fdump-tree-optimized format was changed,
and the test case should be adapted to not expect a space
after test4:
;; Function main (main, funcdef_no=1, decl_uid=1372, symbol_order=4) (executed
once)
main ()
{
:
test ();
test4.localalias.0.localalias.2 (); [tail call]
return;
}
The test case is inconsistent, because the comment
mentions test1 and test2 can be optimized away,
and the scan-tree-dump-not statements search for
test1 and test2, but there is no test1 in the source code.
[Bug tree-optimization/56933] [4.9 Regression] Vectorizer missing read-write dependency for interleaved accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56933
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Comment #4 from Bernd Edlinger ---
The test case gcc.dg/vect/pr56933.c fails on a pentium II,
because of invalid instruction.
A fairly obvious fix (which works for me) would be:
--- gcc/testsuite/gcc.dg/vect/pr56933.c.jj 2013-04-15 16:08:41.0
+0200
+++ gcc/testsuite/gcc.dg/vect/pr56933.c 2013-08-22 21:12:19.0 +0200
@@ -1,4 +1,5 @@
/* { dg-do run } */
+/* { dg-require-effective-target sse2_runtime } */
extern void abort (void);
void __attribute__((noinline,noclone))
[Bug tree-optimization/56933] [4.9 Regression] Vectorizer missing read-write dependency for interleaved accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56933
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #4)
> The test case gcc.dg/vect/pr56933.c fails on a pentium II,
> because of invalid instruction.
>
> A fairly obvious fix (which works for me) would be:
There is nothing obvious on it (maybe obviously broken).
The vect.exp tests aren't i?86/x86_64 only, so you definitely can't add
unguarded requirements for specific CPUs, it would cause the test not to be run
on ppcs/arm/etc.
The bug in this test is that it specifies { dg-do run }, either it shouldn't
(then the default will be run if CPU supports the -msse2 flags in this case, or
compile otherwise), or it should use the tree-vect.h + check_vect () framework
like many other tests.
> --- gcc/testsuite/gcc.dg/vect/pr56933.c.jj 2013-04-15
> 16:08:41.0 +0200
> +++ gcc/testsuite/gcc.dg/vect/pr56933.c 2013-08-22 21:12:19.0 +0200
> @@ -1,4 +1,5 @@
> /* { dg-do run } */
> +/* { dg-require-effective-target sse2_runtime } */
>
> extern void abort (void);
> void __attribute__((noinline,noclone))
[Bug fortran/58146] Array slice bounds checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58146 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #9 from Thomas Koenig --- Compile-time check done, runtime check still to be done.
[Bug tree-optimization/57994] Constant folding of infinity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57994 --- Comment #15 from Vincent Lefèvre --- If GCC intends to handle Bessel functions j0, j1, jn, y0, y1, yn (POSIX), there may be differences with GNU MPFR. See my messages and bug report: http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/7982 http://permalink.gmane.org/gmane.comp.standards.posix.austin.general/7990 http://sourceware.org/bugzilla/show_bug.cgi?id=15901
[Bug tree-optimization/56933] [4.9 Regression] Vectorizer missing read-write dependency for interleaved accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56933
--- Comment #6 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Bernd Edlinger from comment #4)
> The test case
> gcc.dg/vect/pr56933.c fails on a pentium II,
> because of invalid
> instruction.
>
> A fairly obvious fix (which works for me) would be:
There
> is nothing obvious on it (maybe obviously broken).
The vect.exp tests aren't
> i?86/x86_64 only, so you definitely can't add
unguarded requirements for
> specific CPUs, it would cause the test not to be run on ppcs/arm/etc.
The
> bug in this test is that it specifies { dg-do run }, either it shouldn't
> (then the default will be run if CPU supports the -msse2 flags in this case,
> or
compile otherwise), or it should use the tree-vect.h + check_vect ()
> framework like many other tests.
Oh I thought that it is only for x86...
The problem is that the option -msse2 is somehow used to compile this
and therfore the following statement is generated.
movapd .LC4, %xmm0
I do not see how this test case can test anything unless it scans
the assembler output for this instruction. Maybe there is something
special in the -fdump-tree-xxx that should be looked for?
[Bug tree-optimization/58248] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248 --- Comment #8 from Zhendong Su --- (In reply to Jakub Jelinek from comment #6) > Are you sure your gcc isn't configured with --enable-checking=release ? Jakub, below is my gcc configure: Configured with: ../gcc-trunk/configure --enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-checking --with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk --with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk --prefix=/usr/local/gcc-trunk Should I do "--enable-checking=release" instead of "--disable-checking"? > I really get: > pr58248.c: In function ‘main’: > pr58248.c:14:1: error: definition in block 2 follows the use > main () > ^ > for SSA_NAME: _126 in statement: > c.2_78 = _16 & _126; > pr58248.c:14:1: internal compiler error: verify_ssa failed
[Bug fortran/44646] [F2008] Implement DO CONCURRENT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44646 --- Comment #4 from Tobias Burnus --- Now that Aldy's/Jakub's OMP_SIMD patch (backend only) is in, r202029, - we can use it to annotate DO CONCURRENT loops. (The semantics should be the same - and match vector length of infinity.) For the usage, see also gomp-4_0-branch or the Cilk branches.
[Bug tree-optimization/58248] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248 --- Comment #10 from Zhendong Su --- (In reply to Jakub Jelinek from comment #9) > For testing bugs against trunk it is better to omit both --disable-checking > and --enable-checking=release and just use the default. > Because otherwise the compiler doesn't perform various verifications and you > could see a miscompilation which would otherwise be caught already at > compile time. Okay, thanks Jakub.
[Bug tree-optimization/58248] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58248 --- Comment #9 from Jakub Jelinek --- For testing bugs against trunk it is better to omit both --disable-checking and --enable-checking=release and just use the default. Because otherwise the compiler doesn't perform various verifications and you could see a miscompilation which would otherwise be caught already at compile time.
[Bug target/57927] -march=core-avx2 different than -march=native on INTEL Haswell (i7-4700K)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57927 --- Comment #7 from Christian Widmer --- (In reply to H.J. Lu from comment #6) > (In reply to Christian Widmer from comment #4) > > Created attachment 30703 [details] > > Patch to add Ivy Bridge/Haswell detection > > > > Here is a short patch adding Ivy Bridge and Haswell detection. Because Ivy > > Bridge does not support AVX2 it differs a bit from the suggestion above. > > Ivy Bridge is core-avx-i, not corei7-avx. Indeed it is. Although I have sent my wrong version to the mailing list a corrected version has been committed to trunk in the meantime which has later been amended by further model numbers. This bug can probably be closed now.
[Bug c++/58254] New: ICE when using PGO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58254
Bug ID: 58254
Summary: ICE when using PGO
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hrebejkt at gmail dot com
Created attachment 30707
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30707&action=edit
preprocessed testcase source file
Error message:
main.cpp: In destructor ‘std::_Function_base::~_Function_base()’:
main.cpp:207:1: internal compiler error: Neoprávněný přístup do paměti
(SIGSEGV)
GCC version:
Using built-in specs.
COLLECT_GCC=g++-4.8.1
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.1/configure --program-suffix=-4.8.1
Thread model: posix
gcc version 4.8.1 (GCC)
Cammands that trigger the bug:
g++-4.8.1 -std=c++11 -fprofile-generate -o test main.ii
./test
g++-4.8.1 -std=c++11 -fprofile-use -o test main.ii
Additional info:
There was no error when compiling without PGO and there was no error when
compiling (with PGO) using gcc 4.7.2.
Code overview:
Preprecessed and reduce C++ source file is attached. It originally looked like
this:
#include
void g(std::function f)
{}
int main(){
g([] {} );
}
[Bug c++/58254] ICE when using PGO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58254 --- Comment #1 from Paolo Carlini --- Doesn't look like a C++ front-end issue.
[Bug target/57927] -march=core-avx2 different than -march=native on INTEL Haswell (i7-4700K)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57927 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug c++/58255] New: [C++11] explicit delegating constructor with no arguments wrongly rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58255
Bug ID: 58255
Summary: [C++11] explicit delegating constructor with no
arguments wrongly rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/10458361
Test:
struct A {
explicit A() { } // remove explicit -> compiles fine
A(int x) : A() { }
};
Builds with Clang.
Fails using g++ (GCC) 4.9.0 20130827 (experimental):
g++ -c -std=c++11 /tmp/t1.cc -o /tmp/t.o
/tmp/t1.cc: In constructor 'A::A(int)':
/tmp/t1.cc:3:16: error: no matching function for call to 'A::A()'
A(int x) : A() { }
^
/tmp/t1.cc:3:16: note: candidates are:
/tmp/t1.cc:3:3: note: A::A(int)
A(int x) : A() { }
^
/tmp/t1.cc:3:3: note: candidate expects 1 argument, 0 provided
/tmp/t1.cc:1:8: note: constexpr A::A(const A&)
struct A {
^
/tmp/t1.cc:1:8: note: candidate expects 1 argument, 0 provided
/tmp/t1.cc:1:8: note: constexpr A::A(A&&)
/tmp/t1.cc:1:8: note: candidate expects 1 argument, 0 provided
This has been broken since at least gcc-4.7
[Bug c/58256] New: gcc for h8300 internal compiler error: in maybe_record_trace_start
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256
Bug ID: 58256
Summary: gcc for h8300 internal compiler error: in
maybe_record_trace_start
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gang.chen at asianux dot com
[root@dhcp122 linux-next]# /usr/local/bin/h8300-gchen-elf-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/h8300-gchen-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/h8300-gchen-elf/4.9.0/lto-wrapper
Target: h8300-gchen-elf
Configured with: ../gcc-4.9.0/configure --target=h8300-gchen-elf
--without-header --disable-nls --enable-language=c --disable-threads
--disable-shared --enable-werror=no
Thread model: single
gcc version 4.9.0 20130827 (experimental) (GCC)
In file included from include/linux/thread_info.h:11:0,
from include/linux/preempt.h:9,
from include/linux/spinlock.h:50,
from include/linux/mmzone.h:7,
from include/linux/gfp.h:4,
from include/linux/slab.h:12,
from fs/namei.c:20:
fs/namei.c: In function 'SyS_mknodat':
include/linux/bug.h:33:45: internal compiler error: in
maybe_record_trace_start, at dwarf2cfi.c:2217
#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
^
include/linux/syscalls.h:104:31: note: in expansion of macro
'BUILD_BUG_ON_ZERO'
#define __SC_TEST(t, a) (void)BUILD_BUG_ON_ZERO(!__TYPE_IS_LL(t) && sizeof(t)
> sizeof(long))
^
include/linux/syscalls.h:91:23: note: in expansion of macro '__SC_TEST'
#define __MAP1(m,t,a) m(t,a)
^
include/linux/syscalls.h:92:35: note: in expansion of macro '__MAP1'
#define __MAP2(m,t,a,...) m(t,a), __MAP1(m,__VA_ARGS__)
^
include/linux/syscalls.h:93:35: note: in expansion of macro '__MAP2'
#define __MAP3(m,t,a,...) m(t,a), __MAP2(m,__VA_ARGS__)
^
include/linux/syscalls.h:94:35: note: in expansion of macro '__MAP3'
#define __MAP4(m,t,a,...) m(t,a), __MAP3(m,__VA_ARGS__)
^
include/linux/syscalls.h:97:22: note: in expansion of macro '__MAP4'
#define __MAP(n,...) __MAP##n(__VA_ARGS__)
^
include/linux/syscalls.h:194:3: note: in expansion of macro '__MAP'
__MAP(x,__SC_TEST,__VA_ARGS__);\
^
include/linux/syscalls.h:183:2: note: in expansion of macro '__SYSCALL_DEFINEx'
__SYSCALL_DEFINEx(x, sname, __VA_ARGS__)
^
include/linux/syscalls.h:177:36: note: in expansion of macro 'SYSCALL_DEFINEx'
#define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)
^
fs/namei.c:3209:1: note: in expansion of macro 'SYSCALL_DEFINE4'
SYSCALL_DEFINE4(mknodat, int, dfd, const char __user *, filename, umode_t,
mode,
^
0x68949a maybe_record_trace_start
../../gcc-4.9.0/gcc/dwarf2cfi.c:2217
0x689739 create_trace_edges
../../gcc-4.9.0/gcc/dwarf2cfi.c:2309
0x68981c scan_trace
../../gcc-4.9.0/gcc/dwarf2cfi.c:2522
0x68a29e create_cfi_notes
../../gcc-4.9.0/gcc/dwarf2cfi.c:2548
0x68a29e execute_dwarf2_frame
../../gcc-4.9.0/gcc/dwarf2cfi.c:2903
0x68a29e execute
../../gcc-4.9.0/gcc/dwarf2cfi.c:3399
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.
make[1]: *** [fs/namei.o] Error 1
make: *** [fs] Error 2
[Bug fortran/41209] Add full ATTRIBUTE support to gfortran (ALIGN, (WEAK)ALIAS, ...)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209 --- Comment #9 from Tobias Burnus --- For ALIGN, we should consider following Intel's compiler by also using it for ALLOCATE and not only for static arrays; cf. http://software.intel.com/en-us/articles/data-alignment-to-assist-vectorization (That has to be explicitly spelled out as for C/C++ the aligned attribute - obviously - does not have this effect.)
