[Bug fortran/61234] Warn for use-stmt without explicit only-list.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61234 Joost VandeVondele changed: What|Removed |Added URL||https://gcc.gnu.org/ml/fort ||ran/2014-05/msg00158.html --- Comment #5 from Joost VandeVondele --- patch posted
[Bug middle-end/61354] GCC bootstrap with LTO fails in trunk when built with isl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61354 Maxim Kuvyrkov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mkuvyrkov at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Maxim Kuvyrkov --- ./contrib/download_prerequisites should be run at the top-level directory of GCC source. If run inside ./gcc/ sources of supporting libraries will be treated with same strict requirement as GCC code. Closing as INVALID.
[Bug rtl-optimization/59429] Missed optimization opportunity in qsort-style comparison functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429 --- Comment #13 from Kai Tietz --- Hmm, I don't see what binary-combine helper would help here? It might be a good thing to have such a abstract-representation for doing logical optimizations of comparison chains. Nevertheless this seems to me being not the solution for the given issue here. The issue - described in this problem - is more related to simple pattern-matching. So normalization in such cases seems to be the way to go.
[Bug middle-end/61354] GCC bootstrap with LTO fails in trunk when built with isl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61354 --- Comment #2 from Venkataramanan --- Maxim, "sources/gcc-fsf/gcc" is the top level source directory and it contains the contrib folder. gcc compiler sources are in "sources/gcc-fsf/gcc/gcc".
[Bug spam/61366] erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61366 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|java|spam Resolution|--- |INVALID Severity|critical|normal --- Comment #1 from Jonathan Wakely --- .
[Bug spam/61365] e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61365 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|java|spam Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- .
[Bug lto/58528] lto1: internal compiler error: in build_abbrev_table, at dwarf2out.c:7478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58528 Eduard Bloch changed: What|Removed |Added CC||blade at debian dot org --- Comment #8 from Eduard Bloch --- I have the same or at least very similar issue and it makes me crazy because it seems to have something with the position of the -g flag. I.e. this option set seems to work: -pthread -g -O3 -Wall -Wextra -Wno-unused-parameter -D_FILE_OFFSET_BITS=64 -flto but -pthread -O3 -Wall -Wextra -Wno-unused-parameter -D_FILE_OFFSET_BITS=64 -g -flto does not! There also seems to be some kind of race: the first time I tried it with g++-4.9, it was hanging for a while and then segfaulted, afterwards it's now running into ICE (same behavior with version 4.8). I made a build with -save-temps inside, see https://www.unix-ag.uni-kl.de/~bloch/acng/tmp/ and I can provide source: git clone https://alioth.debian.org/anonscm/git/apt-cacher-ng/apt-cacher-ng.git Branch: upstream Ref: 55661a69fcdc8263101a7849d3f9f83b8b05571b Command: make -j5 CXXFLAGS="-g -flto" LDFLAGS=-flto apt-cacher-ng
[Bug inline-asm/49611] Inline asm should support input/output of flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
Jeremy changed:
What|Removed |Added
CC||gcc.hall at gmail dot com
--- Comment #5 from Jeremy ---
It may not be possible, but perhaps a simpler thing might be for
the asm() to notionally "return" a single boolean value which
reflects ONE flag only.
By default this could be the ZF flag (which is probably the most
useful). It would not generate any extra code at all. Thus:
if( asm( "test %%eax,%%eax" ))
would emit:
test eax,eax
jz
rather than the usual route involving setcc and a second test.
The actual flag notionally returned could be changed with an attribute:
__attribute__ ((asm_return(cc_carry)))
__attribute__ ((asm_return(cc_overflow)))
__attribute__ ((asm_return(cc_zero)))
__attribute__ ((asm_return(cc_sign)))
__attribute__ ((asm_return(cc_parity)))
or shorter, for example:
__attribute__ ((cc_carry))
The inverse condition is simply expressed with !asm(...)
The new code would also allow:
bool zero = asm( "test %%eax,%%eax" );
where the compiler would emit setz.
or
x = asm( "test %%eax,%%eax" ) ? 10 : 20;
where the compiler might emit cmovz.
It would not break any existing code because nothing yet expects a return from
an asm,
neither would it preclude exporting all the flags with "=cc" in the future.
It would be a hard error if a flag is not supported by the current platform as
code cannnot be generated.
GCC does not examine the asm template string, if the flag is not set then the
result is UB, just like use of an undefined variable.
A final, more useful, example:
// Implement "left *= right" reporting signed integer overflow
#define checked_multiply(left,right) \
__attribute__ ((asm_return(cc_overflow))) \
asm( "imul %1,%0" : "+r" (left) : "r" (right) )
allowing an efficient implementation of:
if( checked_multiply( a, b ) )
{
handle overflow
}
Possible documentation follows...
Return Value
If you are using the asm_return attribute, you are informing the compiler that
a comparison has already been done in your assembler code, and the flags have
been set appropriately. The compiler can now use those flags to perform
conditional jumps, conditional assignments, etc. Which conditional operator
should be used is determined by which value is specified to asm_return. For
example on i386:
if( __attribute__(asm_return(cc_carry)) asm() )
printf ("Carry yes\n");
else
printf ("Carry no\n");
indicates that the asm template has set a value in the Carry flag, and GCC
should use the jc/jnc instructions to jump to the correct location. Similarly:
int a = __attribute__(asm_return(cc_zero)) asm() ? 23 : 42;
could use the i386 cmovz instruction to perform the assignment. And
bool DidOverflow = __attribute__(asm_return(cc_overflow)) asm();
could use i386's seto.
Which flags (if any) are supported depend upon your platform (see Asm
Attributes). If no asm_return attribute is specified, it is an error to attempt
to use the return value from the asm. It is acceptable for code to ignore the
returned flags.
[Bug ipa/61211] [4.9/4.10 Regression] ICE: verify_cgraph_node failed: edge points to wrong declaration with -O3 -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61211 Martin Jambor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-30 Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Jambor --- Mine.
[Bug c/30020] improve diagnostics for limited range warning for a switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30020
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-05-30
CC||manu at gcc dot gnu.org
Summary|missing limited range |improve diagnostics for
|warning for a switch|limited range warning for a
|statement |switch statement
Ever confirmed|0 |1
--- Comment #2 from Manuel López-Ibáñez ---
GCC now warns by default for this, but the location sucks.
test.c: In function ‘foo’:
test.c:3:3: warning: case label value is less than minimum value for type
switch (c) { case -1: return -1; };
^
It would be nice if it said which type.
Clang says:
test.c:3:21: warning: overflow converting case value to switch condition type
(-1 to 255) [-Wswitch]
switch (c) { case -1: return -1; };
^
[Bug c++/38612] Vague error diagnostics for pointer-to-member type incompatibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38612
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-05-30
CC||jason at gcc dot gnu.org,
||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from Manuel López-Ibáñez ---
I agree the diagnostic could be much better but I'm not fully convinced by your
proposal.
Clang++ says:
pr38612.cc:7:16: error: left hand operand to ->* must be a pointer to class
compatible with the right hand operand, but is 'X'
return object->*p2m;// fails because X is incomplete
^
pr38612.cc:2:8: note: forward declaration of 'X'
struct X;// X derived from Base later but incomplete here
^
pr38612.cc:21:16: error: left hand operand to ->* must be a pointer to class
compatible with the right hand operand, but is 'Y *'
return object->*p2m;// fails because Y is not derived from A
^
which to me is only slightly better.
I think I would like to get:
pr38612.cc:7:16: error: right hand operand 'Base::*' to '->*' is not compatible
with left-hand operand 'X *' because 'X' is not a complete type
return object->*p2m;// fails because X is incomplete
^
pr38612.cc:2:8: note: forward declaration of 'X'
struct X;// X derived from Base later but incomplete here
^
pr38612.cc:21:16: error: right hand operand 'Base::*' to '->*' is not
compatible with left-hand operand 'Y *' because 'Y' is not derived from 'Base'
return object->*p2m;// fails because Y is not derived from A
^
pr38612.cc:3:8: note: 'Y' declared here
struct Y {};// Y not derived from Base
^
What do you think?
Jason?
[Bug inline-asm/49611] Inline asm should support input/output of flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49611
--- Comment #6 from Ryan Johnson ---
(In reply to Jeremy from comment #5)
> It may not be possible, but perhaps a simpler thing might be for
> the asm() to notionally "return" a single boolean value which
> reflects ONE flag only.
Interesting!
Ironically, limiting it to one flag opens the way to cleanly specify branching
based on multiple flags. The optimizer just needs to recognize that when it
sees two otherwise-equivalent (non-volatile) asm statements with different
asm_return attribute, it's really just one asm statement that sets multiple
flags. Thus:
#ifdef USE_ASM
#define CMP(a,b) asm("cmp %0 %1" : : "r"(a), "r"(b))
#define BELOW(a,b) (__attribute__((asm_return(cc_carry))) CMP(a,b))
#define EQUAL(a,b) (__attribute__((asm_return(cc_zero))) CMP(a,b))
#else
#define BELOW(a,b) ((a) < (b))
#define EQUAL(a,b) ((a) == (b))
#endif
int do_it(unsigned int a, unsigned int b, int c, int d, int e, int f) {
int x;
if (BELOW(a,b))
x = c+d;
else if (EQUAL(a,b))
x = d+e;
else
x = c+e;
return x+f;
}
Would produce the same assembly code output---with only one
comparison---whether USE_ASM was defined or not.
Even more fun would be if the optimizer could recognize conditionals that
depend on multiple flags (like x86 "less or equal") and turn this:
if ((__attribute__((asm_return(cc_zero))) CMP(a,b)
|| __attribute__((asm_return(cc_overflow))) CMP(a,b)
!= __attribute__((asm_return(cc_sign))) CMP(a,b))
do_less_or_equal();
do_something_else();
into:
cmp %[a] %[b]
jg 1f
call do_less_or_equal
1:
call do_something_else
Much of the flag-wrangling machinery seems to already exist, because the
compiler emits the above asm if you replace the inline asm with either "a <= b"
or "a < b || a == b" (assuming now that a and b are signed ints).
[Bug c++/38612] Vague error diagnostics for pointer-to-member type incompatibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38612 --- Comment #5 from Jason Merrill --- (In reply to Manuel López-Ibáñez from comment #4) Those sound good to me.
[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 changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- I will take a look at the location stuff.
[Bug c++/61368] New: Sfinae with template member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61368
Bug ID: 61368
Summary: Sfinae with template member
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: p.bartosiewi at partner dot samsung.com
GCC 4.8.2 can't compile following reduced code snippet, but I think the code is
fine. I've checked it against clang 3.4 and code compiles fine.
typedef char true_type;
typedef int false_type;
struct SubObject {
template
void visit(V v) {
v(1); // error here
}
};
struct Object {
template
void visit(V v) {
v(SubObject());
}
};
struct VisitorMatcher {
template
void operator()(T);
};
template
struct hasVisitor {
template
static true_type test(decltype(&C::template visit));
//template
//static true_type test(decltype(&C::template visit));
template static false_type test(...);
typedef decltype(test(0)) type;
};
struct Visitor {
template
void operator()(T v)
{
typedef typename hasVisitor::type type;
// impl(v, type());
}
};
int main()
{
Object o;
o.visit(Visitor());
}
[Bug libstdc++/61369] New: std::discrete_distribution::operator() may return event 0 even if its probability is 0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61369 Bug ID: 61369 Summary: std::discrete_distribution::operator() may return event 0 even if its probability is 0.0 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: stefan_stuff at web dot de OLD CODE: std::discrete_distribution::operator() in 4.9.0 random.tcc: 2843 __detail::_Adaptor<_UniformRandomNumberGenerator, double> 2844 __aurng(__urng); 2845 2846 const double __p = __aurng(); 2847 auto __pos = std::lower_bound(__param._M_cp.begin(), 2848 __param._M_cp.end(), __p); 2849 2850 return __pos - __param._M_cp.begin(); PROPOSED FIX: std::lower_bound should be std::upper_bound. EXAMPLE: Assume the following distribution: (The specification allows 0-weights, if at least one weight is strictly positive.) event: 0 | 1 | 2 | 3 probability:0.0 |0.5 | 0.0 |0.5 cummulative:0.0 |0.5 | 0.5 |1.0 lower_bound: [0.0, 0.0] | (0.0, 0.5] | - | (0.5, 1.0) upper_bound: - | [0.0, 0.5) | - | [0.5, 1.0) __p is in the interval [0.0, 1.0). The lower 2 rows describe the intervals of __p, in which the according event-index is returned. This shows, that std::lower_bound produces wrong results, if the first element has probability 0.0 and __p is also 0.0. (Another positive effect of using std::upper_bound is, that the intervals are more balanced as all intervals are inclusive-exclusive, in contrast to lower_bound, which is inclusive-inclusive for the last event.) This will *probably* be fixed by Bug ID 57925, where this algorithm is reworked, but I haven't done the math for the new algorithm.
[Bug c++/61362] g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 does not compile lambda with template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61362
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
||com
--- Comment #1 from Daniel Krügler ---
The code produces an ICE on gcc 4.8.2, 4.9.0, and recent 4.10.0 trunk:
"prog.cc: In instantiation of 'struct C::__lambda0': prog.cc:8:7:
required from here prog.cc:11:38: internal compiler error: in tsubst_copy, at
cp/pt.c:12116 std::function f = [this](N node) { ^ 0x51c14e
tsubst_copy ../../gcc-4.8.2/gcc/cp/pt.c:12116 0x51c743
tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool)
../../gcc-4.8.2/gcc/cp/pt.c:14455 0x51c7e2 tsubst_copy_and_build(tree_node*,
tree_node*, int, tree_node*, bool, bool) ../../gcc-4.8.2/gcc/cp/pt.c:14236
0x52b94f instantiate_class_template_1 ../../gcc-4.8.2/gcc/cp/pt.c:9030 0x52b94f
instantiate_class_template(tree_node*) ../../gcc-4.8.2/gcc/cp/pt.c:9088
0x57993d complete_type(tree_node*) ../../gcc-4.8.2/gcc/cp/typeck.c:131 0x51d448
tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool)
../../gcc-4.8.2/gcc/cp/pt.c:14552 0x592618 perform_member_init
../../gcc-4.8.2/gcc/cp/init.c:538 0x592618 emit_mem_initializers(tree_node*)
../../gcc-4.8.2/gcc/cp/init.c:1109 0x596976 synthesize_method(tree_node*)
../../gcc-4.8.2/gcc/cp/method.c:796 0x54367a mark_used(tree_node*)
../../gcc-4.8.2/gcc/cp/decl2.c:4677 0x4f01ec build_over_call
../../gcc-4.8.2/gcc/cp/call.c:7055 0x4ed698 build_new_method_call_1
../../gcc-4.8.2/gcc/cp/call.c:7715 0x4ed698 build_new_method_call(tree_node*,
tree_node*, vec**, tree_node*, int, tree_node**,
int) ../../gcc-4.8.2/gcc/cp/call.c:7785 0x4edf3e
build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int) ../../gcc-4.8.2/gcc/cp/call.c:7352 0x58fec5
expand_default_init ../../gcc-4.8.2/gcc/cp/init.c:1679 0x58fec5
expand_aggr_init_1 ../../gcc-4.8.2/gcc/cp/init.c:1780 0x591a08
build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc-4.8.2/gcc/cp/init.c:1531 0x4fcd9c build_aggr_init_full_exprs
../../gcc-4.8.2/gcc/cp/decl.c:5543 0x4fcd9c check_initializer
../../gcc-4.8.2/gcc/cp/decl.c:5678 Please submit a full bug report, with
preprocessed source if appropriate. Please include the complete backtrace with
any bug report. See for instructions."
[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 #5 from Jason Merrill --- Author: jason Date: Fri May 30 15:09:40 2014 New Revision: 211084 URL: http://gcc.gnu.org/viewcvs?rev=211084&root=gcc&view=rev Log: PR c++/60992 * pt.c (tsubst_init): Split out from... (tsubst_expr) [DECL_EXPR]: Here. (tsubst_copy) [VAR_DECL]: Use it. * semantics.c (finish_id_expression): Return the decl for static/const. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c
[Bug c++/56947] [4.7 Regression] Bogus 'XX' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56947 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri May 30 15:09:29 2014 New Revision: 211083 URL: http://gcc.gnu.org/viewcvs?rev=211083&root=gcc&view=rev Log: PR c++/56947 * pt.c (instantiate_decl): Don't defer instantiation of a nested function. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/template/local8.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/pt.c
[Bug c++/61362] g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 does not compile lambda with template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61362
--- Comment #2 from Daniel Krügler ---
Reduced example (removing library dependencies) using compiler flags
-Wall -Wextra -std=c++11 -pedantic
for gcc HEAD 4.10.0 20140529 (experimental)
//-
struct function {
template
function(F){}
void operator()(...) {}
};
struct Node {
unsigned length;
};
template
class C {
public:
unsigned longest = 0;
function f = [this](N node) {
if(node->length > this->longest) this->longest = node->length;
};
};
int main() {
Node n;
n.length = 5;
C c;
c.f(&n);
}
//-
results in
"prog.cc: In instantiation of 'C:: [with N = Node*]':
prog.cc:16:17: required from 'struct C::'
prog.cc:24:12: required from here prog.cc:16:29: internal compiler error:
Segmentation fault function f = [this](N node) { ^ 0x96976f crash_signal
/home/heads/gcc/gcc-source/gcc/toplev.c:337 0x56ddb5
instantiate_decl(tree_node*, int, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:19932 0x5802b1
instantiate_class_template_1 /home/heads/gcc/gcc-source/gcc/cp/pt.c:9367
0x5802b1 instantiate_class_template(tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:9435 0x5d726d complete_type(tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/typeck.c:134 0x567644
tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:15327 0x5ec715 get_nsdmi(tree_node*,
bool) /home/heads/gcc/gcc-source/gcc/cp/init.c:543 0x5f4bf4 walk_field_subobs
/home/heads/gcc/gcc-source/gcc/cp/method.c:1098 0x5f53bc
synthesized_method_walk /home/heads/gcc/gcc-source/gcc/cp/method.c:1424
0x5f64b5 get_defaulted_eh_spec(tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/method.c:1455 0x581707
maybe_instantiate_noexcept(tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:19563 0x599ae7 mark_used(tree_node*,
int) /home/heads/gcc/gcc-source/gcc/cp/decl2.c:4823 0x537459 build_over_call
/home/heads/gcc/gcc-source/gcc/cp/call.c:7325 0x53de3a build_new_method_call_1
/home/heads/gcc/gcc-source/gcc/cp/call.c:8037 0x53de3a
build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/heads/gcc/gcc-source/gcc/cp/call.c:8107 0x53e6e6
build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/heads/gcc/gcc-source/gcc/cp/call.c:7651 0x5ef036 expand_default_init
/home/heads/gcc/gcc-source/gcc/cp/init.c:1713 0x5ef036 expand_aggr_init_1
/home/heads/gcc/gcc-source/gcc/cp/init.c:1814 0x5f096e
build_aggr_init(tree_node*, tree_node*, int, int)
/home/heads/gcc/gcc-source/gcc/cp/init.c:1566 0x549a2d
build_aggr_init_full_exprs /home/heads/gcc/gcc-source/gcc/cp/decl.c:5642 Please
submit a full bug report, with preprocessed source if appropriate. Please
include the complete backtrace with any bug report. See
for instructions."
[Bug c++/61370] New: decltype, enable_if, previous arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61370 Bug ID: 61370 Summary: decltype, enable_if, previous arguments Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: patrick.a.moran at gmail dot com Created attachment 32878 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32878&action=edit minimal reproduction SFINAE that depednds on the decltype of a previous argument fails to funciton in a member function if the definition is external to the class. The out-of-class definition is reported as having a prototype that does not match any in the class. In the attached test case you can see the error. If you define WORKAROUND, you will see the same code with the definition moved into the class and the error will not recur.
[Bug c++/36183] misleading error message with explicit copy constructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36183
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-05-30
CC||jason at gcc dot gnu.org,
||manu at gcc dot gnu.org
Ever confirmed|0 |1
Severity|trivial |normal
--- Comment #1 from Manuel López-Ibáñez ---
It seems to me that the problem is the "explicit" keyword, so an error like:
test.cc:14:6: error: no matching function for call to ‘B::B(const B&)’
f(b); // error: no matching function for call to 'B::B(const B&)'
^
test.cc:4:3: note: candidate: 'explicit B::B(const B&)'
B() {}
^
test.cc:4:3: note: is marked as explicit but implicit conversion required
test.cc:8:6: note: initializing argument 1 of ‘void f(B)’
void f(B obj) {}
^
Jason?
[Bug preprocessor/61371] New: cpp: Implement -fno-date-time/-freproducible-dates or similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61371 Bug ID: 61371 Summary: cpp: Implement -fno-date-time/-freproducible-dates or similar Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: crrodriguez at opensuse dot org Hi: Current releases have the option to warn/err on the use of __DATE__ , __TIME__ and __TIMESTAMP__, first thanks for implementing this as it is a good step to aid reproducible builds. That said, it is unfortunately still quite inconvenient for large scale projects such as distributions because it requires going through hundreds or thousands of packages. I suggest a command line option to be implemented such as -fno-date-time -freproducible-dates Or whatever other appropriate name that behaves in one of this ways: Either: - __DATE__, __TIME__ and __TIMESTAMP__ expand as "If GCC cannot determine the current date" (that is ???...) - __DATE__ and __TIME__ expand to the file 's last modification time - Whatever other sane alternative that ensures different builds of the same source code and same preprocessor/compiler/linker options result in identical builds.
[Bug preprocessor/61371] cpp: Implement -fno-date-time/-freproducible-dates or similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61371 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- You can simply redefine them in the command-line: http://lists.opensuse.org/opensuse-buildservice/2011-04/msg00049.html isn't that enough?
[Bug preprocessor/61371] cpp: Implement -fno-date-time/-freproducible-dates or similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61371 --- Comment #2 from Cristian Rodríguez --- (In reply to Manuel López-Ibáñez from comment #1) > You can simply redefine them in the command-line: > > http://lists.opensuse.org/opensuse-buildservice/2011-04/msg00049.html > > isn't that enough? It would be.. if there wasn't half a ton of packages using -Werror
[Bug preprocessor/61371] cpp: Implement -fno-date-time/-freproducible-dates or similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61371 --- Comment #3 from Andrew Pinski --- Why don't you poision the use of __DATE__ and __TIME__ in a header file that you -include to force people not to use use those macros which allows you to audit the packages in one go.
[Bug preprocessor/61371] cpp: Implement -fno-date-time/-freproducible-dates or similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61371 --- Comment #4 from Manuel López-Ibáñez --- Also, there was this patch, but I am not sure it was ever committed: https://gcc.gnu.org/ml/gcc-patches/2008-07/msg02321.html
[Bug preprocessor/61371] cpp: Implement -fno-date-time/-freproducible-dates or similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61371 --- Comment #5 from Manuel López-Ibáñez --- (In reply to Cristian Rodríguez from comment #2) > It would be.. if there wasn't half a ton of packages using -Werror In fact, it was committed and the message tells you which option you have to use to silence the warning: manuel@gcc10:~$ ~/test1/210581/build/gcc/cc1 -D__DATE__='bla' test.c -Werror :0:0: error: "__DATE__" redefined [-Werror=builtin-macro-redefined] manuel@gcc10:~$ ~/test1/210581/build/gcc/cc1 -D__DATE__='bla' test.c -Werror -Wno-error=builtin-macro-redefined :0:0: warning: "__DATE__" redefined [-Wbuiltin-macro-redefined] manuel@gcc10:~$ ~/test1/210581/build/gcc/cc1 -D__DATE__='bla' test.c -Werror -Wno-builtin-macro-redefined Isn't this what you want?
[Bug preprocessor/61371] cpp: Implement -fno-date-time/-freproducible-dates or similar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61371 --- Comment #6 from Cristian Rodríguez --- (In reply to Manuel López-Ibáñez from comment #5) > (In reply to Cristian Rodríguez from comment #2) > > It would be.. if there wasn't half a ton of packages using -Werror > > In fact, it was committed and the message tells you which option you have to > use to silence the warning: > > manuel@gcc10:~$ ~/test1/210581/build/gcc/cc1 -D__DATE__='bla' test.c -Werror > :0:0: error: "__DATE__" redefined > [-Werror=builtin-macro-redefined] > > manuel@gcc10:~$ ~/test1/210581/build/gcc/cc1 -D__DATE__='bla' test.c -Werror > -Wno-error=builtin-macro-redefined > :0:0: warning: "__DATE__" redefined [-Wbuiltin-macro-redefined] > > manuel@gcc10:~$ ~/test1/210581/build/gcc/cc1 -D__DATE__='bla' test.c -Werror > -Wno-builtin-macro-redefined > > > Isn't this what you want? -Wno-builtin-macro-redefined silences redefinitions of __FILE__, and __BASE_FILE__..
[Bug c++/61368] Sfinae with template member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61368 --- Comment #1 from Piotr Bartosiewicz --- template static true_type test(decltype(std::declval().template visit(std::declval()))*); This fixes the problem, but still don't know whether gcc or clang is wrong about the original code.
[Bug c++/61372] New: Add warning to detect noexcept functions that might throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372
Bug ID: 61372
Summary: Add warning to detect noexcept functions that might
throw
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: scovich at gmail dot com
The C++11 standard adds the "noexcept" specification that lets the programmer
assert that a function does not throw any exceptions (terminating execution if
that assertion ever turns out to be false at runtime).
Unfortunately, there is currently no reliable way for a programmer to validate,
at compile time, her assertion that a function does or does not throw.
The closest thing is -Wnoexcept, which detects the (very narrow) case where the
following all apply to some function F:
1. F lacks the noexcept declaration or has declared noexcept(false)
2. The compiler has determined that F cannot throw
3. F causes some noexcept operator to evaluate to false
Unfortunately, that narrow formulation makes it really hard to validate much of
anything (see example and further discussion below).
It would be very helpful to have a warning flag which tells the compiler to
report cases where a function's noexcept specification contradicts the
compiler's analysis of the function body. Perhaps -Wnoexcept-mismatch={1,2,3}?
1 (high priority): functions declared noexcept(true) but which contain
expressions that might throw. This validates stated noexcept assumptions,
helping to avoid issues like PR #56166.
2 (medium priority): Also report functions declared noexcept(false) that in
fact cannot throw (e.g. cases #1 and #2 for -Wnoexcept). This improves the
accuracy of noexcept validation, and also improves performance in general (by
eliminating unwind handlers). And makes it easier to avoid/fix things like PR
#52562.
3 (low priority): Also report functions which lack any noexcept declaration but
which cannot throw (similar to -Wsuggest-attribute for const, pure, etc.). This
also improves accuracy of noexcept, but the programmer would have to decide
whether to make the API change (marking the function noexcept) or whether it's
important to retain the ability to throw in the future.
Probably none of the above warnings should be enabled by default, but it might
make sense to enable -Wnoexcept-mismatch=1 with -Wall and -Wnoexcept-mismatch=2
with -Wextra.
To implement the warning, the compiler would make a pass over each function
body (after applying most optimizations, especially inlining and dead code
elimination). It would then infer a noexcept value by examining all function
calls that remain, and compare that result with the function's actual noexcept
specification (or lack thereof). No need for any kind of IPA: if a callee lies
about its noexcept status, it's the callee's problem.
===
Workaround using -Wnoexcept
===
One might try to combine static_assert with noexcept, e.g:
// example.cpp
void might_throw(int); // lacks noexcept
void also_might_throw(); // lacks noexcept
void never_throw(int a) noexcept(noexcept(might_throw(a)) &&
noexcept(also_might_throw())) {
if (a)
might_throw(a);
also_might_throw();
}
void foo(int a) noexcept(noexcept(might_throw(a))) {
might_throw(a);
}
static_assert(noexcept(foo(0)), "never_throw might throw");
There are two glaring problems with that approach, however:
1. Every expression in the function body must be part of the noexcept clause,
effectively replicating the function body in its signature (but without the
ability to declare local variables).
- Maintaining the noexcept chain across code changes would be tedious and
error-prone for all but the smallest and most stable functions (= ie the ones
least in need of verification).
- Operator overloading means you can't even assume basic expressions like
a+b are nothrow. To get complete coverage would require either a very careful
analysis (error prone) or cracking the entire function body into an AST atomic
expressions (tedious *and* error prone).
- Macro expansions would add even more headaches, because they may expand to
more than one statement and/or include control flow.
2. The static_assert must choose one set of inputs for each function call it
passes to operator noexcept.
- An optimizer (especially after inlining and constant propagation) could
conceivably report that the function is noexcept for that particular input,
when in fact other inputs exist that could cause an exception to be thrown
(this does not seem to be the case currently).
- There may not be any easy way to come up with a valid input (objects that
lack a default constructor, etc.). Using hacks like (*(T*)0) would violate all
sorts of compiler/optimizer assumptions and risks breaking the analysis.
[Bug target/61296] Excessive alignment in ix86_data_alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #2 from H.J. Lu --- After r199898, DATA_ALIGNMENT is only for optimization purposes. Align struct >= 64 bytes to 64 bytes may increase data size due to excessive alignment.
[Bug libstdc++/61011] libstdc++-v3 should be target-libstdc++-v3 in top level configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61011 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Fri May 30 17:16:14 2014 New Revision: 211087 URL: http://gcc.gnu.org/viewcvs?rev=211087&root=gcc&view=rev Log: PR libstdc++/61011 * configure.ac (--disable-libstdcxx): Set noconfigdirs correctly. Disable libcilkrts, libitm, libsanitizer when not building libstdc++. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac
[Bug libstdc++/61011] libstdc++-v3 should be target-libstdc++-v3 in top level configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61011 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #3 from Jonathan Wakely --- Fixed on trunk - thanks for the report.
[Bug target/60104] load not folded into indirect branch on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60104 --- Comment #1 from Kai Tietz --- Author: ktietz Date: Fri May 30 18:00:11 2014 New Revision: 211089 URL: http://gcc.gnu.org/viewcvs?rev=211089&root=gcc&view=rev Log: PR target/60104 * config/i386/i386.c (x86_output_mi_thunk): Add memory case for sibling-tail-calls. * config/i386/i386.md (sibcall_insn_operand): Add memory-constrain to its use. * config/i386/predicates.md (sibcall_memory_operand): New predicate. (sibcall_insn_operand): Add check for sibcall_memory_operand. PR target/60104 * gcc.target/i386/sibcall-1.c: New test. * gcc.target/i386/sibcall-2.c: New test. * gcc.target/i386/sibcall-3.c: New test. * gcc.target/i386/sibcall-4.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/sibcall-1.c trunk/gcc/testsuite/gcc.target/i386/sibcall-2.c trunk/gcc/testsuite/gcc.target/i386/sibcall-3.c trunk/gcc/testsuite/gcc.target/i386/sibcall-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/predicates.md
[Bug c++/56947] [4.7 Regression] Bogus 'XX' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56947 --- Comment #5 from Jason Merrill --- Author: jason Date: Fri May 30 18:55:56 2014 New Revision: 211094 URL: http://gcc.gnu.org/viewcvs?rev=211094&root=gcc&view=rev Log: PR c++/56947 * pt.c (instantiate_decl): Check that defer_ok is not set for local class members. Added: trunk/gcc/testsuite/g++.dg/template/local8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/36183] misleading error message with explicit copy constructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36183 --- Comment #2 from Jason Merrill --- Sounds good. We'd probably get that by changing add_candidates to mark an explicit candidate as bad rather than non-viable, and then adding the explanation to convert_like_real.
[Bug c++/52026] [4.6/4.7/4.8 Regression] Constexpr Variable Appears Uninitialized in Lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52026 Bug 52026 depends on bug 56947, which changed state. Bug 56947 Summary: [4.7 Regression] Bogus 'XX' was not declared in this scope https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56947 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/56947] [4.7 Regression] Bogus 'XX' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56947 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed for 4.7.4.
[Bug c++/61370] decltype, enable_if, previous arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61370 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-30 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- That code causes an ICE on trunk: /var/tmp/bug_report.cpp:39:60: internal compiler error: canonical types differ for identical types eif::value> and eif::value> typename eif::value>::type * ) ^ 0x699b99 comptypes /home/jwakely/src/gcc/gcc/gcc/cp/typeck.c:1403 0x6980cd structural_comptypes /home/jwakely/src/gcc/gcc/gcc/cp/typeck.c:1319 0x697bbc structural_comptypes /home/jwakely/src/gcc/gcc/gcc/cp/typeck.c:1337 0x69d243 compparms(tree_node const*, tree_node const*) /home/jwakely/src/gcc/gcc/gcc/cp/typeck.c:1514 0x63331a check_classfn(tree_node*, tree_node*, tree_node*) /home/jwakely/src/gcc/gcc/gcc/cp/decl2.c:705 0x4fccc0 grokfndecl /home/jwakely/src/gcc/gcc/gcc/cp/decl.c:7810 0x59a012 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*, decl_context, int, tree_node**) /home/jwakely/src/gcc/gcc/gcc/cp/decl.c:10823 0x59ae36 start_function(cp_decl_specifier_seq*, cp_declarator const*, tree_node*) /home/jwakely/src/gcc/gcc/gcc/cp/decl.c:13519 0x67f46f cp_parser_function_definition_from_specifiers_and_declarator /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:22802 0x67f46f cp_parser_init_declarator /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:16646 0x681044 cp_parser_single_declaration /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:23254 0x6823a0 cp_parser_template_declaration_after_export /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:23056 0x68cdf9 cp_parser_declaration /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:10991 0x68b98d cp_parser_declaration_seq_opt /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:10913 0x68d1f3 cp_parser_translation_unit /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:4040 0x68d1f3 c_parse_file() /home/jwakely/src/gcc/gcc/gcc/cp/parser.c:31698 0x7b8164 c_common_parse_file() /home/jwakely/src/gcc/gcc/gcc/c-family/c-opts.c:1067
[Bug c++/61368] Sfinae with template member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61368 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-30 Ever confirmed|0 |1
[Bug c++/61370] decltype, enable_if, previous arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61370 --- Comment #2 from Paolo Carlini --- Seems closely related to c++/58230
[Bug c++/61370] decltype, enable_if, previous arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61370 --- Comment #3 from Paolo Carlini --- I meant c++/52830
[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 #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #1 from Richard Biener --- >> gcc/java/jcf.h:#define GET_u2(PTR) (((PTR)[0] << 8) | ((PTR)[1])) >> >> smells like >> >> 2014-05-23 Thomas Preud'homme >> >> PR tree-optimization/54733 >> * tree-ssa-math-opts.c (nop_stats): New "bswap_stats" structure. >> ... > > I've now confirmed that this patch is indeed the culprit. Thomas, any progress on fixing this regression? SPARC bootstrap is broken for a week now. Thanks. Rainer
[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 --- Comment #31 from Andrew Pinski --- I cannot reproduce the original bug with the patch in comment #26 reverted.
[Bug c++/52830] ICE: "canonical types differ for identity types ..." when attempting SFINAE with member type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52830 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-30 Ever confirmed|0 |1
[Bug ipa/61190] [4.8/4.9/4.10 Regression] g++.old-deja/g++.mike/p4736b.C FAILs at -O2/-Os/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61190 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #1 from Bernd Edlinger --- Created attachment 32879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32879&action=edit slightly reduced test case Acutally also -O1 produces wrong code, and happens to not crash by chance. Only -O0 and -Og produce correct code. The constructor Main::Main() first inlined and then completely optimized away in the dce1 pass. But even with -fno-tree-dce the constructor seems to be removed in the rtl passes. However when I use -fno-ipa-pure-const the sample works at all optimization levels. So should we blame "ipa-pure-const"?
[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 --- Comment #32 from H.J. Lu --- (In reply to Andrew Pinski from comment #31) > I cannot reproduce the original bug with the patch in comment #26 reverted. The original bug only happened with -maddress-mode=long and it may become latent due to other middle-end changes.
[Bug c/61373] New: neon registers restored incorrectly with -mapcs-frame -O -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61373
Bug ID: 61373
Summary: neon registers restored incorrectly with -mapcs-frame
-O -fno-omit-frame-pointer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: breiten at lexmark dot com
The attached file is a preprocessed and stripped version of:
http://cgit.freedesktop.org/systemd/systemd/plain/src/shared/siphash24.c
When compiled with -O -march=armv7-a -mfpu=neon -mapcs-frame
-fno-omit-frame-pointer, the neon registers are restored incorrectly. The are
stored to the stack with:
fstmfddsp!, {d8, d9, d10, d11}
fstmfddsp!, {d14}
but restored [out of order] with:
fldmfddip!, {d8-d11}
fldmfddip!, {d14}
This does not occur at -O0 or -O2 or without -mapcs-frame.
With -fno-omit-frame-pointer removed, the two fldmfdd instructions are swapped
and appear correct. This occurs on both 4.8.1 (as patched by poky-1.5) and
4.8.3.
Here's my gcc version:
Using built-in specs.
COLLECT_GCC=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.3/lto-wrapper
Target: arm-poky-linux-gnueabi
Configured with:
/bonus/scratch/gcc483/poky/myproject/tmp/work-shared/gcc-4.8.3-r0/gcc-4.8.3/configure
--build=x86_64-linux --host=x86_64-linux --target=arm-poky-linux-gnueabi
--prefix=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr
--exec_prefix=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr
--bindir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi
--sbindir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi
--libexecdir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi
--datadir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr/share
--sysconfdir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/etc
--sharedstatedir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/com
--localstatedir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/var
--libdir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr/lib/armv7a-vfp-neon-poky-linux-gnueabi
--includedir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr/include
--oldincludedir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr/include
--infodir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr/share/info
--mandir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux
--enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++
--enable-threads=posix --disable-multilib --enable-c99 --enable-long-long
--enable-symvers=gnu --enable-libstdcxx-pch
--program-prefix=arm-poky-linux-gnueabi- --without-local-prefix
--enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap
--disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu
--enable-linker-build-id --with-ppl=no --with-cloog=no
--enable-checking=release --enable-cheaders=c_global
--with-gxx-include-dir=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/myarmcpu/usr/include/c++
--with-sysroot=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/myarmcpu
--with-build-sysroot=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/myarmcpu
--enable-poison-system-directories --disable-libunwind-exceptions
--with-mpfr=/bonus/scratch/gcc483/poky/myproject/tmp/sysroots/x86_64-linux/usr
--with-system-zlib --disable-nls
Thread model: posix
gcc version 4.8.3 (GCC)
[Bug middle-end/61354] GCC bootstrap with LTO fails in trunk when built with isl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61354 Venkataramanan changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #3 from Venkataramanan --- I am closing this PR since it seems to be problem with ISL code. The bug occurs while building stage 1 "cc1" via link time optimizer "lto1" and now compiler is detecting uninitialized code in ISL. During bootstrap compiler treats all warnings as errors.
[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 --- Comment #33 from Andrew Pinski --- *** Bug 55142 has been marked as a duplicate of this bug. ***
[Bug middle-end/55142] [4.8 Regression] internal compiler error: in plus_constant, at explow.c:88
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55142 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #40 from Andrew Pinski --- Dup of bug 49721 really. *** This bug has been marked as a duplicate of bug 49721 ***
[Bug ipa/61211] [4.9/4.10 Regression] ICE: verify_cgraph_node failed: edge points to wrong declaration with -O3 -fno-inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61211 --- Comment #2 from Martin Jambor --- I have proposed a patch to address this in the mailing list: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02656.html
[Bug middle-end/49721] convert_memory_address_addr_space may generate invalid new insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-30 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #34 from Andrew Pinski --- I have a correct fix (tested by backing all the way to the old code and testing there). The only time this transformation is safe is inside a CONST rtl. This fixes both this one and does not cause the regression that was bug 55142. We also produce better code for -maddress-mode=long for x32 too.
[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 #4 from Martin Jambor --- These are in fact two different issues. I proposed the following to patches on the mailing list to address them: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02658.html and https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02660.html
[Bug libstdc++/61374] New: string_view::operator string() is buggy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61374
Bug ID: 61374
Summary: string_view::operator string() is buggy
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: john.salmon at deshaw dot com
The problem is the string(length, c) constructor on line 255 of string_view.
The begin/end constructor is what's needed. Here's a quick demonstration.
drdlogin0039$ cat bug.cpp
#include
#include
std::experimental::string_view sv("hello world");
std::string s {sv};
drdlogin0039$
drdlogin0039$
drdlogin0039$ dw -m gcc/4.9.0-28B/bin g++ -std=c++1y bug.cpp
In file included from bug.cpp:1:0:
/aprj/desrad-c/root/Linux/x86_64/gcc/4.9.0-28B/include/c++/4.9.0/experimental/string_view:
In instantiation of 'std::experimental::basic_string_view<_CharT,
_Traits>::operator std::basic_string<_CharT, _Traits, _Allocator>() const [with
_Allocator = std::allocator; _CharT = char; _Traits =
std::char_traits]':
bug.cpp:5:18: required from here
/aprj/desrad-c/root/Linux/x86_64/gcc/4.9.0-28B/include/c++/4.9.0/experimental/string_view:255:33:
error: invalid conversion from 'const char*' to 'char' [-fpermissive]
(this->_M_len, this->_M_str);
^
In file included from
/aprj/desrad-c/root/Linux/x86_64/gcc/4.9.0-28B/include/c++/4.9.0/string:52:0,
from
/aprj/desrad-c/root/Linux/x86_64/gcc/4.9.0-28B/include/c++/4.9.0/experimental/string_view:43,
from bug.cpp:1:
/aprj/desrad-c/root/Linux/x86_64/gcc/4.9.0-28B/include/c++/4.9.0/bits/basic_string.h:502:7:
note: initializing argument 2 of 'std::basic_string<_CharT, _Traits,
_Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::size_type,
_CharT, const _Alloc&) [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator; std::basic_string<_CharT, _Traits,
_Alloc>::size_type = long unsigned int]'
basic_string(size_type __n, _CharT __c, const _Alloc& __a = _Alloc());
^
drdlogin0039$
[Bug tree-optimization/61375] New: ICE in int_cst_value at -O3 in tree-ssa pass when compiling a reference to an __int128 value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61375 Bug ID: 61375 Summary: ICE in int_cst_value at -O3 in tree-ssa pass when compiling a reference to an __int128 value Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: gary at intrepid dot com CC: nenad at intrepid dot com Target: x86_64 Created attachment 32880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32880&action=edit pre-processed "C" source, generates ICE at -O3 in tree-ssa When compiling the attached pre-processed source file at -O3, the following stack trace is generated. $ gcc -O3 -fpreprocessed -c ice-int_cst_value-int128.i ice-int_cst_value-int128.i: In function ‘test15’: ice-int_cst_value-int128.i:442:1: internal compiler error: in int_cst_value, at tree.c:10492 test15 () ^ 0xe3fb99 int_cst_value(tree_node const*) /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree.c:10492 0xd03709 find_bswap_or_nop_1 /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-ssa-math-opts.c:1848 0xd0354c find_bswap_or_nop_1 /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-ssa-math-opts.c:1815 0xd0354c find_bswap_or_nop_1 /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-ssa-math-opts.c:1815 0xd039a9 find_bswap_or_nop_1 /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-ssa-math-opts.c:1916 0xd03f6a find_bswap_or_nop /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-ssa-math-opts.c:2034 0xd04ac3 execute /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/tree-ssa-math-opts.c:2322 The compiler is based on: Last Changed Rev: 211071 Last Changed Date: 2014-05-29 17:17:10 -0700 The test case can likely be reduced. The issue seems to relate to an attempt to simplify an expression that mixes an address and an __int128 value. The ICE triggered here: 10488 unsigned bits = TYPE_PRECISION (TREE_TYPE (x)); 10489 unsigned HOST_WIDE_INT val = TREE_INT_CST_LOW (x); 10490 10491 /* Make sure the sign-extended value will fit in a HOST_WIDE_INT. */ 10492 gcc_assert (cst_and_fits_in_hwi (x)); where 'x' is: constant 0x0f000> and the type is a 128 bit integer: constant 128> unit size constant 16> align 128 symtab 0 alias set -1 canonical type 0x7189fb28 precision 128 min max context pointer_to_this > The gimple statement being simplified looks like this: _15 = array.0_8 & 18446726481523507200 (gdb) p/x 18446726481523507200 $4 = 0xf000
[Bug libstdc++/61374] string_view::operator string() is buggy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61374 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-31 Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- Just swap the 2 arguments line 255.
