[Bug c++/47488] sorry, unimplemented: string literal in function template signature
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47488 Jeremiah Willcock jewillco at osl dot iu.edu changed: What|Removed |Added CC||jewillco at osl dot iu.edu --- Comment #11 from Jeremiah Willcock jewillco at osl dot iu.edu --- This problem still exists as of GCC 4.9.0 snapshot 20131013, with the same test case failing.
[Bug c++/57528] New: Missed warning for putting reference to temporary in class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57528
Bug ID: 57528
Summary: Missed warning for putting reference to temporary in
class member
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jewillco at osl dot iu.edu
It would be nice to have a warning on code such as:
struct b {
const int r;
b(int r): r(r) {}
};
that is almost certainly unintended since it always binds a reference to a
temporary in a case where the reference outlives the temporary. g++ (GCC)
4.9.0 20130519 (experimental) does not warn on this code with -Wall -Wextra,
whether with -O2 or without. Uses of the struct b (including with a literal
number as constructor argument) do not produce warnings either.
[Bug middle-end/57529] New: Redundant masking of zero-extended values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57529
Bug ID: 57529
Summary: Redundant masking of zero-extended values
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jewillco at osl dot iu.edu
Using version gcc (GCC) 4.9.0 20130519 (experimental) with target
x86_64-unknown-linux-gnu and the flags -Ofast -std=gnu99 -march=bdver1, the
following code:
#include stdint.h
void foo(const uint16_t* restrict indexes, const uint64_t* restrict bits,
unsigned int* restrict sum, int count) {
for (int i = 0; i count; ++i) {
unsigned int val = indexes[i];
if (bits[val / 64] (1UL (val % 64))) {sum[val] += 1;}
}
}
produces two shifts to implement the val / 64 operation instead of one,
seemingly because the compiler is trying to mask val to 16 bits even though it
was loaded with movzwl and thus was already masked and zero-extended. Here is
the assembly for the function body:
testl %ecx, %ecx # count
movl%ecx, %r9d # count, count
jle .L8 #,
xorl%eax, %eax # ivtmp.5
.p2align 4,,10
.p2align 3
.L4:
movzwl (%rdi,%rax,2), %ecx # MEM[base: indexes_8(D), index:
ivtmp.5_52, step: 2, offset: 0B], D.2242
movq%rcx, %r8 # D.2242, D.2244
# Redundant masking operation:
salq$48, %r8#, D.2244
shrq$54, %r8#, D.2244
#
movq(%rsi,%r8,8), %r8 # *_16, D.2244
#
shrq%cl, %r8# D.2242, D.2244
andl$1, %r8d#, D.2244
#
je .L3 #,
#
movzwl %cx, %r8d # D.2242, D.2244
#
incl(%rdx,%r8,4)# *_25
.L3:
incq%rax# ivtmp.5
cmpl%eax, %r9d # ivtmp.5, count
jg .L4 #,
.L8:
rep; ret
The seemingly-unnecessary operation is marked with stars; a single shrq by 6
should do the unsigned division operation correctly, while two instructions are
used to both mask the value to 16 bits and shift it. The zero-extension inside
x's is also unnecessary (%rcx could have been used directly in the index
expression). On a somewhat unrelated issue, the code marked in +'s seems to be
sub-optimal as well, and could probably be replaced by a bt instruction (GCC
4.4.7 uses btq there using -O3 and the same -march flag).
[Bug tree-optimization/57380] New: GCC 4.9.0 will not vectorize std::max and similar functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57380
Bug ID: 57380
Summary: GCC 4.9.0 will not vectorize std::max and similar
functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jewillco at osl dot iu.edu
It appears that having a function that returns a const reference to one of its
arguments causes vectorization of calls to that function to fail. Here is a
simple test program:
struct my_array {
int data[4] __attribute__((aligned(16)));
};
const int my_max(const int a, const int b) {
return a b ? b : a;
}
int f(my_array a, my_array b) {
int res = 0;
for (int i = 0; i 4; ++i) {
res += my_max(a.data[i], b.data[i]);
}
return res;
}
The signature of my_max is a specialization of the one of std::max; std::max
itself has similar problems. The loop will vectorize without trouble if my_max
returns int. The main errors from the vectorization report seem to be:
vec_min_max.cpp:11: note: not vectorized: not suitable for gather load _6 =
*iftmp.0_12;
vec_min_max.cpp:11: note: bad data references.
Other variants of the code get control flow in loop instead. The flags I am
using are:
-ftree-vectorizer-verbose=4 -Ofast -march=nocona
but the code should be able to vectorize under SSE2. The GCC version I am
using is g++ (GCC) 4.9.0 20130519 (experimental) on x86-64. GCC 4.7.2 has a
similar error, while 4.4.7 20120313 (Red Hat 4.4.7-3) can vectorize it
without problems.
[Bug tree-optimization/57380] GCC 4.9.0 will not vectorize std::max and similar functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57380 --- Comment #1 from Jeremiah Willcock jewillco at osl dot iu.edu --- I tested version (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 and that fails as well (with note: not vectorized: data ref analysis failed D.2097_9 = *D.2115_16; in the vectorization report).
[Bug c++/53845] Another error reporting routines re-entered issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53845 --- Comment #4 from Jeremiah Willcock jewillco at osl dot iu.edu 2012-10-04 15:43:30 UTC --- I don't know whether it is valid or not after all of the trimming I did on it.
[Bug c++/54379] New: Suggestion for type attribute similar to warn_unused_result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54379 Bug #: 54379 Summary: Suggestion for type attribute similar to warn_unused_result Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jewil...@osl.iu.edu I think it would be useful to extend GCC with an attribute similar to `warn_unused_result` but applying to a user-defined type rather than just a single function. The effect would be that all expressions (variable references, function calls, etc.) that return some object of that type would warn if their results were unused. The intended use case is for C++ patterns such as expression templates in which purely-functional code builds up an expression tree which does not make sense to discard; in some cases, operator= would just add to the expression tree as well, leading to a source of bugs. This would probably require the kind of cast-to-void override mechanism that PR 25509 is about, since these annotations would strictly be recommendations.
[Bug c++/53845] New: Another error reporting routines re-entered issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53845
Bug #: 53845
Summary: Another error reporting routines re-entered issue
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jewil...@osl.iu.edu
This example causes Error reporting routines re-entered, and seems to be
different from those reported so far:
struct a {};
templatetypename struct b;
template struct ba {static const int v = 3;};
template typename L
struct c {
static_assert(bL::v == 3, );
using t = int;
};
template typename E, typename T
auto d(T x) - decltype(((x.template eE( {return ((x.template eE()));}
template typename B
struct f {
template typename E
struct h {
using w = int;
typename cE::t x;
};
template typename E
decltype(dtypename hE::w(*(B*)nullptr)) e();
};
struct g {
template typename int e();
};
int main(int argc, char** argv) {
da(fg{});
return 0;
}
It is probably invalid code. Some small variations on it cause infinite loops
(recursion depth exceeded), which also seem to be incorrect. The full error
message for the code above with 4.7.1 is:
‘
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/52859] New: ICE (Error reporting routines re-entered) on highly recursive template code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52859 Bug #: 52859 Summary: ICE (Error reporting routines re-entered) on highly recursive template code Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jewil...@osl.iu.edu Created attachment 27083 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27083 Semi-trimmed test program I am not sure whether this program is valid C++11 or not, but it causes the error: ‘ Internal compiler error: Error reporting routines re-entered. Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (backquote in original error message; turns into a normal single quote in the C locale). If line 180 (marked with asterisks) is commented out, the compiler goes into an infinite loop of template instantiations, stopped by the depth limit; other seemingly meaningless changes cause the same result. Because of the use of std::tuple, I was not able to trim the code to something tiny; note that I simplified the parts of the code that came from the standard library as well.
[Bug c++/52816] New: Access to private members inside decltype in the signature of a member template causes access control error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52816
Bug #: 52816
Summary: Access to private members inside decltype in the
signature of a member template causes access control
error
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jewil...@osl.iu.edu
When using decltype inside the return type of a member function template, I
receive access control errors for references to private member variables. Here
is a simple example of a failing program:
class c {
int f;
public:
template typename A
decltype(f) m(A) const;
};
decltype(c{}.m(0)) i;
The use of old- vs. new-style function declarations does not change the
behavior; neither does whether the class itself is a template. The error I get
from GCC 4.7.0 is:
test.cpp:2:7: error: ‘int c::f’ is private
test.cpp:8:20: error: within this context
I think that is likely to be incorrect since the reference to f is from inside
the body of the class definition itself.
[Bug libstdc++/50159] New: tuple_cat only accepts two arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50159 Bug #: 50159 Summary: tuple_cat only accepts two arguments Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jewil...@osl.iu.edu The tuple_cat function in tuple (in C++0x) is documented in the FDIS as taking any number of parameters, while the libstdc++ version accepts exactly two.
