| Message ID | 526B9876.8060704@redhat.com |
|---|---|
| State | New |
| Headers | show |
... slightly out of topic, sorry Jeff, but your message made me think that we should probably do something about the mudflap fails that we have got since forever (at least on Linux): to your best knowledge is somebody actively working on those? Should be just xfails for now?!? Thanks! Paolo
On Sat, Oct 26, 2013 at 12:31:34PM +0200, Paolo Carlini wrote:
> ... slightly out of topic, sorry Jeff, but your message made me think that we should probably do something about the mudflap fails that we have got since forever (at least on Linux): to your best knowledge is somebody actively working on those? Should be just xfails for now?!?
Which ones? All mudflap tests should be gone now.
Marek
Marek Polacek <polacek@redhat.com> ha scritto:
>Which ones? All mudflap tests should be gone now.
Just browse gcc-testresults ;)
Paolo
... seriously, in libmudflap.c++, 41, etc Paolo
On Sat, Oct 26, 2013 at 12:46:41PM +0200, Paolo Carlini wrote:
> ... seriously, in libmudflap.c++, 41, etc
But aren't all these removed in commit 204090?
Marek
Hi Marek Polacek <polacek@redhat.com> ha scritto: >On Sat, Oct 26, 2013 at 12:46:41PM +0200, Paolo Carlini wrote: >> ... seriously, in libmudflap.c++, 41, etc > >But aren't all these removed in commit 204090? Ah! I didn't notice something such aggressive was going on! Excellent! Thanks, Paolo
On Sat, 26 Oct 2013, Jeff Law wrote: > It appears that mudflap creeped into one additional file (targhooks) between > the time I bootstrapped the final change and committed the change. This also > elimiantes PRED_MUDFLAP which I missed the first time around. > > Given this is currently breaking boostrap, I'm checking it in proactively, but > will allow my bootstrap and regression test to continue overnight. Yeah, cris-elf is broken too. I use PRED_MUDFLAP in cris_emit_trap_for_misalignment, which should explain its use. Is there a replacement? PRED_MUDFLAP: -/* Branches to a mudflap bounds check are extremely unlikely. brgds, H-P
On Sat, Oct 26, 2013 at 6:45 AM, Hans-Peter Nilsson <hp@bitrange.com> wrote: > On Sat, 26 Oct 2013, Jeff Law wrote: > >> It appears that mudflap creeped into one additional file (targhooks) between >> the time I bootstrapped the final change and committed the change. This also >> elimiantes PRED_MUDFLAP which I missed the first time around. >> >> Given this is currently breaking boostrap, I'm checking it in proactively, but >> will allow my bootstrap and regression test to continue overnight. > > Yeah, cris-elf is broken too. I use PRED_MUDFLAP in > cris_emit_trap_for_misalignment, which should explain its use. > Is there a replacement? I think you could use PRED_NORETURN which should be a reasonable replacement. Thanks, Andrew Pinski > > PRED_MUDFLAP: > -/* Branches to a mudflap bounds check are extremely unlikely. > > brgds, H-P
On 10/26/13 07:45, Hans-Peter Nilsson wrote: > On Sat, 26 Oct 2013, Jeff Law wrote: > >> It appears that mudflap creeped into one additional file (targhooks) between >> the time I bootstrapped the final change and committed the change. This also >> elimiantes PRED_MUDFLAP which I missed the first time around. >> >> Given this is currently breaking boostrap, I'm checking it in proactively, but >> will allow my bootstrap and regression test to continue overnight. > > Yeah, cris-elf is broken too. I use PRED_MUDFLAP in > cris_emit_trap_for_misalignment, which should explain its use. > Is there a replacement? I'd suggest PRED_COLD_LABEL. jeff
On 10/26/13 05:19, Paolo Carlini wrote: > > > Hi > > Marek Polacek <polacek@redhat.com> ha scritto: >> On Sat, Oct 26, 2013 at 12:46:41PM +0200, Paolo Carlini wrote: >>> ... seriously, in libmudflap.c++, 41, etc >> >> But aren't all these removed in commit 204090? > > Ah! I didn't notice something such aggressive was going on! Excellent! The message containing the final version of the patch bounded due to size, but I didn't notice until just a short while ago. Sorry. jeff
On Sat, 26 Oct 2013, Andrew Pinski wrote:
> I think you could use PRED_NORETURN which should be a reasonable replacement.
I've totally missed that one, thanks.
brgds, H-P
diff --git a/gcc/predict.def b/gcc/predict.def index f8dba66..2ce135c 100644 --- a/gcc/predict.def +++ b/gcc/predict.def @@ -117,9 +117,6 @@ DEF_PREDICTOR (PRED_NEGATIVE_RETURN, "negative return", HITRATE (96), 0) /* Branch ending with return; is probably not taken */ DEF_PREDICTOR (PRED_NULL_RETURN, "null return", HITRATE (90), 0) -/* Branches to a mudflap bounds check are extremely unlikely. */ -DEF_PREDICTOR (PRED_MUDFLAP, "mudflap check", PROB_VERY_LIKELY, 0) - /* Branches to compare induction variable to a loop bound is extremely likely. */ DEF_PREDICTOR (PRED_LOOP_IV_COMPARE_GUESS, "guess loop iv compare", diff --git a/gcc/targhooks.c b/gcc/targhooks.c index bee404d..fd0d0d4 100644 --- a/gcc/targhooks.c +++ b/gcc/targhooks.c @@ -72,7 +72,6 @@ along with GCC; see the file COPYING3. If not see #include "tree-ssanames.h" #include "tree-ssa-alias.h" #include "insn-codes.h" -#include "tree-mudflap.h" bool @@ -1576,10 +1575,6 @@ tree build_va_arg_indirect_ref (tree addr) { addr = build_simple_mem_ref_loc (EXPR_LOCATION (addr), addr); - - if (flag_mudflap) /* Don't instrument va_arg INDIRECT_REF. */ - mf_mark (addr); - return addr; }