[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- I think lowering LDBL_MAX_EXP would be far worse than this. The double-double format is unusable for any real numerics in so many ways that this is just one small part of that, the variable precision from 106 to thousands of precision bits depending on exact value is far worse.
[Bug c/61399] LDBL_MAX is incorrect with IBM long double format / overflow issues near large values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399 --- Comment #3 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- The variable precision is unavoidable with this format (this is even a feature, despite the drawbacks). But the fact that the variable precision is problematic by itself isn't a reason not to try to solve other issues.
[Bug c++/61401] New: Wrong treatment of empty template-argument packs during deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61401
Bug ID: 61401
Summary: Wrong treatment of empty template-argument packs
during deduction
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alexey.kudinkin at gmail dot com
templatetypename, typename
struct X;
templatetypename T
struct XT, T(T)
{
typedef int type;
};
templatetypename T, typename ...Args
struct Y : XArgs..., T, T(T)
{
};
Yint::type x;
Compiling this snippet g++ (4.9.0) complains about wrong amount of template
arguments while shouldn't.
[Bug c++/61361] gcc segfaults on SLES12 beta4 P8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61361 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/61383] [4.8/4.9/4.10 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61383 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Jun 3 08:48:28 2014 New Revision: 211163 URL: http://gcc.gnu.org/viewcvs?rev=211163root=gccview=rev Log: 2014-06-03 Richard Biener rguent...@suse.de PR tree-optimization/61383 * tree-ssa-ifcombine.c (bb_no_side_effects_p): Make sure stmts can't trap. * gcc.dg/torture/pr61383-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61383-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ifcombine.c
[Bug rtl-optimization/60901] [4.8/4.9 Regression] ICE: SIGSEGV in add_to_deps_list with -fsel-sched-pipelining-outer-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901 --- Comment #9 from Andrey Belevantsev abel at gcc dot gnu.org --- Author: abel Date: Tue Jun 3 09:20:36 2014 New Revision: 211164 URL: http://gcc.gnu.org/viewcvs?rev=211164root=gccview=rev Log: Backport from mainline 2014-05-14 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/60901 * config/i386/i386.c (ix86_dependencies_evaluation_hook): Check that bb predecessor belongs to the same scheduling region. Adjust comment. * gcc.target/i386/pr60901.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr60901.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/i386.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/61401] Wrong treatment of empty template-argument packs during deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61401 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- The template Y can only be instantiated with an empty parameter pack, which makes it invalid. [temp.res] p8 says: If every valid specialization of a variadic template requires an empty template parameter pack, the template is ill-formed, no diagnostic required
[Bug rtl-optimization/60866] [4.7/4.8/4.9 Regression] ICE: in get_seqno_for_a_jump, at sel-sched-ir.c:4068 with -fselective-scheduling -fno-if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60866 --- Comment #7 from Andrey Belevantsev abel at gcc dot gnu.org --- Author: abel Date: Tue Jun 3 09:25:39 2014 New Revision: 211165 URL: http://gcc.gnu.org/viewcvs?rev=211165root=gccview=rev Log: Backport from mainline 2014-05-14 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/60866 * sel-sched-ir (sel_init_new_insn): New parameter old_seqno. Default it to -1. Pass it down to init_simplejump_data. (init_simplejump_data): New parameter old_seqno. Pass it down to get_seqno_for_a_jump. (get_seqno_for_a_jump): New parameter old_seqno. Use it for initializing new jump seqno as a last resort. Add comment. (sel_redirect_edge_and_branch): Save old seqno of the conditional jump and pass it down to sel_init_new_insn. (sel_redirect_edge_and_branch_force): Likewise. * gcc.dg/pr60866.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr60866.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/sel-sched-ir.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/61328] valgrind finds problem in find_bswap_or_nop_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61328 --- Comment #5 from thopre01 at gcc dot gnu.org --- Author: thopre01 Date: Tue Jun 3 09:29:06 2014 New Revision: 211166 URL: http://gcc.gnu.org/viewcvs?rev=211166root=gccview=rev Log: 2014-06-03 Thomas Preud'homme thomas.preudho...@arm.com PR tree-optimization/61328 * tree-ssa-math-opts.c (init_symbolic_number): Extract symbolic number initialization from find_bswap_or_nop_1. (find_bswap_or_nop_1): Test return value of find_bswap_or_nop_1 stored in source_expr2 before using the size value the function sets. Also make use of init_symbolic_number () in both the old place and find_bswap_or_nop_load () to avoid reading uninitialized memory when doing recursion in the GIMPLE_BINARY_RHS case. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Akim Demaille from comment #10) auto t = std::make_tuple(incr(), incr()); That's not an initializer-list, it's a function call, so the order of evaluation is not specified and that example is not relevant AFAICT.
[Bug c++/57543] decltype needs explicit 'this' pointer in member function declaration of template class with trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57543 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||yyc1992 at gmail dot com --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- *** Bug 61400 has been marked as a duplicate of this bug. ***
[Bug c++/61400] suffix return type doesn't work for template member functions with explict specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61400 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Yichao Yu from comment #1) 2. The function used in decltype have to be explicitly specialized using at least one of the template parameter from the other function. (i.e. there won't be any error if I replace `decltype(ai())` with `decltype(a0())` That has an explicit template argument list, that's not the same as explicitly specialized This was fixed a few days ago anyway. *** This bug has been marked as a duplicate of bug 57543 ***
[Bug rtl-optimization/60901] [4.8/4.9 Regression] ICE: SIGSEGV in add_to_deps_list with -fsel-sched-pipelining-outer-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901 --- Comment #10 from Andrey Belevantsev abel at gcc dot gnu.org --- Author: abel Date: Tue Jun 3 10:06:39 2014 New Revision: 211168 URL: http://gcc.gnu.org/viewcvs?rev=211168root=gccview=rev Log: Backport from mainline 2014-05-14 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/60901 * config/i386/i386.c (ix86_dependencies_evaluation_hook): Check that bb predecessor belongs to the same scheduling region. Adjust comment. * gcc.target/i386/pr60901.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr60901.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/60901] [4.8/4.9 Regression] ICE: SIGSEGV in add_to_deps_list with -fsel-sched-pipelining-outer-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Andrey Belevantsev abel at gcc dot gnu.org --- Fixed on branches.
[Bug ipa/61160] [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Tue Jun 3 10:09:20 2014 New Revision: 211170 URL: http://gcc.gnu.org/viewcvs?rev=211170root=gccview=rev Log: 2014-06-03 Martin Jambor mjam...@suse.cz PR ipa/61160 * ipa-cp.c (cgraph_edge_brings_value_p): Handle edges leading to thunks. testsuite/ * g++.dg/ipa/pr61160-1.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr61160-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/60866] [4.7/4.8/4.9 Regression] ICE: in get_seqno_for_a_jump, at sel-sched-ir.c:4068 with -fselective-scheduling -fno-if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60866 --- Comment #8 from Andrey Belevantsev abel at gcc dot gnu.org --- Author: abel Date: Tue Jun 3 10:08:58 2014 New Revision: 211169 URL: http://gcc.gnu.org/viewcvs?rev=211169root=gccview=rev Log: Backport from mainline 2014-05-14 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/60866 * sel-sched-ir (sel_init_new_insn): New parameter old_seqno. Default it to -1. Pass it down to init_simplejump_data. (init_simplejump_data): New parameter old_seqno. Pass it down to get_seqno_for_a_jump. (get_seqno_for_a_jump): New parameter old_seqno. Use it for initializing new jump seqno as a last resort. Add comment. (sel_redirect_edge_and_branch): Save old seqno of the conditional jump and pass it down to sel_init_new_insn. (sel_redirect_edge_and_branch_force): Likewise. * gcc.dg/pr60866.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr60866.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/sel-sched-ir.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/60866] [4.7/4.8/4.9 Regression] ICE: in get_seqno_for_a_jump, at sel-sched-ir.c:4068 with -fselective-scheduling -fno-if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60866 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Andrey Belevantsev abel at gcc dot gnu.org --- Also fixed on branches.
[Bug ipa/61160] [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Tue Jun 3 10:13:15 2014 New Revision: 211171 URL: http://gcc.gnu.org/viewcvs?rev=211171root=gccview=rev Log: 2014-06-03 Martin Jambor mjam...@suse.cz PR ipa/61160 * ipa-cp.c (cgraph_edge_brings_value_p): Handle edges leading to thunks. testsuite/ * g++.dg/ipa/pr61160-1.C: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr61160-1.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ipa-cp.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug ipa/61160] [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160 --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org --- The first patch has been approved and committed, the second one (https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02660.html) is still pending approval.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #10 from Thomas Preud'homme thomas.preudhomme at arm dot com --- So I am testing the patch right now and should be able to send it tomorrow. However, the code already shall already mark the load with the actual alignment the access is being done with. Therefore it seems to me that something in the backend fails to split the unaligned load into several aligned load. Could you break after the line align = get_object_alignment (src); in tree-ssa-math-opts.c when compiling gcc/java/jcf-parse.c in stage 1 (I suppose it breaks in stage 2)? What does print align gives? What about print load_type-type_common.align ? Best regards.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org --- So I am testing the patch right now and should be able to send it tomorrow. However, the code already shall already mark the load with the actual alignment the access is being done with. Therefore it seems to me that something in the backend fails to split the unaligned load into several aligned load. But what would be the point of this round trip exactly?
[Bug c++/61402] New: [C++1y] Init-capture with side effect not working for some types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61402
Bug ID: 61402
Summary: [C++1y] Init-capture with side effect not working for
some types
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thibaut.lutz at googlemail dot com
Lambda functions with an init-capture for which the initializer has a side
effect is not always taken into account.
The example below defines a lambda with an init-capture, which increments a
variable in the initalizer, and invoke the lambda immediately with the same
variable as a parameter. The body of the lambda prints the value of the
captured value and its parameters, which should be identical.
Expected result: The captured value and the parameter should have the same
value, since the instantiation of the lambda should be evaluated before its
invocation.
Actual results: for some types (at least bool and char), the increment inside
the init-capture is partially evaluated: the captured value is correct but the
side effect is gone. Other types are working as expected.
Tested with: gcc 4.9.0 and 4.8.1
Code:
--888888--
#include iostream
templatetypename T
void foo(T t) {
using namespace std;
// print the original argument
cout endl par t = t endl;
{ // lambda function declaration and invocation
// capture argument by-copy after pre-increment
[ i = ++t ]
// take one parameter
(T v)
{
// print captured value and argument
cout cap i = ++t = i endl
arg v = v endl;
}
// invocation with the new value of the argument
(t);
}
}
int main(){
foo(3.14f); // works OK
foo(0); // works OK
foo('a'); // fails!
foo(false); // fails!
}
--888888--
Program output:
par t = 3.14
cap i = ++t = 4.14
arg v = 4.14
par t = 0
cap i = ++t = 1
arg v = 1
par t = a
cap i = ++t = b
arg v = a
par t = 0
cap i = ++t = 1
arg v = 0
For the last two types (char and bool), we observe v == t instead of v == i.
[Bug c++/61402] [C++1y] Init-capture with side effect not working for some types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61402
--- Comment #1 from Thibaut LUTZ thibaut.lutz at googlemail dot com ---
I forgot to add that separating declaration and invocation seems to solve the
problem:
--888888--
#include iostream
templatetypename T
void foo(T t) {
using namespace std;
cout endl par t = t endl;
auto test = [ i = ++t ](T v) {
cout cap i = ++t = i endl
arg v = v endl;
};
test(t);
}
int main(){
foo(3.14f); // works OK
foo(0); // works OK
foo('a'); // works OK
foo(false); // works OK
}
--888888--
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #11) So I am testing the patch right now and should be able to send it tomorrow. However, the code already shall already mark the load with the actual alignment the access is being done with. Therefore it seems to me that something in the backend fails to split the unaligned load into several aligned load. But what would be the point of this round trip exactly? I'd say Index: tree-ssa-math-opts.c === --- tree-ssa-math-opts.c(revision 211170) +++ tree-ssa-math-opts.c(working copy) @@ -2149,7 +2149,8 @@ bswap_replace (gimple stmt, gimple_stmt_ unsigned align; align = get_object_alignment (src); - if (bswap SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) + if (align GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) + SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) return false; /* Compute address to load from and cast according to the size is obvious (and pre-approved).
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Thomas Preud'homme from comment #10) So I am testing the patch right now and should be able to send it tomorrow. However, the code already shall already mark the load with the actual alignment the access is being done with. Therefore it seems to me that something in the backend fails to split the unaligned load into several aligned load. Could you break after the line align = get_object_alignment (src); in tree-ssa-math-opts.c when compiling gcc/java/jcf-parse.c in stage 1 (I suppose it breaks in stage 2)? What does print align gives? What about print load_type-type_common.align ? Best regards. The question is more like what happens in expand_assignment, that is, why don't we go the extract_bit_field codepath.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #14 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Richard Biener from comment #12) (In reply to Eric Botcazou from comment #11) So I am testing the patch right now and should be able to send it tomorrow. However, the code already shall already mark the load with the actual alignment the access is being done with. Therefore it seems to me that something in the backend fails to split the unaligned load into several aligned load. But what would be the point of this round trip exactly? I'd say Index: tree-ssa-math-opts.c === --- tree-ssa-math-opts.c(revision 211170) +++ tree-ssa-math-opts.c(working copy) @@ -2149,7 +2149,8 @@ bswap_replace (gimple stmt, gimple_stmt_ unsigned align; align = get_object_alignment (src); - if (bswap SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) + if (align GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) + SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) return false; /* Compute address to load from and cast according to the size is obvious (and pre-approved). obvious as a workaround, that is.
[Bug java/61398] [4.10 Regression] Object.java:313:0: ICE: Bus error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61398 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Sounds like a dup of PR61320?
[Bug middle-end/61394] [4.10 regression] ICE in symtab_get_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61394 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I think I've seen a dup. The issue is we fail to set DECL_HARD_REGISTER on this bogus decl and/or fail to set it up as proper variable. That leaves the symtab in inconsistent shape.
[Bug other/61391] [4.10 Regression] ICE in execute_one_pass at -O3 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61391 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-03 CC||ysrumyan at gmail dot com Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. Backtrace: #0 0x00c6bdcb in bb_predicate (bb=basic_block 0x76d49d68 (14)) at /space/rguenther/src/svn/trunk/gcc/tree-if-conv.c:149 #1 0x00c6c127 in is_predicated (bb=basic_block 0x76d49d68 (14)) at /space/rguenther/src/svn/trunk/gcc/tree-if-conv.c:275 #2 0x00c6f101 in is_cond_scalar_reduction ( phi=gimple_phi 0x76d82300, reduc=0x7fffd888, op0=0x7fffd898, op1=0x7fffd890) at /space/rguenther/src/svn/trunk/gcc/tree-if-conv.c:1442 #3 0x00c6f63c in predicate_scalar_phi ( phi=gimple_phi 0x76d82300, cond=ne_expr 0x76d8b0f0, true_bb=basic_block 0x76d7e958 (27), gsi=0x7fffd970) at /space/rguenther/src/svn/trunk/gcc/tree-if-conv.c:1583 #4 0x00c6f8b4 in predicate_all_scalar_phis (loop=0x76c309c0) at /space/rguenther/src/svn/trunk/gcc/tree-if-conv.c:1637
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org ---
Btw, unpatched and with a cross to sparc-linux (didn't figure out a working
solaris triplet that builds) and
unsigned int foo (unsigned short *x)
{
return x[0] 16 | x[1];
}
I see
32 bit load in host endianness found at: _8 = (int) load_dst_11;
foo (short unsigned int * x)
{
short unsigned int _3;
int _4;
int _5;
short unsigned int _6;
int _7;
int _8;
unsigned int _9;
short unsigned int * load_src_10;
unsigned int load_dst_11;
bb 2:
_3 = *x_2(D);
_4 = (int) _3;
_5 = _4 16;
_6 = MEM[(short unsigned int *)x_2(D) + 2B];
_7 = (int) _6;
load_src_10 = x_2(D);
load_dst_11 = MEM[(short unsigned int *)load_src_10];
_8 = (int) load_dst_11;
_9 = (unsigned int) _8;
return _9;
expanding from
bb 2:
load_dst_11 = MEM[(short unsigned int *)x_2(D)];
return load_dst_11;
gets you
foo:
lduh[%o0], %g1
lduh[%o0+2], %o0
sll %g1, 16, %g1
jmp %o7+8
or %o0, %g1, %o0
which looks perfect to me.
So it must be sth else that breaks the libjava case?
Can someone please provide preprocessed source for jcf-parse.c and
point out the error in the assembly at least?
[Bug c++/61134] [4.7/4.8/4.9/4.10 Regression][C++11] bogus no matching function for call...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61134 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 3 11:55:28 2014 New Revision: 211175 URL: http://gcc.gnu.org/viewcvs?rev=211175root=gccview=rev Log: PR c++/61134 * pt.c (pack_deducible_p): Handle canonicalization. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/variadic158.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/pt.c
[Bug c++/61020] [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61020 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 3 11:55:36 2014 New Revision: 211176 URL: http://gcc.gnu.org/viewcvs?rev=211176root=gccview=rev Log: PR c++/61020 * varpool.c (ctor_for_folding): Handle uninitialized vtables. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/opt/typeinfo1.C Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/varpool.c
[Bug c++/61020] [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61020 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 3 11:56:58 2014 New Revision: 211178 URL: http://gcc.gnu.org/viewcvs?rev=211178root=gccview=rev Log: PR c++/61020 * varpool.c (ctor_for_folding): Handle uninitialized vtables. Added: trunk/gcc/testsuite/g++.dg/opt/typeinfo1.C Modified: trunk/gcc/ChangeLog trunk/gcc/varpool.c
[Bug lto/61334] [4.10 Regression] lto-cgraph.c:976:68: error: 'strnlen' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61334 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #5 from Iain Sandoe iains at gcc dot gnu.org --- works for me on ppc-darwin9
[Bug c++/59498] [DR 1430][4.9/4.10 Regression] Pack expansion error in template alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- And the current development version of clang also rejects this testcase: wa.C:5:34: error: pack expansion used as argument for non-pack parameter of alias template using variadic_alias = aliasT...; ^~~~ wa.C:1:24: note: template parameter is declared here template typename T, typename ... ^
[Bug c++/61046] [4.8/4.9/4.10 Regression] ICE in lookup_field_1, at cp/search.c:384
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61046 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.4 |4.10.0 Known to fail|4.10.0 | --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/61134] [4.7/4.8 Regression][C++11] bogus no matching function for call...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61134 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8/4.9/4.10 |[4.7/4.8 Regression][C++11] |Regression][C++11] bogus|bogus no matching function |no matching function for |for call... |call...| --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.9.1 and trunk so far.
[Bug c++/61020] [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61020 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug middle-end/61294] [4.9 Regression] erroneous memset used with constant zero length parameter warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61294
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC||jason at gcc dot gnu.org
Component|c++ |middle-end
--- Comment #4 from Jason Merrill jason at gcc dot gnu.org ---
It's clearly a false positive; the warning is intended to catch calls where the
user wrote a 0 directly in the argument list for memset (which suggests
accidentally transposed arguments), not cases where some execution path might
result in a 0 argument (which works fine). The only question is what there is
to fix either in GCC or GLIBC to avoid this false positive.
A simple way to work around this is to guard the memset with if (npoints 0).
The false positive seems to come up fairly often:
https://sourceware.org/ml/binutils/2012-02/msg00073.html
https://bugzilla.redhat.com/show_bug.cgi?id=452219
https://www.nsnam.org/bugzilla/show_bug.cgi?id=1165
Changing component to middle-end.
Reduced C testcase:
typedef __SIZE_TYPE__ size_t;
extern void *malloc (size_t __size) __attribute__ ((__malloc__)) __attribute__
((__warn_unused_result__));
extern void *memset (void *__s, int __c, size_t __n) __attribute__
((__nonnull__ (1)));
extern void __warn_memset_zero_len (void) __attribute__((__warning__ (memset
used with constant zero length parameter; this could be due to transposed
parameters)));
extern __inline __attribute__((__always_inline__))
__attribute__((__artificial__))
void *
memset (void *__dest, int __ch, size_t __len)
{
if (__builtin_constant_p (__len) __len == 0
(!__builtin_constant_p (__ch) || __ch != 0))
{
__warn_memset_zero_len ();
return __dest;
}
return __builtin___memset_chk (__dest, __ch, __len,
__builtin_object_size (__dest, 0));
}
int i;
inline int f()
{
if (i)
return i;
else
return 0;
}
void g(unsigned char val)
{
int len = f();
void *p = malloc (len);
memset (p, val, len);
}
[Bug tree-optimization/61403] New: An opportunity for x86 gcc vectorizer (~40% gain)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61403
Bug ID: 61403
Summary: An opportunity for x86 gcc vectorizer (~40% gain)
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: evstupac at gmail dot com
Test normalizing 3D coordinates failed to vectorize
#include math.h
struct XYZ
{
float x;
float y;
float z;
};
void
norm (struct XYZ *in, struct XYZ *out, int size)
{
int i;
for (i = 0; i size; ++i)
{
float n = sqrt(in[i].x * in[i].x + in[i].y * in[i].y + in[i].z *
in[i].z);
out[i].x = in[i].x / n;
out[i].y = in[i].y / n;
out[i].z = in[i].z / n;
}
}
gcc norm.c -Ofast -S -mssse3 -fdump-tree-vect-details
norm.c:14:3: note: type of def: 3.
norm.c:14:3: note: no array mode for V4SF[3]
norm.c:14:3: note: the size of the group of accesses is not a power of 2
norm.c:14:3: note: not vectorized: relevant stmt not supported: _19-x = _20;
Vectorization should give ~40% gain on x86
[Bug c++/60848] [4.7/4.8/4.9/4.10 Regression] Crash while experimenting with c++-0x initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60848 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/60894] [4.7/4.8/4.9/4.10 Regression] Use of redundant struct keyword in virtual function prototype combined with using statement causes compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60894 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Any news?
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.9.1 |4.9.0 --- Comment #28 from Richard Biener rguenth at gcc dot gnu.org --- Fixed for 4.9.0.
[Bug libfortran/61173] [4.9/4.10 Regression] Erroneous end of file with internal read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 --- Comment #7 from Keith Refson krefson at gmail dot com --- Is it possible to say which version of gcc will contain the fix? It is not in the gfortran.com snapshot dated 20140528. Will this go in to the 4.9.1 release?
[Bug c++/60848] [4.7/4.8/4.9/4.10 Regression] Crash while experimenting with c++-0x initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60848 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 3 14:11:10 2014 New Revision: 211179 URL: http://gcc.gnu.org/viewcvs?rev=211179root=gccview=rev Log: PR c++/60848 * call.c (is_std_init_list): Check CLASSTYPE_TEMPLATE_INFO. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist85.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug rtl-optimization/46235] inefficient bittest code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46235
--- Comment #5 from chris.a.ferguson at gmail dot com ---
This optimization opportunity is still being missed as of GCC 4.9.
Test cases:
bool IsBitSet1(unsigned char byte, int index)
{
return (byte (1index)) != 0;
}
bool IsBitSet2(unsigned char byte, int index)
{
return (byte index) 1;
}
From GCC 4.9:
IsBitSet1(unsigned char, int):
movecx, esi
moveax, 1
movzx edi, dil
saleax, cl
test eax, edi
setne al
ret
IsBitSet2(unsigned char, int):
movzx eax, dil
movecx, esi
sareax, cl
andeax, 1
ret
From Clang 3.3:
IsBitSet1(unsigned char, int):
btl%esi, %edi
setb %al
ret
IsBitSet2(unsigned char, int):
btl%esi, %edi
setb %al
ret
[Bug c++/60848] [4.7/4.8/4.9/4.10 Regression] Crash while experimenting with c++-0x initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60848 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.7.4 |4.10.0 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/61381] constexpr non captured by template lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61381 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- Recent gcc 4.10 trunk (20140602) accepts the code
[Bug libstdc++/61227] [C++11] Regex [\w] does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61227 --- Comment #6 from FaTony fatony at fatony dot net --- Hi. I'm using Debain Testing and today according to changelog: * Update to SVN 20140527 (r210956) from the gcc-4_9-branch. The bug still persists.
[Bug c++/61381] constexpr non captured by template lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61381 --- Comment #2 from vincenzo Innocente vincenzo.innocente at cern dot ch --- I am still at trunk revision 210507 will update and test again
[Bug c++/60992] [4.9/4.10 Regression] ICE in tsubst_copy, at cp/pt.c:12637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60992 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Jun 3 15:39:20 2014 New Revision: 211188 URL: http://gcc.gnu.org/viewcvs?rev=211188root=gccview=rev Log: PR c++/60992 * pt.c (tsubst_copy) [VAR_DECL]: Try lookup first. Add a new variable to local_specializations. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug ipa/61393] [trans-mem] O3 optimization level constant propagation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393 --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org --- Alexander, as a temporary workaround, you can use -fno-ipa-cp. The problem (also present in the trunk) seems to be that the tm_clone flag of cgrapn_node is not copied over to clones (of tm_clones). Thus, the following patch fixes the testcase: diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c index 4387b99..056d82b 100644 --- a/gcc/cgraphclones.c +++ b/gcc/cgraphclones.c @@ -562,6 +562,7 @@ cgraph_create_virtual_clone (struct cgraph_node *old_node, set_new_clone_decl_and_node_flags (new_node); new_node-clone.tree_map = tree_map; new_node-clone.args_to_skip = args_to_skip; + new_node-tm_clone = old_node-tm_clone; /* Clones of global symbols or symbols with unique names are unique. */ if ((TREE_PUBLIC (old_decl) However, I do not really know what the semantics of that flag mean so at least for now I am not going to propose this (I am also not quite sure this is the best place for the copy). What properties of a function should be maintained in order to keep it flagged as a tm clone?
[Bug c++/61214] [4.9/4.10 regression] Weird interaction between -fvisibility-inlines-hidden, inline virtuals and devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61214 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- I wonder why we don't inline Foo::clone, though.
[Bug fortran/61404] New: Incorrect error message when misusing a structure component + explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61404 Bug ID: 61404 Summary: Incorrect error message when misusing a structure component + explicit interface Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: bardeau at iram dot fr Dear gfortran developers, gfortran issues an incorrect error message using the (invalid on purpose) program below. It refers to the module providing the structure component, instead of the actual line where the error lies (CALL statement). The bug is observed with gfortran 4.9.0 but I also found it in gfortran 4.4.7, so it seems to be here since a long time... module gbl_message type :: mytype integer(kind=4) :: e end type mytype type(mytype), parameter :: seve = mytype(1) end module gbl_message ! module gbl_interfaces interface subroutine gagout(message) character(len=*), intent(in) :: message end subroutine gagout end interface end module gbl_interfaces ! program test use gbl_message use gbl_interfaces ! Make an incorrect call according to the interface: call gagout(seve%e,'Some string') end program test $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran Target: x86_64-unknown-linux-gnu Configured with: ./configure --with-gmp=... --prefix=... --enable-languages=c,c++,fortran Thread model: posix gcc version 4.9.0 (GCC) $ gfortran test.f90 test.f90:17.6: use gbl_message 1 Error: Type mismatch in argument 'message' at (1); passed INTEGER(4) to CHARACTER(1) You can see that the error message refers to the USE statement instead of the CALL statement. If I change the line call gagout(seve%e,'Some string') by call gagout(1,'Some string') the error message is now correct. Sebastien
[Bug c/61405] New: Not emitting enumeration value not handled in switch warning for bit-field enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61405
Bug ID: 61405
Summary: Not emitting enumeration value not handled in switch
warning for bit-field enums
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
This a followup to PR 61340. In both C and C++ we do not emit a
warning about unhandled enumeration values in a switch if the enum is
also a bit-field (and clang does, that is how it was noticed).
Testcase:
$ cat test.c
enum ipa_ref_use
{
IPA_REF_LOAD,
IPA_REF_STORE,
IPA_REF_ADDR,
IPA_REF_ALIAS
};
/* Record of reference in callgraph or varpool. */
struct ipa_ref
{
unsigned int lto_stmt_uid;
unsigned int referred_index;
#ifndef PRODUCE_WARNING
enum ipa_ref_use use:2;
#else
enum ipa_ref_use use;
#endif
unsigned int speculative:1;
};
int blah1 (unsigned int);
int blah2 (unsigned int);
int blah3 (unsigned int);
int
foo (struct ipa_ref *ref)
{
int r;
switch (ref-use)
{
case IPA_REF_LOAD:
r = blah1 (ref-lto_stmt_uid) + 8;
break;
case IPA_REF_STORE:
r = blah2 (ref-referred_index +5) * 3;
break;
case IPA_REF_ADDR:
r = blah3 (ref-lto_stmt_uid + ref-speculative);
break;
}
return r;
}
$ ~/gcc/mine/inst/bin/gcc test.c -O -S -Wswitch
$ ~/gcc/mine/inst/bin/gcc test.c -O -S -Wswitch -DPRODUCE_WARNING
test.c: In function ‘foo’:
test.c:30:3: warning: enumeration value ‘IPA_REF_ALIAS’ not handled in switch
[-Wswitch]
switch (ref-use)
^
$ clang test.c -O -S -Wswitch -DPRODUCE_WARNING
test.c:30:11: warning: enumeration value 'IPA_REF_ALIAS' not handled in switch
[-Wswitch]
switch (ref-use)
^
1 warning generated.
[Bug target/61154] [4.10 Regression][ARM] wide-int merge introduced regressions in vshuf tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154 --- Comment #9 from christophe.lyon at st dot com --- I confirm it fixes the regressions I reported. Thanks.
[Bug c/61405] Not emitting enumeration value not handled in switch warning for bit-field enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61405 --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org --- The reason why we do not emit is that in c_do_switch_warnings in c-family/c-common.c we check that: /* From here on, we only care about about enumerated types. */ if (!type || TREE_CODE (type) != ENUMERAL_TYPE) return; which fails because (unlike in the non-bit-field case) type is: integer_type 0x76d5e150 public unsigned QI size integer_cst 0x76c34768 type integer_type 0x76c36150 bitsizetype constant 8 unit size integer_cst 0x76c34780 type integer_type 0x76c360a8 sizetype constant 1 align 8 symtab 0 alias set -1 canonical type 0x76d5e150 precision 2 min integer_cst 0x76d4adc8 0 max integer_cst 0x76d4ade0 3
[Bug ipa/61340] ipa-pure-const.c, ipa-reference.c: possible missing switch cases ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61340 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2014-6-3 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- As far as the unhandled values are concerned, I have posted a patch addressing that to the mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00249.html I have also opened a new bug, PR 61405 for tracking that we do not warn for these enums and provided a simple testcase so I suggest any discussion what can be done about that is moved there.
[Bug bootstrap/61315] wide-int.cc cannot be built by darwin system compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61315 --- Comment #15 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Wed, 28 May 2014, manu at gcc dot gnu.org wrote: Is any company spending money on GCC Fortran development? That would be awesome if it were true! It's true for OpenACC support.
[Bug c++/61344] Wswitch does not work with enum bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61344 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Martin opened another report, but he has more analysis there, so closing this one. *** This bug has been marked as a duplicate of bug 61405 ***
[Bug middle-end/61396] [4.10 regression] ICE in simplify_immed_subreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61396 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-03 CC||iains at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Iain Sandoe iains at gcc dot gnu.org --- confirmed on ppc-darwin9
[Bug c/61405] Not emitting enumeration value not handled in switch warning for bit-field enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61405 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Related to PR53874.
[Bug c/61405] Not emitting enumeration value not handled in switch warning for bit-field enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61405 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 61344 has been marked as a duplicate of this bug. ***
[Bug ipa/61340] ipa-pure-const.c, ipa-reference.c: possible missing switch cases ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61340 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Blocks|61344 |61405 Ever confirmed|0 |1 --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Update blocking bug.
[Bug libstdc++/61227] [C++11] Regex [\w] does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61227 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Because nothing changed on the 4.9 branch
[Bug c++/61381] constexpr non captured by template lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61381 vincenzo Innocente vincenzo.innocente at cern dot ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from vincenzo Innocente vincenzo.innocente at cern dot ch --- confirmed it compile with [trunk revision 211189] a back port to 4.9.1. would be appreciated
[Bug c/48062] `shadowed declaration is here' should be a note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48062 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Mine.
[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue Jun 3 17:26:05 2014 New Revision: 211190 URL: http://gcc.gnu.org/viewcvs?rev=211190root=gccview=rev Log: Backport from mainline 2014-04-15 Jonathan Wakely jwak...@redhat.com PR libstdc++/60734 * include/bits/stl_tree.h (_Rb_tree::_M_end): Fix invalid cast. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/stl_tree.h
[Bug libstdc++/61227] [C++11] Regex [\w] does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61227 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue Jun 3 17:26:24 2014 New Revision: 211192 URL: http://gcc.gnu.org/viewcvs?rev=211192root=gccview=rev Log: Backport from mainline 2014-05-20 Tim Shen timshe...@gmail.com PR libstdc++/61227 * include/bits/regex_compiler.h (_BracketMatcher::_M_add_character_class): Add negative character class support. * include/bits/regex_compiler.tcc (_BracketMatcher::_M_apply): Likewise. * testsuite/28_regex/algorithms/regex_match/ecma/char/quoted_char.cc: Add more testcases. Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex_compiler.h branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex_compiler.tcc branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/algorithms/regex_match/ecma/char/quoted_char.cc
[Bug libstdc++/61227] [C++11] Regex [\w] does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61227 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.1 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- Now it's fixed on the 4.9 branch.
[Bug middle-end/60102] [4.9/4.10 Regression] powerpc fp-bit ices at dwf_regno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102 --- Comment #12 from Ulrich Weigand uweigand at gcc dot gnu.org --- (In reply to Sandra Loosemore from comment #9) I've been looking at this a little bit more. DWARF_FRAME_REGNUM is specifically documented to take a hard register number as its operand, so the assertion in dwf_regno is at least consistent with that. The one in dbx_reg_number is more dubious, since neither LEAF_REG_REMAP or DBX_REGISTER_NUMBER are documented to require a hard register number. So: either the powerpc backend is broken to be using a pseudo in this context, or else the documentation for DWARF_FRAME_REGNUM should be changed to permit this and the assertions (as necessary) moved into the target-specific implementations of these macros. All those routines are supposed to implement mappings from GCC internal hard register numbers to some externally-defined number scheme (DWARF, DBX, ...), so it is consistent that they only accept hard register numbers. The rs6000 back-end isn't actually attempting to use a pseudo, they're just using a quick hack there: apparently, with SPE registers, GCC internal hard registers 0 .. 31 may be backed by a pair of external registers in debug info, where the high element of the pair gets a DWARF number in the 1200 ... 1231 range. The rs6000_dwarf_register_span attempts to implement that by returning a PARALLEL of two registers. Now, according to the rules, those both ought to be hard registers. However, there is no GCC internal number defined for the high part of the pair. The back-end used to hack around that by simply using the DWARF number (in the 1200 ... 1231) range as hard regno, combined with another hack in rs6000_dbx_register_number that then just passes that number through unchanged to the DWARF assembler output. This all worked as long as the middle-end didn't look too closely at those PARALLELs ... but with those extra asserts, it now fails. I guess I don't quite understand why there aren't real GCC hard regnos to cover those SPE high parts ... that seems the cleanest solution. Not sure if this was done to avoid some drawback I'm not seeing right now ...
[Bug c/60439] No warning for case overflow in switch statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60439 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Jun 3 17:35:34 2014 New Revision: 211194 URL: http://gcc.gnu.org/viewcvs?rev=211194root=gccview=rev Log: PR c/60439 * doc/invoke.texi: Document -Wswitch-bool. * function.c (stack_protect_epilogue): Cast controlling expression of the switch to int. * gengtype.c (walk_type): Generate switch expression with its controlling expression cast to int. c/ * c-parser.c (c_parser_switch_statement): Pass explicit_cast_p to c_start_case. * c-tree.h (c_start_case): Update. * c-typeck.c (c_start_case): Add new boolean parameter. Warn if switch condition has boolean value. cp/ * semantics.c (finish_switch_cond): Warn if switch condition has boolean value. c-family/ * c.opt (Wswitch-bool): New option. testsuite/ * c-c++-common/pr60439.c: New test. * g++.dg/eh/scope1.C (f4): Add dg-warning. Added: trunk/gcc/testsuite/c-c++-common/pr60439.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/c/c-tree.h trunk/gcc/c/c-typeck.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/doc/invoke.texi trunk/gcc/function.c trunk/gcc/gengtype.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/eh/scope1.C
[Bug c/60439] No warning for case overflow in switch statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60439 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug c++/52174] [DR 1423] Implicit conversion of nullptr to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52174 --- Comment #7 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Jun 3 17:48:36 2014 New Revision: 211195 URL: http://gcc.gnu.org/viewcvs?rev=211195root=gccview=rev Log: gcc/cp 2014-06-03 Paolo Carlini paolo.carl...@oracle.com DR 1423 PR c++/52174 * call.c (standard_conversion): Convert nullptr to bool only in case of direct-initialization. (convert_like_real): Provide informative error message. gcc/testsuite 2014-06-03 Paolo Carlini paolo.carl...@oracle.com DR 1423 PR c++/52174 * g++.dg/cpp0x/nullptr31.C: New. * g++.dg/cpp0x/sfinae-nullptr1.C: Likewise. * g++.dg/cpp0x/nullptr17.C: Update. libstdc++-v3 2014-06-03 Paolo Carlini paolo.carl...@oracle.com DR 1423 PR c++/52174 * testsuite/20_util/is_assignable/value.cc: Update. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nullptr31.C trunk/gcc/testsuite/g++.dg/cpp0x/sfinae-nullptr1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/nullptr17.C trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/20_util/is_assignable/value.cc
[Bug c++/52174] [DR 1423] Implicit conversion of nullptr to bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52174 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.10.0.
[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue Jun 3 17:58:51 2014 New Revision: 211197 URL: http://gcc.gnu.org/viewcvs?rev=211197root=gccview=rev Log: Backport from mainline 2014-04-15 Jonathan Wakely jwak...@redhat.com PR libstdc++/60734 * include/bits/stl_tree.h (_Rb_tree::_M_end): Fix invalid cast. Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/bits/stl_tree.h
[Bug libstdc++/60966] std::call_once sometime hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966 --- Comment #30 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Tue Jun 3 17:58:56 2014 New Revision: 211198 URL: http://gcc.gnu.org/viewcvs?rev=211198root=gccview=rev Log: Backport from mainline 2014-05-16 Jonathan Wakely jwak...@redhat.com PR libstdc++/60966 * include/std/future (__future_base::_State_baseV2::_M_set_result): Signal condition variable after call_once returns. (__future_base::_State_baseV2::_M_do_set): Do not signal here. (promise::set_value, promise::set_exception): Increment the reference count on the shared state until the function returns. * testsuite/30_threads/promise/60966.cc: New. Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/30_threads/promise/60966.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/std/future
[Bug libstdc++/60734] Undefined behavior in g++-v4/bits/stl_tree.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.4 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for 4.8.4 and 4.9.1
[Bug libstdc++/60966] std::call_once sometime hangs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #31 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for 4.8.4 and 4.9.1
[Bug c++/59483] A nested lambda fails to find a protected name with qualified name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59483 --- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com --- It seems that 58972 is a duplicate, and is fixed by the same patch.
[Bug fortran/29383] Fortran 2003/F95[TR15580:1999]: Floating point exception (IEEE) support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29383 Walter Spector w6ws at earthlink dot net changed: What|Removed |Added CC||w6ws at earthlink dot net --- Comment #12 from Walter Spector w6ws at earthlink dot net --- Adding myself to the CC list, sympathizing with comment #5. Just IEEE_ARITHMETIC intrinsic functions for basic setting (e.g., IEEE_VALUE) and testing (e.g., IEEE_IS_NAN) with the default rounding mode, roughly equivalent to what g95 supports, would be very useful. I don't need fancy rounding modes.
[Bug c++/38612] Vague error diagnostics for pointer-to-member type incompatibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38612 --- Comment #6 from Michael Bruck bruck.michael at googlemail dot com --- (In reply to Manuel López-Ibáñez from comment #4) What do you think? Looks great. My main beef was that the two errors were merged into one diagnostic.
[Bug c++/51311] bogus array bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51311 Michael Bruck bruck.michael at googlemail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Michael Bruck bruck.michael at googlemail dot com --- Not reproducible with 4.8.2.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
unsigned int foo (unsigned short *x)
{
return x[0] 16 | x[1];
}
[...]
gets you
foo:
lduh[%o0], %g1
lduh[%o0+2], %o0
sll %g1, 16, %g1
jmp %o7+8
or %o0, %g1, %o0
which looks perfect to me.
Indeed, but after having gone through a perfectly useless transformation and
wasted cycles. This reminds me of the ipa-split + inlining round trip.
Really SPARC machines aren't fast enough to allow such a silliness...
[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org --- subroutine foo () type dt character(len=:), allocatable :: o character(len=:), allocatable :: n(:) end type type (dt) :: d logical :: l integer :: n n = 4 allocate(character(len=n+1) :: d%o) allocate(character(len=n+2) :: d%n(4)) end seems to ICE during gimplification (there is 0 = 4; stmt in *.original), and the length of d%n allocation is weird too. subroutine bar () character(len=:), allocatable :: o, o2 character(len=:), allocatable :: n(:), n2(:) allocate(character(len=4) :: o, n(10)) o2 = o n2 = n end ICEs too.
[Bug c/30020] improve diagnostics for limited range warning for a switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30020 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0
[Bug c++/58972] Lambda can't access private members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972 Ville Voutilainen ville.voutilainen at gmail dot com changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #2 from Ville Voutilainen ville.voutilainen at gmail dot com --- Uh oh. The current trunk ICEs with Daniel's code, but compiles Akim's testcase correctly.
[Bug c++/58972] Lambda can't access private members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972
--- Comment #3 from Ville Voutilainen ville.voutilainen at gmail dot com ---
[ville@localhost ~]$ g++ --std=c++11 -c dan.cpp
dan.cpp: In instantiation of ‘struct deriveT::foo(base::type) [with T = char;
base::type = int]::f_t’:
dan.cpp:18:5: required from ‘void deriveT::foo(base::type) [with T = char;
base::type = int]’
dan.cpp:26:11: required from here
dan.cpp:4:15: error: ‘typedef int base::type’ is protected
typedef int type;
^
dan.cpp:15:11: error: within this context
f_t(type a) : a(a) {}
^
dan.cpp: In instantiation of ‘void deriveT::foo(base::type) [with T = char;
base::type = int]’:
dan.cpp:26:11: required from here
dan.cpp:18:10: internal compiler error: in instantiate_decl, at cp/pt.c:19746
} f(a);
^
0x5c281f instantiate_decl(tree_node*, int, bool)
../../gcc/cp/pt.c:19745
0x638853 mark_used(tree_node*, int)
../../gcc/cp/decl2.c:5016
0x553bf3 build_over_call
../../gcc/cp/call.c:7325
0x55f470 build_new_method_call_1
../../gcc/cp/call.c:8037
0x55f470 build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.c:8107
0x560549 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, tree_node*, int, int)
../../gcc/cp/call.c:7651
0x6bd6e9 expand_default_init
../../gcc/cp/init.c:1713
0x6bd6e9 expand_aggr_init_1
../../gcc/cp/init.c:1814
0x6bfdac build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/cp/init.c:1566
0x57360c build_aggr_init_full_exprs
../../gcc/cp/decl.c:5642
0x57360c check_initializer
../../gcc/cp/decl.c:5777
0x58556c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:6445
0x5c9700 tsubst_expr
../../gcc/cp/pt.c:13650
0x5c5d83 tsubst_expr
../../gcc/cp/pt.c:13538
0x5c6a13 tsubst_expr
../../gcc/cp/pt.c:13724
0x5c401b instantiate_decl(tree_node*, int, bool)
../../gcc/cp/pt.c:20036
0x5fce67 instantiate_pending_templates(int)
../../gcc/cp/pt.c:20152
0x63a29f cp_write_global_declarations()
../../gcc/cp/decl2.c:4348
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/61406] New: ICE on ASSOCIATE construct to literal array expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61406 Bug ID: 61406 Summary: ICE on ASSOCIATE construct to literal array expression Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: adam at aphirst dot karoo.co.uk Created attachment 32885 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32885action=edit demonstration of ICE for ASSOCIATE with array literal Association of a name to a literal array expression (see attached test case) results in an ICE. I'm sure that this used to work in GCC 4.8 (at least, it seems to in the mingw32 setup of 4.8 that I have at work, and on a friend's 4.6), but not here in 4.9.0. Compiled using `gfortran -Wall -Wextra -std=f2008`. No optimisations. Arch Linux x86_64 - Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-4.9-20140521/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 4.9.0 20140521 (prerelease) (GCC)
[Bug libstdc++/56166] std::string::clear() can throw despite being marked noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- I think __gnu_cxx::__rc_string has the same problem There's a patch at https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00278.html
[Bug fortran/61318] Improve error diagnostic by pointing to the expression and not to declared-at of a USE-associated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61318 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||bardeau at iram dot fr --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 61404 has been marked as a duplicate of this bug. ***
[Bug fortran/61404] Incorrect error message when misusing a structure component + explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61404 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Duplicate. *** This bug has been marked as a duplicate of bug 61318 ***
[Bug c++/61382] parameter pack expansion unexpected order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61382
Thibaut LUTZ thibaut.lutz at googlemail dot com changed:
What|Removed |Added
CC||thibaut.lutz at googlemail dot
com
--- Comment #2 from Thibaut LUTZ thibaut.lutz at googlemail dot com ---
@Jonathan: you might be referring to 56774. 59716 was a similar issue.
However I think this case is definitely NOT a bug. Here is why:
- let's decompose the line:
std::tupleARGS... r { get_singleARGS(posfoo++)... };
* std::tupleARGS... r{ ... }: this is a constructor call: std::tuple(args...)
* get_singleARGS(posfoo++)... expands to get_singleint(posfoo++),
get_singlefloat(posfoo++), get_singlefloat(posfoo++),
get_singleint(posfoo++)
Putting the two together, with the previous line:
int posfoo = 0;
std::tupleARGS... r ( get_singleint(posfoo++),
get_singlefloat(posfoo++),
get_singlefloat(posfoo++),
get_singleint(posfoo++));
This is the root of your problem:
N3797 §8.3.6.9: The order of evaluation of function arguments is unspecified.
The pack expansion is working fine, but the increments to posfoo are not being
sequenced. Clang does evaluate arguments in the opposite order as GCC does,
which makes it look correct in this case, but it is still undefined behavior.
You can re-write your get_single function to do a pack traversal instead.
[Bug c++/61382] parameter pack expansion unexpected order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61382
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Thibaut LUTZ from comment #2)
@Jonathan: you might be referring to 56774. 59716 was a similar issue.
They don't look related. I meant PR 51253
However I think this case is definitely NOT a bug. Here is why:
- let's decompose the line:
std::tupleARGS... r { get_singleARGS(posfoo++)... };
* std::tupleARGS... r{ ... }: this is a constructor call:
std::tuple(args...)
No, this is not a valid transformation, the semantics of T r{args...} are not
the same as T r(args...), see [dcl.init.list] p4.
[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org --- Trunk still gives -Wsequence-point warnings, and PR 61382 has an example that still fails
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #17 from Thomas Preud'homme thomas.preudhomme at arm dot com --- (In reply to Richard Biener from comment #12) I'd say Index: tree-ssa-math-opts.c === --- tree-ssa-math-opts.c(revision 211170) +++ tree-ssa-math-opts.c(working copy) @@ -2149,7 +2149,8 @@ bswap_replace (gimple stmt, gimple_stmt_ unsigned align; align = get_object_alignment (src); - if (bswap SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) + if (align GET_MODE_ALIGNMENT (TYPE_MODE (load_type)) + SLOW_UNALIGNED_ACCESS (TYPE_MODE (load_type), align)) return false; /* Compute address to load from and cast according to the size is obvious (and pre-approved). Alright but tests need to be modified to add an xfail for target impacted by this. I did such a change and also rewrote the tests to use aligned variable as much as possible so that they are more meaningful on STRICT_ALIGNMENT targets. I'll post it for review today (at least for the changes in the testsuite).
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #18 from Thomas Preud'homme thomas.preudhomme at arm dot com ---
(In reply to Eric Botcazou from comment #16)
unsigned int foo (unsigned short *x)
{
return x[0] 16 | x[1];
}
[...]
gets you
foo:
lduh[%o0], %g1
lduh[%o0+2], %o0
sll %g1, 16, %g1
jmp %o7+8
or %o0, %g1, %o0
which looks perfect to me.
Indeed, but after having gone through a perfectly useless transformation and
wasted cycles. This reminds me of the ipa-split + inlining round trip.
Really SPARC machines aren't fast enough to allow such a silliness...
Fair enough but the information about alignment is only available late in the
pass so that most of the code is already executed. Only when the whole OR
expression has been processed do we know what is the lowest address and the
range of the memory access and therefore whether that access is aligned or not.
Also if the expression was loading a 32 bit value byte by byte then the
transformation would be useful. I'm already working on a patch to add a cost
model but this will just add more code to execute before taking the decision.
It will however prevent rewriting statements if the result will execute slower
on the target.
Maybe a better solution for sparc would be to add a switch for this pass and
disable it by default on sparc. What do you think about that?
[Bug libfortran/61173] [4.9/4.10 Regression] Erroneous end of file with internal read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61173 --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- I will backport to 4.9 in the next few days so it will get into 4.9.1 I am not sure how your snapshot is set up. If it is using dynamically loaded library, you may be getting the newer gfortran calling an older libgfortran in the library search path. So try with -static to see if that works. It should be in the 4.10 trunk by the date you gave for the snapshot.
[Bug target/61407] New: Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 Bug ID: 61407 Summary: Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kassafari at gmail dot com Created attachment 32886 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32886action=edit make log Will not build on latest OS X and Xcode... Attaching log...
[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483 --- Comment #7 from dennis luehring dl.soluz at gmx dot net --- clang got now support for (see: http://clang-developers.42468.n3.nabble.com/missing-optimization-opportunity-for-const-std-vector-compared-to-std-array-td4034587.html#none) void *__builtin_operator_new(size_t) void __builtin_operator_delete(void*) and using this in libc++ can reduce all testcases down to the const result gcc seems to have removed these long time ago and i currently do understand whats gcc solution could be
