[Bug libstdc++/49048] setprecision rounding fails in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49048
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19
06:08:50 UTC ---
printf in glibc rounds, I think you should read something about rounding.
The default rounding mode (and the only one actually implemented for printf) is
round to even. http://www.lmgtfy.com/?q=round+to+even
So
#include stdio.h
int
main (void)
{
printf (%.2f\n, 5798.12500);
printf (%.2f\n, 5798.87500);
return 0;
}
printing
5798.12
5798.88
is correct.
[Bug rtl-optimization/49057] New: benchmark of gcc. a piece of loop code compiled by gcc-4.5.1 is slower compiled by gcc-4.4.2 when run on cortex-a9.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49057
Summary: benchmark of gcc. a piece of loop code compiled by
gcc-4.5.1 is slower compiled by gcc-4.4.2 when run on
cortex-a9.
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kun...@mediatek.com
The following C code is used to do a “integer add” test. The type of n, i, i1,
i2, loop_cnt are all ‘int’. the initial value: loop_cnt=500, i=0, i1=3,
i2=-3.
for (n = loop_cnt; n 0; n--) {/*0x -x - initial value */
i += i1;/*xx -x */
i1 += i2; /*x0 -x */
i1 += i2; /*x-x-x */
i2 += i;/*x-x0*/
i2 += i;/*x-xx*/
i += i1;/*0-xx*/
i += i1;/*-x -xx*/
i1 += i2; /*-x 0 x*/
i1 += i2; /*-x x x*/
i2 += i;/*-x x 0*/
i2 += i;/*-x x -x */
i += i1;/*0x -x */
/*
* Note that at loop end, i1 = -i2
*/
/*
* which is as we started. Thus,
*/
/*
* the values in the loop are stable
*/
}
I use gcc-4.4.2 and gcc-4.5.1 compile this C code, that will generate different
binary code.
Gcc-4.42:
284:e083 addr0, r0, r3
288:e2511001 subsr1, r1, #1; 0x1
28c:e0833082 addr3, r3, r2, lsl #1
290:e0822080 addr2, r2, r0, lsl #1
294:e0800083 addr0, r0, r3, lsl #1
298:e0833082 addr3, r3, r2, lsl #1
29c:e0822080 addr2, r2, r0, lsl #1
2a0:e083 addr0, r3, r0
2a4:1af6 bne284 add_int+0x4c
Gcc-4.5.1:
138:e083 addr0, r0, r3
13c:e0833082 addr3, r3, r2, lsl #1
140:e0822080 addr2, r2, r0, lsl #1
144:e2511001 subsr1, r1, #1
148:e0800083 addr0, r0, r3, lsl #1
14c:e0833082 addr3, r3, r2, lsl #1
150:e0822080 addr2, r2, r0, lsl #1
154:e083 addr0, r3, r0
158:1af6 bne138 add_int+0x4c
As you see, the only one difference is the position of “subsr1, r1, #1”,
and this difference has led to huge differences in performance. The performance
of the latter just has 80% of the former.
[Bug target/49026] [4.7 Regression] FAIL: gcc.target/i386/sse4_1-(ceil|floor)-vec.c execution test at r173809 on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49026 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-05-19 07:08:18 UTC --- Should be fixed by r173845. It is fixed (seehttp://gcc.gnu.org/ml/gcc-testresults/2011-05/msg01935.html ): closing. Thanks for the quick fix.
[Bug c++/49058] New: [C++0x] Bind no-arguments functor failed using std::bind with -pedantic option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49058
Summary: [C++0x] Bind no-arguments functor failed using
std::bind with -pedantic option.
Product: gcc
Version: 4.5.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fl...@flast.jp
GCC rejects following code with -pedantic option.
testcase.cc
#include functional
struct F
{
void
operator()();
};
void f()
{
std::bind( F() );
}
output
$ g++-4.5 -std=c++0x -pedantic testcase.cc
In file included from testcase.cc:1:0:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.5.4/../../../../include/c++/4.5.4/functional:
In instantiation of 'std::_BindF()':
testcase.cc:11:20: instantiated from here
/usr/local/lib/gcc/i686-pc-linux-gnu/4.5.4/../../../../include/c++/4.5.4/functional:1174:39:
error: no match for call to '(const F) ()'
testcase.cc:5:5: note: candidate is: void F::operator()() near match
After GCC 4.6, also faild with no-arguments lambda-expression.
testcase.cc
#include functional
void f()
{
std::bind( []{} );
}
output
$ g++-4.6 -std=c++0x -pedantic testcase.cc
In file included from testcase.cc:1:0:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/functional:
In instantiation of 'std::_Bindf()::lambda()()':
testcase.cc:5:21: instantiated from here
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/functional:1227:32:
error: no match for call to '(volatile f()::lambda()) ()'
testcase.cc:5:17: note: candidates are:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/functional:1227:32:
note: void (*)() conversion
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/functional:1227:32:
note: candidate expects 0 arguments, 1 provided
testcase.cc:5:17: note: f()::lambda() near match
testcase.cc:5:17: note: no known conversion for implicit 'this' parameter
from 'volatile f()::lambda()*' to 'const f()::lambda()*'
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/functional:
In instantiation of 'std::_Bindf()::lambda()()':
testcase.cc:5:21: instantiated from here
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/functional:1240:38:
error: no match for call to '(const volatile f()::lambda()) ()'
testcase.cc:5:17: note: candidates are:
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/functional:1240:38:
note: void (*)() conversion
/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.1/../../../../include/c++/4.6.1/functional:1240:38:
note: candidate expects 0 arguments, 1 provided
testcase.cc:5:17: note: f()::lambda() near match
testcase.cc:5:17: note: no known conversion for implicit 'this' parameter
from 'const volatile f()::lambda()*' to 'const f()::lambda()*'
gcc-4.5 (GCC) 4.5.4 20110512 (prerelease) - Failed
gcc-4.6 (GCC) 4.6.1 20110513 (prerelease) - Failed
gcc-4.7 (GCC) 4.7.0 20110517 (experimental) - Failed
[Bug libstdc++/49048] setprecision rounding fails in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49048 --- Comment #6 from Cecilio s.cecilio at gmail dot com 2011-05-19 07:12:25 UTC --- Thanks for the link. Funny website but a great article at wikipedia. Thanks indeed. Now I understand the issue, so there is no bug anywere! I always understood 'rounding' as 'rounding up'. Thanks for your help and time. Regards, Cecilio
[Bug c++/48869] [4.5/4.6/4.7 Regression] OpenMP task construct fails to instantiate copy constructor(same as Bug 36523)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 07:44:35 UTC --- Author: jakub Date: Thu May 19 07:44:31 2011 New Revision: 173888 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173888 Log: PR c++/48869 * method.c (get_dtor, get_copy_ctor): Add COMPLAIN argument, pass it down to locate_fn_flags. * cp-tree.h (get_dtor, get_copy_ctor): Adjust prototypes. * semantics.c (cxx_omp_create_clause_info): Adjust callers. * cp-gimplify.c: Include splay-tree.h. (splay_tree_compare_decl_uid, omp_var_to_track, omp_cxx_notice_variable): New functions. (struct cp_genericize_omp_taskreg): New type. (struct cp_genericize_data): Add omp_ctx field. (cp_genericize_r): Attempt to determine implicitly determined firstprivate class type variables. (cp_genericize): Clear omp_ctx. * Make-lang.in (cp/cp-gimplify.o): Depend on $(SPLAY_TREE_H). * testsuite/libgomp.c++/pr48869.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr48869.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/Make-lang.in trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/method.c trunk/gcc/cp/semantics.c trunk/libgomp/ChangeLog
[Bug c++/48869] [4.5 Regression] OpenMP task construct fails to instantiate copy constructor(same as Bug 36523)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.1, 4.7.0 Summary|[4.5/4.6/4.7 Regression]|[4.5 Regression] OpenMP |OpenMP task construct fails |task construct fails to |to instantiate copy |instantiate copy |constructor(same as Bug |constructor(same as Bug |36523) |36523) Known to fail|4.7.0 | --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 08:03:37 UTC --- Fixed for 4.6+ so far.
[Bug c++/49043] [OpenMP C++0x]: Compiler error when lambda-function within OpenMP loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49043
--- Comment #2 from Joel Yliluoma bisqwit at iki dot fi 2011-05-19 08:10:06
UTC ---
Even if the lambda function is not called, it happens. Merely defining the
function causes it.
Interestingly though, it does not happen if a method body is defined within the
loop. The code below does not cause the error. So it is restricted to lambda
function bodies.
It also does not happen when calling lambda functions that are defined outside
the loop.
int main()
{
#pragma omp parallel for
for(int a=0; a10; ++a)
{
struct tmp
{
static int test() { return 0; }
};
}
}
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #6 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-19 08:05:32 UTC --- (In reply to comment #5) As a general rule, d specifies the number of significant digits in the result, i.e. the number of digits counting from the first non-zero digit. So in the example all numbers should be formatted with 2 significant digits, i.e. 2 decimal digits if the value rounded to 2 significant digits is smaller than 1, and 1 decimal digit if the value rounded to 2 significant digits is larger than or equal to 1. implicit none integer, parameter :: RT = 8 write(*, (rc,f11.2,4x,'RC')) .995_RT write(*, (rc,g15.2,'RC')) .995_RT write(*, (rd,f11.2,4x,'RD')) .995_RT write(*, (rd,g15.2,'RD')) .995_RT write(*, (ru,f11.2,4x,'RU')) .995_RT write(*, (ru,g15.2,'RU')) .995_RT write(*,'(a)') 12345678901234567890 end 0.99RC 0.99RC 0.99RD 0.99RD 1.00RU 1.0RU 12345678901234567890 and write(*, (ru,f11.1,4x,'RU')) .995_RT gets 1.0RU
[Bug tree-optimization/44897] -flto + ipa-sra misoptimize sqlite (non-plugin only)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44897 vincenzo Innocente vincenzo.innocente at cern dot ch changed: What|Removed |Added CC||vincenzo.innocente at cern ||dot ch --- Comment #16 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-05-19 08:12:20 UTC --- I'm getting a whole bunch of lto1: internal compiler error: Floating point exception using g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure -enable-gold=yes --enable-lto --with-fpmath=avx --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 Thread model: posix gcc version 4.6.1 20110513 (prerelease) (GCC) before submitting a new bug report I would like to know if the patch by Honza quoted below is already in it or still pending
[Bug c++/48869] [4.5/4.6/4.7 Regression] OpenMP task construct fails to instantiate copy constructor(same as Bug 36523)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 08:00:56 UTC --- Author: jakub Date: Thu May 19 08:00:50 2011 New Revision: 173889 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173889 Log: PR c++/48869 * method.c (get_dtor, get_copy_ctor): Add COMPLAIN argument, pass it down to locate_fn_flags. * cp-tree.h (get_dtor, get_copy_ctor): Adjust prototypes. * semantics.c (cxx_omp_create_clause_info): Adjust callers. * cp-gimplify.c: Include splay-tree.h. (splay_tree_compare_decl_uid, omp_var_to_track, omp_cxx_notice_variable): New functions. (struct cp_genericize_omp_taskreg): New type. (struct cp_genericize_data): Add omp_ctx field. (cp_genericize_r): Attempt to determine implicitly determined firstprivate class type variables. (cp_genericize): Clear omp_ctx. * Make-lang.in (cp/cp-gimplify.o): Depend on $(SPLAY_TREE_H). * testsuite/libgomp.c++/pr48869.C: New test. Added: branches/gcc-4_6-branch/libgomp/testsuite/libgomp.c++/pr48869.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/Make-lang.in branches/gcc-4_6-branch/gcc/cp/cp-gimplify.c branches/gcc-4_6-branch/gcc/cp/cp-tree.h branches/gcc-4_6-branch/gcc/cp/method.c branches/gcc-4_6-branch/gcc/cp/semantics.c branches/gcc-4_6-branch/libgomp/ChangeLog
[Bug target/47440] Use LCM for vzeroupper insertion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47440 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.19 08:29:24 CC||ubizjak at gmail dot com Version|4.6.0 |4.7.0 Target Milestone|--- |4.7.0 Summary|Use LCM for vzeroupper |Use LCM for vzeroupper |optimization|insertion Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-05-19 08:29:24 UTC --- Confirmed.
[Bug libstdc++/49048] setprecision rounding fails in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49048 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-19 08:42:45 UTC --- Glad that the issue is clear now. By the way, Cecilio, apparently in your Comment #4 you didn't get my point about the C++ library vs printf: the ISO C++ Standard specifies the behavior of setprecision, precision, and so on, **in terms of printf**, with no intermediate rounding, truncation, or whatelse: really everything must go as-if the number were feed directly to a printf like the one written down by myself and Jakub. Thus, really, if anything, this PR could be *only* a glibc issue. As a matter of fact, isn't an issue at all.
[Bug middle-end/45098] Missed induction variable optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45098 --- Comment #4 from vries at gcc dot gnu.org 2011-05-19 08:49:32 UTC --- Author: vries Date: Thu May 19 08:49:28 2011 New Revision: 173893 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173893 Log: 2011-05-19 Tom de Vries t...@codesourcery.com PR target/45098 * tree-ssa-loop-ivopts.c (determine_iv_cost): Prevent cost_base.cost == 0. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug middle-end/48849] [4.7 Regression] SPEC CPU 2000/2006 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48849
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.05.19 08:49:11
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-19
08:49:11 UTC ---
Btw, I looked into similar ICEs I get on x86_64 SPEC2k6 and the issue is that
LTO TYPE_CANONICAL merging behaves different than the middle-end when it
constructs new pointer types (that is what I was looking at, similar issues
apply to vector and complex and array types I think). That is, for the
middle-end the canonical type of a pointer type is a pointer to the canonical
pointed-to type while LTO TYPE_CANONICAL building does something different.
Now, a simple patch like
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 173724)
+++ gcc/gimple.c(working copy)
@@ -4830,6 +4830,25 @@ gimple_register_canonical_type (tree t)
if (TYPE_MAIN_VARIANT (t) != t)
gimple_register_canonical_type (TYPE_MAIN_VARIANT (t));
+ /* For pointer and reference types do as the middle-end does - the
+ canonical type is a pointer to the canonical pointed-to type. */
+ if (TREE_CODE (t) == POINTER_TYPE)
+{
+ TYPE_CANONICAL (t)
+ = build_pointer_type_for_mode
+ (gimple_register_canonical_type (TREE_TYPE (t)),
+TYPE_MODE (t), TYPE_REF_CAN_ALIAS_ALL (t));
+ return TYPE_CANONICAL (t);
+}
+ else if (TREE_CODE (t) == REFERENCE_TYPE)
+{
+ TYPE_CANONICAL (t)
+ = build_reference_type_for_mode
+ (gimple_register_canonical_type (TREE_TYPE (t)),
+TYPE_MODE (t), TYPE_REF_CAN_ALIAS_ALL (t));
+ return TYPE_CANONICAL (t);
+}
+
if (gimple_canonical_types == NULL)
gimple_canonical_types = htab_create_ggc (16381,
gimple_canonical_type_hash,
gimple_canonical_type_eq, 0);
that I tested after analyzing the issue doesn't work as the middle-end
pointer-type building depends on properly setup TYPE_POINTER_TO lists
which we are only about to construct when re-building canonical types.
Anyway, I was working on this but got distracted.
[Bug c++/49043] [OpenMP C++0x]: Compiler error when lambda-function within OpenMP loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49043
Joel Yliluoma bisqwit at iki dot fi changed:
What|Removed |Added
Summary|[C++0x] Returns from lambda |[OpenMP C++0x]: Compiler
|functions incorrectly |error when lambda-function
|detected as exits from|within OpenMP loop
|OpenMP loops in surrounding |
|code|
--- Comment #1 from Joel Yliluoma bisqwit at iki dot fi 2011-05-19 08:05:26
UTC ---
It also happens if the lambda-function does not explicitly contain the return
statement.
For example, this code triggers the same error.
int main()
{
#pragma omp parallel for
for(int a=0; a10; ++a)
{
auto func = [] () - void { };
func();
}
}
[Bug debug/49047] DW_AT_linkage_name missing for constructors and destructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49047 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 08:17:48 UTC --- My guess is that's because there is no single symbol for them, but two or three.
[Bug target/44217] GCC emits cmpxchg16b which Sun as cannot handle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44217 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-05-19 08:27:49 UTC --- The latest version of Sun as (patch 119961-10 for Solaris 10, snv_164 for Solaris 11) now includes a fix for CR 6938785 as doesn't support cmpxchg16b instruction Since there seems to be no interest whatsoever to provide a workaround in gcc, I'm closing this bug as WONTFIX. Rainer
[Bug c++/49043] [OpenMP C++0x]: Compiler error when lambda-function within OpenMP loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49043 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.05.19 08:55:08 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 08:55:08 UTC --- Created attachment 24287 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24287 gcc46-pr49043.patch Untested fix. That said, I'd advise not to use lambdas in OpenMP regions, because the OpenMP standard doesn't say anything about the data environment of those and how it should behave. Even the upcoming OpenMP 3.1 doesn't cover C++0x, I hope OpenMP 4.0 will.
[Bug middle-end/49054] useless cmp+jmp generated for switch when default: is unreachable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49054 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-19 08:56:11 UTC --- I think this is just an artifact of how we handle __builtin_unreachable ().
[Bug middle-end/45098] Missed induction variable optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45098 --- Comment #5 from vries at gcc dot gnu.org 2011-05-19 09:03:15 UTC --- Author: vries Date: Thu May 19 09:03:12 2011 New Revision: 173894 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173894 Log: 2011-05-19 Tom de Vries t...@codesourcery.com PR target/45098 * tree-ssa-loop-ivopts.c (get_expr_id): Factored new function out of get_loop_invariant_expr_id. (get_loop_invariant_expr_id): Use get_expr_id. (parm_decl_cost): New function. (determine_use_iv_cost_condition): Use get_expr_id and parm_decl_cost. Improve bound cost estimation. Use different inv_expr_id for elim and express cases. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug tree-optimization/44897] -flto + ipa-sra misoptimize sqlite (non-plugin only)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44897 --- Comment #17 from Jan Hubicka hubicka at ucw dot cz 2011-05-19 08:56:37 UTC --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44897 vincenzo Innocente vincenzo.innocente at cern dot ch changed: What|Removed |Added CC||vincenzo.innocente at cern ||dot ch --- Comment #16 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-05-19 08:12:20 UTC --- I'm getting a whole bunch of lto1: internal compiler error: Floating point exception using g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure -enable-gold=yes --enable-lto --with-fpmath=avx --with-build-config=bootstrap-lto --with-gmp-lib=/usr/local/lib64 --with-mpfr-lib=/usr/local/lib64 -with-mpc-lib=/usr/local/lib64 Thread model: posix gcc version 4.6.1 20110513 (prerelease) (GCC) before submitting a new bug report I would like to know if the patch by Honza quoted below is already in it or still pending It is in mainline, I should backport it to 4.6.1. Will try to do it today or tomorrow. Honza -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug fortran/49052] i386 version of gcc-4.5 fails to compile C or Fortran files on CIFS mounts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49052 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-19 08:58:43 UTC --- The issue is that gcc 4.6 does not have large file support enabled and so on 32bit hosts with 64bit file systems you can get this if the inode number does not fit in the 32bit stat structure. That's what we have seen on 32bit userland with 64bit kernels and big fs. Should be fixed for 4.6.
[Bug target/49046] code fragment with inline assembly seg faults gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49046 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.05.19 09:02:03 Component|c |target Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-19 09:02:03 UTC --- And what's the crash?
[Bug fortran/49052] i386 version of gcc-4.5 fails to compile C or Fortran files on CIFS mounts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49052 --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-19 09:01:30 UTC --- Not a GCC bug. As an aside, CIFS mounts work quite well IF the server supports the CIFS Unix extensions; Samba supports those, but IIRC the Windows CIFS server doesn't. Without the Unix extensions, the mounts behave very POSIX-unlike in some situations which makes many applications break, apparently including GCC. HTH, HAND.
[Bug target/49046] code fragment with inline assembly seg faults gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49046 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 09:29:13 UTC --- If the crash is the same as in the #c0 attachment, then you should file it against binutils, not gcc, as it is a bug in the assembler: arm-none-eabi-gcc: Internal error: Segmentation fault (program as)
[Bug middle-end/45098] Missed induction variable optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45098 --- Comment #6 from vries at gcc dot gnu.org 2011-05-19 09:33:52 UTC --- Author: vries Date: Thu May 19 09:33:49 2011 New Revision: 173896 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173896 Log: 2011-05-19 Tom de Vries t...@codesourcery.com PR target/45098 * gcc.target/arm/ivopts.c: New test. * gcc.target/arm/ivopts-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/ivopts-2.c trunk/gcc/testsuite/gcc.target/arm/ivopts.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/49056] [C++0x] ICE: OMP parallel for with template constexpr function, LTO and debug options.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49056 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 09:51:42 UTC --- I don't believe you you can reproduce it with two days old trunk, it has been fixed there a month ago. And has been fixed on the 4.6 branch yesterday too. *** This bug has been marked as a duplicate of bug 48207 ***
[Bug debug/48207] ICE in lhd_set_decl_assembler_name, at langhooks.c:158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48207 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||flast at flast dot jp --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 09:51:42 UTC --- *** Bug 49056 has been marked as a duplicate of this bug. ***
[Bug testsuite/48251] guality_check hangs indefinitely on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48251 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 10:38:20 UTC --- Can this be closed now?
[Bug debug/47624] FAIL: gcc.dg/guality/pr43077-1.c -O1 line 42 c == 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47624 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 10:40:13 UTC --- Can you please ping this patch?
[Bug target/33049] [avr] bit extraction non optimal, inversing logic solves problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33049 Wouter van Gulik wvangulik at xs4all dot nl changed: What|Removed |Added Known to fail|| --- Comment #13 from Wouter van Gulik wvangulik at xs4all dot nl 2011-05-19 10:38:38 UTC --- Yep it looks a lot better now. The if statements could be optimized into the equivalent shift instructions but that is not a AVR backend problem I guess. I noticed that the disassembly shows wrong lengths for some outputs of extzv. Is that a problem?
[Bug c/48985] bogus buffer overflow warning and abort on static flexible array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48985 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-19 10:45:29 UTC --- Author: rguenth Date: Thu May 19 10:45:26 2011 New Revision: 173901 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173901 Log: 2011-05-19 Richard Guenther rguent...@suse.de PR middle-end/48985 * tree-object-size.c (addr_object_size): If the pointed-to variable is a decl use DECL_SIZE_UNIT instead of TYPE_SIZE_UNIT. * gcc.dg/builtin-object-size-11.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/builtin-object-size-11.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-object-size.c
[Bug debug/48333] -fcompare-debug failure (length) - memmove x __builtin_memmove
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48333 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 10:35:16 UTC --- Can you please ping this patch? It makes sense given: case tcc_declaration: /* Consider __builtin_sqrt equal to sqrt. */ return (TREE_CODE (arg0) == FUNCTION_DECL DECL_BUILT_IN (arg0) DECL_BUILT_IN (arg1) DECL_BUILT_IN_CLASS (arg0) == DECL_BUILT_IN_CLASS (arg1) DECL_FUNCTION_CODE (arg0) == DECL_FUNCTION_CODE (arg1)); in operand_equal_p...
[Bug lto/49059] New: Linking with -flto fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49059 Summary: Linking with -flto fails Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: petr.ma...@hotmail.com Hello. I've been using CCfits library to write data into FITS files. The code compiles until I turn LTO on, then it fails with: lto1: internal compiler error: in lto_wpa_write_files, at lto/lto.c:1518 lto-wrapper: g++ returned 1 exit status /usr/bin/ld: lto-wrapper failed collect2: ld returned 1 exit status The problem seems to appear only after invoking writeArrays() on CCfits::Column. OS: Ubuntu 11.04 x64 (2.6.38-8-virtual) GCC: 4.6.0 (also present in 'gcc-4.6-20110506') GCC compiled with: --with-arch=native --with-tune=native --enable-threads=posix --with-fpmath=sse --enable-checking --enable-cloog-backend=isl IDE: Eclipse CDT 7.0.2 Build of configuration Release for project lto_ccfits_fail make all Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Building file: ../src/Main.cpp Invoking: GCC C++ Compiler g++ -I/home/petmal/Eclipse_Projects/lto_ccfits_fail/include -O3 -Wall -c -fmessage-length=0 -flto -save-temps -v -MMD -MP -MFsrc/Main.d -MTsrc/Main.d -osrc/Main.o ../src/Main.cpp Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.6.0/configure --with-arch=native --with-tune=native --enable-threads=posix --with-fpmath=sse --enable-checking --enable-cloog-backend=isl Thread model: posix gcc version 4.6.0 (GCC) COLLECT_GCC_OPTIONS='-I' '/home/petmal/Eclipse_Projects/lto_ccfits_fail/include' '-O3' '-Wall' '-c' '-fmessage-length=0' '-flto' '-save-temps' '-v' '-MMD' '-MP' '-MF' 'src/Main.d' '-MT' 'src/Main.d' '-o' 'src/Main.o' '-shared-libgcc' '-mtune=native' '-march=native' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -E -quiet -v -I /home/petmal/Eclipse_Projects/lto_ccfits_fail/include -MMD src/Main.d -MF src/Main.d -MP -MT src/Main.d -D_GNU_SOURCE ../src/Main.cpp -march=corei7 -mcx16 -msahf -maes -mpclmul -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=corei7 -Wall -fmessage-length=0 -flto -O3 -fpch-preprocess -o Main.ii ignoring nonexistent directory /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /home/petmal/Eclipse_Projects/lto_ccfits_fail/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/x86_64-unknown-linux-gnu /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include /usr/local/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-I' '/home/petmal/Eclipse_Projects/lto_ccfits_fail/include' '-O3' '-Wall' '-c' '-fmessage-length=0' '-flto' '-save-temps' '-v' '-MMD' '-MP' '-MF' 'src/Main.d' '-MT' 'src/Main.d' '-o' 'src/Main.o' '-shared-libgcc' '-mtune=native' '-march=native' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1plus -fpreprocessed Main.ii -march=corei7 -mcx16 -msahf -maes -mpclmul -mpopcnt -msse4.2 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=corei7 -quiet -dumpbase Main.cpp -auxbase-strip src/Main.o -O3 -Wall -version -fmessage-length=0 -flto -o Main.s GNU C++ (GCC) version 4.6.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0, GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.2 warning: GMP header version 5.0.1 differs from library version 4.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C++ (GCC) version 4.6.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.0, GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.2 warning: GMP header version 5.0.1 differs from library version 4.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 04a475928a1f5131bc3081e746d72187 COLLECT_GCC_OPTIONS='-I' '/home/petmal/Eclipse_Projects/lto_ccfits_fail/include' '-O3' '-Wall' '-c' '-fmessage-length=0' '-flto' '-save-temps' '-v' '-MMD' '-MP' '-MF' 'src/Main.d' '-MT' 'src/Main.d' '-o' 'src/Main.o' '-shared-libgcc' '-mtune=native' '-march=native' as --64 -o src/Main.o Main.s COMPILER_PATH=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/ Finished building: ../src/Main.cpp
[Bug lto/49059] Linking with -flto fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49059 --- Comment #1 from Petr petr.malik at hotmail dot com 2011-05-19 10:51:37 UTC --- Created attachment 24288 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24288 Preprocessed source.
[Bug lto/48246] ICE in lto_wpa_write_files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48246 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||petr.malik at hotmail dot ||com --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-19 11:15:19 UTC --- *** Bug 49059 has been marked as a duplicate of this bug. ***
[Bug lto/49059] Linking with -flto fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49059 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-19 11:15:19 UTC --- If you do not add --enable-checking the error will vanish. The check is for optimality of partitioning and asserts that no partition is empty. *** This bug has been marked as a duplicate of bug 48246 ***
[Bug testsuite/48251] guality_check hangs indefinitely on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48251 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-05-19 11:07:14 UTC --- --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 10:38:20 UTC --- Can this be closed now? No, skipping the tests is just a workaround. I mean to look into the root cause of this and would like the PR to be kept open until then. Rainer
[Bug libstdc++/49060] New: use of deleted memory in __gnu_cxx::hashtable::erase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49060 Summary: use of deleted memory in __gnu_cxx::hashtable::erase Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dtar...@redhat.com Created attachment 24289 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24289 reproducer How to reproduce: 1. get the attached reproducer 2. g++ -Wall -g -O0 hashtable.cc -o hashtable 3. valgrind ./hashtable Note: I think this cannot be triggered through normal use of std::hash_map or std::hash_set, because it requires that the bucket contains two nodes with equal key.
[Bug libstdc++/49060] use of deleted memory in __gnu_cxx::hashtable::erase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49060 --- Comment #1 from David Tardon dtardon at redhat dot com 2011-05-19 11:26:42 UTC --- Created attachment 24290 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24290 patch
[Bug c++/49058] [C++0x] Bind no-arguments functor failed using std::bind with -pedantic option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49058
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-19
10:47:15 UTC ---
Jason, this works without -pedantic but fails with:
templatetypename T T val();
struct F1
{
void operator()();
};
templatetypename... T struct tuple { };
templatetypename T, typename... V
T
call(T t, tupleV...)
{ return t; }
templatetypename F, typename... T
struct Bind
{
templatetypename... A, typename R
= decltype( valF()( call(valT(), tupleA...())... ) )
R f(A...);
templatetypename... A, typename R
= decltype( valconst F()( call(valT(), tupleA...())... ) )
R f(A...) const;
};
int main()
{
BindF1().f();
}
Is this code relying on a G++ extension?
The parameter pack T has zero elements so the expansion:
call(valT(), tupleA...())... )
expands to nothing, and in -pedantic mode that seems to prevent the parameter
pack A from participating in type deduction, so SFINAE doesn't remove the
overload.
[Bug testsuite/48251] guality_check hangs indefinitely on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48251 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 11:28:25 UTC --- If you can't attach to a running process, that sounds like either a gdb bug, or kernel bug, certainly not a gcc fault.
[Bug libstdc++/49060] use of deleted memory in __gnu_cxx::hashtable::erase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49060 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-19 12:04:27 UTC --- Personally I consider this legacy code essentially frozen, and don't mean to spend time on it barring serious regressions. If Ian can review the patch and approve it, I don't object, though.
[Bug c/49061] New: wrong code with ARM NEON intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49061
Summary: wrong code with ARM NEON intrinsics
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hu...@free.fr
The code below generates wrong results when compiled with optimizations
enabled:
#include stdio.h
#include string.h
#include arm_neon.h
static void vvalidate(float *f) {
float32x4_t a0 = { 0, 1, 2, 3};
float32x4_t a1 = { 4, 5, 6, 7};
float32x4_t a2 = { 8, 9, 10, 11};
float32x4x2_t t0 = vzipq_f32(a1, a2);
t0 = vzipq_f32(a0, a2);
memcpy(f, t0.val[0], 8*sizeof(float));
}
int main() {
float f[8];
vvalidate(f);
printf(interleaved([0 1 2 3], [8 9 10 11])=%g %g %g %g %g %g %g %g\n, f[0],
f[1], f[2], f[3], f[4], f[5], f[6], f[7]);
if (f[4] != 2) printf(BGGG -- should be 0 8 1 9 2 10 3 11\n);
return 0;
}
# gcc-4.6.0 -mfloat-abi=softfp -mfpu=neon -O0 ./neon_bug.c ./a.out
interleaved([0 1 2 3], [8 9 10 11])=0 8 1 9 2 10 3 11
# gcc-4.6.0 -mfloat-abi=softfp -mfpu=neon -O1 ./neon_bug.c ./a.out
interleaved([0 1 2 3], [8 9 10 11])=0 8 1 9 6 10 7 11
BGGG -- should be 0 8 1 9 2 10 3 11
The bug also happens with the gcc-4.5 (Ubuntu/Linaro 4.5.2-8ubuntu4) and
gcc-4.4 (Ubuntu/Linaro 4.4.5-15ubuntu1) that ship with ubuntu 11.04.
[Bug middle-end/49062] New: [4.7 regression] Many C++ tests ICE on Tru64 UNIX: non-DECL_ONE_ONLY node in a same_comdat_group list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49062 Summary: [4.7 regression] Many C++ tests ICE on Tru64 UNIX: non-DECL_ONE_ONLY node in a same_comdat_group list Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: hubi...@gcc.gnu.org Host: alpha-dec-osf5.1b Target: alpha-dec-osf5.1b Build: alpha-dec-osf5.1b Between 20110502 and 20110518, many C++ tests stated to ICE on Tru64 UNIX (Alpha/ECOFF without COMDAT support), e.g. FAIL: g++.dg/torture/covariant-1.C -O0 (internal compiler error) FAIL: g++.dg/torture/covariant-1.C -O0 (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/torture/covariant-1.C:33:1: error: non-DECL_ONE_ONLY node in a same_comdat_group list AB* AB::_ZTchn8_h8_N2AB7getThisEv()/4 @166940 (asm: _ZTchn8_h8_N2AB7getThisEv) (same comdat group as AB* AB::_ZTch0_h8_N2AB7getThisEv()/3) availability:available analyzed needed address_taken externally_visible finalized asm_written thunk of AB* AB::_ZTch0_h8_N2AB7getThisEv() (asm: _ZTch0_h8_N2AB7getThisEv) fixed offset -8 virtual value 0 has virtual offset 0) called by: calls: AB* AB::_ZTch0_h8_N2AB7getThisEv()/3 (1.00 per call) References: Refering this function: var:int (* AB::_ZTV2AB [6])(...) (addr) /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/torture/covariant-1.C:33:1: internal compiler error: verify_cgraph_node failed This is almost certainly due to this patch: 2011-05-06 Jan Hubicka j...@suse.cz * cgraph.c (cgraph_add_thunk): Create real function node instead of alias node; finalize it and mark needed/reachale; arrange visibility to be right and add it into the corresponding same comdat group list. (dump_cgraph_node): Dump thunks. Please fix. Rainer
[Bug libstdc++/49060] use of deleted memory in __gnu_cxx::hashtable::erase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49060 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.19 12:03:35 Ever Confirmed|0 |1
[Bug middle-end/49062] [4.7 regression] Many C++ tests ICE on Tru64 UNIX: non-DECL_ONE_ONLY node in a same_comdat_group list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49062 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug libstdc++/49060] use of deleted memory in __gnu_cxx::hashtable::erase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49060 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||iant at google dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-05-19 12:15:10 UTC --- CC-ing Ian.
[Bug target/48903] sol2.c:solaris_output_init_fini: implicit declaration of function ‘print_operand’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48903 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-05/msg00381.htm ||l CC||ro at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-05-19 12:20:16 UTC --- Should be fixed by the above patch.
[Bug tree-optimization/49006] [4.6/4.7 Regression] Missed vectorization due to revision 167531
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49006 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #4 from Ira Rosen irar at il dot ibm.com 2011-05-19 12:33:49 UTC --- (In reply to comment #0) The problem is you don't see: induct_v4.f90:1766: note: LOOP VECTORIZED. induct_v4.f90:2177: note: LOOP VECTORIZED. anymore, right? With -Ofast there are no such loops, 1766 and 2177, they are probably being unrolled. I see these loops with -O2 -ftree-vectorize, and they are indeed not vectorized, but they are not vectorized by previous version as well, AFAIU. Ira
[Bug tree-optimization/49038] [4.5/4.6/4.7 Regression] -ftree-vectorise introduces reads past end of array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49038 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-05-19 12:38:32 UTC --- Is there a way for the vectorizer to check this? If not, we should probably create a scalar epilogue for last access with gap. Thanks, Ira
[Bug target/48949] [4.6/4.7 Regression] gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48949 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.05.19 12:37:15 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 Severity|critical|normal --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 12:37:15 UTC --- Can you see if fixincluded complex.h is used, or for some reason the system one instead? If the former, can you diff up the system one and the fixincluded one? You can run gcc -E foo.c | grep complex.h to see which complex.h is being used.
[Bug target/44618] [4.4/4.5/4.6/4.7 regression] wrong code with -frename-registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 12:42:02 UTC --- Edmar, have you posted your alternative patch to gcc-patches? That's where patch review is done, not in bugzilla.
[Bug testsuite/48251] guality_check hangs indefinitely on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48251 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-05-19 12:16:25 UTC --- --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 11:28:25 UTC --- If you can't attach to a running process, that sounds like either a gdb bug, or kernel bug, certainly not a gcc fault. I'd bet it's a gdb bug, but I'd still keep the gcc testsuite bug open as a reminder. Rainer
[Bug tree-optimization/48822] [4.5 Regression] G++ gets stucks and never finishes compilation when enabling -O2/3 optimization options.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48822 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||arthur.j.odwyer at gmail ||dot com --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 12:51:25 UTC --- *** Bug 48921 has been marked as a duplicate of this bug. ***
[Bug c/49061] wrong code with ARM NEON intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49061 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #1 from Ira Rosen irar at il dot ibm.com 2011-05-19 12:35:35 UTC --- This is probably related to pr 48252.
[Bug tree-optimization/48921] Value numbering takes infinite time on nested infinite loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48921 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||DUPLICATE --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 12:51:25 UTC --- Closing as DUP then. *** This bug has been marked as a duplicate of bug 48822 ***
[Bug libfortran/48906] Wrong rounding results with -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48906 --- Comment #7 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-19 12:58:34 UTC --- It was the last case I was having trouble with. I also was getting different results from different compilers, so I needed to confirm independently. I have this part working now. Still have some bugs here.
[Bug tree-optimization/49038] [4.5/4.6/4.7 Regression] -ftree-vectorise introduces reads past end of array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49038 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de 2011-05-19 13:05:42 UTC --- On Thu, 19 May 2011, irar at il dot ibm.com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49038 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||irar at il dot ibm.com --- Comment #2 from Ira Rosen irar at il dot ibm.com 2011-05-19 12:38:32 UTC --- Is there a way for the vectorizer to check this? No. If not, we should probably create a scalar epilogue for last access with gap. Probably yes. Richard.
[Bug middle-end/49063] [4.7 Regression] FAIL: gcc.dg/builtin-object-size-11.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49063 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-19 13:07:53 UTC --- Author: rguenth Date: Thu May 19 13:07:50 2011 New Revision: 173906 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173906 Log: 2011-05-19 Richard Guenther rguent...@suse.de PR testsuite/49063 * gcc.dg/builtin-object-size-11.c: Use -std=gnu89. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/builtin-object-size-11.c
[Bug c++/49043] [OpenMP C++0x]: Compiler error when lambda-function within OpenMP loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49043 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 13:12:02 UTC --- Author: jakub Date: Thu May 19 13:11:56 2011 New Revision: 173907 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173907 Log: PR c++/49043 * decl.c (check_omp_return): Stop searching on sk_function_parms. * testsuite/libgomp.c++/pr49043.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/pr49043.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/libgomp/ChangeLog
[Bug middle-end/49063] New: [4.7 Regression] FAIL: gcc.dg/builtin-object-size-11.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49063 Summary: [4.7 Regression] FAIL: gcc.dg/builtin-object-size-11.c Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: rgue...@gcc.gnu.org On Linux/x86, revision 173901 gave FAIL: gcc.dg/builtin-object-size-11.c (test for excess errors)
[Bug middle-end/49063] [4.7 Regression] FAIL: gcc.dg/builtin-object-size-11.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49063 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Blocks||48985 Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-05-19 13:08:18 UTC --- Fixed.
[Bug c++/49043] [OpenMP C++0x]: Compiler error when lambda-function within OpenMP loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49043 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 13:39:33 UTC --- Fixed.
[Bug c++/49043] [OpenMP C++0x]: Compiler error when lambda-function within OpenMP loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49043 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 13:14:00 UTC --- Author: jakub Date: Thu May 19 13:13:57 2011 New Revision: 173908 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173908 Log: PR c++/49043 * decl.c (check_omp_return): Stop searching on sk_function_parms. * testsuite/libgomp.c++/pr49043.C: New test. Added: branches/gcc-4_6-branch/libgomp/testsuite/libgomp.c++/pr49043.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/decl.c branches/gcc-4_6-branch/libgomp/ChangeLog
[Bug tree-optimization/49064] New: [x86/x64]: broken alias analysis leads vectorizer to emit poor code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49064
Summary: [x86/x64]: broken alias analysis leads vectorizer to
emit poor code
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: piotr.wyder...@gmail.com
On an x86 capable of SSE2 or x64 (which has SSE2 by definition) GCC tries
to vectorize as much integer code as possible, but ends up witch code much
worse than without vectorization. The SSE2-based version unnecessarily
recomputes all the m_Data pointers, as demonstrated by the following C++
snippet. I guess the reason is unsophisticated alias analysis, but the
actual reason may in fact be different.
struct X {
__m128i*m_Data;
std::size_t m_Len;
void xor_all(const X v1, const X v2);
void xor_all2(const X v1, const X v2);
};
void X::xor_all(const X v1, const X v2) {
for(std::size_t i = 0; i != m_Len; ++i) {
m_Data[i] = v1.m_Data[i] ^ v2.m_Data[i];
}
}
void X::xor_all2(const X v1, const X v2) {
__m128i* p0 = m_Data;
__m128i* p1 = v1.m_Data;
__m128i* p2 = v2.m_Data;
for(std::size_t i = 0; i != m_Len; ++i) {
p0[i] = p1[i] ^ p2[i];
}
}
As can be seen, xor_all2 produces nice code and xor_all doesn't:
00447c70 _ZN1X7xor_allERKS_S1_:
447c70:48 83 7f 08 00 cmpq $0x0,0x8(%rdi)
447c75:74 35je 447cac
_ZN1X7xor_allERKS_S1_+0x3c
447c77:31 c0xor%eax,%eax
447c79:0f 1f 80 00 00 00 00 nopl 0x0(%rax)
447c80:4c 8b 12 mov(%rdx),%r10
447c83:48 89 c1 mov%rax,%rcx
447c86:48 83 c0 01 add$0x1,%rax
447c8a:4c 8b 0e mov(%rsi),%r9
447c8d:48 c1 e1 04 shl$0x4,%rcx
447c91:4c 8b 07 mov(%rdi),%r8
447c94:66 41 0f 6f 04 0amovdqa (%r10,%rcx,1),%xmm0
447c9a:66 41 0f ef 04 09pxor (%r9,%rcx,1),%xmm0
447ca0:66 41 0f 7f 04 08movdqa %xmm0,(%r8,%rcx,1)
447ca6:48 39 47 08 cmp%rax,0x8(%rdi)
447caa:75 d4jne447c80
_ZN1X7xor_allERKS_S1_+0x10
447cac:f3 c3repz retq
00447cb0 _ZN1X8xor_all2ERKS_S1_:
447cb0:48 83 7f 08 00 cmpq $0x0,0x8(%rdi)
447cb5:48 8b 0f mov(%rdi),%rcx
447cb8:48 8b 36 mov(%rsi),%rsi
447cbb:4c 8b 02 mov(%rdx),%r8
447cbe:74 26je 447ce6
_ZN1X8xor_all2ERKS_S1_+0x36
447cc0:31 c0xor%eax,%eax
447cc2:31 d2xor%edx,%edx
447cc4:0f 1f 40 00 nopl 0x0(%rax)
447cc8:66 41 0f 6f 04 00movdqa (%r8,%rax,1),%xmm0
447cce:48 83 c2 01 add$0x1,%rdx
447cd2:66 0f ef 04 06 pxor (%rsi,%rax,1),%xmm0
447cd7:66 0f 7f 04 01 movdqa %xmm0,(%rcx,%rax,1)
447cdc:48 83 c0 10 add$0x10,%rax
447ce0:48 39 57 08 cmp%rdx,0x8(%rdi)
447ce4:75 e2jne447cc8
_ZN1X8xor_all2ERKS_S1_+0x18
447ce6:f3 c3repz retq
[Bug tree-optimization/49064] [x86/x64]: broken alias analysis leads vectorizer to emit poor code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49064 --- Comment #1 from Piotr Wyderski piotr.wyderski at gmail dot com 2011-05-19 14:27:28 UTC --- This is caused by the following definition in emmintrin.h: /* The Intel API is flexible enough that we must allow aliasing with other vector types, and their scalar components. */ typedef long long __m128i __attribute__ ((__vector_size__ (16), __may_alias__)); Without __may_alias__ the generated assembly code is OK. It's wrong to blindly assume a type aliases everything; proper analysis should be performed. Because the headers are indended to provide seamless integration with MSVC and ICC vectorized code, it's a good practice to use SSE that way. Most bona fide users will step into that trap assuming GCC produces comparably good code, which in this case it obviously doesn't, as can be seen above.
[Bug target/40483] gcc 4.x needs to utilize better COMDAT mechanism under Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40483 --- Comment #4 from Rainer Orth ro at gcc dot gnu.org 2011-05-19 14:29:11 UTC --- Author: ro Date: Thu May 19 14:29:05 2011 New Revision: 173913 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173913 Log: PR target/40483 * configure.ac (gcc_cv_as_comdat_group_group): Check for Sun as COMDAT group syntax, both SPARC and x86 variants. (HAVE_COMDAT_GROUP): Also define if gcc_cv_as_comdat_group_group. * configure: Regenerate. * config/sol2.h (TARGET_SOLARIS): Define. (PUSHSECTION_FORMAT): Remove. (SECTION_NAME_FORMAT): Define. * config/sol2.c: Include hashtab.h. (solaris_output_init_fini): Replace PUSHSECTION_FORMAT by its expansion, using SECTION_NAME_FORMAT. (solaris_comdat_htab): New variable. (struct comdat_entry): Define. (comdat_hash): New function. (comdat_eq): New function. (solaris_elf_asm_comdat_section): New function. (solaris_define_comdat_signature): New function. (solaris_code_end): New function. * config/sol2-protos.h (solaris_elf_asm_comdat_section): Declare. (solaris_code_end): Declare. * config/t-sol2 (sol2.o): Add $HASHTAB_H dependency. * config/i386/i386.c (ix86_code_end) [TARGET_SOLARIS]: Call solaris_code_end. (i386_solaris_elf_named_section): Wrap in TARGET_SOLARIS. Remove ATTRIBUTE_UNUSED. [!USE_GAS]: Call solaris_elf_asm_comdat_section for SECTION_LINKONCE sections if HAVE_COMDAT_GROUP. * config/sparc/sparc.c (sparc_solaris_elf_asm_named_section): Likewise. * config/i386/sol2-10.h (TARGET_ASM_NAMED_SECTION): Moved ... * config/i386/sol2.h (TARGET_ASM_NAMED_SECTION): ... here. * config/sparc/sol2.h (TARGET_ASM_CODE_END): Redefine. (PUSHSECTION_FORMAT): Remove. (SECTION_NAME_FORMAT): Redefine. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sol2-10.h trunk/gcc/config/i386/sol2.h trunk/gcc/config/sol2-protos.h trunk/gcc/config/sol2.c trunk/gcc/config/sol2.h trunk/gcc/config/sparc/sol2.h trunk/gcc/config/sparc/sparc.c trunk/gcc/configure trunk/gcc/configure.ac
[Bug c/49065] New: Write of non-aligned volatile float generates extra read instructions on PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49065
Summary: Write of non-aligned volatile float generates extra
read instructions on PowerPC
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kulpin...@gmail.com
On the PowerPC, a write to a non-aligned float within a packed data structure
results in each byte being read before being written if the object is declared
volatile. This can cause unexpected behavior with hardware. The bug exists in
recent 4.x gcc versions as well.
$ powerpc-eabi-gcc -v -save-temps -S -O2 gcc_bug.c
Reading specs from /opt/crossgcc/004DBN01/lib/gcc/powerpc-eabi/3.4.4/specs
Configured with: /opt/crossgcc/004DBN01/src/gcc-3.4.4/configure
--target=powerpc-eabi --prefix=/opt/crossgcc/004DBN01 --with-gnu-as
--with-gnu-ld --with-newlib --disable-multilib
Thread model: single
gcc version 3.4.4
/opt/crossgcc/004DBN01/libexec/gcc/powerpc-eabi/3.4.4/cc1 -E -quiet -v
gcc_bug.c -O2 -o gcc_bug.i
ignoring nonexistent directory
/opt/crossgcc/004DBN01/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/sys-include
#include ... search starts here:
#include ... search starts here:
/opt/crossgcc/004DBN01/lib/gcc/powerpc-eabi/3.4.4/include
/opt/crossgcc/004DBN01/lib/gcc/powerpc-eabi/3.4.4/../../../../powerpc-eabi/include
End of search list.
/opt/crossgcc/004DBN01/libexec/gcc/powerpc-eabi/3.4.4/cc1 -fpreprocessed
gcc_bug.i -quiet -dumpbase gcc_bug.c -auxbase gcc_bug -O2 -version -o gcc_bug.s
GNU C version 3.4.4 (powerpc-eabi)
compiled by GNU C version 4.1.2 20071124 (Red Hat 4.1.2-42).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
$
$ cat gcc_bug.i
# 1 gcc_bug.c
# 1 built-in
# 1 command line
# 1 gcc_bug.c
struct msg {
short header;
float data;
} __attribute__((packed));
void nonvolatile_good(struct msg *p) {
p-data = 0.0;
}
void volatile_bad(volatile struct msg *p) {
p-data = 0.0;
}
$
$ cat gcc_bug.s
.file gcc_bug.c
.section.text
.align 2
.globl nonvolatile_good
.type nonvolatile_good, @function
nonvolatile_good:
li 0,0
stb 0,5(3)
stb 0,2(3)
stb 0,3(3)
stb 0,4(3)
blr
.size nonvolatile_good, .-nonvolatile_good
.align 2
.globl volatile_bad
.type volatile_bad, @function
volatile_bad:
li 0,0
lbz 9,2(3)--- troublesome load
stb 0,2(3)
lbz 9,3(3)--- troublesome load
stb 0,3(3)
lbz 9,4(3)--- troublesome load
stb 0,4(3)
lbz 9,5(3)--- troublesome load
stb 0,5(3)
blr
.size volatile_bad, .-volatile_bad
.ident GCC: (GNU) 3.4.4
[Bug target/40483] gcc 4.x needs to utilize better COMDAT mechanism under Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40483 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2010-06/msg00600.htm |atches/2011-05/msg01384.htm |l |l Target Milestone|--- |4.7.0 --- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2011-05-19 15:10:26 UTC --- Fixed for 4.7.0.
[Bug lto/49059] Linking with -flto fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49059 Petr petr.malik at hotmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | --- Comment #3 from Petr petr.malik at hotmail dot com 2011-05-19 15:04:03 UTC --- (In reply to comment #2) If you do not add --enable-checking the error will vanish. The check is for optimality of partitioning and asserts that no partition is empty. *** This bug has been marked as a duplicate of bug 48246 *** I removed the '--enable-checking' switch and reconfigured GCC 4.6.0, then compiled my app with this 'new' version, but with the same success as before...
[Bug c++/49058] [C++0x] Bind no-arguments functor failed using std::bind with -pedantic option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49058
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011.05.19 15:43:41
AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-05-19
15:43:41 UTC ---
This has nothing to do with variadics; the same error occurs with
templatetypename T T val();
struct F1
{
void operator()();
};
templatetypename F
struct Bind
{
templatetypename R
= decltype( valF()( ) )
R f();
templatetypename R
= decltype( valconst F()( ) )
R f() const;
};
int main()
{
BindF1().f();
}
The problem is that F1::operator() is non-const, so when we instantiate
BindF1, valconst F() is ill-formed. And this error is not dependent on
EDG also rejects this testcase. The bug is that we silently accept it without
-pedantic; we should be giving a pedwarn.
[Bug c++/49066] New: [C++0x] Non-defining declaration of deleted function suppresses usage validation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49066
Summary: [C++0x] Non-defining declaration of deleted function
suppresses usage validation
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
gcc 4.7.0 20110514 (experimental) in C++0x mode compiles the following program
successfully (but produces a link error):
//--
void foo() = delete;
void foo();
int main() { foo(); }
//--
It seems that the second (non-defining) declaration of the deleted function
foo() has the effect of undeleting the initial deleted definition. I cannot
deduce this kind of semantics from the FDIS wording: The program should be
rejected, when compiled [In a strict sense the compiler probably behaves
conforming, because in the end the program *is* ill-formed, but to me it looks
like a generally expected behaviour, that this should done by the compiler, not
by the linker. I'm hesitating to categorize this as an enhancement request and
therefore I did not so].
[Bug target/44618] [4.4/4.5/4.6/4.7 regression] wrong code with -frename-registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44618 --- Comment #21 from Edmar Wienskoski edmar at freescale dot com 2011-05-19 15:52:02 UTC --- (In reply to comment #20) Edmar, have you posted your alternative patch to gcc-patches? That's where patch review is done, not in bugzilla. I don't remember, I am posting it today just in case I missed. Thanks Edmar
[Bug c++/49051] [C++0x] Doesn't SFINAE away an invalid substitution into toplevel parameter type T[N]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49051 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-05-19 16:05:05 UTC --- I disagree. The transformation of array to pointer is done immediately at declaration time (8.3.5/6), so there is no substitution into an array type. In resolving issue 1001, core agreed that the transformations in 8.3.5/6 are done at template definition time, not deferred until the instantiation. http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#1001 http://wiki.dinkumware.com/twiki/bin/view/Wg21batavia/CoreWorkingGroup#Core_issue_1001_Parameter_type_a
[Bug c++/49058] [C++0x] Bind no-arguments functor failed using std::bind with -pedantic option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49058 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-05-19 16:09:05 UTC --- Created attachment 24291 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24291 Fix Here's a fix, which breaks bind, so I'm not going to check it in yet. Is there already a libstdc++ bug for this issue that I can mark as blocking this one?
[Bug libstdc++/49058] [C++0x] Bind no-arguments functor failed using std::bind with -pedantic option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49058 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-05-19 16:10:58 UTC --- ...and adding Jonathan to CC. See my earlier comments: a compiler bug was masking a library bug.
[Bug libstdc++/49058] [C++0x] Bind no-arguments functor failed using std::bind with -pedantic option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49058 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Component|c++ |libstdc++ AssignedTo|jason at gcc dot gnu.org|unassigned at gcc dot ||gnu.org --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-05-19 16:09:59 UTC --- Actually I'll just unassign myself and change the category.
[Bug c++/49051] [C++0x] Doesn't SFINAE away an invalid substitution into toplevel parameter type T[N]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49051 --- Comment #2 from Johannes Schaub schaub.johannes at googlemail dot com 2011-05-19 16:26:30 UTC --- (In reply to comment #1) I disagree. The transformation of array to pointer is done immediately at declaration time (8.3.5/6), so there is no substitution into an array type. In resolving issue 1001, core agreed that the transformations in 8.3.5/6 are done at template definition time, not deferred until the instantiation. http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#1001 http://wiki.dinkumware.com/twiki/bin/view/Wg21batavia/CoreWorkingGroup#Core_issue_1001_Parameter_type_a jason, the transformation is immediately done at declaration time. I agree: That's why these two are equivalent: templatetypename T void f(T[1]); templatetypename T void f(T*); For equivalence, both shall have identical parameter-type-lists, which these have. But before argument deduction, explicit template arguments are substituted, and those explicit arguments are substituted into the *unadjusted* parameter type. See 14.8.2p3 (FDIS): After this substitution is performed, the function parameter type adjustments described in 8.3.5 are performed. The note that contains a list of substitution failures also has an example like that at 14.8.2p8: template class T int f(T[5]); int I = fint(0); int j = fvoid(0); // invalid array
[Bug rtl-optimization/49014] [4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7132 with even more insane set of flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49014 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added CC||ubizjak at gmail dot com --- Comment #3 from Andrey Belevantsev abel at gcc dot gnu.org 2011-05-19 16:43:04 UTC --- We again hit an insn with the nothing reservation. This time it is the compare from *cmpfp_iu_sse. It does set the decode attribute to vector correctly but sets type to ssecomi, and in the athlon.md the athlon_ssecomi reservation compares against ssecmp, not ssecomi. I see the following comment there: ;; It seems athlon_ssecomi has a bug in the attr_type, fixed for amdfam10 Changing the type to ssecomi (like below, as in atom.md) fixes this. Uros, does this look right to you? The other ssecomi* reservations also have the ssecomi type. If yes, then I will add the assert to the scheduler which will fire immediately upon detecting this, it will be simple. diff --git a/gcc/config/i386/athlon.md b/gcc/config/i386/athlon.md index 341adf4..2896a15 100644 --- a/gcc/config/i386/athlon.md +++ b/gcc/config/i386/athlon.md @@ -798,7 +798,7 @@ athlon-direct,athlon-fploadk8,athlon-fadd) (define_insn_reservation athlon_ssecomi 4 (and (eq_attr cpu athlon,k8,generic64) - (eq_attr type ssecmp)) + (eq_attr type ssecomi)) athlon-vector,athlon-fpsched,athlon-fadd) (define_insn_reservation athlon_ssecomi_amdfam10 3 (and (eq_attr cpu amdfam10)
[Bug libstdc++/49058] [C++0x] Bind no-arguments functor failed using std::bind with -pedantic option.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49058 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-05-19 16:52:35 UTC --- thanks, I'll deal with the lib bug
[Bug c++/49051] [C++0x] Doesn't SFINAE away an invalid substitution into toplevel parameter type T[N]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49051 --- Comment #3 from Johannes Schaub schaub.johannes at googlemail dot com 2011-05-19 16:56:07 UTC --- (In reply to comment #2) (In reply to comment #1) I disagree. The transformation of array to pointer is done immediately at declaration time (8.3.5/6), so there is no substitution into an array type. In resolving issue 1001, core agreed that the transformations in 8.3.5/6 are done at template definition time, not deferred until the instantiation. http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_closed.html#1001 http://wiki.dinkumware.com/twiki/bin/view/Wg21batavia/CoreWorkingGroup#Core_issue_1001_Parameter_type_a jason, the transformation is immediately done at declaration time. I agree: That's why these two are equivalent: templatetypename T void f(T[1]); templatetypename T void f(T*); For equivalence, both shall have identical parameter-type-lists, which these have. But before argument deduction, explicit template arguments are substituted, and those explicit arguments are substituted into the *unadjusted* parameter type. See 14.8.2p3 (FDIS): After this substitution is performed, the function parameter type adjustments described in 8.3.5 are performed. The note that contains a list of substitution failures also has an example like that at 14.8.2p8: template class T int f(T[5]); int I = fint(0); int j = fvoid(0); // invalid array Ah I see now: The substitution for explicit arguments uses the *function type*, not the parameter types (according to p6). So in the example above, it uses T* and becomes void*. It doesn't use T[5]. p3 only applies when the dependent type was adjusted and substitution made it a non-adjusted type. So on a second read of this, I agree to you. The note at 14.8.2p8 and the example of p3 were confusing me, both tricking me into thinking that for substitution, the parameter types themselves somehow would be used.
[Bug libstdc++/49048] setprecision rounding fails in some cases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49048 --- Comment #8 from Cecilio s.cecilio at gmail dot com 2011-05-19 17:01:15 UTC --- Thanks again, Paolo and Jackub, for your help and explanations. Believe it or not, I a have a PhD and had to learn a lot of complex mathematics, but I never heard about so many types of 'rounding' methods. To me, rounding had always meant round-half-up (banker's rounding): 5.5 rounds up to 6 and 6.5 rounds up to 7. As this is also the normally required method for financial calculations, I can not understand the usefulness of printf sometimes rounding up and others rounding down, as it is the behaviour of round-half-even method. But once I've learn that (thanks for this) I know that I can no longer rely on setprecision or printf, and that I have to implement my rounding methods to get the banker's rounding behaviour. I'm wondering how many financial programs are there relying on setprecision without having noticed its 'problematic' rounding behaviour, caused by printf and blessed by ISO c++ standard. ;-) It's been a pleasure taking to both and learning with your help. With my best regards, Cecilio
[Bug debug/49032] -gstabs generates reference to deleted static variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49032 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-05-19 17:07:35 UTC --- Created attachment 24293 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24293 gcc47-pr49032.patch Untested fix. Works on this testcase, as well as when s is actually forced to be output (e.g. through inline asm). I'm not a stabs user (are there any left anyway?), so don't know whether it doesn't decrease debug info quality (if we can speak about debug info quality in stabs case), but from I understand at least the global_decl debug hooks are called at least by C/C++ FEs after cgraph_finalize_compilation_unit has been called and thus IMHO the patch should only change anything when the vars aren't output. Guess one could put there instead gcc_unreachable (); instead of return NULL; and see how often it triggers during -gstabs bootstrap.
[Bug c/49067] New: Internal Compiler Error with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49067 Summary: Internal Compiler Error with -O3 Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: asal...@snet.net Created attachment 24292 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24292 Pre=processed .i file GCC aborts with internal compiler error when optimization is set to -O3. Setting optimization to -O2 prevents the problem. Pre-processed .i file attached. System type: Ubuntu 11.04 Entire command line (via Makefile) that triggers the error: cd /home/fcf/blender-svn/cmake/source/blender/editors/space_view3d /usr/bin/gcc -D__SSE__ -D__MMX__ -D__SSE2__ -DWITH_GAMEENGINE -DGLEW_STATIC -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -fopenmp -msse2 -msse -pipe -fPIC -funsigned-char -fno-strict-aliasing -Wall -Wcast-align -Werror=declaration-after-statement -Werror=implicit-function-declaration -Werror=return-type -Wstrict-prototypes -Wno-char-subscripts -Wno-unknown-pragmas -Wpointer-arith -Wunused-parameter -Wwrite-strings -O3 -DNDEBUG -DNDEBUG -I/home/fcf/blender-svn/blender/source/blender/editors/include -I/home/fcf/blender-svn/blender/source/blender/blenfont -I/home/fcf/blender-svn/blender/source/blender/blenkernel -I/home/fcf/blender-svn/blender/source/blender/blenloader -I/home/fcf/blender-svn/blender/source/blender/blenlib -I/home/fcf/blender-svn/blender/source/blender/gpu -I/home/fcf/blender-svn/blender/source/blender/imbuf -I/home/fcf/blender-svn/blender/source/blender/makesdna -I/home/fcf/blender-svn/blender/source/blender/makesrna -I/home/fcf/blender-svn/blender/source/blender/windowmanager -I/home/fcf/blender-svn/blender/source/blender/render/extern/include -I/home/fcf/blender-svn/blender/intern/guardedalloc -I/home/fcf/blender-svn/blender/intern/smoke/extern -I/home/fcf/blender-svn/blender/extern/glew/include -I/home/fcf/blender-svn/blender/source/gameengine/BlenderRoutines -save-temps -o CMakeFiles/bf_editor_space_view3d.dir/view3d_select.c.o -c /home/fcf/blender-svn/blender/source/blender/editors/space_view3d/view3d_select.c Output of gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --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 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
[Bug c++/49051] [C++0x] Doesn't SFINAE away an invalid substitution into toplevel parameter type T[N]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49051 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|SUSPENDED Resolution|INVALID | --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-05-19 17:20:44 UTC --- Hmm, the example in 14.8.2p8 does seem to contradict my interpretation of the normative wording. I'll raise this with core.
[Bug c/49068] New: Failure to auto-cast in expression, results in broken code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49068 Summary: Failure to auto-cast in expression, results in broken code Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: thomas.ev...@nrl.navy.mil Subject: Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5666.3~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5666) (dot 3) = Predicate: the code: int gnome, jape[20]; char buff[888]; gnome = sscanf(buff, %d %d %d %d %d %d %d %d %d,jape+0, jape+1, jape+2, jape+3, jape+4, jape+5, jape+6, jape+7, jape+8); generates the following warning: warning: format '%d' expects type 'int *', but argument 6 has type 'int (*)[20]' also, the code does not work properly -- the values in jape[] are not the same as those in the buff[] array. The cause apears to be the expression jape+0 (or maybeso jape+5, but that makes much less sense from my naive perspective) being prematurely optimized by removal of the +0, which would otherwise force a quiet cast of jape from 'int (*)[20]' to 'int *'.
[Bug c/49068] Failure to auto-cast in expression, results in broken code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49068 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-05-19 18:17:17 UTC --- It does say which argument too: argument 6.
[Bug target/49069] New: ICE in gen_cstoredi4, at config/arm/arm.md:7554
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49069 Summary: ICE in gen_cstoredi4, at config/arm/arm.md:7554 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: rmansfi...@qnx.com Host: x86_64-linux-gnu Target: arm-unknown-linux-gnueabi Build: x86_64-linux-gnu Created attachment 24294 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24294 preprocessed source $ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: arm-unknown-linux-gnueabi Configured with: ../configure --target=arm-unknown-linux-gnueabi --prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi --with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root --disable-multilib --with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99 --enable-long-long --enable-target-optspace target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared --disable-libmudflap --disable-libssp Thread model: posix gcc version 4.7.0 20110519 (experimental) [trunk revision 173917] (GCC) $ ./xgcc -B. /home/ryan/ice.i -Os /home/ryan/ice.i: In function 'foo': /home/ryan/ice.i:23:11: internal compiler error: in gen_cstoredi4, at config/arm/arm.md:7554 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/49068] Failure to auto-cast in expression, results in broken code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49068 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-05-19 18:16:53 UTC --- jape+3 is the issue.
[Bug objc++/49070] New: ObjC++ compiler fails to compile ObjC method invocations without keyword arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49070
Summary: ObjC++ compiler fails to compile ObjC method
invocations without keyword arguments
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
The following testcase
/* Contributed by Nicola Pero nicola.p...@meta-innovation.com, May 2011. */
#include objc/objc.h
@interface A
- (id) method:(id)arg0 :(id)arg1;
@end
id function (A *x)
{
return [x method:x :x];
}
fails to compile as Objective-C++ with GCC 4.7.0:
[nicola@lampone ~]$ gcc test.mm -c
test.mm: In function ‘objc_object* function(A*)’:
test.mm:10:22: error: found ‘:’ in nested-name-specifier, expected ‘::’
test.mm:10:20: error: ‘x’ is not a class or namespace
test.mm:10:24: warning: ‘A’ may not respond to ‘-method:’ [enabled by default]
test.mm:10:24: warning: (Messages without a matching method signature [enabled
by default]
test.mm:10:24: warning: will be assumed to return ‘id’ and accept [enabled by
default]
test.mm:10:24: warning: ‘...’ as arguments.) [enabled by default]
[nicola@lampone ~]$
It compiles as Objective-C (ie, if you rename the file as test.m). It also
compiles with much older compilers, such as GCC 4.1.2.
This testcase was distilled from a bug reported by Banlu Kemiyatorn.
I'd consider this slightly higher priority than the usual Objective-C++
testcase because what is broken is actually part of the basic Objective-C
language syntax.
Thanks
[Bug objc++/49070] ObjC++ compiler fails to compile ObjC method invocations without keyword arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49070 Nicola Pero nicola at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.05.19 18:36:55 Ever Confirmed|0 |1 --- Comment #1 from Nicola Pero nicola at gcc dot gnu.org 2011-05-19 18:36:55 UTC --- Confirmed. The testcase fails to compile with gcc (GCC) 4.7.0 20110519 (experimental). Thanks
[Bug target/49071] New: Wrong code with -fschedule-insns (x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49071
Summary: Wrong code with -fschedule-insns (x86-64)
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com
Created attachment 24295
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24295
Output of gcc -O1 -fschedule-insns test.c -v with GCC 4.4.5
This bug reproduces all the way back to at least 4.4.5, and also reproduces
with trunk revision 173843 (2011-05-17). I'm on Ubuntu 10.10, x86-64.
cat test.c EOF
#include stdio.h
#pragma pack(1)
struct S0 {
int f0;
int f1;
unsigned f3 : 6;
int f4;
int f5;
unsigned f6 : 23;
unsigned f8 : 10;
};
static struct S0 g_12 = {0};
static struct S0 g_361 = {0,0,0,0,0,0,55};
static unsigned char g_547 = 1;
static int func_66() {
g_12.f8 |= 1;
return g_12.f6;
}
static struct S0 func_1(void) {
int p;
for (p = 2; p = 0; --p)
g_547 = 2;
g_361.f8 = func_66();
return (struct S0){0};
}
int main() {
func_1();
printf(, (unsigned)g_361.f6);
printf(%x\n, (unsigned)g_547);
return 0;
}
EOF
gcc -O1 test.c ; ./a.out // correctly prints 2
gcc -O2 test.c ; ./a.out // incorrectly prints 1
You can replace -O2 with -O1 -fschedule-insns and see the same wrong code
generated.
This test case is reduced from the output of Csmith 2.1.0 (git hash 01aa8b04,
https://github.com/Quuxplusone/csmith/), using the following command line:
csmith --paranoid --longlong --no-pointers --arrays --no-jumps --no-consts
--no-volatiles --checksum --divs --no-muls --bitfields --packed-struct -s
591872179
[Bug rtl-optimization/49014] [4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7132 with even more insane set of flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49014 --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2011-05-19 19:09:44 UTC --- (In reply to comment #3) Changing the type to ssecomi (like below, as in atom.md) fixes this. Uros, does this look right to you? The other ssecomi* reservations also have the ssecomi type. If yes, then I will add the assert to the scheduler which will fire immediately upon detecting this, it will be simple. diff --git a/gcc/config/i386/athlon.md b/gcc/config/i386/athlon.md index 341adf4..2896a15 100644 --- a/gcc/config/i386/athlon.md +++ b/gcc/config/i386/athlon.md @@ -798,7 +798,7 @@ athlon-direct,athlon-fploadk8,athlon-fadd) (define_insn_reservation athlon_ssecomi 4 (and (eq_attr cpu athlon,k8,generic64) - (eq_attr type ssecmp)) + (eq_attr type ssecomi)) athlon-vector,athlon-fpsched,athlon-fadd) (define_insn_reservation athlon_ssecomi_amdfam10 3 (and (eq_attr cpu amdfam10) This change looks correct to me, ssecmp type goes to ssecmp* reservations.
[Bug c++/49066] [C++0x] Non-defining declaration of deleted function suppresses usage validation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49066
--- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com
2011-05-19 19:06:15 UTC ---
I found another example that convinces me that the current behaviour is a real
bug and that this issue is not just an enhancement request. Consider this
example:
//---
void foo() = delete;
void foo();
templateclass = decltype(foo())
void bar(){}
int main() { bar(); }
//---
Without the second non-defining declaration of foo(), the program would be
clearly rejected, but with the second declaration it is accepted. This code
should be rejected independent of the existence of the second declaration of
foo().
[Bug target/49071] Wrong code with -fschedule-insns (x86-64)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49071 --- Comment #1 from John Regehr regehr at cs dot utah.edu 2011-05-19 19:27:34 UTC --- May be related to 48124
[Bug target/49061] wrong code with ARM NEON intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49061 --- Comment #2 from Julien Pommier hules at free dot fr 2011-05-19 19:30:49 UTC --- Thanks Ira, I guess you are right. Testing with the latest gcc 4.6.1 snapshot, the bug seems to be gone !
[Bug bootstrap/49072] New: Error building the compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49072 Summary: Error building the compiler Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: jose.pascual-guti...@1-act.com I downloaded from one of the mirror sites the following tar balls: gcc-4.6.0.tar.gz gmp-4.3.2.tar.bz2 mpc-0.8.1.tar.gz mpfr-2.4.2.tar.bz2 I decompressed and untarred the files, which resulted in four directories, respectively: gcc-4.6.0, gmp-4.3.2, mpc-0.8.1, and mpfr-2.4.2. I then created the directory ~/gcc4 and I moved gcc-4.6.0 in it. I then changed the names of the directories gmp-4.3.2, mpc-0.8.1, and mpfr-2.4.2 to gmp, mpc, and mpfr, respectively. These three directories, namely gmp, mpc, and mpfr were moved it to ~/gcc4/gcc-4.6.0. In gcc4, I created the directory objdir. So, the directory tree looks like the following: |--gcc4 | |--objdir | |--gcc-4.6.0 | | |--gmp | | |--mpc | | |--mpfr I then proceeded to configure the installation. From ~/gcc4/objdir, I executed “../gcc-4.6.0/configure”. Once the Makefile was created, still from within ~/gcc4/objdir, I executed “make bootstrap”. After about 24 hours of execution, the build failed with the following error message: ../../../gcc-4.6.0/libgcc/../gcc/libgcc2.c:791:1: internal compiler error: Floating point exception Please submit a full bug report, With preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructinos. make [3]: *** [_popcountsi2.o] Error 1 make [3]: Leaving directory ‘/home/Jose.Pascual-Gutierr/gcc4/objdir/i686-pc-cygwin/libgcc’ make [2]: *** [all-stage2-target-libgcc] Error 2 make [2]: Leaving directory ‘/home/Jose.Pascual-Gutierr/gcc4/objdir’ make [1]: *** [stage2-bubble] Error 2 make [1]: Leaving directory ‘/home/Jose.Pascual-Gutierr/gcc4/objdir’ make: *** [bootstrap] Error 2 All the help you can provide will be very appreciated. Thank you very much, José
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #49 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-19 20:53:36 UTC --- Author: burnus Date: Thu May 19 20:53:33 2011 New Revision: 173920 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=173920 Log: 2011-06-19 Tobias Burnus bur...@net-b.de PR fortran/18918 * trans-types.c (gfc_get_element_type): Handle scalar coarrays. (gfc_get_nodesc_array_type): Make a variant-type copy for scalar coarrays. * trans.c (gfc_build_array_ref): Return original type not * variant copy for scalar coarrays. * trans-array.c (gfc_conv_array_ref): Ditto. 2011-06-19 Tobias Burnus bur...@net-b.de PR fortran/18918 * gfortran.dg/coarray_21.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/coarray_21.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans.c trunk/gcc/testsuite/ChangeLog
