Re: RFA: Testsuite PATCH to add support for dlopen tests

[Thomas Schwinge]

Hi!

On Mon, 14 Apr 2014 00:37:30 -0400, Jason Merrill  wrote:
> On 04/13/2014 09:24 PM, Hans-Peter Nilsson wrote:
> > Can this please be reverted and a patch circulated for testing
> > instead?
> 
> Done, sorry.

Committed as obvious:

r210742 | tschwinge | 2014-05-22 09:07:29 +0200 (Thu, 22 May 2014) | 2
lines
Changed paths:
   D /trunk/gcc/testsuite/g++.dg/dso

Remove empty directory gcc/testsuite/g++.dg/dso.

(This was causing "differences" between Subversion and Git checkouts.)


Grüße,
 Thomas


pgp4ugmwJXWJg.pgp
Description: PGP signature

FWD: Re: OpenACC subarray specifications in the GCC Fortran front end

[Ilmir Usmanov]

On 16.05.2014 19:44, Ilmir Usmanov wrote:

Hi Thomas!

On 16.05.2014 19:12, Thomas Schwinge wrote:

Hi Ilmir!

You recently indicated that you have already begun implementing OpenACC
subarray specifications in the GCC Fortran front end, but have not
been/are not currently able to complete that.  Would you be willing to
share your WIP patch with Cesar, who is now working on this, so that he
doesn't have to duplicate your work?

Sure! I'm glad to know that my work won't go directly to trash.

BTW, another patch is still pending: 
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00027.html


Cesar,

You can find the patch in attachment.

I started to implement sub-arrays in gfortran by implementing OpenMP 
4.0 target map clause. This clause was already implemented in C/C++ 
FEs, so I could check the behavior. I don't know whether it's already 
implemented in gfortran or not.


To represent OpenMP array sections (or OpenACC subarrays) I used 
gfc_expr.


After implementing OpenMP target map clauses I was going to use it to 
represent OpenACC data clauses, just as Thomas recommended in his 
mail: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg02040.html


I hope this will be useful for you. If you will have any question feel 
free to ask.


Grüße,
  Thomas

--
Ilmir.
>From 5ba154b9af6499f567172b92f9abcf362584be58 Mon Sep 17 00:00:00 2001
From: Ilmir Usmanov 
Date: Tue, 8 Apr 2014 17:08:02 +0400
Subject: [PATCH] Subarrays

---
 gcc/fortran/dump-parse-tree.c |  55 +++--
 gcc/fortran/gfortran.h|  21 +-
 gcc/fortran/match.h   |   1 +
 gcc/fortran/openmp.c  | 292 +++---
 gcc/fortran/parse.c   |  17 +-
 gcc/fortran/resolve.c |   3 +
 gcc/fortran/st.c  |   1 +
 gcc/fortran/trans-openmp.c| 185 +++-
 gcc/fortran/trans.c   |   1 +
 gcc/testsuite/gfortran.dg/goacc/subarrays.f95 |  36 
 gcc/testsuite/gfortran.dg/gomp/map-1.f90  | 101 +
 gcc/testsuite/gfortran.dg/gomp/target-1.f90   |  21 ++
 12 files changed, 674 insertions(+), 60 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/goacc/subarrays.f95
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/map-1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/gomp/target-1.f90

diff --git a/gcc/fortran/dump-parse-tree.c b/gcc/fortran/dump-parse-tree.c
index b6679ab..bdc30c2 100644
--- a/gcc/fortran/dump-parse-tree.c
+++ b/gcc/fortran/dump-parse-tree.c
@@ -1023,6 +1023,17 @@ show_namelist (gfc_namelist *n)
   fprintf (dumpfile, "%s", n->sym->name);
 }
 
+static void
+show_expr_list (gfc_expr_list *el)
+{
+  for (; el->next; el = el->next)
+{
+  show_expr (el->expr);
+  fputc (',', dumpfile);
+}
+  show_expr (el->expr);
+}
+
 
 /* Show OpenMP or OpenACC clauses.  */
 
@@ -1043,6 +1054,12 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
   show_expr (omp_clauses->final_expr);
   fputc (')', dumpfile);
 }
+  if (omp_clauses->device_id)
+{
+  fputs (" DEVICE(", dumpfile);
+  show_expr (omp_clauses->device_id);
+  fputc (')', dumpfile);
+}
   if (omp_clauses->num_threads)
 {
   fputs (" NUM_THREADS(", dumpfile);
@@ -1148,28 +1165,35 @@ show_omp_clauses (gfc_omp_clauses *omp_clauses)
 	}
   fprintf (dumpfile, " DEFAULT(%s)", type);
 }
-  if (omp_clauses->tile_list)
+  for (int kind = 0; kind < OMP_MAP_LIST_LAST; kind++)
 {
-  gfc_expr_list *list;
-  fputs (" TILE(", dumpfile);
-  for (list = omp_clauses->tile_list; list; list = list->next)
+  const char *type;
+  if (omp_clauses->map_lists[kind] == NULL)
+	continue;
+
+  switch (kind)
 	{
-	  show_expr (list->expr);
-	  if (list->next) 
-	fputs (", ", dumpfile);
+	case OMP_MAP_LIST_ALLOC: type = "ALLOC"; break;
+	case OMP_MAP_LIST_TO: type = "TO"; break;
+	case OMP_MAP_LIST_FROM: type = "FROM"; break;
+	case OMP_MAP_LIST_TOFROM: type = "TOFROM"; break;
+	default:
+	  gcc_unreachable ();
 	}
+  fprintf (dumpfile, " MAP(%s:", type);
+  show_expr_list (omp_clauses->map_lists[kind]);
+  fputc (')', dumpfile);
+}
+  if (omp_clauses->tile_list)
+{
+  fputs (" TILE(", dumpfile);
+  show_expr_list (omp_clauses->tile_list);
   fputc (')', dumpfile);
 }
   if (omp_clauses->wait_list)
 {
-  gfc_expr_list *list;
   fputs (" WAIT(", dumpfile);
-  for (list = omp_clauses->wait_list; list; list = list->next)
-	{
-	  show_expr (list->expr);
-	  if (list->next) 
-	fputs (", ", dumpfile);
-	}
+  show_expr_list (omp_clauses->wait_list);
   fputc (')', dumpfile);
 }
   if (omp_clauses->seq)
@@ -1286,6 +1310,7 @@ show_omp_node (int level, gfc_code *c)
 case EXEC_OMP_PARALLEL_WORKSHARE: name = "PARALLEL WORKSHARE"; break;
 case EXEC_OMP_SECTIONS: name = "SECTIONS"; break;
 case EXEC_OMP_SINGLE: name = "SINGLE"; break;
+cas

RE: [PATCH][MIPS] Implement O32 FPXX ABI (GCC)

[Matthew Fortune]

Richard Sandiford  writes:
> Matthew Fortune  writes:
> >> > *) Because GCC can be built to have mfpxx or mfp64 as the default
> option
> >> >the ASM_SPEC has to handle these specially such that they are not
> >> >passed in conjunction with -msingle-float. Depending on how all
> this
> >> >option handling pans out then this may also need to account for
> >> >msoft-float as well. It is an error to have -msoft-float and -mfp64
> in
> >> >the assembler.
> >>
> >> The assembler and GCC shouldn't treat the options differently though.
> >> Either it should be OK for both or neither.
> >
> > I wasn't sure if you were applying this rule to options set by --with- at
> > configure time as well as user supplied options. If I move this logic
> > to OPTION_DEFAULT_SPECS instead and not apply the --with-fp option if
> > -msingle-float is given then that will fix the issue too. Is that OK?
> 
> --with-foo is just a way of setting the default -mfoo option when no
> explicit -mfoo option is given.  We shouldn't generally distinguish
> between them.

OK. I don't mind what we do here so I'm happy to just relax the (new)
assembler restrictions that would prevent -msingle-float -mfp64. I need to
check if these ended up in the .module binutils patch or are in the FPXX
patch.
 
> >> > @@ -5141,7 +5141,7 @@ mips_get_arg_info (struct mips_arg_info *info,
> >> const CUMULATIVE_ARGS *cum,
> >> >   || SCALAR_FLOAT_TYPE_P (type)
> >> >   || VECTOR_FLOAT_TYPE_P (type))
> >> >   && (GET_MODE_CLASS (mode) == MODE_FLOAT
> >> > - || mode == V2SFmode)
> >> > + || (TARGET_PAIRED_SINGLE_FLOAT && mode == 
> >> > V2SFmode))
> >> >   && GET_MODE_SIZE (mode) <= UNITS_PER_FPVALUE);
> >> >break;
> >>
> >> This looks odd.  We shouldn't have V2SF values if there's no ISA support
> >> for them.
> >
> > True. This is a safety measure against future vector support. I/We wish
> to
> > completely restrict this ABI extension to the paired single-float
> > hardware feature. This detail is easy to forget, I would like to keep
> > the check but you get final call of course.
> 
> But the problem is that the change gives a specific behaviour for
> !TARGET_PAIRED_SINGLE_FLOAT && mode == V2SFmode, which at the moment
> should be a nonsensical condition.  I want to avoid defining an ABI
> for something that shouldn't happen.
> 
> I'd be happy with an assert like:
> 
>   gcc_assert (TARGET_PAIRED_SINGLE_FLOAT || mode != V2SFmode);

OK. It's just for future safety so this looks good.

> instead.
> >> > @@ -12202,7 +12247,8 @@ mips_secondary_reload_class (enum reg_class
> >> rclass,
> >> >  return NO_REGS;
> >> >
> >> >/* Otherwise, we need to reload through an integer register.
> */
> >> > -  return GR_REGS;
> >> > +  if (regno >= 0)
> >> > +return GR_REGS;
> >> >  }
> >> >if (FP_REG_P (regno))
> >> >  return reg_class_subset_p (rclass, GR_REGS) ? NO_REGS : GR_REGS;
> >>
> >> Why's this change needed?  Although I assume it's dead code if you
> tested
> >> against LRA.
> >
> > It is an optimisation actually (and this code is used by LRA). Without it
> > We end up with reload registers for floating point values being reloaded
> > via GR_REGS even though they can be stored to memory directly if a
> > FP_REG was used. This results in extra moves between GP and FP. The test
> > cases will fail if this code is removed (call-clobbered-3 and
> > call-clobbered-5).
> 
> Ah, OK.  In that case I think we should instead change:
> 
>   if (MEM_P (x)
> && (GET_MODE_SIZE (mode) == 4 || GET_MODE_SIZE (mode) == 8))
>   /* In this case we can use lwc1, swc1, ldc1 or sdc1.  We'll use
>  pairs of lwc1s and swc1s if ldc1 and sdc1 are not supported.  */
>   return NO_REGS;
> 
> to:
> 
>   if (MEM_P (x) || regno < 0)
>   {
> /* In this case we can use combinations of LWC1, SWC1, LDC1 and
>SDC1.  */
> gcc_checking_assert (GET_MODE_SIZE (mode) % 4 == 0);
> return NO_REGS;
>   }
> 
> Please do it as a separate patch though.

OK
 
> >> > diff --git a/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
> >> b/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
> >> > new file mode 100644
> >> > index 000..f47cdda
> >> > --- /dev/null
> >> > +++ b/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
> >> > @@ -0,0 +1,21 @@
> >> > +/* Check that we handle call-clobbered FPRs correctly.  */
> >> > +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
> >> > +/* { dg-options "-mabi=32 -modd-spreg -mfp32 -ffixed-f0 -ffixed-f1 -
> >> ffixed-f2 -ffixed-f3 -ffixed-f4 -ffixed-f5 -ffixed-f6 -ffixed-f7 -
> ffixed-f8
> >> -ffixed-f9 -ffixed-f10 -ffixed-f11 -ffixed-f12 -ffixed-f13 -ffixed-f14 -
> >> ffixed-f15 -ffixed-f16 -ffixed-f17 -ffixed-f18 -ffixed-f19 -ffixed-f20 -
> >> ffixed-f22 -ffixed-f24 -ffixed-f26 -ffixed-

Re: [patch] c/61271 fix ICE for invalid cilkplus array notation

[Richard Biener]

On Wed, May 21, 2014 at 5:43 PM, Jonathan Wakely  wrote:
> This is only one of several cases in the PR, but one that's simple
> enough for me to write a test for and fix.
>
> Tested x86_64-linux, OK for trunk?

Ok.

Thanks,
Richard.

Re: [PATCH] __attribute__ ((malloc)) doc fix (PR other/56955)

[Richard Biener]

On Wed, May 21, 2014 at 8:37 PM, Paul Eggert  wrote:
> Attached is a proposed documentation patch for __attribute__ ((malloc)),
> taken from:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955#c9
>
> Richard Biener suggested that I forward it to this list.

Thanks Paul.  Re-reading this I wonder if the wording is clear enough to
disallow for example

struct S { struct S *p; };

struct S * __attribute__((malloc)) allocS (void)
{
  struct S *s = malloc (sizeof (struct S));
  s->p = s;
  return s;
}

the function returns an initialized S, but it's pointers do
not alias any other pointer valid when the function returns(?).

That is, the constraint is rather that pointers extracted from the
memory pointed to by the return value do not point to "valid"
objects.

For the above doing

struct S *s = allocS();
s->s->s = 0;

would be DSEd (because s->s points to 'nothing').

Can you try to clarify the wording (I'm not a native speaker).

Thanks,
Richard.

Re: [PATCH][MIPS] Implement O32 FPXX ABI (GCC)

[Richard Sandiford]

Matthew Fortune  writes:
> Richard Sandiford  writes:
>> Matthew Fortune  writes:
>> >> > *) Because GCC can be built to have mfpxx or mfp64 as the default
>> option
>> >> >the ASM_SPEC has to handle these specially such that they are not
>> >> >passed in conjunction with -msingle-float. Depending on how all
>> this
>> >> >option handling pans out then this may also need to account for
>> >> >msoft-float as well. It is an error to have -msoft-float and -mfp64
>> in
>> >> >the assembler.
>> >>
>> >> The assembler and GCC shouldn't treat the options differently though.
>> >> Either it should be OK for both or neither.
>> >
>> > I wasn't sure if you were applying this rule to options set by --with- at
>> > configure time as well as user supplied options. If I move this logic
>> > to OPTION_DEFAULT_SPECS instead and not apply the --with-fp option if
>> > -msingle-float is given then that will fix the issue too. Is that OK?
>> 
>> --with-foo is just a way of setting the default -mfoo option when no
>> explicit -mfoo option is given.  We shouldn't generally distinguish
>> between them.
>
> OK. I don't mind what we do here so I'm happy to just relax the (new)
> assembler restrictions that would prevent -msingle-float -mfp64. I need to
> check if these ended up in the .module binutils patch or are in the FPXX
> patch.

Let's step back a bit.  Please explain which case you were trying to
handle with the specs patch.  Rejecting -msingle-float -mfp64 seems fine.
Fiddling with the specs to stop that combination reaching the assembler
is what seemed odd.

>> >> > diff --git a/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
>> >> b/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
>> >> > new file mode 100644
>> >> > index 000..f47cdda
>> >> > --- /dev/null
>> >> > +++ b/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
>> >> > @@ -0,0 +1,21 @@
>> >> > +/* Check that we handle call-clobbered FPRs correctly.  */
>> >> > +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" } } */
>> >> > +/* { dg-options "-mabi=32 -modd-spreg -mfp32 -ffixed-f0 -ffixed-f1 -
>> >> ffixed-f2 -ffixed-f3 -ffixed-f4 -ffixed-f5 -ffixed-f6 -ffixed-f7 -
>> ffixed-f8
>> >> -ffixed-f9 -ffixed-f10 -ffixed-f11 -ffixed-f12 -ffixed-f13 -ffixed-f14 -
>> >> ffixed-f15 -ffixed-f16 -ffixed-f17 -ffixed-f18 -ffixed-f19 -ffixed-f20 -
>> >> ffixed-f22 -ffixed-f24 -ffixed-f26 -ffixed-f28 -ffixed-f30" } */
>> >> > +
>> >> > +void bar (void);
>> >> > +float a;
>> >> > +float
>> >> > +foo ()
>> >> > +{
>> >> > +  float b = a + 1.0f;
>> >> > +  bar();
>> >> > +  return b;
>> >> > +}
>> >> > +/* { dg-final { scan-assembler-times "lwc1" 2 } } */
>> >> > +/* { dg-final { scan-assembler-not "swc1" } } */
>> >> > +/* { dg-final { scan-assembler-times "sdc1" 2 } } */
>> >> > +/* { dg-final { scan-assembler-not "mtc" } } */
>> >> > +/* { dg-final { scan-assembler-not "mfc" } } */
>> >> > +/* { dg-final { scan-assembler-not "mthc" } } */
>> >> > +/* { dg-final { scan-assembler-not "mfhc" } } */
>> >>
>> >> Why require sdc1 here?  Would Chao-Ying's patch make this use SWC1 and
>> LWC1
>> >> exclusively?
>> >
>> > The SDC1 instructions are for callee-saved registers. I'll add the
>> > check for two corresponding LDC1 instructions in the epilogue though
>> > since I've noticed them being missing.
>> 
>> I'm probably being dense, sorry, but why is SDC1 needed for -mfp32
>> -modd-spreg?  Can't we just save and restore the odd register?
>> That's technically more correct too, since we shouldn't really touch
>> -ffixed registers.
>
> You are correct and I am/was aware of this...
>
> GCC is saving too much of the callee-saved registers when single-precision
> values are live in them but this is historic behaviour. The code which
> controls this is very complex and I'd be worried about breaking it. The
> fix would be invasive as all the logic is honed towards the notion of
> 64-bit callee-saved registers.

But that's because it was written before separate odd spregs came along.
I'm not convinced the situation is as bad as you say.

> One thing to say is that this test is
> a very aggressive test of ABI not normal compiler behaviour. Normally
> an even-numbered callee-saved register would be used first followed by the
> odd meaning that it is rare to only use the odd register. That flips the
> problem round to single precision data in even registers...
>
> I believe that prior to mips32 introducing odd-numbered single-precision
> registers then GCC will have been saving and restoring using sdc1/ldc1
> for even-numbered registers regardless of whether they are used for
> single or double precision data (for mips1 it also will do pairs of
> lwc1/swc1).

Sure.  And saving and restoring both using LDC1 and SDC1 is still
the right thing to do if both registers are clobbered.  But if only
one is clobbered then we should save just that.  It's really just
the same principle as Chao-ying's patch, but applied to the prologue
and epilogue.

> My vote FWIW is to l

[PATCH] Fix LTO decimal ICE

[Jakub Jelinek]

On Wed, May 21, 2014 at 08:52:03PM +0200, Jakub Jelinek wrote:
> FAIL: c-c++-common/ubsan/float-cast-overflow-10.c  -O2 -flto 
> -fno-use-linker-plugin -flto-partition=none  (internal compiler error)
> FAIL: c-c++-common/ubsan/float-cast-overflow-10.c  -O2 -flto 
> -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
> FAIL: c-c++-common/ubsan/float-cast-overflow-10.c  -O2 -flto 
> -fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error)
> FAIL: c-c++-common/ubsan/float-cast-overflow-10.c  -O2 -flto 
> -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
> FAIL: c-c++-common/ubsan/float-cast-overflow-7.c  -O2 -flto 
> -fno-use-linker-plugin -flto-partition=none  (internal compiler error)
> FAIL: c-c++-common/ubsan/float-cast-overflow-7.c  -O2 -flto 
> -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
> FAIL: c-c++-common/ubsan/float-cast-overflow-7.c  -O2 -flto 
> -fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error)
> FAIL: c-c++-common/ubsan/float-cast-overflow-7.c  -O2 -flto 
> -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
> 
> The LTO ICEs on float-cast-overflow-{7,10}.c seems to be related to decimal 
> support:
> /usr/src/gcc/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.c:147:1: 
> internal compiler error: in decimal_to_decnumber, at dfp.c:138
> 0x116b4cb decimal_to_decnumber
> ../../gcc/dfp.c:138
...

This bug is because we leave garbage in REAL_VALUE_TYPE padding bits, but
then use memcmp on REAL_VALUE_TYPE objects.  All other places use memset
first to clear the padding bits, so I've committed this fix as obvious
to trunk and 4.9 (without testcase, because I couldn't reproduce it on
anything smaller than float-cast-overflow-{7,10}.c and those require
further gcc patches.

> The execution test FAILs for -m32 are:
> ==4494==Sanitizer CHECK failed: 
> ../../../../../libsanitizer/ubsan/ubsan_value.cc:98 ((0 && "unexpected 
> floating point bit width")) != (0) (0, 0)

This one can be fixed by handling 96 the same as 80 and 128, apparently even 
clang/llvm uses 96 on i?86 and crashes in libubsan the same way.  Marek, can
you please handle the LLVM bureaucracy?

2014-05-22  Jakub Jelinek  

* tree-streamer-in.c (unpack_ts_real_cst_value_fields): Make sure
all padding bits in REAL_VALUE_TYPE are cleared.

--- gcc/tree-streamer-in.c.jj   2014-05-20 16:37:05.0 +0200
+++ gcc/tree-streamer-in.c  2014-05-22 09:40:01.300112220 +0200
@@ -168,6 +168,9 @@ unpack_ts_real_cst_value_fields (struct
   REAL_VALUE_TYPE r;
   REAL_VALUE_TYPE *rp;
 
+  /* Clear all bits of the real value type so that we can later do
+ bitwise comparisons to see if two values are the same.  */
+  memset (&r, 0, sizeof r);
   r.cl = (unsigned) bp_unpack_value (bp, 2);
   r.decimal = (unsigned) bp_unpack_value (bp, 1);
   r.sign = (unsigned) bp_unpack_value (bp, 1);


Jakub

Re: [patch] Small enhancement to associate_plusminus

[Richard Biener]

On Wed, May 21, 2014 at 9:45 PM, Eric Botcazou  wrote:
> Hi,
>
> one of the transformations performed by associate_plusminus is:
>
>   /* Second match patterns that allow contracting a plus-minus pair
>  irrespective of overflow issues.
>
>   [...]
> (T)(P + A) - (T)P  -> (T)A
>
> but it is actually applied only to POINTER_PLUS_EXPR and pointer types:
>
>  /* (T)(ptr + adj) - (T)ptr -> (T)adj.  */
>
> It turns out that this pattern arises for size computations of array slices in
> Ada, which are done in integer types; for the attached testcase, extending the
> transformation to integer types makes it possible to eliminate a call to the
> alloca builtin.
>
> Tested on x86_64-suse-linux, OK for the mainline?

I'm a little worried that introducing PLUS_EXPR_CODE_P and friends
invites too easy (not well thought) uses of it - they are distinct enough
that we have very few "common" code-paths given the constraints on
op2 of POINTER_PLUS_EXPR.

Thus I'd say ok without adding those.

Thanks,
Richard.

> 2014-05-21  Eric Botcazou  
>
> * tree.h (PLUS_EXPR_CODE_P): New macro.
> (PLUS_EXPR_P): Likewise.
> (CASE_PLUS): Likewise.
> * tree-ssa-forwprop.c (associate_plusminus): Extend (T)(P+A) - (T)P
> -> (T)A transformation to integer types.
>
>
> 2014-05-21  Eric Botcazou  
>
> * gnat.dg/opt37.ad[sb]: New test.
>
>
> --
> Eric Botcazou

[gomp4] Merge trunk r210672 (2014-05-21) into gomp-4_0-branch

[Thomas Schwinge]

Hi!

In r210750, I have committed a merge from trunk r210672 (2014-05-21) into
gomp-4_0-branch.


The LTO regression that appeared with the second to last merge,
,
remains to be resolved:

 PASS: gcc.dg/lto/save-temps c_lto_save-temps_0.o assemble,  -O -flto 
-save-temps
-PASS: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o 
link,  -O -flto -save-temps
+FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o 
link,  -O -flto -save-temps
+UNRESOLVED: gcc.dg/lto/save-temps 
c_lto_save-temps_0.o-c_lto_save-temps_0.o execute  -O -flto -save-temps

Executing on host: [...]/build/gcc/xgcc -B[...]/build/gcc/  
-fno-diagnostics-show-caret -fdiagnostics-color=never   -O -flto -save-temps  
-c  -o c_lto_save-temps_0.o 
[...]/source/gcc/testsuite/gcc.dg/lto/save-temps_0.c(timeout = 300)
spawn [...]/build/gcc/xgcc -B[...]/build/gcc/ -fno-diagnostics-show-caret 
-fdiagnostics-color=never -O -flto -save-temps -c -o c_lto_save-temps_0.o 
[...]/source/gcc/testsuite/gcc.dg/lto/save-temps_0.c
PASS: gcc.dg/lto/save-temps c_lto_save-temps_0.o assemble,  -O -flto 
-save-temps
Executing on host: [...]/build/gcc/xgcc -B[...]/build/gcc/ 
c_lto_save-temps_0.o  -fno-diagnostics-show-caret -fdiagnostics-color=never   
-O -flto -save-temps   -o gcc-dg-lto-save-temps-01.exe(timeout = 300)
spawn [...]/build/gcc/xgcc -B[...]/build/gcc/ c_lto_save-temps_0.o 
-fno-diagnostics-show-caret -fdiagnostics-color=never -O -flto -save-temps -o 
gcc-dg-lto-save-temps-01.exe
[...]/build/gcc/xgcc @/tmp/ccjomvFW
[...]/build/gcc/xgcc @/tmp/ccAM0t6j
output is:
[...]/build/gcc/xgcc @/tmp/ccjomvFW
[...]/build/gcc/xgcc @/tmp/ccAM0t6j

FAIL: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o link, 
 -O -flto -save-temps
UNRESOLVED: gcc.dg/lto/save-temps c_lto_save-temps_0.o-c_lto_save-temps_0.o 
execute  -O -flto -save-temps


Grüße,
 Thomas


pgp9XddbCIn1S.pgp
Description: PGP signature

[C++ Patch] PR 61088

[Paolo Carlini]

Hi,

again, a simple core issue, an ICE on invalid, with some rather more 
interesting side issues. The core is that we are not enforcing that an 
incomplete type cannot be captured by value. Thus the add_capture check. 
Then:
1- I'm also adding the early error_mark_node check because otherwise in 
some cases we ICE during error recovery when COMPLETE_TYPE_P gets an 
error_mark_node. I added the second function g() in the testcase to 
cover that.
2- I wish I could just do type = error_mark_node, for the by value 
capture error, like we do above for the VLA-related error, instead of 
returning error_mark_node, but that would result in a suboptimal 
diagnostic for the existing lambda-ice7.C. For it, we used to produce:


lambda-ice7.C: In function ‘void foo(A&)’:
lambda-ice7.C:8:3: error: invalid use of incomplete type ‘struct A’
[=](){a;};
^
lambda-ice7.C:4:8: error: forward declaration of ‘struct A’
struct A;
^
lambda-ice7.C:8:3: error: invalid use of incomplete type ‘struct A’
[=](){a;};
^
lambda-ice7.C:4:8: error: forward declaration of ‘struct A’
struct A;
^

and, after the patch:

lambda-ice7.C: In lambda function:
lambda-ice7.C:8:9: error: cannot capture by value ‘a’ of incomplete type ‘A’
[=](){a;};
^
lambda-ice7.C:4:8: note: forward declaration of ‘struct A’
struct A;
^

which I think is nearly optimal. With type = error_mark_node we would 
only add an additional error to the former.


3- The cxx_incomplete_type_inform check is because in some cases 
TYPE_MAIN_DECL can indeed be null (traditionally we used + which means 
location_of, which handles that). This happens for example for f() in 
the new testcase, and we don't emit any inform for it (at variance with 
lambda-ice7.C, for example). I think it's fine.


4- Finally, something I noticed while working on add_capture: right 
above the new check there is:


type = lambda_capture_field_type (initializer, explicit_init_p);
if (by_reference_p)
{
type = build_reference_type (type);
if (!real_lvalue_p (initializer))
error ("cannot capture %qE by reference", initializer);
}

now, interestingly, nothing in the testsuite exercises this error. And, 
so far, I failed to create a testcase for it. The Standard too doesn't 
seem to me so clear about that. Ideas?!?


Thanks!
Paolo.

/

/cp
2014-05-22  Paolo Carlini  

PR c++/61088
* lambda.c (add_capture): Enforce that capture by value requires
complete type.
* typeck2.c (cxx_incomplete_type_inform): Early return if
TYPE_MAIN_DECL is null.

/testsuite
2014-05-22  Paolo Carlini  

PR c++/61088
* g++.dg/cpp0x/lambda/lambda-ice13.C: New.
* g++.dg/cpp0x/lambda/lambda-ice7.C: Adjust.
Index: cp/lambda.c
===
--- cp/lambda.c (revision 210682)
+++ cp/lambda.c (working copy)
@@ -456,6 +456,9 @@ add_capture (tree lambda, tree id, tree orig_init,
 initializer = build_x_compound_expr_from_list (initializer, ELK_INIT,
   tf_warning_or_error);
   type = TREE_TYPE (initializer);
+  if (type == error_mark_node)
+return error_mark_node;
+
   if (array_of_runtime_bound_p (type))
 {
   vla = true;
@@ -492,8 +495,17 @@ add_capture (tree lambda, tree id, tree orig_init,
error ("cannot capture %qE by reference", initializer);
}
   else
-   /* Capture by copy requires a complete type.  */
-   type = complete_type (type);
+   {
+ /* Capture by copy requires a complete type.  */
+ type = complete_type (type);
+ if (!dependent_type_p (type) && !COMPLETE_TYPE_P (type))
+   {
+ error ("cannot capture by value %qE of incomplete "
+"type %qT", initializer, type);
+ cxx_incomplete_type_inform (type);
+ return error_mark_node;
+   }
+   }
 }
 
   /* Add __ to the beginning of the field name so that user code
Index: cp/typeck2.c
===
--- cp/typeck2.c(revision 210682)
+++ cp/typeck2.c(working copy)
@@ -434,6 +434,9 @@ abstract_virtuals_error (abstract_class_use use, t
 void
 cxx_incomplete_type_inform (const_tree type)
 {
+  if (!TYPE_MAIN_DECL (type))
+return;
+
   location_t loc = DECL_SOURCE_LOCATION (TYPE_MAIN_DECL (type));
   tree ptype = strip_top_quals (CONST_CAST_TREE (type));
 
Index: testsuite/g++.dg/cpp0x/lambda/lambda-ice13.C
===
--- testsuite/g++.dg/cpp0x/lambda/lambda-ice13.C(revision 0)
+++ testsuite/g++.dg/cpp0x/lambda/lambda-ice13.C(working copy)
@@ -0,0 +1,14 @@
+// PR c++/61088
+// { dg-do compile { target c++11 } }
+
+void f()
+{
+  typedef void (*X) ();
+  X x[] = { [x](){} };  // { dg-error "incomplete type" }
+}
+
+void g()
+{
+  typedef void (X) ();
+  X x[] = { [x](){} };  // { dg-error "array of functions

Re: libsanitizer merge from upstream r208536

[Paolo Carlini]

.. sorry, I didn't follow the whole thread, but today I'm seeing loads 
of failures when testing C++ on x86_64-linux, beginning with:


FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test
FAIL: c-c++-common/asan/asan-interface-1.c  -O1  execution test
FAIL: c-c++-common/asan/asan-interface-1.c  -O2  execution test
FAIL: c-c++-common/asan/asan-interface-1.c  -O3 -fomit-frame-pointer  
execution test

FAIL: c-c++-common/asan/asan-interface-1.c  -O3 -g  execution test
FAIL: c-c++-common/asan/asan-interface-1.c  -Os  execution test
FAIL: c-c++-common/asan/asan-interface-1.c  -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/asan/asan-interface-1.c  -O2 -flto 
-fuse-linker-plugin -fno-fat-lto-objects  execution test

...

this is already being addressed, right? Because I cannot really work.

Thanks,
Paolo.

Re: [PATCH i386 5/8] [AVX-512] Extend vectorizer hooks.

[Kirill Yukhin]

Hello,
On 20 May 08:24, H.J. Lu wrote:
> ABI alignment should be sufficient for correctness. Bigger alignments
> are supposed to give better performance.  Can you try this patch on
> HSW and SLM to see if it has any impact on performance?

Here is perf. data of your patch.

Only HSW so far

HSW, 64 bits, base

Test Previous Current Ratio(%)
400.perlbench 37.700037.7000 +0%
401.bzip2 24.800024.7000 -0.40%
403.gcc   35.100035.2000 +0.28%
429.mcf   41.700042. +0.71%
445.gobmk 26.900027. +0.37%
456.hmmer 27.200027.2000 +0%
458.sjeng 30.200030.1000 -0.33%
462.libquantum77.400076.7000 -0.90%
464.h264ref   52.500052.8000 +0.57%
471.omnetpp   23.800023.7000 -0.42%
473.astar 23.200023.1000 -0.43%
483.xalancbmk 39.800040.1000 +0.75%
410.bwaves78.400078.5000 +0.12%
416.gamess33.900033.9000 +0%
433.milc  34.700034.8000 +0.28%
434.zeusmp38.600038.4000 -0.51%
435.gromacs   26.900027. +0.37%
436.cactusADM 54.700062. +13.34%
437.leslie3d  45.300045.3000 +0%
444.namd  27.200027.1000 -0.36%
447.dealII56.700056.7000 +0%
450.soplex39.300039.3000 +0%
453.povray49.49.1000 +0.20%
454.calculix  28.800029.3000 +1.73%
459.GemsFDTD  38.900039. +0.25%
465.tonto 23.100023.3000 +0.86%
470.lbm   55.300055.6000 +0.54%
481.wrf   40.800040.8000 +0%
482.sphinx3   47.800047.9000 +0.20%

HSW, 64 bits, o2

Test Previous Current Ratio(%)
400.perlbench 39.700039.7000 +0%
401.bzip2 25.100025.1000 +0%
403.gcc   33.700033.7000 +0%
429.mcf   40.100039.9000 -0.49%
445.gobmk 26.500026.4000 -0.37%
456.hmmer 24.800024.8000 +0%
458.sjeng 28.400028.5000 +0.35%
462.libquantum74.400074.4000 +0%
464.h264ref   50.100050.3000 +0.39%
471.omnetpp   22.600022.5000 -0.44%
473.astar 20.700021. +1.44%
483.xalancbmk 37.37.4000 +1.08%
410.bwaves60.100060.1000 +0%
416.gamess35.500035.4000 -0.28%
433.milc  29.900029.8000 -0.33%
434.zeusmp34.800034.6000 -0.57%
435.gromacs   27.400027.5000 +0.36%
436.cactusADM 32.300033.8000 +4.64%
437.leslie3d  32.600032.6000 +0%
444.namd  26.900026.9000 +0%
447.dealII45.200045.1000 -0.22%
450.soplex42.500042.6000 +0.23%
453.povray45.900046.1000 +0.43%
454.calculix  12.900012.9000 +0%
459.GemsFDTD  38.600038.7000 +0.25%
465.tonto 23.700023.8000 +0.42%
470.lbm   56.700056.7000 +0%
481.wrf   28.900028.9000 +0%
482.sphinx3   43.900043.8000 -0.22%

--
Thanks, K

Re: libsanitizer merge from upstream r208536

[Konstantin Serebryany]

On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
 wrote:
> .. sorry, I didn't follow the whole thread, but today I'm seeing loads of
> failures when testing C++ on x86_64-linux, beginning with:
>
> FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test
Is that before or after r210743?
> FAIL: c-c++-common/asan/asan-interface-1.c  -O1  execution test
> FAIL: c-c++-common/asan/asan-interface-1.c  -O2  execution test
> FAIL: c-c++-common/asan/asan-interface-1.c  -O3 -fomit-frame-pointer
> execution test
> FAIL: c-c++-common/asan/asan-interface-1.c  -O3 -g  execution test
> FAIL: c-c++-common/asan/asan-interface-1.c  -Os  execution test
> FAIL: c-c++-common/asan/asan-interface-1.c  -O2 -flto -fno-use-linker-plugin
> -flto-partition=none  execution test
> FAIL: c-c++-common/asan/asan-interface-1.c  -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects  execution test
> ...
>
> this is already being addressed, right? Because I cannot really work.
>
> Thanks,
> Paolo.
>
>

Re: patch to fix PR60969

[Ramana Radhakrishnan]

>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969
>> FAIL: gcc.target/aarch64/table-intrinsics.c (internal compiler error)
>> FAIL: gcc.target/aarch64/table-intrinsics.c (test for excess errors)
>> Excess errors:
>> /work/gcc-clean/src/gcc/gcc/testsuite/gcc.target/aarch64/table-intrinsics.c:172:1:
>>  internal compiler error: Max. number of generated reload insns per insn is 
>> achieved (90)
>> 0x8923cd lra_constraints(bool)
>>   /work/gcc-clean/src/gcc/gcc/lra-constraints.c:4140
>> 0x882f62 lra(_IO_FILE*)
>>   /work/gcc-clean/src/gcc/gcc/lra.c:2353
>> 0x8453f6 do_reload
>>   /work/gcc-clean/src/gcc/gcc/ira.c:5457
>> 0x8453f6 execute
>>   /work/gcc-clean/src/gcc/gcc/ira.c:5618
>>
>>
> Sorry, I have no aarch64 machine.  Could you sent me the pre-processed
> file of the test.


Please find inline a reduced testcase that fails.

Compiler configured with

$SRC/gcc/configure --target=aarch64-none-elf



$>./xgcc -B`pwd` -S -O2 try.c
try.c: In function 'qtbl_tests8_2':
try.c:26:1: internal compiler error: Max. number of generated reload
insns per insn is achieved (90)

 }
 ^
0x8653f7 lra_constraints(bool)
/work/wa1/src/gcc/gcc/lra-constraints.c:4140
0x855ca6 lra(_IO_FILE*)
/work/wa1/src/gcc/gcc/lra.c:2353
0x81eada do_reload
/work/wa1/src/gcc/gcc/ira.c:5457
0x81eada execute
/work/wa1/src/gcc/gcc/ira.c:5618
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compilation status=1


$>cat try.c
typedef __builtin_aarch64_simd_qi int8x8_t
  __attribute__ ((__vector_size__ (8)));
typedef __builtin_aarch64_simd_uqi uint8x8_t
  __attribute__ ((__vector_size__ (8)));
typedef __builtin_aarch64_simd_qi int8x16_t
  __attribute__ ((__vector_size__ (16)));
typedef struct int8x16x2_t
{
  int8x16_t val[2];
} int8x16x2_t;
__extension__ static __inline int8x8_t __attribute__ ((__always_inline__))
vqtbl2_s8 (int8x16x2_t tab, uint8x8_t idx)
{
  int8x8_t result;
  __asm__ ("ld1 {v16.16b, v17.16b}, %1\n\t"
:"=w"(result)
:"Q"(tab),"w"(idx)
:"memory", "v16", "v17");
  return result;
}
int8x8_t
qtbl_tests8_2 (int8x16x2_t tab, uint8x8_t idx)
{
  return vqtbl2_s8 (tab, idx);
}




>
>

Re: [PATCH] Add support for GNU/Hurd in gnat-4.9

[Arnaud Charlet]

BTW,

> I wonder ho the kfreebsd people managed to get accepted upstream?

This is typically a good example of patches being accepted too rapidly,
and leading to maintenance issues, see:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56274

for which nobody is stepping up to fix.
So we might well end up removing support for Ada/kfreebsd soon.

Arno

Re: libsanitizer merge from upstream r208536

[Paolo Carlini]

Hi,

On 22 maggio 2014 11:05:31 CEST, Konstantin Serebryany 
 wrote:
>On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
> wrote:
>> .. sorry, I didn't follow the whole thread, but today I'm seeing
>loads of
>> failures when testing C++ on x86_64-linux, beginning with:
>>
>> FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test
>Is that before or after r210743?

This is after the merge, up to date tree 30 mins ago. Yesterday everything was 
ok, as usual.

Paolo

Re: libsanitizer merge from upstream r208536

[Jakub Jelinek]

On Thu, May 22, 2014 at 11:44:06AM +0200, Paolo Carlini wrote:
> On 22 maggio 2014 11:05:31 CEST, Konstantin Serebryany 
>  wrote:
> >On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
> > wrote:
> >> .. sorry, I didn't follow the whole thread, but today I'm seeing
> >loads of
> >> failures when testing C++ on x86_64-linux, beginning with:
> >>
> >> FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test
> >Is that before or after r210743?
> 
> This is after the merge, up to date tree 30 mins ago. Yesterday everything 
> was ok, as usual.

Yesterday

FAIL: c-c++-common/asan/asan-interface-1.c  -O0  (test for excess errors)
UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O0  compilation failed to 
produce executable
FAIL: c-c++-common/asan/asan-interface-1.c  -O1  (test for excess errors)
UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O1  compilation failed to 
produce executable
FAIL: c-c++-common/asan/asan-interface-1.c  -O2  (test for excess errors)
UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O2  compilation failed to 
produce executable
FAIL: c-c++-common/asan/asan-interface-1.c  -O3 -fomit-frame-pointer  (test for 
excess errors)
UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O3 -fomit-frame-pointer  
compilation failed to produce executable
FAIL: c-c++-common/asan/asan-interface-1.c  -O3 -g  (test for excess errors)
UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O3 -g  compilation failed to 
produce executable
FAIL: c-c++-common/asan/asan-interface-1.c  -Os  (test for excess errors)
UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -Os  compilation failed to 
produce executable
FAIL: c-c++-common/asan/asan-interface-1.c  -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  (test for excess errors)
UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  compilation failed to produce 
executable
FAIL: c-c++-common/asan/asan-interface-1.c  -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  (test for excess errors)
UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  compilation failed to produce executable

failed for C, but not C++.

Jakub

Re: [PATCH] Fix PR 61225

[Zhenqiang Chen]

On 21 May 2014 20:43, Steven Bosscher  wrote:
> On Wed, May 21, 2014 at 11:58 AM, Zhenqiang Chen wrote:
>> Hi,
>>
>> The patch fixes the gcc.target/i386/pr49095.c FAIL in PR61225. The
>> test case tends to check a peephole2 optimization, which optimizes the
>> following sequence
>>
>> 2: bx:SI=ax:SI
>> 25: ax:SI=[bx:SI]
>> 7: {ax:SI=ax:SI-0x1;clobber flags:CC;}
>> 8: [bx:SI]=ax:SI
>> 9: flags:CCZ=cmp(ax:SI,0)
>> to
>>2: bx:SI=ax:SI
>>41: {flags:CCZ=cmp([bx:SI]-0x1,0);[bx:SI]=[bx:SI]-0x1;}
>>
>> The enhanced shrink-wrapping, which calls copyprop_hardreg_forward
>> changes the INSN 25 to
>>
>> 25: ax:SI=[ax:SI]
>>
>> Then peephole2 can not optimize it since two memory_operands look like
>> different.
>>
>> To fix it, the patch adds another peephole2 rule to read one more
>> insn. From the register copy, it knows the address is the same.
>
> That is one complex peephole2 to deal with a transformation like this.
> It seems to be like it's a too specific solution for a bigger problem.
>
> Could you please try one of the following solutions instead:
>
> 1. Track register values for peephole2 and try different alternatives
> based on known register equivalences? E.g. in your example, perhaps
> there is already a REG_EQUAL/REG_EQUIV note available on insn 25 after
> copyprop_hardreg_forward, to annotate that [ax:SI] is equivalent to
> [bx:SI] at that point (or if that information is not available, it is
> not very difficult to make it available). Then you could try applying
> peephole2 on the original pattern but also on patterns modified with
> the known equivalences (i.e. try peephole2 on multiple equivalent
> patterns for the same insn). This may expose other peephole2
> opportunities, not just the specific one your patch addresses.

Patch is updated according to the comment. There is no REG_EQUAL. So I
add it when replace_oldest_value_reg.

ChangeLog:
2014-05-22  Zhenqiang Chen  

Part of PR rtl-optimization/61225
* config/i386/i386-protos.h (ix86_peephole2_rtx_equal_p): New proto.
* config/i386/i386.c (ix86_peephole2_rtx_equal_p): New function.
* regcprop.c (replace_oldest_value_reg): Add REG_EQUAL note when
propagating to SET.

diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index 39462bd..0c4a2b9 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -42,6 +42,7 @@ extern enum calling_abi ix86_function_type_abi (const_tree);

 extern void ix86_reset_previous_fndecl (void);

+extern bool ix86_peephole2_rtx_equal_p (rtx, rtx, rtx, rtx);
 #ifdef RTX_CODE
 extern int standard_80387_constant_p (rtx);
 extern const char *standard_80387_constant_opcode (rtx);
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6ffb788..583ebe8 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -46856,6 +46856,29 @@ ix86_atomic_assign_expand_fenv (tree *hold,
tree *clear, tree *update)
atomic_feraiseexcept_call);
 }

+/* OP0 is the SET_DEST of INSN and OP1 is the SET_SRC of INSN.
+   Check whether OP1 and OP6 is equal.  */
+
+bool
+ix86_peephole2_rtx_equal_p (rtx insn, rtx op0, rtx op1, rtx op6)
+{
+  rtx note;
+
+  if (!reg_overlap_mentioned_p (op0, op1) && rtx_equal_p (op1, op6))
+return true;
+
+  gcc_assert (single_set (insn)
+ && op0 == SET_DEST (single_set (insn))
+ && op1 == SET_SRC (single_set (insn)));
+
+  note = find_reg_note (insn, REG_EQUAL, NULL_RTX);
+  if (note
+  && !reg_overlap_mentioned_p (op0, XEXP (note, 0))
+  && rtx_equal_p (XEXP (note, 0), op6))
+return true;
+
+  return false;
+}
 /* Initialize the GCC target structure.  */
 #undef TARGET_RETURN_IN_MEMORY
 #define TARGET_RETURN_IN_MEMORY ix86_return_in_memory
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 44e80ec..b57fc86 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -16996,11 +16996,12 @@
 [(match_dup 0)
  (match_operand:SWI 2 "")]))
  (clobber (reg:CC FLAGS_REG))])
-   (set (match_dup 1) (match_dup 0))
+   (set (match_operand:SWI 6 "memory_operand") (match_dup 0))
(set (reg FLAGS_REG) (compare (match_dup 0) (const_int 0)))]
   "(TARGET_READ_MODIFY_WRITE || optimize_insn_for_size_p ())
&& peep2_reg_dead_p (4, operands[0])
-   && !reg_overlap_mentioned_p (operands[0], operands[1])
+   && ix86_peephole2_rtx_equal_p (peep2_next_insn (0), operands[0],
+ operands[1], operands[6])
&& !reg_overlap_mentioned_p (operands[0], operands[2])
&& (mode != QImode
|| immediate_operand (operands[2], QImode)
diff --git a/gcc/regcprop.c b/gcc/regcprop.c
index 7a5a4f6..4e09724 100644
--- a/gcc/regcprop.c
+++ b/gcc/regcprop.c
@@ -510,6 +510,22 @@ replace_oldest_value_reg (rtx *loc, enum
reg_class cl, rtx insn,
fprintf (dump_file, "insn %u: replaced reg %u with %u\n",
 INSN_UID (insn), REGN

Re: [PATCH][RFC] Handle realloc in PTA and alias analysis

[Richard Biener]

On Wed, 21 May 2014, Richard Biener wrote:

> On Wed, 21 May 2014, Richard Biener wrote:
> 
> > 
> > PR56955 prompted me to handle BUILT_IN_REALLOC just the same
> > way we already handle BUILT_IN_STR[N]DUP.
> > 
> > Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> > 
> > Now this will disambiguate *p and *q for p = realloc (q, n)
> > for any value of n (including those that don't actually
> > trigger re-allocation and thus where p == q after the call).
> > I don't think that any such use would be valid - but I can
> > certainly play safer here and implement the points-to part
> > as a pass-through (that is, make p point to what q points).
> > That's of course less optimization.
> 
> Like with incremental
> 
> Index: gcc/tree-ssa-structalias.c
> ===
> --- gcc/tree-ssa-structalias.c.orig 2014-05-21 15:37:58.762890034 
> +0200
> +++ gcc/tree-ssa-structalias.c  2014-05-21 15:35:52.044898758 +0200
> @@ -4313,6 +4313,17 @@ find_func_aliases_for_builtin_call (stru
> process_all_all_constraints (lhsc, rhsc);
> lhsc.release ();
> rhsc.release ();
> +   /* For realloc the resulting pointer can be equal to the
> +  argument as well.  But only doing this wouldn't be
> +  correct because with ptr == 0 realloc behaves like malloc.  
> */
> +   if (DECL_FUNCTION_CODE (fndecl) == BUILT_IN_REALLOC)
> + {
> +   get_constraint_for (gimple_call_lhs (t), &lhsc);
> +   get_constraint_for (gimple_call_arg (t, 0), &rhsc);
> +   process_all_all_constraints (lhsc, rhsc);
> +   lhsc.release ();
> +   rhsc.release ();
> + }
> return true;
>   }
> break;
> 
> that of course makes it a somewhat pointless excercise if
> points-to doesn't figure out sth fancy for the argument to
> realloc (like its NULL or the result of an earlier malloc call,
> still optimizes the testcase as expected).

The following is what I have applied after bootstrapping and
testing on x86_64-unknown-linux-gnu.

Richard.

2014-05-21  Richard Biener  

* tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Handle
BUILT_IN_REALLOC like BUILT_IN_STRDUP.
(call_may_clobber_ref_p_1): Handle BUILT_IN_REALLOC as allocation
and deallocation site.
* tree-ssa-structalias.c (find_func_aliases_for_builtin_call):
Handle BUILT_IN_REALLOC similar to BUILT_IN_STRDUP with also
passing through the incoming points-to set.
(handle_lhs_call): Use flags argument instead of recomputing it.
(find_func_aliases_for_call): Call handle_lhs_call with proper
call return flags.

* gcc.dg/tree-ssa/alias-33.c: New testcase.

Index: gcc/tree-ssa-alias.c
===
*** gcc/tree-ssa-alias.c.orig   2014-05-21 16:21:18.995711011 +0200
--- gcc/tree-ssa-alias.c2014-05-22 09:44:40.940400943 +0200
*** ref_maybe_used_by_call_p_1 (gimple call,
*** 1594,1599 
--- 1594,1600 
/* These read memory pointed to by the first argument.  */
case BUILT_IN_STRDUP:
case BUILT_IN_STRNDUP:
+   case BUILT_IN_REALLOC:
  {
ao_ref dref;
tree size = NULL_TREE;
*** call_may_clobber_ref_p_1 (gimple call, a
*** 1991,1996 
--- 1992,2006 
tree ptr = gimple_call_arg (call, 0);
return ptr_deref_may_alias_ref_p_1 (ptr, ref);
  }
+   /* Realloc serves both as allocation point and deallocation point.  */
+   case BUILT_IN_REALLOC:
+ {
+   tree ptr = gimple_call_arg (call, 0);
+   /* Unix98 specifies that errno is set on allocation failure.  */
+   return ((flag_errno_math
+&& targetm.ref_may_alias_errno (ref))
+   || ptr_deref_may_alias_ref_p_1 (ptr, ref));
+ }
case BUILT_IN_GAMMA_R:
case BUILT_IN_GAMMAF_R:
case BUILT_IN_GAMMAL_R:
Index: gcc/tree-ssa-structalias.c
===
*** gcc/tree-ssa-structalias.c.orig 2014-05-21 16:21:18.995711011 +0200
--- gcc/tree-ssa-structalias.c  2014-05-22 09:43:05.807407492 +0200
*** handle_lhs_call (gimple stmt, tree lhs,
*** 3974,3980 
  
/* If the call returns an argument unmodified override the rhs
   constraints.  */
-   flags = gimple_call_return_flags (stmt);
if (flags & ERF_RETURNS_ARG
&& (flags & ERF_RETURN_ARG_MASK) < gimple_call_num_args (stmt))
  {
--- 3974,3979 
*** find_func_aliases_for_builtin_call (stru
*** 4299,4307 
return true;
case BUILT_IN_STRDUP:
case BUILT_IN_STRNDUP:
if (gimple_call_lhs (t))
  {
!   handle_lhs_call (t, gimple_call_lhs (t), gimple_call_flags (t),
  

Re: [PATCH] Fix PR54733 Optimize endian independent load/store

[Richard Biener]

On Wed, May 21, 2014 at 3:00 AM, Thomas Preud'homme
 wrote:
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>>
>> I'll send the new patch as soon as all the tests are done.
>
> Here you are. I also simplified the tests a bit having the reference as a 
> function
> parameter instead of a local one.
>
> Updated ChangeLogs:
>
> *** gcc/ChangeLog ***
>
> 2014-05-20  Thomas Preud'homme  
>
> PR tree-optimization/54733
> * tree-ssa-math-opts.c (nop_stats): New "bswap_stats" structure.
> (CMPNOP): Define.
> (find_bswap_or_nop_load): New.
> (find_bswap_1): Renamed to ...
> (find_bswap_or_nop_1): This. Also add support for memory source.
> (find_bswap): Renamed to ...
> (find_bswap_or_nop): This. Also add support for memory source and
> detection of bitwise operations equivalent to load in host endianness.
> (execute_optimize_bswap): Likewise. Also move its leading comment back
> in place and split statement transformation into ...
> (bswap_replace): This.
>
> *** gcc/testsuite/ChangeLog ***
>
> 2014-05-20  Thomas Preud'homme  
>
> PR tree-optimization/54733
> * gcc.dg/optimize-bswapdi-3.c: New test to check extension of bswap
> optimization to support memory sources and bitwise operations
> equivalent to load in host endianness.
> * gcc.dg/optimize-bswaphi-1.c: Likewise.
> * gcc.dg/optimize-bswapsi-2.c: Likewise.
> * gcc.c-torture/execute/bswap-2.c: Likewise.
>
> Best regards,

This is ok.

Thanks,
Richard.

> Thomas

[PATCH, ARM, v2] Improve 64 bit division performance

[Charles Baylis]

On 1 May 2014 16:41, Richard Earnshaw  wrote:
> I think really, you've got three independent changes here:

Version 2 of this patch series is now a 9 patch series which addresses
most of the following. Exceptions discussed below.

> 1) Optimize the prologue/epilogue sequences when ldrd is available.
> 2) Replace the call to __gnu_ldivmod_helper with __udivmoddi4

I assume you mean __gnu_uldivmod_helper here, as __gnu_ldivmod_helper
performs signed division and can't be directly replaced with the
unsigned division performed by __udivmoddi4.

> 3) Optimize the code to __aeabi_ldivmod.

Converting to call __udivmoddi4, fixing up signedness of operands and
results and optimisation are all one change.

> Ideally, therefore, this is a three patch series, but it's then missing
> a few bits.
>
> 4) Step 2 can also be trivially applied to bpabi-v6m.S as well, since
> it's a direct swap of one function for another (unless I've misread the
> changes, I think the ABI of the two helper functions are the same).

For __aeabi_uldivmod this is true. For __aeabi_ldivmod this is not
trivial as the signedness fix-ups must be written.

> 5) Step 4 then makes __gnu_ldivmod_helper in bpabi.c a dead function
> which can be deleted.  This is good because currently pulling in either
> 64-bit division function causes both these helper functions to be pulled
> in and thus the whole of the 64-bit div-mod code for both signed and
> unsigned values.   That's particularly unfortunate for ARMv6m class
> devices as that's potentially a lot of redundant code.

Similarly, __gnu_uldivmod_helper not __gnu_ldivmod_helper.

I've included two patches which do the trivial steps for the unsigned case.

>
> Finally, I know this was the original code, but the complete lack of
> comments in this code made reviewing even the trivial parts a complete
> nightmare -- it took me half an hour before I remembered that
> __udivmoddi4 took three parameters, the third of which was on the stack:
> thus the messing around with sp/ip in the prologue wasn't just trivial
> padding but a necessary part of the function.  Please could you add, at
> least some short comments clarifying the register disposition on input
> and what that prologue code is up to...

Done.

> Finally, how was this code tested?

It has been built and "make check" has been run with no regressions on:
arm-unknown-linux-gnueabihf --with-mode=thumb --with-arch=armv7-a
arm-unknown-linux-gnueabihf --with-mode=arm --with-arch=armv7-a
arm-unknown-linux-gnueabi --with-mode=arm --with-arch=armv5te
arm-unknown-linux-gnueabi --with-mode=arm --with-arch=armv4t

I have also run a simple test harness which checks the result of
several 64 bit division operations where gcc has been built with the
above configurations.

I am not currently set up with a way to test v6M, so those parts aren't tested.

> Anyway, some additional comments below:
>
> Don't repeat the function name for multiple tweaks to the same function;
> as mentioned above, if these are really separate changes they should be
> in separate submissions.  Mixing unrelated changes just makes the
> reviewing step that much harder.

Done.


>> + strd ip,lr, [sp, #-16]!
>
> Space after comma.

Done

> Also, since you've essentially rewritten the entire function, can you
> please also reformat them to follow the coding style of the rest of the
> file: namely "OPoperands".

Done

>>  #else
>> + sub sp, sp, #8
>>   do_push {sp, lr}
>>  #endif
>
> Please add a comment that the value at *sp is the address of the the
> slot for the remainder.

Done
>> +#if defined(__thumb2__) && CAN_USE_LDRD
>> + sub ip, sp, #8
>> + strd ip,lr, [sp, #-16]!
>
> Space after comma.

Done

>>  #else
>> + sub sp, sp, #8
>>   do_push {sp, lr}
>>  #endif
>> + cmp xxh, #0
>> + blt 1f
>> + cmp yyh, #0
>> + blt 2f
>> +
>> +98:  cfi_push 98b - __aeabi_ldivmod, 0xe, -0xc, 0x10
>
> The CFI push should really precede your conditional tests, it relates to
> the do_push expression.

Done.

>> + bl SYM(__udivmoddi4) __PLT__
>> + ldr lr, [sp, #4]
>> +#if CAN_USE_LDRD
>> + ldrd r2, r3, [sp, #8]
>> + add sp, sp, #16
>> +#else
>> + add sp, sp, #8
>> + do_pop {r2, r3}
>> +#endif
>
> You're missing a CFI pop, which is needed when the values on the stack
> go out of scope.

The existing code doesn't do this. Since there are multiple exit
points from the optimised function the existing cfi_* macros aren't
sufficient (there is no cfi_save_state/cfi_restore_state), so I have
included a patch which uses the gas .cfi_* directives. This may be
interesting on non-DWARF or non-ELF platforms, if any are still
supported .

>> + RET
>> +1: /* xxh:xxl is negative */
>> + rsbs xxl, xxl, #0
>
> We're using unified syntax, so NEGS is preferable.

Done

>> + sbc xxh, xxh, xxh, lsl #1
>
> Worthy of a comment, Thumb2 has no RSC instruction, so use X - 2X.

Done

>> + cmp yyh, #0
>> + blt 3f
>> +98:  cfi_push 98b - __aeabi_ldivmod, 

Re: libsanitizer merge from upstream r208536

[Konstantin Serebryany]

What is the exact command are you running?

On Thu, May 22, 2014 at 1:47 PM, Jakub Jelinek  wrote:
> On Thu, May 22, 2014 at 11:44:06AM +0200, Paolo Carlini wrote:
>> On 22 maggio 2014 11:05:31 CEST, Konstantin Serebryany 
>>  wrote:
>> >On Thu, May 22, 2014 at 12:54 PM, Paolo Carlini
>> > wrote:
>> >> .. sorry, I didn't follow the whole thread, but today I'm seeing
>> >loads of
>> >> failures when testing C++ on x86_64-linux, beginning with:
>> >>
>> >> FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test
>> >Is that before or after r210743?
>>
>> This is after the merge, up to date tree 30 mins ago. Yesterday everything 
>> was ok, as usual.
>
> Yesterday
>
> FAIL: c-c++-common/asan/asan-interface-1.c  -O0  (test for excess errors)
> UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O0  compilation failed to 
> produce executable
> FAIL: c-c++-common/asan/asan-interface-1.c  -O1  (test for excess errors)
> UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O1  compilation failed to 
> produce executable
> FAIL: c-c++-common/asan/asan-interface-1.c  -O2  (test for excess errors)
> UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O2  compilation failed to 
> produce executable
> FAIL: c-c++-common/asan/asan-interface-1.c  -O3 -fomit-frame-pointer  (test 
> for excess errors)
> UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O3 -fomit-frame-pointer  
> compilation failed to produce executable
> FAIL: c-c++-common/asan/asan-interface-1.c  -O3 -g  (test for excess errors)
> UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O3 -g  compilation failed 
> to produce executable
> FAIL: c-c++-common/asan/asan-interface-1.c  -Os  (test for excess errors)
> UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -Os  compilation failed to 
> produce executable
> FAIL: c-c++-common/asan/asan-interface-1.c  -O2 -flto -fno-use-linker-plugin 
> -flto-partition=none  (test for excess errors)
> UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O2 -flto 
> -fno-use-linker-plugin -flto-partition=none  compilation failed to produce 
> executable
> FAIL: c-c++-common/asan/asan-interface-1.c  -O2 -flto -fuse-linker-plugin 
> -fno-fat-lto-objects  (test for excess errors)
> UNRESOLVED: c-c++-common/asan/asan-interface-1.c  -O2 -flto 
> -fuse-linker-plugin -fno-fat-lto-objects  compilation failed to produce 
> executable
>
> failed for C, but not C++.
>
> Jakub

Re: libsanitizer merge from upstream r208536

[Paolo Carlini]

Hi

On 22 maggio 2014 12:26:19 CEST, Konstantin Serebryany 
 wrote:
>What is the exact command are you running?

Sorry, now I'm traveling. But nothing special, a very simple c and c++ build on 
x86_64-linux. No special flags, all defaults. If nobody can reproduce I'll try 
to fetch again the tree from scratch. Weird, anyway.

Paolo

Re: lto-plugin: mismatch between ld's architecture and GCC's configure --host

[Thomas Schwinge]

Hi!

Now that GCC again is in development stage, and with fresh hope to have
someone review this patch submission, after having let the issue rest for
several months: I just re-tested the current versions.  Still there are
no changes for a "regular" build (not using the new configure options).
On the other hand, configuring GCC as described in the documentation
update, it is possible to use the 32-bit x86 linker for/with a x86_64
build, and get the very same GCC test results as when using a x86_64
linker.  See

for the whole story.

The patches looked fine to Cary, but he says they need approval by a
global maintainer or build machinery maintainer.

commit 64cb4b8443eee67eeccc6b6996b0b66856a86990
Author: Thomas Schwinge 
AuthorDate: Sun Oct 13 16:15:56 2013 +0200
Commit: Thomas Schwinge 
CommitDate: Wed May 21 07:24:01 2014 +0200

Allow overriding the libiberty used for building the LTO plugin.

lto-plugin/
* configure.ac (--with-libiberty): New configure option.
* configure: Regenerate.
* Makefile.am (libiberty, libiberty_noasan, libiberty_pic): New
variables.
(liblto_plugin_la_LIBADD, liblto_plugin_la_LDFLAGS)
(liblto_plugin_la_DEPENDENCIES): Use them.
* Makefile.in: Regenerate.
---
 lto-plugin/Makefile.am  | 31 +--
 lto-plugin/Makefile.in  | 32 +---
 lto-plugin/configure| 17 +++--
 lto-plugin/configure.ac |  5 +
 4 files changed, 54 insertions(+), 31 deletions(-)

diff --git lto-plugin/Makefile.am lto-plugin/Makefile.am
index bbb92f9..f3fb89b 100644
--- lto-plugin/Makefile.am
+++ lto-plugin/Makefile.am
@@ -18,22 +18,25 @@ libexecsub_LTLIBRARIES = liblto_plugin.la
 gcc_build_dir = ../$(host_subdir)/gcc
 in_gcc_libs = $(foreach lib, $(libexecsub_LTLIBRARIES), 
$(gcc_build_dir)/$(lib))
 
-# Can be removed when libiberty becomes a normal convenience library
-Wc=-Wc,
-LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
-
 liblto_plugin_la_SOURCES = lto-plugin.c
-liblto_plugin_la_LIBADD = \
-   $(if $(wildcard 
../libiberty/noasan/libiberty.a),$(Wc)../libiberty/noasan/libiberty.a, \
-   $(if $(wildcard 
../libiberty/pic/libiberty.a),$(Wc)../libiberty/pic/libiberty.a,))
-# Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS
+# Note that we intentionally override the bindir supplied by ACX_LT_HOST_FLAGS.
 liblto_plugin_la_LDFLAGS = $(AM_LDFLAGS) \
-   $(lt_host_flags) -module -bindir $(libexecsubdir) \
-   $(if $(wildcard ../libiberty/noasan/libiberty.a),, \
-   $(if $(wildcard 
../libiberty/pic/libiberty.a),,-Wc,../libiberty/libiberty.a))
-liblto_plugin_la_DEPENDENCIES = $(if $(wildcard \
-   ../libiberty/noasan/libiberty.a),../libiberty/noasan/libiberty.a, \
-   $(if $(wildcard 
../libiberty/pic/libiberty.a),../libiberty/pic/libiberty.a,))
+   $(lt_host_flags) -module -bindir $(libexecsubdir)
+# Can be simplified when libiberty becomes a normal convenience library.
+libiberty = $(with_libiberty)/libiberty.a
+libiberty_noasan = $(with_libiberty)/noasan/libiberty.a
+libiberty_pic = $(with_libiberty)/pic/libiberty.a
+Wc=-Wc,
+liblto_plugin_la_LIBADD = \
+   $(if $(wildcard $(libiberty_noasan)),$(Wc)$(libiberty_noasan), \
+   $(if $(wildcard $(libiberty_pic)),$(Wc)$(libiberty_pic),))
+liblto_plugin_la_LDFLAGS += \
+   $(if $(wildcard $(libiberty_noasan)),, \
+   $(if $(wildcard $(libiberty_pic)),,-Wc,$(libiberty)))
+liblto_plugin_la_DEPENDENCIES = \
+   $(if $(wildcard $(libiberty_noasan)),$(libiberty_noasan), \
+   $(if $(wildcard $(libiberty_pic)),$(libiberty_pic),))
+LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
 liblto_plugin_la_LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
$(liblto_plugin_la_LDFLAGS) $(LTLDFLAGS) -o $@
diff --git lto-plugin/Makefile.in lto-plugin/Makefile.in
index 6e2fcc6..0a259e4 100644
--- lto-plugin/Makefile.in
+++ lto-plugin/Makefile.in
[...]
diff --git lto-plugin/configure lto-plugin/configure
index a579b99..6c36dfb 100755
--- lto-plugin/configure
+++ lto-plugin/configure
[...]
diff --git lto-plugin/configure.ac lto-plugin/configure.ac
index a5f1774d..6a5ae8a 100644
--- lto-plugin/configure.ac
+++ lto-plugin/configure.ac
@@ -4,6 +4,11 @@ AC_CANONICAL_SYSTEM
 GCC_TOPLEV_SUBDIRS
 AM_INIT_AUTOMAKE([foreign no-dist])
 AM_MAINTAINER_MODE
+AC_ARG_WITH(libiberty,
+  [AS_HELP_STRING([--with-libiberty=PATH],
+[specify the directory where to find libiberty [../libiberty]])],
+  [], with_libiberty=../libiberty)
+AC_SUBST(with_libiberty)
 AC_PROG_CC
 AC_SYS_LARGEFILE
 ACX_PROG_CC_WARNING_OPTS([-Wall], [ac_lto_plugin_warn_cflags])

commit 4f145a98767b78c083fa981f211d79591e0fe456
Author: Thomas Schwinge 
AuthorDate: Sun Oct 13 14:36:07 2

Re: config-ml.in: Robustify ac_configure_args parsing.

[Thomas Schwinge]

Hi!

Ping.


On Fri, 14 Mar 2014 12:22:29 +0100, I wrote:
> $ ../configure --enable-foo='--enable-a=1 --enable-b=2 --enable-c=3'
> [...]
> $ make configure-zlib
> config.status: creating Makefile
> config.status: executing default-1 commands
> ../../zlib/../config-ml.in: eval: line 142: unexpected EOF while looking 
> for matching `''
> ../../zlib/../config-ml.in: eval: line 143: syntax error: unexpected end 
> of file
> make: *** [configure-zlib] Error 1
> 
>140  case $enableopt in
>141  enable_shared | enable_static) ;;
>142  *) eval $enableopt="$optarg" ;;
>143  esac
>144  ;;
> 
> $ grep ac_configure_args < zlib/config.status
> ac_configure_args="  '--cache-file=./config.cache' 
> '--enable-foo=--enable-a=1 --enable-b=2 --enable-c=3' 
> '--enable-languages=c,c++,fortran,java,lto,objc' 
> '--program-transform-name=s,y,y,' '--disable-option-checking' 
> '--build=x86_64-unknown-linux-gnu' '--host=x86_64-unknown-linux-gnu' 
> '--target=x86_64-unknown-linux-gnu' '--srcdir=../../zlib' 
> 'build_alias=x86_64-unknown-linux-gnu' 'host_alias=x86_64-unknown-linux-gnu' 
> 'target_alias=x86_64-unknown-linux-gnu'"
> 
> These are quoted correctly; the error happens because the
> ac_configure_args parsing logic in config-ml.in will parse this as:
> 
>  1. '--enable-foo=--enable-a=1
>  2. --enable-b=2
>  3. --enable-c=3'
> 
> Below I'm proposing a patch using a shell function and eval to properly
> handle such configure arguments.  Instead of a shell function, we could
> also use:
> 
> eval set x "${ac_configure_args}" && shift
> for option
> do
>   [...]
> done
> 
> ..., as done in top-level configure.ac for baseargs etc., but as the
> config-ml.in script is sourced in different contexts, it is not obvious
> to me that we're permitted to overwrite the shell's positional parameters
> here.
> 
> OK for trunk?  (Will properly indent scan_arguments before commit.)
> 
> commit bc6f99e9840994309eaf4e88679c3ba50d5e4918
> Author: Thomas Schwinge 
> Date:   Thu Mar 13 19:54:58 2014 +0100
> 
>   * config-ml.in: Robustify ac_configure_args parsing.
> 
> diff --git config-ml.in config-ml.in
> index 1198346..0cd7db3 100644
> --- config-ml.in
> +++ config-ml.in
> @@ -105,10 +105,13 @@ ml_realsrcdir=${srcdir}
>  
>  # Scan all the arguments and set all the ones we need.
>  
> +scan_arguments ()
> +{
>  ml_verbose=--verbose
> -for option in ${ac_configure_args}
> +for option
>  do
> -  # strip single quotes surrounding individual options
> +  # Strip single quotes surrounding individual options, that is, remove one
> +  # level of shell quoting for these.
>case $option in
>\'*\') eval option=$option ;;
>esac
> @@ -139,7 +142,7 @@ do
>   # Don't undo its work.
>   case $enableopt in
>   enable_shared | enable_static) ;;
> - *) eval $enableopt="$optarg" ;;
> + *) eval $enableopt='$optarg' ;;
>   esac
>   ;;
>--norecursion | --no-recursion)
> @@ -157,7 +160,7 @@ do
>   *)  optarg=yes ;;
>   esac
>   withopt=`echo ${option} | sed 's:^--::;s:=.*$::;s:-:_:g'`
> - eval $withopt="$optarg"
> + eval $withopt='$optarg'
>   ;;
>--without-*)
>   withopt=`echo ${option} | sed 's:^--::;s:out::;s:-:_:g'`
> @@ -165,6 +168,11 @@ do
>   ;;
>esac
>  done
> +}
> +# Use eval to properly handle configure arguments such as
> +# --enable-foo='--enable-a=1 --enable-b=2 --enable-c=3'.
> +eval scan_arguments "${ac_configure_args}"
> +unset scan_arguments
>  
>  # Only do this if --enable-multilib.
>  if [ "${enable_multilib}" = yes ]; then
> @@ -860,7 +868,7 @@ if [ -n "${multidirs}" ] && [ -z "${ml_norecursion}" ]; 
> then
>  
>  if eval ${ml_config_env} ${ml_config_shell} ${ml_recprog} \
>   --with-multisubdir=${ml_dir} --with-multisrctop=${multisrctop} \
> - ${ac_configure_args} ${ml_config_env} ${ml_srcdiroption} ; then
> + "${ac_configure_args}" ${ml_config_env} ${ml_srcdiroption} ; then
>true
>  else
>exit 1


Grüße,
 Thomas


pgpQsL4yCxe3N.pgp
Description: PGP signature

Re: libsanitizer merge from upstream r208536

[Jakub Jelinek]

On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
> >> >> FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test
> >> >Is that before or after r210743?

Can't reproduce the above (note, not bootstrapped compiler, just
--disable-bootstrap), check-gcc RUNTESTFLAGS=asan.exp is clean, but
check-g++ RUNTESTFLAGS=asan.exp I got:
Running /usr/src/gcc/gcc/testsuite/g++.dg/asan/asan.exp ...
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_MallocUsableSizeTest 
execution test
:
Setting LD_LIBRARY_PATH to 
.:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libst
dc++-v3/src/.libs:/usr/src/gcc/obj2/gcc:/usr/src/gcc/obj2/gcc/32:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs:.:/usr/src/gc
c/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/usr/src/gcc/obj2/gcc:
/usr/src/gcc/obj2/gcc/32:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs
spawn [open ...]
DEJAGNU_GTEST_EXPECT_DEATH1 malloc_usable_size((void*)0x123) 
DEJAGNU_GTEST_EXPECT_DEATH1 AddressSanitizer: attempting to call 
malloc_usable_size() 
DEJAGNU_GTEST_EXPECT_DEATH1
DEJAGNU_GTEST_EXPECT_DEATH2 malloc_usable_size(array + kArraySize / 2) 
DEJAGNU_GTEST_EXPECT_DEATH2 AddressSanitizer: attempting to call malloc_usab
le_size() DEJAGNU_GTEST_EXPECT_DEATH2
DEJAGNU_GTEST_EXPECT_DEATH3 malloc_usable_size(array) 
DEJAGNU_GTEST_EXPECT_DEATH3 AddressSanitizer: attempting to call 
malloc_usable_size() DEJAGNU
_GTEST_EXPECT_DEATH3

=
==28396==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7f5c18048df9 in operator new(unsigned long) 
../../../../libsanitizer/asan/asan_new_delete.cc:53
#1 0x409134 in AddressSanitizer_MallocUsableSizeTest_fn 
/usr/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:407

SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_MallocUsableSizeTest 
execution test

If I manually compile it:
/usr/src/gcc/obj2/gcc/testsuite/g++/../../xg++ 
-B/usr/src/gcc/obj2/gcc/testsuite/g++/../../ 
/usr/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.C -fsanitize=address -g 
-I/usr/src/gcc/gcc/testsuite/../../libsanitizer/include 
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ 
-I/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
 -I/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libstdc++-v3/include 
-I/usr/src/gcc/libstdc++-v3/libsupc++ 
-I/usr/src/gcc/libstdc++-v3/include/backward 
-I/usr/src/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 
-fsanitize=address -fno-builtin -Wall -Wno-format -Werror -g -DASAN_UAR=0 
-DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0 -DASAN_USE_DEJAGNU_GTEST=1 
-lasan -lpthread -ldl -DASAN_NEEDS_SEGV=1 -DASAN_AVOID_EXPENSIVE_TESTS=1 -msse2 
-D__NO_INLINE__ 
/usr/src/gcc/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc 
-B/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/ 
-B/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/ 
-L/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs 
-L/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs 
-B/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs 
-L/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -lm -o 
./asan_test.exe 
-Wl,-rpath,/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs/
and run:
./asan_test.exe AddressSanitizer_MallocUsableSizeTest
I get the same error.

Seems compiler-rt has there:

--- gcc/testsuite/g++.dg/asan/asan_test.cc  2013-11-12 11:31:20.0 
+0100
+++ gcc/testsuite/g++.dg/asan/asan_test.cc  2014-05-22 13:00:23.391901708 
+0200
@@ -413,6 +413,7 @@ TEST(AddressSanitizer, MallocUsableSizeT
kMallocUsableSizeErrorMsg);
   free(array);
   EXPECT_DEATH(malloc_usable_size(array), kMallocUsableSizeErrorMsg);
+  delete int_ptr;
 }
 #endif

There are various other changes to asan_test.cc, so guess some work is needed 
on that. 

Jakub

Re: [RFC] HOST_WIDE_INT transition steps

[Richard Sandiford]

"Joseph S. Myers"  writes:
> On Tue, 20 May 2014, Eric Botcazou wrote:
>> > Make the code base easier to understand for newcomers.  It's also a
>> > documentation improvement (you see what a HOST_WIDE_INT really is),
>> > alongside with [u]int64_t being less to type ...
>> 
>> I personally find the abstraction and the separation with the other, more 
>> mundane types useful, but I guess that it's a matter of habit.
>
> Whatever the abstraction is, HOST_WIDE_INT is a pretty poor name for it.  
> I think it's something like "integer type that is big enough to store a 
> target address / offset in bytes, or a target word", together with a sense 
> of "integer type big enough for certain constants and such that twice it 
> is big enough for other constants" (the latter being what wide-int should 
> enable eliminating eventually).
>
> But I suspect HOST_WIDE_INT is used for lots of other things as well - and 
> for things for which 64 bits may not be enough (bit offsets, for example), 
> and for that matter int is used for things for which HOST_WIDE_INT would 
> be more appropriate (the length of a STRING_CST, for example).  So while 
> there may be a meaningful abstraction somewhere in there, I don't think 
> the particular places that happen to use HOST_WIDE_INT are a very good 
> guide to where such an abstraction should be used - and don't think moving 
> to int64_t / uint64_t would actually lose information of use for cleaning 
> things up in future.

Same here FWIW.  And int64_t and uint64_t have the advantage of being
"proper" types rather than #defines, which has caused surprises in the past.
(E.g. a case where HOST_WIDE_INT (x) worked for most hosts but not mingw64.)

We wouldn't be able to get away from using the #define without also
replacing "unsigned HOST_WIDE_INT" with something else, which wouldn't
be much less invasive than replacing all HOST_WIDE_INTs.  And I can't
help thinking that people have used HOST_WIDE_INT not because they
needed a signed type with undefined overflow, but because it was less
to type.

Richard

Re: libsanitizer merge from upstream r208536

[Jakub Jelinek]

On Thu, May 22, 2014 at 01:03:48PM +0200, Jakub Jelinek wrote:
> There are various other changes to asan_test.cc, so guess some work is needed 
> on that. 

Ok, tried to merge also g++.dg/asan from the same revision as you've merged
libsanitizer.

On x86_64-linux, both -m32 and -m64 I see
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_Packed5 p[0] = p[3] 
execution test
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_Packed5 p[3] = p[0] 
execution test
and with -m32 additionally:
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_long_double 
Ident(p)[12] = 0 execution test
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_long_double 
Ident(p)[0] = Ident(p)[12] execution test
The former boils down into:
struct Packed5 {
  int x;
  char c;
} __attribute__((packed));

int
main ()
{
  Packed5 *p = new Packed5[2];
  asm volatile ("" : "+r" (p));
  p[0] = p[3];
  p[3] = p[0];
  return 0;
}

Right now we instrument only accesses which have sizes power of two
<= 16:

  size_in_bytes = int_size_in_bytes (type);
  if ((size_in_bytes & (size_in_bytes - 1)) != 0
  || (unsigned HOST_WIDE_INT) size_in_bytes - 1 >= 16)
return;

I thought so did LLVM, has that changed recently?

2014-05-22  Jakub Jelinek  

* g++.dg/asan/asan_test.C: Add -std=c++11 and
-DSANITIZER_USE_DEJAGNU_GTEST=1 to dg-options, remove
-DASAN_USE_DEJAGNU_GTEST=1.
* g++.dg/asan/asan_mem_test.cc: Updated from upstream
r209283.
* g++.dg/asan/asan_oob_test.cc: Likewise.
* g++.dg/asan/sanitizer_test_utils.h: Likewise.
* g++.dg/asan/asan_str_test.cc: Likewise.
* g++.dg/asan/asan_test_utils.h: Likewise.
* g++.dg/asan/sanitizer_test_config.h: Likewise.
* g++.dg/asan/asan_test.cc: Likewise.
* g++.dg/asan/sanitizer_pthread_wrappers.h: New file.
Imported from upstream r209283.
* g++.dg/asan/asan_test_config.h: Likewise.

--- gcc/testsuite/g++.dg/asan/asan_test.C.jj2013-02-14 09:38:05.0 
+0100
+++ gcc/testsuite/g++.dg/asan/asan_test.C   2014-05-22 13:22:33.747459933 
+0200
@@ -2,7 +2,7 @@
 // { dg-skip-if "" { *-*-* } { "*" } { "-O2" } }
 // { dg-skip-if "" { *-*-* } { "-flto" } { "" } }
 // { dg-additional-sources "asan_globals_test-wrapper.cc" }
-// { dg-options "-fsanitize=address -fno-builtin -Wall -Wno-format -Werror -g 
-DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0 
-DASAN_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl" }
+// { dg-options "-std=c++11 -fsanitize=address -fno-builtin -Wall -Wno-format 
-Werror -g -DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0 
-DSANITIZER_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl" }
 // { dg-additional-options "-DASAN_NEEDS_SEGV=1" { target { ! arm*-*-* } } }
 // { dg-additional-options "-DASAN_LOW_MEMORY=1 -DASAN_NEEDS_SEGV=0" { target 
arm*-*-* } }
 // { dg-additional-options "-DASAN_AVOID_EXPENSIVE_TESTS=1" { target { ! 
run_expensive_tests } } }
--- gcc/testsuite/g++.dg/asan/asan_mem_test.cc.jj   2013-02-14 
09:38:05.697773648 +0100
+++ gcc/testsuite/g++.dg/asan/asan_mem_test.cc  2014-05-22 13:13:48.158014955 
+0200
@@ -74,17 +74,17 @@ TEST(AddressSanitizer, MemSetOOBTest) {
 // Strictly speaking we are not guaranteed to find such two pointers,
 // but given the structure of asan's allocator we will.
 static bool AllocateTwoAdjacentArrays(char **x1, char **x2, size_t size) {
-  vector v;
+  vector v;
   bool res = false;
   for (size_t i = 0; i < 1000U && !res; i++) {
-v.push_back(new char[size]);
+v.push_back(reinterpret_cast(new char[size]));
 if (i == 0) continue;
 sort(v.begin(), v.end());
 for (size_t j = 1; j < v.size(); j++) {
   assert(v[j] > v[j-1]);
   if ((size_t)(v[j] - v[j-1]) < size * 2) {
-*x2 = v[j];
-*x1 = v[j-1];
+*x2 = reinterpret_cast(v[j]);
+*x1 = reinterpret_cast(v[j-1]);
 res = true;
 break;
   }
@@ -92,9 +92,10 @@ static bool AllocateTwoAdjacentArrays(ch
   }
 
   for (size_t i = 0; i < v.size(); i++) {
-if (res && v[i] == *x1) continue;
-if (res && v[i] == *x2) continue;
-delete [] v[i];
+char *p = reinterpret_cast(v[i]);
+if (res && p == *x1) continue;
+if (res && p == *x2) continue;
+delete [] p;
   }
   return res;
 }
@@ -223,6 +224,13 @@ TEST(AddressSanitizer, MemCmpOOBTest) {
   s1[size - 1] = '\0';
   s2[size - 1] = '\0';
   EXPECT_DEATH(Ident(memcmp)(s1, s2, size + 1), RightOOBReadMessage(0));
+
+  // Even if the buffers differ in the first byte, we still assume that
+  // memcmp may access the whole buffer and thus reporting the overflow here:
+  s1[0] = 1;
+  s2[0] = 123;
+  EXPECT_DEATH(Ident(memcmp)(s1, s2, size + 1), RightOOBReadMessage(0));
+
   free(s1);
   free(s2);
 }
--- gcc/testsuite/g++.dg/asan/asan_oob_test.cc.jj   2013-02-14 
09:38:05.697773648 +0100
+++ gcc/testsuite/g++.dg/asan/asan_oob_test.cc  2014-05-22 13:13:49.976009670 
+0200
@@ -97,7 +97,6 @@ TEST(AddressSanitizer, O

Re: [build, driver] RFC: Support compressed debug sections

[Rainer Orth]

"Joseph S. Myers"  writes:

[Sorry for dropping the ball on this for so long.]

> I still have no idea from your answer how a user is meant to know whether 
> to use the option when compiling, linking or both, which is what needs to 
> be clear from invoke.texi.
>
> What does it mean for the option to be supported for compiling but not 
> linking?  What in that case will the linker do with compressed debug 
> sections on input?  Combine them in some way, good or bad?  Uncompress 
> them?
>
> Likewise, for it to be supported for linking but not compiling?  Will the 
> linker then compress the uncompressed sections it receives on input?
>
> I think it would be better if the option semantics are more like "if you 
> pass the same option when both compiling and linking, the linked output 
> will have the sections appropriately compressed as specified by the 
> option, whether or not the individual .o files do" - and if this can't be 
> supported with the tools being used, don't allow the option.

Ok, makes sense: although it may lose some of the capabilities of the
toolchain (like gas/gld, where gas can write compressed debug, gld can
read, but not write it), the user experience is certainly better.  I
thought about warning for an assembler not supporting compressed debug
when -gz is passed, but that would only produce noise.

So here's the revised patch.  Tested on

* i386-pc-solaris2.10 with gas/ld: gas could write but ld cannot read
  compressed debug, so reject all -gz options.

* i386-pc-solaris2.11 with gas/ld: gas can write zlib-gnu format, ld can
  read and write all of them

* x86_64-unknown-linux-gnu with gas/gold: gas can write, gold can read
  and write zlib-gnu format

In every case, -gz and -gz= behaved as expected as checked by
inspecting the assembler and linker invocations and the resulting object
files and executables.

Ok for mainline now?

Thanks.
Rainer


2013-04-10  Rainer Orth  

gcc:
* configure.ac (gcc_cv_as_compress_debug): Check for assembler
compressed debug support.
(gcc_cv_ld_compress_debug): Check for linker compressed debug
support.
* configure: Regenerate.
* config.in: Regenerate.
* common.opt (compressed_debug_sections): New enum.
(gz, gz=): New options.
* gcc.c (LINK_COMPRESS_DEBUG_SPEC, ASM_COMPRESS_DEBUG_SPEC):
Define.
(LINK_COMMAND_SPEC): Invoke LINK_COMPRESS_DEBUG_SPEC.
(asm_options): Invoke ASM_COMPRESS_DEBUG_SPEC.
* config/darwin.h (LINK_COMMAND_SPEC_A): Invoke
LINK_COMPRESS_DEBUG_SPEC.
* config/i386/djgpp.h (LINK_COMMAND_SPEC): Likewise.
* opts.c (common_handle_option): Handle OPT_gz, OPT_gz_.
* doc/invoke.texi (Option Summary, Debugging Options): Add
-gz[=type].
(Debugging Options): Document -gz[=type].

# HG changeset patch
# Parent 461334df01269c96bf9f041380cfc901c395307d
Enable --compress-debug-sections

diff --git a/gcc/common.opt b/gcc/common.opt
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2518,6 +2518,28 @@ gxcoff+
 Common JoinedOrMissing Negative(gcoff)
 Generate debug information in extended XCOFF format
 
+Enum
+Name(compressed_debug_sections) Type(int)
+
+; Since -gz= is completely handled in specs, the values aren't used and we
+; assign arbitrary constants.
+EnumValue
+Enum(compressed_debug_sections) String(none) Value(0)
+
+EnumValue
+Enum(compressed_debug_sections) String(zlib) Value(1)
+
+EnumValue
+Enum(compressed_debug_sections) String(zlib-gnu) Value(2)
+
+gz
+Common Driver
+Generate compressed debug sections
+
+gz=
+Common Driver Joined Enum(compressed_debug_sections)
+-gz=	Generate compressed debug sections in format 
+
 h
 Driver Joined Separate
 
diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -171,7 +171,8 @@ extern GTY(()) int darwin_ms_struct;
 LINK_PLUGIN_SPEC \
 "%{flto*:%&1 | grep -i warning > /dev/null
+   then
+ gcc_cv_as_compress_debug=0
+   elif $gcc_cv_as --compress-debug-sections -o conftest.o conftest.s > /dev/null 2>&1
+   then
+ gcc_cv_as_compress_debug=1
+ gcc_cv_as_compress_debug_option="--compress-debug-sections"
+ gcc_cv_as_no_compress_debug_option="--nocompress-debug-sections"
+   else
+ gcc_cv_as_compress_debug=0
+   # FIXME: Future gas versions will support ELF gABI style via
+   # --compress-debug-sections[=type].
+   fi])
+AC_DEFINE_UNQUOTED(HAVE_AS_COMPRESS_DEBUG, $gcc_cv_as_compress_debug,
+[Define to the level of your assembler's compressed debug section support.])
+AC_DEFINE_UNQUOTED(AS_COMPRESS_DEBUG_OPTION, "$gcc_cv_as_compress_debug_option",
+[Define to the assembler option to enable compressed debug sections.])
+AC_DEFINE_UNQUOTED(AS_NO_COMPRESS_DEBUG_OPTION, "$gcc_cv_as_no_compress_debug_option",
+[Define to the assembler option to disable compressed debug sections.])
+
 gcc_GAS_CHECK_FEATURE([.lcomm with alignment], gcc_cv_as_lcomm_with_alignment,
  ,,
 [.lc

RE: [PATCH][MIPS] Implement O32 FPXX ABI (GCC)

[Matthew Fortune]

> Let's step back a bit.  Please explain which case you were trying to
> handle with the specs patch.  Rejecting -msingle-float -mfp64 seems
> fine.
> Fiddling with the specs to stop that combination reaching the assembler
> is what seemed odd.

So, perhaps this is a 'vendor' issue too like some other debates we have
had in this area. I presume the --with arguments are intended to
be used to configure a single purpose toolchain that targets a specific
ABI. So if used to construct a single-float toolchain then --with-fp=64
would not be used. And if configured using --with-fp=64 then it is OK to
have an error if using -msingle-float.

I am actually considering implications of adding support for MIPS64r6
to GCC which I have not posted yet, sorry :-). MIPSr6 only supports
64-bit registers which naturally leads to needing -mfp64. MIPSr6 does
however also support a single-precision only variant.

For a single purpose native toolchain then --with-fp=64 can be used xor
--with-fpu=single to get the desired tools.

In a multilib toolchain then the vendor specific DRIVER_SELF_SPECS need
to infer -mfp64 for -mabi=32 and MIPSr6.  The FPXX patch currently has:

mti-linux.h:
  /* If no FP option is specified, infer one from the ABI/ISA level.  */\
  "%{!mfp*: %{mabi=32: %{" MIPS_FP32_OPTION_SPEC\
  ": -mfp32;: -mfpxx}}}",   \
 
With MIPSr6 added this would naturally become

mti-linux.h:
  /* If no FP option is specified, infer one from the ABI/ISA level.  */\
  "%{!mfp*: %{mabi=32: %{" MIPS_FP32_OPTION_SPEC\
  ": -mfp32;%{" MIPS_FP64_OPTION_SPEC ": -mfp64;: -mfpxx}}}",

With:
#define MIPS_FP64_OPTION_SPEC "mips32r6"

But I suppose it could be changed to the following such that
msingle-float prevents inferring a non-default -mfp setting.

mti-linux.h:
  /* If no FP option is specified, infer one from the ABI/ISA level.  */\
  "%{!mfp*: %{mabi=32: %{!msingle-float:%{" MIPS_FP32_OPTION_SPEC   
 \
  ": -mfp32;" MIPS_FP64_OPTION_SPEC ": -mfp64;: -mfpxx",

With:
#define MIPS_FP64_OPTION_SPEC "mips32r6"

The goal is to support a multilib toolchain which will generate correct
code by just using the architecture option and then be able to add other
options for non-default ABI variations.

mips-mti-linux-gnu -mips32r6 ==> gets O32 FP64
mips-mti-linux-gnu -mips32r6 -msingle-float ==> gets O32 FPSINGLE
mips-mti-linux-gnu -mips32r5 ==> gets O32 FPXX
mips-mti-linux-gnu -mips1 ==> gets O32 FP32

It seems strange if the -mips32r6 -msingle-float required you to set
-mfp32 as that should not matter. Single-float can only possibly mean
32-bit registers.

> >> >> > diff --git a/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
> >> >> b/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
> >> >> > new file mode 100644
> >> >> > index 000..f47cdda
> >> >> > --- /dev/null
> >> >> > +++ b/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
> >> >> > @@ -0,0 +1,21 @@
> >> >> > +/* Check that we handle call-clobbered FPRs correctly.  */
> >> >> > +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" }
> } */
> >> >> > +/* { dg-options "-mabi=32 -modd-spreg -mfp32 -ffixed-f0 -
> ffixed-f1 -
> >> >> ffixed-f2 -ffixed-f3 -ffixed-f4 -ffixed-f5 -ffixed-f6 -ffixed-f7 -
> >> ffixed-f8
> >> >> -ffixed-f9 -ffixed-f10 -ffixed-f11 -ffixed-f12 -ffixed-f13 -
> ffixed-f14 -
> >> >> ffixed-f15 -ffixed-f16 -ffixed-f17 -ffixed-f18 -ffixed-f19 -
> ffixed-f20 -
> >> >> ffixed-f22 -ffixed-f24 -ffixed-f26 -ffixed-f28 -ffixed-f30" } */
> >> >> > +
> >> >> > +void bar (void);
> >> >> > +float a;
> >> >> > +float
> >> >> > +foo ()
> >> >> > +{
> >> >> > +  float b = a + 1.0f;
> >> >> > +  bar();
> >> >> > +  return b;
> >> >> > +}
> >> >> > +/* { dg-final { scan-assembler-times "lwc1" 2 } } */
> >> >> > +/* { dg-final { scan-assembler-not "swc1" } } */
> >> >> > +/* { dg-final { scan-assembler-times "sdc1" 2 } } */
> >> >> > +/* { dg-final { scan-assembler-not "mtc" } } */
> >> >> > +/* { dg-final { scan-assembler-not "mfc" } } */
> >> >> > +/* { dg-final { scan-assembler-not "mthc" } } */
> >> >> > +/* { dg-final { scan-assembler-not "mfhc" } } */
> >> >>
> >> >> Why require sdc1 here?  Would Chao-Ying's patch make this use SWC1
> and
> >> LWC1
> >> >> exclusively?
> >> >
> >> > The SDC1 instructions are for callee-saved registers. I'll add the
> >> > check for two corresponding LDC1 instructions in the epilogue
> though
> >> > since I've noticed them being missing.
> >>
> >> I'm probably being dense, sorry, but why is SDC1 needed for -mfp32
> >> -modd-spreg?  Can't we just save and restore the odd register?
> >> That's technically more correct too, since we shouldn't really touch
> >> -ffixed registers.
> >
> > You are correct and I am/was aware of this...
> >
> > GCC is saving too much of the callee-saved registers when single-
> precision
> > values are live in them but this is historic behaviour. The code which
> > controls this is very complex 

Add a lto-section-names.h header

[Bernd Schmidt]

This is a change from the gomp4 branch which I think could go on trunk 
now. It removes some duplicated definitions and puts them in a header 
file. More definitions will be added to that header once offloading is 
implemented as on the branch.


Bootstrapped and tested on x86_64-linux, ok?


Bernd
commit f2f3cb92d29cd1940771bf4297055aed3ee86251
Author: Bernd Schmidt 
Date:   Wed May 21 15:04:47 2014 +0200

Create a new header lto-section-names.h

   gcc/
* config/darwin.c: Include "lto-section-names.h".
(LTO_SEGMENT_NAME): Don't define.
* config/i386/winnt.c: Include "lto-section-names.h".
* lto-streamer.c: Include "lto-section-names.h".
* lto-streamer.h (LTO_SECTION_NAME_PREFIX): Don't define.
* lto-wrapper.c: Include "lto-section-names.h".
(LTO_SECTION_NAME_PREFIX): Don't define.
* lto-section-names.h: New file.
* cgraphunit.c: Include "lto-section-names.h".

gcc/lto/
* lto-object.c: Include "lto-section-names.h".
(LTO_SEGMENT_NAME): Don't define.
* lto.c: Include "lto-section-names.h".

diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index cec341d..a2c8749 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -61,6 +61,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "gimple.h"
 #include "gimplify.h"
 #include "lto-streamer.h"
+#include "lto-section-names.h"
 
 /* Darwin supports a feature called fix-and-continue, which is used
for rapid turn around debugging.  When code is compiled with the
@@ -1898,9 +1899,6 @@ typedef struct GTY (()) darwin_lto_section_e {
 
 static GTY (()) vec *lto_section_names;
 
-/* Segment for LTO data.  */
-#define LTO_SEGMENT_NAME "__GNU_LTO"
-
 /* Section wrapper scheme (used here to wrap the unlimited number of LTO
sections into three Mach-O ones).
NOTE: These names MUST be kept in sync with those in
diff --git a/gcc/config/i386/winnt.c b/gcc/config/i386/winnt.c
index 6cdc29f..03e77aa 100644
--- a/gcc/config/i386/winnt.c
+++ b/gcc/config/i386/winnt.c
@@ -49,6 +49,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "is-a.h"
 #include "gimple.h"
 #include "lto-streamer.h"
+#include "lto-section-names.h"
 
 /* i386/PE specific attribute support.
 
diff --git a/gcc/lto-section-names.h b/gcc/lto-section-names.h
new file mode 100644
index 000..19a992d
--- /dev/null
+++ b/gcc/lto-section-names.h
@@ -0,0 +1,28 @@
+/* Definitions for LTO section names.
+   Copyright (C) 2013 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+/* The string that is the prefix on the section names we make for lto.
+   For decls the DECL_ASSEMBLER_NAME is appended to make the section
+   name for the functions and static_initializers.  For other types of
+   sections a '.' and the section type are appended.  */
+#define LTO_SECTION_NAME_PREFIX ".gnu.lto_"
+
+/* Segment name for LTO sections.  This is only used for Mach-O.  */
+
+#define LTO_SEGMENT_NAME "__GNU_LTO"
diff --git a/gcc/lto-streamer.c b/gcc/lto-streamer.c
index e94b787..a352adf 100644
--- a/gcc/lto-streamer.c
+++ b/gcc/lto-streamer.c
@@ -37,6 +37,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "diagnostic-core.h"
 #include "tree-streamer.h"
 #include "lto-streamer.h"
+#include "lto-section-names.h"
 #include "streamer-hooks.h"
 
 /* Statistics gathered during LTO, WPA and LTRANS.  */
diff --git a/gcc/lto-streamer.h b/gcc/lto-streamer.h
index ca66465..521d78d 100644
--- a/gcc/lto-streamer.h
+++ b/gcc/lto-streamer.h
@@ -134,12 +134,6 @@ along with GCC; see the file COPYING3.  If not see
  String are represented in the table as pairs, a length in ULEB128
  form followed by the data for the string.  */
 
-/* The string that is the prefix on the section names we make for lto.
-   For decls the DECL_ASSEMBLER_NAME is appended to make the section
-   name for the functions and static_initializers.  For other types of
-   sections a '.' and the section type are appended.  */
-#define LTO_SECTION_NAME_PREFIX ".gnu.lto_"
-
 #define LTO_major_version 4
 #define LTO_minor_version 0
 
diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index fd604b0..f59d74e 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -46,13 +46,7 @@ along with GCC; see the file COPYING3.  If not

Re: [PATCH] cplus-demangler, free resource after a failed call to gnu_special.

[Thomas Schwinge]

Hi!

On Wed, 14 May 2014 15:20:16 +0100, Gary Benson  wrote:
> Andrew Burgess wrote:
> > On 14/05/2014 10:01 AM, Gary Benson wrote:
> > > Ian Lance Taylor wrote:
> > > > Andrew Burgess  wrote:
> > > > > On 09/05/2014 9:53 PM, Ian Lance Taylor wrote:
> > > > > > Andrew Burgess  wrote:
> > > > > > >if ((AUTO_DEMANGLING || GNU_DEMANGLING))
> > > > > > > {
> > > > > > >   success = gnu_special (work, &mangled, &decl);
> > > > > > > +  if (!success)
> > > > > > > +{
> > > > > > > +  delete_work_stuff (work);
> > > > > > > +  string_delete (&decl);
> > > > > > > +}
> > > > > >
> > > >
> > > > This patch is OK.
> > > 
> > > Andrew, would you like me to commit this?
> > 
> > Yes please.
> 
> Done:
> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=210425

In GCC, I'm consistenly seeing the following new failure:

./test-demangle < ../../../source/libiberty/testsuite/demangle-expected
FAIL at line 4350, options --format=auto --no-params:
in:  _QueueNotification_QueueController__$4PPPM_A_INotice___Z
out: (null)
exp: 
./test-demangle: 895 tests, 1 failures
make[2]: *** [check-cplus-dem] Error 1

The patch was committed incompletely; I added the missing last line in
r210803:

commit 8207b6a22d5955c41109399cb09f0af661a593ea
Author: tschwinge 
AuthorDate: Thu May 22 11:56:45 2014 +
Commit: tschwinge 
CommitDate: Thu May 22 11:56:45 2014 +

Fix test in libiberty/testsuite/demangle-expected.

libiberty/
* testsuite/demangle-expected: Fix last commit.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210803 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libiberty/ChangeLog   | 4 
 libiberty/testsuite/demangle-expected | 1 +
 2 files changed, 5 insertions(+)

diff --git libiberty/ChangeLog libiberty/ChangeLog
index 7156be7..7b25c7e 100644
--- libiberty/ChangeLog
+++ libiberty/ChangeLog
@@ -1,3 +1,7 @@
+2014-05-22  Thomas Schwinge  
+
+   * testsuite/demangle-expected: Fix last commit.
+
 2014-05-14  Andrew Burgess  
 
* cplus-dmem.c (internal_cplus_demangle): Free any resources
diff --git libiberty/testsuite/demangle-expected 
libiberty/testsuite/demangle-expected
index 823a1c4..864ee7e 100644
--- libiberty/testsuite/demangle-expected
+++ libiberty/testsuite/demangle-expected
@@ -4347,3 +4347,4 @@ void post >(std::function&&)::{lambda()#1}*& std
 --format=auto --no-params
 _QueueNotification_QueueController__$4PPPM_A_INotice___Z
 _QueueNotification_QueueController__$4PPPM_A_INotice___Z
+_QueueNotification_QueueController__$4PPPM_A_INotice___Z


Grüße,
 Thomas


pgpR5Bu0GVWsx.pgp
Description: PGP signature

Create a library for tools like collect2 and lto-wrapper (1/2)

[Bernd Schmidt]

For offloading which is being implemented on the gomp4 branch, we're 
about to introduce new mkoffload programs. These are going to require a 
lot of functionality that's already present in lto-wrapper and collect2, 
I've decided to make a new set of utility functions that can be linked 
in with these programs.


This is the first step, splitting off code from lto-wrapper into a new 
collect-utils.c file. The next step will replace some of these with 
almost-identical ones from collect2 and make that tool also link with 
collect-utils.


Bootstrapped and tested on x86_64-linux, ok for trunk?


Bernd
commit 1faf8f4aa2f81be4a0b0db8c89933e9c5bd2abcb
Author: Bernd Schmidt 
Date:   Wed May 21 15:15:45 2014 +0200

Make a collect-utils library for use by tools like collect2 and lto-wrapper.

	* Makefile.in (ALL_HOST_BACKEND_OBJS): Add collect-utils.o.
	(lto-wrapper$(exeext)): Link with collect-utils.o.
	* collect-utils.c: New file.
	* collect-utils.h: New file.
	* lto-wrapper.c: Include "collect-utils.h".
	(args_name): Delete variable.
	(tool_name): New variable.
	(tool_cleanup): New function.
	(maybe_unlink): Renamed from maybe_unlink_file.  All callers changed.
	(lto_wrapper_cleanup, fatal_signal, fatal, fatal_perror,
	collect_execute, collect_wait, fork_execute): Remove functions.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index e74bb67..ad9df57 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1490,7 +1490,7 @@ ALL_HOST_FRONTEND_OBJS = $(foreach v,$(CONFIG_LANGUAGES),$($(v)_OBJS))
 ALL_HOST_BACKEND_OBJS = $(GCC_OBJS) $(OBJS) $(OBJS-libcommon) \
   $(OBJS-libcommon-target) @TREEBROWSER@ main.o c-family/cppspec.o \
   $(COLLECT2_OBJS) $(EXTRA_GCC_OBJS) $(GCOV_OBJS) $(GCOV_DUMP_OBJS) \
-  lto-wrapper.o
+  lto-wrapper.o collect-utils.o
 
 # This lists all host object files, whether they are included in this
 # compilation or not.
@@ -1909,9 +1909,10 @@ collect2$(exeext): $(COLLECT2_OBJS) $(LIBDEPS)
 CFLAGS-collect2.o += -DTARGET_MACHINE=\"$(target_noncanonical)\" \
 	@TARGET_SYSTEM_ROOT_DEFINE@
 
-lto-wrapper$(exeext): lto-wrapper.o ggc-none.o libcommon-target.a $(LIBDEPS)
+LTO_WRAPPER_OBJS = lto-wrapper.o collect-utils.o ggc-none.o
+lto-wrapper$(exeext): $(LTO_WRAPPER_OBJS) libcommon-target.a $(LIBDEPS)
 	+$(LINKER) $(ALL_COMPILERFLAGS) $(LDFLAGS) -o T$@ \
-	lto-wrapper.o ggc-none.o libcommon-target.a $(LIBS)
+	   $(LTO_WRAPPER_OBJS) libcommon-target.a $(LIBS)
 	mv -f T$@ $@
 
 # Files used by all variants of C or by the stand-alone pre-processor.
diff --git a/gcc/collect-utils.c b/gcc/collect-utils.c
new file mode 100644
index 000..22d90a4
--- /dev/null
+++ b/gcc/collect-utils.c
@@ -0,0 +1,259 @@
+/* Utility functions used by tools like collect2 and lto-wrapper.
+   Copyright (C) 2009-2014 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "intl.h"
+#include "diagnostic.h"
+#include "obstack.h"
+#include "opts.h"
+#include "options.h"
+#include "simple-object.h"
+#include "lto-section-names.h"
+#include "collect-utils.h"
+
+static char *response_file;
+
+bool debug;
+bool verbose;
+
+/* Delete tempfiles.  */
+
+void
+utils_cleanup (void)
+{
+  static bool cleanup_done = false;
+
+  if (cleanup_done)
+return;
+
+  /* Setting cleanup_done prevents an infinite loop if one of the
+ calls to maybe_unlink fails. */
+  cleanup_done = true;
+
+  if (response_file)
+maybe_unlink (response_file);
+  tool_cleanup ();
+}
+
+/* Notify user of a non-error.  */
+void
+notice (const char *cmsgid, ...)
+{
+  va_list ap;
+
+  va_start (ap, cmsgid);
+  vfprintf (stderr, _(cmsgid), ap);
+  va_end (ap);
+}
+
+void
+fatal_signal (int signum)
+{
+  signal (signum, SIG_DFL);
+  utils_cleanup ();
+  /* Get the same signal again, this time not handled,
+ so its normal effect occurs.  */
+  kill (getpid (), signum);
+}
+
+/* Just die. CMSGID is the error message. */
+
+void __attribute__ ((format (printf, 1, 2)))
+fatal (const char * cmsgid, ...)
+{
+  va_list ap;
+
+  va_start (ap, cmsgid);
+  fprintf (stderr, "%s: ", tool_name);
+  vfprintf (stderr, _(cmsgid), ap);
+  fprintf (stderr, "\n");
+  va_end (ap);
+
+  utils_cleanup ();
+  exit (FATAL_EXIT_CODE);
+}
+
+
+/* Die when sys call fails. CMSGID is the error message.  */

Create a library for tools like collect2 and lto-wrapper (2/2)

[Bernd Schmidt]

This is the second part of making a set of utility functions to be used 
by collect2, lto-wrapper and mkoffload.


The implementations of some functions like fork_execute are changed to 
those from collect2 and the calls in lto-wrapper adapted accordingly. 
There are some minor changes in these functions: for example I avoid 
calling fatal_error, instead using the fatal/fatal_perror functions so 
that the cleanup routine is called properly (lto-wrapper does not use 
atexit as collect2 does).


Bootstrapped and tested on x86_64-linux, ok for trunk?


Bernd

commit 39e9b2e3b47c893fcc1d96dfa7bdd975da80633e
Author: Bernd Schmidt 
Date:   Wed May 21 16:44:03 2014 +0200

Part 2 of the collect-utils library, now also used for collect2.

* Makefile.in (COLLECT2_OBJS): Add collect-utils.o.
(LTO_WRAPPER_OBJS): New variable.
(lto-wrapper$(exeext)): Use it.
* collect2.c: Include "collect-utils.h".
(vflag, debug): Remove variables.  Rename all uses of vflag to
verbose.
(at_file_supplied): No longer static.
(tool_name): New variable.
(do_wait, fork_execute, maybe_unlink): Don't declare.
(tool_cleanup): Renamed from collect_atexit.  New arg from_signal.
(collect_atexit): New static function.
(notice): Remove function.
(handler): Just call tool_cleanup.
(maybe_run_lto_and_relink, main, do_dsymutil): Add new arg to
fork_execute calls.
(collect_wait, do_wait, collect_execute): Remove functions.
(maybe_unlink): No longer static.
* collect2.h (vflag, debug): Don't declare.
(at_file_supplied): Declare.
* collect-utils.c (utils_cleanup): New arg from_signal.  All callers
changed.
(collect_execute): Replace with implementation from collect2, plus a
new arg use_atfile.  All callers changed.
(collect_wait): Replace with implementation from collect2.
(maybe_unlink_file): Remove function.
(fork_execute): Replace with implementation from collect2, plus a
new arg use_atfile.  All callers changed.
(do_wait): Add call to utils_cleanup to the error path.
* collect-utils.h (collect_execute, fork_execute, utils_cleanup,
tool_cleanup): Adjust declarations.
* lto-wrapper.c (tool_cleanup): Add unused bool argument.
* tlink.c: Include "collect-utils.h".
(tlink_execute): New arg use_atfile.  All callers changed.
(tlink_init, tlink_execute): Remove declarations.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index ad9df57..c59a1fc 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1898,7 +1898,8 @@ gcc-ranlib.c: gcc-ar.c
 gcc-nm.c: gcc-ar.c
 	cp $^ $@
 
-COLLECT2_OBJS = collect2.o collect2-aix.o tlink.o vec.o ggc-none.o file-find.o
+COLLECT2_OBJS = collect2.o collect2-aix.o tlink.o vec.o ggc-none.o \
+  collect-utils.o file-find.o
 COLLECT2_LIBS = @COLLECT2_LIBS@
 collect2$(exeext): $(COLLECT2_OBJS) $(LIBDEPS)
 # Don't try modifying collect2 (aka ld) in place--it might be linking this.
diff --git a/gcc/collect-utils.c b/gcc/collect-utils.c
index 22d90a4..5f5ace9 100644
--- a/gcc/collect-utils.c
+++ b/gcc/collect-utils.c
@@ -34,24 +34,6 @@ static char *response_file;
 bool debug;
 bool verbose;
 
-/* Delete tempfiles.  */
-
-void
-utils_cleanup (void)
-{
-  static bool cleanup_done = false;
-
-  if (cleanup_done)
-return;
-
-  /* Setting cleanup_done prevents an infinite loop if one of the
- calls to maybe_unlink fails. */
-  cleanup_done = true;
-
-  if (response_file)
-maybe_unlink (response_file);
-  tool_cleanup ();
-}
 
 /* Notify user of a non-error.  */
 void
@@ -68,7 +50,7 @@ void
 fatal_signal (int signum)
 {
   signal (signum, SIG_DFL);
-  utils_cleanup ();
+  utils_cleanup (true);
   /* Get the same signal again, this time not handled,
  so its normal effect occurs.  */
   kill (getpid (), signum);
@@ -87,7 +69,7 @@ fatal (const char * cmsgid, ...)
   fprintf (stderr, "\n");
   va_end (ap);
 
-  utils_cleanup ();
+  utils_cleanup (false);
   exit (FATAL_EXIT_CODE);
 }
 
@@ -106,61 +88,12 @@ fatal_perror (const char *cmsgid, ...)
   fprintf (stderr, ": %s\n", xstrerror (e));
   va_end (ap);
 
-  utils_cleanup ();
+  utils_cleanup (false);
   exit (FATAL_EXIT_CODE);
 }
 
-
-/* Execute a program, and wait for the reply. ARGV are the arguments. The
-   last one must be NULL. */
-
-struct pex_obj *
-collect_execute (char **argv)
-{
-  struct pex_obj *pex;
-  const char *errmsg;
-  int err;
-
-  if (verbose)
-{
-  char **p_argv;
-  const char *str;
-
-  for (p_argv = argv; (str = *p_argv) != (char *) 0; p_argv++)
-	fprintf (stderr, " %s", str);
-
-  fprintf (stderr, "\n");
-}
-
-  fflush (stdout);
-  fflush (stderr);
-
-  pex = pex_init (0, tool_name, NULL);
-  if (pex == NULL)
-fatal_

Re: libsanitizer merge from upstream r208536

[Konstantin Serebryany]

On Thu, May 22, 2014 at 3:43 PM, Jakub Jelinek  wrote:
> On Thu, May 22, 2014 at 01:03:48PM +0200, Jakub Jelinek wrote:
>> There are various other changes to asan_test.cc, so guess some work is 
>> needed on that.
>
> Ok, tried to merge also g++.dg/asan from the same revision as you've merged
> libsanitizer.
Oh, cool.

>
> On x86_64-linux, both -m32 and -m64 I see
> FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_Packed5 p[0] = p[3] 
> execution test
> FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_Packed5 p[3] = p[0] 
> execution test
> and with -m32 additionally:
> FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_long_double 
> Ident(p)[12] = 0 execution test
> FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_long_double 
> Ident(p)[0] = Ident(p)[12] execution test
> The former boils down into:
> struct Packed5 {
>   int x;
>   char c;
> } __attribute__((packed));
>
> int
> main ()
> {
>   Packed5 *p = new Packed5[2];
>   asm volatile ("" : "+r" (p));
>   p[0] = p[3];
>   p[3] = p[0];
>   return 0;
> }
>
> Right now we instrument only accesses which have sizes power of two
> <= 16:
>
>   size_in_bytes = int_size_in_bytes (type);
>   if ((size_in_bytes & (size_in_bytes - 1)) != 0
>   || (unsigned HOST_WIDE_INT) size_in_bytes - 1 >= 16)
> return;
>
> I thought so did LLVM, has that changed recently?

Not really recently... (Feb 2013)
http://llvm.org/viewvc/llvm-project?rev=175507&view=rev

--kcc

>
> 2014-05-22  Jakub Jelinek  
>
> * g++.dg/asan/asan_test.C: Add -std=c++11 and
> -DSANITIZER_USE_DEJAGNU_GTEST=1 to dg-options, remove
> -DASAN_USE_DEJAGNU_GTEST=1.
> * g++.dg/asan/asan_mem_test.cc: Updated from upstream
> r209283.
> * g++.dg/asan/asan_oob_test.cc: Likewise.
> * g++.dg/asan/sanitizer_test_utils.h: Likewise.
> * g++.dg/asan/asan_str_test.cc: Likewise.
> * g++.dg/asan/asan_test_utils.h: Likewise.
> * g++.dg/asan/sanitizer_test_config.h: Likewise.
> * g++.dg/asan/asan_test.cc: Likewise.
> * g++.dg/asan/sanitizer_pthread_wrappers.h: New file.
> Imported from upstream r209283.
> * g++.dg/asan/asan_test_config.h: Likewise.
>
> --- gcc/testsuite/g++.dg/asan/asan_test.C.jj2013-02-14 09:38:05.0 
> +0100
> +++ gcc/testsuite/g++.dg/asan/asan_test.C   2014-05-22 13:22:33.747459933 
> +0200
> @@ -2,7 +2,7 @@
>  // { dg-skip-if "" { *-*-* } { "*" } { "-O2" } }
>  // { dg-skip-if "" { *-*-* } { "-flto" } { "" } }
>  // { dg-additional-sources "asan_globals_test-wrapper.cc" }
> -// { dg-options "-fsanitize=address -fno-builtin -Wall -Wno-format -Werror 
> -g -DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0 
> -DASAN_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl" }
> +// { dg-options "-std=c++11 -fsanitize=address -fno-builtin -Wall 
> -Wno-format -Werror -g -DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 
> -DASAN_HAS_BLACKLIST=0 -DSANITIZER_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl" 
> }
>  // { dg-additional-options "-DASAN_NEEDS_SEGV=1" { target { ! arm*-*-* } } }
>  // { dg-additional-options "-DASAN_LOW_MEMORY=1 -DASAN_NEEDS_SEGV=0" { 
> target arm*-*-* } }
>  // { dg-additional-options "-DASAN_AVOID_EXPENSIVE_TESTS=1" { target { ! 
> run_expensive_tests } } }
> --- gcc/testsuite/g++.dg/asan/asan_mem_test.cc.jj   2013-02-14 
> 09:38:05.697773648 +0100
> +++ gcc/testsuite/g++.dg/asan/asan_mem_test.cc  2014-05-22 13:13:48.158014955 
> +0200
> @@ -74,17 +74,17 @@ TEST(AddressSanitizer, MemSetOOBTest) {
>  // Strictly speaking we are not guaranteed to find such two pointers,
>  // but given the structure of asan's allocator we will.
>  static bool AllocateTwoAdjacentArrays(char **x1, char **x2, size_t size) {
> -  vector v;
> +  vector v;
>bool res = false;
>for (size_t i = 0; i < 1000U && !res; i++) {
> -v.push_back(new char[size]);
> +v.push_back(reinterpret_cast(new char[size]));
>  if (i == 0) continue;
>  sort(v.begin(), v.end());
>  for (size_t j = 1; j < v.size(); j++) {
>assert(v[j] > v[j-1]);
>if ((size_t)(v[j] - v[j-1]) < size * 2) {
> -*x2 = v[j];
> -*x1 = v[j-1];
> +*x2 = reinterpret_cast(v[j]);
> +*x1 = reinterpret_cast(v[j-1]);
>  res = true;
>  break;
>}
> @@ -92,9 +92,10 @@ static bool AllocateTwoAdjacentArrays(ch
>}
>
>for (size_t i = 0; i < v.size(); i++) {
> -if (res && v[i] == *x1) continue;
> -if (res && v[i] == *x2) continue;
> -delete [] v[i];
> +char *p = reinterpret_cast(v[i]);
> +if (res && p == *x1) continue;
> +if (res && p == *x2) continue;
> +delete [] p;
>}
>return res;
>  }
> @@ -223,6 +224,13 @@ TEST(AddressSanitizer, MemCmpOOBTest) {
>s1[size - 1] = '\0';
>s2[size - 1] = '\0';
>EXPECT_DEATH(Ident(memcmp)(s1, s2, size + 1), RightOOBReadMessage(0));
> +
> +  // Even if the buffers differ in the first byte, we still assume that
> +  // memcmp may access the 

Re: [RFC][AArch64] Define TARGET_SPILL_CLASS

[Richard Earnshaw]

On 22/05/14 00:44, Kugan wrote:
> Compiling some applications with -mgeneral-regs-only produces better
> code (runs faster) compared to not using it. The difference here is that
> when -mgeneral-regs-only is not used, floating point register are also
> used in register allocation. Then IRA/LRA has to move them to core
> registers before performing operations.
> 
> I experimented with TARGET_SPILL_CLASS (as in attached patch) to make
> floating point register class as just spill class for integer pseudos.
> Though this benefits the application which had this issue. Overall
> performance with speck2k is neutral (some of the benchmarks benefits a
> lot but others regress). I am looking to see if I can make it perform
> better overall. Any suggestions welcome.
> 
> Attached experimental patch passes regression but 168.wupwise and
> 187.facerec miscompares now. I am looking at fixing this as well.
> 

While I'll be the first to admit that the generic costs are currently
little more than estimates, I'm worried about changing them based on the
results of one benchmark run on a single (unspecified) implementation.
The generic costs are intended to be a "best blend" of costs across a
large range of implementations.  Generically tuned code will not
necessarily be optimial on every processor -- what's more important is
that it's not severely sub-optimal on any processor.

I think the way we should proceed here is to add processor-specific
tuning tables for the cores that are being benchmarked.  Then, once we
have a reasonable selection of costing tables to base an assessment on
we should then re-review what the generic costs should be.

R.

> Thanks,
> Kugan
> 
> gcc/
> 2014-05-22  Kugan Vivekanandarajah  
> 
>   * config/aarch64/aarch64.c (generic_regmove_cost) : Adjust GP2FP and
>   FP2GP costs.
>   (aarch64_spill_class) : New function.
>   (TARGET_SHIFT_TRUNCATION_MASK) : Define.
> 
> 
> p.txt
> 
> 
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index a3147ee..16d1b51 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -184,8 +184,8 @@ __extension__
>  static const struct cpu_regmove_cost generic_regmove_cost =
>  {
>NAMED_PARAM (GP2GP, 1),
> -  NAMED_PARAM (GP2FP, 2),
> -  NAMED_PARAM (FP2GP, 2),
> +  NAMED_PARAM (GP2FP, 5),
> +  NAMED_PARAM (FP2GP, 5),
>/* We currently do not provide direct support for TFmode Q->Q move.
>   Therefore we need to raise the cost above 2 in order to have
>   reload handle the situation.  */
> @@ -4882,6 +4882,18 @@ aarch64_register_move_cost (enum machine_mode mode 
> ATTRIBUTE_UNUSED,
>return regmove_cost->FP2FP;
>  }
>  
> +/* Return class of registers which could be used for pseudo of MODE
> +   and of class RCLASS for spilling instead of memory.  */
> +static reg_class_t
> +aarch64_spill_class (reg_class_t rclass, enum machine_mode mode)
> +{
> +  if ((GET_MODE_CLASS (mode) == MODE_INT)
> +   && reg_class_subset_p (rclass, GENERAL_REGS))
> +return FP_REGS;
> +  return NO_REGS;
> +}
> +
> +
>  static int
>  aarch64_memory_move_cost (enum machine_mode mode ATTRIBUTE_UNUSED,
> reg_class_t rclass ATTRIBUTE_UNUSED,
> @@ -8431,6 +8443,9 @@ aarch64_cannot_change_mode_class (enum machine_mode 
> from,
>  #undef TARGET_SECONDARY_RELOAD
>  #define TARGET_SECONDARY_RELOAD aarch64_secondary_reload
>  
> +#undef TARGET_SPILL_CLASS
> +#define TARGET_SPILL_CLASS aarch64_spill_class
> +
>  #undef TARGET_SHIFT_TRUNCATION_MASK
>  #define TARGET_SHIFT_TRUNCATION_MASK aarch64_shift_truncation_mask
>  
> 

Re: libsanitizer merge from upstream r208536

[Konstantin Serebryany]

On Thu, May 22, 2014 at 3:03 PM, Jakub Jelinek  wrote:
> On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
>> >> >> FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test
>> >> >Is that before or after r210743?
>
> Can't reproduce the above (note, not bootstrapped compiler, just
> --disable-bootstrap), check-gcc RUNTESTFLAGS=asan.exp is clean, but
> check-g++ RUNTESTFLAGS=asan.exp I got:

How exactly do you run this check-g++?

For me:
% make check-gcc RUNTESTFLAGS=asan.exp
make[1]: Entering directory ...  

make check-g++ RUNTESTFLAGS=asan.exp
make: *** No rule to make target `check-g++'.  Stop.






> Running /usr/src/gcc/gcc/testsuite/g++.dg/asan/asan.exp ...
> FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_MallocUsableSizeTest 
> execution test
> :
> Setting LD_LIBRARY_PATH to 
> .:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libst
> dc++-v3/src/.libs:/usr/src/gcc/obj2/gcc:/usr/src/gcc/obj2/gcc/32:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs:.:/usr/src/gc
> c/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/usr/src/gcc/obj2/gcc:
> /usr/src/gcc/obj2/gcc/32:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs
> spawn [open ...]
> DEJAGNU_GTEST_EXPECT_DEATH1 malloc_usable_size((void*)0x123) 
> DEJAGNU_GTEST_EXPECT_DEATH1 AddressSanitizer: attempting to call 
> malloc_usable_size()
> DEJAGNU_GTEST_EXPECT_DEATH1
> DEJAGNU_GTEST_EXPECT_DEATH2 malloc_usable_size(array + kArraySize / 2) 
> DEJAGNU_GTEST_EXPECT_DEATH2 AddressSanitizer: attempting to call malloc_usab
> le_size() DEJAGNU_GTEST_EXPECT_DEATH2
> DEJAGNU_GTEST_EXPECT_DEATH3 malloc_usable_size(array) 
> DEJAGNU_GTEST_EXPECT_DEATH3 AddressSanitizer: attempting to call 
> malloc_usable_size() DEJAGNU
> _GTEST_EXPECT_DEATH3
>
> =
> ==28396==ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 4 byte(s) in 1 object(s) allocated from:
> #0 0x7f5c18048df9 in operator new(unsigned long) 
> ../../../../libsanitizer/asan/asan_new_delete.cc:53
> #1 0x409134 in AddressSanitizer_MallocUsableSizeTest_fn 
> /usr/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:407
>
> SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
> FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_MallocUsableSizeTest 
> execution test
>
> If I manually compile it:
> /usr/src/gcc/obj2/gcc/testsuite/g++/../../xg++ 
> -B/usr/src/gcc/obj2/gcc/testsuite/g++/../../ 
> /usr/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.C -fsanitize=address -g 
> -I/usr/src/gcc/gcc/testsuite/../../libsanitizer/include 
> -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ 
> -I/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
>  -I/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libstdc++-v3/include 
> -I/usr/src/gcc/libstdc++-v3/libsupc++ 
> -I/usr/src/gcc/libstdc++-v3/include/backward 
> -I/usr/src/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 
> -fsanitize=address -fno-builtin -Wall -Wno-format -Werror -g -DASAN_UAR=0 
> -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0 -DASAN_USE_DEJAGNU_GTEST=1 
> -lasan -lpthread -ldl -DASAN_NEEDS_SEGV=1 -DASAN_AVOID_EXPENSIVE_TESTS=1 
> -msse2 -D__NO_INLINE__ 
> /usr/src/gcc/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc 
> -B/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/ 
> -B/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/ 
> -L/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs 
> -L/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs 
> -B/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs 
> -L/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -lm -o 
> ./asan_test.exe 
> -Wl,-rpath,/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs/
> and run:
> ./asan_test.exe AddressSanitizer_MallocUsableSizeTest
> I get the same error.
>
> Seems compiler-rt has there:
>
> --- gcc/testsuite/g++.dg/asan/asan_test.cc  2013-11-12 11:31:20.0 
> +0100
> +++ gcc/testsuite/g++.dg/asan/asan_test.cc  2014-05-22 13:00:23.391901708 
> +0200
> @@ -413,6 +413,7 @@ TEST(AddressSanitizer, MallocUsableSizeT
> kMallocUsableSizeErrorMsg);
>free(array);
>EXPECT_DEATH(malloc_usable_size(array), kMallocUsableSizeErrorMsg);
> +  delete int_ptr;
>  }
>  #endif
>
> There are various other changes to asan_test.cc, so guess some work is needed 
> on that.
>
> Jakub

Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags

[Martin Jambor]

Hi,

On Wed, May 21, 2014 at 04:27:32PM +0200, Richard Biener wrote:
> On Wed, May 21, 2014 at 3:16 PM, Martin Jambor  wrote:
> > Hi,
> >
> > this demonstrates how results of ipa-prop escape analysis from
> > previous patches can be used at a later stage of compilation by
> > directly returning them from gimple_call_arg_flags which currently
> > relies on fnspec annotations.
> >
> > Bootstrapped and tested on x86_64-linux and also passes LTO bootstrap.
> > I have only had a brief look at behavior of this in SPEC 2006 and for
> > example in astar 1.19% of invocations of gimple_call_arg_flags return
> > noescape where we previously never did and in calculix this increases
> > from 15.62% (from annotations) to 18.14%.  Noclobber flag is reported
> > far less often still but for example in gamess that number raises from
> > 5.21% to 7.66%.
> >
> > Thanks,
> >
> > Martin
> >
> >
> > 2014-04-30  Martin Jambor  
> >
> > * gimple.c: Include cgraph.h.
> > (gimple_call_arg_flags): Also query bitmaps in cgraph_node.
> >
> > Index: src/gcc/gimple.c
> > ===
> > --- src.orig/gcc/gimple.c
> > +++ src/gcc/gimple.c
> > @@ -47,7 +47,7 @@ along with GCC; see the file COPYING3.
> >  #include "demangle.h"
> >  #include "langhooks.h"
> >  #include "bitmap.h"
> > -
> > +#include "cgraph.h"
> >
> >  /* All the tuples have their operand vector (if present) at the very bottom
> > of the structure.  Therefore, the offset required to find the
> > @@ -1349,32 +1349,50 @@ int
> >  gimple_call_arg_flags (const_gimple stmt, unsigned arg)
> >  {
> >tree attr = gimple_call_fnspec (stmt);
> > +  int ret;
> >
> > -  if (!attr || 1 + arg >= (unsigned) TREE_STRING_LENGTH (attr))
> > -return 0;
> > -
> > -  switch (TREE_STRING_POINTER (attr)[1 + arg])
> > +  if (attr && 1 + arg < (unsigned) TREE_STRING_LENGTH (attr))
> >  {
> > -case 'x':
> > -case 'X':
> > -  return EAF_UNUSED;
> > -
> > -case 'R':
> > -  return EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE;
> > -
> > -case 'r':
> > -  return EAF_NOCLOBBER | EAF_NOESCAPE;
> > -
> > -case 'W':
> > -  return EAF_DIRECT | EAF_NOESCAPE;
> > -
> > -case 'w':
> > -  return EAF_NOESCAPE;
> > +  switch (TREE_STRING_POINTER (attr)[1 + arg])
> > +   {
> > +   case 'x':
> > +   case 'X':
> > + ret = EAF_UNUSED;
> > + break;
> > +   case 'R':
> > + ret = EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE;
> > + break;
> > +   case 'r':
> > + ret = EAF_NOCLOBBER | EAF_NOESCAPE;
> > + break;
> > +   case 'W':
> > + ret = EAF_DIRECT | EAF_NOESCAPE;
> > + break;
> > +   case 'w':
> > + ret = EAF_NOESCAPE;
> > + break;
> > +   case '.':
> > +   default:
> > + ret = 0;
> > +   }
> > +}
> > +  else
> > +ret = 0;
> >
> > -case '.':
> > -default:
> > -  return 0;
> > +  tree callee_decl = gimple_call_fndecl (stmt);
> > +  if (callee_decl)
> > +{
> > +  cgraph_node *callee_node = cgraph_get_node (callee_decl);
> > +  if (callee_node)
> > +   {
> > + if (cgraph_param_noescape_p (callee_node, arg))
> > +   ret |= EAF_NOESCAPE;
> > + if (cgraph_param_noclobber_p (callee_node, arg))
> > +   ret |= EAF_NOCLOBBER;
> 
> That's quite expensive.  I guess we need a better way to store
> those?

if we want to avoid the cgraph_node lookup, then I think we need to
store this information in the decl or struct function.  That is
certainly possible and might even be more appropriate.

Thanks,

Martin

> 
> > +   }
> >  }
> > +
> > +  return ret;
> >  }
> >
> >  /* Detects return flags for the call STMT.  */
> >

Re: libsanitizer merge from upstream r208536

[Konstantin Serebryany]

Oops, ignore that. Forgot -C gcc

On Thu, May 22, 2014 at 4:49 PM, Konstantin Serebryany
 wrote:
> On Thu, May 22, 2014 at 3:03 PM, Jakub Jelinek  wrote:
>> On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
>>> >> >> FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test
>>> >> >Is that before or after r210743?
>>
>> Can't reproduce the above (note, not bootstrapped compiler, just
>> --disable-bootstrap), check-gcc RUNTESTFLAGS=asan.exp is clean, but
>> check-g++ RUNTESTFLAGS=asan.exp I got:
>
> How exactly do you run this check-g++?
>
> For me:
> % make check-gcc RUNTESTFLAGS=asan.exp
> make[1]: Entering directory ...  
>
> make check-g++ RUNTESTFLAGS=asan.exp
> make: *** No rule to make target `check-g++'.  Stop.
>
>
>
>
>
>
>> Running /usr/src/gcc/gcc/testsuite/g++.dg/asan/asan.exp ...
>> FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_MallocUsableSizeTest 
>> execution test
>> :
>> Setting LD_LIBRARY_PATH to 
>> .:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libst
>> dc++-v3/src/.libs:/usr/src/gcc/obj2/gcc:/usr/src/gcc/obj2/gcc/32:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs:.:/usr/src/gc
>> c/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/usr/src/gcc/obj2/gcc:
>> /usr/src/gcc/obj2/gcc/32:/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs
>> spawn [open ...]
>> DEJAGNU_GTEST_EXPECT_DEATH1 malloc_usable_size((void*)0x123) 
>> DEJAGNU_GTEST_EXPECT_DEATH1 AddressSanitizer: attempting to call 
>> malloc_usable_size()
>> DEJAGNU_GTEST_EXPECT_DEATH1
>> DEJAGNU_GTEST_EXPECT_DEATH2 malloc_usable_size(array + kArraySize / 2) 
>> DEJAGNU_GTEST_EXPECT_DEATH2 AddressSanitizer: attempting to call malloc_usab
>> le_size() DEJAGNU_GTEST_EXPECT_DEATH2
>> DEJAGNU_GTEST_EXPECT_DEATH3 malloc_usable_size(array) 
>> DEJAGNU_GTEST_EXPECT_DEATH3 AddressSanitizer: attempting to call 
>> malloc_usable_size() DEJAGNU
>> _GTEST_EXPECT_DEATH3
>>
>> =
>> ==28396==ERROR: LeakSanitizer: detected memory leaks
>>
>> Direct leak of 4 byte(s) in 1 object(s) allocated from:
>> #0 0x7f5c18048df9 in operator new(unsigned long) 
>> ../../../../libsanitizer/asan/asan_new_delete.cc:53
>> #1 0x409134 in AddressSanitizer_MallocUsableSizeTest_fn 
>> /usr/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:407
>>
>> SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
>> FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_MallocUsableSizeTest 
>> execution test
>>
>> If I manually compile it:
>> /usr/src/gcc/obj2/gcc/testsuite/g++/../../xg++ 
>> -B/usr/src/gcc/obj2/gcc/testsuite/g++/../../ 
>> /usr/src/gcc/gcc/testsuite/g++.dg/asan/asan_test.C -fsanitize=address -g 
>> -I/usr/src/gcc/gcc/testsuite/../../libsanitizer/include 
>> -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ 
>> -I/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
>>  -I/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/libstdc++-v3/include 
>> -I/usr/src/gcc/libstdc++-v3/libsupc++ 
>> -I/usr/src/gcc/libstdc++-v3/include/backward 
>> -I/usr/src/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 
>> -fsanitize=address -fno-builtin -Wall -Wno-format -Werror -g -DASAN_UAR=0 
>> -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0 -DASAN_USE_DEJAGNU_GTEST=1 
>> -lasan -lpthread -ldl -DASAN_NEEDS_SEGV=1 -DASAN_AVOID_EXPENSIVE_TESTS=1 
>> -msse2 -D__NO_INLINE__ 
>> /usr/src/gcc/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc 
>> -B/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/ 
>> -B/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/ 
>> -L/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs 
>> -L/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs 
>> -B/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs 
>> -L/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -lm -o 
>> ./asan_test.exe 
>> -Wl,-rpath,/usr/src/gcc/obj2/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs/
>> and run:
>> ./asan_test.exe AddressSanitizer_MallocUsableSizeTest
>> I get the same error.
>>
>> Seems compiler-rt has there:
>>
>> --- gcc/testsuite/g++.dg/asan/asan_test.cc  2013-11-12 
>> 11:31:20.0 +0100
>> +++ gcc/testsuite/g++.dg/asan/asan_test.cc  2014-05-22 
>> 13:00:23.391901708 +0200
>> @@ -413,6 +413,7 @@ TEST(AddressSanitizer, MallocUsableSizeT
>> kMallocUsableSizeErrorMsg);
>>free(array);
>>EXPECT_DEATH(malloc_usable_size(array), kMallocUsableSizeErrorMsg);
>> +  delete int_ptr;
>>  }
>>  #endif
>>
>> There are various other changes to asan_test.cc, so guess some work is 
>> needed on that.
>>
>> Jakub

Re: [PATCH 4/5] add gcc/gdb interface files

[Jeff Law]

On 05/16/14 09:26, Tom Tromey wrote:


2014-05-16  Phil Muldoon  
Jan Kratochvil  
Tom Tromey  

* gcc-c-fe.def: New file.
* gcc-c-interface.h: New file.
* gcc-interface.h: New file.
---


+GCC_METHOD7 (gcc_decl, build_decl,
+const char */* name */,
+enum gcc_c_symbol_kind /* sym_kind */,
+gcc_type /* sym_type */,
+const char */* substitution_name */,
+gcc_address /* address */,
+const char */* filename */,
+unsigned int /* line_number */)

I must say that I hate the embedded comments in the signatures. 
Especially when you end up with something like:


const char */* name */,

My brain just doesn't parse it.

const char * /* name */

is marginally better, but I still don't like it.

const char *, /* name */

Parses better as long as every argument is on a separate line.  But I 
still don't like it...


I'm curious how others feel about this.

All these files say they're part of GDB, not sure if that was 
intentional.  Obviously a nit.


Otherwise it's pretty reasonable.  If we could come up with a better way 
to handle the signatures, then I think this part is good to go.


jeff

Re: [PATCH][AARCH64] Support tail indirect function call

[Jiong Wang]

On 21/05/14 15:44, Marcus Shawcroft wrote:

Couple of comments:

+typedef void FP(int);

GNU style please, space before (.

+void f1(FP fp, int n) { (fp)(n); }

GNU style please, line breaks after void, '(' and ';'. Space between
')' an '('. Likewise in the following line.

We should really follow the test case name convention, see
https://gcc.gnu.org/wiki/TestCaseWriting, specifically paragraph 1.

+(define_register_constraint "Ucs" "CALLER_SAVE_REGS"
+ "@internal The caller save registers.  Useful for sibcalls.")

Please move this hunk up and place with the other
define_register_constraints.  Line break after @internal like the
other entries in this file  Drop the "Useful for ..." part of the
comment.

+   br\\t%0
+   b\\t%a0"
[(set_attr "type" "branch")]

Don't forget to add another attribute value for the new alternative.
Likewise is the following pattern.

CORE_REGS,
+  CALLER_SAVE_REGS,
GENERAL_REGS,

Register classes should be ordered such that if class x is contained
in class y, class x has the lower number therefore CALLER_SAVE_REGS
should be above CORE_REG.

Cheers
/Marcus



thanks for review, all fixed.

below is the updated patch.  no regression and bootstrap OK on aarch64.

ok for trunk?

gcc/
  * config/aarch64/predicates.md (aarch64_call_insn_operand): New 
predicate.

  * config/aarch64/constraints.md ("Ucs", "Usf"):  New constraints.
  * config/aarch64/aarch64.md (*sibcall_insn, *sibcall_value_insn): 
Adjust for

  tailcalling through registers.
  * config/aarch64/aarch64.h (enum reg_class): New caller save register 
class.

  (REG_CLASS_NAMES): Likewise.
  (REG_CLASS_CONTENTS): Likewise.
  * config/aarch64/aarch64.c (aarch64_function_ok_for_sibcall): Allow 
tailcalling

  without decls.

gcc/testsuite
  gcc.target/aarch64/tail-indirect-call_1.c: New test.

--
Jiong
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 8655f04..b8ef9cb 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -1198,18 +1198,10 @@ aarch64_expand_mov_immediate (rtx dest, rtx imm)
 }
 
 static bool
-aarch64_function_ok_for_sibcall (tree decl, tree exp ATTRIBUTE_UNUSED)
+aarch64_function_ok_for_sibcall (tree decl ATTRIBUTE_UNUSED,
+ tree exp ATTRIBUTE_UNUSED)
 {
-  /* Indirect calls are not currently supported.  */
-  if (decl == NULL)
-return false;
-
-  /* Cannot tail-call to long-calls, since these are outside of the
- range of a branch instruction (we could handle this if we added
- support for indirect tail-calls.  */
-  if (aarch64_decl_is_long_call_p (decl))
-return false;
-
+  /* Currently, always true.  */
   return true;
 }
 
@@ -4270,6 +4262,7 @@ aarch64_class_max_nregs (reg_class_t regclass, enum machine_mode mode)
 {
   switch (regclass)
 {
+case CALLER_SAVE_REGS:
 case CORE_REGS:
 case POINTER_REGS:
 case GENERAL_REGS:
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index c9b30d0..fa78f23 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -408,6 +408,7 @@ extern unsigned long aarch64_tune_flags;
 enum reg_class
 {
   NO_REGS,
+  CALLER_SAVE_REGS,
   CORE_REGS,
   GENERAL_REGS,
   STACK_REG,
@@ -423,6 +424,7 @@ enum reg_class
 #define REG_CLASS_NAMES\
 {		\
   "NO_REGS",	\
+  "CALLER_SAVE_REGS",\
   "CORE_REGS",	\
   "GENERAL_REGS",\
   "STACK_REG",	\
@@ -435,6 +437,7 @@ enum reg_class
 #define REG_CLASS_CONTENTS		\
 {	\
   { 0x, 0x, 0x },	/* NO_REGS */		\
+  { 0x0007, 0x, 0x },	/* CALLER_SAVE_REGS */	\
   { 0x7fff, 0x, 0x0003 },	/* CORE_REGS */		\
   { 0x7fff, 0x, 0x0003 },	/* GENERAL_REGS */	\
   { 0x8000, 0x, 0x },	/* STACK_REG */		\
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 266d787..7c374b9 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -519,6 +519,10 @@
 	  (use (match_operand 2 "" ""))])]
   ""
   {
+if (!REG_P (XEXP (operands[0], 0))
+   && (GET_CODE (XEXP (operands[0], 0)) != SYMBOL_REF))
+ XEXP (operands[0], 0) = force_reg (Pmode, XEXP (operands[0], 0));
+
 if (operands[2] == NULL_RTX)
   operands[2] = const0_rtx;
   }
@@ -532,31 +536,38 @@
 	  (use (match_operand 3 "" ""))])]
   ""
   {
+if (!REG_P (XEXP (operands[1], 0))
+   && (GET_CODE (XEXP (operands[1], 0)) != SYMBOL_REF))
+ XEXP (operands[1], 0) = force_reg (Pmode, XEXP (operands[1], 0));
+
 if (operands[3] == NULL_RTX)
   operands[3] = const0_rtx;
   }
 )
 
 (define_insn "*sibcall_insn"
-  [(call (mem:DI (match_operand:DI 0 "" "X"))
+  [(call (mem:DI (match_operand:DI 0 "aarch64_call_insn_operand" "Ucs, Usf"))
 	 (match_operand 1 "" ""))
(return)
(use (match_operand 2 "" ""))]
-  "GET_CODE (operands[0]) == SYMBOL_REF"
-  "b\\t%a0"
-  [(set_attr "type" "branch")]
-
+  "SIBLING_CALL_P (insn)"
+  "@
+   br\\t%0
+   b\\t%

Re: [PATCH 4/5] add gcc/gdb interface files

[Jakub Jelinek]

On Thu, May 22, 2014 at 06:52:05AM -0600, Jeff Law wrote:
> On 05/16/14 09:26, Tom Tromey wrote:
> >
> >2014-05-16  Phil Muldoon  
> > Jan Kratochvil  
> > Tom Tromey  
> >
> > * gcc-c-fe.def: New file.
> > * gcc-c-interface.h: New file.
> > * gcc-interface.h: New file.
> >---
> 
> +GCC_METHOD7 (gcc_decl, build_decl,
> +  const char */* name */,
> +  enum gcc_c_symbol_kind /* sym_kind */,
> +  gcc_type /* sym_type */,
> +  const char */* substitution_name */,
> +  gcc_address /* address */,
> +  const char */* filename */,
> +  unsigned int /* line_number */)
> 
> I must say that I hate the embedded comments in the signatures.
> Especially when you end up with something like:

Why it can't be:
GCC_METHOD7 (gcc_decl, build_decl,
 const char *name,
 enum gfc_c_symbol_kind sym_kind,
...
i.e. provide comments in the form of argument names
(sure, you can't use bool for the name of the parameter then...).

Jakub

Re: Add a lto-section-names.h header

[Richard Biener]

On Thu, May 22, 2014 at 1:57 PM, Bernd Schmidt  wrote:
> This is a change from the gomp4 branch which I think could go on trunk now.
> It removes some duplicated definitions and puts them in a header file. More
> definitions will be added to that header once offloading is implemented as
> on the branch.
>
> Bootstrapped and tested on x86_64-linux, ok?

Ok.  Thouhg putting it in lto-streamer.h would be ok as well.

Thanks,
Richard.

>
> Bernd

Re: [PATCH] Regression fix for PR target/61223

[Alexey Merzlyakov]

On 20.05.2014 20:24, Ramana Radhakrishnan wrote:
For now, please revert your original patch and one of Richard or me 
will try to look at it in the morning. The thumb1 case is slightly 
more complicated than this.


I don't like this approach as you are introducing the problem again in 
ARM state
I am not sure, could you provide more details: why do you think ARM 
state is invalid here?



and leaving the problem as is for Thumb1.
True. I've came up a new draft implementation which supports also thumb1 
(untested). Does it look saner?


Actually, it seems "pop lr" is not really necessary because following by 
"bl _Unwind_Resume @ Never returns" instruction overwrites lr immediately.
Perhaps it may make sense to replace "bl _Unwind_Resume" with "b 
_Unwind_Resume" to keep backtracing also in _Unwind_Resume?


Best regards,
Merzlyakov Alexey
--- gcc-4_9-vanilla/libstdc++-v3/libsupc++/eh_arm.cc	2014-05-22 17:20:43.018209504 +0400
+++ gcc-4_9/libstdc++-v3/libsupc++/eh_arm.cc	2014-05-22 16:32:43.726271177 +0400
@@ -199,27 +199,51 @@
 "	nop		5\n");
 #else
 // Assembly wrapper to call __gnu_end_cleanup without clobbering r1-r3.
-// Also push r4 to preserve stack alignment.
-#ifdef __thumb__
+// Also push lr to preserve stack alignment and to allow backtracing.
+#ifdef __thumb2__
 asm ("  .pushsection .text.__cxa_end_cleanup\n"
 "	.global __cxa_end_cleanup\n"
 "	.type __cxa_end_cleanup, \"function\"\n"
 "	.thumb_func\n"
 "__cxa_end_cleanup:\n"
-"	push\t{r1, r2, r3, r4}\n"
+"	.fnstart\n"
+"	push\t{r1, r2, r3, lr}\n"
+"	.save\t{r1, r2, r3, lr}\n"
 "	bl\t__gnu_end_cleanup\n"
-"	pop\t{r1, r2, r3, r4}\n"
+"	pop\t{r1, r2, r3, lr}\n"
 "	bl\t_Unwind_Resume @ Never returns\n"
+"	.fnend\n"
+"	.popsection\n");
+#elif defined(__thumb__)
+asm ("  .pushsection .text.__cxa_end_cleanup\n"
+"	.global __cxa_end_cleanup\n"
+"	.type __cxa_end_cleanup, \"function\"\n"
+"	.thumb_func\n"
+"__cxa_end_cleanup:\n"
+"	.fnstart\n"
+"	push\t{r1, r2, r3}\n"
+"	.save\t{r1, r2, r3}\n"
+"	push\t{lr}\n"
+"	.save\t{lr}\n"
+"	bl\t__gnu_end_cleanup\n"
+"	pop\t{r3}\n"
+"	mov\tlr, r3\n"
+"	pop\t{r1, r2, r3}\n"
+"	bl\t_Unwind_Resume @ Never returns\n"
+"	.fnend\n"
 "	.popsection\n");
 #else
 asm ("  .pushsection .text.__cxa_end_cleanup\n"
 "	.global __cxa_end_cleanup\n"
 "	.type __cxa_end_cleanup, \"function\"\n"
 "__cxa_end_cleanup:\n"
-"	stmfd\tsp!, {r1, r2, r3, r4}\n"
+"	.fnstart\n"
+"	stmfd\tsp!, {r1, r2, r3, lr}\n"
+"	.save\t{r1, r2, r3, lr}\n"
 "	bl\t__gnu_end_cleanup\n"
-"	ldmfd\tsp!, {r1, r2, r3, r4}\n"
+"	ldmfd\tsp!, {r1, r2, r3, lr}\n"
 "	bl\t_Unwind_Resume @ Never returns\n"
+"	.fnend\n"
 "	.popsection\n");
 #endif
 #endif

Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags

[Richard Biener]

On Thu, May 22, 2014 at 2:49 PM, Martin Jambor  wrote:
> Hi,
>
> On Wed, May 21, 2014 at 04:27:32PM +0200, Richard Biener wrote:
>> On Wed, May 21, 2014 at 3:16 PM, Martin Jambor  wrote:
>> > Hi,
>> >
>> > this demonstrates how results of ipa-prop escape analysis from
>> > previous patches can be used at a later stage of compilation by
>> > directly returning them from gimple_call_arg_flags which currently
>> > relies on fnspec annotations.
>> >
>> > Bootstrapped and tested on x86_64-linux and also passes LTO bootstrap.
>> > I have only had a brief look at behavior of this in SPEC 2006 and for
>> > example in astar 1.19% of invocations of gimple_call_arg_flags return
>> > noescape where we previously never did and in calculix this increases
>> > from 15.62% (from annotations) to 18.14%.  Noclobber flag is reported
>> > far less often still but for example in gamess that number raises from
>> > 5.21% to 7.66%.
>> >
>> > Thanks,
>> >
>> > Martin
>> >
>> >
>> > 2014-04-30  Martin Jambor  
>> >
>> > * gimple.c: Include cgraph.h.
>> > (gimple_call_arg_flags): Also query bitmaps in cgraph_node.
>> >
>> > Index: src/gcc/gimple.c
>> > ===
>> > --- src.orig/gcc/gimple.c
>> > +++ src/gcc/gimple.c
>> > @@ -47,7 +47,7 @@ along with GCC; see the file COPYING3.
>> >  #include "demangle.h"
>> >  #include "langhooks.h"
>> >  #include "bitmap.h"
>> > -
>> > +#include "cgraph.h"
>> >
>> >  /* All the tuples have their operand vector (if present) at the very 
>> > bottom
>> > of the structure.  Therefore, the offset required to find the
>> > @@ -1349,32 +1349,50 @@ int
>> >  gimple_call_arg_flags (const_gimple stmt, unsigned arg)
>> >  {
>> >tree attr = gimple_call_fnspec (stmt);
>> > +  int ret;
>> >
>> > -  if (!attr || 1 + arg >= (unsigned) TREE_STRING_LENGTH (attr))
>> > -return 0;
>> > -
>> > -  switch (TREE_STRING_POINTER (attr)[1 + arg])
>> > +  if (attr && 1 + arg < (unsigned) TREE_STRING_LENGTH (attr))
>> >  {
>> > -case 'x':
>> > -case 'X':
>> > -  return EAF_UNUSED;
>> > -
>> > -case 'R':
>> > -  return EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE;
>> > -
>> > -case 'r':
>> > -  return EAF_NOCLOBBER | EAF_NOESCAPE;
>> > -
>> > -case 'W':
>> > -  return EAF_DIRECT | EAF_NOESCAPE;
>> > -
>> > -case 'w':
>> > -  return EAF_NOESCAPE;
>> > +  switch (TREE_STRING_POINTER (attr)[1 + arg])
>> > +   {
>> > +   case 'x':
>> > +   case 'X':
>> > + ret = EAF_UNUSED;
>> > + break;
>> > +   case 'R':
>> > + ret = EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE;
>> > + break;
>> > +   case 'r':
>> > + ret = EAF_NOCLOBBER | EAF_NOESCAPE;
>> > + break;
>> > +   case 'W':
>> > + ret = EAF_DIRECT | EAF_NOESCAPE;
>> > + break;
>> > +   case 'w':
>> > + ret = EAF_NOESCAPE;
>> > + break;
>> > +   case '.':
>> > +   default:
>> > + ret = 0;
>> > +   }
>> > +}
>> > +  else
>> > +ret = 0;
>> >
>> > -case '.':
>> > -default:
>> > -  return 0;
>> > +  tree callee_decl = gimple_call_fndecl (stmt);
>> > +  if (callee_decl)
>> > +{
>> > +  cgraph_node *callee_node = cgraph_get_node (callee_decl);
>> > +  if (callee_node)
>> > +   {
>> > + if (cgraph_param_noescape_p (callee_node, arg))
>> > +   ret |= EAF_NOESCAPE;
>> > + if (cgraph_param_noclobber_p (callee_node, arg))
>> > +   ret |= EAF_NOCLOBBER;
>>
>> That's quite expensive.  I guess we need a better way to store
>> those?
>
> if we want to avoid the cgraph_node lookup, then I think we need to
> store this information in the decl or struct function.  That is
> certainly possible and might even be more appropriate.

Can we?  If the body is not readily available we only have decl and
cgraph-node, not struct function.

I suppose we could exchange the struct function pointer in
tree_function_decl for a cgraph_node pointer and put
the struct function pointer into the cgraph_node.

Of course that may have impacts on FEs who might create
struct function before creating a cgraph node.  But at least
it would avoid enlarging FUNCTION_DECL.

In the end most of the tree_decl_with_vis stuff should move over to symtab
and var-decls should get a varpool_node pointer as well.

Back to the call flags stuff - I also meant the representation of the
"fn spec" attribute.  Rather than parsing that again and again move
it to a better place (which you seem to invent?) and better unified
representation.

Can you try if removing the cgraph hash is possible with the
struct function pointer idea?

Thanks,
Richard.

> Thanks,
>
> Martin
>
>>
>> > +   }
>> >  }
>> > +
>> > +  return ret;
>> >  }
>> >
>> >  /* Detects return flags for the call STMT.  */
>> >

Re: [patch] Small enhancement to associate_plusminus

[Eric Botcazou]

> I'm a little worried that introducing PLUS_EXPR_CODE_P and friends
> invites too easy (not well thought) uses of it - they are distinct enough
> that we have very few "common" code-paths given the constraints on
> op2 of POINTER_PLUS_EXPR.

"grep -A1 -B1 POINTER_PLUS_EXPR *.c" convinced me of the contrary (and I 
planned to post a follow-up patch) but I don't really care in the end.

-- 
Eric Botcazou

Re: libsanitizer merge from upstream r208536

[Jakub Jelinek]

On Thu, May 22, 2014 at 04:06:21PM +0400, Konstantin Serebryany wrote:
> Not really recently... (Feb 2013)
> http://llvm.org/viewvc/llvm-project?rev=175507&view=rev

Ah, wasn't aware of that.

Here is (so far not bootstrapped/regtested) patch for the GCC side.

Notes:
1) the cases where we e.g. for various stringops perform first and
   last address check and use separate __asan_report_*1 for reporting
   that should probably be converted to use this __asan_report_*_n too
2) it doesn't still deal with unaligned power of two accesses properly,
   but neither does llvm (at least not 3.4).  Am not talking about
   undefined behavior cases where the compiler isn't told the access
   is misaligned, but e.g. when accessing struct S { int x; }
   __attribute__((packed)) and similar (or aligned(1)).  Supposedly
   we could force __asan_report_*_n for that case too, because
   normal wider check assumes it is aligned
3) there is still a failure for -m32:
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_long_double 
Ident(p)[12] = 0 output pattern test
Output should match: WRITE of size 1[06]
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_long_double 
Ident(p)[0] = Ident(p)[12] output pattern test
Output should match: READ of size 1[06]
   That sounds like something to fix in upstream, it should allow also size
   12 which is the size of long double on ia32 (16 bytes on x86_64),
   thus 1[026].  Kostya, can you please change it, I'll then apply it
   to the testsuite patch too?  As mentioned earlier, ubsan has similar
   problem where it doesn't recognize float bitsize 96 (but unlike this
   case where clang+llvm pass in 10 bytes, which is what is actually
   accessed by hw if using i387 stack, but not if using other means of
   copying it, in ubsan case clang also passes in bitsize 96 that ubsan
   doesn't handle).

I'll bootstrap/regtest this later today.

2014-05-22  Jakub Jelinek  

* sanitizer.def (BUILT_IN_ASAN_REPORT_LOAD_N,
BUILT_IN_ASAN_REPORT_STORE_N): New.
* asan.c (struct asan_mem_ref): Change access_size type to
HOST_WIDE_INT.
(asan_mem_ref_init, asan_mem_ref_new, get_mem_refs_of_builtin_call,
update_mem_ref_hash_table): Likewise.
(asan_mem_ref_hasher::hash): Hash in a HWI.
(report_error_func): Change size_in_bytes argument to HWI.
Use *_N builtins if size_in_bytes is larger than 16 or not power of
two.
(build_shadow_mem_access): New function.
(build_check_stmt): Use it.  Change size_in_bytes argument to HWI.
Handle size_in_bytes not power of two or larger than 16.
(instrument_derefs): Don't give up if size_in_bytes is not
power of two or is larger than 16.

--- gcc/sanitizer.def.jj2014-05-22 10:18:01.0 +0200
+++ gcc/sanitizer.def   2014-05-22 14:13:27.859513839 +0200
@@ -41,6 +41,9 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPO
  BT_FN_VOID_PTR, ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST)
 DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_LOAD16, "__asan_report_load16",
  BT_FN_VOID_PTR, ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_LOAD_N, "__asan_report_load_n",
+ BT_FN_VOID_PTR_PTRMODE,
+ ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST)
 DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_STORE1, "__asan_report_store1",
  BT_FN_VOID_PTR, ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST)
 DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_STORE2, "__asan_report_store2",
@@ -51,6 +54,9 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPO
  BT_FN_VOID_PTR, ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST)
 DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_STORE16, "__asan_report_store16",
  BT_FN_VOID_PTR, ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_STORE_N, "__asan_report_store_n",
+ BT_FN_VOID_PTR_PTRMODE,
+ ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST)
 DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REGISTER_GLOBALS,
  "__asan_register_globals",
  BT_FN_VOID_PTR_PTRMODE, ATTR_NOTHROW_LEAF_LIST)
--- gcc/asan.c.jj   2014-05-11 22:21:23.0 +0200
+++ gcc/asan.c  2014-05-22 15:28:30.125998730 +0200
@@ -251,8 +251,8 @@ struct asan_mem_ref
   /* The expression of the beginning of the memory region.  */
   tree start;
 
-  /* The size of the access (can be 1, 2, 4, 8, 16 for now).  */
-  char access_size;
+  /* The size of the access.  */
+  HOST_WIDE_INT access_size;
 };
 
 static alloc_pool asan_mem_ref_alloc_pool;
@@ -274,7 +274,7 @@ asan_mem_ref_get_alloc_pool ()
 /* Initializes an instance of asan_mem_ref.  */
 
 static void
-asan_mem_ref_init (asan_mem_ref *ref, tree start, char access_size)
+asan_mem_ref_init (asan_mem_ref *ref, tree start, HOST_WIDE_INT access_size)
 {
   ref->start = start;
   ref->access_size = access_size;
@@ -287,7 

Re: [Patch] Avoid gcc_assert in libgcov

[Teresa Johnson]

On Thu, Jan 16, 2014 at 2:41 PM, Jan Hubicka  wrote:
>> On Wed, Jan 15, 2014 at 8:39 PM, Jan Hubicka  wrote:
>> >>
>> >> In that case should we call gcov_error when IN_LIBGCOV? One
>> >> possibility would be to simply make gcov_nonruntime_assert be defined
>> >> as if (!EXPR) gcov_error in the IN_LIBGCOV case. But I think what you
>> >> wanted here was to reduce libgcov bloat by removing calls altogether,
>> >> which this wouldn't solve. But if we want to call gcov_error in some
>> >> cases, I think I need to add another macro that will either do
>> >> gcc_assert when !IN_LIBGCOV and "if (!EXPR) gcov_error" when
>> >> IN_LIBGCOV. Is that what you had in mind?
>> >
>> > I think for errors that can be triggered by data corruption, we ought to
>> > produce resonable error messages in both IN_LIBGCOV or for offline tools.
>> > Just unwound sequence if(...) gcov_error seems fine to me in this case,
>> > but we may also have assert like wrapper.
>> > I see we do not provide gcov_error outside libgcov, we probably ought to 
>> > map
>> > it to fatal_error in GCC binary.
>> >
>> > thanks,
>> > Honza
>>
>> Ok, here is the new patch. Bootstrapped and tested on
>> x86_64-unknown-linux-gnu. Ok for trunk?
>>
>> Thanks, Teresa
>>
>> 2014-01-16  Teresa Johnson  
>>
>> * gcov-io.c (gcov_position): Use gcov_nonruntime_assert.
>> (gcov_is_error): Remove gcc_assert from IN_LIBGCOV code.
>> (gcov_rewrite): Use gcov_nonruntime_assert.
>> (gcov_open): Ditto.
>> (gcov_write_words): Ditto.
>> (gcov_write_length): Ditto.
>> (gcov_read_words): Use gcov_nonruntime_assert, and remove
>> gcc_assert from IN_LIBGCOV code.
>> (gcov_read_summary): Use gcov_error to flag profile corruption.
>> (gcov_sync): Use gcov_nonruntime_assert.
>> (gcov_seek): Remove gcc_assert from IN_LIBGCOV code.
>> (gcov_histo_index): Use gcov_nonruntime_assert.
>> (static void gcov_histogram_merge): Ditto.
>> (compute_working_sets): Ditto.
>> * gcov-io.h (gcov_nonruntime_assert): Define.
>> (gcov_error): Define for !IN_LIBGCOV
>
> OK, thanks!
> Honza

I just found this old patch sitting in a client! Committed as r210805.

I also discovered that a couple uses of gcc_assert have snuck into
libgcc/libgcov* files in the meantime. Looks like this got added
during some of Rong's refactoring, cc'ing Rong. They are in
libgcc/libgcov-driver-system.c (allocate_filename_struct) and
libgcov-merge.c (__gcov_merge_single and __gcov_merge_delta). Should I
remove those or change to gcov_error?

Teresa



-- 
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

RE: [PATCH][MIPS] P5600 scheduling

[Jaydeep Patil]

Hi Richard,

Please refer to the attached patch files.

gcc-p5600-noMSA.patch
  The patch implements P5600 pipeline and scheduling for GP and FPU 
instructions.

gcc-p5600-noMSA-msched-weight.patch
  The patch implements -msched-weight option.

The -msched-weight option:
We are using ~650 hot-spot functions from VP9/VP8/H264/MPEG4 codes 
available to us as a test suite. The default Haifa-scheduler worked 
well for most of the functions, but excess spilling was observed in 
cases where register pressure was more than ~20. The 
-fsched-pressure flag proved good in some cases, but the algorithm 
focuses more on reducing register pressure.
We observed increase in stalls (but less spilling) with the -fsched- 
pressure option. When the register pressure goes beyond a certain 
threshold, the -msched-weight option tries to keep it down by 
promoting certain instructions up in the order. It has been 
implemented as part of TARGET_SCHED_REORDER target hook (function 
mips_sched_weight). The change is generic and there is nothing 
specific to MIPS.

When the register pressure goes beyond 15 then an instruction with 
maximum forward dependency is promoted ahead of the instruction at
READY[NREADY-1].
Scheduling of an INSN with maximum forward dependency enables early 
scheduling of instructions dependent on it.

When the register pressure goes beyond 25 and if consumer of the 
instruction in question (INSN) has higher priority than the 
instruction at READY[NREADY-1] then INSN is promoted. This chooses 
an INSN which has a high priority instruction dependent on it. This 
triggers the scheduling of that consumer instruction as early as 
possible to free up the registers used by that instruction.

Change log:

2014-05-21  Jaydeep Patil  
Prachi Godbole  

* config/mips/mips.c (mips_sched_weight): New function.
* config/mips/mips.opt: New option -msched-weight.

2014-05-20  Jaydeep Patil  
Prachi Godbole  

* config/mips/p5600.md: New file.
* config/mips/mips-cpus.def: Added p5600.
* config/mips/mips-protos.h (mips_fmadd_bypass): Add prototype.
* config/mips/mips.c (mips_fmadd_bypass): New function.
* config/mips/mips.h: Added p5600 default settings.
* config/mips/mips.md: Included p5600.md.

Regards,
Jaydeep

-Original Message-
From: Richard Sandiford [mailto:rdsandif...@googlemail.com] 
Sent: 20 May 2014 AM 02:37
To: Jaydeep Patil
Cc: Rich Fuhler; Matthew Fortune
Subject: Re: [PATCH][MIPS] P5600 scheduling

Jaydeep Patil  writes:
> Please refer to the attached patch which implements P5600 pipeline and 
> scheduling for GP and FPU instructions.
>
> Target option -msched-pressure has been implemented to reduce register 
> pressure while keeping the latency intact.

Please could you submit the -msched-pressure stuff separately?
Also please explain the heuristic in more detail.  Is it really MIPS-specific, 
or should it be done in generic scheduler code?

> +;; The address generation queue (AGQ) has AL2, CTISTD and LDSTA pipes 
> +(define_cpu_unit "p5600_agq, p5600_al2, p5600_ctistd, p5600_ldsta,
> + p5600_gpdiv" "p5600_agen_pipe")

Please indent to the column after the ".

> +;; fadd, fsub
> +(define_insn_reservation "fpu_fadd" 4
> +  (eq_attr "type" "fadd,fabs,fneg")
> +  "p5600_fpu_long, p5600_fpu_apu")

The insn reservations should have a p5600_ prefix too.

> +;; fload
> +(define_insn_reservation "fpu_fload" 8
> +  (and (eq_attr "type" "fpload,fpidxload")
> +(eq_attr "mode" "!TI"))
> +  "p5600_fpu_long, p5600_fpu_apu")
> +
> +;; fstore
> +(define_insn_reservation "fpu_fstore" 1
> +  (and (eq_attr "type" "fpstore,fpidxstore")
> +(eq_attr "mode" "!TI"))
> +  "p5600_fpu_short, p5600_fpu_apu")

Checking for just !TI (without TF) seems a bit odd.  If you want to test for a 
single load or store, you should be able to use (eq_attr "insn_count" "1") 
instead.

> +;; call
> +(define_insn_reservation "int_call" 2
> +  (eq_attr "jal" "indirect,direct")
> +  "p5600_agq_ctistd")
> +

Very minor nit, but no blank line at the end of the file.

> @@ -13059,6 +13093,32 @@ mips_output_division (const char *division, rtx 
> *operands)
>return s;
>  }
>  

> +/* Return true if destination of IN_INSN is used as add source in
> +   OUT_INSN. Both IN_INSN and OUT_INSN are of type fmadd. Example:
> +   madd.s dst, x, y, z
> +   madd.s a, dst, b, c */
> +
> +bool
> +mips_fmadd_bypass (rtx out_insn, rtx in_insn) {
> +  int dst_reg, src_reg;
> +
> +  if ((recog_memoized (in_insn) < 0)
> +   || (recog_memoized (out_insn) < 0))
> +return false;

Style nit: just a single pair of brackets around the "if" condition.

Although if you take these insns being fmadds as a precondition, you should be 
able to gcc_assert instead.

> +  if (dst_reg == src_reg)
> + return true;

Only indent this return by 4 spaces.

> @@ -13194,7 +13254,8 @@ mips_issue_rate (void)
>  case PROCESSOR_LOONGSON_2E:
>  case PR

Re: [PATCH] __attribute__ ((malloc)) doc fix (PR other/56955)

[Paul Eggert]

Richard Biener wrote:

Can you try to clarify the wording (I'm not a native speaker).


Sure.  I've filed a clarified version on PR 56955 and am attaching it 
here for convenience.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog   (revision 210804)
+++ gcc/ChangeLog   (working copy)
@@ -1,3 +1,10 @@
+2014-05-22  Paul Eggert  
+
+   PR other/56955
+   * doc/extend.texi (Function Attributes): Fix  __attribute__ ((malloc))
+   documentation; the old documentation didn't clearly state the
+   constraints on the contents of the pointed-to storage.
+
 2014-05-22  Richard Biener  
 
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Handle
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 210804)
+++ gcc/doc/extend.texi (working copy)
@@ -3207,15 +3207,17 @@
 
 @item malloc
 @cindex @code{malloc} attribute
-The @code{malloc} attribute is used to tell the compiler that a function
-may be treated as if any non-@code{NULL} pointer it returns cannot
-alias any other pointer valid when the function returns and that the memory
-has undefined content.
-This often improves optimization.
-Standard functions with this property include @code{malloc} and
-@code{calloc}.  @code{realloc}-like functions do not have this
-property as the memory pointed to does not have undefined content.
+This tells the compiler that a function is @code{malloc}-like, i.e.,
+that the pointer @var{P} returned by the function cannot alias any
+other pointer valid when the function returns, and moreover no
+pointers to valid objects occur in any storage addressed by @var{P}.
 
+Using this attribute can improve optimization.  Functions like
+@code{malloc} and @code{calloc} have this property because they return
+a pointer to uninitialized or zeroed-out storage.  However, functions
+like @code{realloc} do not have this property, as they can return a
+pointer to storage containing pointers.
+
 @item mips16/nomips16
 @cindex @code{mips16} attribute
 @cindex @code{nomips16} attribute

Re: [RFC][AARCH64] TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook

[Marcus Shawcroft]

On 2 May 2014 13:27, Kugan  wrote:

> +2014-05-02  Kugan Vivekanandarajah  
> +
> +   * config/aarch64/aarch64.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New
> +   define.
> +   * config/aarch64/aarch64-protos.h (aarch64_atomic_assign_expand_fenv):
> +   New function declaration.
> +   * config/aarch64/aarch64-builtins.c (aarch64_builtins) : Add
> +   AARCH64_BUILTIN_GET_FPCR, AARCH64_BUILTIN_SET_FPCR.
> +   AARCH64_BUILTIN_GET_FPSR and AARCH64_BUILTIN_SET_FPSR.
> +   (aarch64_init_builtins) : Initialize builtins
> +   __builtins_aarch64_set_fpcr, __builtins_aarch64_get_fpcr.
> +   __builtins_aarch64_set_fpsr and __builtins_aarch64_get_fpsr.
> +   (aarch64_expand_builtin) : Expand builtins __builtins_aarch64_set_fpcr
> +   __builtins_aarch64_get_fpcr, __builtins_aarch64_get_fpsr,
> +   and __builtins_aarch64_set_fpsr.
> +   (aarch64_atomic_assign_expand_fenv): New function.
> +   * config/aarch64/aarch64.md (set_fpcr): New pattern.
> +   (get_fpcr) : Likewise.
> +   (set_fpsr) : Likewise.
> +   (get_fpsr) : Likewise.
> +   (unspecv): Add UNSPECV_GET_FPCR and UNSPECV_SET_FPCR, UNSPECV_GET_FPSR
> +and UNSPECV_SET_FPSR.
> +   * doc/extend.texi (AARCH64 Built-in Functions) : Document
> +   __builtins_aarch64_set_fpcr, __builtins_aarch64_get_fpcr.
> +   __builtins_aarch64_set_fpsr and __builtins_aarch64_get_fpsr.
> +

OK, thanks Kugan.

/Marcus

PR 61222: noncanonical constant in simplify_shift_const_1

[Richard Sandiford]

simplify_shift_const_1 has code to convert:

  (ashift (trunc (plus X C1)) C2)

into:

  (plus (ashift (trunc X) C2) C1<

Re: [PATCH][AARCH64] Support tail indirect function call

[Marcus Shawcroft]

On 22 May 2014 14:03, Jiong Wang  wrote:

> gcc/testsuite
>   gcc.target/aarch64/tail-indirect-call_1.c: New test.

That should be tail_indirect_call_1.c as requested in the previous
review.  Otherwise this is OK to commit.

/Marcus

Re: libsanitizer merge from upstream r208536

[Konstantin Serebryany]

On Thu, May 22, 2014 at 6:07 PM, Jakub Jelinek  wrote:
> On Thu, May 22, 2014 at 04:06:21PM +0400, Konstantin Serebryany wrote:
>> Not really recently... (Feb 2013)
>> http://llvm.org/viewvc/llvm-project?rev=175507&view=rev
>
> Ah, wasn't aware of that.
>
> Here is (so far not bootstrapped/regtested) patch for the GCC side.
>
> Notes:
> 1) the cases where we e.g. for various stringops perform first and
>last address check and use separate __asan_report_*1 for reporting
>that should probably be converted to use this __asan_report_*_n too

Note that in clang we completely removed the code that instruments
srtingops (we had memset/memcpy/memmove).
Instead we replace memset with __asan_memset (ditto for
memcpy/memmove) so that it does not get inlined later.
This simplifies the code and allows to properly analyze all memset/etc
calls, not just check the first and the last bytes.


> 2) it doesn't still deal with unaligned power of two accesses properly,
>but neither does llvm (at least not 3.4).  Am not talking about
>undefined behavior cases where the compiler isn't told the access
>is misaligned, but e.g. when accessing struct S { int x; }
>__attribute__((packed)) and similar (or aligned(1)).  Supposedly
>we could force __asan_report_*_n for that case too, because
>normal wider check assumes it is aligned

Yep, we don't do it.

> 3) there is still a failure for -m32:
> FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_long_double 
> Ident(p)[12] = 0 output pattern test
> Output should match: WRITE of size 1[06]
> FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_long_double 
> Ident(p)[0] = Ident(p)[12] output pattern test
> Output should match: READ of size 1[06]
>That sounds like something to fix in upstream, it should allow also size
>12 which is the size of long double on ia32 (16 bytes on x86_64),
>thus 1[026].  Kostya, can you please change it, I'll then apply it
>to the testsuite patch too?
Like this?

--- lib/asan/tests/asan_test.cc (revision 209430)
+++ lib/asan/tests/asan_test.cc (working copy)
@@ -183,8 +183,8 @@
 TEST(AddressSanitizer, UAF_long_double) {
   if (sizeof(long double) == sizeof(double)) return;
   long double *p = Ident(new long double[10]);
-  EXPECT_DEATH(Ident(p)[12] = 0, "WRITE of size 1[06]");
-  EXPECT_DEATH(Ident(p)[0] = Ident(p)[12], "READ of size 1[06]");
+  EXPECT_DEATH(Ident(p)[12] = 0, "WRITE of size 1[026]");
+  EXPECT_DEATH(Ident(p)[0] = Ident(p)[12], "READ of size 1[026]");
   delete [] Ident(p);
 }


> As mentioned earlier, ubsan has similar
>problem where it doesn't recognize float bitsize 96 (but unlike this
>case where clang+llvm pass in 10 bytes, which is what is actually
>accessed by hw if using i387 stack, but not if using other means of
>copying it, in ubsan case clang also passes in bitsize 96 that ubsan
>doesn't handle).

Yea, this long double business is rather confusing to me...

--kcc

>
> I'll bootstrap/regtest this later today.
>
> 2014-05-22  Jakub Jelinek  
>
> * sanitizer.def (BUILT_IN_ASAN_REPORT_LOAD_N,
> BUILT_IN_ASAN_REPORT_STORE_N): New.
> * asan.c (struct asan_mem_ref): Change access_size type to
> HOST_WIDE_INT.
> (asan_mem_ref_init, asan_mem_ref_new, get_mem_refs_of_builtin_call,
> update_mem_ref_hash_table): Likewise.
> (asan_mem_ref_hasher::hash): Hash in a HWI.
> (report_error_func): Change size_in_bytes argument to HWI.
> Use *_N builtins if size_in_bytes is larger than 16 or not power of
> two.
> (build_shadow_mem_access): New function.
> (build_check_stmt): Use it.  Change size_in_bytes argument to HWI.
> Handle size_in_bytes not power of two or larger than 16.
> (instrument_derefs): Don't give up if size_in_bytes is not
> power of two or is larger than 16.
>
> --- gcc/sanitizer.def.jj2014-05-22 10:18:01.0 +0200
> +++ gcc/sanitizer.def   2014-05-22 14:13:27.859513839 +0200
> @@ -41,6 +41,9 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPO
>   BT_FN_VOID_PTR, ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST)
>  DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_LOAD16, "__asan_report_load16",
>   BT_FN_VOID_PTR, ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST)
> +DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_LOAD_N, "__asan_report_load_n",
> + BT_FN_VOID_PTR_PTRMODE,
> + ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST)
>  DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_STORE1, "__asan_report_store1",
>   BT_FN_VOID_PTR, ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST)
>  DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_STORE2, "__asan_report_store2",
> @@ -51,6 +54,9 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPO
>   BT_FN_VOID_PTR, ATTR_TMPURE_NORETURN_NOTHROW_LEAF_LIST)
>  DEF_SANITIZER_BUILTIN(BUILT_IN_ASAN_REPORT_STORE16, "__asan_report_store16",
>   

Re: libsanitizer merge from upstream r208536

[Jakub Jelinek]

On Thu, May 22, 2014 at 06:34:22PM +0400, Konstantin Serebryany wrote:
> > Notes:
> > 1) the cases where we e.g. for various stringops perform first and
> >last address check and use separate __asan_report_*1 for reporting
> >that should probably be converted to use this __asan_report_*_n too
> 
> Note that in clang we completely removed the code that instruments
> srtingops (we had memset/memcpy/memmove).
> Instead we replace memset with __asan_memset (ditto for
> memcpy/memmove) so that it does not get inlined later.
> This simplifies the code and allows to properly analyze all memset/etc
> calls, not just check the first and the last bytes.

Food for thought, yes.

> > 3) there is still a failure for -m32:
> > FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_long_double 
> > Ident(p)[12] = 0 output pattern test
> > Output should match: WRITE of size 1[06]
> > FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_long_double 
> > Ident(p)[0] = Ident(p)[12] output pattern test
> > Output should match: READ of size 1[06]
> >That sounds like something to fix in upstream, it should allow also size
> >12 which is the size of long double on ia32 (16 bytes on x86_64),
> >thus 1[026].  Kostya, can you please change it, I'll then apply it
> >to the testsuite patch too?
> Like this?
> 
> --- lib/asan/tests/asan_test.cc (revision 209430)
> +++ lib/asan/tests/asan_test.cc (working copy)
> @@ -183,8 +183,8 @@
>  TEST(AddressSanitizer, UAF_long_double) {
>if (sizeof(long double) == sizeof(double)) return;
>long double *p = Ident(new long double[10]);
> -  EXPECT_DEATH(Ident(p)[12] = 0, "WRITE of size 1[06]");
> -  EXPECT_DEATH(Ident(p)[0] = Ident(p)[12], "READ of size 1[06]");
> +  EXPECT_DEATH(Ident(p)[12] = 0, "WRITE of size 1[026]");
> +  EXPECT_DEATH(Ident(p)[0] = Ident(p)[12], "READ of size 1[026]");
>delete [] Ident(p);
>  }
> 

Yep, exactly.

> > As mentioned earlier, ubsan has similar
> >problem where it doesn't recognize float bitsize 96 (but unlike this
> >case where clang+llvm pass in 10 bytes, which is what is actually
> >accessed by hw if using i387 stack, but not if using other means of
> >copying it, in ubsan case clang also passes in bitsize 96 that ubsan
> >doesn't handle).
> 
> Yea, this long double business is rather confusing to me...

It is actually even more complicated than that, on x86_64 GCC supports
long double (== __float80) which has 128 bits (64-bit) or 96 bits (32-bit),
and is the 80-bit extended double format, plus also __float128, which
is a software implemented IEEE 754 quad long double (also 128 bit).
Now, ubsan handles all of 80 and 128 bit (and should 96 bit) floats
as long double, so it is unclear how to tell libubsan about __float128
type (because bitsize 128 is already used for something else),
plus in order to actually print __float128 one would need to link in
libquadmath, which is probably not desirable.  So, ideally there should
be some way to tell the library we have IEEE 754 quad __float128 and
for now the library should just print that the number is not printable.
Ditto for _Decimal{32,64,128}, which should probably just be a different
kind from float, and again would require additional library to support
printing into strings, so perhaps it could be for now just printed
as something unprintable.

Jakub

Re: [PATCH][MIPS] P5600 scheduling

[Richard Sandiford]

Hi Jaydeep,

Thanks for the write-up and updated patches.  I'll try to get to them
this weekend.  In the meantime...

Jaydeep Patil  writes:
> The -msched-weight option:
> We are using ~650 hot-spot functions from VP9/VP8/H264/MPEG4 codes 
> available to us as a test suite. The default Haifa-scheduler worked 
> well for most of the functions, but excess spilling was observed in 
> cases where register pressure was more than ~20. The 
> -fsched-pressure flag proved good in some cases, but the algorithm 
> focuses more on reducing register pressure.
> We observed increase in stalls (but less spilling) with the -fsched- 
> pressure option. When the register pressure goes beyond a certain 
> threshold, the -msched-weight option tries to keep it down by 
> promoting certain instructions up in the order. It has been 
> implemented as part of TARGET_SCHED_REORDER target hook (function 
> mips_sched_weight). The change is generic and there is nothing 
> specific to MIPS.
>
> When the register pressure goes beyond 15 then an instruction with 
> maximum forward dependency is promoted ahead of the instruction at
> READY[NREADY-1].
> Scheduling of an INSN with maximum forward dependency enables early 
> scheduling of instructions dependent on it.
>
> When the register pressure goes beyond 25 and if consumer of the 
> instruction in question (INSN) has higher priority than the 
> instruction at READY[NREADY-1] then INSN is promoted. This chooses 
> an INSN which has a high priority instruction dependent on it. This 
> triggers the scheduling of that consumer instruction as early as 
> possible to free up the registers used by that instruction.

Yeah, this sounds similar to what I was seeing for Cortex-A8
with the default -fsched-pressure (which is tuned for and known
to work well on x86).  Did you try with:

  -fsched-pressure --param sched-pressure-heuristic=2

?  That isn't advertised in the documentation because we don't
want to make it a user-level option that would then need to be
supported in future.  But if you find that the above works better
than plain -fsched-pressure, which is equivalent to:

  -fsched-pressure --param sched-pressure-heuristic=1

then we could consider making sched-pressure-heuristic=2 the
default for MIPS.  I'd certainly be interested to know how it
compares with -msched-weight.

FWIW the write-up of the alternative -fsched-pressure is here:

  https://gcc.gnu.org/ml/gcc-patches/2011-12/msg01684.html

It sounds like the Linaro guys have a performance fix pending, so if
running the tests takes a lot of your time or a lot of resources,
it might be worth waiting until that's submitted.

E.g. one of the things I noticed with the default -fsched-pressure
at the time -- not sure whether this has changed since -- is that
the pressure at the start of the EBB was based on the total number
of live values, including those that are live across a loop but
not used in it.  So in many cases the starting pressure was too high
and so like you say the heuristic was too conservative.  That was
one of the main things that the alternative heuristic was supposed
to help with.

It looks like you solve that by starting with a pressure of 0
for each EBB, is that right?  That's a bit more aggressive than
what I did, since AIUI starting with 0 will ignore loop invariants.
On the other hand, being more aggressive (i.e. closer to what you'd get
with the default scheduling heuristic) also means that it's more likely
to be usable by default.

Thanks,
Richard

Re: libsanitizer merge from upstream r208536

[Konstantin Serebryany]

>
>> > 3) there is still a failure for -m32:
>> > FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_long_double 
>> > Ident(p)[12] = 0 output pattern test
>> > Output should match: WRITE of size 1[06]
>> > FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_UAF_long_double 
>> > Ident(p)[0] = Ident(p)[12] output pattern test
>> > Output should match: READ of size 1[06]
>> >That sounds like something to fix in upstream, it should allow also size
>> >12 which is the size of long double on ia32 (16 bytes on x86_64),
>> >thus 1[026].  Kostya, can you please change it, I'll then apply it
>> >to the testsuite patch too?
>> Like this?
>>
>> --- lib/asan/tests/asan_test.cc (revision 209430)
>> +++ lib/asan/tests/asan_test.cc (working copy)
>> @@ -183,8 +183,8 @@
>>  TEST(AddressSanitizer, UAF_long_double) {
>>if (sizeof(long double) == sizeof(double)) return;
>>long double *p = Ident(new long double[10]);
>> -  EXPECT_DEATH(Ident(p)[12] = 0, "WRITE of size 1[06]");
>> -  EXPECT_DEATH(Ident(p)[0] = Ident(p)[12], "READ of size 1[06]");
>> +  EXPECT_DEATH(Ident(p)[12] = 0, "WRITE of size 1[026]");
>> +  EXPECT_DEATH(Ident(p)[0] = Ident(p)[12], "READ of size 1[026]");
>>delete [] Ident(p);
>>  }
>>
>
> Yep, exactly.

done, r209445.

Re: [PATCH][MIPS] P5600 scheduling

[Richard Sandiford]

Richard Sandiford  writes:
> Yeah, this sounds similar to what I was seeing for Cortex-A8
> with the default -fsched-pressure (which is tuned for and known
> to work well on x86).  Did you try with:
>
>   -fsched-pressure --param sched-pressure-heuristic=2

Gah, sched-pressure-algorithm rather than sched-pressure-heuristic

Commit: MSP430: Add spaces after options inserted by ASM_SPEC

[Nick Clifton]

Hi Guys,

  I am applying the patch below (to mainline and the 4.9 branch) to fix
  a small bug in the definition of ASM_SPEC for the MSP430.  The problem
  was that there were no spaces between some of the options that could
  be inserted into the assembler command line, which could produce
  unintelligible options.

Cheers
  Nick

gcc/ChangeLog
2014-05-22  Nick Clifton  

* config/msp430/msp430.h (ASM_SPEC): Add spaces after inserted
options.

Index: gcc/config/msp430/msp430.h
===
--- gcc/config/msp430/msp430.h  (revision 210807)
+++ gcc/config/msp430/msp430.h  (working copy)
@@ -55,8 +55,8 @@
   "%{mcpu=*:-mcpu=%*}%{!mcpu=*:%{mmcu=*:-mmcu=%*}} " /* Pass the CPU type on 
to the assembler.  */ \
   "%{mrelax=-mQ} " /* Pass the relax option on to the assembler.  */ \
   "%{mlarge:-ml} " /* Tell the assembler if we are building for the LARGE 
pointer model.  */ \
-  "%{!msim:-md} %{msim:%{mlarge:-md}}" /* Copy data from ROM to RAM if 
necessary.  */ \
-  "%{ffunction-sections:-gdwarf-sections}" /* If function sections are being 
created then create DWARF line number sections as well.  */
+  "%{!msim:-md} %{msim:%{mlarge:-md}} " /* Copy data from ROM to RAM if 
necessary.  */ \
+  "%{ffunction-sections:-gdwarf-sections} " /* If function sections are being 
created then create DWARF line number sections as well.  */
 
 /* Enable linker section garbage collection by default, unless we
are creating a relocatable binary (gc does not work) or debugging

Re: [PATCH 4/5] add gcc/gdb interface files

[Jeff Law]

On 05/22/14 07:16, Jakub Jelinek wrote:

On Thu, May 22, 2014 at 06:52:05AM -0600, Jeff Law wrote:

On 05/16/14 09:26, Tom Tromey wrote:


2014-05-16  Phil Muldoon  
Jan Kratochvil  
Tom Tromey  

* gcc-c-fe.def: New file.
* gcc-c-interface.h: New file.
* gcc-interface.h: New file.
---


+GCC_METHOD7 (gcc_decl, build_decl,
+const char */* name */,
+enum gcc_c_symbol_kind /* sym_kind */,
+gcc_type /* sym_type */,
+const char */* substitution_name */,
+gcc_address /* address */,
+const char */* filename */,
+unsigned int /* line_number */)

I must say that I hate the embedded comments in the signatures.
Especially when you end up with something like:


Why it can't be:
GCC_METHOD7 (gcc_decl, build_decl,
 const char *name,
 enum gfc_c_symbol_kind sym_kind,
...
i.e. provide comments in the form of argument names
(sure, you can't use bool for the name of the parameter then...).
No idea.  I'd assumed they had it in a comment rather than in the 
signature for a reason.


jeff

Commit: MSP430: Built libgcc with hardware multiply disabled

[Nick Clifton]

Hi Guys,

  I am applying the patch below (to mainline and the 4.9 branch) to fix
  a problem when building libgcc for the MSP430.  The problem was that
  the software multiply functions were being renamed to the hardware
  multiply equivalents, and libgcc was using the hardware multiply
  feature even when it was not clear that it would be supported by the
  target MCU.  The fix is just to disable the use of hardware multiplies
  inside libgcc.

Cheers
  Nick

libgcc/ChangeLog
2014-05-22  Nick Clifton  

* config/msp430/t-msp430 (HOST_LIBGCC2_CFLAGS): Add
-mhwmult=none.

Index: config/msp430/t-msp430
===
--- config/msp430/t-msp430  (revision 210809)
+++ config/msp430/t-msp430  (working copy)
@@ -42,7 +42,7 @@
$(srcdir)/config/msp430/floathisf.c \
$(srcdir)/config/msp430/cmpd.c
 
-HOST_LIBGCC2_CFLAGS += -Os -ffunction-sections -fdata-sections
+HOST_LIBGCC2_CFLAGS += -Os -ffunction-sections -fdata-sections -mhwmult=none
 
 # Local Variables:
 # mode: Makefile

Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags

[Jan Hubicka]

> 
> Can we?  If the body is not readily available we only have decl and
> cgraph-node, not struct function.
> 
> I suppose we could exchange the struct function pointer in
> tree_function_decl for a cgraph_node pointer and put
> the struct function pointer into the cgraph_node.
> 
> Of course that may have impacts on FEs who might create
> struct function before creating a cgraph node.  But at least
> it would avoid enlarging FUNCTION_DECL.
> 
> In the end most of the tree_decl_with_vis stuff should move over to symtab
> and var-decls should get a varpool_node pointer as well.
> 
> Back to the call flags stuff - I also meant the representation of the
> "fn spec" attribute.  Rather than parsing that again and again move
> it to a better place (which you seem to invent?) and better unified
> representation.
> 
> Can you try if removing the cgraph hash is possible with the
> struct function pointer idea?

It won't be so easy, because struct function is really built at relatively 
convoluted
places within frontend before cgraph node is assigned to them (I tried that few 
years
back).
I think we may be on better track moving DECL_ASSEMBLER_NAME that is calculated 
later,
but then we have problem with DECL_ASSEMBLER_NAME being set for assembler names 
and
const decls, too that still go around symtab.
Given that decl_assembler_name is a function, I suppose we could go with extra 
conditoinal
in there.

Getting struct function out of frontend busyness would be nice indeed, too, but 
probably
should be independent of Martin's work here.

Honza
> 
> Thanks,
> Richard.
> 
> > Thanks,
> >
> > Martin
> >
> >>
> >> > +   }
> >> >  }
> >> > +
> >> > +  return ret;
> >> >  }
> >> >
> >> >  /* Detects return flags for the call STMT.  */
> >> >

Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags

[Richard Biener]

On May 22, 2014 5:24:33 PM CEST, Jan Hubicka  wrote:
>> 
>> Can we?  If the body is not readily available we only have decl and
>> cgraph-node, not struct function.
>> 
>> I suppose we could exchange the struct function pointer in
>> tree_function_decl for a cgraph_node pointer and put
>> the struct function pointer into the cgraph_node.
>> 
>> Of course that may have impacts on FEs who might create
>> struct function before creating a cgraph node.  But at least
>> it would avoid enlarging FUNCTION_DECL.
>> 
>> In the end most of the tree_decl_with_vis stuff should move over to
>symtab
>> and var-decls should get a varpool_node pointer as well.
>> 
>> Back to the call flags stuff - I also meant the representation of the
>> "fn spec" attribute.  Rather than parsing that again and again move
>> it to a better place (which you seem to invent?) and better unified
>> representation.
>> 
>> Can you try if removing the cgraph hash is possible with the
>> struct function pointer idea?
>
>It won't be so easy, because struct function is really built at
>relatively convoluted
>places within frontend before cgraph node is assigned to them (I tried
>that few years
>back).

Well, just call cgraph create node from struct Funktion allocation.

Richard.

>I think we may be on better track moving DECL_ASSEMBLER_NAME that is
>calculated later,
>but then we have problem with DECL_ASSEMBLER_NAME being set for
>assembler names and
>const decls, too that still go around symtab.
>Given that decl_assembler_name is a function, I suppose we could go
>with extra conditoinal
>in there.
>
>Getting struct function out of frontend busyness would be nice indeed,
>too, but probably
>should be independent of Martin's work here.
>
>Honza
>> 
>> Thanks,
>> Richard.
>> 
>> > Thanks,
>> >
>> > Martin
>> >
>> >>
>> >> > +   }
>> >> >  }
>> >> > +
>> >> > +  return ret;
>> >> >  }
>> >> >
>> >> >  /* Detects return flags for the call STMT.  */
>> >> >

Breakage with [PATCH, libgfortran] PR60324 Handle arbitrarily long path names

[Hans-Peter Nilsson]

On Mon, 19 May 2014, Janne Blomqvist wrote:
> Hello,
>
> some systems such as GNU Hurd, don't define PATH_MAX at all, and on
> some other systems many syscalls apparently work for paths longer than
> PATH_MAX. Thus GFortran shouldn't truncate paths to PATH_MAX
> characters, but rather use heap allocated buffers limited only by the
> available memory. The attached patch implements this, with the
> exception of the backtrace functionality where we cannot use malloc
> since backtrace might be called from a signal handler.
>
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>
> 2014-05-19  Janne Blomqvist  
>
> PR libfortran/60324
> * config.h.in: Regenerated.
> * configure: Regenerated.
> * configure.ac (AC_CHECK_FUNCS_ONCE): Check for strnlen and
> strndup.
> * libgfortran.h (fc_strdup): New prototype.
> * runtime/string.c (strnlen): New fallback function.
> (strndup): New fallback function.
> (fc_strdup): New function.
> * io/close.c (st_close): Use fc_strdup.
> * io/open.c (new_unit): Likewise.
> (already_open): Likewise.
> * io/unit.c (filename_from_unit): Likewise.
> * io/unix.c (unpack_filename): Remove function.
> (regular_file): Rename to regular_file2, add path argument.
> (regular_file): New function calling regular_file2.
> (compare_file_filename): Use fc_strdup.
> (find_file): Likewise.
> (delete_file): Likewise.
> (file_exists): Likewise.
> (file_size): Likewise.
> (inquire_sequential): Likewise.
> (inquire_direct): Likewise.
> (inquire_formatted): Likewise.
> (inquire_access): Likewise.
> * io/unix.h (unpack_filename): Remove prototype.
> * runtime/main.c (please_free_exe_path_when_done): Change type to
> bool.
> (store_exe_path): Use malloced buffer, grow as needed.

This patch broke build for newlib targets; you need AC_DEFINE
clauses for those in the "if-then"-leg where you patched the
"else"-leg. There's also a need for #include  for the
malloc use in runtime/string.c.

brgds, H-P

Re: [build, driver] RFC: Support compressed debug sections

[Joseph S. Myers]

On Thu, 22 May 2014, Rainer Orth wrote:

>   * common.opt (compressed_debug_sections): New enum.
>   (gz, gz=): New options.

>   * opts.c (common_handle_option): Handle OPT_gz, OPT_gz_.

Given that the options are completely handled via specs, why can't they 
just be Driver options (without Common) and so not mentioned in 
common_handle_option?

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Create a library for tools like collect2 and lto-wrapper (2/2)

[Joseph S. Myers]

On Thu, 22 May 2014, Bernd Schmidt wrote:

> The implementations of some functions like fork_execute are changed to those
> from collect2 and the calls in lto-wrapper adapted accordingly. There are some
> minor changes in these functions: for example I avoid calling fatal_error,
> instead using the fatal/fatal_perror functions so that the cleanup routine is
> called properly (lto-wrapper does not use atexit as collect2 does).

Avoiding fatal_error seems like the wrong direction.  Using the common 
diagnostics code from diagnostic.c is preferred to using custom code.  
Thus, as an initial step I'd suggest instead converting lto-wrapper to use 
the common functionality where possible (fatal_error with %m replacing 
fatal_perror), making it use atexit in the process.  Don't move code using 
legacy fatal / fatal_perror functions to a common library.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] cplus-demangler, free resource after a failed call to gnu_special.

[Gary Benson]

Hi Thomas,

Thomas Schwinge wrote:
> In GCC, I'm consistenly seeing the following new failure:
> 
> ./test-demangle < ../../../source/libiberty/testsuite/demangle-expected
> FAIL at line 4350, options --format=auto --no-params:
> in:  _QueueNotification_QueueController__$4PPPM_A_INotice___Z
> out: (null)
> exp: 
> ./test-demangle: 895 tests, 1 failures
> make[2]: *** [check-cplus-dem] Error 1
> 
> The patch was committed incompletely; I added the missing last line in
> r210803:
[snip]
> @@ -4347,3 +4347,4 @@ void post >(std::function ()>&&)::{lambda()#1}*& std
>  --format=auto --no-params
>  _QueueNotification_QueueController__$4PPPM_A_INotice___Z
>  _QueueNotification_QueueController__$4PPPM_A_INotice___Z
> +_QueueNotification_QueueController__$4PPPM_A_INotice___Z

I thought that extra line was a mistake; I thought each test was
precisely three lines:

  # options
  # input to be demangled
  # expected output

What is the extra line here?

Thanks,
Gary

-- 
http://gbenson.net/

Re: [PATCH, rs6000] Fix HTM __builtin_ttest rtl expansion

[Peter Bergner]

On Tue, 2014-05-20 at 16:36 -0400, David Edelsohn wrote:
> On Tue, May 20, 2014 at 3:28 PM, Peter Bergner  wrote:
> > gcc/
> > * config/rs6000/htm.md (ttest): Use correct shift value to get CR0.
> >
> > gcc/testsuite/
> > * gcc.target/powerpc/htm-ttest.c: New test.
> 
> Okay.

Ok, this was committed to trunk, 4.9 and 4.8 branches as revisions
210815, 210817 and 210818 respectively.  Thanks.

Peter

Re: [PATCH] cplus-demangler, free resource after a failed call to gnu_special.

[Thomas Schwinge]

Hi Gary!

On Thu, 22 May 2014 17:02:08 +0100, Gary Benson  wrote:
> Thomas Schwinge wrote:
> > In GCC, I'm consistenly seeing the following new failure:
> > 
> > ./test-demangle < ../../../source/libiberty/testsuite/demangle-expected
> > FAIL at line 4350, options --format=auto --no-params:
> > in:  _QueueNotification_QueueController__$4PPPM_A_INotice___Z
> > out: (null)
> > exp: 
> > ./test-demangle: 895 tests, 1 failures
> > make[2]: *** [check-cplus-dem] Error 1
> > 
> > The patch was committed incompletely; I added the missing last line in
> > r210803:
> [snip]
> > @@ -4347,3 +4347,4 @@ void post >(std::function > ()>&&)::{lambda()#1}*& std
> >  --format=auto --no-params
> >  _QueueNotification_QueueController__$4PPPM_A_INotice___Z
> >  _QueueNotification_QueueController__$4PPPM_A_INotice___Z
> > +_QueueNotification_QueueController__$4PPPM_A_INotice___Z
> 
> I thought that extra line was a mistake; I thought each test was
> precisely three lines:
> 
>   # options
>   # input to be demangled
>   # expected output
> 
> What is the extra line here?

I too had to look it up -- see the explanation at the beginning of the
file:

#--no-params There are two lines of expected output; the first
#is with DMGL_PARAMS, the second is without it.


Grüße,
 Thomas


pgpU4wIueQZmC.pgp
Description: PGP signature

Re: [build, driver] RFC: Support compressed debug sections

[Rainer Orth]

"Joseph S. Myers"  writes:

> On Thu, 22 May 2014, Rainer Orth wrote:
>
>>  * common.opt (compressed_debug_sections): New enum.
>>  (gz, gz=): New options.
>
>>  * opts.c (common_handle_option): Handle OPT_gz, OPT_gz_.
>
> Given that the options are completely handled via specs, why can't they 
> just be Driver options (without Common) and so not mentioned in 
> common_handle_option?

If I do this, -gz still gets passed to e.g. cc1, which errors out like
this:

cc1: error: unrecognised debug output level "z"

It seems my way of handling this is clearer than doing this in opts.c
(set_debug_level).

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Create a library for tools like collect2 and lto-wrapper (1/2)

[David Edelsohn]

> For offloading which is being implemented on the gomp4 branch, we're about to 
> introduce new mkoffload programs. These are going to require a lot of 
> functionality that's already present in lto-wrapper and collect2, I've 
> decided to make a new set of utility functions that can be linked in with 
> these programs.

> This is the first step, splitting off code from lto-wrapper into a new 
> collect-utils.c file. The next step will replace some of these with 
> almost-identical ones from collect2 and make that tool also link with 
> collect-utils.

> Bootstrapped and tested on x86_64-linux, ok for trunk?

Given that collect2 is critical for ctors and dtors on AIX and AIX has
been the major (only?) recent user of collect2, please test this on
AIX.

Thanks, David

Re: [build, driver] RFC: Support compressed debug sections

[Joseph S. Myers]

On Thu, 22 May 2014, Rainer Orth wrote:

> "Joseph S. Myers"  writes:
> 
> > On Thu, 22 May 2014, Rainer Orth wrote:
> >
> >>* common.opt (compressed_debug_sections): New enum.
> >>(gz, gz=): New options.
> >
> >>* opts.c (common_handle_option): Handle OPT_gz, OPT_gz_.
> >
> > Given that the options are completely handled via specs, why can't they 
> > just be Driver options (without Common) and so not mentioned in 
> > common_handle_option?
> 
> If I do this, -gz still gets passed to e.g. cc1, which errors out like
> this:
> 
> cc1: error: unrecognised debug output level "z"
> 
> It seems my way of handling this is clearer than doing this in opts.c
> (set_debug_level).

Thanks for the explanation.  The driver changes are OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

RE: [PATCH][MIPS] Implement O32 FPXX ABI (GCC)

[Maciej W. Rozycki]

On Thu, 22 May 2014, Matthew Fortune wrote:

> GCC is saving too much of the callee-saved registers when single-precision
> values are live in them but this is historic behaviour. The code which
> controls this is very complex and I'd be worried about breaking it. The
> fix would be invasive as all the logic is honed towards the notion of
> 64-bit callee-saved registers. One thing to say is that this test is
> a very aggressive test of ABI not normal compiler behaviour. Normally
> an even-numbered callee-saved register would be used first followed by the
> odd meaning that it is rare to only use the odd register. That flips the
> problem round to single precision data in even registers...
> 
> I believe that prior to mips32 introducing odd-numbered single-precision
> registers then GCC will have been saving and restoring using sdc1/ldc1
> for even-numbered registers regardless of whether they are used for
> single or double precision data (for mips1 it also will do pairs of
> lwc1/swc1).

 This is required by the architecture, on legacy MIPS processors any 
arithmetic operation writing to a single floating-point (S format) or a 
single fixed-point (W format) destination is specified to leave the upper 
32 bits of the destination in an undefined state.  Depending on the FPU 
implementation and the state of the CP0 Status.FR bit (when implemented) 
the upper 32 bits are located in either the upper half of the 64-bit FPR 
selected or the odd-numbered 32-bit FPR corresponding to the even-numbered 
FPR selected.  See the StoreFPR pseudocode in the R4400 processor manual 
or other legacy MIPS documentation that you undoubtedly have handy.

 So while making changes in this area you need to take care to retain 
saving/restoring full double FPRs on pre MIPS32/MIPS64 processors as their 
upper halves may be clobbered even if only single operations are used.

  Maciej

RE: [PATCH][MIPS] Implement O32 FPXX ABI (GCC)

[Maciej W. Rozycki]

On Thu, 22 May 2014, Matthew Fortune wrote:

> I'm not confident that it would be the right thing to change this
> behaviour. While the test is slightly weird in that the compiler generates
> code that touches a -ffixed-reg this is just an ABI test.
> 
> == Taken from MIPS ABI supplement ==
> Only registers $f20.$f30 are preserved across a function call. All other 
> float-
> ing-point registers can change across a function call. However, functions
> that use any of $f20.$f30 for single-precision operations only must still save
> and restore the corresponding odd-numbered register since the odd-num-
> bered register contents are left undefined by single-precision operations
> == end == 
> 
> There are comments in the code to assert that this is behaviour is very much
> intentional as well:
> 
> == mips.c ==
> static bool
> mips_save_reg_p (unsigned int regno)
> {
>   if (mips_cfun_call_saved_reg_p (regno))
> {
>   if (mips_cfun_might_clobber_call_saved_reg_p (regno))
> return true;
> 
>   /* Save both registers in an FPR pair if either one is used.  This is
>  needed for the case when MIN_FPRS_PER_FMT == 1, which allows the odd
>  register to be used without the even register.  */
>   if (FP_REG_P (regno)
>   && MAX_FPRS_PER_FMT == 2
>   && mips_cfun_might_clobber_call_saved_reg_p (regno + 1))
> return true;
> }
> 
>   /* We need to save the incoming return address if __builtin_eh_return
>  is being used to set a different return address.  */
>   if (regno == RETURN_ADDR_REGNUM && crtl->calls_eh_return)
> return true;
> 
>   return false;
> }
> == end ==
> 
> I therefore take back my comment about the prologue/epilogue saving too much
> callee-save register state :-) It is doing exactly what is required by the
> arch. I doubt very much that any MIPS implementation would end up with
> incorrect operation if you ran the following and ended up with $f18 and $f20
> being different or undefined behaviour if $f20 were accessed as a double but 
> that is actually what the spec says.
> 
> ADD.D $f20, $f10, $f10
> MOV.D $f18, $f20
> SWC1 $f20, 0($sp)
> MTC1 $2, $f20
> LWC1 $f20, 0($sp)
> ADD.D $f16, $f18, $f20
> ($f16 should be 4*$f10)

 Neither of MTC1/LWC1 is arithmetic so a different rule applies.  This 
code will work just fine on a 32-bit FPU or with the CP0 Status.FR bit 
clear where implemented because non-arithmetic FPR 32-bit write operations 
do not change the corresponding high-order 32-bit FPR.  It will only break 
with the CP0 Status.FR bit set, where the upper half of the 64-bit FPR 
written will be left undefined, but that is actually no different to the 
current architecture definition.

 This code would break on legacy processors if you substituted MTC1 with 
an arithmetic operation e.g.:

ADD.D $f20, $f10, $f10
MOV.D $f18, $f20
SWC1 $f20, 0($sp)
CVT.S.D $f20, $f20
LWC1 $f20, 0($sp)
ADD.D $f16, $f18, $f20
($f16 should be 4*$f10)

> Presumably, to account for MIPS I then a pair of SWC1s/LWC1s are required
> by the architecture to allow the resulting even numbered register to be
> accessed as a double.
> 
> MIPS32 to my knowledge makes no re-assuring statement that accessing the
> odd numbered register with a single precision operation does not clobber
> the lower 32-bits of the double it is overlaid with.

 But the MIPS psABI also says that only MIPS I ISA instructions may be 
used in a compliant program, so by building a program for the MIPS32 or 
higher ISA you've already broken the ABI as it stands.  So I think we 
could relax the rule on FPR saving/restoration from MIPS32 ISA up, as an 
ABI extension that we already made anyway.

  Maciej

Re: [PATCH i386 5/8] [AVX-512] Extend vectorizer hooks.

[H.J. Lu]

On Thu, May 22, 2014 at 2:01 AM, Kirill Yukhin  wrote:
> Hello,
> On 20 May 08:24, H.J. Lu wrote:
>> ABI alignment should be sufficient for correctness. Bigger alignments
>> are supposed to give better performance.  Can you try this patch on
>> HSW and SLM to see if it has any impact on performance?
>
> Here is perf. data of your patch.
>
> Only HSW so far
>
> HSW, 64 bits, base
>
> Test Previous Current Ratio(%)
> 400.perlbench 37.700037.7000 +0%
> 401.bzip2 24.800024.7000 -0.40%
> 403.gcc   35.100035.2000 +0.28%
> 429.mcf   41.700042. +0.71%
> 445.gobmk 26.900027. +0.37%
> 456.hmmer 27.200027.2000 +0%
> 458.sjeng 30.200030.1000 -0.33%
> 462.libquantum77.400076.7000 -0.90%
> 464.h264ref   52.500052.8000 +0.57%
> 471.omnetpp   23.800023.7000 -0.42%
> 473.astar 23.200023.1000 -0.43%
> 483.xalancbmk 39.800040.1000 +0.75%
> 410.bwaves78.400078.5000 +0.12%
> 416.gamess33.900033.9000 +0%
> 433.milc  34.700034.8000 +0.28%
> 434.zeusmp38.600038.4000 -0.51%
> 435.gromacs   26.900027. +0.37%
> 436.cactusADM 54.700062. +13.34%
> 437.leslie3d  45.300045.3000 +0%
> 444.namd  27.200027.1000 -0.36%
> 447.dealII56.700056.7000 +0%
> 450.soplex39.300039.3000 +0%
> 453.povray49.49.1000 +0.20%
> 454.calculix  28.800029.3000 +1.73%
> 459.GemsFDTD  38.900039. +0.25%
> 465.tonto 23.100023.3000 +0.86%
> 470.lbm   55.300055.6000 +0.54%
> 481.wrf   40.800040.8000 +0%
> 482.sphinx3   47.800047.9000 +0.20%
>
> HSW, 64 bits, o2
>
> Test Previous Current Ratio(%)
> 400.perlbench 39.700039.7000 +0%
> 401.bzip2 25.100025.1000 +0%
> 403.gcc   33.700033.7000 +0%
> 429.mcf   40.100039.9000 -0.49%
> 445.gobmk 26.500026.4000 -0.37%
> 456.hmmer 24.800024.8000 +0%
> 458.sjeng 28.400028.5000 +0.35%
> 462.libquantum74.400074.4000 +0%
> 464.h264ref   50.100050.3000 +0.39%
> 471.omnetpp   22.600022.5000 -0.44%
> 473.astar 20.700021. +1.44%
> 483.xalancbmk 37.37.4000 +1.08%
> 410.bwaves60.100060.1000 +0%
> 416.gamess35.500035.4000 -0.28%
> 433.milc  29.900029.8000 -0.33%
> 434.zeusmp34.800034.6000 -0.57%
> 435.gromacs   27.400027.5000 +0.36%
> 436.cactusADM 32.300033.8000 +4.64%
> 437.leslie3d  32.600032.6000 +0%
> 444.namd  26.900026.9000 +0%
> 447.dealII45.200045.1000 -0.22%
> 450.soplex42.500042.6000 +0.23%
> 453.povray45.900046.1000 +0.43%
> 454.calculix  12.900012.9000 +0%
> 459.GemsFDTD  38.600038.7000 +0.25%
> 465.tonto 23.700023.8000 +0.42%
> 470.lbm   56.700056.7000 +0%
> 481.wrf   28.900028.9000 +0%
> 482.sphinx3   43.900043.8000 -0.22%
>

So extra alignment doesn't have any performance impact
on HSW with SPEC CPU 2006.  So the question is if using
alignment specified by ABI will cause any correctness issue.
I am concerned about the comment:

  /* GCC 4.8 and earlier used to incorrectly assume this alignment even
 for symbols from other compilation units or symbols that don't need
 to bind locally.  In order to preserve some ABI compatibility with
 those compilers, ensure we don't decrease alignment from what we
 used to assume.  */

Jakub,  will we into any correctness issue if ix86_data_alignment
always returns ABI alignment?


-- 
H.J.

Re: [PATCH 7/7] Plug ipa-prop escape analysis into gimple_call_arg_flags

[Jan Hubicka]

> >It won't be so easy, because struct function is really built at
> >relatively convoluted
> >places within frontend before cgraph node is assigned to them (I tried
> >that few years
> >back).
> 
> Well, just call cgraph create node from struct Funktion allocation.

That will make uninstantiated templates to land symbol table (and if you have
aliases, also do the assembler name mangling) that is not that cool either :(

Honza
> 
> Richard.
> 
> >I think we may be on better track moving DECL_ASSEMBLER_NAME that is
> >calculated later,
> >but then we have problem with DECL_ASSEMBLER_NAME being set for
> >assembler names and
> >const decls, too that still go around symtab.
> >Given that decl_assembler_name is a function, I suppose we could go
> >with extra conditoinal
> >in there.
> >
> >Getting struct function out of frontend busyness would be nice indeed,
> >too, but probably
> >should be independent of Martin's work here.
> >
> >Honza
> >> 
> >> Thanks,
> >> Richard.
> >> 
> >> > Thanks,
> >> >
> >> > Martin
> >> >
> >> >>
> >> >> > +   }
> >> >> >  }
> >> >> > +
> >> >> > +  return ret;
> >> >> >  }
> >> >> >
> >> >> >  /* Detects return flags for the call STMT.  */
> >> >> >
> 

Re: [C++ Patch] PR 61088

[Jason Merrill]

On 05/22/2014 04:27 AM, Paolo Carlini wrote:

lambda-ice7.C:8:9: error: cannot capture by value ‘a’ of incomplete type
‘A’
[=](){a;};
^


All the carets in your mail are in the first column; is this one in the 
right place for you?


Let's not print out the expression, we've been moving away from that. 
Maybe "capture by value of incomplete type 'A'".


OK with that change.


4- Finally, something I noticed while working on add_capture: right above the 
new check there is:

type = lambda_capture_field_type (initializer, explicit_init_p);
if (by_reference_p)
{
type = build_reference_type (type);
if (!real_lvalue_p (initializer))
error ("cannot capture %qE by reference", initializer);
}

now, interestingly, nothing in the testsuite exercises this error. And, so far, 
I failed to create a testcase for it. The Standard too doesn't seem to me so 
clear about that. Ideas?!?


void f()
{
  [&x=1]{}
}

Jason

Re: libsanitizer merge from upstream r208536

[Jakub Jelinek]

On Thu, May 22, 2014 at 04:07:38PM +0200, Jakub Jelinek wrote:
> 2014-05-22  Jakub Jelinek  
> 
>   * sanitizer.def (BUILT_IN_ASAN_REPORT_LOAD_N,
>   BUILT_IN_ASAN_REPORT_STORE_N): New.
>   * asan.c (struct asan_mem_ref): Change access_size type to
>   HOST_WIDE_INT.
>   (asan_mem_ref_init, asan_mem_ref_new, get_mem_refs_of_builtin_call,
>   update_mem_ref_hash_table): Likewise.
>   (asan_mem_ref_hasher::hash): Hash in a HWI.
>   (report_error_func): Change size_in_bytes argument to HWI.
>   Use *_N builtins if size_in_bytes is larger than 16 or not power of
>   two.
>   (build_shadow_mem_access): New function.
>   (build_check_stmt): Use it.  Change size_in_bytes argument to HWI.
>   Handle size_in_bytes not power of two or larger than 16.
>   (instrument_derefs): Don't give up if size_in_bytes is not
>   power of two or is larger than 16.

Both patches bootstrapped/regtested on x86_64-linux and i686-linux
successfully, ok for trunk for both?

Jakub

Re: [C++ Patch] PR 61088

[Paolo Carlini]

Hi,

On 05/22/2014 08:13 PM, Jason Merrill wrote:

On 05/22/2014 04:27 AM, Paolo Carlini wrote:

lambda-ice7.C:8:9: error: cannot capture by value ‘a’ of incomplete type
‘A’
[=](){a;};
^


All the carets in your mail are in the first column; is this one in 
the right place for you?
It would be definitely wrong, but it's just that I did something wrong 
with the mailer, it shows Ok on my shell, under the a. Look at the 
column, 9, which is fine.
Let's not print out the expression, we've been moving away from that. 
Maybe "capture by value of incomplete type 'A'".
Good. I wanted to ask about that. Also, by copy instead of by value, 
right? Because the Standard always talks about copy (likewise clang).


OK with that change.

4- Finally, something I noticed while working on add_capture: right 
above the new check there is:


type = lambda_capture_field_type (initializer, explicit_init_p);
if (by_reference_p)
{
type = build_reference_type (type);
if (!real_lvalue_p (initializer))
error ("cannot capture %qE by reference", initializer);
}

now, interestingly, nothing in the testsuite exercises this error. 
And, so far, I failed to create a testcase for it. The Standard too 
doesn't seem to me so clear about that. Ideas?!?


void f()
{
  [&x=1]{}
}
Right, thanks. I'm probably going to add it, at some point. Me, I was 
looking for something not using C++14 initializers, I think in that case 
is more difficult!?!


Paolo.

Re: libsanitizer merge from upstream r208536

[Paolo Carlini]

Hi,

On 05/22/2014 01:03 PM, Jakub Jelinek wrote:

On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:

FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test

Is that before or after r210743?

Can't reproduce the above (note, not bootstrapped compiler, just
--disable-bootstrap), check-gcc RUNTESTFLAGS=asan.exp is clean,
Thanks Jakub. I'm not bootstrapping either, but all the fails are still 
there (fetched a fresh tree, built again). I have just noticed the below 
during the build, are expected?


Paolo.



In file included from 
../../../../trunk/libsanitizer/asan/asan_interceptors.cc:147:0:
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc: 
In function ‘int __interceptor_accept4(int, void*, unsigned int*, int)’:
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1821:12: 
warning: ‘addrlen0’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]

unsigned addrlen0;
^
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc: 
In function ‘int __interceptor_accept(int, void*, unsigned int*)’:
../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1799:12: 
warning: ‘addrlen0’ may be used uninitialized in this function 
[-Wmaybe-uninitialized]

unsigned addrlen0;
^

Re: libsanitizer merge from upstream r208536

[Jakub Jelinek]

On Thu, May 22, 2014 at 08:38:31PM +0200, Paolo Carlini wrote:
> Hi,
> 
> On 05/22/2014 01:03 PM, Jakub Jelinek wrote:
> >On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
> >>FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test
> >Is that before or after r210743?
> >Can't reproduce the above (note, not bootstrapped compiler, just
> >--disable-bootstrap), check-gcc RUNTESTFLAGS=asan.exp is clean,
> Thanks Jakub. I'm not bootstrapping either, but all the fails are
> still there (fetched a fresh tree, built again). I have just noticed
> the below during the build, are expected?

In any case, I couldn't reproduce that even during fresh bootstrap/regtest
I did.

> In file included from
> ../../../../trunk/libsanitizer/asan/asan_interceptors.cc:147:0:
> ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:
> In function ‘int __interceptor_accept4(int, void*, unsigned int*,
> int)’:
> ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1821:12:
> warning: ‘addrlen0’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> unsigned addrlen0;
> ^
> ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:
> In function ‘int __interceptor_accept(int, void*, unsigned int*)’:
> ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1799:12:
> warning: ‘addrlen0’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> unsigned addrlen0;
> ^

That sounds like a false positive warning:
  unsigned addrlen0;
  if (addrlen) {
COMMON_INTERCEPTOR_READ_RANGE(ctx, addrlen, sizeof(*addrlen));
addrlen0 = *addrlen;
  }
  int fd2 = REAL(accept4)(fd, addr, addrlen, f);
  if (fd2 >= 0) {
if (fd >= 0) COMMON_INTERCEPTOR_FD_SOCKET_ACCEPT(ctx, fd, fd2);
if (addr && addrlen)
  COMMON_INTERCEPTOR_WRITE_RANGE(ctx, addr, Min(*addrlen, addrlen0));
  }
(unless the COMMON_INTERCEPTOR* macros do too weird stuff), wonder why the
predicate aware uninit doesn't handle this.

Jakub

Re: libsanitizer merge from upstream r208536

[Paolo Carlini]

Hi,

On 05/22/2014 09:02 PM, Jakub Jelinek wrote:

On Thu, May 22, 2014 at 08:38:31PM +0200, Paolo Carlini wrote:

Hi,

On 05/22/2014 01:03 PM, Jakub Jelinek wrote:

On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:

FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test

Is that before or after r210743?

Can't reproduce the above (note, not bootstrapped compiler, just
--disable-bootstrap), check-gcc RUNTESTFLAGS=asan.exp is clean,

Thanks Jakub. I'm not bootstrapping either, but all the fails are
still there (fetched a fresh tree, built again). I have just noticed
the below during the build, are expected?

In any case, I couldn't reproduce that even during fresh bootstrap/regtest
I did.
I see. Some of the fails I'm seeing spill this kind of diagnostic, does 
that tell you something?


FAIL: g++.dg/asan/large-func-test-1.C  -O1  output pattern test, is 
==18037==ASan runtime does not come first in initial library list; you 
should either link runtime to your application or manually preload it 
with LD_PRELOAD.

, should match ERROR: AddressSanitizer:? heap-buffer-overflow on address[^



Paolo.

Re: [C++ Patch] PR 61088

[Jason Merrill]

On 05/22/2014 02:26 PM, Paolo Carlini wrote:

Good. I wanted to ask about that. Also, by copy instead of by value,
right? Because the Standard always talks about copy (likewise clang).


Yes.


Right, thanks. I'm probably going to add it, at some point. Me, I was looking 
for something not using C++14 initializers, I think in that case is more 
difficult!?!


The error can only occur with a C++14 initializer; a (captured) variable 
is always an lvalue.


Jason

Re: libsanitizer merge from upstream r208536

[Jakub Jelinek]

On Thu, May 22, 2014 at 09:03:44PM +0200, Paolo Carlini wrote:
> Hi,
> 
> On 05/22/2014 09:02 PM, Jakub Jelinek wrote:
> >On Thu, May 22, 2014 at 08:38:31PM +0200, Paolo Carlini wrote:
> >>Hi,
> >>
> >>On 05/22/2014 01:03 PM, Jakub Jelinek wrote:
> >>>On Thu, May 22, 2014 at 02:26:19PM +0400, Konstantin Serebryany wrote:
> FAIL: c-c++-common/asan/asan-interface-1.c  -O0  execution test
> >>>Is that before or after r210743?
> >>>Can't reproduce the above (note, not bootstrapped compiler, just
> >>>--disable-bootstrap), check-gcc RUNTESTFLAGS=asan.exp is clean,
> >>Thanks Jakub. I'm not bootstrapping either, but all the fails are
> >>still there (fetched a fresh tree, built again). I have just noticed
> >>the below during the build, are expected?
> >In any case, I couldn't reproduce that even during fresh bootstrap/regtest
> >I did.
> I see. Some of the fails I'm seeing spill this kind of diagnostic,
> does that tell you something?
> 
> FAIL: g++.dg/asan/large-func-test-1.C  -O1  output pattern test, is
> ==18037==ASan runtime does not come first in initial library list;
> you should either link runtime to your application or manually
> preload it with LD_PRELOAD.
> , should match ERROR: AddressSanitizer:? heap-buffer-overflow on address[^
> 
> 

Do you have LD_PRELOAD set in the environment?
If not, can you cut'n'paste the large-func-test-1.exe command line
and run it with the given LD_LIBRARY_PATH under ldd?

Jakub

Re: [PATCH] cplus-demangler, free resource after a failed call to gnu_special.

[Gary Benson]

Thomas Schwinge wrote:
> On Thu, 22 May 2014 17:02:08 +0100, Gary Benson  wrote:
> > Thomas Schwinge wrote:
> > > In GCC, I'm consistenly seeing the following new failure:
> > > 
> > > ./test-demangle < 
> > > ../../../source/libiberty/testsuite/demangle-expected
> > > FAIL at line 4350, options --format=auto --no-params:
> > > in:  _QueueNotification_QueueController__$4PPPM_A_INotice___Z
> > > out: (null)
> > > exp: 
> > > ./test-demangle: 895 tests, 1 failures
> > > make[2]: *** [check-cplus-dem] Error 1
> > > 
> > > The patch was committed incompletely; I added the missing last line in
> > > r210803:
> > [snip]
> > > @@ -4347,3 +4347,4 @@ void post 
> > > >(std::function&&)::{lambda()#1}*& std
> > >  --format=auto --no-params
> > >  _QueueNotification_QueueController__$4PPPM_A_INotice___Z
> > >  _QueueNotification_QueueController__$4PPPM_A_INotice___Z
> > > +_QueueNotification_QueueController__$4PPPM_A_INotice___Z
> > 
> > I thought that extra line was a mistake; I thought each test was
> > precisely three lines:
> > 
> >   # options
> >   # input to be demangled
> >   # expected output
> > 
> > What is the extra line here?
> 
> I too had to look it up -- see the explanation at the beginning of
> the file:
> 
> #--no-params There are two lines of expected output; the first
> #is with DMGL_PARAMS, the second is without it.

Ah, I missed that.  Thank you for fixing this!

Gary

--
http://gbenson.net/

Re: [1/6] OpenMP 4.0 C FE support

[Thomas Schwinge]

Hi!

On Tue, 8 Oct 2013 21:52:40 +0200, Jakub Jelinek  wrote:
> --- gcc/c/c-parser.c  (.../trunk) (revision 203241)
> +++ gcc/c/c-parser.c  (.../branches/gomp-4_0-branch)  (revision 203287)

> +c_parser_omp_clause_thread_limit (c_parser *parser, tree list)
> [...]
> +  location_t num_teams_loc = c_parser_peek_token (parser)->location;

Applied in r210821:

commit 22ac3f78e77bed5dd3ede9db86954581175dcd96
Author: tschwinge 
AuthorDate: Thu May 22 19:44:14 2014 +
Commit: tschwinge 
CommitDate: Thu May 22 19:44:14 2014 +

Fix copy'n'pasto.

gcc/c/
* c-parser.c (c_parser_omp_clause_thread_limit): Rename
num_teams_loc variable to num_thread_limit_loc.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210821 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/c/ChangeLog  | 5 +
 gcc/c/c-parser.c | 4 ++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git gcc/c/ChangeLog gcc/c/ChangeLog
index 76d5c46..9acc6f7 100644
--- gcc/c/ChangeLog
+++ gcc/c/ChangeLog
@@ -1,3 +1,8 @@
+2014-05-22  Thomas Schwinge  
+
+   * c-parser.c (c_parser_omp_clause_thread_limit): Rename
+   num_teams_loc variable to num_thread_limit_loc.
+
 2014-05-21  Richard Sandiford  
 
* c-array-notation.c (expand_array_notations): Use void_node
diff --git gcc/c/c-parser.c gcc/c/c-parser.c
index bfc7147..a7e33b0 100644
--- gcc/c/c-parser.c
+++ gcc/c/c-parser.c
@@ -10453,7 +10453,7 @@ c_parser_omp_clause_num_teams (c_parser *parser, tree 
list)
 static tree
 c_parser_omp_clause_thread_limit (c_parser *parser, tree list)
 {
-  location_t num_teams_loc = c_parser_peek_token (parser)->location;
+  location_t num_thread_limit_loc = c_parser_peek_token (parser)->location;
   if (c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
 {
   location_t expr_loc = c_parser_peek_token (parser)->location;
@@ -10483,7 +10483,7 @@ c_parser_omp_clause_thread_limit (c_parser *parser, 
tree list)
   check_no_duplicate_clause (list, OMP_CLAUSE_THREAD_LIMIT,
 "thread_limit");
 
-  c = build_omp_clause (num_teams_loc, OMP_CLAUSE_THREAD_LIMIT);
+  c = build_omp_clause (num_thread_limit_loc, OMP_CLAUSE_THREAD_LIMIT);
   OMP_CLAUSE_THREAD_LIMIT_EXPR (c) = t;
   OMP_CLAUSE_CHAIN (c) = list;
   list = c;


Grüße,
 Thomas


pgpvTToppkedG.pgp
Description: PGP signature

Re: libsanitizer merge from upstream r208536

[Paolo Carlini]

Hi,

On 05/22/2014 09:15 PM, Jakub Jelinek wrote:

Do you have LD_PRELOAD set in the environment?

I don't.
If not, can you cut'n'paste the large-func-test-1.exe command line and 
run it with the given LD_LIBRARY_PATH under ldd? Jakub 

Sure. This is what I get:

linux-vdso.so.1 (0x7fffee578000)
libasan.so.1 => 
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs/libasan.so.1 
(0x7f41610c7000)
libstdc++.so.6 => 
/home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so.6 
(0x7f4160db6000)

libm.so.6 => /lib64/libm.so.6 (0x7f4160ab3000)
libgcc_s.so.1 => 
/home/paolo/Gcc/svn-dirs/trunk-build/gcc/libgcc_s.so.1 (0x7f416089c000)

libc.so.6 => /lib64/libc.so.6 (0x7f41604ed000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f41602cf000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f41600cb000)
/lib64/ld-linux-x86-64.so.2 (0x7f4161ff3000)

Paolo.

Re: libsanitizer merge from upstream r208536

[Jakub Jelinek]

On Thu, May 22, 2014 at 09:43:01PM +0200, Paolo Carlini wrote:
> Hi,
> 
> On 05/22/2014 09:15 PM, Jakub Jelinek wrote:
> >Do you have LD_PRELOAD set in the environment?
> I don't.
> >If not, can you cut'n'paste the large-func-test-1.exe command line
> >and run it with the given LD_LIBRARY_PATH under ldd? Jakub
> Sure. This is what I get:
> 
> linux-vdso.so.1 (0x7fffee578000)
> libasan.so.1 => 
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs/libasan.so.1
> (0x7f41610c7000)
> libstdc++.so.6 => 
> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so.6
> (0x7f4160db6000)
> libm.so.6 => /lib64/libm.so.6 (0x7f4160ab3000)
> libgcc_s.so.1 =>
> /home/paolo/Gcc/svn-dirs/trunk-build/gcc/libgcc_s.so.1
> (0x7f416089c000)
> libc.so.6 => /lib64/libc.so.6 (0x7f41604ed000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f41602cf000)
> libdl.so.2 => /lib64/libdl.so.2 (0x7f41600cb000)
> /lib64/ld-linux-x86-64.so.2 (0x7f4161ff3000)

Kostya, guess you should ignore the vDSO.

I'd say the test is useless anyway, if you really want to do some
quick sanity check, much better would be just dlsym a couple of
interesting symbols to verify that libasan.so.1 is ahead
of libc.so.6, libstdc++.so.6, libpthread.so.0 (whatever else
you want to override).  Otherwise libasan apps will simply stop
working altogether if LD_PRELOAD is set, to whatever library,
even if it doesn't define any symbols you care about.
I'd verify that malloc, memcpy, pthread_create, operator new
all resolve to the libasan.so.1 copy (if all those have local aliases,
just compare what dlsym returns with those local aliases).
Typically people in LD_PRELOAD override malloc (which we want to diagnose),
or far more rarely stringops (e.g. memstomp, also undesirable).

Jakub

Re: libsanitizer merge from upstream r208536

[Konstantin Serebryany]

Yuri, this comes from yours
http://llvm.org/viewvc/llvm-project?view=revision&revision=205308
Could you please take a look?

On Thu, May 22, 2014 at 11:54 PM, Jakub Jelinek  wrote:
> On Thu, May 22, 2014 at 09:43:01PM +0200, Paolo Carlini wrote:
>> Hi,
>>
>> On 05/22/2014 09:15 PM, Jakub Jelinek wrote:
>> >Do you have LD_PRELOAD set in the environment?
>> I don't.
>> >If not, can you cut'n'paste the large-func-test-1.exe command line
>> >and run it with the given LD_LIBRARY_PATH under ldd? Jakub
>> Sure. This is what I get:
>>
>> linux-vdso.so.1 (0x7fffee578000)
>> libasan.so.1 => 
>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs/libasan.so.1
>> (0x7f41610c7000)
>> libstdc++.so.6 => 
>> /home/paolo/Gcc/svn-dirs/trunk-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so.6
>> (0x7f4160db6000)
>> libm.so.6 => /lib64/libm.so.6 (0x7f4160ab3000)
>> libgcc_s.so.1 =>
>> /home/paolo/Gcc/svn-dirs/trunk-build/gcc/libgcc_s.so.1
>> (0x7f416089c000)
>> libc.so.6 => /lib64/libc.so.6 (0x7f41604ed000)
>> libpthread.so.0 => /lib64/libpthread.so.0 (0x7f41602cf000)
>> libdl.so.2 => /lib64/libdl.so.2 (0x7f41600cb000)
>> /lib64/ld-linux-x86-64.so.2 (0x7f4161ff3000)
>
> Kostya, guess you should ignore the vDSO.
>
> I'd say the test is useless anyway, if you really want to do some
> quick sanity check, much better would be just dlsym a couple of
> interesting symbols to verify that libasan.so.1 is ahead
> of libc.so.6, libstdc++.so.6, libpthread.so.0 (whatever else
> you want to override).  Otherwise libasan apps will simply stop
> working altogether if LD_PRELOAD is set, to whatever library,
> even if it doesn't define any symbols you care about.
> I'd verify that malloc, memcpy, pthread_create, operator new
> all resolve to the libasan.so.1 copy (if all those have local aliases,
> just compare what dlsym returns with those local aliases).
> Typically people in LD_PRELOAD override malloc (which we want to diagnose),
> or far more rarely stringops (e.g. memstomp, also undesirable).
>
> Jakub

[COMMITTED] Cosmetic fixes for DEF_FUNCTION_TYPE_* macros.

[Thomas Schwinge]

From: tschwinge 

gcc/ada/
* gcc-interface/utils.c (DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_6)
(DEF_FUNCTION_TYPE_7, DEF_FUNCTION_TYPE_8)
(DEF_FUNCTION_TYPE_VAR_5): Cosmetic fixes.
gcc/
* builtin-types.def: Simplify examples for DEF_FUNCTION_TYPE_*.
gcc/c-family/
* c-common.c (DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_6)
(DEF_FUNCTION_TYPE_7, DEF_FUNCTION_TYPE_8)
(DEF_FUNCTION_TYPE_VAR_5): Cosmetic fixes.
gcc/fortran/
* f95-lang.c (DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_6)
(DEF_FUNCTION_TYPE_7, DEF_FUNCTION_TYPE_8)
(DEF_FUNCTION_TYPE_VAR_5): Cosmetic fixes.
* types.def: Simplify examples for DEF_FUNCTION_TYPE_*.
gcc/lto/
* lto-lang.c (DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_6)
(DEF_FUNCTION_TYPE_7, DEF_FUNCTION_TYPE_8)
(DEF_FUNCTION_TYPE_VAR_5): Cosmetic fixes.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210822 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog |  4 
 gcc/ada/ChangeLog |  6 ++
 gcc/ada/gcc-interface/utils.c | 14 ++
 gcc/builtin-types.def | 12 ++--
 gcc/c-family/ChangeLog|  6 ++
 gcc/c-family/c-common.c   | 14 ++
 gcc/fortran/ChangeLog |  7 +++
 gcc/fortran/f95-lang.c| 12 +---
 gcc/fortran/types.def |  8 +---
 gcc/lto/ChangeLog |  6 ++
 gcc/lto/lto-lang.c| 12 +---
 11 files changed, 70 insertions(+), 31 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index 65fb502..ace8d99 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,7 @@
+2014-05-22  Thomas Schwinge  
+
+   * builtin-types.def: Simplify examples for DEF_FUNCTION_TYPE_*.
+
 2012-05-22  Bernd Schmidt  
 
* config/darwin.c: Include "lto-section-names.h".
diff --git gcc/ada/ChangeLog gcc/ada/ChangeLog
index 547b327..8ce8b25 100644
--- gcc/ada/ChangeLog
+++ gcc/ada/ChangeLog
@@ -1,3 +1,9 @@
+2014-05-22  Thomas Schwinge  
+
+   * gcc-interface/utils.c (DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_6)
+   (DEF_FUNCTION_TYPE_7, DEF_FUNCTION_TYPE_8)
+   (DEF_FUNCTION_TYPE_VAR_5): Cosmetic fixes.
+
 2014-05-21  Robert Dewar  
 
* layout.adb: Minor reformatting.
diff --git gcc/ada/gcc-interface/utils.c gcc/ada/gcc-interface/utils.c
index 4f39dd6..56636a6 100644
--- gcc/ada/gcc-interface/utils.c
+++ gcc/ada/gcc-interface/utils.c
@@ -5914,15 +5914,18 @@ enum c_builtin_type
 #define DEF_FUNCTION_TYPE_3(NAME, RETURN, ARG1, ARG2, ARG3) NAME,
 #define DEF_FUNCTION_TYPE_4(NAME, RETURN, ARG1, ARG2, ARG3, ARG4) NAME,
 #define DEF_FUNCTION_TYPE_5(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5) NAME,
-#define DEF_FUNCTION_TYPE_6(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5, ARG6) 
NAME,
-#define DEF_FUNCTION_TYPE_7(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5, ARG6, 
ARG7) NAME,
-#define DEF_FUNCTION_TYPE_8(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5, ARG6, 
ARG7, ARG8) NAME,
+#define DEF_FUNCTION_TYPE_6(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5, \
+   ARG6) NAME,
+#define DEF_FUNCTION_TYPE_7(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5, \
+   ARG6, ARG7) NAME,
+#define DEF_FUNCTION_TYPE_8(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5, \
+   ARG6, ARG7, ARG8) NAME,
 #define DEF_FUNCTION_TYPE_VAR_0(NAME, RETURN) NAME,
 #define DEF_FUNCTION_TYPE_VAR_1(NAME, RETURN, ARG1) NAME,
 #define DEF_FUNCTION_TYPE_VAR_2(NAME, RETURN, ARG1, ARG2) NAME,
 #define DEF_FUNCTION_TYPE_VAR_3(NAME, RETURN, ARG1, ARG2, ARG3) NAME,
 #define DEF_FUNCTION_TYPE_VAR_4(NAME, RETURN, ARG1, ARG2, ARG3, ARG4) NAME,
-#define DEF_FUNCTION_TYPE_VAR_5(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG6) \
+#define DEF_FUNCTION_TYPE_VAR_5(NAME, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5) \
   NAME,
 #define DEF_POINTER_TYPE(NAME, TYPE) NAME,
 #include "builtin-types.def"
@@ -6053,12 +6056,15 @@ install_builtin_function_types (void)
 #include "builtin-types.def"
 
 #undef DEF_PRIMITIVE_TYPE
+#undef DEF_FUNCTION_TYPE_0
 #undef DEF_FUNCTION_TYPE_1
 #undef DEF_FUNCTION_TYPE_2
 #undef DEF_FUNCTION_TYPE_3
 #undef DEF_FUNCTION_TYPE_4
 #undef DEF_FUNCTION_TYPE_5
 #undef DEF_FUNCTION_TYPE_6
+#undef DEF_FUNCTION_TYPE_7
+#undef DEF_FUNCTION_TYPE_8
 #undef DEF_FUNCTION_TYPE_VAR_0
 #undef DEF_FUNCTION_TYPE_VAR_1
 #undef DEF_FUNCTION_TYPE_VAR_2
diff --git gcc/builtin-types.def gcc/builtin-types.def
index fba9c7d..f09c335 100644
--- gcc/builtin-types.def
+++ gcc/builtin-types.def
@@ -29,13 +29,7 @@ along with GCC; see the file COPYING3.  If not see
DEF_FUNCTION_TYPE_0 (ENUM, RETURN)
DEF_FUNCTION_TYPE_1 (ENUM, RETURN, ARG1)
DEF_FUNCTION_TYPE_2 (ENUM, RETURN, ARG1, ARG2)
-   DEF_FUNCTION_TYPE_3 (ENUM, RETURN, ARG1, ARG2, ARG3)
-   DEF_FUNCTION_TYPE_4 (ENUM, RETURN, ARG1, ARG2, ARG3, ARG4)
-   DEF_FUNCTION_TYPE_5 (ENUM, RETURN, ARG1, ARG2, ARG3, ARG4, ARG5)
-   DEF_FUNCTION_TYPE_6 (ENUM, RETURN, ARG1, 

[COMMITTED] Remove unused, and sort prototypes.

[Thomas Schwinge]

From: tschwinge 

gcc/c-family/
* c-common.h (c_omp_sharing_predetermined, c_omp_remap_decl):
Remove prototypes.
(record_types_used_by_current_var_decl): Move prototype to where
it belongs.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@210823 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/c-family/ChangeLog  | 5 +
 gcc/c-family/c-common.h | 6 +-
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git gcc/c-family/ChangeLog gcc/c-family/ChangeLog
index 5e3e541..675a66e 100644
--- gcc/c-family/ChangeLog
+++ gcc/c-family/ChangeLog
@@ -1,5 +1,10 @@
 2014-05-22  Thomas Schwinge  
 
+   * c-common.h (c_omp_sharing_predetermined, c_omp_remap_decl):
+   Remove prototypes.
+   (record_types_used_by_current_var_decl): Move prototype to where
+   it belongs.
+
* c-common.c (DEF_FUNCTION_TYPE_0, DEF_FUNCTION_TYPE_6)
(DEF_FUNCTION_TYPE_7, DEF_FUNCTION_TYPE_8)
(DEF_FUNCTION_TYPE_VAR_5): Cosmetic fixes.
diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index edd43b6..0d34004 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -1000,6 +1000,7 @@ extern void warn_for_sign_compare (location_t,
 extern void do_warn_double_promotion (tree, tree, tree, const char *, 
  location_t);
 extern void set_underlying_type (tree);
+extern void record_types_used_by_current_var_decl (tree);
 extern void record_locally_defined_typedef (tree);
 extern void maybe_record_typedef_use (tree);
 extern void maybe_warn_unused_local_typedefs (void);
@@ -1208,11 +1209,6 @@ extern tree c_omp_declare_simd_clauses_to_numbers (tree, 
tree);
 extern void c_omp_declare_simd_clauses_to_decls (tree, tree);
 extern enum omp_clause_default_kind c_omp_predetermined_sharing (tree);
 
-/* Not in c-omp.c; provided by the front end.  */
-extern bool c_omp_sharing_predetermined (tree);
-extern tree c_omp_remap_decl (tree, bool);
-extern void record_types_used_by_current_var_decl (tree);
-
 /* Return next tree in the chain for chain_next walking of tree nodes.  */
 static inline tree
 c_tree_chain_next (tree t)
-- 
1.9.1

[patch i386]: Sibcall tail-call improvement and partial fix PR/60104

[Kai Tietz]

Hi,

This patch adds a small improvement about sibling tail-calls.  We producing 
without that patch an useless load of address into register.
See for this the testcases sibcall-1.c, and sibcall-3.c.  The testcase 
sibcall-3.c is just an demonstration about other missed opportunities for 
sibcall tail-calls and I added it to the testcases for completion.  I test here 
just 32-bit to make testcases simple.  Nevertheless all those tests apply in 
general to 64-bit, too.

This patch addresses partial the general issue shown in PR 60104.  I will sent 
with follow-up patches for it.

ChangeLog

2014-05-22  Kai Tietz  

PR target/60104
* config/i386/i386-protos.h (x86_sibcall_memory_p): New prototype.
* config/i386/i386.md (!SIBLING_CALL_P): Add alternative check
for x86_sibcall_memory_p.
* config/i386/i386.c (x86_sibcall_memory_p): New function.
(x86_sibcall_memory_p_1): New helper function.
(x86_output_mi_thunk): Allow memory if x86_sibcall_memory_p is true.

2014-05-22  Kai Tietz  

PR target/60104
* gcc.target/i386/sibcall-1.c: New test.
* gcc.target/i386/sibcall-2.c: New test.
* gcc.target/i386/sibcall-3.c: New test.


Regression-tested for x86_64-unknown-linux-gnu (multilib), x86_64-w64-mingw32, 
and i686-pc-cygwin.  Ok for apply?

Index: gcc/config/i386/i386-protos.h
===
--- gcc/config/i386/i386-protos.h   (revision 210716)
+++ gcc/config/i386/i386-protos.h   (working copy)
@@ -303,6 +303,7 @@ extern enum attr_cpu ix86_schedule;
 #endif
 
 extern const char * ix86_output_call_insn (rtx insn, rtx call_op);
+extern bool x86_sibcall_memory_p (rtx insn);
 
 #ifdef RTX_CODE
 /* Target data for multipass lookahead scheduling.
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 210716)
+++ gcc/config/i386/i386.c  (working copy)
@@ -38752,6 +38752,69 @@ x86_can_output_mi_thunk (const_tree thunk ATTRIBUT
   return true;
 }
 
+/* Helper routine of x86_sibcall_memory_p.
+
+   RFLAGS is used to prevent to recurse on PLUS, and MULT expressions.  */
+
+static bool
+x86_sibcall_memory_p_1 (rtx op, int rflags)
+{
+  switch (GET_CODE (op))
+{
+case SYMBOL_REF:
+  return true;
+case MULT:
+  if (rflags & 2)
+   return false;
+
+  rflags |= 2; /* Mark to prevent recursion on MULT.  */
+
+  if (x86_sibcall_memory_p_1 (XEXP (op, 0), rflags)
+ && x86_sibcall_memory_p_1 (XEXP (op, 1), rflags))
+   return true;
+  break;
+case PLUS:
+  if (rflags & 1)
+   return false;
+
+  rflags |= 1; /* Makr to prevent recursion on PLUS.  */
+
+  if (x86_sibcall_memory_p_1 (XEXP (op, 0), rflags)
+ && x86_sibcall_memory_p_1 (XEXP (op, 1), rflags))
+   return true;
+  break;
+default:
+  if (REG_P (op))
+   {
+ op = GET_CODE (op) == SUBREG ? SUBREG_REG (op) : op;
+ return REGNO (op) == AX_REG;
+   }
+  else if (CONSTANT_P (op))
+   return true;
+  break;
+}
+
+  return false;
+}
+
+/* Function returns TRUE if operand OP is an memory based on a
+   symbol-reference or based on accumulator-register.
+   Otherwise it returns FALSE.  */
+
+bool
+x86_sibcall_memory_p (rtx op)
+{
+  if (!MEM_P (op))
+return false;
+
+  op = XEXP (op, 0);
+
+  if (GET_CODE (op) == CONST)
+op = XEXP (op, 0);
+
+  return x86_sibcall_memory_p_1 (op, 0);
+}
+
 /* Output the assembler code for a thunk function.  THUNK_DECL is the
declaration for the thunk function itself, FUNCTION is the decl for
the target function.  DELTA is an immediate constant offset to be
@@ -38891,7 +38954,16 @@ x86_output_mi_thunk (FILE *file,
  For our purposes here, we can get away with (ab)using a jump pattern,
  because we're going to do no optimization.  */
   if (MEM_P (fnaddr))
-emit_jump_insn (gen_indirect_jump (fnaddr));
+{
+  if (x86_sibcall_memory_p (fnaddr))
+   {
+ tmp = gen_rtx_CALL (VOIDmode, fnaddr, const0_rtx);
+  tmp = emit_call_insn (tmp);
+  SIBLING_CALL_P (tmp) = 1;
+   }
+  else
+   emit_jump_insn (gen_indirect_jump (fnaddr));
+}
   else
 {
   if (ix86_cmodel == CM_LARGE_PIC && SYMBOLIC_CONST (fnaddr))
Index: gcc/config/i386/i386.md
===
--- gcc/config/i386/i386.md (revision 210716)
+++ gcc/config/i386/i386.md (working copy)
@@ -11362,7 +11362,7 @@
 (define_insn "*call"
   [(call (mem:QI (match_operand:W 0 "call_insn_operand" "zw"))
 (match_operand 1))]
-  "!SIBLING_CALL_P (insn)"
+  "!SIBLING_CALL_P (insn) || x86_sibcall_memory_p (operands[0])"
   "* return ix86_output_call_insn (insn, operands[0]);"
   [(set_attr "type" "call")])
 
@@ -11371,7 +11371,7 @@
 [(call (mem:QI (match_operand:DI 0 "call_insn_operand" "rzw"))
   (

another patch for PR60969

[Vladimir Makarov]

  The following patch fixes a GCC testsuite test failure on aarch64
after committing the 1st patch for PR60969.

  The patch was bootstrapped and tested on x86/x86-64.

  Committed as rev. 210825 for gcc-4.9 branch and rev. 210824 for trunk.

2014-05-22  Vladimir Makarov  

PR rtl-optimization/60969
* ira-costs.c (record_reg_classes): Process NO_REGS for matching
constraints.  Set up mem cost for NO_REGS case.

Index: ira-costs.c
===
--- ira-costs.c	(revision 210728)
+++ ira-costs.c	(working copy)
@@ -407,6 +407,8 @@ record_reg_classes (int n_alts, int n_op
   int alt;
   int i, j, k;
   int insn_allows_mem[MAX_RECOG_OPERANDS];
+  move_table *move_in_cost, *move_out_cost;
+  short (*mem_cost)[2];
 
   for (i = 0; i < n_ops; i++)
 insn_allows_mem[i] = 0;
@@ -517,41 +519,78 @@ record_reg_classes (int n_alts, int n_op
 		  bool in_p = recog_data.operand_type[i] != OP_OUT;
 		  bool out_p = recog_data.operand_type[i] != OP_IN;
 		  enum reg_class op_class = classes[i];
-		  move_table *move_in_cost, *move_out_cost;
 
 		  ira_init_register_move_cost_if_necessary (mode);
 		  if (! in_p)
 		{
 		  ira_assert (out_p);
-		  move_out_cost = ira_may_move_out_cost[mode];
-		  for (k = cost_classes_ptr->num - 1; k >= 0; k--)
+		  if (op_class == NO_REGS)
 			{
-			  rclass = cost_classes[k];
-			  pp_costs[k]
-			= move_out_cost[op_class][rclass] * frequency;
+			  mem_cost = ira_memory_move_cost[mode];
+			  for (k = cost_classes_ptr->num - 1; k >= 0; k--)
+			{
+			  rclass = cost_classes[k];
+			  pp_costs[k] = mem_cost[rclass][0] * frequency;
+			}
+			}
+		  else
+			{
+			  move_out_cost = ira_may_move_out_cost[mode];
+			  for (k = cost_classes_ptr->num - 1; k >= 0; k--)
+			{
+			  rclass = cost_classes[k];
+			  pp_costs[k]
+= move_out_cost[op_class][rclass] * frequency;
+			}
 			}
 		}
 		  else if (! out_p)
 		{
 		  ira_assert (in_p);
-		  move_in_cost = ira_may_move_in_cost[mode];
-		  for (k = cost_classes_ptr->num - 1; k >= 0; k--)
+		  if (op_class == NO_REGS)
 			{
-			  rclass = cost_classes[k];
-			  pp_costs[k]
-			= move_in_cost[rclass][op_class] * frequency;
+			  mem_cost = ira_memory_move_cost[mode];
+			  for (k = cost_classes_ptr->num - 1; k >= 0; k--)
+			{
+			  rclass = cost_classes[k];
+			  pp_costs[k] = mem_cost[rclass][1] * frequency;
+			}
+			}
+		  else
+			{
+			  move_in_cost = ira_may_move_in_cost[mode];
+			  for (k = cost_classes_ptr->num - 1; k >= 0; k--)
+			{
+			  rclass = cost_classes[k];
+			  pp_costs[k]
+= move_in_cost[rclass][op_class] * frequency;
+			}
 			}
 		}
 		  else
 		{
-		  move_in_cost = ira_may_move_in_cost[mode];
-		  move_out_cost = ira_may_move_out_cost[mode];
-		  for (k = cost_classes_ptr->num - 1; k >= 0; k--)
-			{
-			  rclass = cost_classes[k];
-			  pp_costs[k] = ((move_in_cost[rclass][op_class]
-	  + move_out_cost[op_class][rclass])
-	 * frequency);
+		  if (op_class == NO_REGS)
+			{
+			  mem_cost = ira_memory_move_cost[mode];
+			  for (k = cost_classes_ptr->num - 1; k >= 0; k--)
+			{
+			  rclass = cost_classes[k];
+			  pp_costs[k] = ((mem_cost[rclass][0]
+	  + mem_cost[rclass][1])
+	 * frequency);
+			}
+			}
+		  else
+			{
+			  move_in_cost = ira_may_move_in_cost[mode];
+			  move_out_cost = ira_may_move_out_cost[mode];
+			  for (k = cost_classes_ptr->num - 1; k >= 0; k--)
+			{
+			  rclass = cost_classes[k];
+			  pp_costs[k] = ((move_in_cost[rclass][op_class]
+	  + move_out_cost[op_class][rclass])
+	 * frequency);
+			}
 			}
 		}
 
@@ -783,8 +822,6 @@ record_reg_classes (int n_alts, int n_op
 		  bool in_p = recog_data.operand_type[i] != OP_OUT;
 		  bool out_p = recog_data.operand_type[i] != OP_IN;
 		  enum reg_class op_class = classes[i];
-		  move_table *move_in_cost, *move_out_cost;
-		  short (*mem_cost)[2];
 
 		  ira_init_register_move_cost_if_necessary (mode);
 		  if (! in_p)
@@ -860,10 +897,15 @@ record_reg_classes (int n_alts, int n_op
 			}
 		}
 
-		  /* If the alternative actually allows memory, make
-		 things a bit cheaper since we won't need an extra
-		 insn to load it.  */
-		  if (op_class != NO_REGS)
+		  if (op_class == NO_REGS)
+		/* Although we don't need insn to reload from
+		   memory, still accessing memory is usually more
+		   expensive than a register.  */
+		pp->mem_cost = frequency;
+		  else
+		/* If the alternative actually allows memory, make
+		   things a bit cheaper since we won't need an
+		   extra insn to load it.  */
 		pp->mem_cost
 		  = ((out_p ? ira_memory_move_cost[mode][op_class][0] : 0)
 			 + (in_p ? ira_memory_move_cost[mode][op_class][1] : 0)

Re: Breakage with [PATCH, libgfortran] PR60324 Handle arbitrarily long path names

[Janne Blomqvist]

On Thu, May 22, 2014 at 6:36 PM, Hans-Peter Nilsson  wrote:
> On Mon, 19 May 2014, Janne Blomqvist wrote:
>> Hello,
>>
>> some systems such as GNU Hurd, don't define PATH_MAX at all, and on
>> some other systems many syscalls apparently work for paths longer than
>> PATH_MAX. Thus GFortran shouldn't truncate paths to PATH_MAX
>> characters, but rather use heap allocated buffers limited only by the
>> available memory. The attached patch implements this, with the
>> exception of the backtrace functionality where we cannot use malloc
>> since backtrace might be called from a signal handler.
>>
>> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>>
>> 2014-05-19  Janne Blomqvist  
>>
>> PR libfortran/60324
>> * config.h.in: Regenerated.
>> * configure: Regenerated.
>> * configure.ac (AC_CHECK_FUNCS_ONCE): Check for strnlen and
>> strndup.
>> * libgfortran.h (fc_strdup): New prototype.
>> * runtime/string.c (strnlen): New fallback function.
>> (strndup): New fallback function.
>> (fc_strdup): New function.
>> * io/close.c (st_close): Use fc_strdup.
>> * io/open.c (new_unit): Likewise.
>> (already_open): Likewise.
>> * io/unit.c (filename_from_unit): Likewise.
>> * io/unix.c (unpack_filename): Remove function.
>> (regular_file): Rename to regular_file2, add path argument.
>> (regular_file): New function calling regular_file2.
>> (compare_file_filename): Use fc_strdup.
>> (find_file): Likewise.
>> (delete_file): Likewise.
>> (file_exists): Likewise.
>> (file_size): Likewise.
>> (inquire_sequential): Likewise.
>> (inquire_direct): Likewise.
>> (inquire_formatted): Likewise.
>> (inquire_access): Likewise.
>> * io/unix.h (unpack_filename): Remove prototype.
>> * runtime/main.c (please_free_exe_path_when_done): Change type to
>> bool.
>> (store_exe_path): Use malloced buffer, grow as needed.
>
> This patch broke build for newlib targets; you need AC_DEFINE
> clauses for those in the "if-then"-leg where you patched the
> "else"-leg.

Do I? The patch does include fallback implementations for strnlen and
strndup in case the target doesn't supply them. I don't know whether
newlib does, or if current versions do have it but old still in use
versions don't etc. I suggest that whoever was insisting on this
stupid hard-coded func list for newlib takes care of figuring that out
and, if it turns out that all relevant newlib versions do supply one
or both of those functions, posts a patch.

Or hmm, is there some symbol name conflict, in case we try to use a
fallback implementation but the target already defines it?

> There's also a need for #include  for the
> malloc use in runtime/string.c.

This, OTOH, is clearly a bug. Committed the obvious bugfix as r210827,
thanks for reporting. (Annoying that glibc apparently defines malloc
via some other includes as well so I didn't notice it.)



-- 
Janne Blomqvist

Re: [Patch] Avoid gcc_assert in libgcov

[Rong Xu]

I think these asserts will be used by gcov-tool. So I prefer to change
them to  gcov_nonruntime_assert(). I'll merge them in my new gcov-tool
patch before submitting (waiting for honaz's ok).

Thanks,

-Rong

On Thu, May 22, 2014 at 7:09 AM, Teresa Johnson  wrote:
> On Thu, Jan 16, 2014 at 2:41 PM, Jan Hubicka  wrote:
>>> On Wed, Jan 15, 2014 at 8:39 PM, Jan Hubicka  wrote:
>>> >>
>>> >> In that case should we call gcov_error when IN_LIBGCOV? One
>>> >> possibility would be to simply make gcov_nonruntime_assert be defined
>>> >> as if (!EXPR) gcov_error in the IN_LIBGCOV case. But I think what you
>>> >> wanted here was to reduce libgcov bloat by removing calls altogether,
>>> >> which this wouldn't solve. But if we want to call gcov_error in some
>>> >> cases, I think I need to add another macro that will either do
>>> >> gcc_assert when !IN_LIBGCOV and "if (!EXPR) gcov_error" when
>>> >> IN_LIBGCOV. Is that what you had in mind?
>>> >
>>> > I think for errors that can be triggered by data corruption, we ought to
>>> > produce resonable error messages in both IN_LIBGCOV or for offline tools.
>>> > Just unwound sequence if(...) gcov_error seems fine to me in this case,
>>> > but we may also have assert like wrapper.
>>> > I see we do not provide gcov_error outside libgcov, we probably ought to 
>>> > map
>>> > it to fatal_error in GCC binary.
>>> >
>>> > thanks,
>>> > Honza
>>>
>>> Ok, here is the new patch. Bootstrapped and tested on
>>> x86_64-unknown-linux-gnu. Ok for trunk?
>>>
>>> Thanks, Teresa
>>>
>>> 2014-01-16  Teresa Johnson  
>>>
>>> * gcov-io.c (gcov_position): Use gcov_nonruntime_assert.
>>> (gcov_is_error): Remove gcc_assert from IN_LIBGCOV code.
>>> (gcov_rewrite): Use gcov_nonruntime_assert.
>>> (gcov_open): Ditto.
>>> (gcov_write_words): Ditto.
>>> (gcov_write_length): Ditto.
>>> (gcov_read_words): Use gcov_nonruntime_assert, and remove
>>> gcc_assert from IN_LIBGCOV code.
>>> (gcov_read_summary): Use gcov_error to flag profile corruption.
>>> (gcov_sync): Use gcov_nonruntime_assert.
>>> (gcov_seek): Remove gcc_assert from IN_LIBGCOV code.
>>> (gcov_histo_index): Use gcov_nonruntime_assert.
>>> (static void gcov_histogram_merge): Ditto.
>>> (compute_working_sets): Ditto.
>>> * gcov-io.h (gcov_nonruntime_assert): Define.
>>> (gcov_error): Define for !IN_LIBGCOV
>>
>> OK, thanks!
>> Honza
>
> I just found this old patch sitting in a client! Committed as r210805.
>
> I also discovered that a couple uses of gcc_assert have snuck into
> libgcc/libgcov* files in the meantime. Looks like this got added
> during some of Rong's refactoring, cc'ing Rong. They are in
> libgcc/libgcov-driver-system.c (allocate_filename_struct) and
> libgcov-merge.c (__gcov_merge_single and __gcov_merge_delta). Should I
> remove those or change to gcov_error?
>
> Teresa
>
>
>
> --
> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

Re: [PATCH][MIPS] Implement O32 FPXX ABI (GCC)

[Richard Sandiford]

Matthew Fortune  writes:
>> Let's step back a bit.  Please explain which case you were trying to
>> handle with the specs patch.  Rejecting -msingle-float -mfp64 seems
>> fine.
>> Fiddling with the specs to stop that combination reaching the assembler
>> is what seemed odd.
>
> So, perhaps this is a 'vendor' issue too like some other debates we have
> had in this area. I presume the --with arguments are intended to
> be used to configure a single purpose toolchain that targets a specific
> ABI. So if used to construct a single-float toolchain then --with-fp=64
> would not be used. And if configured using --with-fp=64 then it is OK to
> have an error if using -msingle-float.

Yeah, it sounds like it could be a vendor issue.  IMO there are two useful
ways that a configuration can handle --with: (a) build the same multilibs
regardless of the --with option but let the --with option control the
default; or (b) deselect any multilibs that are incompatible with the
--with option.  The simple configurations like mips64*-linux-gnu and
mips64-elf do (a), but for configurations that usually have lots of
multilibs I can imagine it would make sense to do (b).  Obviously your
call for your toolchains (as long as we can avoid the ASM_SPEC magic).

> I am actually considering implications of adding support for MIPS64r6
> to GCC which I have not posted yet, sorry :-).

I don't think you're making anyone suffer from an undersupply of patches. :-)

> MIPSr6 only supports 64-bit registers which naturally leads to needing
> -mfp64. MIPSr6 does however also support a single-precision only variant.
>
> For a single purpose native toolchain then --with-fp=64 can be used xor
> --with-fpu=single to get the desired tools.

Hmm, does that really mean that an FPU that only implements S/W-format
instructions must still have 64-bit registers?  And are MTHC1 and MFHC1
therefore always supported for single-float-only FPUs?  The r6 documentation
I downloaded made it sound like 32-bit FPUs were still allowed for
S/W-only FPUs but that 64-bit FPUs are required if D/L-format
instructions are supported.

Or is this more a single-precision+MSA thing?

(Can't really respond to the later specs stuff without understanding
this part first.)

>> >> >> > diff --git a/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
>> >> >> b/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
>> >> >> > new file mode 100644
>> >> >> > index 000..f47cdda
>> >> >> > --- /dev/null
>> >> >> > +++ b/gcc/testsuite/gcc.target/mips/call-clobbered-2.c
>> >> >> > @@ -0,0 +1,21 @@
>> >> >> > +/* Check that we handle call-clobbered FPRs correctly.  */
>> >> >> > +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" } { "" }
>> } */
>> >> >> > +/* { dg-options "-mabi=32 -modd-spreg -mfp32 -ffixed-f0 -
>> ffixed-f1 -
>> >> >> ffixed-f2 -ffixed-f3 -ffixed-f4 -ffixed-f5 -ffixed-f6 -ffixed-f7 -
>> >> ffixed-f8
>> >> >> -ffixed-f9 -ffixed-f10 -ffixed-f11 -ffixed-f12 -ffixed-f13 -
>> ffixed-f14 -
>> >> >> ffixed-f15 -ffixed-f16 -ffixed-f17 -ffixed-f18 -ffixed-f19 -
>> ffixed-f20 -
>> >> >> ffixed-f22 -ffixed-f24 -ffixed-f26 -ffixed-f28 -ffixed-f30" } */
>> >> >> > +
>> >> >> > +void bar (void);
>> >> >> > +float a;
>> >> >> > +float
>> >> >> > +foo ()
>> >> >> > +{
>> >> >> > +  float b = a + 1.0f;
>> >> >> > +  bar();
>> >> >> > +  return b;
>> >> >> > +}
>> >> >> > +/* { dg-final { scan-assembler-times "lwc1" 2 } } */
>> >> >> > +/* { dg-final { scan-assembler-not "swc1" } } */
>> >> >> > +/* { dg-final { scan-assembler-times "sdc1" 2 } } */
>> >> >> > +/* { dg-final { scan-assembler-not "mtc" } } */
>> >> >> > +/* { dg-final { scan-assembler-not "mfc" } } */
>> >> >> > +/* { dg-final { scan-assembler-not "mthc" } } */
>> >> >> > +/* { dg-final { scan-assembler-not "mfhc" } } */
>> >> >>
>> >> >> Why require sdc1 here?  Would Chao-Ying's patch make this use SWC1
>> and
>> >> LWC1
>> >> >> exclusively?
>> >> >
>> >> > The SDC1 instructions are for callee-saved registers. I'll add the
>> >> > check for two corresponding LDC1 instructions in the epilogue
>> though
>> >> > since I've noticed them being missing.
>> >>
>> >> I'm probably being dense, sorry, but why is SDC1 needed for -mfp32
>> >> -modd-spreg?  Can't we just save and restore the odd register?
>> >> That's technically more correct too, since we shouldn't really touch
>> >> -ffixed registers.
>> >
>> > You are correct and I am/was aware of this...
>> >
>> > GCC is saving too much of the callee-saved registers when single-
>> precision
>> > values are live in them but this is historic behaviour. The code which
>> > controls this is very complex and I'd be worried about breaking it.
>> The
>> > fix would be invasive as all the logic is honed towards the notion of
>> > 64-bit callee-saved registers.
>> 
>> But that's because it was written before separate odd spregs came along.
>> I'm not convinced the situation is as bad as you say.
>>
>> > One thing to say is that this test is
>> > a very aggressive test of ABI not normal c

[patch i386]: Expand sibling-tail-calls via accumulator register

[Kai Tietz]

Hello,

This patch avoids for sibling-tail-calls the use of pseudo-register.  Instead 
it uses for load of memory-address the accumulator-register.  By this we avoid 
that IRA/LRA need to choose a register.  So we reduce register-pressure.

The accumulator-register is always a valid register on tail-call case.  All 
other registers might be callee-saved, or used for argument-passing.  The only 
case where we would use the accumulator on call is the variadic-case for x86_64 
ABI.  Just that this function never is a candidate for sibling-tail-calls.

ChangeLog

2014-05-22  Kai Tietz  

* config/i386/i386.c (ix86_expand_call): Enforce for sibcalls
on memory the use of accumulator-register.

Regression tested for x86_64-unknown-linux-gnu, x86_64-w64-mingw32, and 
i686-pc-cygwin.
Ok for apply?

Regards,
Kai

Index: i386.c
===
--- i386.c  (Revision 210412)
+++ i386.c  (Arbeitskopie)
@@ -24898,8 +24898,19 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx call
   ? !sibcall_insn_operand (XEXP (fnaddr, 0), word_mode)
   : !call_insn_operand (XEXP (fnaddr, 0), word_mode))
 {
+  rtx r;
   fnaddr = convert_to_mode (word_mode, XEXP (fnaddr, 0), 1);
-  fnaddr = gen_rtx_MEM (QImode, copy_to_mode_reg (word_mode, fnaddr));
+  if (!sibcall)
+   r = copy_to_mode_reg (word_mode, fnaddr);
+  else
+   {
+ r = gen_rtx_REG (word_mode, AX_REG);
+ if (! general_operand (fnaddr, VOIDmode))
+   fnaddr = force_operand (fnaddr, r);
+ if (fnaddr != r)
+   emit_move_insn (r, fnaddr);
+   }
+  fnaddr = gen_rtx_MEM (QImode, r);
 }
 
   call = gen_rtx_CALL (VOIDmode, fnaddr, callarg1);

[PATCH] Disable unroll loop that has header count less than iteration count.

[Dehao Chen]

If a loop's header count is less than iteration count, the iteration
estimation is apparently incorrect for this loop. Thus disable
unrolling of such loops.

Testing on going. OK for trunk if test pass?

Thanks,
Dehao

gcc/ChangeLog:
2014-05-21  Dehao Chen  

* cfgloop.h (expected_loop_iterations_reliable_p): New func.
* cfgloopanal.c (expected_loop_iterations_reliable_p): Likewise.
* loop-unroll.c (decide_unroll_runtime_iterations): Disable unroll
loop that has unreliable iteration counts.

Index: gcc/cfgloop.h
===
--- gcc/cfgloop.h (revision 210717)
+++ gcc/cfgloop.h (working copy)
@@ -307,8 +307,8 @@ extern bool just_once_each_iteration_p (const stru
 gcov_type expected_loop_iterations_unbounded (const struct loop *);
 extern unsigned expected_loop_iterations (const struct loop *);
 extern rtx doloop_condition_get (rtx);
+extern bool expected_loop_iterations_reliable_p (const struct loop *);

-
 /* Loop manipulation.  */
 extern bool can_duplicate_loop_p (const struct loop *loop);

Index: gcc/cfgloopanal.c
===
--- gcc/cfgloopanal.c (revision 210717)
+++ gcc/cfgloopanal.c (working copy)
@@ -285,6 +285,15 @@ expected_loop_iterations (const struct loop *loop)
   return (expected > REG_BR_PROB_BASE ? REG_BR_PROB_BASE : expected);
 }

+/* Returns true if the loop header's profile count is smaller than expected
+   loop iteration.  */
+
+bool
+expected_loop_iterations_reliable_p (const struct loop *loop)
+{
+  return expected_loop_iterations (loop) < loop->header->count;
+}
+
 /* Returns the maximum level of nesting of subloops of LOOP.  */

 unsigned
Index: gcc/loop-unroll.c
===
--- gcc/loop-unroll.c (revision 210717)
+++ gcc/loop-unroll.c (working copy)
@@ -988,6 +988,15 @@ decide_unroll_runtime_iterations (struct loop *loo
   return;
 }

+  if (profile_status_for_fn (cfun) == PROFILE_READ
+  && expected_loop_iterations_reliable_p (loop))
+{
+  if (dump_file)
+ fprintf (dump_file, ";; Not unrolling loop, loop iteration "
+ "not reliable.");
+  return;
+}
+
   /* Check whether the loop rolls.  */
   if ((get_estimated_loop_iterations (loop, &iterations)
|| get_max_loop_iterations (loop, &iterations))

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

[H.J. Lu]

On Thu, May 22, 2014 at 2:33 PM, Kai Tietz  wrote:
> Hello,
>
> This patch avoids for sibling-tail-calls the use of pseudo-register.  Instead 
> it uses for load of memory-address the accumulator-register.  By this we 
> avoid that IRA/LRA need to choose a register.  So we reduce register-pressure.
>
> The accumulator-register is always a valid register on tail-call case.  All 
> other registers might be callee-saved, or used for argument-passing.  The 
> only case where we would use the accumulator on call is the variadic-case for 
> x86_64 ABI.  Just that this function never is a candidate for 
> sibling-tail-calls.
>
> ChangeLog
>
> 2014-05-22  Kai Tietz  
>
> * config/i386/i386.c (ix86_expand_call): Enforce for sibcalls
> on memory the use of accumulator-register.
>
> Regression tested for x86_64-unknown-linux-gnu, x86_64-w64-mingw32, and 
> i686-pc-cygwin.
> Ok for apply?
>
> Regards,
> Kai
>
> Index: i386.c
> ===
> --- i386.c  (Revision 210412)
> +++ i386.c  (Arbeitskopie)
> @@ -24898,8 +24898,19 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx call
>? !sibcall_insn_operand (XEXP (fnaddr, 0), word_mode)
>: !call_insn_operand (XEXP (fnaddr, 0), word_mode))
>  {
> +  rtx r;
>fnaddr = convert_to_mode (word_mode, XEXP (fnaddr, 0), 1);
> -  fnaddr = gen_rtx_MEM (QImode, copy_to_mode_reg (word_mode, fnaddr));
> +  if (!sibcall)
> +   r = copy_to_mode_reg (word_mode, fnaddr);
> +  else
> +   {
> + r = gen_rtx_REG (word_mode, AX_REG)

If fnaddr points to a function with variable argument list in
64-bit, AX_REG may be used to store number of FP arguments
passed in registers.

> + if (! general_operand (fnaddr, VOIDmode))
> +   fnaddr = force_operand (fnaddr, r);
> + if (fnaddr != r)
> +   emit_move_insn (r, fnaddr);
> +   }
> +  fnaddr = gen_rtx_MEM (QImode, r);
>  }
>
>call = gen_rtx_CALL (VOIDmode, fnaddr, callarg1);



-- 
H.J.

Re: [PATCH][MIPS] Implement O32 FPXX ABI (GCC)

[Maciej W. Rozycki]

On Thu, 22 May 2014, Richard Sandiford wrote:

> I can't hope to match Maciej's reply on the details, but like he says,
> my understanding was that this:
> 
> > ADD.D $f20, $f10, $f10
> > MOV.D $f18, $f20
> > SWC1 $f20, 0($sp)
> > MTC1 $2, $f20
> > LWC1 $f20, 0($sp)
> > ADD.D $f16, $f18, $f20
> > ($f16 should be 4*$f10)
> 
> really is required to work for -modd-spreg.  Specifically I thought the
> LWC1 would force $f20 to be become "uninterpreted" and then the ADD.D
> would need to (re)interpret the register pair as D-format.

 But as I wrote it has always worked, even with the MIPS I R2010 FPU.  All 
the CP1 transfer instructions are non-arithmetic and operate on FPRs in 
the raw manner (note that MOV.S and MOV.D do not fall in this class).  And 
they actually have to, or otherwise a sequence like this (typical for a 
MIPS I function epilogue):

lwc1$f20,0(sp)
# <- hw interrupt taken here
lwc1$f21,4(sp)
jr  ra
 addiu  sp,sp,8

would break on a system with a proper OS such as Linux if a hardware 
interrupt exception was taken right after the first LWC1 that would cause 
a context switch and the other process also switched (lazily) the FP 
context.  Once back to this process, the second LWC1 would fault with a 
Coprocessor Unusable exception that would pull the whole FP context back.  
Once that has completed the LWC1 instruction would only replace one half 
of the double value stored in $f20 (note that the FP context switch 
handler may well use LDC1 instructions if supported by hardware; Linux 
does where possible).

 Yes, it happens that we restore even-numbered FPRs first, before their 
odd-numbered counterparts each, but neither the ABI nor hardware mandates 
that, we could as well swap the order and that would have to work too.

  Maciej