[Bug c++/58377] spurious may be used uninitialized warning with -Og
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58377 Neil Vachharajani nvachhar at google dot com changed: What|Removed |Added CC||nvachhar at google dot com --- Comment #7 from Neil Vachharajani nvachhar at google dot com --- 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.
[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=gccview=revrev=152612 Log: 2009-10-09 Neil Vachharajani nvach...@google.com * 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 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 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 orggcc-bugzi...@gcc.gnu.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
orggcc-bugzi...@gcc.gnu.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 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=17896action=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/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=17158action=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 c++/38850] New: Cannot find inline friend function in template class when called from within a template function
Compiling the following program:
template typename VType
class Vector2 {
private:
VType c_[2];
public:
typedef Vector2VType 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 class T
Vector2float foo(T x) {
Vector2float y(0,0);
return Max(y, y);
}
int main() {
foo(3);
return 0;
}
gives the following error:
test.cc: In function 'Vector2float foo(T) [with T = int]':
test.cc:25: instantiated from here
test.cc:13: error: no matching function for call to 'Max(Vector2float,
Vector2float)'
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=17103action=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;
}
};
templateclass Comp
class Other {
public:
Other (const Comp c) : c_(c) { }
void* doSomething();
private:
Comp c_;
};
templateclass Comp
void* OtherComp::doSomething() {
return c_;
}
int main(int argc, char **argv) {
MyCompare c;
OtherMyCompare 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=17104action=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
