[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319 Jackie Rosen jackie.rosen at hushmail dot com changed: What|Removed |Added CC||jackie.rosen at hushmail dot com --- Comment #35 from Jackie Rosen jackie.rosen at hushmail dot com --- *** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Marked for reference. Resolved as fixed @bugzilla.
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #34 from f dot knauf at mmkf dot de 2009-05-07 16:30 --- I can confirm the behaviour for sparc-sun-solaris2.8, the first program mentioned in the last comment complains as follows: *** mudflap violation 1 (check/write): time=1241712982.495997 ptr=ffbefac4 size=4 pc=ff288ac8 location=`/usr/local/lib/gcc/sparc-sun-solaris2.8/4.4.0/../../../../sparc-sun-solaris2.8/include/c++/4.4.0/bits/stl_tree.h:171:20 (std::_Rb_tree_iteratorstd::pairconst int, int ::_Rb_tree_iterator)' [0xff2876f0] Nearby object 1: checked region begins 1B after and ends 4B after mudflap object af548: name=`/usr/local/lib/gcc/sparc-sun-solaris2.8/4.4.0/../../../../sparc-sun-solaris2.8/include/c++/4.4.0/bits/stl_map.h:539:23 (std::mapint, int, std::lessint, std::allocatorstd::pairconst int, int ::insert) std::_Rb_tree_iteratorstd::pairconst int, int __position' bounds=[ffbefac0,ffbefac3] size=4 area=stack check=1r/0w liveness=1 alloc time=1241712982.495900 pc=ff2881a4 Nearby object 2: checked region begins 4B before and ends 1B before mudflap object af440: name=`/usr/local/lib/gcc/sparc-sun-solaris2.8/4.4.0/../../../../sparc-sun-solaris2.8/include/c++/4.4.0/bits/stl_map.h:447:11 (std::mapint, int, std::lessint, std::allocatorstd::pairconst int, int ::operator[]) std::_Rb_tree_iteratorstd::pairconst int, int __i' bounds=[ffbefac8,ffbefacb] size=4 area=stack check=0r/1w liveness=1 alloc time=1241712982.495875 pc=ff2881a4 Nearby object 3: checked region begins 4B before and ends 1B before mudflap dead object adc00: name=`/usr/local/lib/gcc/sparc-sun-solaris2.8/4.4.0/../../../../sparc-sun-solaris2.8/include/c++/4.4.0/bits/stl_map.h:447:11 (std::mapint, int, std::lessint, std::allocatorstd::pairconst int, int ::operator[]) std::_Rb_tree_iteratorstd::pairconst int, int __i' bounds=[ffbefac8,ffbefacb] size=4 area=stack check=0r/1w liveness=1 alloc time=1241712982.495593 pc=ff2881a4 dealloc time=1241712982.495861 pc=ff287d58 number of nearby objects: 3 I compiled it with a gcc 4.4.0 cross compiler from i486-linux-gnu to sparc-sun-solaris2.8 (sparcv8), compiler options -fmudflap -lmudflap -lsocket (the last one being necessary to link mudflap). I had to remove the getmntent wrapper from the mudflap library because solaris 2.8 uses an interface different from the one gcc expects. Other than that, the gcc sources the compiler was built from were unchanged. As on x86, the same program compiled with the same options plus -m64 (i.e., for sparcv9) yields no mudflap errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #32 from fche at redhat dot com 2008-04-09 19:15 --- The patch has been committed for some time, and this test case passes. -- fche at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #31 from jason at gcc dot gnu dot org 2007-08-27 18:41 --- It seems that G++ is setting TREE_ADDRESSABLE on the RETURN_DECL properly, so the remaining problem is in the mudflap code. Reassigning to fche. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jason at redhat dot com |fche at redhat dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #30 from awl03 at doc dot ic dot ac dot uk 2007-07-12 23:58 --- This patch applies fine to CVS head, but it does not appear to help significantly with the C++ test cases like the ones in the test suite. If I run the pass58-frag.cxx test case without the patch it produces the following: *** mudflap violation 1 (check/write): time=1184284085.501231 ptr=0xbf9fb160 size=4 pc=0xb7e2a31d location=`mudflap-pass58.cpp:3 (k::k)' /var/home/awl03/Project/trunk/install/usr/local/lib/libmudflap.so.0(__mf_check+0x3d) [0xb7e2a31d] ./mudflap-pass58-cpp(_ZN1kC1Ei+0x6f) [0x80487e7] ./mudflap-pass58-cpp(_Z6make_kv+0x1a) [0x804872e] ... etc. But if I apply the path the same test executes without a problem. Are there other C++ test cases that still don't work properly? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #29 from fche at redhat dot com 2007-06-20 19:37 --- This is the patch mentioned in my explanation. It is against the 4.1.1 release source. Thanks! This patch applies fine to CVS head, but it does not appear to help significantly with the C++ test cases like the ones in the test suite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #27 from awl03 at doc dot ic dot ac dot uk 2007-06-10 19:32
---
I have been writing my own bounds-checker based on Mudflap. While doing so I
had to tackle this same problem. My flatmate and I tracked it down to the fact
that, although function parameters and variables are registered if their
address is ever taken, the return value is not. This is a problem in
return-by-value where the result is returned directly without an intermediate
variable. For example:
class bob {
public:
int i;
bob(int n) { i = n; }
};
bob f(int n)
{
return bob(n);
}
int main()
{
bob b = f(0);
}
Here bob is constructed directly in the return statement in f(). In GIMPLE
this looks like:
bob f(int) (n)
{
bb 0:
__comp_ctor (retval, n);
return retval;
}
Notice that retval has its address taken. Inside the constructor
__comp_ctor() the object is created in the location given by retval.
retval has not been registered by f() as return values are not registered,
nor has it been registered by main() (where the object finally ends up) because
nothing there uses its address.
This happens a lot in the STL, hence why it shows up whenever template, map
etc., are used:
iterator begin()
{
return iterator (this-_M_impl._M_start);
}
which is gimplified to into:
iterator begin()
{
comp_ctor (retval, this-_M_impl._M_start);
return retval;
}
If Mudflap is changed to register these return values, the violations go away
:) I have created a patch that does this but, as I'm a relative newbie, it
could all be complete rubbish in which case I apologise.
This deals with the problem for the initial testcase, the simplified test by
Frank Ch. Eigler and the test by Paul Pluzhnikov. It does not fix the others
as these are caused by a different problem, namely objects created by external
library calls are not registered by Mudflap and so it thinks there is a
violation if you use one of these foreign pointers.
I hope this helps and I would be very glad of feedback.
Alex Lamaison
--
awl03 at doc dot ic dot ac dot uk changed:
What|Removed |Added
CC||awl03 at doc dot ic dot ac
||dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #28 from awl03 at doc dot ic dot ac dot uk 2007-06-10 19:35 --- Created an attachment (id=13673) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13673action=view) Patch for tree-mudflap.c This is the patch mentioned in my explanation. It is against the 4.1.1 release source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #25 from fche at redhat dot com 2006-11-14 12:19 --- (In reply to comment #24) Might the problem be that I am compiling on an old glibc? That is possible. Try MUDFLAP_OPTIONS=-trace-calls -verbose-trace. If you have access to a modern glibc, you could compare traces from the two variants. Or that you didn't invoke ./make and didn't in fact run the resulting exe? I certainly ran it. env MUDFLAP_OPTIONS=-collect-stats ./make gives some interesting figures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #26 from ppluzhnikov at charter dot net 2006-11-15 01:22
---
(In reply to comment 25)
Confirmed: using newer glibc:
GNU C Library development release version 2.3.5, by Roland McGrath et al.
and having rebuilt gcc-4.3-20061104 on it, I do not see violations on
make-3.81
Confirmed: the test case from comment 21 still shows 1 violation.
-
I also tracked down the violations I see on glibc-2.1.3
Here is the smallest test case:
#include ctype.h
int main()
{
const char *p = a;
return isblank(*p);
}
When compiled with '-fmudflap' there are no violations.
When compiled with '-fmudflap -D_GNU_SOURCE', there is a violation:
***
mudflap violation 1 (check/read): time=1163551808.269474 ptr=0x3feeb302 size=2
pc=0x3ff0d2fd location=`junk.c:6 (main)'
/usr/local/gcc-4.3-20061104/lib/libmudflap.so.0(__mf_check+0x3d)
[0x3ff0d2fd]
[0x8048850]
/usr/local/gcc-4.3-20061104/lib/libmudflap.so.0(__wrap_main+0x49)
[0x3ff0cdb9]
number of nearby objects: 0
In the first case, isblank() expands to call to isblank().
In the second, it expands into
(__ctype_b[(int) ((*p))] (unsigned short int) _ISblank)
And libmudflap (apparently) doesn't understand where __ctype_b
is pointing at. In fact, here is reduced test case that shows
the exact same problem regardless of glibc version:
$ cat junk1.c
extern int *array;
int main()
{
return array[0];
}
$ cat junk2.c
int _array[1];
int *array = _array;
$ gcc -g -c junk2.c
gcc -g -fmudflap junk1.c junk2.o -lmudflap \
-Wl,-rpath=/usr/local/gcc-4.3-20061104/lib ./a.out
***
mudflap violation 1 (check/read): time=1163552372.861362 ptr=0x80c9998 size=4
pc=0xe6d1bd location=`junk1.c:4 (main)'
/usr/local/gcc-4.3-20061104/lib/libmudflap.so.0(__mf_check+0x3d)
[0xe6d1bd]
./a.out(main+0x84) [0x8048748]
/usr/local/gcc-4.3-20061104/lib/libmudflap.so.0(__wrap_main+0x49)
[0xe6cc79]
Nearby object 1: checked region begins 8B after and ends 11B after
mudflap object 0x80ca0f8: name=`__mf_lc_shift'
bounds=[0x80c9990,0x80c9990] size=1 area=no-access check=0r/0w liveness=0
alloc time=1163552372.860997 pc=0xe6cc1d
Nearby object 2: checked region begins 9B after and ends 12B after
mudflap object 0x80ca028: name=`__mf_lookup_cache'
bounds=[0x8049990,0x80c998f] size=524288 area=no-access check=0r/0w liveness=0
alloc time=1163552372.860984 pc=0xe6cc1d
number of nearby objects: 2
The above violation goes away when I add
MUDFLAP_OPTIONS=-heur-start-end, and gmake-3.81 violations go away
when I add MUDFLAP_OPTIONS=-heur-proc-map but I had to dig up the
original mudflap design article:
http://gcc.fyxm.net/summit/2003/mudflap.pdf
to figure this out.
If you expect your future users to figure this out, I've got a
surprise for you: they most likely will not. These heuristics
probably should be enabled by default (at least on Linux), or at
least *prominently* displayed in the info/man pages.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #23 from fche at redhat dot com 2006-11-14 03:53 --- As I said in comment 16, this problem isn't limited to C++ code either. Instrument gmake-3.81, and you'll get 100,000+ violations Sorry, I don't see that. configured gnu make 3.81 compiled with mainline, CFLAGS=-fmudflap LDFLAGS=-lmudflap. ran resulting executable. No problems at all, just slower. Tried again with -O2 -fmudflap. Same result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #24 from ppluzhnikov at charter dot net 2006-11-14 04:26 --- Created an attachment (id=12615) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12615action=view) annotated transcript Might the problem be that I am compiling on an old glibc? Or that you didn't invoke ./make and didn't in fact run the resulting exe? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #19 from p dot van-hoof at qub dot ac dot uk 2006-11-10 16:33 --- The reduced testcases listed previously in this thread indeed work correctly on the mainline, but a real C++ program that I tested still spewed thousands of violations, although valgrind could not find anything. The attached test case test.cc is one such example. Note that the test program tries to read its own source, so don't rename the file! g++ -fmudflap test.cc -lmudflap a.out *** mudflap violation 1 (check/read): time=1163175853.725925 ptr=0x2ac0ae8ee720 size=8 pc=0x2ac0ae464871 location=`test.cc:18 (main)' /usr/local/gcc430/lib64/libmudflap.so.0(__mf_check+0x41) [0x2ac0ae464871] a.out(main+0x219) [0x40133d] /lib64/libc.so.6(__libc_start_main+0xf4) [0x2ac0aeb88154] number of nearby objects: 0 g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /dump1/root/temp/gcc/configure --prefix=/usr/local/gcc430 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.3.0 20061030 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #20 from p dot van-hoof at qub dot ac dot uk 2006-11-10 16:35 --- Created an attachment (id=12588) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12588action=view) test case mentioned in Comment #19 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #21 from ppluzhnikov at charter dot net 2006-11-10 23:00
---
I was going to say the same thing, but p.van-hoof beat me to it.
Here is another trivial test case that shows 1 violation:
// Reduced from ex02-04.cpp from STL Tutorial and Reference Guide
#include string
using namespace std;
int main()
{
mapstring, long directory;
directory[Bogart] = 1234567;
directory[Bacall] = 9876543;
}
The violation was reproduced with gcc-4.3-20061104 snapshot on linux-i686.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #22 from ppluzhnikov at charter dot net 2006-11-10 23:30 --- I missed '#include map' in comment 21 above (sorry for cut/paste error). As I said in comment 16, this problem isn't limited to C++ code either. Instrument gmake-3.81, and you'll get 100,000+ violations -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #18 from fche at redhat dot com 2006-11-10 03:09 --- For what it's worth, this problem does not appear to show up in current mainline gcc. If indeed it was caused by tree-ssa passes other than mudflap itself, a backport of whatever is making it work now seems very unlikely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-03-19 05:11 --- NVR in the C++ front-end is causing this violation to be produced. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2005-01-07 22:42:03 |2006-03-19 05:11:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #16 from ppluzhnikov at charter dot net 2005-12-14 17:46 --- Same picture using gcc-4.1-20051209 for i686-pc-linux-gnu: 7 bogus violations on original test, 1 on reduced test. Here are other version results: original reduced gcc-4.1-20051209 i686-pc-linux-gnu 7 1 gcc-4.2-20051210 i686-pc-linux-gnu 1 1 gcc-4.2-20051210 x86_64-unknown-linux-gnu0 0 gcc-4.2-20051210 x86_64-unknown-linux-gnu -m32 1 1 Encouraged by the absence of bogus warnings on x86_64 in 64-bit mode, I tried 4.2-20051210 on my real code. This resulted in 100s of bogus violations, though I have not been able to produce a reduced test case yet :-( I then tried 4.2-20051210 i686 on pure C real code, and got 100s more bogus violations. IMHO, the -fmudflap either needs to be made to work correctly on real C/C++ programs, or it should be removed altogether (bogus reports lead to a lot of wasted time, as each new user discovers the feature, and then finds out it doesn't work). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #15 from ppluzhnikov at charter dot net 2005-10-23 23:47 --- On stock FC2, using the latest gcc-4.1 snapshot (20051022), I get 7 mudflap violations from the original test, 1 from the reduced test. This doesn't appear to be a heisenbug at all -- it reproduces with all gcc-4.x releases/snapshots on all i686 systems I tried! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From fche at redhat dot com 2005-09-23 21:35 --- I can't explain it, but on today's mainline, this bug does not appear. I'm going to commit the smaller test case (... make_k ...) from above to libmudflap/testsuite. If this test fails, please post an attachment with the error log. Since neither my x86 nor x86-64 machine shows the problem, it may be necessary for you to rebuild the test case with extra dump flags (-fdump-tree-all and friends) and scour through that for clues. -- What|Removed |Added Status|REOPENED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-23 21:35 --- Subject: Bug 19319 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-23 21:35:17 Modified files: libmudflap : ChangeLog Added files: libmudflap/testsuite/libmudflap.c++: pass58-frag.cxx Log message: 2005-09-23 Frank Ch. Eigler [EMAIL PROTECTED] * testsuite/libmudflap.c++/pass58-frag.cxx: New test for heisenbug 19319. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libmudflap/ChangeLog.diff?cvsroot=gccr1=1.71r2=1.72 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libmudflap/testsuite/libmudflap.c++/pass58-frag.cxx.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From gideon dot amos at canfieldsci dot com 2005-08-18 19:57 --- I'm still getting a mudflap violation with the simpler test case, posted by Frank Ch. Eigler, I get this on a debian linux system (Linux version 2.6.8-1-686-smp) with at least two builds of gcc: $ gcc --version gcc (GCC) 4.0.1 [...] $ gcc -dumpmachine target i686-pc-linux-gnu and $ gcc-4.0 --version gcc-4.0 (GCC) 4.0.2 20050816 (prerelease) (Debian 4.0.1-5) [...] $ gcc-4.0 -dumpmachine i486-linux-gnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From fche at redhat dot com 2005-08-18 20:05 --- still broken. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
-- What|Removed |Added Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From fche at redhat dot com 2005-03-10 21:57 --- Myseriously, the bug still appears fixed, in both 4_0-branch and mainline, despite the reversion. See libmudflap/testsuite/*++/pass55*. For archival purposes, the last approved but apparently unnecessary patch for this problem was this one: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00381.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-19 15:56 --- Reopening as the patch had to be reverted. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
-- What|Removed |Added AssignedTo|fche at redhat dot com |unassigned at gcc dot gnu ||dot org Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
-- What|Removed |Added CC||fche at redhat dot com AssignedTo|unassigned at gcc dot gnu |jason at redhat dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-17 05:37 --- Subject: Bug 19319 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-17 05:37:21 Modified files: gcc: ChangeLog gimplify.c Log message: PR mudflap/19319, c++/19317 * gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Make return slot explicit. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7504r2=2.7505 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gccr1=2.111r2=2.112 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-13 12:49 --- Subject: Bug 19319 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-13 12:49:34 Modified files: libmudflap : ChangeLog Added files: libmudflap/testsuite/libmudflap.c++: pass55-frag.cxx Log message: 2005-02-13 Frank Ch. Eigler [EMAIL PROTECTED] PR mudflap/19319 * testsuite/libmudflap.c++/pass55-frag.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libmudflap/ChangeLog.diff?cvsroot=gccr1=1.48r2=1.49 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libmudflap/testsuite/libmudflap.c++/pass55-frag.cxx.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From fche at redhat dot com 2005-02-13 12:50 --- Thank you, Jason! -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-13 06:44 --- Subject: Bug 19319 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-02-13 06:43:58 Modified files: gcc: ChangeLog fold-const.c gimplify.c tree.h Log message: PR mudflap/19319 * gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Make return slot explicit. PR c++/16405 * fold-const.c (fold_indirect_ref_1): Split out from... (build_fold_indirect_ref): Here. (fold_indirect_ref): New fn. * tree.h: Declare it. * gimplify.c (gimplify_compound_lval): Call fold_indirect_ref. (gimplify_modify_expr_rhs): Likewise. (gimplify_expr): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7461r2=2.7462 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gccr1=1.507r2=1.508 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gccr1=2.108r2=2.109 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gccr1=1.689r2=1.690 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From bredelin at ucla dot edu 2005-01-18 09:35 --- Note that this is not just a bug in mudflap, but a bug in the middle end: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00579.html See follow-up on above message for a mention of a patch for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From fche at redhat dot com 2005-01-10 17:04
---
This patch appears to fix the problem: testing and getting approvals
--- gimplify.c 1 Jan 2005 01:43:08 - 2.101
+++ gimplify.c 10 Jan 2005 17:03:54 -
@@ -2949,6 +2949,15 @@ gimplify_modify_expr (tree *expr_p, tree
if (ret != GS_UNHANDLED)
return ret;
+ /* Handle aggregate returns from function calls. We need to mark
+ the LHS addressable, since the expanded call will pass its
+ address as a hidden argument. */
+ if (TREE_CODE (*from_p) == CALL_EXPR)
+{
+ if (aggregate_value_p (*to_p, *from_p))
+lang_hooks.mark_addressable (*to_p);
+}
+
/* If we've got a variable sized assignment between two lvalues (i.e. does
not involve a call), then we can make things a bit more straightforward
by converting the assignment to memcpy or memset. */
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From bangerth at dealii dot org 2005-01-08 20:03 --- Analysis is here and in the follow-up: http://gcc.gnu.org/ml/gcc/2005-01/msg00460.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fche at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 GCC build triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC host triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC target triplet| i686-pc-linux-gnu |i686-pc-linux-gnu Last reconfirmed|-00-00 00:00:00 |2005-01-07 22:42:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From fche at redhat dot com 2005-01-07 22:58
---
Here is a simpler test case for at least one of the problems.
struct k {
int data;
k(int j): data(j) {}
};
k make_k () { return k(1); }
int main ()
{
k foo = make_k ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
