[Bug c++/38850] New: Cannot find inline friend function in template class when called from within a template function
Compiling the following program:
template
class Vector2 {
private:
VType c_[2];
public:
typedef Vector2 Self;
Vector2(const VType x, const VType y) {
c_[0] = x;
c_[1] = y;
}
friend inline Self Max(const Self &v1, const Self &v2) {
return Self(v1.c_[0], v1.c_[1]);
}
};
template
Vector2 foo(T x) {
Vector2 y(0,0);
return Max(y, y);
}
int main() {
foo(3);
return 0;
}
gives the following error:
test.cc: In function 'Vector2 foo(T) [with T = int]':
test.cc:25: instantiated from here
test.cc:13: error: no matching function for call to 'Max(Vector2&,
Vector2&)'
When compiled using GCC 4.4.0 trunk. The command line used for the compile is:
g++ -c test.cc
The output of gcc -v is:
Using built-in specs.
Target: i686-unknown-linux-gnu
Configured with: src/configure --disable-nls --enable-threads=posix
--enable-symvers=gnu --enable-__cxa_atexit --enable-c99 --enable-long-long
--with-gnu-as --with-gnu-ld --build=i686-host_pc-linux-gnu
--host=i686-host_pc-linux-gnu
--enable-shared=libgcc,libmudflap,libssp,libstdc++
--enable-languages=c,c++,fortran --with-gmp=/usr/grte/v1
--prefix=/tmp/gcc-4.3.1-glibc-2.3.6-grte/i686-unknown-linux-gnu
--target=i686-unknown-linux-gnu --enable-static-nss --with-arch=pentium3
--with-tune=pentium4
Thread model: posix
gcc version 4.4.0 20090114 (experimental)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=pentium4'
'-march=pentium3'
--
Summary: Cannot find inline friend function in template class
when called from within a template function
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nvachhar at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38850
[Bug c++/38850] Cannot find inline friend function in template class when called from within a template function
--- Comment #1 from nvachhar at google dot com 2009-01-14 20:53 --- Created an attachment (id=17103) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17103&action=view) Test case program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38850
[Bug c++/38851] New: Compiler warns about uninitialized variable that is an object with a constructor
Compiling the following program:
int printf(const char *fmt, ...);
class MyCompare {
public:
MyCompare() { }
bool operator() (const int a, const int b) const {
return a > b;
}
};
template
class Other {
public:
Other (const Comp &c) : c_(c) { }
void* doSomething();
private:
Comp c_;
};
template
void* Other::doSomething() {
return &c_;
}
int main(int argc, char **argv) {
MyCompare c;
Other other(c);
printf("%p\n", other.doSomething());
return 0;
}
yields the following warning:
test.cc: In function 'int main(int, char**)':
test.cc:14: warning: 'c' is used uninitialized in this function
test.cc:27: note: 'c' was declared here
when compiled with the following command line:
g++ -Wall -c -O2 test.cc
However, c is initialized by the no argument constructor (further class
MyCompare does not actually have any member variables to initialize).
--
Summary: Compiler warns about uninitialized variable that is an
object with a constructor
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nvachhar at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851
[Bug c++/38851] Compiler warns about uninitialized variable that is an object with a constructor
--- Comment #1 from nvachhar at google dot com 2009-01-14 21:05 --- Created an attachment (id=17104) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17104&action=view) Test case program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38851
[Bug c++/38850] Cannot find inline friend function in template class when called from within a template function
--- Comment #3 from nvachhar at google dot com 2009-01-14 21:30 --- (In reply to comment #2) > I think this code is invalid as the call to Max is not going to be dependent > as > the arguments are not dependent and can be looked up at the time the function > is defined. > I don't think I follow. While the arguments to Max are not dependent, other code inside of foo could be dependent on T (in the example, no such code exists). Shouldn't the fact that the function can be looked up at definition time make this code legal? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38850
[Bug rtl-optimization/38931] New: Seg fault when getting instruction latency on a *movsi_1 with an MMX target register
Calling insn_default_latency on the following RTL causes the compiler to
segfault.
(insn 75 73 77 2 y.ii:19 (set (reg:SI 30 mm1)
(const_int 0 [0x0])) 41 {*movsi_1} (nil))
The root cause of the problem seems to be in i386.md. Pasted below is a
snippet of the file describing the alternatives for the instruction:
(define_insn "*movsi_1"
[(set (match_operand:SI 0 "nonimmediate_operand"
"=r,m ,*y,*y,?rm,?*y,*x,*x,?r ,m ,?*Yi,*x")
(match_operand:SI 1 "general_operand"
"g ,ri,C ,*y,*y ,rm ,C ,*x,*Yi,*x,r ,m "))]
In this case, alternative 2 is selected (an MMX register destination and a
constant source). Later in the .md file, we see that this causes the
instruction to have attribute "type" equal to "mmxadd"
[(set (attr "type")
(cond [(eq_attr "alternative" "2")
(const_string "mmxadd")
(eq_attr "alternative" "3,4,5")
(const_string "mmxmov")
(eq_attr "alternative" "6")
(const_string "sselog1")
(eq_attr "alternative" "7,8,9,10,11")
(const_string "ssemov")
(match_operand:DI 1 "pic_32bit_operand" "")
(const_string "lea")
]
(const_string "imov")))
Finally, from much earlier in i386.md, there is code to set the attribute
"memory". Here is that code:
(define_attr "memory" "none,load,store,both,unknown"
(cond [(eq_attr "type" "other,multi,str")
(const_string "unknown")
(eq_attr "type" "lea,fcmov,fpspc")
(const_string "none")
(eq_attr "type" "fistp,leave")
(const_string "both")
(eq_attr "type" "frndint")
(const_string "load")
(eq_attr "type" "push")
(if_then_else (match_operand 1 "memory_operand" "")
(const_string "both")
(const_string "store"))
(eq_attr "type" "pop")
(if_then_else (match_operand 0 "memory_operand" "")
(const_string "both")
(const_string "load"))
(eq_attr "type" "setcc")
(if_then_else (match_operand 0 "memory_operand" "")
(const_string "store")
(const_string "none"))
(eq_attr "type" "icmp,test,ssecmp,ssecomi,mmxcmp,fcmp")
(if_then_else (ior (match_operand 0 "memory_operand" "")
(match_operand 1 "memory_operand" ""))
(const_string "load")
(const_string "none"))
(eq_attr "type" "ibr")
(if_then_else (match_operand 0 "memory_operand" "")
(const_string "load")
(const_string "none"))
(eq_attr "type" "call")
(if_then_else (match_operand 0 "constant_call_address_operand" "")
(const_string "none")
(const_string "load"))
(eq_attr "type" "callv")
(if_then_else (match_operand 1 "constant_call_address_operand" "")
(const_string "none")
(const_string "load"))
(and (eq_attr "type" "alu1,negnot,ishift1,sselog1")
(match_operand 1 "memory_operand" ""))
(const_string "both")
(and (match_operand 0 "memory_operand" "")
(match_operand 1 "memory_operand" ""))
(const_string "both")
(match_operand 0 "memory_operand" "")
(const_string "store")
(match_operand 1 "memory_operand" "")
(const_string "load")
(and (eq_attr "type"
"!alu1,negnot,ishift1,
imov,imovx,icmp,test,bitmanip,
fmov,fcmp,fsgn,
sse,ssemov,ssecmp,ssecomi,ssecvt,ssecvt1,sseicvt,sselog1,
sseiadd1,mmx,mmxmov,mmxcmp,mmxcvt")
(match_operand 2 "memory_operand" ""))
(const_string "load")
(and (eq_attr "type" "icmov,ssemuladd,sse4arg")
(match_operand 3 "memory_operand" ""))
(const_string "load")
]
(const_string "none")))
One will notice that none of the patterns match, however, when evaluating the
second to last pattern, it queries operand 2 which does not exist for this RTL
instruction. This directly leads to the segfault.
--
Summary: Seg fault when getting instruction latency on a *movsi_1
with an MMX target register
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nvachhar at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38931
[Bug rtl-optimization/38931] Seg fault when getting instruction latency on a *movsi_1 with an MMX target register
--- Comment #1 from nvachhar at google dot com 2009-01-21 19:02 --- Created an attachment (id=17158) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17158&action=view) Test case to trigger the segfault. To generate the segfault, use the following command line: g++ -mtune=generic -O2 -mfpmath=sse -msse2 y.ii -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38931
[Bug rtl-optimization/40209] New: ICE in iv opts caused by stale REG_UNUSED note
An ICE occurs in iv_analyze_def because the register referred to by a def is
not the same register referred to by the set in an rtx. The rtx in question
actually has multiple set's, but single_set only returns one of them because of
a stale REG_UNUSED note.
The stale REG_UNUSED note is created in gcse. At the beginning of gcse, the
REG_UNUSED note is added (and is correct). At the end of gcse, if expensive
optimizations are on, it will make a call to cse_main which will merge two defs
with the same expression. This makes the REG_UNUSED note stale, however it is
not removed from the operation. Later in iv_analyze_def, the call to
single_set trips over this stale REG_UNUSED note. I have verified that the
problem is resolved if df_analyze (with the notes problem added) corrects the
stale note and avoids the problem. However discussions with Ian suggest that
this might not be the correct approach to fixing the problem, so I'm filing
this bug.
I've attached a test case which will cause the ICE if compiled with the
following command line:
gcc -c -O2 -fprofile-use test.c
Note that no .gcda file is necessary.
--
Summary: ICE in iv opts caused by stale REG_UNUSED note
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nvachhar at google dot com
GCC host triplet: i686-unknown-linux
GCC target triplet: x86_64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
[Bug rtl-optimization/40209] ICE in iv opts caused by stale REG_UNUSED note
--- Comment #1 from nvachhar at google dot com 2009-05-20 18:48 --- Created an attachment (id=17896) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17896&action=view) Test case that causes an ICE Compile with: gcc -c -O2 -Wall -fprofile-use test.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
[Bug rtl-optimization/40209] ICE in iv_analyze_def caused by stale REG_UNUSED note
--- Comment #5 from nvachhar at google dot com 2009-07-24 15:39 --- Subject: Re: ICE in iv_analyze_def caused by stale REG_UNUSED note loop-iv does need notes, albeit indirectly through the single_set function. single_set looks at the REG_UNUSED note, and if all but one set have that note on it, then it asserts that a parallel set is a single set. I do agree that this problem is pervasive through gcc. Any pass that uses single_set is implicitly a user of reg ntoes. On Thu, Jul 23, 2009 at 11:27 PM, steven at gcc dot gnu dot org wrote: > > > --- Comment #4 from steven at gcc dot gnu dot org 2009-07-24 06:27 > --- > A hint, please, about why the patch of comment #2 would be the correct fix. > As > far as I can tell, loop-iv doesn't need the notes and shouldn't have to clean > up other passes' mess. This patch also introduces a pass ordering restriction > that shouldn't be there. And at the very least, if this bug gets papered over > like this, then there should be a comment in loop-iv that the problem is only > added to fix bugs elsewhere... > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
[Bug rtl-optimization/40209] ICE in iv_analyze_def caused by stale REG_UNUSED note
--- Comment #7 from nvachhar at google dot com 2009-07-24 17:47 ---
Subject: Re: ICE in iv_analyze_def caused by
stale REG_UNUSED note
This looks reasonable to me. Given the caveats you mention in the
comment, this would need to be tested for correctness (esp. w.r.t. the
newly added registers) and obviously would need to be tested for
performance regressions.
On Fri, Jul 24, 2009 at 5:04 PM, steven at gcc dot gnu dot
org wrote:
>
>
> --- Comment #6 from steven at gcc dot gnu dot org 2009-07-24 17:04
> ---
> Then we should write a new function, something like this in df.h perhaps:
>
> /* Given an INSN, return a SET expression if the insn has only one
> SET whose SET_DEST is used. If SET_DEST is memory, then the SET is
> assumed to be used somewhere, always.
>
> This means that:
> * If an insn has multiple SETs to only registers, but only one of those
> SETs is used, return that one set.
> * If an insn has multiple SETs to only registers, but none one of those
> SETs is used, return NULL_RTX.
> * If an insn has multiple SETs to registers and/or memory, but the SETs to
> registers are dead, return the one memory SET, or NULL_RTX if there are
> multiple sets to memory.
>
> Only accept INSNs. single_set() can take a pattern, but that is
> "old skool" style that should be abolished.
>
> May miss some single_set SETs that single_set() can find, because this
> function just looks for the number of uses of a register to determine
> whether a set is used (which may fail for hard registers and for unusual
> situations with pseudos that somehow are set twice but never used) whereas
> single_set() uses liveness information through REG_UNUSED notes. Still,
> I expect that, in practice, this function works just as well as
> single_set().
>
> One more caveat: The DF user must use incremental scanning, or the
> DF_REG_USE_COUNT may be wrong. The result of df_single_set would be
> unconservative for new registers since the last scan (DF_REG_USE_COUNT
> will still be 0, indicating the new reg is unused and its SET can be
> ignored). */
>
> rtx
> df_single_set (rtx insn)
> {
> rtx pat;
>
> gcc_assert (INSN_P (insn));
>
> /* ??? Could even just fall back if the current DF mode is not incremental
> scanning. */
> pat = PATTERN (insn);
> if (GET_CODE (pat) == SET)
> return pat;
> else if (GET_CODE (pat) == PARALLEL)
> {
> int i;
> rtx set = NULL_RTX;
> for (i = 0; i < XVECLEN (pat, 0); i++)
> {
> rtx sub = XVECEXP (pat, 0, i);
> switch (GET_CODE (sub))
> {
> case USE:
> case CLOBBER:
> break;
>
> case SET:
> if (! set)
> {
> rtx dest = SET_DEST (set);
> if (GET_CODE (dest) == SUBREG)
> dest = SUBREG_REG (dest);
> if (! REG_P (dest)
> || DF_REG_USE_COUNT (dest) > 0)
> set = sub;
> }
> else
> return NULL_RTX;
> break;
>
> default:
> return NULL_RTX;
> }
> }
> }
> else
> return NULL_RTX;
> }
>
>
> --
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
>
> --- You are receiving this mail because: ---
> You reported the bug, or are watching the reporter.
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40209
[Bug preprocessor/41632] New: The preprocessor incorrectly reports #ident as being deprecated
See http://gcc.gnu.org/ml/gcc/2009-10/msg00071.html -- Summary: The preprocessor incorrectly reports #ident as being deprecated Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nvachhar at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41632
[Bug preprocessor/41632] The preprocessor incorrectly reports #ident as being deprecated
--- Comment #1 from nvachhar at google dot com 2009-10-10 00:36 --- Author: nvachhar Date: Sat Oct 10 00:34:21 2009 New Revision: 152612 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152612 Log: 2009-10-09 Neil Vachharajani * libcpp/directives.c (DIRECTIVE_TABLE): Remove DEPRECATED from ident and sccs. * gcc/doc/cpp.texi (Other Directives): Do not list #ident and #sccs as deprecated. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/cpp.texi trunk/libcpp/ChangeLog trunk/libcpp/directives.c -- nvachhar at google dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41632
[Bug c++/58377] spurious "may be used uninitialized" warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377 Neil Vachharajani changed: What|Removed |Added CC||nvachhar at google dot com --- Comment #7 from Neil Vachharajani --- It seems like the whole problem is that the loop early exit goes through bb_6 which is the same path the back-edge goes through.
