Re: [C PATCH] Diagnose predefined identifiers in pedantic mode

[Marek Polacek]

On Tue, Aug 12, 2014 at 08:17:15AM +0200, Dodji Seketeli wrote:
> Marek Polacek  a écrit:
> 
> 
> > diff --git gcc/testsuite/gcc.dg/concat.c gcc/testsuite/gcc.dg/concat.c
> > index 0b9d6f6..e3bfd46 100644
> > --- gcc/testsuite/gcc.dg/concat.c
> > +++ gcc/testsuite/gcc.dg/concat.c
> > @@ -1,6 +1,7 @@
> >  /* Copyright (C) 2001 Free Software Foundation, Inc.  */
> >  
> >  /* { dg-do compile } */
> > +/* { dg-options "" } */
> 
> Just for my own education, why this change?
> 
> > diff --git gcc/testsuite/gcc.dg/pr22458-1.c gcc/testsuite/gcc.dg/pr22458-1.c
> > index 8b8032c..023fb21 100644
> > --- gcc/testsuite/gcc.dg/pr22458-1.c
> > +++ gcc/testsuite/gcc.dg/pr22458-1.c
> > @@ -1,4 +1,6 @@
> >  /* { dg-error "expected declaration or statement" "" { target *-*-* } 0 } 
> > */
> > +/* { dg-options "" } */
> > +
> 
> Likewise.
> 
> > diff --git gcc/testsuite/gcc.dg/pr33676.c gcc/testsuite/gcc.dg/pr33676.c
> > index 79c830e..c234470 100644
> > --- gcc/testsuite/gcc.dg/pr33676.c
> > +++ gcc/testsuite/gcc.dg/pr33676.c
> > @@ -1,4 +1,5 @@
> >  /* { dg-do run } */
> > +/* { dg-options "" } */
> >  /* { dg-options "-O0 -mtune=i386 -fomit-frame-pointer" { target { { 
> > i?86-*-* x86_64-*-* } && ia32 } } } */
> 
> Likewise.

Thise testcases use predefined identifiers, and without the
dg-options, they would compile with -ansi -pedantic-errors and fail.
Setting dg-options to "" makes the -ansi -pedantic-errors go away.
Setting it to e.g. -std=gnu99 would work as well.

Marek

Re: [PATCH, i386] Remove use of vpmacsdql instruction from multiplication.

[Uros Bizjak]

On Tue, Aug 12, 2014 at 7:23 AM, Gopalasubramanian, Ganesh
 wrote:

>> > +2014-06-10  Ganesh Gopalasubramanian
>> > +
>> > +
>> > +   * config/i386/i386.c (ix86_expand_sse2_mulvxdi3): Issue
>> > +instructions "vpmuludq" and "vpaddq" instead of "vpmacsdql" for
>> > +handling 32-bit multiplication.
>> >
>
>> OK for mainline and release branches.
>
> I would like to backport the above patch for 4.9. Is it OK?

OK. It is a correctness issue.

Uros.

Re: [C PATCH] Diagnose predefined identifiers in pedantic mode

[Dodji Seketeli]

Marek Polacek  a écrit:


> diff --git gcc/testsuite/gcc.dg/concat.c gcc/testsuite/gcc.dg/concat.c
> index 0b9d6f6..e3bfd46 100644
> --- gcc/testsuite/gcc.dg/concat.c
> +++ gcc/testsuite/gcc.dg/concat.c
> @@ -1,6 +1,7 @@
>  /* Copyright (C) 2001 Free Software Foundation, Inc.  */
>  
>  /* { dg-do compile } */
> +/* { dg-options "" } */

Just for my own education, why this change?

> diff --git gcc/testsuite/gcc.dg/pr22458-1.c gcc/testsuite/gcc.dg/pr22458-1.c
> index 8b8032c..023fb21 100644
> --- gcc/testsuite/gcc.dg/pr22458-1.c
> +++ gcc/testsuite/gcc.dg/pr22458-1.c
> @@ -1,4 +1,6 @@
>  /* { dg-error "expected declaration or statement" "" { target *-*-* } 0 } */
> +/* { dg-options "" } */
> +

Likewise.

> diff --git gcc/testsuite/gcc.dg/pr33676.c gcc/testsuite/gcc.dg/pr33676.c
> index 79c830e..c234470 100644
> --- gcc/testsuite/gcc.dg/pr33676.c
> +++ gcc/testsuite/gcc.dg/pr33676.c
> @@ -1,4 +1,5 @@
>  /* { dg-do run } */
> +/* { dg-options "" } */
>  /* { dg-options "-O0 -mtune=i386 -fomit-frame-pointer" { target { { i?86-*-* 
> x86_64-*-* } && ia32 } } } */

Likewise.

Cheers.

-- 
Dodji

Re: [GSoC] the separate option for all dimensions

[Roman Gareev]

> Checking for this specific AST may cause failures with future versions of
> isl that choose a different schedule. Could you write a regular expression
> that checks that there is no if-condition contained in a for loop? I think
> this best models the issue that was addressed in the original bug report.

I’ve implemented this in the attached patch. Is it fine for trunk?

-- 
Cheers, Roman Gareev.
2014-08-12  Roman Gareev  

[gcc/testsuite]

* gcc.dg/graphite/pr35356-2.c: Update according to the ISL code
generator.
Index: gcc/testsuite/gcc.dg/graphite/pr35356-2.c
===
--- gcc/testsuite/gcc.dg/graphite/pr35356-2.c   (revision 213773)
+++ gcc/testsuite/gcc.dg/graphite/pr35356-2.c   (working copy)
@@ -1,4 +1,4 @@
-/* { dg-options "-O2 -fgraphite-identity -fdump-tree-graphite-all" } */
+/* { dg-options "-O2 -fgraphite-identity -fdump-tree-graphite-all  
-fgraphite-code-generator=isl" } */
 
 int a[100];
 
@@ -38,7 +38,5 @@
 
 */
 
-
-/* { dg-final { scan-tree-dump-times "MIN_EXPR\[^\\n\\r]*;" 4 "graphite" } } */
-/* { dg-final { scan-tree-dump-times "MAX_EXPR\[^\\n\\r]*;" 4 "graphite" } } */
+/* { dg-final { scan-tree-dump-times "for\[^\n\]+\n\[^\n\]+if" 0 "graphite" } 
} */
 /* { dg-final { cleanup-tree-dump "graphite" } } */

Re: [PATCH, ARM] Keep constants in register when expanding

[Zhenqiang Chen]

On 11 August 2014 19:14, Ramana Radhakrishnan  wrote:
> On Mon, Aug 11, 2014 at 3:35 AM, Zhenqiang Chen
>  wrote:
>> On 8 August 2014 23:22, Ramana Radhakrishnan  
>> wrote:
>>> On Tue, Aug 5, 2014 at 10:31 AM, Zhenqiang Chen
>>>  wrote:
 Hi,

 For some large constants, ARM will split them during expanding, which
 makes impossible to hoist them out the loop or shared by different
 references (refer the test case in the patch).

 The patch keeps some constants in registers. If the constant can not
 be optimized, the cprop and combine passes can optimize them as what
 we do in current expand pass with

 define_insn_and_split "*arm_subsi3_insn"
 define_insn_and_split "*arm_andsi3_insn"
 define_insn_and_split "*iorsi3_insn"
 define_insn_and_split "*arm_xorsi3"

 The patch does not modify addsi3 since the define_insn_and_split
 "*arm_addsi3" is only valid when (reload_completed ||
 !arm_eliminable_register (operands[1])). The cprop and combine passes
 can not optimize the large constant if we put it in register, which
 will lead to regression.

 For logic operators, the patch skips changes for constants:

 INTVAL (operands[2]) < 0 && const_ok_for_arm (-INTVAL (operands[2])

 since expand pass always uses "sign-extend" to get the value
 (trunc_int_for_mode called from immed_wide_int_const) for rtl, and
 logs show most negative values are UNSIGNED when they are TREE node.
 And combine pass is smart enough to recover the negative value to
 positive value.
>>>
>>> I am unable to verify any change in code generation for this testcase
>>> with and without the patch when I had a play with the patch.
>>>
>>> what gives ?
>>
>> Thanks for trying the patch.
>>
>> Do you add option -fno-gcse which is mentioned in dg-options " -O2
>> -fno-gcse "? Without it, there is no change for the testcase since
>> cprop pass will propagate the constant to AND expr (A patch to enhance
>> cprop pass was discussed at
>> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01321.html).
>
> Probably not and I can now see the difference in code generated for
> Thumb state. Why is it that in ARM state with -mcpu=cortex-a15 we see
> the hoisting of the constant without your patch with -fno-gcse ?

The difference between ARM and THUMB2 modes are due to rtx_cost
difference. For ARM mode, the constant is force_reg in function
avoid_expensive_constant (obtabs.c) before gen_andsi3 when expanding.

> So, the patch improves code generation for -mcpu=cortex-a15 -mthumb
> -fno-gcse for the given testcase ?

Yes.

>>
>> In addition, if the constant can not be hoisted out the loop, later
>> combine pass can also optimize it. These (cprop and combine) are
>> reasons why the patch itself has little impact on current tests.
>
> Does this mean you need the referred to patch to be useful as a
> pre-requisite ? I fail to  understand why this patch needs to go in if
> it makes no difference without disabling GCSE. I cannot see -fno-gcse
> being used by default for performant code.

For some codes, -fno-gcse might get better performance. Please refer paper:

A case study: optimizing GCC on ARM for performance of libevas
rasterization library
http://ctuning.org/dissemination/grow10-03.pdf

The issues mentioned in the paper had been solved since
arm_split_constant is smart enough to handle the 0xff00ff. But what
for other irregular constant?

The patch gives a chance to handle them.

Thanks!
-Zhenqiang

> regards
> Ramana

RE: [PATCH, i386] Remove use of vpmacsdql instruction from multiplication.

[Gopalasubramanian, Ganesh]

Hi Uros!

> > +2014-06-10  Ganesh Gopalasubramanian 
> > +
> > +
> > +   * config/i386/i386.c (ix86_expand_sse2_mulvxdi3): Issue 
> > +instructions "vpmuludq" and "vpaddq" instead of "vpmacsdql" for 
> > +handling 32-bit multiplication.
> >

> OK for mainline and release branches.

I would like to backport the above patch for 4.9. Is it OK?

Regards
Ganesh

Re: RFC: PATCH to allow passing non-trivial types through ...

[Nathan Sidwell]

On 08/11/14 14:02, Jason Merrill wrote:

A customer was recently complaining about G++ rejecting code that tries to pass
a type with a non-trivial copy constructor through ..., which is undefined in
C++98 and conditionally-supported in C++11.  In GCC 3.1 and below we gave a
warning and then did a bitwise copy.  From GCC 3.2 to 4.4 we gave a warning and
then aborted at runtime.  From 4.5 on we have just given an error.

On considering the request, it occurred to me that we could handle variadic
arguments of non-trivial types the same way we handle normal value arguments of
such types: pass by invisible reference.  So this patch implements that.  Since
it's been so long since this was allowed at all, I don't think we need to worry
about ABI incompatibility with the 3.1 behavior.

Thoughts?


Sounds sensible to me.

nathan
--
Nathan Sidwell

Re: [PATCH] gcc/c/c-aux-info.c: Resize 'buff' from 10 to 14 bytes

[Chen Gang]

On 8/12/14 7:38, Mike Stump wrote:
> On Aug 11, 2014, at 2:27 PM, Chen Gang  wrote:
>> Welcome additional disccusions or completions, and if no any additional
>> reply within 1 week, I shall send patch v2 for it (still use sprintf).
> 
> So, my take is it is easier for a maintainer to re-review if you do it 
> without additional delay.  I’d recommend addressing the review points and 
> posting without waiting a week in this case.  Waiting is useful if a review 
> point is contentious.
> 

OK, thanks. What you said sounds reasonable to me.

But excuse me, I have no enough time resource on it, and also, I am
still not quite familiar with building and checking (especially it needs
a long time to build and check which has negative effect for analyzing).

So, excuse me again, I have to need more time period on it. But I should
try send patch v2 for it within this week (2014-08-17).


And still welcome additional ideas, suggestions or completions.

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: PR tree-optimization/52904 testcase

[Kugan]

On 11/08/14 18:03, Richard Biener wrote:
> On Sat, Aug 9, 2014 at 2:33 PM, Kugan  
> wrote:
>> Hi,
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904
>>
>> Tescase was generating warning: assuming signed overflow does not occur
>> when simplifying conditional to constant [-Wstrict-overflow] due to VRP
>> missing the value range.
>>
>> This seems to have been fixed and the PR is now closed. However, as
>> requested there in the PR, I am sending this patch to add the test-case
>> to test-suite.
>>
>>
>> Is this OK ?
> 
> Did you verify the testcase fails before the revision that fixed it?
> Esp. the placement of the dg-bogus looks bogus to me.

I tried it on Linaro 4.9 (It should be the same in fsf gcc 4.9 branch)
and the test cases is failing there. Passes on trunk.

In any case, I have moved it to the top and reverified. I have also
trimmed the warning pattern to check as there was some changes there
from 4.9 to trunk.

> 
> Also don't use -S in dg-options, use lower-case filenames and
> avoid spurious vertical white-space.  The VRP dump scan is
> also very unspecific - I suggest to drop it entirely.
> 

Done.


Is this OK?


Thanks,
Kugan

gcc/testsuite
2014-08-12  Kugan Vivekanandarajah  

PR tree-optimization/52904
* gcc.dg/pr52904.c: New test.



> Thanks,
> Richard.
> 
>> Thanks,
>> Kugan
>>
>> gcc/testsuite
>>
>>
>> 2014-08-09  Kugan Vivekanandarajah  
>>
>> PR tree-optimization/52904
>> * gcc.dg/PR52904.c: New test.
diff --git a/gcc/testsuite/gcc.dg/pr52904.c b/gcc/testsuite/gcc.dg/pr52904.c
index e69de29..7c04187 100644
--- a/gcc/testsuite/gcc.dg/pr52904.c
+++ b/gcc/testsuite/gcc.dg/pr52904.c
@@ -0,0 +1,24 @@
+
+/* { dg-do compile } */
+/* { dg-options "-Wstrict-overflow -O2" } */
+/* { dg-bogus "assuming signed overflow does not occur when simplifying" */
+
+extern int foo (int);
+
+int
+wait_reading_process_output (void)
+{
+  int nfds = 0;
+  int channel;
+  for (channel = 0; channel < 1024; ++channel)
+{
+  if (foo (channel))
+   nfds++;
+}
+
+  if (nfds < 0)
+return 1;
+
+  return 0;
+}
+

[PING v2][Patch]Fix ICE for gcc.dg/noncompile/920507-1.c

[Tony Wang]

Ping 2, and pasted my observation about this ICE, and may someone can help?

The main cause for the ICE is in the function symtab_get_node:

  gcc_checking_assert (TREE_CODE (decl) == FUNCTION_DECL
   || (TREE_CODE (decl) == VAR_DECL
   && (TREE_STATIC (decl) || DECL_EXTERNAL (decl)
   || in_lto_p)));

It's a check for the tree attribute for VAR_DECL, but as the register type 
variable is neither static nor
external(not sure if this is correct), the compiler will raise ICE here, but in 
function
make_decl_rtl(gcc/varasm.c:1357), there's one line comment:

globalize_reg (decl, reg_number + --nregs);
}

  /* As a register variable, it has no section.  */
  return;
}

And for the correct register type declaration like: register int *a asm("r1"), 
the program will just directly
return(gcc/varasm.c:1358), and won't sink into the symbol ref generation part. 
So symtab_get_node won't be
called.

Currently invalid register type declaration will always sink into the symbol 
ref generation part of function
make_decl_rtl, which will also lead to wrong rtx generation.
register int *a asm("r1")=>(reg:SI 1 r1 [orig:0 a] [0])
register int *a asm("unknown register")=>(symbol_ref:SI ("unknown register") 
[flag 0x80])

Also the reason that x86 wont't have sunch an ICE is in the code:

if (use_object_blocks_p () && use_blocks_for_decl_p (decl))
x = create_block_symbol (name, get_block_for_decl (decl), -1);

function use_object_blocks_p will always return false on target doesn't support 
section anchor, so function
get_block_for_decl which will call symtab_get_node will never be called.

This patch just move the else condition in  make_decl_rtl to make all register 
type declaration to get the
same rtx, it this a reasonable fix?

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On 
> Behalf Of Tony Wang
> Sent: Tuesday, August 05, 2014 9:35 AM
> To: gcc-patches@gcc.gnu.org
> Cc: 'Richard Biener'; 'Jakub Jelinek'
> Subject: [PING][Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
> 
> Ping, any comment and suggestion on this bug fix?
> 
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Tony Wang
> > Sent: Tuesday, July 29, 2014 10:31 AM
> > To: gcc-patches@gcc.gnu.org; 'Richard Biener'; 'Jakub Jelinek'
> > Subject: [Patch]Fix ICE for gcc.dg/noncompile/920507-1.c
> >
> > Hi there,
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61330.
> > There will be an ICE in gcc trunk for targets support section anchor
> > optimization when compiling this case(like arm and mips). This looks like
> an
> 
> The target should be aarch64, arm, powerpc, alpha
> 
> > old bug which is exposed by recent patch.
> >
> > In make_decl_rtl, when you declare register type incorrectly like
> "register int
> > *a asm("unknown register");", the compiler will raise an error messge but
> > doesn't return directly. It will continue to run into the rtx generation
> code for
> > general variable declaration and generate a wrong rtx:(symbol_ref:SI...).
> So I
> > just remove the else condition which used to be the rtx generation part
> for
> > correctly declared register type, and let all the register type
> declaration(no
> > matter it declared correct or not) go through it and generate the same
> type
> > of rtx:(reg:SI...).
> >
> > gcc/ChangeLog:
> >
> > 2014-07-29  Tony Wang  tony.w...@arm.com
> >
> > * gcc/varasm.c (make_decl_rtl): Remove the else condition
> >   for properly declared static register variables.
> >
> > diff --git a/gcc/varasm.c b/gcc/varasm.c index 819ec26..a6fae0c 100644
> > --- a/gcc/varasm.c
> > +++ b/gcc/varasm.c
> > @@ -1333,45 +1333,42 @@ make_decl_rtl (tree decl)
> >error ("register specified for %q+D isn%'t suitable for
> data type",
> > decl);
> >/* Now handle properly declared static register variables.  */
> > -  else
> > -  {
> > -int nregs;
> > +  int nregs;
> >
> > -if (DECL_INITIAL (decl) != 0 && TREE_STATIC (decl))
> > -  {
> > -DECL_INITIAL (decl) = 0;
> > -error ("global register variable has initial value");
> > -  }
> > -if (TREE_THIS_VOLATILE (decl))
> > -  warning (OPT_Wvolatile_register_var,
> > -   "optimization may eliminate reads 
> > and/or"
> > -   "writes to register variables");
> > +  if (DECL_INITIAL (decl) != 0 && TREE_STATIC (decl))
> > +{
> > +   DECL_INITIAL (decl) = 0;
> > +   error ("global register variable has initial value");
> > +}
> > +  if (TREE_THIS_VOLATILE (decl))
> > +warning (OPT_Wvolatile_register_var,
> > +   

Re: [testsuite patch] add __ARM_ARCH check for arm_v8_neon_ok

[Mike Stump]

On Aug 11, 2014, at 3:01 PM, Janis Johnson  wrote:
> The check for effective target arm_v8_neon_ok passes even if __ARM_ARCH
> is not 8 or greater, but then some tests fail because intrinsic functions
> used in the test have not been declared.  This patch requires that
> __ARM_ARCH be 8 or greater.  Tested for arm-none-linux-gnu for mainline
> and 4.9 with a variety of multilib flags.
> 
> OK for mainline and the 4.9 branch?

Ok.

[patch,gomp4] make fortran loop variables implicitly private in openacc

[Cesar Philippidis]

According to section 2.6.1 in the openacc spec, fortran loop variables
should be implicitly private like in openmp. This patch does just so.
Also, while working on this patch, I noticed that I made the check for
variables appearing in multiple openacc clauses too strict. A private
variable may also appear inside a reduction clause. I've also included a
fix for this in this patch.

Is this OK for gomp-4_0-branch?

Thanks,
Cesar
2014-08-11  Cesar Philippidis  

	gcc/fortran/
	* openmp.c (oacc_compatible_clauses): New function.
	(resolve_omp_clauses): Use it.
	(oacc_current_ctx): Move it near omp_current_ctx.
	(gfc_resolve_do_iterator): Handle OpenACC index variables.
	(gfc_resolve_oacc_blocks): Initialize ctx.share_clauses and
	ctx.private_iterators.

	gcc/testsuite/
	* gfortran.dg/goacc/private-1.f95: New test.


diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 91e00c4..2c91597 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -2713,6 +2713,29 @@ resolve_omp_udr_clause (gfc_omp_namelist *n, gfc_namespace *ns,
   return copy;
 }
 
+/* Returns true if clause in list 'list' is compatible with any of
+   of the clauses in lists [0..list-1].  E.g., a reduction variable may
+   appear in both reduction and private clauses, so this function
+   will return true in this case.  */
+
+static bool
+oacc_compatible_clauses (gfc_omp_clauses *clauses, int list,
+			   gfc_symbol *sym, bool openacc)
+{
+  gfc_omp_namelist *n;
+
+  if (!openacc)
+return false;
+
+  if (list != OMP_LIST_REDUCTION)
+return false;
+
+  for (n = clauses->lists[OMP_LIST_PRIVATE]; n; n = n->next)
+if (n->sym == sym)
+  return true;
+
+  return false;
+}
 
 /* OpenMP directive resolving routines.  */
 
@@ -2826,7 +2849,8 @@ resolve_omp_clauses (gfc_code *code, locus *where,
 	&& list != OMP_LIST_TO)
   for (n = omp_clauses->lists[list]; n; n = n->next)
 	{
-	  if (n->sym->mark)
+	  if (n->sym->mark && !oacc_compatible_clauses (omp_clauses, list,
+			n->sym, openacc))
 	gfc_error ("Symbol '%s' present on multiple clauses at %L",
 		   n->sym->name, where);
 	  else
@@ -3791,6 +3815,9 @@ struct omp_context
 static gfc_code *omp_current_do_code;
 static int omp_current_do_collapse;
 
+typedef struct omp_context oacc_context;
+oacc_context *oacc_current_ctx;
+
 void
 gfc_resolve_omp_do_blocks (gfc_code *code, gfc_namespace *ns)
 {
@@ -3906,6 +3933,8 @@ gfc_resolve_do_iterator (gfc_code *code, gfc_symbol *sym)
 {
   int i = omp_current_do_collapse;
   gfc_code *c = omp_current_do_code;
+  bool openacc = omp_current_ctx == NULL;
+  omp_context *current_ctx = openacc ? oacc_current_ctx : omp_current_ctx;
 
   if (sym->attr.threadprivate)
 return;
@@ -3922,15 +3951,15 @@ gfc_resolve_do_iterator (gfc_code *code, gfc_symbol *sym)
   c = c->block->next;
 }
 
-  if (omp_current_ctx == NULL)
+  if (current_ctx == NULL)
 return;
 
-  if (pointer_set_contains (omp_current_ctx->sharing_clauses, sym))
+  if (!openacc && pointer_set_contains (current_ctx->sharing_clauses, sym))
 return;
 
-  if (! pointer_set_insert (omp_current_ctx->private_iterators, sym))
+  if (! pointer_set_insert (current_ctx->private_iterators, sym))
 {
-  gfc_omp_clauses *omp_clauses = omp_current_ctx->code->ext.omp_clauses;
+  gfc_omp_clauses *omp_clauses = current_ctx->code->ext.omp_clauses;
   gfc_omp_namelist *p;
 
   p = gfc_get_omp_namelist ();
@@ -4106,9 +4135,6 @@ resolve_omp_do (gfc_code *code)
 }
 }
 
-typedef struct omp_context oacc_context;
-oacc_context *oacc_current_ctx;
-
 static bool
 oacc_is_parallel (gfc_code *code)
 {
@@ -4424,6 +4450,8 @@ gfc_resolve_oacc_blocks (gfc_code *code, gfc_namespace *ns)
   resolve_oacc_loop_blocks (code);
 
   ctx.code = code;
+  ctx.sharing_clauses = NULL;
+  ctx.private_iterators = pointer_set_create ();
   ctx.previous = oacc_current_ctx;
   oacc_current_ctx = &ctx;
 
diff --git a/gcc/testsuite/gfortran.dg/goacc/private-1.f95 b/gcc/testsuite/gfortran.dg/goacc/private-1.f95
new file mode 100644
index 000..4eaec4f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/private-1.f95
@@ -0,0 +1,39 @@
+! { dg-do compile } 
+! { dg-additional-options "-fdump-tree-omplower" } 
+
+! test for implicit private clauses in do loops
+
+program test
+  implicit none
+  integer :: i, j, k
+  logical :: l
+
+  !$acc parallel
+  !$acc loop
+  do i = 1, 100
+  end do
+  !$acc end parallel
+
+  !$acc parallel
+  !$acc loop
+  do i = 1, 100
+ do j = 1, 100
+ end do
+  end do
+  !$acc end parallel
+
+  !$acc parallel
+  !$acc loop
+  do i = 1, 100
+ do j = 1, 100
+do k = 1, 100
+end do
+ end do
+  end do
+  !$acc end parallel
+end program test
+! { dg-prune-output "unimplemented" }
+! { dg-final { scan-tree-dump-times "pragma acc parallel" 3 "omplower" } } 
+! { dg-final { scan-tree-dump-times "private\\(i\\)" 3 "omplower" } } 
+! { dg-final { scan-tree-dump-times "private\\(j\\)" 2 "omplower" } } 
+! { dg-final { scan-tree-d

Fwd: [testsuite patch] fix ARM tests with options that conflict with thumb1

[Mike Stump]

[ dup, sorry ]

On Aug 11, 2014, at 2:58 PM, Janis Johnson  wrote:
> Two tests in gcc.target/arm add options that conflict with thumb1
> multilib flags; skip them.  Tested with arm-none-linux-gnu for mainline
> and 4.9 for a variety of multilib flags.
> 
> OK for mainline and 4.9 branch?

So, my take is you can self-review things like this if you would like.  Doesn’t 
look controversial and likely you understand the issues better than most.

Ok.

Nit, if you discover a way to figure out incompatible options, it would be 
nicer to use it.  The usual gcc rules are, last option wins, which generally 
precludes noticing conflicting options.  I only mention this here, in case 
people want to contemplate conflicting options.

Re: [testsuite patch] don't add ARM options for a thumb1 multilib

[Mike Stump]

On Aug 11, 2014, at 3:00 PM, Janis Johnson  wrote:
> Test gcc.dg/pr59418.c adds ARM-specific options for an ARM target, but
> those options conflict with flags for a thumb1 multilib.  Don't add
> the extra ARM flags for a thumb1 multilib.  Tested with arm-none-linux-gnu
> for mainline and 4.9 with a variety of multilib flags.
> 
> OK for mainline and the 4.9 branch?

Ok.

Re: [testsuite patch] fix ARM tests with options that conflict with thumb1

[Mike Stump]

On Aug 11, 2014, at 2:58 PM, Janis Johnson  wrote:
> Two tests in gcc.target/arm add options that conflict with thumb1
> multilib flags; skip them.  Tested with arm-none-linux-gnu for mainline
> and 4.9 for a variety of multilib flags.
> 
> OK for mainline and 4.9 branch?

So, my take is you can self-review things like this if you would like.  Doesn’t 
look controversial and likely you understand the issues better than most.

Ok.

Nit, if you discover a way to figure out incompatible options, it would be 
nicer to use it.  The usual gcc rules are, last option wins, which generally 
precludes noticing conflicting options.  I only mention this here, in case 
people want to contemplate conflicting options.

Re: [testsuite patch] skip an ARM run test if not using neon hardware

[Mike Stump]

On Aug 11, 2014, at 2:59 PM, Janis Johnson  wrote:
> Test gcc.target/arm/neon-vext-execute.c checks that the compiler can
> generate neon instructions, but it should also check that the test will
> be run using hardware that supports neon, which this patch adds.
> Tested with arm-none-linux-gnu for mainline and 4.9 with a variety of
> multilib flags.
> 
> OK for mainline and the 4.9 branch?

Ok.

Re: [PATCH] gcc/c/c-aux-info.c: Resize 'buff' from 10 to 14 bytes

[Mike Stump]

On Aug 11, 2014, at 2:27 PM, Chen Gang  wrote:
> Welcome additional disccusions or completions, and if no any additional
> reply within 1 week, I shall send patch v2 for it (still use sprintf).

So, my take is it is easier for a maintainer to re-review if you do it without 
additional delay.  I’d recommend addressing the review points and posting 
without waiting a week in this case.  Waiting is useful if a review point is 
contentious.

Re: RFC: PATCH to allow passing non-trivial types through ...

[Mike Stump]

On Aug 11, 2014, at 2:02 PM, Jason Merrill  wrote:
> 
> On considering the request, it occurred to me that we could handle variadic 
> arguments of non-trivial types the same way we handle normal value arguments 
> of such types: pass by invisible reference.  So this patch implements that.  
> Since it's been so long since this was allowed at all, I don't think we need 
> to worry about ABI incompatibility with the 3.1 behavior.

So, it would be nice if the C++ abi document defined how to pass them.  Once it 
says do it this way, then all people have to do it that way if they want to 
claim conformance to that doc, and when all do, we then get C++ abi 
compatibility across compilers (which is nice).  If they want to dictate some 
other convention, then it sure would be nice to know _before_ we ship an abi 
incompatible version.  I’m thinking compatibility with clang for example would 
be nice.  Also, would be nice if the standard mandated it just work, though, 
that might take another standard to get it in there.

[GSoC][match-and-simplify] Add abs_expr pattern

[Prathamesh Kulkarni]

Add pattern: abs (abs (x)) -> abs (x)

* match.pd: Add new pattern.

[gcc/testsuite/gcc.dg/tree-ssa]
* match.c: New test-case.

Thanks,
Prathamesh
Index: gcc/match.pd
===
--- gcc/match.pd	(revision 213814)
+++ gcc/match.pd	(working copy)
@@ -101,6 +101,12 @@ along with GCC; see the file COPYING3.
   (fma INTEGER_CST_P@0 INTEGER_CST_P@1 @3)
   (plus (mult @0 @1) @3))
 
+/* abs (abs (x)) -> abs (x) */
+(simplify
+  (abs (abs @0))
+  (abs @0))
+
+
 #include "match-plusminus.pd"
 #include "match-bitwise.pd"
 #include "match-rotate.pd"
Index: gcc/testsuite/gcc.dg/tree-ssa/match.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/match.c	(revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/match.c	(working copy)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-forwprop1-details" }  */
+
+int abs(int);
+
+int match_1 (int x)
+{
+  int t1 = abs (x);
+  int match_1_val = abs (t1);
+  return match_1_val;
+}  
+/* { dg-final { scan-tree-dump "gimple_simplified to match_1_val_\\d\+ = ABS_EXPR 

Re: [PATCH] Drop user_defined_section_attribute, directly check DECL_SECTION_NAME instead

[Yi Yang]

Sorry, it is a typo :(

Patch v2:

--

2014-08-11  Yi Yang  

gcc:
* bb-reorder.c (pass_partition_blocks::gate): Replace check.
* c-family/c-common.c (handle_section_attribute): Remove
user_defined_section_attribute
* final.c (rest_of_handle_final): ditto
* toplev.c (user_defined_section_attribute): ditto
* toplev.h (user_defined_section_attribute): ditto

diff --git gcc/bb-reorder.c gcc/bb-reorder.c
index 96547c2..7b74887 100644
--- gcc/bb-reorder.c
+++ gcc/bb-reorder.c
@@ -95,7 +95,6 @@
 #include "expr.h"
 #include "params.h"
 #include "diagnostic-core.h"
-#include "toplev.h" /* user_defined_section_attribute */
 #include "tree-pass.h"
 #include "df.h"
 #include "bb-reorder.h"
@@ -2671,11 +2670,9 @@ pass_partition_blocks::gate (function *fun)
  arises.  */
   return (flag_reorder_blocks_and_partition
   && optimize
-  /* See gate_handle_reorder_blocks.  We should not partition if
- we are going to omit the reordering.  */
   && optimize_function_for_speed_p (fun)
   && !DECL_COMDAT_GROUP (current_function_decl)
-  && !user_defined_section_attribute);
+  && !DECL_SECTION_NAME (current_function_decl));
 }

 unsigned
diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index acc9a20..967ae2b 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -7395,8 +7395,6 @@ handle_section_attribute (tree *node, tree
ARG_UNUSED (name), tree args,

   if (targetm_common.have_named_sections)
 {
-  user_defined_section_attribute = true;
-
   if ((TREE_CODE (decl) == FUNCTION_DECL
|| TREE_CODE (decl) == VAR_DECL)
   && TREE_CODE (TREE_VALUE (args)) == STRING_CST)
diff --git gcc/final.c gcc/final.c
index 304ae2a..3fee226 100644
--- gcc/final.c
+++ gcc/final.c
@@ -4460,8 +4460,6 @@ rest_of_handle_final (void)

   assemble_end_function (current_function_decl, fnname);

-  user_defined_section_attribute = false;
-
   /* Free up reg info memory.  */
   free_reg_info ();

diff --git gcc/toplev.c gcc/toplev.c
index 88d48c2..07d5e05 100644
--- gcc/toplev.c
+++ gcc/toplev.c
@@ -152,11 +152,6 @@ HOST_WIDE_INT random_seed;
the support provided depends on the backend.  */
 rtx stack_limit_rtx;

-/* True if the user has tagged the function with the 'section'
-   attribute.  */
-
-bool user_defined_section_attribute = false;
-
 struct target_flag_state default_target_flag_state;
 #if SWITCHABLE_TARGET
 struct target_flag_state *this_target_flag_state = &default_target_flag_state;
diff --git gcc/toplev.h gcc/toplev.h
index 1b54578..b0d0ca4 100644
--- gcc/toplev.h
+++ gcc/toplev.h
@@ -53,11 +53,6 @@ extern void target_reinit (void);
 /* A unique local time stamp, might be zero if none is available.  */
 extern unsigned local_tick;

-/* True if the user has tagged the function with the 'section'
-   attribute.  */
-
-extern bool user_defined_section_attribute;
-
 /* See toplev.c.  */
 extern int flag_rerun_cse_after_global_opts;

-- 

On Mon, Aug 11, 2014 at 1:46 PM, H.J. Lu  wrote:
> On Mon, Aug 11, 2014 at 1:41 PM, Yi Yang  wrote:
>> Replace checking user_defined_section_attribute with directly checking
>> DECL_SECTION_NAME. The former does not work in the presence of IPA.
>>
>> See also: discussion on the same patch in Google branch:
>> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00749.html
>>
>> --
>>
>> 2014-08-11  Yi Yang  
>>
>> gcc:
>> * bb-reorder.c (pass_partition_blocks::gate): Replace check.
>> * c-family/c-common.c (handle_section_attribute): Remove
>> user_defined_section_attribute
>> * final.c (rest_of_handle_final): ditto
>> * toplev.c (user_defined_section_attribute): ditto
>> * toplev.h (user_defined_section_attribute): ditto
>>
>> diff --git gcc/bb-reorder.c gcc/bb-reorder.c
>> index 96547c2..747831c 100644
>> --- gcc/bb-reorder.c
>> +++ gcc/bb-reorder.c
>> @@ -95,7 +95,6 @@
>>  #include "expr.h"
>>  #include "params.h"
>>  #include "diagnostic-core.h"
>> -#include "toplev.h" /* user_defined_section_attribute */
>>  #include "tree-pass.h"
>>  #include "df.h"
>>  #include "bb-reorder.h"
>> @@ -2671,11 +2670,9 @@ pass_partition_blocks::gate (function *fun)
>>   arises.  */
>>return (flag_reorder_blocks_and_partition
>>&& optimize
>> -  /* See gate_handle_reorder_blocks.  We should not partition if
>> - we are going to omit the reordering.  */
>>&& optimize_function_for_speed_p (fun)
>> -  && !DECL_COMDAT_GROUP (current_function_decl)
>> -  && !user_defined_section_attribute);
>> +  && !DECL_COMDAT_GROUP (current_function_decl);
>
>  ^^^ Is this extra ';' a typo?
>
>> +  && !DECL_SECTION_NAME (current_function_decl));
>>  }
>>
>
>
>
> --
> H.J.

[testsuite patch] add __ARM_ARCH check for arm_v8_neon_ok

[Janis Johnson]

The check for effective target arm_v8_neon_ok passes even if __ARM_ARCH
is not 8 or greater, but then some tests fail because intrinsic functions
used in the test have not been declared.  This patch requires that
__ARM_ARCH be 8 or greater.  Tested for arm-none-linux-gnu for mainline
and 4.9 with a variety of multilib flags.

OK for mainline and the 4.9 branch?

Janis
2014-08-11  Janis Johnson  

* lib/target/supports.exp
(check_effective_target_arm_v8_neon_ok_nocache): Check for armv8
or later.

Index: gcc/testsuite/lib/target-supports.exp
===
--- gcc/testsuite/lib/target-supports.exp   (revision 213831)
+++ gcc/testsuite/lib/target-supports.exp   (working copy)
@@ -2578,6 +2578,9 @@
 if { [check_effective_target_arm32] } {
foreach flags {"" "-mfloat-abi=softfp" "-mfpu=neon-fp-armv8" 
"-mfpu=neon-fp-armv8 -mfloat-abi=softfp"} {
if { [check_no_compiler_messages_nocache arm_v8_neon_ok object {
+   #if __ARM_ARCH < 8
+   #error not armv8 or later
+   #endif
#include "arm_neon.h"
void
foo ()

[testsuite patch] don't add ARM options for a thumb1 multilib

[Janis Johnson]

Test gcc.dg/pr59418.c adds ARM-specific options for an ARM target, but
those options conflict with flags for a thumb1 multilib.  Don't add
the extra ARM flags for a thumb1 multilib.  Tested with arm-none-linux-gnu
for mainline and 4.9 with a variety of multilib flags.

OK for mainline and the 4.9 branch?

Janis
2014-08-11  Janis Johnson  

* gcc.dg/pr59418.c: Don't add ARM options for a Thumb1 multilib.

Index: gcc/testsuite/gcc.dg/pr59418.c
===
--- gcc/testsuite/gcc.dg/pr59418.c  (revision 437379)
+++ gcc/testsuite/gcc.dg/pr59418.c  (working copy)
@@ -3,7 +3,7 @@
 
 /* { dg-do compile } */
 /* { dg-options "-Os -g" } */
-/* { dg-options "-march=armv7-a -mfloat-abi=hard -Os -g" { target arm*-*-* } } 
*/
+/* { dg-options "-march=armv7-a -mfloat-abi=hard -Os -g" { target { arm*-*-* 
&& { ! arm_thumb1 } } } } */
 
 extern int printf (const char *__format, ...);
 

[testsuite patch] skip an ARM run test if not using neon hardware

[Janis Johnson]

Test gcc.target/arm/neon-vext-execute.c checks that the compiler can
generate neon instructions, but it should also check that the test will
be run using hardware that supports neon, which this patch adds.
Tested with arm-none-linux-gnu for mainline and 4.9 with a variety of
multilib flags.

OK for mainline and the 4.9 branch?

Janis
2014-08-11  Janis Johnson  

* gcc.target/arm/neon-vext-execute.c: Skip if the test won't run
on Neon hardware.

Index: gcc/testsuite/gcc.target/arm/neon-vext-execute.c
===
--- gcc/testsuite/gcc.target/arm/neon-vext-execute.c(revision 437379)
+++ gcc/testsuite/gcc.target/arm/neon-vext-execute.c(working copy)
@@ -1,5 +1,6 @@
 /* { dg-do run } */
 /* { dg-require-effective-target arm_neon_ok } */
+/* { dg-require-effective-target arm_neon_hw } */
 /* { dg-require-effective-target arm_little_endian } */
 /* { dg-options "-O2" } */
 /* { dg-add-options arm_neon } */

[testsuite patch] fix ARM tests with options that conflict with thumb1

[Janis Johnson]

Two tests in gcc.target/arm add options that conflict with thumb1
multilib flags; skip them.  Tested with arm-none-linux-gnu for mainline
and 4.9 for a variety of multilib flags.

OK for mainline and 4.9 branch?

Janis
2014-08-11  Janis Johnson  

* gcc.target/arm/pr48784.c: Skip for thumb1 multilib.
* gcc.target/arm/pr59985.c: Likewise.

Index: gcc/testsuite/gcc.target/arm/pr58784.c
===
--- gcc/testsuite/gcc.target/arm/pr58784.c  (revision 437379)
+++ gcc/testsuite/gcc.target/arm/pr58784.c  (working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-skip-if "incompatible options" { arm_thumb1 } { "*" } { "" } } */
 /* { dg-options "-march=armv7-a -mfloat-abi=hard -mfpu=neon -marm -O2" } */
 
 typedef struct __attribute__ ((__packed__))
Index: gcc/testsuite/gcc.target/arm/pr59985.C
===
--- gcc/testsuite/gcc.target/arm/pr59985.C  (revision 437379)
+++ gcc/testsuite/gcc.target/arm/pr59985.C  (working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-skip-if "incompatible options" { arm_thumb1 } { "*" } { "" } } */
 /* { dg-options "-g -fcompare-debug -O2 -march=armv7-a -mtune=cortex-a9 
-mfpu=vfpv3-d16 -mfloat-abi=hard" } */
 
 extern void *f1 (unsigned long, unsigned long);

Re: [PATCH 1/3] gcc/ada/s-osinte-rtems.adb: Correct formatting of comment

[Joel Sherrill]

Thanks. This is committed.

I leaned toward obvious as well but figured I already had two
patches that needed a review, so why not. :)

On 8/11/2014 3:05 PM, Arnaud Charlet wrote:
>> This patch is needed to make Ada compile for *-*-rtems*
>> on GCC 4.8, 4.9, and the head. Is is ok to commit?
> Yes. This one even falls under the obvious category IMO.
>
>> 2014-08-11  Joel Sherrill 
>>
>>  * s-osinte-rtems.adb: Correct formatting of line in license block.

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH] gcc/c/c-aux-info.c: Resize 'buff' from 10 to 14 bytes

[Chen Gang]

On 08/12/2014 04:25 AM, Joseph S. Myers wrote:
> On Sun, 10 Aug 2014, Chen Gang wrote:
> 
>> For "[%d]" in sprintf(), theoretically, the maximize size is 14 -- for
>> 0x8000, it is sizeof("[-2147483648]"). Normally, it may not cause
>> real world bug, but if another issues occur, it may lead things worse.
> 
> Negative values certainly don't make sense here, although it may still 
> make sense to be robust against them.  If you get one, it probably means a 
> conversion from HOST_WIDE_INT to int has overflowed.
> 
> int_size_in_bytes returns HOST_WIDE_INT (64-bit).  I think the size 
> variable should be changed to HOST_WIDE_INT, buff expanded to be big 
> enough for any 64-bit value, and HOST_WIDE_INT_PRINT_DEC used in the 
> sprintf format.
> 

OK, thanks, what you said sounds reasonable to me.

> Separately, I think it's generally a good idea to convert sprintf uses in 
> GCC to snprintf - checking in each case that the size is such that 
> truncation shouldn't occur, but snprintf provides extra safety in case 
> there is some problem with the size calculation (although there may also 
> be a case for having an snprintf variant with an assertion that no 
> truncation occurs, so that the compiler safely aborts rather than either 
> continuing on truncation or overflowing a buffer).
> 

For me, if buffer is already enough, sprintf() is more obvious than
snprintf() which let readers know about it should have no truncation,
although what you said about snprintf() is true to me.

Welcome additional disccusions or completions, and if no any additional
reply within 1 week, I shall send patch v2 for it (still use sprintf).


Thanks.
-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [PATCH 3/3] gcc/ada/socket.c: Add conditionals for RTEMS

[Joel Sherrill]

On 8/11/2014 3:09 PM, Arnaud Charlet wrote:
>>> This patch is needed to make Ada compile for *-*-rtems*
>>> on GCC 4.8, 4.9, and the head. Is is ok to commit?
>> OK.
> Actually, these includes should go in gsocket.h, as done on other targets,
> which also answers your previous question.
Where do you want the include of unistd.h? It doesn't appear to be
included in
gsocket.h and none of the other areas specific to RTEMS make sense to
add it.

I think the best place is below this:

#if defined (__vxworks) && ! defined (__RTP__)
#include 
#else
#include 
#endif

And just move the conditional from socket.c with comment.
> Can you please repost an updated patch for review?
No problem.
> Arno

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

RFC: PATCH to allow passing non-trivial types through ...

[Jason Merrill]

A customer was recently complaining about G++ rejecting code that tries 
to pass a type with a non-trivial copy constructor through ..., which is 
undefined in C++98 and conditionally-supported in C++11.  In GCC 3.1 and 
below we gave a warning and then did a bitwise copy.  From GCC 3.2 to 
4.4 we gave a warning and then aborted at runtime.  From 4.5 on we have 
just given an error.


On considering the request, it occurred to me that we could handle 
variadic arguments of non-trivial types the same way we handle normal 
value arguments of such types: pass by invisible reference.  So this 
patch implements that.  Since it's been so long since this was allowed 
at all, I don't think we need to worry about ABI incompatibility with 
the 3.1 behavior.


Thoughts?
commit 68a0f48b2c82f157a04842e996fe340428fcfcc3
Author: Jason Merrill 
Date:   Fri Aug 8 17:23:14 2014 -0400

	* call.c (build_x_va_arg): Support passing non-POD through 
	(convert_arg_to_ellipsis): Likewise.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 56b3c5a..fbe92a9 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6570,8 +6570,8 @@ convert_arg_to_ellipsis (tree arg, tsubst_flags_t complain)
 	 with no corresponding parameter is conditionally-supported, with
 	 implementation-defined semantics.
 
-	 We used to just warn here and do a bitwise copy, but now
-	 cp_expr_size will abort if we try to do that.
+	 We support it as pass-by-invisible-reference, just like a normal
+	 value parameter.
 
 	 If the call appears in the context of a sizeof expression,
 	 it is not potentially-evaluated.  */
@@ -6579,10 +6579,12 @@ convert_arg_to_ellipsis (tree arg, tsubst_flags_t complain)
 	  && (type_has_nontrivial_copy_init (arg_type)
 	  || TYPE_HAS_NONTRIVIAL_DESTRUCTOR (arg_type)))
 	{
-	  if (complain & tf_error)
-	error_at (loc, "cannot pass objects of non-trivially-copyable "
-		  "type %q#T through %<...%>", arg_type);
-	  return error_mark_node;
+	  if (complain & tf_warning)
+	warning (OPT_Wconditionally_supported,
+		 "passing objects of non-trivially-copyable "
+		 "type %q#T through %<...%> is conditionally supported",
+		 arg_type);
+	  return cp_build_addr_expr (arg, complain);
 	}
 }
 
@@ -6595,7 +6597,11 @@ tree
 build_x_va_arg (source_location loc, tree expr, tree type)
 {
   if (processing_template_decl)
-return build_min (VA_ARG_EXPR, type, expr);
+{
+  tree r = build_min (VA_ARG_EXPR, type, expr);
+  SET_EXPR_LOCATION (r, loc);
+  return r;
+}
 
   type = complete_type_or_else (type, NULL_TREE);
 
@@ -6604,18 +6610,24 @@ build_x_va_arg (source_location loc, tree expr, tree type)
 
   expr = mark_lvalue_use (expr);
 
+  if (TREE_CODE (type) == REFERENCE_TYPE)
+{
+  error ("cannot receive reference type %qT through %<...%>", type);
+  return error_mark_node;
+}
+
   if (type_has_nontrivial_copy_init (type)
-  || TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type)
-  || TREE_CODE (type) == REFERENCE_TYPE)
+  || TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type))
 {
-  /* Remove reference types so we don't ICE later on.  */
-  tree type1 = non_reference (type);
-  /* conditionally-supported behavior [expr.call] 5.2.2/7.  */
-  error ("cannot receive objects of non-trivially-copyable type %q#T "
-	 "through %<...%>; ", type);
-  expr = convert (build_pointer_type (type1), null_node);
-  expr = cp_build_indirect_ref (expr, RO_NULL, tf_warning_or_error);
-  return expr;
+  /* conditionally-supported behavior [expr.call] 5.2.2/7.  Let's treat
+	 it as pass by invisible reference.  */
+  warning_at (loc, OPT_Wconditionally_supported,
+		 "receiving objects of non-trivially-copyable type %q#T "
+		 "through %<...%> is conditionally-supported", type);
+
+  tree ptr = build_pointer_type (type);
+  ptr = build_va_arg (loc, expr, ptr);
+  return cp_build_indirect_ref (ptr, RO_NULL, tf_warning_or_error);
 }
 
   return build_va_arg (loc, expr, type);
diff --git a/gcc/doc/implement-cxx.texi b/gcc/doc/implement-cxx.texi
index 50efcc3..5802311 100644
--- a/gcc/doc/implement-cxx.texi
+++ b/gcc/doc/implement-cxx.texi
@@ -42,7 +42,9 @@ all conditionally-supported constructs that it does not support (C++0x
 @cite{Whether an argument of class type with a non-trivial copy
 constructor or destructor can be passed to ... (C++0x 5.2.2).}
 
-Such argument passing is not supported.
+Such argument passing is supported, using the same
+pass-by-invisible-reference approach used for normal function
+arguments of such types.
 
 @end itemize
 
diff --git a/gcc/testsuite/g++.dg/ext/varargs1.C b/gcc/testsuite/g++.dg/ext/varargs1.C
new file mode 100644
index 000..b67d788
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/varargs1.C
@@ -0,0 +1,34 @@
+// Test that passing an object with non-trivial copy constructor and
+// destructor is (conditionally) supported and has sensible semantics.
+
+#include 
+extern "C" void abort();
+
+void *as[5];
+int 

Re: [PATCH] Drop user_defined_section_attribute, directly check DECL_SECTION_NAME instead

[H.J. Lu]

On Mon, Aug 11, 2014 at 1:41 PM, Yi Yang  wrote:
> Replace checking user_defined_section_attribute with directly checking
> DECL_SECTION_NAME. The former does not work in the presence of IPA.
>
> See also: discussion on the same patch in Google branch:
> https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00749.html
>
> --
>
> 2014-08-11  Yi Yang  
>
> gcc:
> * bb-reorder.c (pass_partition_blocks::gate): Replace check.
> * c-family/c-common.c (handle_section_attribute): Remove
> user_defined_section_attribute
> * final.c (rest_of_handle_final): ditto
> * toplev.c (user_defined_section_attribute): ditto
> * toplev.h (user_defined_section_attribute): ditto
>
> diff --git gcc/bb-reorder.c gcc/bb-reorder.c
> index 96547c2..747831c 100644
> --- gcc/bb-reorder.c
> +++ gcc/bb-reorder.c
> @@ -95,7 +95,6 @@
>  #include "expr.h"
>  #include "params.h"
>  #include "diagnostic-core.h"
> -#include "toplev.h" /* user_defined_section_attribute */
>  #include "tree-pass.h"
>  #include "df.h"
>  #include "bb-reorder.h"
> @@ -2671,11 +2670,9 @@ pass_partition_blocks::gate (function *fun)
>   arises.  */
>return (flag_reorder_blocks_and_partition
>&& optimize
> -  /* See gate_handle_reorder_blocks.  We should not partition if
> - we are going to omit the reordering.  */
>&& optimize_function_for_speed_p (fun)
> -  && !DECL_COMDAT_GROUP (current_function_decl)
> -  && !user_defined_section_attribute);
> +  && !DECL_COMDAT_GROUP (current_function_decl);

 ^^^ Is this extra ';' a typo?

> +  && !DECL_SECTION_NAME (current_function_decl));
>  }
>



-- 
H.J.

Re: [GOOGLE] Do not partition the cold/hot sections of a function with "section" attribute

[Yi Yang]

I ported this to trunk.

Shall I commit this patch to the Google 4_8/4_9 branches first?

On Mon, Aug 11, 2014 at 12:46 PM, Teresa Johnson  wrote:
> Ok, thanks. This seems reasonable. Can you send the patch to trunk as well?
> Teresa
>
> On Mon, Aug 11, 2014 at 12:35 PM, Yi Yang  wrote:
>> Patch v2
>>
>> ..
>>
>> diff --git gcc/bb-reorder.c gcc/bb-reorder.c
>> index fa6f62f..a1b3e65 100644
>> --- gcc/bb-reorder.c
>> +++ gcc/bb-reorder.c
>> @@ -95,7 +95,6 @@
>>  #include "expr.h"
>>  #include "params.h"
>>  #include "diagnostic-core.h"
>> -#include "toplev.h" /* user_defined_section_attribute */
>>  #include "tree-pass.h"
>>  #include "df.h"
>>  #include "bb-reorder.h"
>> @@ -2555,7 +2554,7 @@ gate_handle_partition_blocks (void)
>>   we are going to omit the reordering.  */
>>&& optimize_function_for_speed_p (cfun)
>>&& !DECL_ONE_ONLY (current_function_decl)
>> -  && !user_defined_section_attribute);
>> +  && !DECL_SECTION_NAME (current_function_decl));
>>  }
>>
>>  /* This function is the main 'entrance' for the optimization that
>> diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
>> index 65c25bf..9923928 100644
>> --- gcc/c-family/c-common.c
>> +++ gcc/c-family/c-common.c
>> @@ -7378,8 +7378,6 @@ handle_section_attribute (tree *node, tree
>> ARG_UNUSED (name), tree args,
>>
>>if (targetm_common.have_named_sections)
>>  {
>> -  user_defined_section_attribute = true;
>> -
>>if ((TREE_CODE (decl) == FUNCTION_DECL
>> || TREE_CODE (decl) == VAR_DECL)
>>&& TREE_CODE (TREE_VALUE (args)) == STRING_CST)
>> diff --git gcc/final.c gcc/final.c
>> index 9af0b2b..38c90b2 100644
>> --- gcc/final.c
>> +++ gcc/final.c
>> @@ -4501,8 +4501,6 @@ rest_of_handle_final (void)
>>
>>assemble_end_function (current_function_decl, fnname);
>>
>> -  user_defined_section_attribute = false;
>> -
>>/* Free up reg info memory.  */
>>free_reg_info ();
>>
>> diff --git gcc/toplev.c gcc/toplev.c
>> index 9b8d313..4c8c965 100644
>> --- gcc/toplev.c
>> +++ gcc/toplev.c
>> @@ -153,11 +153,6 @@ HOST_WIDE_INT random_seed;
>> the support provided depends on the backend.  */
>>  rtx stack_limit_rtx;
>>
>> -/* True if the user has tagged the function with the 'section'
>> -   attribute.  */
>> -
>> -bool user_defined_section_attribute = false;
>> -
>>  struct target_flag_state default_target_flag_state;
>>  #if SWITCHABLE_TARGET
>>  struct target_flag_state *this_target_flag_state = 
>> &default_target_flag_state;
>> diff --git gcc/toplev.h gcc/toplev.h
>> index 0290be3..65e38e7 100644
>> --- gcc/toplev.h
>> +++ gcc/toplev.h
>> @@ -53,11 +53,6 @@ extern void target_reinit (void);
>>  /* A unique local time stamp, might be zero if none is available.  */
>>  extern unsigned local_tick;
>>
>> -/* True if the user has tagged the function with the 'section'
>> -   attribute.  */
>> -
>> -extern bool user_defined_section_attribute;
>> -
>>  /* See toplev.c.  */
>>  extern int flag_rerun_cse_after_global_opts;
>>
>> --
>>
>> On Mon, Aug 11, 2014 at 12:22 PM, Yi Yang  wrote:
>>> Thanks for pointing out this!
>>>
>>> It seems to me that this user_defined_section_attribute variable is
>>> useless now and should be removed. It is intended to work in this way:
>>>
>>> for each function {
>>>parse into tree (setting user_defined_section_attribute)
>>>do tree passes
>>>do RTL passes (using user_defined_section_attribute)
>>>resetting (user_defined_section_attribute = false)
>>> }
>>>
>>> But now GCC works this way:
>>>
>>> for each function {
>>>parse into tree (setting user_defined_section_attribute)
>>> }
>>> do IPA passes
>>> for each function {
>>>do tree passes
>>>do RTL passes (using user_defined_section_attribute)
>>>resetting (user_defined_section_attribute = false)
>>> }
>>>
>>> Therefore the first function will use the actual
>>> user_defined_section_attribute of the last function, and all other
>>> functions will always see user_defined_section_attribute=0.
>>>
>>> I suggest removing user_defined_section_attribute and simply check
>>> !DECL_SECTION_NAME (current_function_decl).
>>>
>>> On Mon, Aug 11, 2014 at 8:00 AM, Teresa Johnson  
>>> wrote:
 On Fri, Aug 8, 2014 at 3:22 PM, Yi Yang  wrote:
> Friendly ping.

 Sorry, was OOO.

 The solution of preventing splitting for named sections is good - but
 it looks like there is already code that should prevent this. See the
 user_defined_section_attribute check here - why is that not set? Looks
 like it should be set in handle_section_attribute() in
 c-family/c-common.c.

 Teresa

>
>
> On Wed, Aug 6, 2014 at 5:20 PM, Dehao Chen  wrote:
>>
>> OK for google-4_8 and google-4_9. David and Teresa may have further
>> comments.
>>
>> Dehao
>>
>> On Wed, Aug 6, 2014 at 3:36 PM, Yi Yang  wrote:
>> > This currently puts split sections together again in the specified
>> > section and breaks DWARF output. This patch disabl

[PATCH] Drop user_defined_section_attribute, directly check DECL_SECTION_NAME instead

[Yi Yang]

Replace checking user_defined_section_attribute with directly checking
DECL_SECTION_NAME. The former does not work in the presence of IPA.

See also: discussion on the same patch in Google branch:
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00749.html

--

2014-08-11  Yi Yang  

gcc:
* bb-reorder.c (pass_partition_blocks::gate): Replace check.
* c-family/c-common.c (handle_section_attribute): Remove
user_defined_section_attribute
* final.c (rest_of_handle_final): ditto
* toplev.c (user_defined_section_attribute): ditto
* toplev.h (user_defined_section_attribute): ditto

diff --git gcc/bb-reorder.c gcc/bb-reorder.c
index 96547c2..747831c 100644
--- gcc/bb-reorder.c
+++ gcc/bb-reorder.c
@@ -95,7 +95,6 @@
 #include "expr.h"
 #include "params.h"
 #include "diagnostic-core.h"
-#include "toplev.h" /* user_defined_section_attribute */
 #include "tree-pass.h"
 #include "df.h"
 #include "bb-reorder.h"
@@ -2671,11 +2670,9 @@ pass_partition_blocks::gate (function *fun)
  arises.  */
   return (flag_reorder_blocks_and_partition
   && optimize
-  /* See gate_handle_reorder_blocks.  We should not partition if
- we are going to omit the reordering.  */
   && optimize_function_for_speed_p (fun)
-  && !DECL_COMDAT_GROUP (current_function_decl)
-  && !user_defined_section_attribute);
+  && !DECL_COMDAT_GROUP (current_function_decl);
+  && !DECL_SECTION_NAME (current_function_decl));
 }

 unsigned
diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index acc9a20..967ae2b 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -7395,8 +7395,6 @@ handle_section_attribute (tree *node, tree
ARG_UNUSED (name), tree args,

   if (targetm_common.have_named_sections)
 {
-  user_defined_section_attribute = true;
-
   if ((TREE_CODE (decl) == FUNCTION_DECL
|| TREE_CODE (decl) == VAR_DECL)
   && TREE_CODE (TREE_VALUE (args)) == STRING_CST)
diff --git gcc/final.c gcc/final.c
index 304ae2a..3fee226 100644
--- gcc/final.c
+++ gcc/final.c
@@ -4460,8 +4460,6 @@ rest_of_handle_final (void)

   assemble_end_function (current_function_decl, fnname);

-  user_defined_section_attribute = false;
-
   /* Free up reg info memory.  */
   free_reg_info ();

diff --git gcc/toplev.c gcc/toplev.c
index 88d48c2..07d5e05 100644
--- gcc/toplev.c
+++ gcc/toplev.c
@@ -152,11 +152,6 @@ HOST_WIDE_INT random_seed;
the support provided depends on the backend.  */
 rtx stack_limit_rtx;

-/* True if the user has tagged the function with the 'section'
-   attribute.  */
-
-bool user_defined_section_attribute = false;
-
 struct target_flag_state default_target_flag_state;
 #if SWITCHABLE_TARGET
 struct target_flag_state *this_target_flag_state = &default_target_flag_state;
diff --git gcc/toplev.h gcc/toplev.h
index 1b54578..b0d0ca4 100644
--- gcc/toplev.h
+++ gcc/toplev.h
@@ -53,11 +53,6 @@ extern void target_reinit (void);
 /* A unique local time stamp, might be zero if none is available.  */
 extern unsigned local_tick;

-/* True if the user has tagged the function with the 'section'
-   attribute.  */
-
-extern bool user_defined_section_attribute;
-
 /* See toplev.c.  */
 extern int flag_rerun_cse_after_global_opts;

--

Re: [C PATCH] Tidy up pedwarn_c90

[Marek Polacek]

On Mon, Aug 11, 2014 at 08:19:52PM +, Joseph S. Myers wrote:
> On Sat, 9 Aug 2014, Marek Polacek wrote:
> 
> > +  /* Maybe we want to issue the C90/C99 compat warning, which is more
> > + specific than -pedantic.  */
> > +  if (warn_c90_c99_compat > 0)
> >  {
> >diagnostic_set_info (&diagnostic, gmsgid, &ap, location, DK_WARNING);
> 
> That seems wrong; it means that -Wc90-c99-compat turns errors from 
> -pedantic-errors into warnings.  E.g.
> 
> const const int i;
> 
> with -std=c90 -pedantic-errors gets an error, but (with this patch 
> applied) with -Wc90-c99-compat it becomes a warning.
> 
> (In view of this problem I haven't reviewed the rest of this patch.)

Ah, ok, I thought that this is desirable.  I'll adjust it.
 
> > diff --git gcc/gcc/c/c-parser.c gcc/gcc/c/c-parser.c
> > index ca8577c..454f279 100644
> > --- gcc/gcc/c/c-parser.c
> > +++ gcc/gcc/c/c-parser.c
> > @@ -1073,7 +1073,10 @@ disable_extension_diagnostics (void)
> >  | (warn_long_long << 4)
> >  | (warn_cxx_compat << 5)
> >  | (warn_overlength_strings << 6)
> > -| (warn_c90_c99_compat << 7));
> > +/* warn_c90_c99_compat has three states: -1/0/1, so we must
> > +   play tricks to properly restore it.  */
> > +| (warn_c90_c99_compat << 7)
> > +| ((warn_c90_c99_compat == -1) << 8));
> 
> This doesn't make sense to me either.  You're left-shifting a negative 
> value (undefined behavior in ISO C, so should be avoided anyway), and left 
> shifting -1 means that all the bits to the left of bit 7 in the result 
> will also be set so can't be used to carry any other information (in 
> particular bit 8 will be set, so this code will in fact work, but by 
> accident).

Oops, sneaky.  I haven't noticed that when I made warn_c90_c99_compat be
initialized to -1 :(.

The patch for -Wc99-c11-compat I posted today has the same issues, so
please ignore that one for now - I'll send a better version tomorrow.

Marek

Re: [PATCH] gcc/c/c-aux-info.c: Resize 'buff' from 10 to 14 bytes

[Joseph S. Myers]

On Sun, 10 Aug 2014, Chen Gang wrote:

> For "[%d]" in sprintf(), theoretically, the maximize size is 14 -- for
> 0x8000, it is sizeof("[-2147483648]"). Normally, it may not cause
> real world bug, but if another issues occur, it may lead things worse.

Negative values certainly don't make sense here, although it may still 
make sense to be robust against them.  If you get one, it probably means a 
conversion from HOST_WIDE_INT to int has overflowed.

int_size_in_bytes returns HOST_WIDE_INT (64-bit).  I think the size 
variable should be changed to HOST_WIDE_INT, buff expanded to be big 
enough for any 64-bit value, and HOST_WIDE_INT_PRINT_DEC used in the 
sprintf format.

Separately, I think it's generally a good idea to convert sprintf uses in 
GCC to snprintf - checking in each case that the size is such that 
truncation shouldn't occur, but snprintf provides extra safety in case 
there is some problem with the size calculation (although there may also 
be a case for having an snprintf variant with an assertion that no 
truncation occurs, so that the compiler safely aborts rather than either 
continuing on truncation or overflowing a buffer).

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

Re: [PATCH] libjava/classpath/native/jni/java-lang/java_lang_VMProcess.c: Be sure 'errbuf' always be zero terminated.

[Chen Gang]

On 08/10/2014 04:22 PM, Chen Gang wrote:
> 
> I guess, I find the root cause:
> 

Although I say "I guess", in fact, I already had related proofs for it.

 - When configure "libjava/classpath", "--disable-core-jni" is passed
   as parameter explicitly (can check "x86_64-.../libjava/classpatch/
   config.log" to know about it).

 - if pass "--disable-core-jni" to "libjava/classpatch/configure", it
   will disable 'JNIDIR' in "libjava/classpath/native/jni/Makefile". If
   remove "--disable-core-jni", it enables 'JNIDIR' to build java-lang.

 - After grep "--disaboe-core-jni", only "libjava/configure(.ac)" do it
   (and hard code it).

For me, the proofs are enough, and the code in "libjava/configure(.ac)"
are also obvious for it.


So please check it is whether it is the root cause, when you have time.

Thanks.

> In "gcc/libjava/configure", "--disable-core-jni" is hardcoded manually
> for classpath with FIXME, then all related trying are useless. For me,
> if have parameter "--enable-core-jni", need skip "--disable-core-jni".
> 
> The related information in gcc/libjava/configure:
> 
>  6820 # Set up to configure Classpath.
>  6821 # FIXME: no supported way to pass args in autoconf.
>  6822 # Disable tool wrappers to avoid ltdl.h configure check.
>  6823 ac_configure_args="$ac_configure_args --disable-tool-wrappers"
>  6824 ac_configure_args="$ac_configure_args --disable-load-library"
>  6825 ac_configure_args="$ac_configure_args --${LIBGCJDEBUG}-debug"
>  6826 ac_configure_args="$ac_configure_args --enable-default-toolkit=$TOOLKIT"
>  6827 dir1=`cd $srcdir && pwd`
>  6828 dir2=`pwd`
>  6829 ac_configure_args="$ac_configure_args --with-vm-classes=$dir1:$dir2"
>  6830 ac_configure_args="$ac_configure_args --disable-core-jni"
>  6831 ac_configure_args="$ac_configure_args --disable-examples"
>  6832 ac_configure_args="$ac_configure_args --with-glibj=build"
> 
> 
> 
> On 08/10/2014 01:58 PM, Chen Gang wrote:
>>
>> On 8/3/14 13:50, Chen Gang wrote:
>>> Excuse me, after tried, I still did not know hot to build the source
>>> code for "x86_64-unknown-linux-gnu/32/libjava/classpath/native/jni".
>>> What I have done is:
>>>
>>>  - ../gcc/configure --enable-core-jni  --enable-languages=c,c++,java
>>>make all-target-libjava
>>>
>>>  - also try "../gcc/configure && make", but get same result.
>>>
>>>  - I also enable JNIDIRS in "x86_64-unknown-linux-gnu/libjava/classpath
>>>/native/jni/Makefile" manually, but still no effect.
>>>
>>> Welcome any ideas, suggestions or completions for it, thank.
>>>
>>> Also sorry, I did not finish sending patch v2 for it within 2014-08-03,
>>> one excuse is: for each complete building, it needs 12-15 hours under my
>>> laptop. So next, I shall buy a PC for it (also for linux kernel).
>>>
>>
>> After try again, I can let it pass building, but I do not know whether
>> it is enough for this patch:
>>
>>  - ../gcc/configure --enable-core-jni && make
>>
>>  - enable JNIDIRS in x86_64-unknown-linux-gnu/libjava/classpath/native/
>>Makefile, manually.
>>
>>  - then "make && make check" succeed with all related things are built.
>>
>> Before send patch v2 for it, I shall wait the confirmation from related
>> members.
>>
>>
>> Thanks.
>>
> 


-- 
Chen Gang

Open share and attitude like air water and life which God blessed

Re: [C PATCH] Tidy up pedwarn_c90

[Joseph S. Myers]

On Sat, 9 Aug 2014, Marek Polacek wrote:

> +  /* Maybe we want to issue the C90/C99 compat warning, which is more
> + specific than -pedantic.  */
> +  if (warn_c90_c99_compat > 0)
>  {
>diagnostic_set_info (&diagnostic, gmsgid, &ap, location, DK_WARNING);

That seems wrong; it means that -Wc90-c99-compat turns errors from 
-pedantic-errors into warnings.  E.g.

const const int i;

with -std=c90 -pedantic-errors gets an error, but (with this patch 
applied) with -Wc90-c99-compat it becomes a warning.

(In view of this problem I haven't reviewed the rest of this patch.)

> diff --git gcc/gcc/c/c-parser.c gcc/gcc/c/c-parser.c
> index ca8577c..454f279 100644
> --- gcc/gcc/c/c-parser.c
> +++ gcc/gcc/c/c-parser.c
> @@ -1073,7 +1073,10 @@ disable_extension_diagnostics (void)
>| (warn_long_long << 4)
>| (warn_cxx_compat << 5)
>| (warn_overlength_strings << 6)
> -  | (warn_c90_c99_compat << 7));
> +  /* warn_c90_c99_compat has three states: -1/0/1, so we must
> + play tricks to properly restore it.  */
> +  | (warn_c90_c99_compat << 7)
> +  | ((warn_c90_c99_compat == -1) << 8));

This doesn't make sense to me either.  You're left-shifting a negative 
value (undefined behavior in ISO C, so should be avoided anyway), and left 
shifting -1 means that all the bits to the left of bit 7 in the result 
will also be set so can't be used to carry any other information (in 
particular bit 8 will be set, so this code will in fact work, but by 
accident).

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

Re: [PATCH 3/3] gcc/ada/socket.c: Add conditionals for RTEMS

[Arnaud Charlet]

> > This patch is needed to make Ada compile for *-*-rtems*
> > on GCC 4.8, 4.9, and the head. Is is ok to commit?
> 
> OK.

Actually, these includes should go in gsocket.h, as done on other targets,
which also answers your previous question.

Can you please repost an updated patch for review?

Arno

Re: [PATCH 3/3] gcc/ada/socket.c: Add conditionals for RTEMS

[Arnaud Charlet]

> This patch is needed to make Ada compile for *-*-rtems*
> on GCC 4.8, 4.9, and the head. Is is ok to commit?

OK.

> 2014-08-11  Joel Sherrill 
> 
>   * socket.c: Add conditionals for RTEMS. Add include of 
>   and so correct prototype of gethostbyname_r() is used.

Re: [PATCH 1/3] gcc/ada/s-osinte-rtems.adb: Correct formatting of comment

[Arnaud Charlet]

> This patch is needed to make Ada compile for *-*-rtems*
> on GCC 4.8, 4.9, and the head. Is is ok to commit?

Yes. This one even falls under the obvious category IMO.

> 2014-08-11  Joel Sherrill 
> 
>   * s-osinte-rtems.adb: Correct formatting of line in license block.

Re: [committed] Use branch with link register for jump from thunk

[John David Anglin]

On 11-Aug-14, at 3:24 PM, John David Anglin wrote:

Tested on hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11.11 and hppa64- 
hp-hpux11.11 with no observed regressions.

Committed to trunk, 4.9 and 4.8.


There is a problem...

Patch reverted.

Dave
--
John David Anglin   dave.ang...@bell.net

Re: [PATCH], rs6000 cleanup, make constraints tighter

[Michael Meissner]

This is the patch I checked in as subversion id 213834.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/constraints.md
===
--- gcc/config/rs6000/constraints.md(revision 213833)
+++ gcc/config/rs6000/constraints.md(working copy)
@@ -68,6 +68,20 @@ (define_register_constraint "wf" "rs6000
 (define_register_constraint "wg" "rs6000_constraints[RS6000_CONSTRAINT_wg]"
   "If -mmfpgpr was used, a floating point register or NO_REGS.")
 
+(define_register_constraint "wh" "rs6000_constraints[RS6000_CONSTRAINT_wh]"
+  "Floating point register if direct moves are available, or NO_REGS.")
+
+;; At present, DImode is not allowed in the Altivec registers.  If in the
+;; future it is allowed, wi/wj can be set to VSX_REGS instead of FLOAT_REGS.
+(define_register_constraint "wi" "rs6000_constraints[RS6000_CONSTRAINT_wi]"
+  "FP or VSX register to hold 64-bit integers or NO_REGS.")
+
+(define_register_constraint "wj" "rs6000_constraints[RS6000_CONSTRAINT_wj]"
+  "FP or VSX register to hold 64-bit integers for direct moves or NO_REGS.")
+
+(define_register_constraint "wk" "rs6000_constraints[RS6000_CONSTRAINT_wk]"
+  "FP or VSX register to hold 64-bit doubles for direct moves or NO_REGS.")
+
 (define_register_constraint "wl" "rs6000_constraints[RS6000_CONSTRAINT_wl]"
   "Floating point register if the LFIWAX instruction is enabled or NO_REGS.")
 
@@ -101,7 +115,7 @@ (define_register_constraint "wx" "rs6000
   "Floating point register if the STFIWX instruction is enabled or NO_REGS.")
 
 (define_register_constraint "wy" "rs6000_constraints[RS6000_CONSTRAINT_wy]"
-  "VSX vector register to hold scalar float values or NO_REGS.")
+  "FP or VSX register to perform ISA 2.07 float ops or NO_REGS.")
 
 (define_register_constraint "wz" "rs6000_constraints[RS6000_CONSTRAINT_wz]"
   "Floating point register if the LFIWZX instruction is enabled or NO_REGS.")
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 213833)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -388,6 +388,7 @@ struct rs6000_reg_addr {
   enum insn_code reload_gpr_vsx;   /* INSN to move from GPR to VSX.  */
   enum insn_code reload_vsx_gpr;   /* INSN to move from VSX to GPR.  */
   addr_mask_type addr_mask[(int)N_RELOAD_REG]; /* Valid address masks.  */
+  bool scalar_in_vmx_p;/* Scalar value can go in VMX.  
*/
 };
 
 static struct rs6000_reg_addr reg_addr[NUM_MACHINE_MODES];
@@ -1732,8 +1733,7 @@ rs6000_hard_regno_mode_ok (int regno, en
  asked for it.  */
   if (TARGET_VSX && VSX_REGNO_P (regno)
   && (VECTOR_MEM_VSX_P (mode)
- || (TARGET_VSX_SCALAR_FLOAT && mode == SFmode)
- || (TARGET_VSX_SCALAR_DOUBLE && (mode == DFmode || mode == DImode))
+ || reg_addr[mode].scalar_in_vmx_p
  || (TARGET_VSX_TIMODE && mode == TImode)
  || (TARGET_VADDUQM && mode == V1TImode)))
 {
@@ -1742,10 +1742,7 @@ rs6000_hard_regno_mode_ok (int regno, en
 
   if (ALTIVEC_REGNO_P (regno))
{
- if (mode == SFmode && !TARGET_UPPER_REGS_SF)
-   return 0;
-
- if ((mode == DFmode || mode == DImode) && !TARGET_UPPER_REGS_DF)
+ if (GET_MODE_SIZE (mode) != 16 && !reg_addr[mode].scalar_in_vmx_p)
return 0;
 
  return ALTIVEC_REGNO_P (last_regno);
@@ -1925,14 +1922,16 @@ rs6000_debug_print_mode (ssize_t m)
   if (rs6000_vector_unit[m] != VECTOR_NONE
   || rs6000_vector_mem[m] != VECTOR_NONE
   || (reg_addr[m].reload_store != CODE_FOR_nothing)
-  || (reg_addr[m].reload_load != CODE_FOR_nothing))
+  || (reg_addr[m].reload_load != CODE_FOR_nothing)
+  || reg_addr[m].scalar_in_vmx_p)
 {
   fprintf (stderr,
-  "  Vector-arith=%-10s Vector-mem=%-10s Reload=%c%c",
+  "  Vector-arith=%-10s Vector-mem=%-10s Reload=%c%c Upper=%c",
   rs6000_debug_vector_unit (rs6000_vector_unit[m]),
   rs6000_debug_vector_unit (rs6000_vector_mem[m]),
   (reg_addr[m].reload_store != CODE_FOR_nothing) ? 's' : '*',
-  (reg_addr[m].reload_load != CODE_FOR_nothing) ? 'l' : '*');
+  (reg_addr[m].reload_load != CODE_FOR_nothing) ? 'l' : '*',
+  (reg_addr[m].scalar_in_vmx_p) ? 'y' : 'n');
 }
 
   fputs ("\n", stderr);
@@ -2049,6 +2048,10 @@ rs6000_debug_reg_global (void)
   "wd reg_class = %s\n"
   "wf reg_class = %s\n"
   "wg reg_class = %s\n"
+  "wh reg_class = %s\n"
+  "wi reg_class = %s\n"
+  "wj reg_class = %s\n"
+  "wk reg_class = %s\n"
   "wl reg_class = %s\n"
   "wm reg_class = %s\n"
   "wr reg_class = %s\n"
@@ -2068,6 +2071,10 @@ rs6000_debug_reg_global (void)
   reg_class_names[rs60

Re: [GOOGLE] Do not partition the cold/hot sections of a function with "section" attribute

[Teresa Johnson]

Ok, thanks. This seems reasonable. Can you send the patch to trunk as well?
Teresa

On Mon, Aug 11, 2014 at 12:35 PM, Yi Yang  wrote:
> Patch v2
>
> ..
>
> diff --git gcc/bb-reorder.c gcc/bb-reorder.c
> index fa6f62f..a1b3e65 100644
> --- gcc/bb-reorder.c
> +++ gcc/bb-reorder.c
> @@ -95,7 +95,6 @@
>  #include "expr.h"
>  #include "params.h"
>  #include "diagnostic-core.h"
> -#include "toplev.h" /* user_defined_section_attribute */
>  #include "tree-pass.h"
>  #include "df.h"
>  #include "bb-reorder.h"
> @@ -2555,7 +2554,7 @@ gate_handle_partition_blocks (void)
>   we are going to omit the reordering.  */
>&& optimize_function_for_speed_p (cfun)
>&& !DECL_ONE_ONLY (current_function_decl)
> -  && !user_defined_section_attribute);
> +  && !DECL_SECTION_NAME (current_function_decl));
>  }
>
>  /* This function is the main 'entrance' for the optimization that
> diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
> index 65c25bf..9923928 100644
> --- gcc/c-family/c-common.c
> +++ gcc/c-family/c-common.c
> @@ -7378,8 +7378,6 @@ handle_section_attribute (tree *node, tree
> ARG_UNUSED (name), tree args,
>
>if (targetm_common.have_named_sections)
>  {
> -  user_defined_section_attribute = true;
> -
>if ((TREE_CODE (decl) == FUNCTION_DECL
> || TREE_CODE (decl) == VAR_DECL)
>&& TREE_CODE (TREE_VALUE (args)) == STRING_CST)
> diff --git gcc/final.c gcc/final.c
> index 9af0b2b..38c90b2 100644
> --- gcc/final.c
> +++ gcc/final.c
> @@ -4501,8 +4501,6 @@ rest_of_handle_final (void)
>
>assemble_end_function (current_function_decl, fnname);
>
> -  user_defined_section_attribute = false;
> -
>/* Free up reg info memory.  */
>free_reg_info ();
>
> diff --git gcc/toplev.c gcc/toplev.c
> index 9b8d313..4c8c965 100644
> --- gcc/toplev.c
> +++ gcc/toplev.c
> @@ -153,11 +153,6 @@ HOST_WIDE_INT random_seed;
> the support provided depends on the backend.  */
>  rtx stack_limit_rtx;
>
> -/* True if the user has tagged the function with the 'section'
> -   attribute.  */
> -
> -bool user_defined_section_attribute = false;
> -
>  struct target_flag_state default_target_flag_state;
>  #if SWITCHABLE_TARGET
>  struct target_flag_state *this_target_flag_state = 
> &default_target_flag_state;
> diff --git gcc/toplev.h gcc/toplev.h
> index 0290be3..65e38e7 100644
> --- gcc/toplev.h
> +++ gcc/toplev.h
> @@ -53,11 +53,6 @@ extern void target_reinit (void);
>  /* A unique local time stamp, might be zero if none is available.  */
>  extern unsigned local_tick;
>
> -/* True if the user has tagged the function with the 'section'
> -   attribute.  */
> -
> -extern bool user_defined_section_attribute;
> -
>  /* See toplev.c.  */
>  extern int flag_rerun_cse_after_global_opts;
>
> --
>
> On Mon, Aug 11, 2014 at 12:22 PM, Yi Yang  wrote:
>> Thanks for pointing out this!
>>
>> It seems to me that this user_defined_section_attribute variable is
>> useless now and should be removed. It is intended to work in this way:
>>
>> for each function {
>>parse into tree (setting user_defined_section_attribute)
>>do tree passes
>>do RTL passes (using user_defined_section_attribute)
>>resetting (user_defined_section_attribute = false)
>> }
>>
>> But now GCC works this way:
>>
>> for each function {
>>parse into tree (setting user_defined_section_attribute)
>> }
>> do IPA passes
>> for each function {
>>do tree passes
>>do RTL passes (using user_defined_section_attribute)
>>resetting (user_defined_section_attribute = false)
>> }
>>
>> Therefore the first function will use the actual
>> user_defined_section_attribute of the last function, and all other
>> functions will always see user_defined_section_attribute=0.
>>
>> I suggest removing user_defined_section_attribute and simply check
>> !DECL_SECTION_NAME (current_function_decl).
>>
>> On Mon, Aug 11, 2014 at 8:00 AM, Teresa Johnson  wrote:
>>> On Fri, Aug 8, 2014 at 3:22 PM, Yi Yang  wrote:
 Friendly ping.
>>>
>>> Sorry, was OOO.
>>>
>>> The solution of preventing splitting for named sections is good - but
>>> it looks like there is already code that should prevent this. See the
>>> user_defined_section_attribute check here - why is that not set? Looks
>>> like it should be set in handle_section_attribute() in
>>> c-family/c-common.c.
>>>
>>> Teresa
>>>


 On Wed, Aug 6, 2014 at 5:20 PM, Dehao Chen  wrote:
>
> OK for google-4_8 and google-4_9. David and Teresa may have further
> comments.
>
> Dehao
>
> On Wed, Aug 6, 2014 at 3:36 PM, Yi Yang  wrote:
> > This currently puts split sections together again in the specified
> > section and breaks DWARF output. This patch disables the partitioning
> > for such functions.
> >
> > --
> >
> > 2014-08-06  Yi Yang  
> >
> > gcc:
> > * bb-reorder.c (gate_handle_partition_blocks): Add a check for
> > "section"
> > attribute.
> >
> > diff --git gcc/bb-reorder.c gcc/bb-reorder.c
>

Re: [GOOGLE] Do not partition the cold/hot sections of a function with "section" attribute

[Yi Yang]

Patch v2

..

diff --git gcc/bb-reorder.c gcc/bb-reorder.c
index fa6f62f..a1b3e65 100644
--- gcc/bb-reorder.c
+++ gcc/bb-reorder.c
@@ -95,7 +95,6 @@
 #include "expr.h"
 #include "params.h"
 #include "diagnostic-core.h"
-#include "toplev.h" /* user_defined_section_attribute */
 #include "tree-pass.h"
 #include "df.h"
 #include "bb-reorder.h"
@@ -2555,7 +2554,7 @@ gate_handle_partition_blocks (void)
  we are going to omit the reordering.  */
   && optimize_function_for_speed_p (cfun)
   && !DECL_ONE_ONLY (current_function_decl)
-  && !user_defined_section_attribute);
+  && !DECL_SECTION_NAME (current_function_decl));
 }

 /* This function is the main 'entrance' for the optimization that
diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 65c25bf..9923928 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -7378,8 +7378,6 @@ handle_section_attribute (tree *node, tree
ARG_UNUSED (name), tree args,

   if (targetm_common.have_named_sections)
 {
-  user_defined_section_attribute = true;
-
   if ((TREE_CODE (decl) == FUNCTION_DECL
|| TREE_CODE (decl) == VAR_DECL)
   && TREE_CODE (TREE_VALUE (args)) == STRING_CST)
diff --git gcc/final.c gcc/final.c
index 9af0b2b..38c90b2 100644
--- gcc/final.c
+++ gcc/final.c
@@ -4501,8 +4501,6 @@ rest_of_handle_final (void)

   assemble_end_function (current_function_decl, fnname);

-  user_defined_section_attribute = false;
-
   /* Free up reg info memory.  */
   free_reg_info ();

diff --git gcc/toplev.c gcc/toplev.c
index 9b8d313..4c8c965 100644
--- gcc/toplev.c
+++ gcc/toplev.c
@@ -153,11 +153,6 @@ HOST_WIDE_INT random_seed;
the support provided depends on the backend.  */
 rtx stack_limit_rtx;

-/* True if the user has tagged the function with the 'section'
-   attribute.  */
-
-bool user_defined_section_attribute = false;
-
 struct target_flag_state default_target_flag_state;
 #if SWITCHABLE_TARGET
 struct target_flag_state *this_target_flag_state = &default_target_flag_state;
diff --git gcc/toplev.h gcc/toplev.h
index 0290be3..65e38e7 100644
--- gcc/toplev.h
+++ gcc/toplev.h
@@ -53,11 +53,6 @@ extern void target_reinit (void);
 /* A unique local time stamp, might be zero if none is available.  */
 extern unsigned local_tick;

-/* True if the user has tagged the function with the 'section'
-   attribute.  */
-
-extern bool user_defined_section_attribute;
-
 /* See toplev.c.  */
 extern int flag_rerun_cse_after_global_opts;

-- 

On Mon, Aug 11, 2014 at 12:22 PM, Yi Yang  wrote:
> Thanks for pointing out this!
>
> It seems to me that this user_defined_section_attribute variable is
> useless now and should be removed. It is intended to work in this way:
>
> for each function {
>parse into tree (setting user_defined_section_attribute)
>do tree passes
>do RTL passes (using user_defined_section_attribute)
>resetting (user_defined_section_attribute = false)
> }
>
> But now GCC works this way:
>
> for each function {
>parse into tree (setting user_defined_section_attribute)
> }
> do IPA passes
> for each function {
>do tree passes
>do RTL passes (using user_defined_section_attribute)
>resetting (user_defined_section_attribute = false)
> }
>
> Therefore the first function will use the actual
> user_defined_section_attribute of the last function, and all other
> functions will always see user_defined_section_attribute=0.
>
> I suggest removing user_defined_section_attribute and simply check
> !DECL_SECTION_NAME (current_function_decl).
>
> On Mon, Aug 11, 2014 at 8:00 AM, Teresa Johnson  wrote:
>> On Fri, Aug 8, 2014 at 3:22 PM, Yi Yang  wrote:
>>> Friendly ping.
>>
>> Sorry, was OOO.
>>
>> The solution of preventing splitting for named sections is good - but
>> it looks like there is already code that should prevent this. See the
>> user_defined_section_attribute check here - why is that not set? Looks
>> like it should be set in handle_section_attribute() in
>> c-family/c-common.c.
>>
>> Teresa
>>
>>>
>>>
>>> On Wed, Aug 6, 2014 at 5:20 PM, Dehao Chen  wrote:

 OK for google-4_8 and google-4_9. David and Teresa may have further
 comments.

 Dehao

 On Wed, Aug 6, 2014 at 3:36 PM, Yi Yang  wrote:
 > This currently puts split sections together again in the specified
 > section and breaks DWARF output. This patch disables the partitioning
 > for such functions.
 >
 > --
 >
 > 2014-08-06  Yi Yang  
 >
 > gcc:
 > * bb-reorder.c (gate_handle_partition_blocks): Add a check for
 > "section"
 > attribute.
 >
 > diff --git gcc/bb-reorder.c gcc/bb-reorder.c
 > index fa6f62f..09449c6 100644
 > --- gcc/bb-reorder.c
 > +++ gcc/bb-reorder.c
 > @@ -2555,6 +2555,7 @@ gate_handle_partition_blocks (void)
 >   we are going to omit the reordering.  */
 >&& optimize_function_for_speed_p (cfun)
 >&& !DECL_ONE_ONLY (current_function_decl)
 > +  && !DECL_SECTION_NAME (current_function_decl)
>>>

Go patch committed: comma-ok assignments used untyped bool

[Ian Lance Taylor]

The Go language was changed slightly so that comma-ok assignments now
return the ok value as an untyped boolean value rather than as the named
type "bool".  The effect of this is that programs can use an existing
variable of a boolean type that is not actually "bool".  This patch by
Chris Manghane implements this for gccgo.  This requires updating one
test in the testsuite.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline (I goofed slightly and
made two separate svn commits).

Ian

diff -r 015c9aa9e4a7 go/runtime.cc
--- a/go/runtime.cc	Sun Aug 10 10:07:25 2014 -0700
+++ b/go/runtime.cc	Mon Aug 11 12:23:24 2014 -0700
@@ -24,7 +24,7 @@
 {
   // General indicator that value is not used.
   RFT_VOID,
-  // Go type bool, C type _Bool.
+  // Go untyped bool, C type _Bool.
   RFT_BOOL,
   // Go type *bool, C type _Bool*.
   RFT_BOOLPTR,
@@ -93,7 +93,7 @@
 	  go_unreachable();
 
 	case RFT_BOOL:
-	  t = Type::lookup_bool_type();
+	  t = Type::make_boolean_type();
 	  break;
 
 	case RFT_BOOLPTR:
diff -r 015c9aa9e4a7 go/statements.cc
--- a/go/statements.cc	Sun Aug 10 10:07:25 2014 -0700
+++ b/go/statements.cc	Mon Aug 11 12:23:24 2014 -0700
@@ -1150,7 +1150,10 @@
 
   // var present_temp bool
   Temporary_statement* present_temp =
-Statement::make_temporary(Type::lookup_bool_type(), NULL, loc);
+Statement::make_temporary((this->present_->type()->is_sink_type())
+			  ? Type::make_boolean_type()
+			  : this->present_->type(),
+			  NULL, loc);
   b->add_statement(present_temp);
 
   // present_temp = mapaccess2(DESCRIPTOR, MAP, &key_temp, &val_temp)
@@ -1163,7 +1166,6 @@
   Expression* a4 = Expression::make_unary(OPERATOR_AND, ref, loc);
   Expression* call = Runtime::make_call(Runtime::MAPACCESS2, loc, 4,
 	a1, a2, a3, a4);
-
   ref = Expression::make_temporary_reference(present_temp, loc);
   ref->set_is_lvalue();
   Statement* s = Statement::make_assignment(ref, call, loc);
@@ -1426,7 +1428,10 @@
 
   // var closed_temp bool
   Temporary_statement* closed_temp =
-Statement::make_temporary(Type::lookup_bool_type(), NULL, loc);
+Statement::make_temporary((this->closed_->type()->is_sink_type())
+			  ? Type::make_boolean_type()
+			  : this->closed_->type(),
+			  NULL, loc);
   b->add_statement(closed_temp);
 
   // closed_temp = chanrecv2(type, channel, &val_temp)
Index: test/named1.go
===
--- test/named1.go	(revision 213455)
+++ test/named1.go	(working copy)
@@ -41,21 +41,21 @@ func main() {
 	asBool(1 != 2) // ok now
 	asBool(i < j)  // ok now
 
-	_, b = m[2] // ERROR "cannot .* bool.*type Bool"
+	_, b = m[2]
 
 	var inter interface{}
-	_, b = inter.(Map) // ERROR "cannot .* bool.*type Bool"
+	_, b = inter.(Map)
 	_ = b
 
 	var minter interface {
 		M()
 	}
-	_, b = minter.(Map) // ERROR "cannot .* bool.*type Bool"
+	_, b = minter.(Map)
 	_ = b
 
 	_, bb := <-c
 	asBool(bb) // ERROR "cannot use.*type bool.*as type Bool"
-	_, b = <-c // ERROR "cannot .* bool.*type Bool"
+	_, b = <-c
 	_ = b
 
 	asString(String(slice)) // ok

[committed] Use branch with link register for jump from thunk

[John David Anglin]

With a large function, the 'b' branch may not be able to reach its  
target without a long branch stub.  Gas doesn't provide
a long branch stub for a branch without a link register (i.e., it  
considers branches with link registers calls).  This patch
changes pa_asm_output_mi_thunk() to use a bl branch so the linker will  
provide a long branch stub if needed.


Tested on hppa-unknown-linux-gnu, hppa2.0w-hp-hpux11.11 and hppa64-hp- 
hpux11.11 with no observed regressions.

Committed to trunk, 4.9 and 4.8.

Dave
--
John David Anglin   dave.ang...@bell.net


2014-08-11  John Dave Anglin  

PR target/62038
* config/pa/pa.c (pa_asm_output_mi_thunk): Use a branch with %r31 link
register.

Index: config/pa/pa.c
===
--- config/pa/pa.c  (revision 213683)
+++ config/pa/pa.c  (working copy)
@@ -8285,7 +8287,9 @@
   if (!val_14)
output_asm_insn ("addil L'%2,%%r26", xoperands);
 
-  output_asm_insn ("b %0", xoperands);
+  /* An absolute branch without a link register is not considered
+a call by GAS.  We need a call to get a stub if necessary.  */
+  output_asm_insn ("bl %0,%%r31", xoperands);
 
   if (val_14)
{

Re: [GOOGLE] Do not partition the cold/hot sections of a function with "section" attribute

[Yi Yang]

Thanks for pointing out this!

It seems to me that this user_defined_section_attribute variable is
useless now and should be removed. It is intended to work in this way:

for each function {
   parse into tree (setting user_defined_section_attribute)
   do tree passes
   do RTL passes (using user_defined_section_attribute)
   resetting (user_defined_section_attribute = false)
}

But now GCC works this way:

for each function {
   parse into tree (setting user_defined_section_attribute)
}
do IPA passes
for each function {
   do tree passes
   do RTL passes (using user_defined_section_attribute)
   resetting (user_defined_section_attribute = false)
}

Therefore the first function will use the actual
user_defined_section_attribute of the last function, and all other
functions will always see user_defined_section_attribute=0.

I suggest removing user_defined_section_attribute and simply check
!DECL_SECTION_NAME (current_function_decl).

On Mon, Aug 11, 2014 at 8:00 AM, Teresa Johnson  wrote:
> On Fri, Aug 8, 2014 at 3:22 PM, Yi Yang  wrote:
>> Friendly ping.
>
> Sorry, was OOO.
>
> The solution of preventing splitting for named sections is good - but
> it looks like there is already code that should prevent this. See the
> user_defined_section_attribute check here - why is that not set? Looks
> like it should be set in handle_section_attribute() in
> c-family/c-common.c.
>
> Teresa
>
>>
>>
>> On Wed, Aug 6, 2014 at 5:20 PM, Dehao Chen  wrote:
>>>
>>> OK for google-4_8 and google-4_9. David and Teresa may have further
>>> comments.
>>>
>>> Dehao
>>>
>>> On Wed, Aug 6, 2014 at 3:36 PM, Yi Yang  wrote:
>>> > This currently puts split sections together again in the specified
>>> > section and breaks DWARF output. This patch disables the partitioning
>>> > for such functions.
>>> >
>>> > --
>>> >
>>> > 2014-08-06  Yi Yang  
>>> >
>>> > gcc:
>>> > * bb-reorder.c (gate_handle_partition_blocks): Add a check for
>>> > "section"
>>> > attribute.
>>> >
>>> > diff --git gcc/bb-reorder.c gcc/bb-reorder.c
>>> > index fa6f62f..09449c6 100644
>>> > --- gcc/bb-reorder.c
>>> > +++ gcc/bb-reorder.c
>>> > @@ -2555,6 +2555,7 @@ gate_handle_partition_blocks (void)
>>> >   we are going to omit the reordering.  */
>>> >&& optimize_function_for_speed_p (cfun)
>>> >&& !DECL_ONE_ONLY (current_function_decl)
>>> > +  && !DECL_SECTION_NAME (current_function_decl)
>>> >&& !user_defined_section_attribute);
>>> >  }
>>
>>
>
>
>
> --
> Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413

Re: [PATCH i386 AVX512] [4/n] Add new way of generating all 0/1 vector.

[Uros Bizjak]

On Mon, Aug 11, 2014 at 3:06 PM, Kirill Yukhin  wrote:
> On 11 Aug 13:51, Jakub Jelinek wrote:
>> On Mon, Aug 11, 2014 at 03:47:07PM +0400, Kirill Yukhin wrote:
>> > @@ -9020,7 +9025,8 @@ standard_sse_constant_opcode (rtx insn, rtx x)
>> > }
>> >
>> >  case 2:
>> > -  if (get_attr_mode (insn) == MODE_XI
>> > +  if (TARGET_AVX512VL
>> > + ||get_attr_mode (insn) == MODE_XI
>>
>> Formatting, add space after ||.
> Fixed.

The patch is OK.

Thanks,
Uros.

Re: [PATCH] Demangler fuzzer

[Mike Stump]

On Aug 11, 2014, at 10:57 AM, Jakub Jelinek  wrote:
> 
>> +  if (timeout != -1)
>> +{
>> +  signal (SIGALRM, alarm_handler);
>> +  alarm (timeout);
>> +}
> 
> Not sure how much portable signal/alarm is.  So probably should be guarded
> by the existence of signal.h, SIGALRM being defined etc.

Generally speaking, newlib doesn’t have it (and I use newlib to build gcc for 
testing).  Autoconf and HAVE_alarm is better, newlib has a SIGALRM.

Re: [RFC/Patch] Latent issue in cp_parser_template_id

[Jason Merrill]

OK with a comment explaining how we can get there.

Jason

Re: [PATCH 3/3] gcc/ada/socket.c: Add conditionals for RTEMS

[Joel Sherrill]

On 8/11/2014 1:15 PM, Mike Stump wrote:
> On Aug 11, 2014, at 8:08 AM, Joel Sherrill  wrote:
>> +#if defined(__rtems__)
>> +#include 
>> +/* Required, for read(), write(), and close() */
>> +#endif
> Strikes me as exceptionally odd.  Should be done unconditionally, and any 
> system that doesn’t like that should be the odd ball.

I assume on other targets, these get prototyped by some implicit include.
I found it odd that this wasn't included already also.

Any Ada maintainers want to comment?

-- 
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available(256) 722-9985

Re: [PATCH 3/3] gcc/ada/socket.c: Add conditionals for RTEMS

[Mike Stump]

On Aug 11, 2014, at 8:08 AM, Joel Sherrill  wrote:
> +#if defined(__rtems__)
> +#include 
> +/* Required, for read(), write(), and close() */
> +#endif

Strikes me as exceptionally odd.  Should be done unconditionally, and any 
system that doesn’t like that should be the odd ball.

[RFC/Patch] Latent issue in cp_parser_template_id

[Paolo Carlini]

Hi,

while working on a patchlet for the simple c++/54377 I noticed a latent 
issue, which goes normally unnoticed because template/typename17.c uses 
the catch all dg-error "". The issue is that, whereas for C++98 we give 
a sensible error message, for C++11 only the late "last resort" check in 
cp_parser_init_declarator:


  /* If the decl specifiers were bad, issue an error now that we're
 sure this was intended to be a declarator.  Then continue
 declaring the variable(s), as int, to try to cut down on further
 errors.  */
  if (decl_specifiers->any_specifiers_p
  && decl_specifiers->type == error_mark_node)
{
  cp_parser_error (parser, "invalid type in declaration");
  decl_specifiers->type = integer_type_node;
}

catches the problem in the typename17.C snippet. As far as I can see, 
the problem is due to the CPP_TEMPLATE_ID optimization in 
cp_parser_template_id, eg, if I disable it with an && 0 the error 
message for C++11 becomes identical to that for C++98. The reason is, 
with C++11, cp_parser_template_id is called first with none_type as 
tag_type, when the optimization mechanism triggers, and then again with 
typename_type, when normally cp_parser_template_id would return 
error_mark_node (it does in C++98) and instead succeeds, returns the 
already parsed BASELINK. At the moment my impression is that the 
CPP_TEMPLATE_ID optimization is rather fragile because in reality the 
parsing can succeed or not depending on the tag_type passes to 
cp_parser_template_id and the optimization doesn't see that. Thus, what 
to do? Something that works, is coping after the fact with the BASELINK 
in cp_parser_elaborated_type_specifier, this allows to have a sensible 
error message for typename17.C and passes testing (patchlet attached)...


If you are curious why I care that much about this issue, I have been 
also playing with removing the "last resort" check above, which would 
avoid a lot of redundant lines in the error messages (which other 
front-end doesn't seem to ever emit). If I do that, after adjusting for 
the redundant error messages, there are *no* regressions in the 
testsuite, *besides* exactly typename17.C in C++11 mode... I'm attaching 
a complete wip patch which passes testing.


Thanks!
Paolo.

///
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 213809)
+++ gcc/cp/parser.c (working copy)
@@ -15194,6 +15188,12 @@ cp_parser_elaborated_type_specifier (cp_parser* pa
 identifier.  */
   if (!template_p && !cp_parser_parse_definitely (parser))
;
+  else if (tag_type == typename_type
+  && BASELINK_P (decl))
+   {
+ cp_parser_diagnose_invalid_type_name (parser, decl, token->location);
+ type = error_mark_node;
+   }
   /* If DECL is a TEMPLATE_ID_EXPR, and the `typename' keyword is
 in effect, then we must assume that, upon instantiation, the
 template will correspond to a class.  */
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 213809)
+++ gcc/cp/parser.c (working copy)
@@ -15194,6 +15188,12 @@ cp_parser_elaborated_type_specifier (cp_parser* pa
 identifier.  */
   if (!template_p && !cp_parser_parse_definitely (parser))
;
+  else if (tag_type == typename_type
+  && BASELINK_P (decl))
+   {
+ cp_parser_diagnose_invalid_type_name (parser, decl, token->location);
+ type = error_mark_node;
+   }
   /* If DECL is a TEMPLATE_ID_EXPR, and the `typename' keyword is
 in effect, then we must assume that, upon instantiation, the
 template will correspond to a class.  */
@@ -16897,17 +16895,6 @@ cp_parser_init_declarator (cp_parser* parser,
  possibly be looking at any other construct.  */
   cp_parser_commit_to_tentative_parse (parser);
 
-  /* If the decl specifiers were bad, issue an error now that we're
- sure this was intended to be a declarator.  Then continue
- declaring the variable(s), as int, to try to cut down on further
- errors.  */
-  if (decl_specifiers->any_specifiers_p
-  && decl_specifiers->type == error_mark_node)
-{
-  cp_parser_error (parser, "invalid type in declaration");
-  decl_specifiers->type = integer_type_node;
-}
-
   /* Enter the newly declared entry in the symbol table.  If we're
  processing a declaration in a class-specifier, we wait until
  after processing the initializer.  */
Index: gcc/testsuite/g++.dg/cpp0x/alias-decl-4.C
===
--- gcc/testsuite/g++.dg/cpp0x/alias-decl-4.C   (revision 213809)
+++ gcc/testsuite/g++.dg/cpp0x/alias-decl-4.C   (working copy)
@@ -11,4 +11,4 @@ template  using B = typename A::U; //
 template  struct A {
 typedef B U;
 };
-B b; // { dg-error "invalid type" }
+B b;
I

[jit] Add a multithreaded test case.

[David Malcolm]

Committed and pushed to branch dmalcolm/jit:

gcc/testsuite/
* jit.dg/test-threads.c: New test case, running all of the
individual test cases in separate threads.
* jit.dg/test-combination.c: Move inclusion of the various
individual testcases into...
* jit.dg/all-non-failing-tests.h: ...this new file, and rename
TEST_COMBINATION to COMBINED_TEST.
* jit.dg/harness.h: Respond to new macro MAKE_DEJAGNU_H_THREADSAFE
by hacking up  to be threadsafe.  Rename
TEST_COMBINATION to COMBINED_TEST.
* jit.dg/jit.exp (proc jit-dg-test): Add "-lpthread" when building
test-threads.exe.
---
 gcc/testsuite/ChangeLog.jit  |  14 ++
 gcc/testsuite/jit.dg/all-non-failing-tests.h | 152 ++
 gcc/testsuite/jit.dg/harness.h   |  25 ++-
 gcc/testsuite/jit.dg/jit.exp |   5 +
 gcc/testsuite/jit.dg/test-combination.c  | 152 +-
 gcc/testsuite/jit.dg/test-threads.c  | 230 +++
 6 files changed, 423 insertions(+), 155 deletions(-)
 create mode 100644 gcc/testsuite/jit.dg/all-non-failing-tests.h
 create mode 100644 gcc/testsuite/jit.dg/test-threads.c

diff --git a/gcc/testsuite/ChangeLog.jit b/gcc/testsuite/ChangeLog.jit
index cdde662..846540f 100644
--- a/gcc/testsuite/ChangeLog.jit
+++ b/gcc/testsuite/ChangeLog.jit
@@ -1,3 +1,17 @@
+2014-08-11  David Malcolm  
+
+   * jit.dg/test-threads.c: New test case, running all of the
+   individual test cases in separate threads.
+   * jit.dg/test-combination.c: Move inclusion of the various
+   individual testcases into...
+   * jit.dg/all-non-failing-tests.h: ...this new file, and rename
+   TEST_COMBINATION to COMBINED_TEST.
+   * jit.dg/harness.h: Respond to new macro MAKE_DEJAGNU_H_THREADSAFE
+   by hacking up  to be threadsafe.  Rename
+   TEST_COMBINATION to COMBINED_TEST.
+   * jit.dg/jit.exp (proc jit-dg-test): Add "-lpthread" when building
+   test-threads.exe.
+
 2014-08-08  David Malcolm  
 
* jit.dg/test-accessing-union.c: New test case.
diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h 
b/gcc/testsuite/jit.dg/all-non-failing-tests.h
new file mode 100644
index 000..54dacb7
--- /dev/null
+++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
@@ -0,0 +1,152 @@
+/* This file is used by test-combination.c and test-threads.c to
+   bring all of the non-failing test cases into one source file,
+   renaming each "create_code" and "verify_code" hook so that they
+   each have unique name.  */
+
+/* Include various other test cases, defining COMBINED_TEST so that
+   harness.h doesn't duplicate copes of e.g. main, and renaming the
+   hooks provided by each test case.  */
+#define COMBINED_TEST
+
+/* test-accessing-struct.c */
+#define create_code create_code_accessing_struct
+#define verify_code verify_code_accessing_struct
+#include "test-accessing-struct.c"
+#undef create_code
+#undef verify_code
+
+/* test-accessing-union.c */
+#define create_code create_code_accessing_union
+#define verify_code verify_code_accessing_union
+#include "test-accessing-union.c"
+#undef create_code
+#undef verify_code
+
+/* test-array-as-pointer.c */
+#define create_code create_code_array_as_pointer
+#define verify_code verify_code_array_as_pointer
+#include "test-array-as-pointer.c"
+#undef create_code
+#undef verify_code
+
+/* test-arrays.c */
+#define create_code create_code_arrays
+#define verify_code verify_code_arrays
+#include "test-arrays.c"
+#undef create_code
+#undef verify_code
+
+/* test-calling-external-function.c */
+#define create_code create_code_calling_external_function
+#define verify_code verify_code_calling_external_function
+#include "test-calling-external-function.c"
+#undef create_code
+#undef verify_code
+
+/* test-calling-function-ptr.c */
+#define create_code create_code_calling_function_ptr
+#define verify_code verify_code_calling_function_ptr
+#include "test-calling-function-ptr.c"
+#undef create_code
+#undef verify_code
+
+/* test-dot-product.c */
+#define create_code create_code_dot_product
+#define verify_code verify_code_dot_product
+#include "test-dot-product.c"
+#undef create_code
+#undef verify_code
+
+/* test-error-*.c: We don't use these test cases, since they deliberately
+   introduce errors, which we don't want here.  */
+
+/* test-expressions.c */
+#define create_code create_code_expressions
+#define verify_code verify_code_expressions
+#include "test-expressions.c"
+#undef create_code
+#undef verify_code
+
+/* test-factorial.c */
+#define create_code create_code_factorial
+#define verify_code verify_code_factorial
+#include "test-factorial.c"
+#undef create_code
+#undef verify_code
+
+/* test-fibonacci.c */
+#define create_code create_code_fibonacci
+#define verify_code verify_code_fibonacci
+#include "test-fibonacci.c"
+#undef create_code
+#undef verify_code
+
+/* test-functions.c */
+#define create_code create_cod

Re: [PATCH] Demangler fuzzer

[Jakub Jelinek]

On Mon, Aug 11, 2014 at 05:04:20PM +0100, Gary Benson wrote:
> + case 's':
> +   seed = atoi (optarg);
> +   break;
> +
> + case 't':
> +   timeout = atoi (optarg);
> +   break;
> +
> + case 'm':
> +   maxcount = atoi (optarg);
> +   break;
> + }
> +}
> +  while (optchr != -1);
> +
> +  if (seed == -1)
> +seed = time (NULL);
> +  srand (seed);
> +  printf ("%s: seed = %d\n", program_name, seed);

That will still make it non-reproduceable if time returns -1
(well, as you cast time_t to int, that can be e.g. on 64-bit arches
any time which has 0x in the low 32 bits).  So perhaps do
  if (seed == -1)
{
  seed = time (NULL);
  if (seed == -1) seed = 0;
}
or something similar?

> +  if (timeout != -1)
> +{
> +  signal (SIGALRM, alarm_handler);
> +  alarm (timeout);
> +}

Not sure how much portable signal/alarm is.  So probably should be guarded
by the existence of signal.h, SIGALRM being defined etc.

Jakub

Re: [PATCH][AArch64][tests]Skip graphite tests that don't fit -mcmodel=tiny

[Mike Stump]

On Aug 11, 2014, at 2:06 AM, Richard Earnshaw  wrote:
> Not quite, read the subject line again.

Doh.  I did miss that entirely.  The solutions I gave were for other cases than 
the case at hand.

> I'm not sure what the correct change to the testsuite is here.

The below is close, let me refine it a little.

> Perhaps the best solution would be something like marking the test as
> "large" in some way and for "large" tests the linker would handle
> "relocation truncated to fit" errors from the linker through some target
> hook that had a better understanding of whether size related options
> were being used and could decide between error and unsupported.

How about a target tiny in supports.exp and any target that is tiny, we handle 
overflows in relocs as always unsupported.  Works for all tiny targets, and 
uniformly works for all languages and all test cases of all time.  Doesn’t 
depend upon guessing a size (how many bytes is tiny, is it code or data, and 
exactly how many bytes were generated on the target for the test case) nor 
guessing which test case are large.  If you test the entire test suite with the 
tiny flag or if that flag is the default, then supports will say that the 
target is tiny.  If you don’t give that flag and it isn’t the default, that 
same target is large.  A person that only has tiny, can just say I’m tiny, and 
be forever done with it.  An advanced ports with relaxation can then remove the 
I’m tiny, and then test relaxation.

I think that offers little code to do this (5-10 lines), handles most 
situations nicely, retains as much testing as possible generally speaking.

If one wants to handle mcmodel options on test cases seamlessly, one can use 
check-flags I think as well, see check_effective_target_arm_fp16_ok_nocache for 
example.

Something like:

 proc ${tool}_check_unsupported_p { output } {
if [regexp "(^|\n)\[^\n\]*: region \[^\n\]* is full" $output] {
  return "memory full”
+if { [regexp "(^|\n)\[^\n\]*: relocation truncated to fit" $output] && 
[check_effective_target_tiny] } {
  return "memory full”
 }

proc check_effective_target_tiny { } {
if { [istarget blabla-*-*]
return 1
}
return 0
}

if the choice is static for the target.  Slightly more complex is check-flags 
is used. I’ll leave that as an exercise for the reader.  :-)

[c++-concepts] substitution fixes

[Andrew Sutton]

Fixing some bugs substituting through constraints. In particular, when
diagnosing an error, make sure that we use the right arguments.

There was also a bug caused by substitution through a decltype-type.
In particular, when folding a non-dependent expression containing a
decltype-type, the inner type is not being resolved (because tsubst
returns early when args == NULL_TREE).

The second patch fixes a regression introduced by the first patch.

2014-08-11  Andrew Sutton  

* gcc/cp/pt.c (tsubst): Don't short circuit substitution into
types when processing constraints.
* gcc/cp/constraint.c (tsubst_constraint_expr): Indicate that
constraint processing is happening.
(tsubst_constraint_info): Just substitute directly into the
normalized constraints instead of re-normalizing.
(diagnose_constraints): Adjust template arguments when
diagnosing template constraint failures.
* gcc/cp/logic.cc (decompose_assumptions): Handle null assumptions.

Andrew Sutton
Index: pt.c
===
--- pt.c	(revision 213758)
+++ pt.c	(working copy)
@@ -11960,6 +11960,8 @@ tsubst_exception_specification (tree fnt
   return new_specs;
 }
 
+extern int processing_constraint;
+
 /* Take the tree structure T and replace template parameters used
therein with the argument vector ARGS.  IN_DECL is an associated
decl for diagnostics.  If an error occurs, returns ERROR_MARK_NODE.
@@ -11994,7 +11996,7 @@ tsubst (tree t, tree args, tsubst_flags_
   if (DECL_P (t))
 return tsubst_decl (t, args, complain);
 
-  if (args == NULL_TREE)
+  if (args == NULL_TREE && !processing_constraint)
 return t;
 
   code = TREE_CODE (t);
Index: semantics.c
===
--- semantics.c	(revision 213758)
+++ semantics.c	(working copy)
@@ -7011,6 +7011,7 @@ finish_decltype_type (tree expr, bool id
   return type;
 }
 
+
   /* The type denoted by decltype(e) is defined as follows:  */
 
   expr = resolve_nondeduced_context (expr);
@@ -7386,7 +7387,7 @@ finish_trait_expr (cp_trait_kind kind, t
 	  || kind == CPTK_IS_LITERAL_TYPE
 	  || kind == CPTK_IS_POD
 	  || kind == CPTK_IS_POLYMORPHIC
-|| kind == CPTK_IS_SAME_AS
+  || kind == CPTK_IS_SAME_AS
 	  || kind == CPTK_IS_STD_LAYOUT
 	  || kind == CPTK_IS_TRIVIAL
 	  || kind == CPTK_IS_UNION);
Index: constraint.cc
===
--- constraint.cc	(revision 213758)
+++ constraint.cc	(working copy)
@@ -241,7 +241,7 @@ tree normalize_stmt (tree);
 tree normalize_decl (tree);
 tree normalize_misc (tree);
 tree normalize_logical (tree);
-tree normalize_call(tree);
+tree normalize_call (tree);
 tree normalize_requires (tree);
 tree normalize_expr_req (tree);
 tree normalize_type_req (tree);
@@ -1114,14 +1114,14 @@ tsubst_local_parms (tree t,
 }
 
 // Substitute ARGS into the requirement body (list of requirements), T.
+// Note that if any substitutions fail, then this is equivalent to 
+// returning false.
 tree
 tsubst_requirement_body (tree t, tree args, tree in_decl)
 {
   tree r = NULL_TREE;
   while (t)
 {
-  // If any substitutions fail, then this is equivalent to
-  // returning false.
   tree e = tsubst_expr (TREE_VALUE (t), args, tf_none, in_decl, false);
   if (e == error_mark_node)
 e = boolean_false_node;
@@ -1142,7 +1142,6 @@ tsubst_requires_expr (tree t, tree args,
   return finish_requires_expr (p, r);
 }
 
-
 // Substitute ARGS into the valid-expr expression T.
 tree
 tsubst_validexpr_expr (tree t, tree args, tree in_decl)
@@ -1197,6 +1196,12 @@ tsubst_nested_req (tree t, tree args, tr
   return tsubst_expr (TREE_OPERAND (t, 0), args, tf_none, in_decl, false);
 }
 
+// Used in various contexts to control substitution. In particular, when
+// non-zero, the substitution of NULL arguments into a type will still
+// process the type as if passing non-NULL arguments, allowing type
+// expressions to be fully elaborated during substitution.
+int processing_constraint;
+
 // Substitute the template arguments ARGS into the requirement
 // expression REQS. Errors resulting from substitution are not
 // diagnosed.
@@ -1208,11 +1213,13 @@ tree
 tsubst_constraint_expr (tree reqs, tree args, bool do_not_fold)
 {
   cp_unevaluated guard;
+  ++processing_constraint;
   if (do_not_fold)
 ++processing_template_decl;
   tree r = tsubst_expr (reqs, args, tf_none, NULL_TREE, false);
   if (do_not_fold)
 --processing_template_decl;
+  --processing_constraint;
   return r;
 }
 
@@ -1230,10 +1237,8 @@ tsubst_constraint_info (tree ci, tree ar
 result->leading_reqs = tsubst_constraint_expr (r, args, true);
   if (tree r = CI_TRAILING_REQS (ci))
 result->trailing_reqs = tsubst_constraint_expr (r, args, true);
-
-  // Build the normalized associated requiremnts.
-  tree r = conjoin_constraints (r

Re: [PATCH] Keep patch file permissions in mklog

[Segher Boessenkool]

On Mon, Aug 11, 2014 at 11:10:59AM +0200, Tom de Vries wrote:
> +use File::Temp;
> +use File::Copy qw(cp mv);

> + # Copy the permissions to the temp file (in perl 2.15 and later).
> + cp $diff, $tmp or die "Could not copy patch file to temp file: $!";

That's File::Copy 2.15, not Perl 2.15 (which doesn't exist).  File::Copy 2.15
isn't so terribly old, so you might want to do a version check, e.g. as

use File::Copy 2.15 qw/cp mv/;

(but it's in Perl 5.10 already, so you might not want to bother).

> -if ($#ARGV != 0) {
> +$inline = 0;
> +if ($#ARGV == 1 && ("$ARGV[0]" eq "-i" || "$ARGV[0]" eq "--inline")) {
> + shift;
> + $inline = 1;
> +} elsif ($#ARGV != 0) {

If you want any more command-line options, have a look at Getopt::Long.


Segher

Re: [C++ PATCH] Improve location info [1/many]

[Jason Merrill]

On 08/01/2014 07:59 AM, Marek Polacek wrote:

Thanks for taking this on, sorry it's taken so long to respond.


+convert_like_real (location_t loc, conversion *convs, tree expr, tree fn,
+  int argnum, int inner, bool issue_conversion_warnings,
   bool c_cast_p, tsubst_flags_t complain)
  {
tree totype = convs->type;
diagnostic_t diag_kind;
int flags;
-  location_t loc = EXPR_LOC_OR_LOC (expr, input_location);


I'm afraid I think this will be a regression for many callers: for 
instance, with a ?: expression this will change conversion diagnostics 
to have the same location as the ?: as a whole rather than the location 
of the subexpression being converted.  Same for build_new_op_1, and all 
the calls where now you pass input_location.


Furthermore, the arguments should have their own locations in 
EXPR_LOCATION; I don't think we need to track them separately.  If their 
locations are wrong that's something to fix directly, rather than adding 
a special case for function arguments.


So I think I'd like to drop the arg_loc/convert_like changes from this 
patch.



+ pedwarn (loc, 0, "deducing %qT as %qT",



+ if (permerror (loc, "passing %qT as % "


These should use the location of the argument, not the call.

There are also a lot of added uses of input_location, which makes me 
uncomfortable.  For build_operator_new_call and build_new_1, I think we 
want the location of the 'new' token.   For build_op_call_1, we can use 
the '(', and so on.


Jason

Re: [PATCH], rs6000 cleanup, make constraints tighter

[Michael Meissner]

On Fri, Aug 08, 2014 at 03:31:48PM -0400, David Edelsohn wrote:
> Okay.
> 
> Note that you or Carrot will have to be careful about the merge of
> movdi_internal64 as both of your patches affect that pattern.

Carrot has checked in his patch, and I will adapt my patch (and replace the
constraint wm Carrot used with wi, since wi is now the constraint to use for
DImode in FP/VSX registers.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

[C PATCH] Implement -Wc99-c11-compat

[Marek Polacek]

Now that the -Wc90-c99-compat warning is in, the next step was to implement
the -Wc99-c11-compat warning, which is what this patch is about.
Luckily the implementation is quite straightforward, since there are
no specialized options similar to -Wlong-long that should be taken into
account - thus no tinkering in libcpp etc. is needed.
The only snag was that the pedwarn_c99 function was used to diagnose
implicit int rule and return types, but if pedwarn_c90 is about things
present in C99 but not in C90, pedwarn_c99 then should be about things
present in C11 but not in C99 - so I introduced a new helper function
called warn_defaults_to that takes care of the "defaults to" warnings.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2014-08-11  Marek Polacek  

* doc/invoke.texi: Document -Wc99-c11-compat.
c-family/
* c.opt (Wc99-c11-compat): New option.
c/
* c-decl.c (diagnose_mismatched_decls): Unconditionally call
pedwarn_c99 instead of pedwarn.
(grokfield): Likewise.
(warn_defaults_to): New function.
(grokdeclarator): Call warn_defaults_to instead of pedwarn_c99.
Unconditionally call pedwarn_c99 instead of pedwarn.
(start_function): Call warn_defaults_to instead of pedwarn_c99.
(declspecs_add_scspec): Call pedwarn_c99 instead of pedwarn, don't
check flag_isoc11 before.
* c-errors.c (pedwarn_c99): Change the return type to bool.
Handle -Wc99-c11-compat.
* c-parser.c (disable_extension_diagnostics): Handle
warn_c99_c11_compat.
(restore_extension_diagnostics): Likewise.
(c_parser_static_assert_declaration_no_semi): Call pedwarn_c99
instead of pedwarn, don't check flag_isoc11 before.
(c_parser_declspecs): Likewise.
(c_parser_alignas_specifier): Likewise.
(c_parser_alignof_expression): Likewise.
(c_parser_generic_selection): Likewise.
* c-tree.h (pedwarn_c99): Update declaration.
* c-typeck.c (c_finish_return): Call pedwarn or warning_at instead
of pedwarn_c99.
testsuite/
* gcc.dg/Wc99-c11-compat-1.c: New test.
* gcc.dg/Wc99-c11-compat-2.c: New test.
* gcc.dg/Wc99-c11-compat-3.c: New test.
* gcc.dg/Wc99-c11-compat-4.c: New test.
* gcc.dg/Wc99-c11-compat-5.c: New test.

diff --git gcc/c-family/c.opt gcc/c-family/c.opt
index 087eabd..4848399 100644
--- gcc/c-family/c.opt
+++ gcc/c-family/c.opt
@@ -295,6 +295,10 @@ Wc90-c99-compat
 C ObjC Var(warn_c90_c99_compat) Init(-1) Warning
 Warn about features not present in ISO C90, but present in ISO C99
 
+Wc99-c11-compat
+C ObjC Var(warn_c99_c11_compat) Init(-1) Warning
+Warn about features not present in ISO C99, but present in ISO C11
+
 Wc++-compat
 C ObjC Var(warn_cxx_compat) Warning
 Warn about C constructs that are not in the common subset of C and C++
diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index 138b014..39852d5 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -538,6 +538,8 @@ static tree grokdeclarator (const struct c_declarator *,
bool *, enum deprecated_states);
 static tree grokparms (struct c_arg_info *, bool);
 static void layout_array_type (tree);
+static void warn_defaults_to (location_t, int, const char *, ...)
+ATTRIBUTE_GCC_DIAG(3,4);
 
 /* T is a statement.  Add it to the statement-tree.  This is the
C/ObjC version--C++ has a slightly different version of this
@@ -1844,12 +1846,9 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
 newdecl);
  locate_old_decl (olddecl);
}
-  else if (pedantic && !flag_isoc11)
-   {
- pedwarn (input_location, OPT_Wpedantic,
-  "redefinition of typedef %q+D", newdecl);
- locate_old_decl (olddecl);
-   }
+  else if (pedwarn_c99 (input_location, OPT_Wpedantic,
+   "redefinition of typedef %q+D", newdecl))
+   locate_old_decl (olddecl);
 
   return true;
 }
@@ -4941,6 +4940,22 @@ warn_variable_length_array (tree name, tree size)
 }
 }
 
+/* Print warning about defaulting to int if necessary.  */
+
+static void
+warn_defaults_to (location_t location, int opt, const char *gmsgid, ...)
+{
+  diagnostic_info diagnostic;
+  va_list ap;
+
+  va_start (ap, gmsgid);
+  diagnostic_set_info (&diagnostic, gmsgid, &ap, location,
+   flag_isoc99 ? DK_PEDWARN : DK_WARNING);
+  diagnostic.option_index = opt;
+  report_diagnostic (&diagnostic);
+  va_end (ap);
+}
+
 /* Given declspecs and a declarator,
determine the name and type of the object declared
and construct a ..._DECL node for it.
@@ -5117,12 +5132,12 @@ grokdeclarator (const struct c_declarator *declarator,
   else
{
  if (name)
-   pedwarn_c99 (loc, flag_isoc99 ? 0 : OPT_Wimplicit_int,
-"type defaults to % in declaration of %qE",
-name);
+   warn_defaults_to (loc, fl

Re: [PATCH] Demangler fuzzer

[Andi Kleen]

Looks good.
-Andi

Re: [PATCH] Demangler fuzzer

[Gary Benson]

David Malcolm wrote:
> On Mon, 2014-08-11 at 08:06 -0700, Andi Kleen wrote:
> > Gary Benson  writes:
> > > srand(time(NULL));
> > 
> > That's really bad, can never be reproduced.  If you use a random
> > seed like this you need to at least print it.
> 
> How about taking the random seed and the number of iterations as
> command-line arguments?  (with defaults for each)

Well, the reproducer ends up in the corefile, but I take your point.
How about this patch?

Thanks,
Gary

-- 
Index: libiberty/ChangeLog
===
--- libiberty/ChangeLog (revision 213809)
+++ libiberty/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2014-08-11  Gary Benson  
+
+   * testsuite/demangler-fuzzer.c: New file.
+   * testsuite/Makefile.in (fuzz-demangler): New rule.
+   (demangler-fuzzer): Likewise.
+   (mostlyclean): Clean up demangler fuzzer.
+
 2014-06-11  Andrew Burgess  
 
* cplus-dem.c (do_type): Call string_delete even if the call to
Index: libiberty/testsuite/Makefile.in
===
--- libiberty/testsuite/Makefile.in (revision 213809)
+++ libiberty/testsuite/Makefile.in (working copy)
@@ -59,6 +59,10 @@
 check-expandargv: test-expandargv
./test-expandargv
 
+# Run the demangler fuzzer
+fuzz-demangler: demangler-fuzzer
+   ./demangler-fuzzer -m 5000
+
 TEST_COMPILE = $(CC) @DEFS@ $(LIBCFLAGS) -I.. -I$(INCDIR) $(HDEFINES)
 test-demangle: $(srcdir)/test-demangle.c ../libiberty.a
$(TEST_COMPILE) -o test-demangle \
@@ -72,6 +76,10 @@
$(TEST_COMPILE) -DHAVE_CONFIG_H -I.. -o test-expandargv \
$(srcdir)/test-expandargv.c ../libiberty.a
 
+demangler-fuzzer: $(srcdir)/demangler-fuzzer.c ../libiberty.a
+   $(TEST_COMPILE) -o demangler-fuzzer \
+   $(srcdir)/demangler-fuzzer.c ../libiberty.a
+
 # Standard (either GNU or Cygnus) rules we don't use.
 html install-html info install-info clean-info dvi pdf install-pdf \
 install etags tags installcheck:
@@ -81,6 +89,7 @@
rm -f test-demangle
rm -f test-pexecute
rm -f test-expandargv
+   rm -f demangler-fuzzer
rm -f core
 clean: mostlyclean
 distclean: clean
Index: libiberty/testsuite/demangler-fuzzer.c
===
--- libiberty/testsuite/demangler-fuzzer.c  (revision 0)
+++ libiberty/testsuite/demangler-fuzzer.c  (revision 0)
@@ -0,0 +1,121 @@
+/* Demangler fuzzer.
+
+   Copyright (C) 2014 Free Software Foundation, Inc.
+
+   This file is part of GNU libiberty.
+
+   This program 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 of the License, or
+   (at your option) any later version.
+
+   This program 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 this program.  If not, see .  */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAXLEN 253
+#define ALPMIN 33
+#define ALPMAX 127
+
+static char *program_name;
+
+static void
+print_usage (FILE *fp, int exit_value)
+{
+  fprintf (fp, "Usage: %s [OPTION]...\n", program_name);
+  fprintf (fp, "Options:\n");
+  fprintf (fp, "  -h   Display this message.\n");
+  fprintf (fp, "  -s SEED  Select the random seed to be used.\n");
+  fprintf (fp, "  -t TIMEOUT   Exit after TIMEOUT seconds.\n");
+  fprintf (fp, "  -m MAXCOUNT  Exit after MAXCOUNT symbols.\n");
+
+  exit (exit_value);
+}
+
+static int quit_flag;
+
+static void
+alarm_handler (int signum)
+{
+  quit_flag = 1;
+}
+
+int
+main (int argc, char *argv[])
+{
+  char symbol[2 + MAXLEN + 1] = "_Z";
+  int optchr;
+  int seed = -1, maxcount = -1, timeout = -1;
+  int count = 0;
+
+  program_name = argv[0];
+
+  do
+{
+  optchr = getopt (argc, argv, "hs:m:t:");
+  switch (optchr)
+   {
+   case '?':  /* Unrecognized option.  */
+ print_usage (stderr, 1);
+ break;
+
+   case 'h':
+ print_usage (stdout, 0);
+ break;
+
+   case 's':
+ seed = atoi (optarg);
+ break;
+
+   case 't':
+ timeout = atoi (optarg);
+ break;
+
+   case 'm':
+ maxcount = atoi (optarg);
+ break;
+   }
+}
+  while (optchr != -1);
+
+  if (seed == -1)
+seed = time (NULL);
+  srand (seed);
+  printf ("%s: seed = %d\n", program_name, seed);
+
+  if (timeout != -1)
+{
+  signal (SIGALRM, alarm_handler);
+  alarm (timeout);
+}
+
+  while (!quit_flag && (maxcount < 0 || count < maxcount))
+{
+  char *buffer = symbol

Re: [PATCH] Demangler fuzzer

[David Malcolm]

On Mon, 2014-08-11 at 08:06 -0700, Andi Kleen wrote:
> Gary Benson  writes:
> 
> >srand(time(NULL));
> 
> That's really bad, can never be reproduced.  If you use a random seed
> like this you need to at least print it.

How about taking the random seed and the number of iterations as
command-line arguments?  (with defaults for each)

[PATCH 3/3] gcc/ada/socket.c: Add conditionals for RTEMS

[Joel Sherrill]

This patch is needed to make Ada compile for *-*-rtems*
on GCC 4.8, 4.9, and the head. Is is ok to commit?

2014-08-11  Joel Sherrill 

* socket.c: Add conditionals for RTEMS. Add include of 
and so correct prototype of gethostbyname_r() is used.
---
 gcc/ada/socket.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gcc/ada/socket.c b/gcc/ada/socket.c
index 4a9e6ad..631bfdc 100644
--- a/gcc/ada/socket.c
+++ b/gcc/ada/socket.c
@@ -60,6 +60,11 @@ typedef int IOCTL_Req_T;
 #include 
 /* Required for memcpy() */
 
+#if defined(__rtems__)
+#include 
+/* Required, for read(), write(), and close() */
+#endif
+
 extern void __gnat_disable_sigpipe (int fd);
 extern void __gnat_disable_all_sigpipes (void);
 extern int  __gnat_create_signalling_fds (int *fds);
@@ -184,7 +189,7 @@ __gnat_gethostbyname (const char *name,
   struct hostent *rh;
   int ri;
 
-#if defined(__linux__) || defined(__GLIBC__)
+#if defined(__linux__) || defined(__GLIBC__) || defined(__rtems__)
   (void) gethostbyname_r (name, ret, buf, buflen, &rh, h_errnop);
 #else
   rh = gethostbyname_r (name, ret, buf, buflen, h_errnop);
-- 
1.9.3

[PATCH 1/3] gcc/ada/s-osinte-rtems.adb: Correct formatting of comment

[Joel Sherrill]

This patch is needed to make Ada compile for *-*-rtems*
on GCC 4.8, 4.9, and the head. Is is ok to commit?

2014-08-11  Joel Sherrill 

* s-osinte-rtems.adb: Correct formatting of line in license block.
---
 gcc/ada/s-osinte-rtems.adb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/ada/s-osinte-rtems.adb b/gcc/ada/s-osinte-rtems.adb
index de21785..9f01128 100644
--- a/gcc/ada/s-osinte-rtems.adb
+++ b/gcc/ada/s-osinte-rtems.adb
@@ -22,7 +22,7 @@
 -- You should have received a copy of the GNU General Public License and--
 -- a copy of the GCC Runtime Library Exception along with this program; --
 -- see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see--
--- . 
+-- .  --
 --  --
 -- GNARL was developed by the GNARL team at Florida State University. It is --
 -- now maintained by Ada Core Technologies Inc. in cooperation with Florida --
-- 
1.9.3

[PATCH 2/3] libada/Makefile.in: Add CFLAGS_FOR_TARGET to GNATLIBCFLAGS_FOR_C

[Joel Sherrill]

This patch is needed to make Ada compile for *-*-rtems*
on GCC 4.8, 4.9, and the head. Is is ok to commit?

2014-08-11  Joel Sherrill 

* Makefile.in: Add CFLAGS_FOR_TARGET to GNATLIBCFLAGS_FOR_C.
---
 libada/Makefile.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libada/Makefile.in b/libada/Makefile.in
index c307b99..93da740 100644
--- a/libada/Makefile.in
+++ b/libada/Makefile.in
@@ -60,7 +60,7 @@ CFLAGS=-g
 PICFLAG = @PICFLAG@
 GNATLIBFLAGS= -W -Wall -gnatpg -nostdinc
 GNATLIBCFLAGS= -g -O2
-GNATLIBCFLAGS_FOR_C = -W -Wall $(GNATLIBCFLAGS) \
+GNATLIBCFLAGS_FOR_C = -W -Wall $(GNATLIBCFLAGS) $(CFLAGS_FOR_TARGET) \
-fexceptions -DIN_RTS @have_getipinfo@
 
 host_subdir = @host_subdir@
-- 
1.9.3

Re: [PATCH] Demangler fuzzer

[Andi Kleen]

Gary Benson  writes:

>srand(time(NULL));

That's really bad, can never be reproduced.  If you use a random seed
like this you need to at least print it.

-Andi


-- 
a...@linux.intel.com -- Speaking for myself only

Re: [GOOGLE] Do not partition the cold/hot sections of a function with "section" attribute

[Teresa Johnson]

On Fri, Aug 8, 2014 at 3:22 PM, Yi Yang  wrote:
> Friendly ping.

Sorry, was OOO.

The solution of preventing splitting for named sections is good - but
it looks like there is already code that should prevent this. See the
user_defined_section_attribute check here - why is that not set? Looks
like it should be set in handle_section_attribute() in
c-family/c-common.c.

Teresa

>
>
> On Wed, Aug 6, 2014 at 5:20 PM, Dehao Chen  wrote:
>>
>> OK for google-4_8 and google-4_9. David and Teresa may have further
>> comments.
>>
>> Dehao
>>
>> On Wed, Aug 6, 2014 at 3:36 PM, Yi Yang  wrote:
>> > This currently puts split sections together again in the specified
>> > section and breaks DWARF output. This patch disables the partitioning
>> > for such functions.
>> >
>> > --
>> >
>> > 2014-08-06  Yi Yang  
>> >
>> > gcc:
>> > * bb-reorder.c (gate_handle_partition_blocks): Add a check for
>> > "section"
>> > attribute.
>> >
>> > diff --git gcc/bb-reorder.c gcc/bb-reorder.c
>> > index fa6f62f..09449c6 100644
>> > --- gcc/bb-reorder.c
>> > +++ gcc/bb-reorder.c
>> > @@ -2555,6 +2555,7 @@ gate_handle_partition_blocks (void)
>> >   we are going to omit the reordering.  */
>> >&& optimize_function_for_speed_p (cfun)
>> >&& !DECL_ONE_ONLY (current_function_decl)
>> > +  && !DECL_SECTION_NAME (current_function_decl)
>> >&& !user_defined_section_attribute);
>> >  }
>
>



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

Re: Fix side case in ipa-devirt

[Rainer Orth]

Hi Jan,

>   * g++.dg/ipa/devirt-37.C: New testcase.

it seems something is very wrong with this testcase: initially, all
scans FAILed because the dump file didn't exist.  But even with -O2
added to dg-options, the failures remain because either the wording is
different

FAIL: g++.dg/ipa/devirt-37.C  -std=gnu++98  scan-tree-dump fre2 "Determined 
dynamic type."

vs.

Determining dynamic type for call: OBJ_TYPE_REF(_4;(struct A)a_2(D)->0) 
(a_2(D));
^^^

or the strings are completely missing.

Please fix.

Rainer

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

[PATCH] Fix PR62075

[Richard Biener]

The following fixes SLP pure/hybrid detection with patterns.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
sofar.

Richard.

2014-08-11  Richard Biener  

PR tree-optimization/62075
* tree-vect-slp.c (vect_detect_hybrid_slp_stmts): Properly
handle uses in patterns.

* gcc.dg/vect/pr62075.c: New testcase.

Index: gcc/testsuite/gcc.dg/vect/pr62075.c
===
--- gcc/testsuite/gcc.dg/vect/pr62075.c (revision 0)
+++ gcc/testsuite/gcc.dg/vect/pr62075.c (working copy)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+
+int a[16][2];
+struct A
+{
+  int b[16][2];
+  int c[16][1];
+};
+
+void
+foo (struct A *x)
+{
+  int i;
+  for (i = 0; i < 16; ++i)
+{
+  x->b[i][0] = a[i][0];
+  x->c[i][0] = 0 != a[i][0];
+  x->b[i][1] = a[i][1];
+}
+}
+
+/* { dg-final { cleanup-tree-dump "vect" } } */
Index: gcc/tree-vect-slp.c
===
*** gcc/tree-vect-slp.c (revision 213811)
--- gcc/tree-vect-slp.c (working copy)
*** vect_detect_hybrid_slp_stmts (slp_tree n
*** 1793,1799 
&& (stmt_vinfo = vinfo_for_stmt (use_stmt))
&& !STMT_SLP_TYPE (stmt_vinfo)
  && (STMT_VINFO_RELEVANT (stmt_vinfo)
! || VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE (stmt_vinfo)))
&& !(gimple_code (use_stmt) == GIMPLE_PHI
   && STMT_VINFO_DEF_TYPE (stmt_vinfo)
== vect_reduction_def))
--- 1793,1802 
&& (stmt_vinfo = vinfo_for_stmt (use_stmt))
&& !STMT_SLP_TYPE (stmt_vinfo)
  && (STMT_VINFO_RELEVANT (stmt_vinfo)
! || VECTORIZABLE_CYCLE_DEF (STMT_VINFO_DEF_TYPE (stmt_vinfo))
!   || (STMT_VINFO_IN_PATTERN_P (stmt_vinfo)
!   && STMT_VINFO_RELATED_STMT (stmt_vinfo)
!   && !STMT_SLP_TYPE (vinfo_for_stmt (STMT_VINFO_RELATED_STMT 
(stmt_vinfo)
&& !(gimple_code (use_stmt) == GIMPLE_PHI
   && STMT_VINFO_DEF_TYPE (stmt_vinfo)
== vect_reduction_def))

Re: [PATCH] Demangler fuzzer

[Gary Benson]

Jakub Jelinek wrote:
> On Mon, Aug 11, 2014 at 10:27:03AM +0100, Gary Benson wrote:
> > This patch adds a simple fuzzer for the libiberty C++ demangler.
> > You can run it like this:
> > 
> >   make -C /path/to/build/libiberty/testsuite fuzz-demangler
> > 
> > It will run until it dumps core (usually only a few seconds).
> > 
> > Is this ok to commit?
> 
> I think it is bad when the command never succeeds in case of
> success.  There should be some limit on the number of iterations
> (perhaps a parameter to the program), or timeout.

How about as inlined below, with a 60 second timeout?

> > +  for (i = 0; i < length; i++)
> > +   *(buffer++) = (rand () % (ALPMAX - ALPMIN)) + ALPMIN;
> > +
> > +  *(buffer++) = '\0';
> 
> Please use just *buffer++ instead of *(buffer++) in both places.

Changed below.

Thanks,
Gary

-- 
2014-08-11  Gary Benson  

* testsuite/demangler-fuzzer.c: New file.
* testsuite/Makefile.in (fuzz-demangler): New rule.
(demangler-fuzzer): Likewise.
(mostlyclean): Clean up demangler fuzzer.

Index: libiberty/testsuite/Makefile.in
===
--- libiberty/testsuite/Makefile.in (revision 213809)
+++ libiberty/testsuite/Makefile.in (working copy)
@@ -59,6 +59,10 @@
 check-expandargv: test-expandargv
./test-expandargv
 
+# Run the demangler fuzzer
+fuzz-demangler: demangler-fuzzer
+   ./demangler-fuzzer
+
 TEST_COMPILE = $(CC) @DEFS@ $(LIBCFLAGS) -I.. -I$(INCDIR) $(HDEFINES)
 test-demangle: $(srcdir)/test-demangle.c ../libiberty.a
$(TEST_COMPILE) -o test-demangle \
@@ -72,6 +76,10 @@
$(TEST_COMPILE) -DHAVE_CONFIG_H -I.. -o test-expandargv \
$(srcdir)/test-expandargv.c ../libiberty.a
 
+demangler-fuzzer: $(srcdir)/demangler-fuzzer.c ../libiberty.a
+   $(TEST_COMPILE) -o demangler-fuzzer \
+   $(srcdir)/demangler-fuzzer.c ../libiberty.a
+
 # Standard (either GNU or Cygnus) rules we don't use.
 html install-html info install-info clean-info dvi pdf install-pdf \
 install etags tags installcheck:
@@ -81,6 +89,7 @@
rm -f test-demangle
rm -f test-pexecute
rm -f test-expandargv
+   rm -f demangler-fuzzer
rm -f core
 clean: mostlyclean
 distclean: clean
Index: libiberty/testsuite/demangler-fuzzer.c
===
--- libiberty/testsuite/demangler-fuzzer.c  (revision 0)
+++ libiberty/testsuite/demangler-fuzzer.c  (revision 0)
@@ -0,0 +1,67 @@
+/* Demangler fuzzer.
+
+   Copyright (C) 2014 Free Software Foundation, Inc.
+
+   This file is part of GNU libiberty.
+
+   This program 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 of the License, or
+   (at your option) any later version.
+
+   This program 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 this program.  If not, see .  */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAXLEN 253
+#define ALPMIN 33
+#define ALPMAX 127
+
+static int quit_flag;
+
+static void
+alarm_handler (int signum)
+{
+  quit_flag = 1;
+}
+
+int
+main (int argc, char *argv[])
+{
+  char symbol[2 + MAXLEN + 1] = "_Z";
+  int count = 0;
+
+  srand (time (NULL));
+  signal (SIGALRM, alarm_handler);
+  alarm (60);
+
+  while (!quit_flag)
+{
+  char *buffer = symbol + 2;
+  int length, i;
+
+  length = rand () % MAXLEN;
+  for (i = 0; i < length; i++)
+   *buffer++ = (rand () % (ALPMAX - ALPMIN)) + ALPMIN;
+
+  *buffer++ = '\0';
+
+  cplus_demangle (symbol, DMGL_AUTO | DMGL_ANSI | DMGL_PARAMS);
+
+  count++;
+}
+
+  printf ("Successfully demangled %d symbols\n", count);
+  exit (0);
+}

Re: [GSoC] Elimination of CLooG library installation dependency

[Roman Gareev]

> Did you try your code with 64bit pointer types?

Yes. It seems that the result is the same.

> In any case, I don't think it is worth spending time on this. I would check
> in the scop detection that we disable the handling of unsigned and pointer
> types. It is a complex thing to model and the approach currently taking of
> always model their wrapping behaviour seems wrong.

I’ve attached a patch, which disables the handling SSA_NAME nodes in
case they are pointers to object types. Which nodes should also be
disabled? (I’ve found that this disabling helps to avoid the error and
can be a temporary solution) Is the graphite_can_represent_scev an
appropriate place for the disabling of type handling?

-- 
Cheers, Roman Gareev.
Index: gcc/graphite-scop-detection.c
===
--- gcc/graphite-scop-detection.c   (revision 213773)
+++ gcc/graphite-scop-detection.c   (working copy)
@@ -54,6 +54,7 @@
 #include "tree-pass.h"
 #include "sese.h"
 #include "tree-ssa-propagate.h"
+#include "cp/cp-tree.h"
 
 #ifdef HAVE_cloog
 #include "graphite-poly.h"
@@ -217,6 +218,9 @@
   if (chrec_contains_undetermined (scev))
 return false;
 
+  if (TYPE_PTROB_P (TREE_TYPE (scev)) && TREE_CODE (scev) == SSA_NAME)
+return false;
+
   switch (TREE_CODE (scev))
 {
 case NEGATE_EXPR:

Re: [PATCH] PR preprocessor/61817 - Fix location of tokens in built-in macro expansion list

[Dodji Seketeli]

Hello,

I have initially sent a patch for this at
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01144.html.  But then a
patch for a similarly expressed issue
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01521.html (which I think
is the same underlying problem) was committed.  As the PR
preprocessor/61817 is still not fixed, I have updated my initial patch
over the one that was committed already and am submitted the result
below.  I have added more test cases in the process.


Consider this function-like macro definition in the inc.h file

--->inc.h<---
#define F() const int line = __LINE__
--->8<---

Now consider its use in a file test.c:

-->cat -n test.c<
 1  #include "inc.h"
 2
 3  void
 4  foo()
 5  {
 6F
 7  (
 8   )
 9  ;
10  }
--->8<-

Running test.c through cc1 -quiet -E yields:

->8<
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "" 2
# 1 "test.c"
# 1 "inc.h" 1
# 2 "test.c" 2

void
foo()
{
  const int line =

 8
;
}
->8<--

Note how tokens "const", "int", "line" and "=" are all on the same
line (line 6) as the expansion point of the function-like F() macro,
but how the token "8", resulting from the expansion of the built-in
macro __FILE__ is on the same line as the closing parenthesis of the
invocation of F().

This is the problem.  The result of the __LINE__ macro should be "6"
and should be on the same line (line 6) as the other tokens of the
expansion-list of F().

This issue actually holds for the expansion of all built-in macros.

So more generelly, I would describe the issue as such:

When expanded in a function-like macro, the location of resulting
tokens of a built-in macro is set to the closing parenthesis of the
enclosing function-like macro invocation, rather than being set to the
location of the expansion point of the invocation the enclosing
functin-like macro.

I think the problem is that enter_macro_context() is passed the
location of the expansion point of the macro that is about to be
expanded.  But when that macro is built-in, builtin_macro() that is
then called by enter_macro_context() doesn't use the macro expansion
point location when expanding the __LINE__ builtin (in, e.g,
_cpp_builtin_macro_text) .  Rather, what it used is the location of
the closing parenthesis of the enclosing function-like macro
invocation or, more generally, the location of the previous token in
the stream.

The patch proposes to make builtin_macro() use the expansion point
location that enter_macro_context() passed along.  That location is
then used by the different routines that need it (e.g, to expand
builtin macros for instance).

Also, for the particular case of __LINE__, make that built-in expand
to the line number of that expansion point.

Note that in the function builtin_macro, this patch avoids re-setting
token->src_loc because for ease of maintenance (and debugging), I
think it's preferable that the spelling location of tokens be set only
in place -- in the tokens lexer.  To control the value of that
location we use the function cpp_force_token_locations, as intended.

The patch bootstraps and passes tests on x86_64-unknown-linux-gnu
against trunk.

libcpp/
* macro.c (_cpp_builtin_macro_text): Honor the
cpp_reader::forced_token_location_p data member to force the value
__LINE__ expands to accordlingly.
(builtin_macro): Use cpp_force_token_locations() to set the
location of the resulting token to that expansion point location.
(enter_macro_context): Pass the expansion point locatoin to
builtin_macro.

gcc/testsuite/
* gcc.dg/cpp/builtin-macro-{0,1,2,3}.c: New test files.

Signed-off-by: Dodji Seketeli 
---
 gcc/testsuite/gcc.dg/cpp/builtin-macro-0.c | 18 ++
 gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c | 30 
 gcc/testsuite/gcc.dg/cpp/builtin-macro-2.c | 28 +++
 gcc/testsuite/gcc.dg/cpp/builtin-macro-3.c | 28 +++
 libcpp/macro.c | 56 +++---
 5 files changed, 148 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/cpp/builtin-macro-0.c
 create mode 100644 gcc/testsuite/gcc.dg/cpp/builtin-macro-1.c
 create mode 100644 gcc/testsuite/gcc.dg/cpp/builtin-macro-2.c
 create mode 100644 gcc/testsuite/gcc.dg/cpp/builtin-macro-3.c

diff --git a/gcc/testsuite/gcc.dg/cpp/builtin-macro-0.c 
b/gcc/testsuite/gcc.dg/cpp/builtin-macro-0.c
new file mode 100644
index 000..f57dd5b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cpp/builtin-macro-0.c
@@ -0,0 +1,18 @@
+/* Origin: PR preprocessor/61817
+
+  In this test ca

[PATCH] fix hardreg_cprop to honor HARD_REGNO_MODE_OK.

[Ilya Tocar]

Hi,

I've observed SPEC2006 failure on avx512-vlbwdq branch.
It was caused by  hardreg_cprop. In maybe_mode_change it was
assumed, that all values of the same register class and same mode.
are ok. This is not the case for i386/avx512. We need to honor
HARD_REGNO_MODE_OK.
Patch bellow does it.
Ok for trunk?

2014-08-11  Ilya Tocar  

* regcprop.c (maybe_mode_change): Honor HARD_REGNO_MODE_OK.


---
 gcc/regcprop.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/regcprop.c b/gcc/regcprop.c
index 932037d..694deb2 100644
--- a/gcc/regcprop.c
+++ b/gcc/regcprop.c
@@ -410,7 +410,7 @@ maybe_mode_change (enum machine_mode orig_mode, enum 
machine_mode copy_mode,
   && GET_MODE_SIZE (copy_mode) < GET_MODE_SIZE (new_mode))
 return NULL_RTX;
 
-  if (orig_mode == new_mode)
+  if (orig_mode == new_mode && HARD_REGNO_MODE_OK (regno, new_mode))
 return gen_rtx_raw_REG (new_mode, regno);
   else if (mode_change_ok (orig_mode, new_mode, regno))
 {
-- 
1.8.3.1

Re: [PATCH i386 AVX512] [4/n] Add new way of generating all 0/1 vector.

[Kirill Yukhin]

On 11 Aug 13:51, Jakub Jelinek wrote:
> On Mon, Aug 11, 2014 at 03:47:07PM +0400, Kirill Yukhin wrote:
> > @@ -9020,7 +9025,8 @@ standard_sse_constant_opcode (rtx insn, rtx x)
> > }
> >  
> >  case 2:
> > -  if (get_attr_mode (insn) == MODE_XI
> > +  if (TARGET_AVX512VL
> > + ||get_attr_mode (insn) == MODE_XI
> 
> Formatting, add space after ||.
Fixed.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index f12e1c4..c77e8a6 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -8997,19 +8997,24 @@ standard_sse_constant_opcode (rtx insn, rtx x)
   switch (get_attr_mode (insn))
{
case MODE_XI:
-   case MODE_V16SF:
  return "vpxord\t%g0, %g0, %g0";
+   case MODE_V16SF:
+ return TARGET_AVX512DQ ? "vxorps\t%g0, %g0, %g0"
+: "vpxord\t%g0, %g0, %g0";
case MODE_V8DF:
- return "vpxorq\t%g0, %g0, %g0";
+ return TARGET_AVX512DQ ? "vxorpd\t%g0, %g0, %g0"
+: "vpxorq\t%g0, %g0, %g0";
case MODE_TI:
- return "%vpxor\t%0, %d0";
+ return TARGET_AVX512VL ? "vpxord\t%t0, %t0, %t0"
+: "%vpxor\t%0, %d0";
case MODE_V2DF:
  return "%vxorpd\t%0, %d0";
case MODE_V4SF:
  return "%vxorps\t%0, %d0";
 
case MODE_OI:
- return "vpxor\t%x0, %x0, %x0";
+ return TARGET_AVX512VL ? "vpxord\t%x0, %x0, %x0"
+: "vpxor\t%x0, %x0, %x0";
case MODE_V4DF:
  return "vxorpd\t%x0, %x0, %x0";
case MODE_V8SF:
@@ -9020,7 +9025,8 @@ standard_sse_constant_opcode (rtx insn, rtx x)
}
 
 case 2:
-  if (get_attr_mode (insn) == MODE_XI
+  if (TARGET_AVX512VL
+ || get_attr_mode (insn) == MODE_XI
  || get_attr_mode (insn) == MODE_V8DF
  || get_attr_mode (insn) == MODE_V16SF)
return "vpternlogd\t{$0xFF, %g0, %g0, %g0|%g0, %g0, %g0, 0xFF}";

Re: [PATCH] Fix incorrect folding of bitfield in a union on big endian target

[Richard Biener]

On Mon, Aug 11, 2014 at 9:36 AM, Thomas Preud'homme
 wrote:
> In the code dealing with folding of structure and union initialization, there 
> is a
> check that the size of the constructor is the same as the field being read.
> However, in the case of bitfield this test can be wrong because it relies on
> TYPE_SIZE to get the size of the field being read but TYPE_SIZE returns the
> size of the enclosing integer in that case. This patch also check the size
> parameter which contains the actual size of the field being read.
>
> The patch was tested by running the testsuite with three different builds of 
> GCC:
> 1) bootstrap of GCC on x86_64-linux-gnu
> 2) arm-none-eabi cross compiler (defaulting to little endian) with testsuite
> run under qemu emulqting a Cortex M4
> 3) arm-none-eabi cross compiler (defaulting to big endian, thanks to patch at 
> [1])
> with testsuite run under qemu emulating a Cortex M3.
>
> [1] https://sourceware.org/ml/binutils/2014-08/msg00014.html
>
> No regression were observed on any of the tests. The ChangeLog is as follows:
>
>
> 2014-08-11  Thomas Preud'homme  
>
> * gimple-fold.c (fold_ctor_reference): Don't fold in presence of
> bitfields, that is when size doesn't match the size of type or the
> size of the constructor.
>
>
> diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
> index 3dcb576..6270c34 100644
> --- a/gcc/gimple-fold.c
> +++ b/gcc/gimple-fold.c
> @@ -3099,7 +3099,9 @@ fold_ctor_reference (tree type, tree ctor, unsigned 
> HOST_WIDE_INT offset,
>if (!AGGREGATE_TYPE_P (TREE_TYPE (ctor)) && !offset
>/* VIEW_CONVERT_EXPR is defined only for matching sizes.  */
>&& operand_equal_p (TYPE_SIZE (type),
> - TYPE_SIZE (TREE_TYPE (ctor)), 0))
> + TYPE_SIZE (TREE_TYPE (ctor)), 0)
> +  && !compare_tree_int (TYPE_SIZE (type), size)
> +  && !compare_tree_int (TYPE_SIZE (TREE_TYPE (ctor)), size))

That's now extra compares (the operand_equal_p check now does
a check that can be derived transitively).

So - ok with the operand_equal_p cehck removed.

Also see if this can be backported.

Thanks,
Richard.

>  {
>ret = canonicalize_constructor_val (unshare_expr (ctor), from_decl);
>ret = fold_unary (VIEW_CONVERT_EXPR, type, ret);
> diff --git a/gcc/testsuite/gcc.c-torture/execute/bitfld-6.c 
> b/gcc/testsuite/gcc.c-torture/execute/bitfld-6.c
> new file mode 100644
> index 000..50927dc
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/execute/bitfld-6.c
> @@ -0,0 +1,23 @@
> +union U
> +{
> +  const int a;
> +  unsigned b : 20;
> +};
> +
> +static union U u = { 0x12345678 };
> +
> +/* Constant folding used to fail to account for endianness when folding a
> +   union.  */
> +
> +int
> +main (void)
> +{
> +#ifdef __BYTE_ORDER__
> +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
> +  return u.b - 0x45678;
> +#else
> +  return u.b - 0x12345;
> +#endif
> +#endif
> +  return 0;
> +}
>
> Is it ok for trunk?
>
> Best regards,
>
> Thomas
>
>

Re: [PATCH i386 AVX512] [4/n] Add new way of generating all 0/1 vector.

[Jakub Jelinek]

On Mon, Aug 11, 2014 at 03:47:07PM +0400, Kirill Yukhin wrote:
> @@ -9020,7 +9025,8 @@ standard_sse_constant_opcode (rtx insn, rtx x)
>   }
>  
>  case 2:
> -  if (get_attr_mode (insn) == MODE_XI
> +  if (TARGET_AVX512VL
> +   ||get_attr_mode (insn) == MODE_XI

Formatting, add space after ||.

Jakub

[PATCH i386 AVX512] [4/n] Add new way of generating all 0/1 vector.

[Kirill Yukhin]

Hello,

This patch introduces new way of generating all-0 and all-1
vectors.

Boostrapped.

Is it ok for trunk?

gcc/
* config/i386/i386.c (standard_sse_constant_opcode): Use 
vpxord/vpternlog
if avx512 is availible.

--
Thanks, K

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 08fb9b5..5a00963 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -8997,19 +8997,24 @@ standard_sse_constant_opcode (rtx insn, rtx x)
   switch (get_attr_mode (insn))
{
case MODE_XI:
-   case MODE_V16SF:
  return "vpxord\t%g0, %g0, %g0";
+   case MODE_V16SF:
+ return TARGET_AVX512DQ ? "vxorps\t%g0, %g0, %g0"
+: "vpxord\t%g0, %g0, %g0";
case MODE_V8DF:
- return "vpxorq\t%g0, %g0, %g0";
+ return TARGET_AVX512DQ ? "vxorpd\t%g0, %g0, %g0"
+: "vpxorq\t%g0, %g0, %g0";
case MODE_TI:
- return "%vpxor\t%0, %d0";
+ return TARGET_AVX512VL ? "vpxord\t%t0, %t0, %t0"
+: "%vpxor\t%0, %d0";
case MODE_V2DF:
  return "%vxorpd\t%0, %d0";
case MODE_V4SF:
  return "%vxorps\t%0, %d0";
 
case MODE_OI:
- return "vpxor\t%x0, %x0, %x0";
+ return TARGET_AVX512VL ? "vpxord\t%x0, %x0, %x0"
+: "vpxor\t%x0, %x0, %x0";
case MODE_V4DF:
  return "vxorpd\t%x0, %x0, %x0";
case MODE_V8SF:
@@ -9020,7 +9025,8 @@ standard_sse_constant_opcode (rtx insn, rtx x)
}
 
 case 2:
-  if (get_attr_mode (insn) == MODE_XI
+  if (TARGET_AVX512VL
+ ||get_attr_mode (insn) == MODE_XI
  || get_attr_mode (insn) == MODE_V8DF
  || get_attr_mode (insn) == MODE_V16SF)
return "vpternlogd\t{$0xFF, %g0, %g0, %g0|%g0, %g0, %g0, 0xFF}";

Re: [PATCH] Fix incorrect folding of bitfield in a union on big endian target

[Mikael Pettersson]

Thomas Preud'homme writes:
 > In the code dealing with folding of structure and union initialization, 
 > there is a
 > check that the size of the constructor is the same as the field being read.
 > However, in the case of bitfield this test can be wrong because it relies on
 > TYPE_SIZE to get the size of the field being read but TYPE_SIZE returns the
 > size of the enclosing integer in that case. This patch also check the size
 > parameter which contains the actual size of the field being read.
 > 
 > The patch was tested by running the testsuite with three different builds of 
 > GCC:
 > 1) bootstrap of GCC on x86_64-linux-gnu
 > 2) arm-none-eabi cross compiler (defaulting to little endian) with testsuite
 > run under qemu emulqting a Cortex M4
 > 3) arm-none-eabi cross compiler (defaulting to big endian, thanks to patch 
 > at [1])
 > with testsuite run under qemu emulating a Cortex M3.
 > 
 > [1] https://sourceware.org/ml/binutils/2014-08/msg00014.html
 > 
 > No regression were observed on any of the tests. The ChangeLog is as follows:
 > 
 > 
 > 2014-08-11  Thomas Preud'homme  
 > 
 >  * gimple-fold.c (fold_ctor_reference): Don't fold in presence of
 >  bitfields, that is when size doesn't match the size of type or the
 >  size of the constructor.
 > 
 > 
 > diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
 > index 3dcb576..6270c34 100644
 > --- a/gcc/gimple-fold.c
 > +++ b/gcc/gimple-fold.c
 > @@ -3099,7 +3099,9 @@ fold_ctor_reference (tree type, tree ctor, unsigned 
 > HOST_WIDE_INT offset,
 >if (!AGGREGATE_TYPE_P (TREE_TYPE (ctor)) && !offset
 >/* VIEW_CONVERT_EXPR is defined only for matching sizes.  */
 >&& operand_equal_p (TYPE_SIZE (type),
 > -  TYPE_SIZE (TREE_TYPE (ctor)), 0))
 > +  TYPE_SIZE (TREE_TYPE (ctor)), 0)
 > +  && !compare_tree_int (TYPE_SIZE (type), size)
 > +  && !compare_tree_int (TYPE_SIZE (TREE_TYPE (ctor)), size))
 >  {
 >ret = canonicalize_constructor_val (unshare_expr (ctor), from_decl);
 >ret = fold_unary (VIEW_CONVERT_EXPR, type, ret);
 > diff --git a/gcc/testsuite/gcc.c-torture/execute/bitfld-6.c 
 > b/gcc/testsuite/gcc.c-torture/execute/bitfld-6.c
 > new file mode 100644
 > index 000..50927dc
 > --- /dev/null
 > +++ b/gcc/testsuite/gcc.c-torture/execute/bitfld-6.c
 > @@ -0,0 +1,23 @@
 > +union U
 > +{
 > +  const int a;
 > +  unsigned b : 20;
 > +};
 > +
 > +static union U u = { 0x12345678 };
 > +
 > +/* Constant folding used to fail to account for endianness when folding a
 > +   union.  */
 > +
 > +int
 > +main (void)
 > +{
 > +#ifdef __BYTE_ORDER__
 > +#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
 > +  return u.b - 0x45678;
 > +#else
 > +  return u.b - 0x12345;
 > +#endif
 > +#endif
 > +  return 0;
 > +}
 > 
 > Is it ok for trunk?
 > 
 > Best regards,
 > 
 > Thomas
 > 

This test case also fails on powerpc64 (BE not LE), sparc64, and m68k,
with all current gcc branches (4.10, 4.9, 4.8).  On my powerpc64 box
the failure started with gcc-4.6; gcc-4.5 back to gcc-3.4.6 seem Ok.

Perhaps give this a proper PR and consider backporting?

/Mikael

Re: [PATCH] Fix for PR62037

[Richard Biener]

On Sat, Aug 9, 2014 at 6:28 AM, Felix Yang  wrote:
> Attached please find the patch and testcase for PR62037.
>
> DEF1 can be a GIMPLE_NOP and gimple_bb will be NULL then. The patch
> checks for that.
> Bootstrapped on x86_64-suse-linux. OK for trunk? Please commit this
> patch if it's OK.
>

Thanks - applied.

Richard.

> Index: gcc/ChangeLog
> ===
> --- gcc/ChangeLog(revision 213772)
> +++ gcc/ChangeLog(working copy)
> @@ -1,3 +1,9 @@
> +2014-08-09  Felix Yang  
> +
> +PR tree-optimization/62073
> +* tree-vect-loop.c (vect_is_simple_reduction_1): Check that DEF1 has
> +a basic block.
> +
>  2014-08-08  Guozhi Wei  
>
>  * config/rs6000/rs6000.md (*movdi_internal64): Add a new constraint.
> Index: gcc/testsuite/gcc.dg/vect/pr62073.c
> ===
> --- gcc/testsuite/gcc.dg/vect/pr62073.c(revision 0)
> +++ gcc/testsuite/gcc.dg/vect/pr62073.c(revision 0)
> @@ -0,0 +1,41 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O1 -ftree-vectorize" } */
> +
> +struct S0
> +{
> +int f7;
> +};
> +struct S0 g_50;
> +int g_70;
> +int g_76;
> +
> +
> +int foo (long long p_56, int * p_57)
> +{
> +int *l_77;
> +int l_101;
> +
> +for (; g_70;)
> +{
> +int **l_78 = &l_77;
> +if (g_50.f7)
> +continue;
> +*l_78 = 0;
> +}
> +for (g_76 = 1; g_76 >= 0; g_76--)
> +{
> +int *l_90;
> +for (l_101 = 4; l_101 >= 0; l_101--)
> +if (l_101)
> +*l_90 = 0;
> +else
> +{
> +int **l_113 = &l_77;
> +*l_113 = p_57;
> +}
> +}
> +
> +return *l_77;
> +}
> +
> +/* { dg-final { cleanup-tree-dump "vect" } } */
> Index: gcc/testsuite/ChangeLog
> ===
> --- gcc/testsuite/ChangeLog(revision 213772)
> +++ gcc/testsuite/ChangeLog(working copy)
> @@ -1,3 +1,8 @@
> +2014-08-09  Felix Yang  
> +
> +PR tree-optimization/62073
> +* gcc.dg/vect/pr62073.c: New test.
> +
>  2014-08-08  Richard Biener  
>
>  * gcc.dg/strlenopt-8.c: Remove XFAIL.
> Index: gcc/tree-vect-loop.c
> ===
> --- gcc/tree-vect-loop.c(revision 213772)
> +++ gcc/tree-vect-loop.c(working copy)
> @@ -2321,7 +2321,8 @@ vect_is_simple_reduction_1 (loop_vec_info loop_inf
>  }
>
>def1 = SSA_NAME_DEF_STMT (op1);
> -  if (flow_bb_inside_loop_p (loop, gimple_bb (def_stmt))
> +  if (gimple_bb (def1)
> +  && flow_bb_inside_loop_p (loop, gimple_bb (def_stmt))
>&& loop->inner
>&& flow_bb_inside_loop_p (loop->inner, gimple_bb (def1))
>&& is_gimple_assign (def1))
>
>
> Cheers,
> Felix

Re: [PATCH, ARM] Keep constants in register when expanding

[Ramana Radhakrishnan]

On Mon, Aug 11, 2014 at 3:35 AM, Zhenqiang Chen
 wrote:
> On 8 August 2014 23:22, Ramana Radhakrishnan  
> wrote:
>> On Tue, Aug 5, 2014 at 10:31 AM, Zhenqiang Chen
>>  wrote:
>>> Hi,
>>>
>>> For some large constants, ARM will split them during expanding, which
>>> makes impossible to hoist them out the loop or shared by different
>>> references (refer the test case in the patch).
>>>
>>> The patch keeps some constants in registers. If the constant can not
>>> be optimized, the cprop and combine passes can optimize them as what
>>> we do in current expand pass with
>>>
>>> define_insn_and_split "*arm_subsi3_insn"
>>> define_insn_and_split "*arm_andsi3_insn"
>>> define_insn_and_split "*iorsi3_insn"
>>> define_insn_and_split "*arm_xorsi3"
>>>
>>> The patch does not modify addsi3 since the define_insn_and_split
>>> "*arm_addsi3" is only valid when (reload_completed ||
>>> !arm_eliminable_register (operands[1])). The cprop and combine passes
>>> can not optimize the large constant if we put it in register, which
>>> will lead to regression.
>>>
>>> For logic operators, the patch skips changes for constants:
>>>
>>> INTVAL (operands[2]) < 0 && const_ok_for_arm (-INTVAL (operands[2])
>>>
>>> since expand pass always uses "sign-extend" to get the value
>>> (trunc_int_for_mode called from immed_wide_int_const) for rtl, and
>>> logs show most negative values are UNSIGNED when they are TREE node.
>>> And combine pass is smart enough to recover the negative value to
>>> positive value.
>>
>> I am unable to verify any change in code generation for this testcase
>> with and without the patch when I had a play with the patch.
>>
>> what gives ?
>
> Thanks for trying the patch.
>
> Do you add option -fno-gcse which is mentioned in dg-options " -O2
> -fno-gcse "? Without it, there is no change for the testcase since
> cprop pass will propagate the constant to AND expr (A patch to enhance
> cprop pass was discussed at
> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01321.html).

Probably not and I can now see the difference in code generated for
Thumb state. Why is it that in ARM state with -mcpu=cortex-a15 we see
the hoisting of the constant without your patch with -fno-gcse ?

So, the patch improves code generation for -mcpu=cortex-a15 -mthumb
-fno-gcse for the given testcase ?

>
> In addition, if the constant can not be hoisted out the loop, later
> combine pass can also optimize it. These (cprop and combine) are
> reasons why the patch itself has little impact on current tests.

Does this mean you need the referred to patch to be useful as a
pre-requisite ? I fail to  understand why this patch needs to go in if
it makes no difference without disabling GCSE. I cannot see -fno-gcse
being used by default for performant code.


regards
Ramana

[PATCH] Fix PR62070

[Richard Biener]

The following finally removes the SSA checking code from the
gimple_duplicate_loop_to_header_edge CFG hook.  We've tamed
it down previously and now there is predictive commoning that
also doesn't get the chance to complete its work before that
checking runs.

Applied as obvious.

Richard.

2014-08-11  Richard Biener  

PR tree-optimization/62070
* tree-ssa-loop-manip.c (gimple_duplicate_loop_to_header_edge):
Remove SSA checking.

* gcc.dg/pr62070.c: New testcase.

Index: gcc/tree-ssa-loop-manip.c
===
--- gcc/tree-ssa-loop-manip.c   (revision 213809)
+++ gcc/tree-ssa-loop-manip.c   (working copy)
@@ -761,17 +766,6 @@ gimple_duplicate_loop_to_header_edge (st
   if (!loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS))
 return false;
 
-#ifdef ENABLE_CHECKING
-  /* ???  This forces needless update_ssa calls after processing each
- loop instead of just once after processing all loops.  We should
- instead verify that loop-closed SSA form is up-to-date for LOOP
- only (and possibly SSA form).  For now just skip verifying if
- there are to-be renamed variables.  */
-  if (!need_ssa_update_p (cfun)
-  && loops_state_satisfies_p (LOOP_CLOSED_SSA))
-verify_loop_closed_ssa (true);
-#endif
-
   first_new_block = last_basic_block_for_fn (cfun);
   if (!duplicate_loop_to_header_edge (loop, e, ndupl, wont_exit,
  orig, to_remove, flags))
Index: gcc/testsuite/gcc.dg/pr62070.c
===
--- gcc/testsuite/gcc.dg/pr62070.c  (revision 0)
+++ gcc/testsuite/gcc.dg/pr62070.c  (working copy)
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fno-tree-vectorize" } */
+
+int in[8][4];
+int out[4];
+
+void
+foo (void)
+{
+  int sum = 1;
+  int i, j, k;
+  for (k = 0; k < 4; k++)
+{
+  for (j = 0; j < 4; j++)
+   for (i = 0; i < 4; i++)
+ sum *= in[i + k][j];
+  out[k] = sum;
+}
+}

Re: [PATCH, ARM] Fix incorrect alignment of small values in minipool

[Richard Earnshaw]

On 11/08/14 09:53, Richard Earnshaw wrote:
> On 11/08/14 08:49, Thomas Preud'homme wrote:
>> Being 32-bit wide in size, constant pool entries are always filled as 32-bit
>> quantities. This works fine for little endian system but gives some incorrect
>> results for big endian system when the value is *accessed* with a mode 
>> smaller
>> than 32-bit in size. Suppose the case of the value 0x1234 that is accessed 
>> as an
>> HImode value. It would be output as 0x0 0x0 0x12 0x34 in a constant pool 
>> entry
>> and the 16-bit load that would be done would lead to the value 0x0 in 
>> register.
>> The approach here is to transform the value so that it is output correctly by
>> shifting the value left so that the highest byte in its mode ends up in the
>> highest byte of the 32-bit value being output.
>>
>> The patch was tested by running the testsuite with three different builds of 
>> GCC:
>> 1) bootstrap of GCC on x86_64-linux-gnu
>> 2) arm-none-eabi cross compiler (defaulting to little endian) with testsuite
>> run under qemu emulqting a Cortex M4
>> 3) arm-none-eabi cross compiler (defaulting to big endian, thanks to patch 
>> at [1])
>> with testsuite run under qemu emulating a Cortex M3. Due to the processor 
>> used,
>> the test constant-minipool was not run as part of the testsuite but manually 
>> with
>> -cpu=cortex-r4
>>
>> [1] https://sourceware.org/ml/binutils/2014-08/msg00014.html
>>
>> The ChangeLog is as follows:
>>
>> *** gcc/ChangeLog ***
>>
>> 2014-07-14  Thomas Preud'homme  
>>
>>  * config/arm/arm.c (dump_minipool): Fix alignment in minipool of
>>  values whose size is less than MINIPOOL_FIX_SIZE on big endian target.
>>
> 
> I think this is the wrong place for this sort of fix up.  HFmode values
> are fixed up in the consttable_4 pattern and it looks wrong to be that
> HImode values are then fixed up in a different place.  We should be
> consistent and do all the fix ups in one location.
> 

BTW, this is PR59593, please can you cite that in your change log entry.

R.

> R.
> 
> 
>> *** gcc/testsuite/ChangeLog ***
>>
>> 2014-07-14  Thomas Preud'homme  
>>
>>  * gcc.target/arm/constant-pool.c: New test.
>>
>>
>> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
>> index 0146fe8..e4e0ef4 100644
>> --- a/gcc/config/arm/arm.c
>> +++ b/gcc/config/arm/arm.c
>> @@ -16507,6 +16507,15 @@ dump_minipool (rtx scan)
>>fputc ('\n', dump_file);
>>  }
>>  
>> +  /* On big-endian target, make sure that padding for values whose
>> + mode size is smaller than MINIPOOL_FIX_SIZE comes after.  */
>> +  if (BYTES_BIG_ENDIAN && CONST_INT_P (mp->value))
>> +{
>> +  int byte_disp = mp->fix_size - GET_MODE_SIZE (mp->mode);
>> +  HOST_WIDE_INT val = INTVAL (mp->value);
>> +  mp->value = GEN_INT (val << (byte_disp * BITS_PER_UNIT));
>> +}
>> +
>>switch (mp->fix_size)
>>  {
>>  #ifdef HAVE_consttable_1
>> diff --git a/gcc/testsuite/gcc.target/arm/constant-pool.c 
>> b/gcc/testsuite/gcc.target/arm/constant-pool.c
>> new file mode 100644
>> index 000..46a1534
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/arm/constant-pool.c
>> @@ -0,0 +1,28 @@
>> +/* { dg-do compile } */
>> +/* { dg-require-effective-target arm_arm_ok } */
>> +/* { dg-options "-O1 -marm -mbig-endian" } */
>> +
>> +unsigned short v = 0x5678;
>> +int i;
>> +int j = 0;
>> +int *ptr = &j;
>> +
>> +int
>> +func (void)
>> +{
>> +  for (i = 0; i < 1; ++i)
>> +{
>> +  *ptr = -1;
>> +  v = 0x1234;
>> +}
>> +  return v;
>> +}
>> +
>> +int
>> +main (void)
>> +{
>> +  func ();
>> +  return v - 0x1234;
>> +}
>> +
>> +/* { dg-final { scan-assembler-not ".word 4660" } } */
>>
>>
>> Is this ok for trunk?
>>
>> Best regards,
>>
>> Thomas
>>
>>
>>
> 
> 
> 

Re: [PATCH] Demangler fuzzer

[Jakub Jelinek]

On Mon, Aug 11, 2014 at 10:27:03AM +0100, Gary Benson wrote:
> This patch adds a simple fuzzer for the libiberty C++ demangler.
> You can run it like this:
> 
>   make -C /path/to/build/libiberty/testsuite fuzz-demangler
> 
> It will run until it dumps core (usually only a few seconds).
> 
> Is this ok to commit?

I think it is bad when the command never succeeds in case of success.
There should be some limit on the number of iterations (perhaps a parameter
to the program), or timeout.

> +  for (i = 0; i < length; i++)
> + *(buffer++) = (rand () % (ALPMAX - ALPMIN)) + ALPMIN;
> +
> +  *(buffer++) = '\0';

Please use just *buffer++ instead of *(buffer++) in both places.

Jakub

[PING ^ 2] [PATCH, ARM] Set max_insns_skipped to MAX_INSN_PER_IT_BLOCK when optimize_size for THUMB2

[Zhenqiang Chen]

Ping ^ 2?

Thanks!
-Zhenqiang

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Zhenqiang Chen
> Sent: Tuesday, April 29, 2014 5:38 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Ramana Radhakrishnan
> Subject: [PING] [PATCH, ARM] Set max_insns_skipped to
> MAX_INSN_PER_IT_BLOCK when optimize_size for THUMB2
> 
> Ping? OK for trunk?
> 
> Thanks!
> -Zhenqiang
> 
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Zhenqiang Chen
> > Sent: Tuesday, February 25, 2014 5:35 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Ramana Radhakrishnan
> > Subject: [PATCH, ARM] Set max_insns_skipped to
> MAX_INSN_PER_IT_BLOCK
> > when optimize_size for THUMB2
> >
> > Hi,
> >
> > Current value for max_insns_skipped is 6. For THUMB2, it needs 2
> > (IF-THEN) or 3 (IF-THEN-ELSE) IT blocks to hold all the instructions.
> > The overhead
> of IT is
> > 4 or 6 BYTES.
> >
> > If we do not generate IT blocks, for IF-THEN, the overhead of
> > conditional jump is 2 or 4; for IF-THEN-ELSE, the overhead is 4, 6, or
8.
> >
> > Most THUMB2 jump instructions are 2 BYTES. Tests on CSiBE show no one
> > file has code size regression. So The patch sets max_insns_skipped to
> > MAX_INSN_PER_IT_BLOCK.
> >
> > No make check regression on cortex-m3.
> > For CSiBE, no any file has code size regression. And overall there is
> >0.01%  code size improvement for cortex-a9 and cortex-m4.
> >
> > Is it OK?
> >
> > Thanks!
> > -Zhenqiang
> >
> > 2014-02-25  Zhenqiang Chen  
> >
> > * config/arm/arm.c (arm_option_override): Set max_insns_skipped
> > to MAX_INSN_PER_IT_BLOCK when optimize_size for THUMB2.
> >
> > testsuite/ChangeLog:
> > 2014-02-25  Zhenqiang Chen  
> >
> > * gcc.target/arm/max-insns-skipped.c: New test.
> >
> > diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index
> > b49f43e..99cdbc4 100644
> > --- a/gcc/config/arm/arm.c
> > +++ b/gcc/config/arm/arm.c
> > @@ -2743,6 +2743,15 @@ arm_option_override (void)
> >/* If optimizing for size, bump the number of instructions that
we
> >   are prepared to conditionally execute (even on a StrongARM).
*/
> >max_insns_skipped = 6;
> > +
> > +  /* For THUMB2, it needs 2 (IF-THEN) or 3 (IF-THEN-ELSE) IT
> > + blocks
> to
> > +hold all the instructions. The overhead of IT is 4 or 6 BYTES.
> > +If we do not generate IT blocks, for IF-THEN, the overhead of
> > +conditional jump is 2 or 4; for IF-THEN-ELSE, the overhead is 4, 6
> > +or 8.  Most THUMB2 jump instructions are 2 BYTES.
> > +So set max_insns_skipped to MAX_INSN_PER_IT_BLOCK.  */
> > +  if (TARGET_THUMB2)
> > +   max_insns_skipped = MAX_INSN_PER_IT_BLOCK;
> >  }
> >else
> >  max_insns_skipped = current_tune->max_insns_skipped; diff --git
> > a/gcc/testsuite/gcc.target/arm/max-insns-skipped.c
> > b/gcc/testsuite/gcc.target/arm/max-insns-skipped.c
> > new file mode 100644
> > index 000..0a11554
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/arm/max-insns-skipped.c
> > @@ -0,0 +1,21 @@
> > +/* { dg-do assemble { target arm_thumb2 } } */
> > +/* { dg-options " -Os " } */
> > +
> > +int t (int a, int b, int c, int d)
> > +{
> > +  int r;
> > +  if (a > 0) {
> > +r = a + b;
> > +r += 0x456;
> > +r *= 0x1234567;
> > +}
> > +  else {
> > +r = b - a;
> > +r -= 0x123;
> > +r *= 0x12387;
> > +r += d;
> > +   }
> > +  return r;
> > +}
> > +
> > +/* { dg-final { object-size text <= 40 } } */
> >
> >
> >
> 
> 
> 
> 

[C++ Patch] Mini parser->scope related clean up

[Paolo Carlini]

Hi,

I noticed that we can remove the scope parameter from two parser 
functions. Tested x86_64-linux.


Thanks,
Paolo.


2014-08-11  Paolo Carlini  

* parser.c (cp_parser_diagnose_invalid_type_name,
cp_parser_make_typename_type): Remove scope parameter.
(cp_parser_parse_and_diagnose_invalid_type_name,
cp_parser_elaborated_type_specifier): Adjust calls.

Index: parser.c
===
--- parser.c(revision 213809)
+++ parser.c(working copy)
@@ -2454,7 +2454,7 @@ static void cp_parser_check_for_invalid_template_i
 static bool cp_parser_non_integral_constant_expression
   (cp_parser *, non_integral_constant);
 static void cp_parser_diagnose_invalid_type_name
-  (cp_parser *, tree, tree, location_t);
+  (cp_parser *, tree, location_t);
 static bool cp_parser_parse_and_diagnose_invalid_type_name
   (cp_parser *);
 static int cp_parser_skip_to_closing_parenthesis
@@ -2482,7 +2482,7 @@ static bool cp_parser_is_string_literal
 static bool cp_parser_is_keyword
   (cp_token *, enum rid);
 static tree cp_parser_make_typename_type
-  (cp_parser *, tree, tree, location_t location);
+  (cp_parser *, tree, location_t location);
 static cp_declarator * cp_parser_make_indirect_declarator
   (enum tree_code, tree, cp_cv_quals, cp_declarator *, tree);
 static bool cp_parser_compound_literal_p
@@ -2881,28 +2881,23 @@ cp_parser_non_integral_constant_expression (cp_par
   return false;
 }
 
-/* Emit a diagnostic for an invalid type name.  SCOPE is the
-   qualifying scope (or NULL, if none) for ID.  This function commits
+/* Emit a diagnostic for an invalid type name.  This function commits
to the current active tentative parse, if any.  (Otherwise, the
problematic construct might be encountered again later, resulting
in duplicate error messages.) LOCATION is the location of ID.  */
 
 static void
-cp_parser_diagnose_invalid_type_name (cp_parser *parser,
- tree scope, tree id,
+cp_parser_diagnose_invalid_type_name (cp_parser *parser, tree id,
  location_t location)
 {
-  tree decl, old_scope, ambiguous_decls;
+  tree decl, ambiguous_decls;
   cp_parser_commit_to_tentative_parse (parser);
   /* Try to lookup the identifier.  */
-  old_scope = parser->scope;
-  parser->scope = scope;
   decl = cp_parser_lookup_name (parser, id, none_type,
/*is_template=*/false,
/*is_namespace=*/false,
/*check_dependency=*/true,
&ambiguous_decls, location);
-  parser->scope = old_scope;
   if (ambiguous_decls)
 /* If the lookup was ambiguous, an error will already have
been issued.  */
@@ -3063,8 +3058,7 @@ cp_parser_parse_and_diagnose_invalid_type_name (cp
 return false;
 
   /* Emit a diagnostic for the invalid type.  */
-  cp_parser_diagnose_invalid_type_name (parser, parser->scope,
-   id, token->location);
+  cp_parser_diagnose_invalid_type_name (parser, id, token->location);
  out:
   /* If we aren't in the middle of a declarator (i.e. in a
  parameter-declaration-clause), skip to the end of the declaration;
@@ -3376,19 +3370,19 @@ cp_parser_require_pragma_eol (cp_parser *parser, c
using cp_parser_diagnose_invalid_type_name.  */
 
 static tree
-cp_parser_make_typename_type (cp_parser *parser, tree scope,
- tree id, location_t id_location)
+cp_parser_make_typename_type (cp_parser *parser, tree id,
+ location_t id_location)
 {
   tree result;
   if (identifier_p (id))
 {
-  result = make_typename_type (scope, id, typename_type,
+  result = make_typename_type (parser->scope, id, typename_type,
   /*complain=*/tf_none);
   if (result == error_mark_node)
-   cp_parser_diagnose_invalid_type_name (parser, scope, id, id_location);
+   cp_parser_diagnose_invalid_type_name (parser, id, id_location);
   return result;
 }
-  return make_typename_type (scope, id, typename_type, tf_error);
+  return make_typename_type (parser->scope, id, typename_type, tf_error);
 }
 
 /* This is a wrapper around the
@@ -15227,8 +15227,7 @@ cp_parser_elaborated_type_specifier (cp_parser* pa
   /* For a `typename', we needn't call xref_tag.  */
   if (tag_type == typename_type
  && TREE_CODE (parser->scope) != NAMESPACE_DECL)
-   return cp_parser_make_typename_type (parser, parser->scope,
-identifier,
+   return cp_parser_make_typename_type (parser, identifier,
 token->location);
 
   /* Template parameter lists apply only if we are not within a
@@ -15289,7 +15288,6 @@ cp_parser_elaborated_type_specifier (cp_parser* pa
  if (TREE_CODE (decl) != 

[PATCH] Demangler fuzzer

[Gary Benson]

Hi all,

This patch adds a simple fuzzer for the libiberty C++ demangler.
You can run it like this:

  make -C /path/to/build/libiberty/testsuite fuzz-demangler

It will run until it dumps core (usually only a few seconds).

Is this ok to commit?

Thanks,
Gary

-- 
2014-08-11  Gary Benson  

* testsuite/demangler-fuzzer.c: New file.
* testsuite/Makefile.in (fuzz-demangler): New rule.
(demangler-fuzzer): Likewise.
(mostlyclean): Clean up demangler fuzzer.

Index: libiberty/testsuite/Makefile.in
===
--- libiberty/testsuite/Makefile.in (revision 213809)
+++ libiberty/testsuite/Makefile.in (working copy)
@@ -59,6 +59,10 @@
 check-expandargv: test-expandargv
./test-expandargv
 
+# Run the demangler fuzzer
+fuzz-demangler: demangler-fuzzer
+   ./demangler-fuzzer
+
 TEST_COMPILE = $(CC) @DEFS@ $(LIBCFLAGS) -I.. -I$(INCDIR) $(HDEFINES)
 test-demangle: $(srcdir)/test-demangle.c ../libiberty.a
$(TEST_COMPILE) -o test-demangle \
@@ -72,6 +76,10 @@
$(TEST_COMPILE) -DHAVE_CONFIG_H -I.. -o test-expandargv \
$(srcdir)/test-expandargv.c ../libiberty.a
 
+demangler-fuzzer: $(srcdir)/demangler-fuzzer.c ../libiberty.a
+   $(TEST_COMPILE) -o demangler-fuzzer \
+   $(srcdir)/demangler-fuzzer.c ../libiberty.a
+
 # Standard (either GNU or Cygnus) rules we don't use.
 html install-html info install-info clean-info dvi pdf install-pdf \
 install etags tags installcheck:
@@ -81,6 +89,7 @@
rm -f test-demangle
rm -f test-pexecute
rm -f test-expandargv
+   rm -f demangler-fuzzer
rm -f core
 clean: mostlyclean
 distclean: clean
Index: libiberty/testsuite/demangler-fuzzer.c
===
--- libiberty/testsuite/demangler-fuzzer.c  (revision 0)
+++ libiberty/testsuite/demangler-fuzzer.c  (revision 0)
@@ -0,0 +1,47 @@
+/* Demangler fuzzer.
+
+   Copyright (C) 2014 Free Software Foundation, Inc.
+
+   This file is part of GNU libiberty.
+
+   This program 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 of the License, or
+   (at your option) any later version.
+
+   This program 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 this program.  If not, see .  */
+
+#include 
+#include 
+#include 
+
+#define MAXLEN 253
+#define ALPMIN 33
+#define ALPMAX 127
+
+int
+main (int argc, char *argv[])
+{
+  char symbol[2 + MAXLEN + 1] = "_Z";
+
+  srand (time (NULL));
+  while (1)
+{
+  char *buffer = symbol + 2;
+  int length, i;
+
+  length = rand () % MAXLEN;
+  for (i = 0; i < length; i++)
+   *(buffer++) = (rand () % (ALPMAX - ALPMIN)) + ALPMIN;
+
+  *(buffer++) = '\0';
+
+  cplus_demangle (symbol, DMGL_AUTO | DMGL_ANSI | DMGL_PARAMS);
+}
+}

Re: [PATCH][LTO] Streamer re-org (what's left)

[Richard Biener]

On Thu, 7 Aug 2014, Richard Biener wrote:

> On Thu, 7 Aug 2014, Richard Biener wrote:
> 
> > 
> > The following are the non-cleanup parts.  The patch moves us
> > to compress streams (what data-streamer thinks of "streams")
> > instead of whole sections.  This enables us to only need
> > a single compressed and uncompressed block of data "live"
> > as opposed to a whole section (well, in theory - we still
> > do mmap based I/O).  The disadvantage is that you really
> > have to go through the data-streamer interface to access
> > data at read-in.
> > 
> > As is the patch doesn't improve virtual memory usage a lot
> > (according to Martins tests) but it increases compile-time
> > (we now compress LTRANs streams - reducing their size to 1/3).
> > 
> > What the patch still misses is to re-do the string part
> > of the decl streams to make them compressed again.  It also
> > misses ripping out the section-compression code entirely
> > (lto-compress.c).
> > 
> > Oh, and it misses a ChangeLog.
> > 
> > Now the question is whether we want this or not.  It's certainly
> > not perfect in it's current state.
> > 
> > But I wouldn't want to tie the merge-SCCs-from-disk stuff to
> > the data-streamer internals too much (even if it seems tempting
> > and easy in it's current form).
> > 
> > Any comments appreciated.
> 
> The following is the update I promised on IRC.  It fixes a
> small memory leak from read_string () and should restore
> performance of streamer_read_uhwi.

And this fixes the thinko in zlib use.

du  /tmp/*ltrans* | awk '{ sum += $1 } END { print sum }'
stage3 cc1 WPA ltrans file size 178740 (patched)
stage3 cc1 WPA ltrans file size 460068 (unpatched)

Index: gcc/data-streamer-out.c
===
*** gcc/data-streamer-out.c.orig2014-08-08 14:54:20.592135967 +0200
--- gcc/data-streamer-out.c 2014-08-11 10:31:24.066376554 +0200
*** along with GCC; see the file COPYING3.
*** 22,27 
--- 22,32 
  
  #include "config.h"
  #include "system.h"
+ /* zlib.h includes other system headers.  Those headers may test feature
+test macros.  config.h may define feature test macros.  For this reason,
+zlib.h needs to be included after, rather than before, config.h and
+system.h.  */
+ #include 
  #include "coretypes.h"
  #include "tree.h"
  #include "basic-block.h"
*** along with GCC; see the file COPYING3.
*** 33,79 
  #include "data-streamer.h"
  
  
  /* Adds a new block to output stream OBS.  */
  
  void
! lto_append_block (struct lto_output_stream *obs)
  {
struct lto_char_ptr_base *new_block;
  
!   gcc_assert (obs->left_in_block == 0);
  
!   if (obs->first_block == NULL)
  {
!   /* This is the first time the stream has been written
!into.  */
!   obs->block_size = 1024;
!   new_block = (struct lto_char_ptr_base*) xmalloc (obs->block_size);
!   obs->first_block = new_block;
  }
else
  {
!   struct lto_char_ptr_base *tptr;
!   /* Get a new block that is twice as big as the last block
!and link it into the list.  */
!   obs->block_size *= 2;
!   new_block = (struct lto_char_ptr_base*) xmalloc (obs->block_size);
!   /* The first bytes of the block are reserved as a pointer to
!the next block.  Set the chain of the full block to the
!pointer to the new block.  */
!   tptr = obs->current_block;
!   tptr->ptr = (char *) new_block;
  }
  
/* Set the place for the next char at the first position after the
   chain to the next block.  */
!   obs->current_pointer
  = ((char *) new_block) + sizeof (struct lto_char_ptr_base);
!   obs->current_block = new_block;
/* Null out the newly allocated block's pointer to the next block.  */
new_block->ptr = NULL;
!   obs->left_in_block = obs->block_size - sizeof (struct lto_char_ptr_base);
  }
  
  
  /* Return index used to reference STRING of LEN characters in the string table
 in OB.  The string might or might not include a trailing '\0'.
--- 38,193 
  #include "data-streamer.h"
  
  
+ /* Finishes the last block, eventually compressing it, and returns the
+total size of the stream.  */
+ 
+ unsigned int
+ lto_output_stream::finish ()
+ {
+   if (compress
+   && current_pointer)
+ {
+   /* Compress the last (partial) block.  */
+   compress_current_block (true);
+   left_in_block = zlib_stream->avail_out;
+   free (current_block);
+   current_block = NULL;
+   int status = deflateEnd (zlib_stream);
+   if (status != Z_OK)
+   internal_error ("compressed stream: %s", zError (status));
+   free (zlib_stream);
+ }
+   current_pointer = NULL;
+ 
+   unsigned int size = 0;
+   for (lto_char_ptr_base *b = first_block; b; b = (lto_char_ptr_base *)b->ptr)
+ size += block_size - sizeof (lto_char_ptr_base);
+   size -= left_in_block;
+   return size;
+ }
+ 
+ /* Returns a pointer to the first block 

Re: [PATCH] Keep patch file permissions in mklog

[Tom de Vries]

On 11-08-14 10:18, Yury Gribov wrote:

On 08/11/2014 11:22 AM, Tom de Vries wrote:

I'm now using mktemp from File::Temp.


The script now relies on external Perl modules. This is probably fine because
AFAIK File::Temp and File::Copy are available included in all distributions.

+use File::Copy "cp";
+use File::Copy "mv";

You could trade one line with qw(cp mv)...

+$tmp = mktemp("tmp.") or die "cannot create temp file: $!";

Perhaps "Could not" like in other error messages?

+cp "$diff", "$tmp" or die "Could not copy patch file to temp file: $!";

Script don't quote stuff in other places so quoting here is useless.



Updated according comments and retested.

Thanks again,
- Tom


2014-08-11  Tom de Vries  

	* mklog: Add --inline option.

diff --git a/contrib/mklog b/contrib/mklog
index 3d17dc5..b575b6e 100755
--- a/contrib/mklog
+++ b/contrib/mklog
@@ -26,6 +26,9 @@
 # Author: Diego Novillo  and
 # Cary Coutant 
 
+use File::Temp;
+use File::Copy qw(cp mv);
+
 # Change these settings to reflect your profile.
 $username = $ENV{'USER'};
 $name = `finger $username | grep -o 'Name: .*'`;
@@ -56,14 +59,22 @@ if (-d "$gcc_root/.git") {
 # Program starts here. You should not need to edit anything below this
 # line.
 #-
-if ($#ARGV != 0) {
+$inline = 0;
+if ($#ARGV == 1 && ("$ARGV[0]" eq "-i" || "$ARGV[0]" eq "--inline")) {
+	shift;
+	$inline = 1;
+} elsif ($#ARGV != 0) {
 $prog = `basename $0`; chop ($prog);
 print <', $tmp) or die "Could not open temp file: $!";
+} else {
+	*OUTPUTFILE = STDOUT;
+}
+
+# Print the log
 foreach my $clname (keys %cl_entries) {
-	print "$clname:\n\n$hdrline\n\n$cl_entries{$clname}\n";
+	print OUTPUTFILE "$clname:\n\n$hdrline\n\n$cl_entries{$clname}\n";
+}
+
+if ($inline) {
+	# Append the patch to the log
+	foreach (@diff_lines) {
+		print OUTPUTFILE "$_\n";
+	}
+}
+
+if ($inline && $diff ne "-") {
+	# Close $tmp
+	close(OUTPUTFILE);
+
+	# Write new contents to $diff atomically
+	mv $tmp, $diff or die "Could not move temp file to patch file: $!";
 }
 
 exit 0;
-- 
1.9.1

Re: [PATCH][AArch64][tests]Skip graphite tests that don't fit -mcmodel=tiny

[Richard Earnshaw]

On 08/08/14 18:53, Mike Stump wrote:
> On Aug 7, 2014, at 1:38 AM, Kyrill Tkachov  wrote:
>>
>> Thanks for the detailed explanation, the linker errors I was seeing were 
>> about relocations being truncated.
> 
> Ah, those are bugs in your port!  You should be able to generate large code 
> and then relax it into short small code.  Large code, by definition, will 
> never run into relocs being truncated.  :-)
> 
>> I've extended your patch to catch those as well. With this the tests I was 
>> seeing FAIL now are marked UNSUPPORTED.
> 
>> How is this?
> 
> No.  :-(
> 
> Those are traditionally bugs in gcc that users want gcc to fix.  Paper 
> overing those bugs is the wrong path forward.
> 

Not quite, read the subject line again.

This particular case the user (test) has asserted that the image will
fit in a certain amount of memory; but in fact that turns out to be
false.  This can only be detected at link time when the relocations
overflow - it's by definition impossible to detect during the
compilation phase.

I'm not sure what the correct change to the testsuite is here.  Any test
failures like this are likely to be somewhat target specific.  In the
worst case the optimization level may affect what can be made to fit.
Perhaps the best solution would be something like marking the test as
"large" in some way and for "large" tests the linker would handle
"relocation truncated to fit" errors from the linker through some target
hook that had a better understanding of whether size related options
were being used and could decide between error and unsupported.

R.

> So, a couple of ideas come to mind.  The best, add relation and generate 
> large by default.  Next solution, is to have a linker script that limits 
> memory to the size that the large reloc supports.  If it is 18 bits, then 
> limit memory to 18 bits.  Doesn’t impact normal users as they only have 18 
> bits or less on their system.  Next up, add a -mcmodel=large and make it the 
> default and have people that want small code use -mcmodel=small.  Another 
> solution is to add a non-default -mc-model=large, and generate large code 
> with that option, and then fix the specific test cases in the gcc test suite 
> that fail to use that option on your target.  This is a small maintenance 
> nightmare, but…
> 
> So, which one do you like?
> 
> The model option (I just got done doing one for mine).  I was building gcc 
> for my target, which only the simulator can run due to memory sizes and hit 
> the relocs don’t fit.  I fixed it by 2 lines of work, one in branch and one 
> in call, that removed the displacement forms under large model.  Generates 
> gross code, but I only need it for testing.  For production, we default to 
> and use small.  The reality is that while the other instruction might 
> theoretically hit the reloc limits, in practice they don’t.
> 

Re: [PATCH, ARM] Fix incorrect alignment of small values in minipool

[Richard Earnshaw]

On 11/08/14 08:49, Thomas Preud'homme wrote:
> Being 32-bit wide in size, constant pool entries are always filled as 32-bit
> quantities. This works fine for little endian system but gives some incorrect
> results for big endian system when the value is *accessed* with a mode smaller
> than 32-bit in size. Suppose the case of the value 0x1234 that is accessed as 
> an
> HImode value. It would be output as 0x0 0x0 0x12 0x34 in a constant pool entry
> and the 16-bit load that would be done would lead to the value 0x0 in 
> register.
> The approach here is to transform the value so that it is output correctly by
> shifting the value left so that the highest byte in its mode ends up in the
> highest byte of the 32-bit value being output.
> 
> The patch was tested by running the testsuite with three different builds of 
> GCC:
> 1) bootstrap of GCC on x86_64-linux-gnu
> 2) arm-none-eabi cross compiler (defaulting to little endian) with testsuite
> run under qemu emulqting a Cortex M4
> 3) arm-none-eabi cross compiler (defaulting to big endian, thanks to patch at 
> [1])
> with testsuite run under qemu emulating a Cortex M3. Due to the processor 
> used,
> the test constant-minipool was not run as part of the testsuite but manually 
> with
> -cpu=cortex-r4
> 
> [1] https://sourceware.org/ml/binutils/2014-08/msg00014.html
> 
> The ChangeLog is as follows:
> 
> *** gcc/ChangeLog ***
> 
> 2014-07-14  Thomas Preud'homme  
> 
>   * config/arm/arm.c (dump_minipool): Fix alignment in minipool of
>   values whose size is less than MINIPOOL_FIX_SIZE on big endian target.
> 

I think this is the wrong place for this sort of fix up.  HFmode values
are fixed up in the consttable_4 pattern and it looks wrong to be that
HImode values are then fixed up in a different place.  We should be
consistent and do all the fix ups in one location.

R.


> *** gcc/testsuite/ChangeLog ***
> 
> 2014-07-14  Thomas Preud'homme  
> 
>   * gcc.target/arm/constant-pool.c: New test.
> 
> 
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 0146fe8..e4e0ef4 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -16507,6 +16507,15 @@ dump_minipool (rtx scan)
> fputc ('\n', dump_file);
>   }
>  
> +   /* On big-endian target, make sure that padding for values whose
> +  mode size is smaller than MINIPOOL_FIX_SIZE comes after.  */
> +   if (BYTES_BIG_ENDIAN && CONST_INT_P (mp->value))
> + {
> +   int byte_disp = mp->fix_size - GET_MODE_SIZE (mp->mode);
> +   HOST_WIDE_INT val = INTVAL (mp->value);
> +   mp->value = GEN_INT (val << (byte_disp * BITS_PER_UNIT));
> + }
> +
> switch (mp->fix_size)
>   {
>  #ifdef HAVE_consttable_1
> diff --git a/gcc/testsuite/gcc.target/arm/constant-pool.c 
> b/gcc/testsuite/gcc.target/arm/constant-pool.c
> new file mode 100644
> index 000..46a1534
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/constant-pool.c
> @@ -0,0 +1,28 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target arm_arm_ok } */
> +/* { dg-options "-O1 -marm -mbig-endian" } */
> +
> +unsigned short v = 0x5678;
> +int i;
> +int j = 0;
> +int *ptr = &j;
> +
> +int
> +func (void)
> +{
> +  for (i = 0; i < 1; ++i)
> +{
> +  *ptr = -1;
> +  v = 0x1234;
> +}
> +  return v;
> +}
> +
> +int
> +main (void)
> +{
> +  func ();
> +  return v - 0x1234;
> +}
> +
> +/* { dg-final { scan-assembler-not ".word 4660" } } */
> 
> 
> Is this ok for trunk?
> 
> Best regards,
> 
> Thomas
> 
> 
> 

Re: [PATCH] Keep patch file permissions in mklog

[Yury Gribov]

On 08/11/2014 11:22 AM, Tom de Vries wrote:

+if ($#ARGV == 1 && ("$ARGV[0]" eq "-i" || "$ARGV[0]" eq "--inline")) {

I'd do >= 1 but that's a question of personal preference.



What is the purpose of that proposed change ?


Kind of laying foundation for adding more flags in the future. But as I 
said, this could be done as need for new flags arises.



I'm now using mktemp from File::Temp.


The script now relies on external Perl modules. This is probably fine 
because AFAIK File::Temp and File::Copy are available included in all 
distributions.


+use File::Copy "cp";
+use File::Copy "mv";

You could trade one line with qw(cp mv)...

+   $tmp = mktemp("tmp.") or die "cannot create temp file: $!";

Perhaps "Could not" like in other error messages?

+   cp "$diff", "$tmp" or die "Could not copy patch file to temp file: $!";

Script don't quote stuff in other places so quoting here is useless.

-Y

Re: PR tree-optimization/52904 testcase

[Richard Biener]

On Sat, Aug 9, 2014 at 2:33 PM, Kugan  wrote:
> Hi,
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52904
>
> Tescase was generating warning: assuming signed overflow does not occur
> when simplifying conditional to constant [-Wstrict-overflow] due to VRP
> missing the value range.
>
> This seems to have been fixed and the PR is now closed. However, as
> requested there in the PR, I am sending this patch to add the test-case
> to test-suite.
>
>
> Is this OK ?

Did you verify the testcase fails before the revision that fixed it?
Esp. the placement of the dg-bogus looks bogus to me.

Also don't use -S in dg-options, use lower-case filenames and
avoid spurious vertical white-space.  The VRP dump scan is
also very unspecific - I suggest to drop it entirely.

Thanks,
Richard.

> Thanks,
> Kugan
>
> gcc/testsuite
>
>
> 2014-08-09  Kugan Vivekanandarajah  
>
> PR tree-optimization/52904
> * gcc.dg/PR52904.c: New test.

[PATCH, ARM] Fix incorrect alignment of small values in minipool

[Thomas Preud'homme]

Being 32-bit wide in size, constant pool entries are always filled as 32-bit
quantities. This works fine for little endian system but gives some incorrect
results for big endian system when the value is *accessed* with a mode smaller
than 32-bit in size. Suppose the case of the value 0x1234 that is accessed as an
HImode value. It would be output as 0x0 0x0 0x12 0x34 in a constant pool entry
and the 16-bit load that would be done would lead to the value 0x0 in register.
The approach here is to transform the value so that it is output correctly by
shifting the value left so that the highest byte in its mode ends up in the
highest byte of the 32-bit value being output.

The patch was tested by running the testsuite with three different builds of 
GCC:
1) bootstrap of GCC on x86_64-linux-gnu
2) arm-none-eabi cross compiler (defaulting to little endian) with testsuite
run under qemu emulqting a Cortex M4
3) arm-none-eabi cross compiler (defaulting to big endian, thanks to patch at 
[1])
with testsuite run under qemu emulating a Cortex M3. Due to the processor used,
the test constant-minipool was not run as part of the testsuite but manually 
with
-cpu=cortex-r4

[1] https://sourceware.org/ml/binutils/2014-08/msg00014.html

The ChangeLog is as follows:

*** gcc/ChangeLog ***

2014-07-14  Thomas Preud'homme  

* config/arm/arm.c (dump_minipool): Fix alignment in minipool of
values whose size is less than MINIPOOL_FIX_SIZE on big endian target.

*** gcc/testsuite/ChangeLog ***

2014-07-14  Thomas Preud'homme  

* gcc.target/arm/constant-pool.c: New test.


diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 0146fe8..e4e0ef4 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -16507,6 +16507,15 @@ dump_minipool (rtx scan)
  fputc ('\n', dump_file);
}
 
+ /* On big-endian target, make sure that padding for values whose
+mode size is smaller than MINIPOOL_FIX_SIZE comes after.  */
+ if (BYTES_BIG_ENDIAN && CONST_INT_P (mp->value))
+   {
+ int byte_disp = mp->fix_size - GET_MODE_SIZE (mp->mode);
+ HOST_WIDE_INT val = INTVAL (mp->value);
+ mp->value = GEN_INT (val << (byte_disp * BITS_PER_UNIT));
+   }
+
  switch (mp->fix_size)
{
 #ifdef HAVE_consttable_1
diff --git a/gcc/testsuite/gcc.target/arm/constant-pool.c 
b/gcc/testsuite/gcc.target/arm/constant-pool.c
new file mode 100644
index 000..46a1534
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/constant-pool.c
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_arm_ok } */
+/* { dg-options "-O1 -marm -mbig-endian" } */
+
+unsigned short v = 0x5678;
+int i;
+int j = 0;
+int *ptr = &j;
+
+int
+func (void)
+{
+  for (i = 0; i < 1; ++i)
+{
+  *ptr = -1;
+  v = 0x1234;
+}
+  return v;
+}
+
+int
+main (void)
+{
+  func ();
+  return v - 0x1234;
+}
+
+/* { dg-final { scan-assembler-not ".word 4660" } } */


Is this ok for trunk?

Best regards,

Thomas

RE: [PATCH] Fix incorrect folding of bitfield in a union on big endian target

[Thomas Preud'homme]

> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> 
> No regression were observed on any of the tests. The ChangeLog is as
> follows:
> 
> 
> 2014-08-11  Thomas Preud'homme  
> 
>   * gimple-fold.c (fold_ctor_reference): Don't fold in presence of
>   bitfields, that is when size doesn't match the size of type or the
>   size of the constructor.

The ChangeLog is imcomplete. This was for gcc/ChangeLog.

For gcc/testsuite/ChangeLog, there is:

2014-07-02  Thomas Preud'homme  

* gcc.c-torture/execute/bitfld-6.c: New test.

Best regards,

Thomas 

Re: [Patch] PR55189 enable -Wreturn-type by default

[Sylvestre Ledru]

On 31/07/2014 00:08, Joseph S. Myers wrote:
> On Mon, 7 Jul 2014, Sylvestre Ledru wrote:
>
>> Hello,
>>
>> On 17/06/2014 19:41, Joseph S. Myers wrote:
>>> On Tue, 17 Jun 2014, Sylvestre Ledru wrote:
>>>
 OK. I will do that.
 We should test the following:
 * default => run just -Wreturn-type
 * -Wreturn-type => Run both
 * -Wreturn-type + -Wmissing-return => Run both
 * -Wno-return-type + -Wmissing-return => Run just the second one
 * -Wno-return-type + -Wno-missing-return => Run none
 Do you see any other?
>>> That looks like the right things to test, if there are no changes for 
>>> anything other than those options.
>> Here it is:
>> https://github.com/sylvestre/gcc/commit/db8aaac91aa09fd1ec1cc8974586aec45a221e71
>>
>> Is that what you expected?
> The test Wmissing-return2.c only has one of the two warnings.  But as per 
> "-Wreturn-type => Run both", and for backwards compatibility with the 
> existing definition of -Wreturn-type, both warnings should appear for this 
> test.  
Make sense. Thanks for the feedback and the help.
Here it is:
https://github.com/sylvestre/gcc/commit/089ffc9fb85034111b892ee10190dc12b5dbe551

> (It's simply that only a subset of -Wreturn-type seems suitable to 
> enable by default for C.  Maybe the default subset, -Wreturn-type 
> -Wno-missing-return (which is a combination that should also be included 
> in the testcases), should have its own option name, although I don't know 
> what that would be.)
>
What about implementing that in an further commit?
I have touched more than 1200 test files and I would like to see that
merged soon to avoid more conflicts.

By the way, do you prefer a single commit for all tests or one per
directory (gfortran, C++, gcc, OpenMP) ?

Thanks
Sylvestre

[PATCH] Fix incorrect folding of bitfield in a union on big endian target

[Thomas Preud'homme]

In the code dealing with folding of structure and union initialization, there 
is a
check that the size of the constructor is the same as the field being read.
However, in the case of bitfield this test can be wrong because it relies on
TYPE_SIZE to get the size of the field being read but TYPE_SIZE returns the
size of the enclosing integer in that case. This patch also check the size
parameter which contains the actual size of the field being read.

The patch was tested by running the testsuite with three different builds of 
GCC:
1) bootstrap of GCC on x86_64-linux-gnu
2) arm-none-eabi cross compiler (defaulting to little endian) with testsuite
run under qemu emulqting a Cortex M4
3) arm-none-eabi cross compiler (defaulting to big endian, thanks to patch at 
[1])
with testsuite run under qemu emulating a Cortex M3.

[1] https://sourceware.org/ml/binutils/2014-08/msg00014.html

No regression were observed on any of the tests. The ChangeLog is as follows:


2014-08-11  Thomas Preud'homme  

* gimple-fold.c (fold_ctor_reference): Don't fold in presence of
bitfields, that is when size doesn't match the size of type or the
size of the constructor.


diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 3dcb576..6270c34 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -3099,7 +3099,9 @@ fold_ctor_reference (tree type, tree ctor, unsigned 
HOST_WIDE_INT offset,
   if (!AGGREGATE_TYPE_P (TREE_TYPE (ctor)) && !offset
   /* VIEW_CONVERT_EXPR is defined only for matching sizes.  */
   && operand_equal_p (TYPE_SIZE (type),
- TYPE_SIZE (TREE_TYPE (ctor)), 0))
+ TYPE_SIZE (TREE_TYPE (ctor)), 0)
+  && !compare_tree_int (TYPE_SIZE (type), size)
+  && !compare_tree_int (TYPE_SIZE (TREE_TYPE (ctor)), size))
 {
   ret = canonicalize_constructor_val (unshare_expr (ctor), from_decl);
   ret = fold_unary (VIEW_CONVERT_EXPR, type, ret);
diff --git a/gcc/testsuite/gcc.c-torture/execute/bitfld-6.c 
b/gcc/testsuite/gcc.c-torture/execute/bitfld-6.c
new file mode 100644
index 000..50927dc
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/bitfld-6.c
@@ -0,0 +1,23 @@
+union U
+{
+  const int a;
+  unsigned b : 20;
+};
+
+static union U u = { 0x12345678 };
+
+/* Constant folding used to fail to account for endianness when folding a
+   union.  */
+
+int
+main (void)
+{
+#ifdef __BYTE_ORDER__
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+  return u.b - 0x45678;
+#else
+  return u.b - 0x12345;
+#endif
+#endif
+  return 0;
+}

Is it ok for trunk?

Best regards,

Thomas

Re: [GSoC] Elimination of CLooG library installation dependency

[Tobias Grosser]

On 11/08/2014 09:11, Roman Gareev wrote:

I am confused. It seems you attached some kind of reduced version of
btCollisionWorld.cpp? How did you obtain it? Did you compile and test
with these versions?


I’ve manually selected parts of code, which produce the scope.

I’ve found out that this bug is most probably caused by absence of
pointer handling.  The tree, which is corresponding to P_11 has
pointer type. Furthermore,  if we consider the transformed gimple code
for (it can be found attached), we’ll see that it contains wrong
parts:


Could you please advise me an algorithm for pointer handling?


Did you try your code with 64bit pointer types?

In any case, I don't think it is worth spending time on this. I would 
check in the scop detection that we disable the handling of unsigned and 
pointer types. It is a complex thing to model and the approach currently 
taking of always model their wrapping behaviour seems wrong.

What we should do later is to build a run-time check that ensures
no pointer overflow is happening and then just create code without it.

Cheers,
Tobias

Re: [PATCH] Keep patch file permissions in mklog

[Tom de Vries]

On 04-08-14 13:50, Yury Gribov wrote:

 > thanks for the review.

Np, I'm personally happy to see that script is useful.

 > I've now interpreted it such that --inline prints to stdout what it
 > would print to the patch file otherwise, that is, both log and patch.
 > Printing just the log to stdout can be already be achieved by not using
 > --inline.

Could you add a note in the help message?



Done.


+if ($#ARGV == 1 && ("$ARGV[0]" eq "-i" || "$ARGV[0]" eq "--inline")) {

I'd do >= 1 but that's a question of personal preference.



What is the purpose of that proposed change ?


+if ($inline && $diff ne "-") {
+$tmp = `mktemp`;
+if ($? != 0) {
+die "Could not generate temp file";
+}

IMHO better use consistent style: system() or ticks with $?.
Or even better, encapsulate environment calls in a subfunction which would check
return code and return stdout.



I've realised that using cat to keep permissions on the patch file might not be 
a good idea: if it's interrupted, the original patch might be truncated. So I 
use mv at the end to atomically move the new contents to the patch file. And I 
implement keeping the permission by first copying the patch file to the temp 
file. That means that it's necessary to first truncate the temp file before 
writing to it. I've implemented the truncate using open.


I've tried using a temp file with just a file handle, as Segher suggested, (and 
use perl truncate to do the truncation), but I didn't get that working. So I'm 
now using mktemp from File::Temp.


With these modification, I've eliminated system() calls and backticks from the 
patch.



BTW you may want to wait for Diego's and Trevor's comments (Diego is the
maintainer and approver for this code).



ok.

Thanks,
- Tom

2014-08-11  Tom de Vries  

	* mklog: Add --inline option.

diff --git a/contrib/mklog b/contrib/mklog
index 3d17dc5..d294417 100755
--- a/contrib/mklog
+++ b/contrib/mklog
@@ -26,6 +26,10 @@
 # Author: Diego Novillo  and
 # Cary Coutant 
 
+use File::Temp;
+use File::Copy "cp";
+use File::Copy "mv";
+
 # Change these settings to reflect your profile.
 $username = $ENV{'USER'};
 $name = `finger $username | grep -o 'Name: .*'`;
@@ -56,14 +60,22 @@ if (-d "$gcc_root/.git") {
 # Program starts here. You should not need to edit anything below this
 # line.
 #-
-if ($#ARGV != 0) {
+$inline = 0;
+if ($#ARGV == 1 && ("$ARGV[0]" eq "-i" || "$ARGV[0]" eq "--inline")) {
+	shift;
+	$inline = 1;
+} elsif ($#ARGV != 0) {
 $prog = `basename $0`; chop ($prog);
 print <', $tmp) or die "Could not open temp file: $!";
+} else {
+	*OUTPUTFILE = STDOUT;
+}
+
+# Print the log
 foreach my $clname (keys %cl_entries) {
-	print "$clname:\n\n$hdrline\n\n$cl_entries{$clname}\n";
+	print OUTPUTFILE "$clname:\n\n$hdrline\n\n$cl_entries{$clname}\n";
+}
+
+if ($inline) {
+	# Append the patch to the log
+	foreach (@diff_lines) {
+		print OUTPUTFILE "$_\n";
+	}
+}
+
+if ($inline && $diff ne "-") {
+	# Close $tmp
+	close(OUTPUTFILE);
+
+	# Write new contents to $diff atomically
+	mv $tmp, $diff or die "Could not move temp file to patch file: $!";
 }
 
 exit 0;
-- 
1.9.1

Re: [PATCH testcase]Add bind_pic_locally to case addrtmp.c

[Bin.Cheng]

On Thu, Aug 7, 2014 at 5:54 PM, Bin.Cheng  wrote:
> On Thu, Aug 7, 2014 at 5:43 PM, Bin Cheng  wrote:
>> Hi,
>>
>> The case depends on GCC inlining of global function, but the callee won't be
>> inlined because it's global function and considered over-writable during
>> run-time.
> It won't be inlined only if it's tested against -fpic/-fPIC.
>
>> This patch fixes the failure by binding it to pic locally.  Is it OK?
>>
>> Thanks,
>> bin
>>
>> gcc/testsuite/ChangeLog
>> 2014-08-07  Bin Cheng  
>>
>> * c-c++-common/addrtmp.c: Bind pic locally.


Hi,
This is a simple test case change, could somebody have a look at it?

Thanks,
bin

Re: [GSoC] Elimination of CLooG library installation dependency

[Roman Gareev]

> I am confused. It seems you attached some kind of reduced version of
> btCollisionWorld.cpp? How did you obtain it? Did you compile and test
> with these versions?

I’ve manually selected parts of code, which produce the scope.

I’ve found out that this bug is most probably caused by absence of
pointer handling.  The tree, which is corresponding to P_11 has
pointer type. Furthermore,  if we consider the transformed gimple code
for (it can be found attached), we’ll see that it contains wrong
parts:

The code produced by modified version of Graphite:
...
  _35 = (signed long) _11;
  _36 = _34 + _35;
  _37 = _36 % 0;
  _38 = _37 > 0;
  _39 = (signed long) _38;
...

The code produced by origin version of Graphite:

...
  _36 = (sizetype) _11;
  _37 = _36 + 18446744073709551615;
  _38 = 8B + _37;
  _39 = _38 % 0B;
  _40 = _39 != -1B;
...

(If I’m not mistaken, 0B, for example, corresponds to (void *).  It
can be seen here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50712)

I’ve tried to implement pointer handling in the attached patch, but it
is wrong. I get the following error instead of seagfault now:

Floating point exception (core dumped)

back trace:

Program terminated with signal 8, Arithmetic exception.
#0  0x004204c5 in allocSize (this=,
size=)
at 
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/LinearMath/btAlignedObjectArray.h:59
59 return (size ? size*2 : 1);
(gdb) bt
#0  0x004204c5 in allocSize (this=,
size=)
at 
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/LinearMath/btAlignedObjectArray.h:59
#1  push_back (_Val=, this=0x1125600)
at 
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/LinearMath/btAlignedObjectArray.h:220
#2  btCollisionDispatcher::getNewManifold (this=0x11255f0, b0=,
b1=) at btCollisionDispatcher.llvm.cpp:100
#3  0x0044e764 in
btConvexPlaneCollisionAlgorithm::btConvexPlaneCollisionAlgorithm
(this=0x7f665ca6b0c0, mf=0x0, ci=..., col0=,
col1=, isSwapped=,
numPerturbationIterations=1, minimumPointsPerturbationThreshold=1)
at 
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/btConvexPlaneCollisionAlgorithm.cpp:38
#4  0x0046281b in
btConvexPlaneCollisionAlgorithm::CreateFunc::CreateCollisionAlgorithm
(this=0x11254e0, ci=..., body0=0x113d040, body1=0x113d810)
at 
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/include/BulletCollision/CollisionDispatch/btConvexPlaneCollisionAlgorithm.h:76
#5  0x004205ac in btCollisionDispatcher::findAlgorithm (
this=, body0=, body1=,
sharedManifold=) at btCollisionDispatcher.llvm.cpp:145
#6  0x004202e2 in btCollisionDispatcher::defaultNearCallback (
---Type  to continue, or q  to quit---
collisionPair=..., dispatcher=..., dispatchInfo=...)
at btCollisionDispatcher.llvm.cpp:258
#7  0x0042083b in btCollisionPairCallback::processOverlap (
this=, pair=...) at btCollisionDispatcher.llvm.cpp:224
#8  0x004acff2 in
btHashedOverlappingPairCache::processAllOverlappingPairs
(this=0x1127f80, callback=0x7fff0d1af790, dispatcher=0x11255f0)
at 
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/btOverlappingPairCache.cpp:387
#9  0x004200c9 in btCollisionDispatcher::dispatchAllCollisionPairs (
this=, pairCache=, dispatchInfo=...,
dispatcher=) at btCollisionDispatcher.llvm.cpp:238
#10 0x00421bd4 in btCollisionWorld::performDiscreteCollisionDetection()
()
#11 0x00464d9a in
btDiscreteDynamicsWorld::internalSingleStepSimulation(float) ()
#12 0x0046473f in
btDiscreteDynamicsWorld::stepSimulation(float, int, float) ()
#13 0x00401e08 in BenchmarkDemo::clientMoveAndDisplay (
this=0x7fff0d1af980)
at 
/home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/BenchmarkDemo.cpp:232
#14 0x00401b12 in main (argc=, argv=)
at /home/roman/llvm-test-suite/MultiSource/Benchmarks/Bullet/main.cpp:63

Could you please advise me an algorithm for pointer handling?


-- 
Cheers, Roman Gareev.
loop_0 (header = 0, latch = 1, niter = )
{
  bb_2 (preds = {bb_0 }, succs = {bb_4 bb_3 })
  {
:
# DEBUG D#5 => &this_1(D)->m_manifoldsPtr
# DEBUG this => D#5
# VUSE <.MEM_3(D)>
_5 = MEM[(struct btAlignedObjectArray *)this_1(D) + 8B].m_size;
_6 = _5 * 2;
# DEBUG D#4 => &D#5->m_allocator
# DEBUG D#2 => D#4
# DEBUG D#3 => 0B
# DEBUG n => _6
# DEBUG this => D#2
# DEBUG hint => D#3
_7 = (long unsigned int) _6;
_8 = (unsigned int) _7;
_9 = _8 * 8;
_10 = (int) _9;
# .MEM_22 = VDEF <.MEM_3(D)>
_11 = btAlignedAlloc (_10, 16);
# DEBUG s => _11
# DEBUG i => 0
# DEBUG i => 0
# VUSE <.MEM_22>
_2 = MEM[(struct btAlignedObjectArray *)this_1(D) + 8B].m_size;
if (_2 > 0)
  goto ;
else
  goto ;

  }
  bb_3 (preds = {bb_2 bb_10 }, succs = {bb_11 })
  {
:
# .