Today's MPX trunk patches (Rev. 204046): i386.md:18329:2: error: 'TARGET_MPX' was not declared in this scope

[Tobias Burnus]

Hi Kirill,

with the current trunk (newst "git" mirror version), bootstrapping fails 
here with the following error. Did you forget to commit one file?



g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long 
-Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc 
-I../../gcc/build -I../../gcc/../include -I../../gcc/../libcpp/include 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid 
-I../libdecnumber -I../../gcc/../libbacktrace -DCLOOG_INT_GMP\

-o build/gencondmd.o build/gencondmd.c
../../gcc/config/i386/i386.md:18329:2: error: 'TARGET_MPX' was not 
declared in this scope

   "TARGET_MPX"
  ^
../../gcc/config/i386/i386.md:18329:2: error: 'TARGET_MPX' was not 
declared in this scope

   "TARGET_MPX"
  ^
../../gcc/config/i386/i386.md:18329:2: error: 'TARGET_MPX' was not 
declared in this scope

   "TARGET_MPX"
  ^
../../gcc/config/i386/i386.md:18329:2: error: 'TARGET_MPX' was not 
declared in this scope

   "TARGET_MPX"
  ^

Tobias

Re: [Patch, C++] Add C++ FE support for #pragma ivdep

[Jakub Jelinek]

On Fri, Oct 25, 2013 at 08:22:22AM +0200, Tobias Burnus wrote:
> Jason Merrill wrote:
> >On 10/10/2013 04:46 AM, Tobias Burnus wrote:
> >>I considered to add the annotation also to C++11's range-based loops,
> >>but as those are unlikely to vectorize, I didn't do so.
> >
> >I would think that a range-based loop over an array should vectorize
> >nicely:
> >
> >int ar[8];
> >for (int i: ar) { ... }
> 
> They do - but during my experiments they either also did without
> "#pragma GCC ivdep" – typically with static arrays like yours – or
> they didn't with vector<>.
> 
> However, I came now up with an example where "#pragma GCC ivdep"
> should have an effect:
> 
> int ar[100];
> 
> void foo(int *a) {
>   for (auto &i : ar) {
> i *= *a;
>   }
> }
> 
> Therefore, I will send a follow up patch.

What about
#pragma GCC ivdep
while (cond) { ... }
and
#pragma GCC ivdep
do { ... } while (cond);
(for both C and C++)?

Jakub

RE: [PATCH, PR 57748] Check for out of bounds access, Part 2

[Bernd Edlinger]

Hi Richard,


>> Did you just propose:
>>
>> --- stor-layout.c.orig 2013-10-22 10:46:49.233261818 +0200
>> +++ stor-layout.c 2013-10-24 14:54:00.425259062 +0200
>> @@ -471,27 +471,7 @@
>> static enum machine_mode
>> mode_for_array (tree elem_type, tree size)
>> {
>> - tree elem_size;
>> - unsigned HOST_WIDE_INT int_size, int_elem_size;
>> - bool limit_p;
>> -
>> - /* One-element arrays get the component type's mode. */
>> - elem_size = TYPE_SIZE (elem_type);
>> - if (simple_cst_equal (size, elem_size))
>> - return TYPE_MODE (elem_type);
>> -
>> - limit_p = true;
>> - if (host_integerp (size, 1) && host_integerp (elem_size, 1))
>> - {
>> - int_size = tree_low_cst (size, 1);
>> - int_elem_size = tree_low_cst (elem_size, 1);
>> - if (int_elem_size> 0
>> - && int_size % int_elem_size == 0
>> - && targetm.array_mode_supported_p (TYPE_MODE (elem_type),
>> - int_size / int_elem_size))
>> - limit_p = false;
>> - }
>> - return mode_for_size_tree (size, MODE_INT, limit_p);
>> + return BLKmode;
>> }
>>
>> ???
>
> Yes. Does it work?
>
> Richard.
>

No.

PASS: gcc.target/i386/pr14289-1.c  (test for errors, line 10)
FAIL: gcc.target/i386/pr14289-1.c (test for excess errors)
Excess errors:
/home/ed/gnu/gcc-4.9-20131013/gcc/testsuite/gcc.target/i386/pr14289-1.c:5:14: 
error: data type of 'a' isn't suitable for a register

Does that look like an ABI-Change?

the test case uses:
register int a[2] asm("ebx");

Bernd.

Re: [Patch, C++] Add C++ FE support for #pragma ivdep

[Tobias Burnus]

Jason Merrill wrote:

On 10/10/2013 04:46 AM, Tobias Burnus wrote:

I considered to add the annotation also to C++11's range-based loops,
but as those are unlikely to vectorize, I didn't do so.


I would think that a range-based loop over an array should vectorize
nicely:

int ar[8];
for (int i: ar) { ... }


They do - but during my experiments they either also did without 
"#pragma GCC ivdep" – typically with static arrays like yours – or they 
didn't with vector<>.


However, I came now up with an example where "#pragma GCC ivdep" should 
have an effect:


int ar[100];

void foo(int *a) {
  for (auto &i : ar) {
i *= *a;
  }
}

Therefore, I will send a follow up patch.

Tobias

Re: [RFC] Fix context-sensitiveness of peephole2 pass

[Jakub Jelinek]

On Thu, Oct 24, 2013 at 11:14:42PM -0600, Jeff Law wrote:
> On 10/24/13 15:10, Eric Botcazou wrote:
> >As discovered by Richard B. under PR rtl-optimization/58831, the peephole2
> >pass has been context-sensitive for a long time when scratch registers are
> >needed, in the sense that the behaviour of the pass for a given function is
> >dependent on what happened for the previously optimized function.
> >
> >Obvious patch attached, tested on x86_64-suse-linux.  Do we want to apply it
> >on mainline only or on all the active branches?
> >
> >
> >2013-10-24  Eric Botcazou  
> >
> > * recog.c (search_ofs): New static variable moved from...
> > (peep2_find_free_register): ...here.
> > (peephole2_optimize): Initialize it.
> OK for trunk.  Release branch owners have the final call for their branches.

This is ok for the release branches too.

Jakub

Re: Aliasing: look through pointer's def stmt

[Marc Glisse]

On Thu, 24 Oct 2013, Jeff Law wrote:


On 10/24/13 23:23, Marc Glisse wrote:

Hello,

I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstrap+testsuite, does it make sense? (I am a bit afraid of
losing some type information for instance)

I didn't investigate the 2 tests where I had to remove dg-bogus, because
removing dg-bogus sounds like a bonus...

2013-10-25  Marc Glisse  

gcc/
 * tree-ssa-alias.c (ao_ref_init_from_ptr_and_size): Look for an
 ADDR_EXPR in the defining statement.

Shouldn't the ADDR_EXPR have been propagated into the use?


Maybe when the address is a constant, but here it comes from malloc.

--
Marc Glisse

Re: [wwwdocs, patch] gcc-4.9/changes.html: Add quip about "#pragma GCC ivdep" and update Fortran section

[Tobias Burnus]

Gerald Pfeifer wrote:

On Thu, 24 Oct 2013, Tobias Burnus wrote:

Any comments? Or is the patch OK?

thanks for doing this.


Thanks for looking at the patch. However, the patch has a link problem. 
The documentation is at

   http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html

That's also the link I use in the changes.html file. However, some 
script changes the link to:

   http://gcc.gnu.org/onlinedocs/gcc/Loop-Specific-Pragmas.html
which won't work. Try yourself at http://gcc.gnu.org/gcc-4.9/changes.html


Actually, a similar issue was reported at 
http://gcc.gnu.org/ml/gcc-help/2013-10/msg00132.html


Does anyone know which script modifies those links?

Tobias

Re: [PATCH, MPX, 2/X] Pointers Checker [4/25] Constructors

[Jeff Law]

On 10/21/13 06:10, Ilya Enkovich wrote:

Hi,

This patch introduces two new contructor types supported by 
cgraph_build_static_cdtor.

'B' type is used to initialize static objects (bounds) created by Pointers 
Checker. The difference of this type from the regular constructor is that 'B' 
constructor is never instrumented by Pointers Checker.

'P' type is used by Pointers Checker to generate constructors to initialize 
bounds of statically initialized pointers. Pointers Checker remove all stores 
from such constructors after instrumentation.

Since 'P' type constructors are created for statically initialized objects, we 
need to avoid creation of such objects during its gimplification. New 
restriction was added to gimplify_init_constructor.

Bootstrapped and checked on linux-x86_64.

Thanks,
Ilya
--

gcc/

2013-10-21  Ilya Enkovich  

* ipa.c (cgraph_build_static_cdtor_1): Support contructors
with "chkp ctor" and "bnd_legacy" attributes.
* gimplify.c (gimplify_init_constructor): Avoid infinite
loop during gimplification of bounds initializer.

This is OK.

As a side note, it seems awfully strange to be passing in the type of 
ctor/dtor in a char varaible.  I'd look favorably upon changing that to 
an enum where the enum values describe the cases they handle.  The 
existing code seems so, umm, 80s/90s style.  Obviously not something 
that's required of you to move this patch forward.


jeff

Re: [PATCH v2 4/4] Add documentation about gengtype and inheritance

[Jeff Law]

On 10/23/13 21:00, David Malcolm wrote:


I went through the various requirements listed in the doc and
investigated what happens when they're violated.  Some lead to immediate
build failure in gengtype (which is relatively sane), but some lead to
silent lack of field-traversal.  The details:
Yea, build failure in gengtype is reasonable.  Build failure because 
gengtype generated bogons, is slightly less desirable, but still in the 
realm of OK IMHO.Silent lack of field traversal is bad bad bad.





Summarizing:
(B), (F), (G): silent possibility of failing to visit fields during
traversal (bad, bad, bad)

These are obviously the most worrisome.




(A),  (C), (D), (E): build-time failures (relatively benign by
comparison)


As for this patch, it is OK once the prerequisites go in.


AIUI you've approved each patch in the whole series, and so far I've
committed patches 1 and 2 of the 4 (relatively safe).

Clearly I should add some robustness to better handle the more egregious
failure modes described above.  Should I post patches to do so before
committing further, or can I commit the rest of the approved patches in
the "v2" series (patches 3 and 4), doing the hardening patches as a
followup?

Your call as long as you commit to do what you can to harden this code.



As an aside, has anyone tried writing a testsuite for gengtype and the
GTY machinery?

Not that I'm aware of.

jeff

Re: [PATCH, MPX, 2/X] Pointers Checker [2/25] Builtins

[Jeff Law]

On 10/21/13 05:49, Ilya Enkovich wrote:

Hi,

This patch introduces built-in functions used by Pointers Checker and flag to 
enable Pointers Checker. Builtins available for user are expanded in 
expand_builtin. All other builtins are not allowed in expand until generic 
version of Pointers Cheker is implemented.

Bootstrapped and tested on linux-x86_64.

Thanks,
Ilya
--

gcc/

2013-10-04  Ilya Enkovich  

* builtin-types.def (BT_FN_VOID_CONST_PTR): New.
(BT_FN_PTR_CONST_PTR): New.
(BT_FN_CONST_PTR_CONST_PTR): New.
(BT_FN_PTR_CONST_PTR_SIZE): New.
(BT_FN_PTR_CONST_PTR_CONST_PTR): New.
(BT_FN_VOID_PTRPTR_CONST_PTR): New.
(BT_FN_VOID_CONST_PTR_SIZE): New.
(BT_FN_PTR_CONST_PTR_CONST_PTR_SIZE): New.
* chkp-builtins.def: New.
* builtins.def: include chkp-builtins.def.
(DEF_CHKP_BUILTIN): New.
* builtins.c (expand_builtin): Support BUILT_IN_CHKP_INIT_PTR_BOUNDS,
BUILT_IN_CHKP_NULL_PTR_BOUNDS, BUILT_IN_CHKP_COPY_PTR_BOUNDS,
BUILT_IN_CHKP_CHECK_PTR_LBOUNDS, BUILT_IN_CHKP_CHECK_PTR_UBOUNDS,
BUILT_IN_CHKP_CHECK_PTR_BOUNDS, BUILT_IN_CHKP_SET_PTR_BOUNDS,
BUILT_IN_CHKP_NARROW_PTR_BOUNDS, BUILT_IN_CHKP_STORE_PTR_BOUNDS,
BUILT_IN_CHKP_GET_PTR_LBOUND, BUILT_IN_CHKP_GET_PTR_UBOUND,
BUILT_IN_CHKP_BNDMK, BUILT_IN_CHKP_BNDSTX, BUILT_IN_CHKP_BNDCL,
BUILT_IN_CHKP_BNDCU, BUILT_IN_CHKP_BNDLDX, BUILT_IN_CHKP_BNDRET,
BUILT_IN_CHKP_INTERSECT, BUILT_IN_CHKP_ARG_BND, BUILT_IN_CHKP_NARROW,
BUILT_IN_CHKP_EXTRACT_LOWER, BUILT_IN_CHKP_EXTRACT_UPPER.
* common.opt (fcheck-pointers): New.
* toplev.c (process_options): Check Pointers Checker is supported.
* doc/extend.texi: Document Pointers Checker built-in functions.

Just a few minor comments.


--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -874,6 +874,11 @@ fbounds-check
  Common Report Var(flag_bounds_check)
  Generate code to check bounds before indexing arrays

+fcheck-pointers
+Common Report Var(flag_check_pointers)
+Add pointers checker instrumentation.  fchkp-* flags are used to
+control instrumentation.  Currently available for C, C++ and ObjC.
+
I'd probably use "pointer bounds checking" rather than "pointers 
checker".  It's a nit, but most folks have heard the term "pointer 
bounds checking", but few probabaly use "pointers checker".


I think you make several references to "pointers checker" that are 
probably best reworded slightly to use "pointer bounds checker"




diff --git a/gcc/toplev.c b/gcc/toplev.c
index feba051..285b36d 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -1290,6 +1290,18 @@ process_options (void)
if (flag_mudflap && flag_lto)
  sorry ("mudflap cannot be used together with link-time optimization");

+  if (flag_check_pointers)
+{
+  if (flag_lto)
+   sorry ("Pointers checker is not yet fully supported for link-time 
optimization");
What was the final resolution of this?  Like jsm, this seems to me to be 
papering over a problem elsewhere.


I'll pre-approve this patch with the terminology change and the flag_lto 
hack removed.


jeff

Re: [PATCH, MPX, 2/X] Pointers Checker [3/25] Attributes

[Jeff Law]

On 10/21/13 05:59, Ilya Enkovich wrote:

Hi,

This patch adds attributes 'bnd_variable_size' and 'bnd_legacy' used by 
Pointers Checker.

Bootstrapped and tested on linux-x86_64.

Thanks,
Ilya
--

gcc/

2013-10-21  Ilya Enkovich  

* c-family/c-common.c (handle_bnd_variable_size_attribute): New.
(handle_bnd_legacy): New.
(c_common_attribute_table): Add bnd_variable_size and bnd_legacy.
* doc/extend.texi: Document bnd_variable_size and bnd_legacy
attributes.

OK with the same terminology changes from the 2/25 Builtins patch.

jeff

Re: Aliasing: look through pointer's def stmt

[Jeff Law]

On 10/24/13 23:23, Marc Glisse wrote:

Hello,

I noticed that in some cases we were failing to find aliasing
information because we were only looking at an SSA_NAME variable,
missing the fact that it was really an ADDR_EXPR. The attached patch
passes bootstrap+testsuite, does it make sense? (I am a bit afraid of
losing some type information for instance)

I didn't investigate the 2 tests where I had to remove dg-bogus, because
removing dg-bogus sounds like a bonus...

2013-10-25  Marc Glisse  

gcc/
 * tree-ssa-alias.c (ao_ref_init_from_ptr_and_size): Look for an
 ADDR_EXPR in the defining statement.

Shouldn't the ADDR_EXPR have been propagated into the use?

Jeff

Aliasing: look through pointer's def stmt

[Marc Glisse]

Hello,

I noticed that in some cases we were failing to find aliasing information 
because we were only looking at an SSA_NAME variable, missing the fact 
that it was really an ADDR_EXPR. The attached patch passes 
bootstrap+testsuite, does it make sense? (I am a bit afraid of losing some 
type information for instance)


I didn't investigate the 2 tests where I had to remove dg-bogus, because 
removing dg-bogus sounds like a bonus...


2013-10-25  Marc Glisse  

gcc/
* tree-ssa-alias.c (ao_ref_init_from_ptr_and_size): Look for an
ADDR_EXPR in the defining statement.

gcc/testsuite/
* gcc.dg/tree-ssa/alias-23.c: New file.
* gcc.dg/vect/vect-ivdep-1.c: Remove dg-bogus.
* gfortran.dg/vect/vect-do-concurrent-1.f90: Likewise.

--
Marc GlisseIndex: gcc/testsuite/gcc.dg/tree-ssa/alias-23.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/alias-23.c(revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/alias-23.c(working copy)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+
+typedef struct A { int i; double d; } A;
+
+void f1 (const char *c)
+{
+  A *s = (A*) __builtin_malloc (sizeof (A));
+  double *p = &s->d;
+  s->i = 42;
+  __builtin_memcpy (p, c, sizeof (double));
+  int j = s->i;
+  if (j != 42) __builtin_abort();
+}
+
+/* { dg-final { scan-tree-dump-not "abort" "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
+

Property changes on: gcc/testsuite/gcc.dg/tree-ssa/alias-23.c
___
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:keywords
## -0,0 +1 ##
+Author Date Id Revision URL
\ No newline at end of property
Index: gcc/testsuite/gcc.dg/vect/vect-ivdep-1.c
===
--- gcc/testsuite/gcc.dg/vect/vect-ivdep-1.c(revision 204044)
+++ gcc/testsuite/gcc.dg/vect/vect-ivdep-1.c(working copy)
@@ -8,12 +8,11 @@
 void foo(int n, int *a, int *b, int *c, int *d, int *e) {
   int i, j;
 #pragma GCC ivdep
   for (i = 0; i < n; ++i) {
 a[i] = b[i] + c[i];
   }
 }
 
 /* { dg-message "loop vectorized" "" { target *-*-* } 0 } */
 /* { dg-bogus "version" "" { target *-*-* } 0 } */
-/* { dg-bogus "alias" "" { target *-*-* } 0 } */
 /* { dg-final { cleanup-tree-dump "vect" } } */
Index: gcc/testsuite/gfortran.dg/vect/vect-do-concurrent-1.f90
===
--- gcc/testsuite/gfortran.dg/vect/vect-do-concurrent-1.f90 (revision 
204044)
+++ gcc/testsuite/gfortran.dg/vect/vect-do-concurrent-1.f90 (working copy)
@@ -6,12 +6,11 @@ subroutine test(n, a, b, c)
   integer, value :: n
   real, contiguous,  pointer :: a(:), b(:), c(:)
   integer :: i
   do concurrent (i = 1:n)
 a(i) = b(i) + c(i)
   end do
 end subroutine test
 
 ! { dg-message "loop vectorized" "" { target *-*-* } 0 }
 ! { dg-bogus "version" "" { target *-*-* } 0 }
-! { dg-bogus "alias" "" { target *-*-* } 0 }
 ! { dg-final { cleanup-tree-dump "vect" } }
Index: gcc/tree-ssa-alias.c
===
--- gcc/tree-ssa-alias.c(revision 204044)
+++ gcc/tree-ssa-alias.c(working copy)
@@ -561,20 +561,29 @@ ao_ref_alias_set (ao_ref *ref)
 /* Init an alias-oracle reference representation from a gimple pointer
PTR and a gimple size SIZE in bytes.  If SIZE is NULL_TREE the the
size is assumed to be unknown.  The access is assumed to be only
to or after of the pointer target, not before it.  */
 
 void
 ao_ref_init_from_ptr_and_size (ao_ref *ref, tree ptr, tree size)
 {
   HOST_WIDE_INT t1, t2;
   ref->ref = NULL_TREE;
+  if (TREE_CODE (ptr) == SSA_NAME)
+{
+  gimple stmt = SSA_NAME_DEF_STMT (ptr);
+  if (gimple_assign_single_p (stmt)
+ && !gimple_has_volatile_ops (stmt)
+ && gimple_assign_rhs_code (stmt) == ADDR_EXPR)
+   ptr = gimple_assign_rhs1 (stmt);
+}
+
   if (TREE_CODE (ptr) == ADDR_EXPR)
 ref->base = get_ref_base_and_extent (TREE_OPERAND (ptr, 0),
 &ref->offset, &t1, &t2);
   else
 {
   ref->base = build2 (MEM_REF, char_type_node,
  ptr, null_pointer_node);
   ref->offset = 0;
 }
   if (size

Re: [PATCH, MPX, 2/X] Pointers Checker [2/25] Builtins

[Jeff Law]

On 10/24/13 02:36, Ilya Enkovich wrote:

2013/10/24 Richard Henderson :

On 10/23/2013 02:41 PM, Jeff Law wrote:

Out of curiosity, did you consider and/or discuss with Richard whether or not
to make these target-dependent or target-independent builtins?  I realize it's
a bit problematic with Richard being involved during the NDA portion and
someone else during the review/integration portion, but that's unfortunately
where we are.


I suggested that they be target independent.

I suggested that there was nothing in MPX that couldn't be
done generically, if slower, on non-MPX hardware.

E.g. there's no reason why bounds couldn't be packed into a
double-word integer, and the checking builtins completely
outlined into a runtime library.

I suggested that the optimization done on the bound type
would help a generic mudflap replacement.


Right. The design implies generic support of Pointers Checker without
MPX support on hardware. This series does not include generic support.
We are currently examining priority of this task. Suppose generic
support of Pointers Checker may replace Mudflap. Do not know yet if
Pointers Checker may borrow some stuff from Mudflap.

OK.  Thanks for the clarifications.

jeff

Re: [PATCH, MPX, 2/X] Pointers Checker [1/25] Hooks

[Jeff Law]

On 10/24/13 02:24, Ilya Enkovich wrote:

2013/10/24 Jeff Law :

On 10/21/13 08:20, Ilya Enkovich wrote:


diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 8d220f3..79bd0f9 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
+@deftypefn {Target Hook} rtx TARGET_LOAD_BOUNDS_FOR_ARG (rtx @var{slot},
rtx @var{arg}, rtx @var{slot_no})
+This hook is used to emit insn to load bounds of @var{arg} passed
+in @var{slot}.  In case @var{slot} is not a memory, @var{slot_no} is RTX
+constant holding number of the special slot we should get bounds from.
+Return loaded bounds.
+@end deftypefn
+
+@deftypefn {Target Hook} void TARGET_STORE_BOUNDS_FOR_ARG (rtx @var{arg},
rtx @var{slot}, rtx @var{bounds}, rtx @var{slot_no})
+This hook is used to emit insn to store bounds of @var{arg} passed
+in @var{slot}.  In case @var{slot} is not a memory, @var{slot_no} is RTX
+constant holding number of the special slot we should store bounds to.
+@end deftypefn
+


Almost there. What I think is missing is more information about the case
where SLOT is not a memory (presumably it's a reg) and how that relates to
SLOT_NO.

Isn't this just providing a mapping from the input argument registers to
some set of bounds pointer registers?  Presumably you aren't really exposing
the bound registers as argument registers hence this hack?

Not asking you to change anything, just trying to understand the rationale.




These two hooks are used by expand pass to pass/receive bounds for
args. When bounds are passed in a register, expand does not need this
hook and uses regular move insn. If we are out of bound register or
platform does not have them at all, this hook is called. If bounded
arg is passed in memory, regular way to store associated bounds is
supposed to be used in hook. That is why no slot_no value is required,
only arg and it's place (slot) are used. If bounded arg is passed in
register (e.g. it happens on i386 with MPX when more that 4 pointers
are passed in registers), then some special slot has to be used for
bounds. slot_no here holds identifier of this special slot. E.g. if we
call function with 6 pointer on i386, we call this hook passing R8 and
R9 as slot with const1_rtx and const2_rtx as slot_no.
So can we find a concise way to describe this and include that in the 
docs for the hooks.  Otherwise I can't see how a developer is going to 
know how to use this stuff.



So how am I (as a GCC developer) suppsoed to know what BNDMK, BNDLDX, BNDCU,
etc mean?  The names aren't particularly descriptive.  Are these documented
elsewhere in a follow-up patch?  If not, it seems to me we need to document
them here.


Actually the next patch introduces them and is a good place for
documentation. But currently this patch has documentation for user
visible built-ins only. For now built-ins used for instrumentation are
described on Wiki only
(http://gcc.gnu.org/wiki/Intel%20MPX%20support%20in%20the%20GCC%20compiler#Builtins_used_for_instrumentation).
Where should I move it? Does it also go to extend.texi?
If they're strictly for developers, then there's not a real good place 
for them.  They're not really extensions we would expect the user to 
use, so extend.texi seems inappropriate.


Perhaps a section in tm.texi?

Jeff

Re: [RFC] Fix context-sensitiveness of peephole2 pass

[Jeff Law]

On 10/24/13 15:10, Eric Botcazou wrote:

As discovered by Richard B. under PR rtl-optimization/58831, the peephole2
pass has been context-sensitive for a long time when scratch registers are
needed, in the sense that the behaviour of the pass for a given function is
dependent on what happened for the previously optimized function.

Obvious patch attached, tested on x86_64-suse-linux.  Do we want to apply it
on mainline only or on all the active branches?


2013-10-24  Eric Botcazou  

* recog.c (search_ofs): New static variable moved from...
(peep2_find_free_register): ...here.
(peephole2_optimize): Initialize it.

OK for trunk.  Release branch owners have the final call for their branches.

Thanks for taking the time to track this down.

jeff

Re: [PATCH] fixing typo in expr.c to allow proper recognition of complex addresses in some arches.

[Jeff Law]

On 10/24/13 18:20, Igor Shevlyakov wrote:

I stumbled on a case like this:
If the multipliers allowed for addressing modes are dependent on actual
mode, in some cases compiler
refuses to recognize address as legitimate.
It boils down to this place in expr.c where address_mode is incorrectly
used instead of actual mode.

I rebootstraped and tested on x86_64-linux-gnu but there's no testcase to
see the improved behavior...

Please patch the trunk.
Thanks
Igor

=

2013-10-24  Igor
Shevlyakov




* expr.c (expand_expr_real_1): Use proper memory access mode instead of
address_mode
   in the call to memory_address_addr_space.

Thanks.  Installed on the trunk.

FWIW, the PA might show improvements from this patch.  It's scaled 
indexed addressing modes only allow multipliers that are the same as the 
size of the object being accessed.  ie, a load which accesses 2 bytes 
allows *2, load accessing 4 bytes allows *4 and similarly for double-words.


Anyway, the PA is a dead processor, but if you're looking for ways to 
show problems around limited scaled indexed addressing on a processor 
that is in the trunk, you might want to look at the PA.


jeff

Re: [patch] Fix PR rtl-optimization/58831

[Jeff Law]

On 10/24/13 15:28, Eric Botcazou wrote:

This is a very old bug in the alias.c machinery, which is exposed during
the sched2 pass.  We have in .split4:

(insn 23 22 24 4 (set (mem/f:DI (reg/v/f:DI 4 si [orig:90 p2 ] [90]) [3
*p2_9(D)+0 S8 A64])
 (symbol_ref:DI ("d")  )) pr58831-1.c:12 85
{*movdi_internal}
  (expr_list:REG_DEAD (reg/v/f:DI 4 si [orig:90 p2 ] [90])
 (nil)))

[...]

(insn 61 27 62 6 (clobber (reg:DI 4 si)) -1
  (nil))

(insn/f 62 61 56 6 (parallel [
 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
 (reg:DI 4 si))
 (clobber (mem:BLK (scratch) [0 A8]))
 ]) pr58831-1.c:8 73 {*pushdi2_prologue}
  (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
 (plus:DI (reg/f:DI 7 sp)
 (const_int -8 [0xfff8])))
 (nil)))

[...]

(insn 30 29 31 6 (set (reg:DI 4 si)
 (symbol_ref/f:DI ("*.LC0") [flags 0x2]  )) pr58831-1.c:14 85 {*movdi_internal}
  (nil))

si is the 2nd argument register on x86-64 so it's live on entry.  The problem
is that the clobber at insn 61 wipes out the value recorded for si:

   /* A CLOBBER wipes out any old value but does not prevent a previously
 unset register from acquiring a base address (i.e. reg_seen is not
 set).  */
   if (GET_CODE (set) == CLOBBER)
{
  new_reg_base_value[regno] = 0;
  return;
}

by init_alias_target:

   for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
 /* Check whether this register can hold an incoming pointer
argument.  FUNCTION_ARG_REGNO_P tests outgoing register
numbers, so translate if necessary due to register windows.  */
 if (FUNCTION_ARG_REGNO_P (OUTGOING_REGNO (i))
&& HARD_REGNO_MODE_OK (i, Pmode))
   static_reg_base_value[i] = arg_base_value;

and later copied by init_alias_analysis:

   /* Mark all hard registers which may contain an address.
 The stack, frame and argument pointers may contain an address.
 An argument register which can hold a Pmode value may contain
 an address even if it is not in BASE_REGS.

 The address expression is VOIDmode for an argument and
 Pmode for other registers.  */

   memcpy (new_reg_base_value, static_reg_base_value,
  FIRST_PSEUDO_REGISTER * sizeof (rtx));

and that nothing indicates that there was a valid value before the clobber, so
the machinery wrongly records the set at insn 30.  I think the fix is just to
set reg_seen[N] if static_reg_base_value[N] is non-null in the copy above made
by init_alias_analysis.  Tested on x86_64-suse-linux.

Jeff, it's old code of yours, are you OK with this?
Actually I think it's jfc's code; he had a major revamp of alias.c back 
in the early egcs days and getting it integrated was one of the 
project's early wins.  Sadly, jfc hasn't been involved in GCC work for a 
long long time.


Anyway, I think the issue here is that once we set 
new_reg_base_value[regno] to zero, when we do encounter insn 30, we 
assume that's the first set of (reg 4) and we use the RHS as a base value.


The result is we end up with something in new_reg_base_value[4] that is 
not correct for the entire life.  ie, from function entry to the clobber 
(reg 4) has a value totally unrelated to what we've stored in 
new_reg_base_value[4]?  RIght?




My memory of all this is fuzzy, but this code in alias.c is effectively 
trying to compute a set of flow independent base values for each 
register.  If we have two unrelated values going into a register, then 
we need to essentially say we know nothing about its address and the 
aliases that creates.










2013-10-24  Eric Botcazou  

PR rtl-optimization/58831
* alias.c (init_alias_analysis): At the beginning of each iteration, set
the reg_seen[N] bit if static_reg_base_value[N] is non-null.


2013-10-24  Eric Botcazou  

* gcc.c-torture/execute/pr58831.c: New test.

Seems reasonable to me, assuming my understandings noted above are correct.



jeff

Re: question about register pairs

[DJ Delorie]

Yup, my registers are smaller than Pmode.

This is what I ended up with...

Some notes: I lie to gcc and tell it that $fp (reg 22) is two bytes
when it's really one.  None of the register classes have reg 23 (used
for the upper half of $fp) in them.  Reg 23 is also listed as being
two bytes, to keep the register pairing logic in reload in sync for
registers above $fp (otherwise it only checks odd registers afer $fp).

Does this all make sense?

Index: reload.c
===
--- reload.c(revision 203733)
+++ reload.c(working copy)
@@ -723,13 +723,15 @@ find_valid_class_1 (enum machine_mode ou
   unsigned int best_size = 0;
   int cost;
 
   for (rclass = 1; rclass < N_REG_CLASSES; rclass++)
 {
   int bad = 0;
-  for (regno = 0; regno < FIRST_PSEUDO_REGISTER && !bad; regno++)
+  for (regno = 0;
+  regno < FIRST_PSEUDO_REGISTER && !bad;
+  regno += HARD_REGNO_NREGS (regno, mode))
{
  if (in_hard_reg_set_p (reg_class_contents[rclass], mode, regno)
  && !HARD_REGNO_MODE_OK (regno, mode))
bad = 1;
}
   
Index: config/rl78/rl78.h
===
--- config/rl78/rl78.h  (revision 203733)
+++ config/rl78/rl78.h  (working copy)
@@ -242,12 +242,14 @@ enum reg_class
   "V_REGS",\
   "GR_REGS",   \
   "PSWREG",\
   "ALL_REGS"   \
 }
 
+/* Note that no class may include the second register in $fp, because
+   we treat $fp as a single HImode register.  */
 #define REG_CLASS_CONTENTS \
 {  \
   { 0x, 0x },  /* No registers,  */\
   { 0x0001, 0x }, \
   { 0x0002, 0x }, \
   { 0x0003, 0x }, \
Index: config/rl78/rl78.c
===
--- config/rl78/rl78.c  (revision 203733)
+++ config/rl78/rl78.c  (working copy)
@@ -321,19 +321,21 @@ rl78_option_override (void)
   for (i = 24; i < 32; i++)
fixed_regs[i] = 0;
 }
 }
 
 /* Most registers are 8 bits.  Some are 16 bits because, for example,
-   gcc doesn't like dealing with $FP as a register pair.  This table
-   maps register numbers to size in bytes.  */
+   gcc doesn't like dealing with $FP as a register pair (the second
+   half of $fp is also 2 to keep reload happy wrt register pairs, but
+   no register class includes it).  This table maps register numbers
+   to size in bytes.  */
 static const int register_sizes[] =
 {
   1, 1, 1, 1, 1, 1, 1, 1,
   1, 1, 1, 1, 1, 1, 1, 1,
-  1, 1, 1, 1, 1, 1, 2, 1,
+  1, 1, 1, 1, 1, 1, 2, 2,
   1, 1, 1, 1, 1, 1, 1, 1,
   2, 2, 1, 1, 1
 };
 
 /* Predicates used in the MD patterns.  This one is true when virtual
insns may be matched, which typically means before (or during) the

Re: [SH] PR 52483 - Fix volatile mem stores

[Kaz Kojima]

Oleg Endo  wrote:
> The attached patch fixes volatile mem stores on SH so that they won't
> result in redundant sign/zero extensions and will utilize available
> addressing modes.  This is similar to what has been done to fix memory
> loads in http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01315.html
> 
> Tested on rev 203909 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
> 
> and no new failures.
> However, the test result summary showed a bunch of "WARNING: program
> timed out."  Kaz, could you please add it to your test queue and let me
> know if it's OK for trunk?

There are no new failures on my sh4-unknown-linux-gnu tests and
I can't see extra "program timed out" cases for my sh-elf build
on unified tree.

The patch itself looks fine and Ok for trunk.

Regards,
kaz

Re: [Patch] Fix gcc.dg/20050922-*.c

[Hans-Peter Nilsson]

On Thu, 24 Oct 2013, Hans-Peter Nilsson wrote:
> On Mon, 21 Oct 2013, Mike Stump wrote:
>
> > On Oct 21, 2013, at 3:28 AM, Vidya Praveen  wrote:
> > > Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes stdlib.h. This 
> > > can
> > > be a issue especially since they define uint32_t.
> >
> > > OK for 4.7, 4.8?
> >
> > For release branches, you'd need to transition from the
> > theoretical to the practical.  On which systems (software)
> > does
> > it fail?  If none, then no, a back port isn't necessary.  If
> > it
> > fails on a system (or software) on which real users use, then
> > I'll approve it once you name the system (software) and let it
> > bake on trunk for a week and see if anyone objects?
>
> I too would like to include this change on those branches, as
> recent generic newlib changes has caused these tests to break
> (regress) for my autotester for cris-elf testing those branches.

Uhm, I'm on the fence, half-way wanting to retract my
suggestion.  This seems a recent bug in newlib, in which e.g.
#include  causes uint32_t to be defined, bleeding from
newlib-internal include of stdint.h.  On the other hand, testing
that bleed isn't the purpose of these tests.

brgds, H-P

Re: [PATCH][buildrobot] libcpp/lex.c: Use enum properly

[Mike Stump]

On Oct 24, 2013, at 6:25 PM, Andrew Pinski  wrote:
>>  enum raw_str_phase phase = RAW_STR_PREFIX;
> 
> This is a good work around but please add a comment of why this is
> needed (to work around a bug in XLC++).

Oh, curious, I was assuming that file was compiled by the C compiler…  not as 
obvious as I first thought.

Re: [PATCH][buildrobot] libcpp/lex.c: Use enum properly

[Andrew Pinski]

On Thu, Oct 24, 2013 at 6:22 PM, Mike Stump  wrote:
> On Oct 24, 2013, at 2:05 AM, Jan-Benedict Glaw  wrote:
>> -  enum raw_str_phase { RAW_STR_PREFIX, RAW_STR, RAW_STR_SUFFIX };
>> -  raw_str_phase phase = RAW_STR_PREFIX;
>> +  enum raw_str_phase { RAW_STR_PREFIX, RAW_STR, RAW_STR_SUFFIX } phase = 
>> RAW_STR_PREFIX;
>
> Since no one else chimed in…  seems obvious to me…  though the line is too 
> long.  Better likely would be to just say:

No it does not due to in C++ the name is injected without the enum tag too.

>
>   enum raw_str_phase phase = RAW_STR_PREFIX;

This is a good work around but please add a comment of why this is
needed (to work around a bug in XLC++).

Thanks,
Andrew

Re: [PATCH][buildrobot] libcpp/lex.c: Use enum properly

[Mike Stump]

On Oct 24, 2013, at 2:05 AM, Jan-Benedict Glaw  wrote:
> -  enum raw_str_phase { RAW_STR_PREFIX, RAW_STR, RAW_STR_SUFFIX };
> -  raw_str_phase phase = RAW_STR_PREFIX;
> +  enum raw_str_phase { RAW_STR_PREFIX, RAW_STR, RAW_STR_SUFFIX } phase = 
> RAW_STR_PREFIX;

Since no one else chimed in…  seems obvious to me…  though the line is too 
long.  Better likely would be to just say:

  enum raw_str_phase phase = RAW_STR_PREFIX;

[PATCH] Fix names of various macro parameters in tree.h

[David Malcolm]

I noticed that some of the macros in tree.h that act on trees have
parameters named "CODE", rather "NODE", which is confusing when in the
presence of other macros that act on enum tree_code values.

The attached patch renames such params for macros that I believe act on
trees (mostly because they go ahead and lookup the TREE_CODE() of the
param).

Successfully bootstrapped®tested on x86_64-unknown-linux.

OK for trunk?

(fwiw the macros appear to have been this way since they were introduced
in 87675 in 2004-09-17)

gcc/
* tree.h (EXCEPTIONAL_CLASS_P): Rename parameter from "CODE"
to "NODE", since this works on a "tree", not an
"enum tree_code".
(CONSTANT_CLASS_P): Likewise.
(TYPE_P): Likewise.
(DECL_P): Likewise.
(INDIRECT_REF_P): Likewise.
(REFERENCE_CLASS_P): Likewise.
(COMPARISON_CLASS_P): Likewise.
(UNARY_CLASS_P): Likewise.
(BINARY_CLASS_P): Likewise.
(STATEMENT_CLASS_P): Likewise.
(VL_EXP_CLASS_P): Likewise.
(EXPRESSION_CLASS_P): Likewise.
(IS_TYPE_OR_DECL_P): Likewise.

diff --git a/gcc/tree.h b/gcc/tree.h
index 2f4514d..6325e3c 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -90,25 +90,25 @@ along with GCC; see the file COPYING3.  If not see
 
 #define TREE_CODE_CLASS(CODE)	tree_code_type[(int) (CODE)]
 
-/* Nonzero if CODE represents an exceptional code.  */
+/* Nonzero if NODE represents an exceptional code.  */
 
-#define EXCEPTIONAL_CLASS_P(CODE)\
-	(TREE_CODE_CLASS (TREE_CODE (CODE)) == tcc_exceptional)
+#define EXCEPTIONAL_CLASS_P(NODE)\
+	(TREE_CODE_CLASS (TREE_CODE (NODE)) == tcc_exceptional)
 
-/* Nonzero if CODE represents a constant.  */
+/* Nonzero if NODE represents a constant.  */
 
-#define CONSTANT_CLASS_P(CODE)\
-	(TREE_CODE_CLASS (TREE_CODE (CODE)) == tcc_constant)
+#define CONSTANT_CLASS_P(NODE)\
+	(TREE_CODE_CLASS (TREE_CODE (NODE)) == tcc_constant)
 
-/* Nonzero if CODE represents a type.  */
+/* Nonzero if NODE represents a type.  */
 
-#define TYPE_P(CODE)\
-	(TREE_CODE_CLASS (TREE_CODE (CODE)) == tcc_type)
+#define TYPE_P(NODE)\
+	(TREE_CODE_CLASS (TREE_CODE (NODE)) == tcc_type)
 
-/* Nonzero if CODE represents a declaration.  */
+/* Nonzero if NODE represents a declaration.  */
 
-#define DECL_P(CODE)\
-(TREE_CODE_CLASS (TREE_CODE (CODE)) == tcc_declaration)
+#define DECL_P(NODE)\
+(TREE_CODE_CLASS (TREE_CODE (NODE)) == tcc_declaration)
 
 /* True if NODE designates a variable declaration.  */
 #define VAR_P(NODE) \
@@ -119,52 +119,52 @@ along with GCC; see the file COPYING3.  If not see
 #define VAR_OR_FUNCTION_DECL_P(DECL)\
   (TREE_CODE (DECL) == VAR_DECL || TREE_CODE (DECL) == FUNCTION_DECL)
 
-/* Nonzero if CODE represents a INDIRECT_REF.  Keep these checks in
+/* Nonzero if NODE represents a INDIRECT_REF.  Keep these checks in
ascending code order.  */
 
-#define INDIRECT_REF_P(CODE)\
-  (TREE_CODE (CODE) == INDIRECT_REF)
+#define INDIRECT_REF_P(NODE)\
+  (TREE_CODE (NODE) == INDIRECT_REF)
 
-/* Nonzero if CODE represents a reference.  */
+/* Nonzero if NODE represents a reference.  */
 
-#define REFERENCE_CLASS_P(CODE)\
-	(TREE_CODE_CLASS (TREE_CODE (CODE)) == tcc_reference)
+#define REFERENCE_CLASS_P(NODE)\
+	(TREE_CODE_CLASS (TREE_CODE (NODE)) == tcc_reference)
 
-/* Nonzero if CODE represents a comparison.  */
+/* Nonzero if NODE represents a comparison.  */
 
-#define COMPARISON_CLASS_P(CODE)\
-	(TREE_CODE_CLASS (TREE_CODE (CODE)) == tcc_comparison)
+#define COMPARISON_CLASS_P(NODE)\
+	(TREE_CODE_CLASS (TREE_CODE (NODE)) == tcc_comparison)
 
-/* Nonzero if CODE represents a unary arithmetic expression.  */
+/* Nonzero if NODE represents a unary arithmetic expression.  */
 
-#define UNARY_CLASS_P(CODE)\
-	(TREE_CODE_CLASS (TREE_CODE (CODE)) == tcc_unary)
+#define UNARY_CLASS_P(NODE)\
+	(TREE_CODE_CLASS (TREE_CODE (NODE)) == tcc_unary)
 
-/* Nonzero if CODE represents a binary arithmetic expression.  */
+/* Nonzero if NODE represents a binary arithmetic expression.  */
 
-#define BINARY_CLASS_P(CODE)\
-	(TREE_CODE_CLASS (TREE_CODE (CODE)) == tcc_binary)
+#define BINARY_CLASS_P(NODE)\
+	(TREE_CODE_CLASS (TREE_CODE (NODE)) == tcc_binary)
 
-/* Nonzero if CODE represents a statement expression.  */
+/* Nonzero if NODE represents a statement expression.  */
 
-#define STATEMENT_CLASS_P(CODE)\
-	(TREE_CODE_CLASS (TREE_CODE (CODE)) == tcc_statement)
+#define STATEMENT_CLASS_P(NODE)\
+	(TREE_CODE_CLASS (TREE_CODE (NODE)) == tcc_statement)
 
-/* Nonzero if CODE represents a function call-like expression with a
+/* Nonzero if NODE represents a function call-like expression with a
variable-length operand vector.  */
 
-#define VL_EXP_CLASS_P(CODE)\
-	(TREE_CODE_CLASS (TREE_CODE (CODE)) == tcc_vl_exp)
+#define VL_EXP_CLASS_P(NODE)\
+	(TREE_CODE_CLASS (TREE_CODE (NODE)) == tcc_vl_exp)
 
-/* Nonzero if CODE represents any other expression.  */
+/* Nonzero if NODE represents any other expression.  */
 
-#define EXPRESSION_CLASS_P(CODE)\
-	(

Re: wwwdocs / gomp: Update projects/gomp/index.html

[Gerald Pfeifer]

Hi Tobias,

On Thu, 24 Oct 2013, Tobias Burnus wrote:

the attached patch updates the gomp project patch.

(Besides adding an item for the OpenMP 4.0 merge, I removed the "95" from
"Fortran 95" as Fortran is backward compatible and gfortran is effectively a
Fortran 66/77/90/95/2003/2008 compiler [minus bugs and some missing
features].)

OK?


looks good to me, though please give Jakub a bit to chime in in
case.

One thing to consider is replacing "SVN mainline" by "mainline GCC";
that way it's easier to understand and we avoid referring to our
revision control system of the day (well, decade ;-).

Gerald

[PATCH] fixing typo in expr.c to allow proper recognition of complex addresses in some arches.

[Igor Shevlyakov]

I stumbled on a case like this:
If the multipliers allowed for addressing modes are dependent on actual
mode, in some cases compiler
refuses to recognize address as legitimate.
It boils down to this place in expr.c where address_mode is incorrectly
used instead of actual mode.

I rebootstraped and tested on x86_64-linux-gnu but there's no testcase to
see the improved behavior...

Please patch the trunk.
Thanks
Igor

=

2013-10-24  Igor
Shevlyakov
>

* expr.c (expand_expr_real_1): Use proper memory access mode instead of
address_mode
  in the call to memory_address_addr_space.


Index: gcc/expr.c
===
--- gcc/expr.c (revision 204036)
+++ gcc/expr.c (working copy)
@@ -9642,7 +9642,7 @@ expand_expr_real_1 (tree exp, rtx target
   }
  align = get_object_alignment (exp);
  op0 = expand_expr (base, NULL_RTX, VOIDmode, EXPAND_SUM);
- op0 = memory_address_addr_space (address_mode, op0, as);
+ op0 = memory_address_addr_space (mode, op0, as);
  if (!integer_zerop (TREE_OPERAND (exp, 1)))
   {
 rtx off

Re: [PATCH] Vectorizing abs(char/short/int) on x86.

[Cong Hou]

On Wed, Oct 23, 2013 at 11:18 PM, Jakub Jelinek  wrote:
> On Wed, Oct 23, 2013 at 09:40:21PM -0700, Cong Hou wrote:
>> On Wed, Oct 23, 2013 at 8:52 AM, Joseph S. Myers
>>  wrote:
>> > On Tue, 22 Oct 2013, Cong Hou wrote:
>> >
>> >> For abs(char/short), type conversions are needed as the current abs()
>> >> function/operation does not accept argument of char/short type.
>> >> Therefore when we want to get the absolute value of a char_val using
>> >> abs (char_val), it will be converted into abs ((int) char_val). It
>> >> then can be vectorized, but the generated code is not efficient as
>> >> lots of packings and unpackings are envolved. But if we convert
>> >> (char) abs ((int) char_val) to abs (char_val), the vectorizer will be
>> >> able to generate better code. Same for short.
>> >
>> > ABS_EXPR has undefined overflow behavior.  Thus, abs ((int) -128) is
>> > defined (and we also define the subsequent conversion of +128 to signed
>> > char, which ISO C makes implementation-defined not undefined), and
>> > converting to an ABS_EXPR on char would wrongly make it undefined.  For
>> > such a transformation to be valid (in the absence of VRP saying that -128
>> > isn't a possible value) you'd need a GIMPLE representation for
>> > ABS_EXPR, as distinct from ABS_EXPR.
>> > You don't have the option there is for some arithmetic operations of
>> > converting to a corresponding operation on unsigned types.
>> >
>>
>> Yes, you are right. The method I use can guarantee wrapping on
>> overflow (either shift-xor-sub or max(x, -x)). Can I just add the
>> condition if (flag_wrapv) before the conversion I made to prevent the
>> undefined behavior on overflow?
>
> What HW insns you expand to is one thing, but if some GCC pass assumes that
> ABS_EXPR always returns non-negative value (many do, look e.g. at
> tree_unary_nonnegative_warnv_p, extract_range_from_unary_expr_1,
> simplify_const_relational_operation, etc., you'd need to grep for all
> ABS_EXPR/ABS occurrences) and optimizes code based on that fact, you get
> wrong code because (char) abs((char) -128) is well defined.
> If we change ABS_EXPR/ABS definition that it is well defined on the most
> negative value of the typ (resp. mode), then we loose all those
> optimizations, if we do that only for the char/short types, it would be
> quite weird, though we could keep the benefits, but at the RTL level we'd
> need to treat that way all the modes equal to short's mode and smaller (so,
> for sizeof(short) == sizeof(int) target even int's mode).


I checked those functions and they all consider the possibility of
overflow. For example, tree_unary_nonnegative_warnv_p only returns
true for ABS_EXPR on integers if overflow is undefined. If the
consequence of overflow is wrapping, I think converting (char)
abs((int)-128) to abs(-128) (-128 has char type) is safe. Can we do it
by checking flag_wrapv?

I could also first remove the abs conversion content from this patch
but only keep the content of expanding abs() for i386. I will submit
it later.


>
> The other possibility is not to create the ABS_EXPRs of char/short anywhere,
> solve the vectorization issues either through tree-vect-patterns.c or
> as part of the vectorization type demotion/promotions, see the recent
> discussions for that, you'd represent the short/char abs for the vectorized
> loop say using the shift-xor-sub or builtin etc. and if you want to do the
> same thing for scalar code, you'd just have combiner try to match some
> sequence.


Yes, I could do it through tree-vect-patterns.c, if the abs conversion
is prohibited. Currently the only reason I need the abs conversion is
for vectorization.

Vectorization type demotion/promotions is interesting, but I am afraid
we will face the same problem there.


Thank you for your comment!


Cong


>
> Jakub

Re: [Patch] Fix gcc.dg/20050922-*.c

[Mike Stump]

On Oct 24, 2013, at 2:26 AM, Vidya Praveen  wrote:
> On Mon, Oct 21, 2013 at 06:40:28PM +0100, Mike Stump wrote:
>> On Oct 21, 2013, at 3:28 AM, Vidya Praveen  wrote:
>>> Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes stdlib.h. This 
>>> can
>>> be a issue especially since they define uint32_t.
>> 
>>> OK for 4.7, 4.8?
> 
> It fails on arm-none-eabi. 

Ok, let it bake on trunk and then you can back port it if no one screams.

Re: [RFC] PR 58542: const_int vs lost modes

[Richard Henderson]

On 10/24/2013 05:02 AM, Richard Sandiford wrote:
> Do we actually need to do a conversion here at all?  It looks like the
> modes of "expected" and "desired" should already match "mem", so we could
> just use create_input_operand.

This works.  I've committed the following to mainline, and will
test the patch for backport.


r~


PR rtl/58542
* optabs.c (maybe_emit_atomic_exchange): Use create_input_operand
instead of create_convert_operand_to.
(maybe_emit_sync_lock_test_and_set): Likewise.
(expand_atomic_compare_and_swap): Likewise.
(maybe_emit_compare_and_swap_exchange_loop): Don't convert_modes.

diff --git a/gcc/optabs.c b/gcc/optabs.c
index 06a626c..a8a7e4f 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
@@ -7040,8 +7040,7 @@ maybe_emit_atomic_exchange (rtx target, rtx mem, rtx val, 
enum memmodel model)
 
   create_output_operand (&ops[0], target, mode);
   create_fixed_operand (&ops[1], mem);
-  /* VAL may have been promoted to a wider mode.  Shrink it if so.  */
-  create_convert_operand_to (&ops[2], val, mode, true);
+  create_input_operand (&ops[2], val, mode);
   create_integer_operand (&ops[3], model);
   if (maybe_expand_insn (icode, 4, ops))
return ops[0].value;
@@ -7080,8 +7079,7 @@ maybe_emit_sync_lock_test_and_set (rtx target, rtx mem, 
rtx val,
   struct expand_operand ops[3];
   create_output_operand (&ops[0], target, mode);
   create_fixed_operand (&ops[1], mem);
-  /* VAL may have been promoted to a wider mode.  Shrink it if so.  */
-  create_convert_operand_to (&ops[2], val, mode, true);
+  create_input_operand (&ops[2], val, mode);
   if (maybe_expand_insn (icode, 3, ops))
return ops[0].value;
 }
@@ -7123,8 +7121,6 @@ maybe_emit_compare_and_swap_exchange_loop (rtx target, 
rtx mem, rtx val)
 {
   if (!target || !register_operand (target, mode))
target = gen_reg_rtx (mode);
-  if (GET_MODE (val) != VOIDmode && GET_MODE (val) != mode)
-   val = convert_modes (mode, GET_MODE (val), val, 1);
   if (expand_compare_and_swap_loop (mem, target, val, NULL_RTX))
return target;
 }
@@ -7336,8 +7332,8 @@ expand_atomic_compare_and_swap (rtx *ptarget_bool, rtx 
*ptarget_oval,
   create_output_operand (&ops[0], target_bool, bool_mode);
   create_output_operand (&ops[1], target_oval, mode);
   create_fixed_operand (&ops[2], mem);
-  create_convert_operand_to (&ops[3], expected, mode, true);
-  create_convert_operand_to (&ops[4], desired, mode, true);
+  create_input_operand (&ops[3], expected, mode);
+  create_input_operand (&ops[4], desired, mode);
   create_integer_operand (&ops[5], is_weak);
   create_integer_operand (&ops[6], succ_model);
   create_integer_operand (&ops[7], fail_model);
@@ -7358,8 +7354,8 @@ expand_atomic_compare_and_swap (rtx *ptarget_bool, rtx 
*ptarget_oval,
 
   create_output_operand (&ops[0], target_oval, mode);
   create_fixed_operand (&ops[1], mem);
-  create_convert_operand_to (&ops[2], expected, mode, true);
-  create_convert_operand_to (&ops[3], desired, mode, true);
+  create_input_operand (&ops[2], expected, mode);
+  create_input_operand (&ops[3], desired, mode);
   if (!maybe_expand_insn (icode, 4, ops))
return false;
 
diff --git a/gcc/testsuite/gcc.dg/atomic-store-6.c 
b/gcc/testsuite/gcc.dg/atomic-store-6.c
new file mode 100644
index 000..81499cd
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/atomic-store-6.c
@@ -0,0 +1,13 @@
+/* { dg-do run } */
+/* { dg-require-effective-target sync_int_128_runtime } */
+/* { dg-options "-mcx16" { target { i?86-*-* x86_64-*-* } } } */
+
+__int128_t i;
+
+int main()
+{
+  __atomic_store_16(&i, -1, 0);
+  if (i != -1)
+__builtin_abort();
+  return 0;
+}

Re: [PATCH] RFA: Remove mudflap

[Jeff Law]

On 10/24/13 15:53, Marek Polacek wrote:

On Thu, Oct 24, 2013 at 03:22:42PM -0600, Jeff Law wrote:

On 10/24/13 14:56, Steven Bosscher wrote:

Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Obviously
the mudflap specific tests were deleted and not run and were manually
ignored when comparing testsuite runs.

OK for the trunk?



The flags in c.opt should be retained as NOPs. Or maybe even with a
sorry() that mudflap is gone.

Seems reasonable (dummy option, possibly a sorry--deprecated message.

Is there an example NOP option in a .opt file I could crib
somewhere? The .opt files are a complete and utter mystery to me :-)


Perhaps just

fmudflap
C ObjC C++ ObjC++ Ignore Warn(switch %qs is no longer supported)

Note, there are also fmudflapth and fmudflapir options that will need
the same treatment.

Thanks.  I'll give it a whirl tomorrow AM.

jeff

Re: [wwwdocs, patch] gcc-4.9/changes.html: Add quip about "#pragma GCC ivdep" and update Fortran section

[Gerald Pfeifer]

Hi Tobias,

On Thu, 24 Oct 2013, Tobias Burnus wrote:

Any comments? Or is the patch OK?


thanks for doing this.

Index: htdocs/gcc-4.9/changes.html
===
+With the new http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html";
+>#pragma GCC ivdep, the user can assert that there are no
+loop-carried dependencies which would prevent that consecutive iterations 
of
+the following loop can be executed concurrently with SIMD (single 
instruction
+multiple data) instructions.

That would flow a bit nicer if you say "...prevent concurrent execution 
of consecutive iterations using..." or something like that, I believe? 


+allocatable components of variables declared in the main program. The
+Fortran standard states since 2008 explicitly that variables declared
+in the Fortran main program automatically have the SAVE
+attribute.

How about "Since 2008 the Fortran standard..." or "Fortran 2008 and later 
standards..." ?


+  about DO loops with zero iterations.  This warning is now

Good catch!

The patch looks good if you consider my comments (which is not 
necessarily the same as following all of them ;-).


Gerald

Re: [Patch] Fix gcc.dg/20050922-*.c

[Hans-Peter Nilsson]

On Mon, 21 Oct 2013, Mike Stump wrote:

> On Oct 21, 2013, at 3:28 AM, Vidya Praveen  wrote:
> > Tests gcc.dg/20050922-1.c and gcc.dg/20050922-2.c includes stdlib.h. This 
> > can
> > be a issue especially since they define uint32_t.
>
> > OK for 4.7, 4.8?
>
> For release branches, you'd need to transition from the
> theoretical to the practical.  On which systems (software)
> does
> it fail?  If none, then no, a back port isn't necessary.  If
> it
> fails on a system (or software) on which real users use, then
> I'll approve it once you name the system (software) and let it
> bake on trunk for a week and see if anyone objects?

I too would like to include this change on those branches, as
recent generic newlib changes has caused these tests to break
(regress) for my autotester for cris-elf testing those branches.

brgds, H-P

Re: [PATCH] RFA: Remove mudflap

[Marek Polacek]

On Thu, Oct 24, 2013 at 03:22:42PM -0600, Jeff Law wrote:
> On 10/24/13 14:56, Steven Bosscher wrote:
> >>Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Obviously
> >>the mudflap specific tests were deleted and not run and were manually
> >>ignored when comparing testsuite runs.
> >>
> >>OK for the trunk?
> >
> >
> >The flags in c.opt should be retained as NOPs. Or maybe even with a
> >sorry() that mudflap is gone.
> Seems reasonable (dummy option, possibly a sorry--deprecated message.
> 
> Is there an example NOP option in a .opt file I could crib
> somewhere? The .opt files are a complete and utter mystery to me :-)

Perhaps just

fmudflap
C ObjC C++ ObjC++ Ignore Warn(switch %qs is no longer supported)

Note, there are also fmudflapth and fmudflapir options that will need
the same treatment.

Marek

[patch] Fix PR rtl-optimization/58831

[Eric Botcazou]

This is a very old bug in the alias.c machinery, which is exposed during
the sched2 pass.  We have in .split4:

(insn 23 22 24 4 (set (mem/f:DI (reg/v/f:DI 4 si [orig:90 p2 ] [90]) [3 
*p2_9(D)+0 S8 A64])
(symbol_ref:DI ("d")  )) pr58831-1.c:12 85 
{*movdi_internal}
 (expr_list:REG_DEAD (reg/v/f:DI 4 si [orig:90 p2 ] [90])
(nil)))

[...]

(insn 61 27 62 6 (clobber (reg:DI 4 si)) -1
 (nil))

(insn/f 62 61 56 6 (parallel [
(set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(reg:DI 4 si))
(clobber (mem:BLK (scratch) [0 A8]))
]) pr58831-1.c:8 73 {*pushdi2_prologue}
 (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -8 [0xfff8])))
(nil)))

[...]

(insn 30 29 31 6 (set (reg:DI 4 si)
(symbol_ref/f:DI ("*.LC0") [flags 0x2]  )) pr58831-1.c:14 85 {*movdi_internal}
 (nil))

si is the 2nd argument register on x86-64 so it's live on entry.  The problem
is that the clobber at insn 61 wipes out the value recorded for si:

  /* A CLOBBER wipes out any old value but does not prevent a previously
 unset register from acquiring a base address (i.e. reg_seen is not
 set).  */
  if (GET_CODE (set) == CLOBBER)
{
  new_reg_base_value[regno] = 0;
  return;
}

by init_alias_target:

  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
/* Check whether this register can hold an incoming pointer
   argument.  FUNCTION_ARG_REGNO_P tests outgoing register
   numbers, so translate if necessary due to register windows.  */
if (FUNCTION_ARG_REGNO_P (OUTGOING_REGNO (i))
&& HARD_REGNO_MODE_OK (i, Pmode))
  static_reg_base_value[i] = arg_base_value;

and later copied by init_alias_analysis:

  /* Mark all hard registers which may contain an address.
 The stack, frame and argument pointers may contain an address.
 An argument register which can hold a Pmode value may contain
 an address even if it is not in BASE_REGS.

 The address expression is VOIDmode for an argument and
 Pmode for other registers.  */

  memcpy (new_reg_base_value, static_reg_base_value,
  FIRST_PSEUDO_REGISTER * sizeof (rtx));

and that nothing indicates that there was a valid value before the clobber, so 
the machinery wrongly records the set at insn 30.  I think the fix is just to 
set reg_seen[N] if static_reg_base_value[N] is non-null in the copy above made 
by init_alias_analysis.  Tested on x86_64-suse-linux.

Jeff, it's old code of yours, are you OK with this?


2013-10-24  Eric Botcazou  

PR rtl-optimization/58831
* alias.c (init_alias_analysis): At the beginning of each iteration, set
the reg_seen[N] bit if static_reg_base_value[N] is non-null.


2013-10-24  Eric Botcazou  

* gcc.c-torture/execute/pr58831.c: New test.


-- 
Eric Botcazou#include 

int a, *b, c, d, f, **i, p, q, *r;
short o, j;

static int __attribute__((noinline, noclone))
fn1 (int *p1, int **p2)
{
  int **e = &b;
  for (; p; p++)
*p1 = 1;
  *e = *p2 = &d;

  assert (r);

  return c;
}

static int ** __attribute__((noinline, noclone))
fn2 (void)
{
  for (f = 0; f != 42; f++)
{
  int *g[3] = {0, 0, 0};
  for (o = 0; o; o--)
for (; a > 1;)
  {
int **h[1] = { &g[2] };
  }
}
  return &r;
}

int
main (void)
{
  i = fn2 ();
  fn1 (b, i);
  return 0;
}Index: alias.c
===
--- alias.c	(revision 203876)
+++ alias.c	(working copy)
@@ -2975,16 +2975,13 @@ init_alias_analysis (void)
   /* Wipe the reg_seen array clean.  */
   bitmap_clear (reg_seen);
 
-  /* Mark all hard registers which may contain an address.
-	 The stack, frame and argument pointers may contain an address.
-	 An argument register which can hold a Pmode value may contain
-	 an address even if it is not in BASE_REGS.
-
-	 The address expression is VOIDmode for an argument and
-	 Pmode for other registers.  */
-
-  memcpy (new_reg_base_value, static_reg_base_value,
-	  FIRST_PSEUDO_REGISTER * sizeof (rtx));
+  /* Initialize the alias information for this pass.  */
+  for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
+	if (static_reg_base_value[i])
+	  {
+	new_reg_base_value[i] = static_reg_base_value[i];
+	bitmap_set_bit (reg_seen, i);
+	  }
 
   /* Walk the insns adding values to the new_reg_base_value array.  */
   for (i = 0; i < rpo_cnt; i++)

Re: [PATCH] RFA: Remove mudflap

[Jeff Law]

On 10/24/13 14:56, Steven Bosscher wrote:

Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Obviously
the mudflap specific tests were deleted and not run and were manually
ignored when comparing testsuite runs.

OK for the trunk?



The flags in c.opt should be retained as NOPs. Or maybe even with a
sorry() that mudflap is gone.

Seems reasonable (dummy option, possibly a sorry--deprecated message.

Is there an example NOP option in a .opt file I could crib somewhere? 
The .opt files are a complete and utter mystery to me :-)


jeff

[jit] Add fuzz-testing program for API

[David Malcolm]

Committed to dmalcolm/jit branch:

This is a work-in-progress, and currently doesn't achieve very deep
coverage of the code, due to mismatching types.

gcc/testsuite/
* jit.dg/harness.h (main): Wrap with #ifndef TEST_PROVIDES_MAIN
* jit.dg/test-fuzzer.c: New.
---
 gcc/testsuite/ChangeLog.jit|   5 +
 gcc/testsuite/jit.dg/harness.h |   3 +
 gcc/testsuite/jit.dg/test-fuzzer.c | 458 +
 3 files changed, 466 insertions(+)
 create mode 100644 gcc/testsuite/jit.dg/test-fuzzer.c

diff --git a/gcc/testsuite/ChangeLog.jit b/gcc/testsuite/ChangeLog.jit
index 0476507..18b6d9a 100644
--- a/gcc/testsuite/ChangeLog.jit
+++ b/gcc/testsuite/ChangeLog.jit
@@ -1,3 +1,8 @@
+2013-10-24  David Malcolm  
+
+   * jit.dg/harness.h (main): Wrap with #ifndef TEST_PROVIDES_MAIN
+   * jit.dg/test-fuzzer.c: New.
+
 2013-10-22  David Malcolm  
 
* jit.dg/harness.h (verify_code): Add context param so that
diff --git a/gcc/testsuite/jit.dg/harness.h b/gcc/testsuite/jit.dg/harness.h
index 8e75924..353c7c1 100644
--- a/gcc/testsuite/jit.dg/harness.h
+++ b/gcc/testsuite/jit.dg/harness.h
@@ -162,6 +162,7 @@ extract_progname (const char *argv0)
   return p;
 }
 
+#ifndef TEST_PROVIDES_MAIN
 int
 main (int argc, char **argv)
 {
@@ -183,4 +184,6 @@ main (int argc, char **argv)
 
   return 0;
 }
+#endif /* #ifndef TEST_PROVIDES_MAIN */
+
 #endif /* #ifndef TEST_COMBINATION */
diff --git a/gcc/testsuite/jit.dg/test-fuzzer.c 
b/gcc/testsuite/jit.dg/test-fuzzer.c
new file mode 100644
index 000..d35286b
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-fuzzer.c
@@ -0,0 +1,458 @@
+/* Fuzz-testing of libgccjit API.
+   Currently this triggers internal compiler errors, typically due to type
+   mismatches.  */
+#include 
+#include 
+#include 
+#include 
+
+#include "libgccjit.h"
+
+#define TEST_PROVIDES_MAIN
+#include "harness.h"
+
+typedef struct fuzzer
+{
+  gcc_jit_context *ctxt;
+
+  unsigned int seed;
+
+  int num_types;
+  gcc_jit_type **types;
+
+  int num_globals;
+  gcc_jit_lvalue **globals;
+
+  int num_funcs;
+  gcc_jit_function **funcs;
+
+} fuzzer;
+
+static void
+fuzzer_init (fuzzer *f, gcc_jit_context *ctxt, unsigned int seed);
+
+static int
+fuzzer_randrange (fuzzer *f, int min, int max);
+
+static gcc_jit_location *
+get_random_location (fuzzer *f);
+
+static gcc_jit_type *
+get_random_type (fuzzer *f);
+
+static gcc_jit_type *
+make_random_type (fuzzer *f);
+
+static gcc_jit_lvalue *
+make_random_global (fuzzer *f);
+
+static gcc_jit_function *
+make_random_function (fuzzer *f);
+
+typedef struct function_fuzzer
+{
+  fuzzer *f;
+
+  int num_params;
+  gcc_jit_param **params;
+
+  gcc_jit_function *fn;
+
+  int num_locals;
+  gcc_jit_lvalue **locals;
+
+} function_fuzzer;
+
+static void
+function_fuzzer_add_stmt (function_fuzzer *ff);
+
+static gcc_jit_lvalue *
+get_random_lvalue (function_fuzzer *ff, int max_depth);
+
+static gcc_jit_rvalue *
+get_random_rvalue (function_fuzzer *ff, int max_depth);
+
+/* fuzzer defns.  */
+
+static void
+fuzzer_init (fuzzer *f, gcc_jit_context *ctxt, unsigned int seed)
+{
+  int i;
+  memset (f, 0, sizeof (*f));
+  f->ctxt = ctxt;
+  f->seed = seed;
+
+  int num_types = fuzzer_randrange (f, 5, 10);
+  f->types = malloc (num_types * sizeof (gcc_jit_type *));
+
+  int num_funcs = fuzzer_randrange (f, 3, 5);
+  f->funcs = malloc (num_funcs * sizeof (gcc_jit_function *));
+
+  int num_globals = fuzzer_randrange (f, 5, 10);
+  f->globals = malloc (num_globals * sizeof (gcc_jit_lvalue *));
+
+  for (i = 0; i < num_types; i++)
+{
+  gcc_jit_type *type = make_random_type (f);
+  assert (type);
+  f->types[f->num_types++] = type;
+}
+
+  for (i = 0; i < num_globals; i++)
+f->globals[f->num_globals++] = make_random_global (f);
+
+  for (i = 0; i < num_funcs; i++)
+f->funcs[f->num_funcs++] = make_random_function (f);
+}
+
+/* Get random int in inclusive range [min, max].  */
+
+static int fuzzer_randrange (fuzzer *f, int min, int max)
+{
+  assert (min <= max);
+  int i = rand_r (&f->seed);
+  int result = (i % (max + 1 - min)) + min;
+  assert (result >= min);
+  assert (result <= max);
+  return result;
+}
+
+static gcc_jit_location *
+get_random_location (fuzzer *f)
+{
+  const char *filename = NULL;
+
+  if (fuzzer_randrange (f, 0, 1))
+return NULL;
+
+  switch (fuzzer_randrange (f, 1, 2))
+{
+case 1:
+  filename = "foo.c";
+  break;
+case 2:
+  filename = "bar.c";
+  break;
+}
+
+  return gcc_jit_context_new_location (f->ctxt,
+  filename,
+  fuzzer_randrange (f, 1, 1000),
+  fuzzer_randrange (f, 1, 1000));
+}
+
+const enum gcc_jit_types types[] = {
+  GCC_JIT_TYPE_VOID,
+
+  GCC_JIT_TYPE_VOID_PTR,
+
+  GCC_JIT_TYPE_CHAR,
+  GCC_JIT_TYPE_SIGNED_CHAR,
+  GCC_JIT_TYPE_UNSIGNED_CHAR,
+
+  GCC_JIT_TYPE_SHORT,
+  GCC_JIT_TYPE_UNSIGNED_SHORT,
+
+  GCC_JIT_TYPE_INT,
+

[RFC] Fix context-sensitiveness of peephole2 pass

[Eric Botcazou]

As discovered by Richard B. under PR rtl-optimization/58831, the peephole2 
pass has been context-sensitive for a long time when scratch registers are 
needed, in the sense that the behaviour of the pass for a given function is 
dependent on what happened for the previously optimized function.

Obvious patch attached, tested on x86_64-suse-linux.  Do we want to apply it 
on mainline only or on all the active branches?


2013-10-24  Eric Botcazou  

* recog.c (search_ofs): New static variable moved from...
(peep2_find_free_register): ...here.
(peephole2_optimize): Initialize it.


-- 
Eric BotcazouIndex: recog.c
===
--- recog.c	(revision 203876)
+++ recog.c	(working copy)
@@ -3068,6 +3068,9 @@ peep2_reg_dead_p (int ofs, rtx reg)
   return 1;
 }
 
+/* Regno offset to be used in the register search.  */
+static int search_ofs;
+
 /* Try to find a hard register of mode MODE, matching the register class in
CLASS_STR, which is available at the beginning of insn CURRENT_INSN and
remains available until the end of LAST_INSN.  LAST_INSN may be NULL_RTX,
@@ -3083,7 +3086,6 @@ rtx
 peep2_find_free_register (int from, int to, const char *class_str,
 			  enum machine_mode mode, HARD_REG_SET *reg_set)
 {
-  static int search_ofs;
   enum reg_class cl;
   HARD_REG_SET live;
   df_ref *def_rec;
@@ -3548,6 +3550,7 @@ peephole2_optimize (void)
   /* Initialize the regsets we're going to use.  */
   for (i = 0; i < MAX_INSNS_PER_PEEP2 + 1; ++i)
 peep2_insn_data[i].live_before = BITMAP_ALLOC (®_obstack);
+  search_ofs = 0;
   live = BITMAP_ALLOC (®_obstack);
 
   FOR_EACH_BB_REVERSE (bb)

Re: [PATCH] RFA: Remove mudflap

[Steven Bosscher]

On Thu, Oct 24, 2013 at 10:35 PM, Jeff Law wrote:
> On 10/24/13 07:40, Richard Biener wrote:

 we were supposed to remove mudflap for 4.9, no?


>>> Really?  I guess it hasn't been removed yet since the include is still
>>> there?  who is doing that?
>>
>>
>> Yeah, nobody has done it yet appearantly :/
>
> Well, here we go...

Good riddance...



> Bootstrapped and regression tested on x86_64-unknown-linux-gnu. Obviously
> the mudflap specific tests were deleted and not run and were manually
> ignored when comparing testsuite runs.
>
> OK for the trunk?


The flags in c.opt should be retained as NOPs. Or maybe even with a
sorry() that mudflap is gone.

Ciao!
Steven

[jit] Fix various issues relating to gcc_jit_location.

[David Malcolm]

I've committed the following fixes to the dmalcolm/jit branch:

(Found via fuzz testing)

gcc/jit/
* internal-api.c (gcc::jit::function::add_eval): Handle non-NULL
locations.
(gcc::jit::context::handle_locations): Fix test for the various
kinds of declarations, replacing use of DECL_MINIMAL_CHECK,
which aborts on failure (such as if we saw a type).
* libgccjit.h (GCC_JIT_BOOL_OPTION_DEBUGINFO): Fix out-of-date
comment.
---
 gcc/jit/ChangeLog.jit  | 10 ++
 gcc/jit/internal-api.c |  6 --
 gcc/jit/libgccjit.h|  4 ++--
 3 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/gcc/jit/ChangeLog.jit b/gcc/jit/ChangeLog.jit
index 6308c6d..30664be 100644
--- a/gcc/jit/ChangeLog.jit
+++ b/gcc/jit/ChangeLog.jit
@@ -1,3 +1,13 @@
+2013-10-24  David Malcolm  
+
+   * internal-api.c (gcc::jit::function::add_eval): Handle non-NULL
+   locations.
+   (gcc::jit::context::handle_locations): Fix test for the various
+   kinds of declarations, replacing use of DECL_MINIMAL_CHECK,
+   which aborts on failure (such as if we saw a type).
+   * libgccjit.h (GCC_JIT_BOOL_OPTION_DEBUGINFO): Fix out-of-date
+   comment.
+
 2013-10-23  David Malcolm  
 
* internal-api.c: Update for rename of tree-flow.h to tree-cfg.h
diff --git a/gcc/jit/internal-api.c b/gcc/jit/internal-api.c
index 574aef0..b21aaa6 100644
--- a/gcc/jit/internal-api.c
+++ b/gcc/jit/internal-api.c
@@ -883,10 +883,12 @@ gcc::jit::function::
 add_eval (location *loc,
  rvalue *rvalue)
 {
-  gcc_assert (NULL == loc);
   gcc_assert (rvalue);
   gcc_assert (m_kind != GCC_JIT_FUNCTION_IMPORTED);
 
+  if (loc)
+set_tree_location (rvalue->as_tree (), loc);
+
   tsi_link_after (&m_stmt_iter, rvalue->as_tree (), TSI_CONTINUE_LINKING);
 }
 
@@ -1444,7 +1446,7 @@ handle_locations ()
   /* This covers expressions: */
   if (CAN_HAVE_LOCATION_P (t))
SET_EXPR_LOCATION (t, srcloc);
-  else if (DECL_MINIMAL_CHECK (t))
+  else if (CODE_CONTAINS_STRUCT(TREE_CODE(t), TS_DECL_MINIMAL))
DECL_SOURCE_LOCATION (t) = srcloc;
   else
{
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index f058162..0712533 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -144,8 +144,8 @@ enum gcc_jit_bool_option
  be able to inspect variables and step through your code.
 
  Note that you can't step through code unless you set up source
- location information for the code, and that isn't yet supported
- in the API.  */
+ location information for the code (by creating and passing in
+ gcc_jit_location instances).  */
   GCC_JIT_BOOL_OPTION_DEBUGINFO,
 
   /* If true, gcc_jit_context_compile will dump its initial "tree"
-- 
1.7.11.7

Re: [Patch, C++] Add C++ FE support for #pragma ivdep

[Jason Merrill]

On 10/10/2013 04:46 AM, Tobias Burnus wrote:

I considered to add the annotation also to C++11's range-based loops,
but as those are unlikely to vectorize, I didn't do so.


I would think that a range-based loop over an array should vectorize nicely:

int ar[8];
for (int i: ar) { ... }

But your most recent patch is OK.

Jason

Re: [wide-int] Make the main tree decompose cheaper

[Richard Sandiford]

Richard Biener  writes:
> On Wed, 23 Oct 2013, Richard Sandiford wrote:
>> This patch stores two array lengths in an INTEGER_CST: the length that
>> should be used when accessing the constant in its TYPE_PRECISION,
>> and the one that should be used for wider precisions.  This means that
>> the main tree decompose routine is just a simple storage_ref constructor.
>> It also means that cst_fits_shwi_p can be simplified back to its earlier
>> form (before r203602).
>> 
>> The patch also fixes wi::extended_tree ::get_len so that it uses
>> the right length when a tree has the same precision as addr_wide_int.
>> I just noticed this by inspection, I don't have a testcase.
>> 
>> (It might be better to require "address" trees to be smaller than
>> addr_wide_int though -- I can look into that if you agree.  But just
>> changing:
>> 
>>   gcc_checking_assert (TYPE_PRECISION (TREE_TYPE (t)) <= N);
>> 
>> to:
>> 
>>   gcc_checking_assert (TYPE_PRECISION (TREE_TYPE (t)) < N);
>> 
>> did trigger when I tried it in the first version of the wi::address patch.)
>> 
>> Tested on powerpc64-linux-gnu.  OK for wide-int?
>
> I like how this simplifies code, still storing two lengths is a bit
> odd ... ah well.
>
> Minor nits:
>
> + /* Make sure no one is clobbering the shared constant.  We
> +must be careful here because tree-csts and wide-ints are
> +not canonicalized in the same way.  */
> + gcc_assert (TREE_TYPE (t) == type);
> + gcc_assert (TREE_INT_CST_NUNITS (t) == 1);
> + gcc_assert (TREE_INT_CST_EXT_NUNITS (t) == 1);
> + gcc_assert (TREE_INT_CST_ELT (t, 0) == hwi);
>
> please merge into a single gcc_assert.

OK.

>> +/* The number of HOST_WIDE_INTs in an INTEGER_CST.  */
>> +struct {
>> +  /* The number of HOST_WIDE_INTs if the INTEGER_CST is accessed in
>> +  its native precision.  */
>> +  unsigned short unextended;
>> +
>> +  /* The number of HOST_WIDE_INTs if the INTEGER_CST is extended to
>> +  wider precisions based on its TYPE_SIGN.  */
>> +  unsigned short extended;
>> +} split_length;
>
> split_length sounds generic while unextended and extended not.  I suggest
> to either rename split_length to something clearly integer constant
> specific or renaming unextended and extended to length1 and length2.

Yeah, good point.  I changed it to "int_length" instead.

Committed with those changes, thanks.

Richard

Re: [PATCH][ubsan] Add VLA bound instrumentation

[Jason Merrill]

On 09/25/2013 08:41 AM, Marek Polacek wrote:

+  /* Do the instrumentation of VLAs if desired.  */
+  if ((flag_sanitize & SANITIZE_VLA)
+  && size && !TREE_CONSTANT (size)
+  /* From C++1y onwards, we throw an exception on a negative length size
+ of an array.  */
+  && cxx_dialect < cxx1y)


This code is in a completely different place from the C++1y code in 
cp_finish_decl; they should be in the same place.  I'm also concerned 
that doing it here will mean adding sanitization code to template 
definitions, but I think we want to wait to add it until instantiation time.



+  /* Prevent bogus set-but-not-used warnings: we're definitely using
+ the variable.  */
+  if (VAR_P (size))
+DECL_READ_P (size) = 1;


Use mark_rvalue_use for this.

Jason

wwwdocs / gomp: Update projects/gomp/index.html

[Tobias Burnus]

Hi Jakub and Gerald,

the attached patch updates the gomp project patch.

(Besides adding an item for the OpenMP 4.0 merge, I removed the "95" 
from "Fortran 95" as Fortran is backward compatible and gfortran is 
effectively a Fortran 66/77/90/95/2003/2008 compiler [minus bugs and 
some missing features].)


OK?

Tobias

PS: One site which links to that page is 
http://openmp.org/wp/openmp-compilers/
Index: htdocs/projects/gomp/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/gomp/index.html,v
retrieving revision 1.12
diff -u -p -r1.12 index.html
--- htdocs/projects/gomp/index.html	17 Sep 2011 22:21:35 -	1.12
+++ htdocs/projects/gomp/index.html	24 Oct 2013 19:50:15 -
@@ -9,8 +9,8 @@
 
 The GOMP project has developed an implementation of
 http://openmp.org/wp/";>OpenMP
-for the C, C++, and Fortran
-95 compilers in the GNU
+for the C, C++, and Fortran
+compilers in the GNU
 Compiler Collection and is further improving it. As part of the GNU Project, GOMP
 simplifies parallel programming for all GNU system variants. This
@@ -63,6 +63,10 @@ available.
 
 Status
 
+Oct 11, 2013
+The gomp-4_0-branch has been merged into SVN
+mainline, so GCC 4.9 and later will feature OpenMP v4.0 support.
+
 Aug 2, 2011
 The gomp-3_1-branch has been merged into SVN
 mainline, so GCC 4.7 and later will feature OpenMP v3.1 support.

Re: [RFC] Isolate & simplify paths with undefined behaviour

[Jeff Law]

On 10/23/13 07:05, Richard Biener wrote:

Btw, -ftree-isolate-paths sounds a bit generic for isolating paths leading
to undefined behavior, maybe -fisolate-errorneous-paths?  (please drop
'tree-' from new options, 'tree' isn't meaningful to GCC users)
Seems reasonable, particularly since I think this can and should be 
easily extended for things like out-of-bounds array accesses and perhaps 
other stuff.  Oh yea, it'll be -fisolate-erroneous-paths.  Done.




The file should be named gimple-ssa-isolate-paths.c, too.

Done.



+   for (si = gsi_start_nondebug_bb (bb), si2 = gsi_start_nondebug_bb
(duplicate);
+!gsi_end_p (si) && !gsi_end_p (si2);
+gsi_next_nondebug (&si), gsi_next_nondebug (&si2))
+ {
+   while (gimple_code (gsi_stmt (si)) == GIMPLE_LABEL)
+   gsi_next_nondebug (&si);

gsi_after_labels (bb);
if (is_gimple_debug (gsi_stmt (gsi)))
   gsi_next_nondebug (&gsi);

warrants a new gsi_nondebug_after_labels ()

I assume you meant gsi_start_nondebug_after_labels_bb.  Once we hit the
first real statement in a BB  we shouldn't see any more labels in that 
block, so we just need to use gsi_next_nondebug after that.








+   /* SI2 is the iterator in the duplicate block and it now points
+to our victim statement.  */
+   gimple_seq seq = NULL;
+   tree t = build_call_expr_loc (0,
+   builtin_decl_explicit (BUILT_IN_TRAP), 0);
+   gimplify_and_add (t, &seq);
+   gsi_insert_before (&si2, seq, GSI_SAME_STMT);

please build a gimple call stmt directly instead of going through the
gimplifier.
I can't recall where I got that gem (wherever it was it should be fixed 
too), but yea, going through the gimplifier is dumb.  Fixed.





+ if (operand_equal_p (op, integer_zero_node, 0))

integer_zerop ()
Fixed.  Note this instance goes away, but there was another in the 
stanza which detected explicit NULL pointer dereferences in the IL.




+ /* We've got a NULL PHI argument.  Now see if the
+PHI's result is dereferenced within BB.  */
+ FOR_EACH_IMM_USE_STMT (use_stmt, iter, lhs)
+   {
+ unsigned int j;
+ bool removed_edge = false;
+
+ /* We only care about uses in BB which are assignements
+with memory operands.
+
+We could see if any uses are as function arguments
+when the callee has marked the argument as being
+non-null.  */
+ if (gimple_bb (use_stmt) != bb
+ || !gimple_has_mem_ops (use_stmt)
+ || gimple_code (use_stmt) != GIMPLE_ASSIGN)

!is_gimple_assign (), you can drop the has_mem_ops check, but ...

+   continue;
+
+ /* Look at each operand for a memory reference using
+LHS.  */

... you want to use walk_stmt_load_store_ops () which handles all kinds
of stmts fine.
Actually for this code Marc Glisse recommended infer_nonnull_range, and 
I'm in agreement.






+ for (j = 0; j < gimple_num_ops (use_stmt); j++)
+   {
+ tree op = gimple_op (use_stmt, j);
+
+ if (op == NULL)
+   continue;
+
+ while (handled_component_p (op))
+   op = TREE_OPERAND (op, 0);
+
+ if ((TREE_CODE (op) == MEM_REF
+  || TREE_CODE (op) == INDIRECT_REF)

no more INDIRECT_REFs are in the IL.
Oh.  I learn something every day.  I vaguely recall discussing MEM_REF 
at a summit years ago, but I was a bit pre-occupied with personal 
matters.  I guess it totally subsumed INDIRECT_REF at this stage in the 
compiler.  Can't complain about that :-)


I'll need to rework the second stanza which detects NULL dereferences 
explicitly appearing in the IL a bit, but it shouldn't be too difficult.


Thanks for the feedback,
Jeff

[wwwdocs, patch] gcc-4.9/changes.html: Add quip about "#pragma GCC ivdep" and update Fortran section

[Tobias Burnus]

Dear Gerald, dear all,

the patch adds a quip about the new "#pragma GCC ivdep" to the release 
notes. Additionally, I updated the Fortran section based on the changes 
accumulated on http://gcc.gnu.org/wiki/GFortran#news


Any comments? Or is the patch OK?

Tobias
Index: htdocs/gcc-4.9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.28
diff -u -p -r1.28 changes.html
--- htdocs/gcc-4.9/changes.html	3 Oct 2013 14:15:36 -	1.28
+++ htdocs/gcc-4.9/changes.html	24 Oct 2013 19:44:28 -
@@ -84,6 +84,13 @@
 
 test.C:2:46: error: incomplete type ‘X<100>’ used in nested name specifier
 
+
+With the new http://gcc.gnu.org/onlinedocs/gcc/Loop_002dSpecific-Pragmas.html";
+>#pragma GCC ivdep, the user can assert that there are no
+loop-carried dependencies which would prevent that consecutive iterations of
+the following loop can be executed concurrently with SIMD (single instruction
+multiple data) instructions.
  
 
 

Re: Debug functions review

[François Dumont]

On 10/24/2013 12:12 AM, Paolo Carlini wrote:

On 10/23/2013 11:22 PM, François Dumont wrote:
You are right, I am preparing a test case. However you have to know 
that __check_dereferenceable is simply not used for the moment. It is 
only because I have started using it for a debug mode evolution that 
I discovered the issue.
Ok, thanks. Now however I'm curious to know the story of 
__check_dereferenceable: dates back to when Doug added debug-mode and 
never used since? Any idea?


Paolo.


Don't know __check_dereferenceable story, nothing in ChangeLogs.

Here is my new proposal with tests. I finally restore 
__check_singular_aux, don't know why __check_singular(const 
_Safe_Iterator<>&) didn't work. I even completely removed it as 
__check_singular_aux works well for all kind of safe iterators 
inheriting from _Safe_iterator_base.


2013-10-24  François Dumont  

* include/debug/formatter.h (__check_singular): Add const on
iterator reference.
* include/debug/functions.h (__check_singular): Likewise.
(__check_singular(const _Safe_iterator<_Ite, _Seq>&)): Delete.
(__check_dereferenceable(const _Ite&)): Add const on iterator
reference.
(__check_dereferenceable(const _Safe_local_iterator<>&)): New.
* include/debug/safe_iterator.h (__check_singular_aux): Review
comment.
* testsuite/23_containers/vector/debug/debug_functions.cc: New.
* testsuite/23_containers/unordered_set/debug/debug_functions.cc:
New.

Tested under Linux x86_64, normal and debug mode.

Ok to commit ?

François

Index: include/debug/formatter.h
===
--- include/debug/formatter.h	(revision 204032)
+++ include/debug/formatter.h	(working copy)
@@ -38,7 +38,7 @@
   using std::type_info;
 
   template
-bool __check_singular(_Iterator&);
+bool __check_singular(const _Iterator&);
 
   class _Safe_sequence_base;
 
Index: include/debug/functions.h
===
--- include/debug/functions.h	(revision 204032)
+++ include/debug/functions.h	(working copy)
@@ -45,6 +45,9 @@
   template
 class _Safe_iterator;
 
+  template
+class _Safe_local_iterator;
+
   template
 struct _Insert_range_from_self_is_safe
 { enum { __value = 0 }; };
@@ -57,7 +60,7 @@
   // a _Safe_iterator.
   template
 inline bool
-__check_singular(_Iterator& __x)
+__check_singular(const _Iterator& __x)
 { return __check_singular_aux(&__x); }
 
   /** Non-NULL pointers are nonsingular. */
@@ -66,17 +69,11 @@
 __check_singular(const _Tp* __ptr)
 { return __ptr == 0; }
 
-  /** Safe iterators know if they are singular. */
-  template
-inline bool
-__check_singular(const _Safe_iterator<_Iterator, _Sequence>& __x)
-{ return __x._M_singular(); }
-
   /** Assume that some arbitrary iterator is dereferenceable, because we
   can't prove that it isn't. */
   template
 inline bool
-__check_dereferenceable(_Iterator&)
+__check_dereferenceable(const _Iterator&)
 { return true; }
 
   /** Non-NULL pointers are dereferenceable. */
@@ -85,12 +82,19 @@
 __check_dereferenceable(const _Tp* __ptr)
 { return __ptr; }
 
-  /** Safe iterators know if they are singular. */
+  /** Safe iterators know if they are dereferenceable. */
   template
 inline bool
 __check_dereferenceable(const _Safe_iterator<_Iterator, _Sequence>& __x)
 { return __x._M_dereferenceable(); }
 
+  /** Safe local iterators know if they are dereferenceable. */
+  template
+inline bool
+__check_dereferenceable(const _Safe_local_iterator<_Iterator,
+		   _Sequence>& __x)
+{ return __x._M_dereferenceable(); }
+
   /** If the distance between two random access iterators is
*  nonnegative, assume the range is valid.
   */
Index: include/debug/safe_iterator.h
===
--- include/debug/safe_iterator.h	(revision 204032)
+++ include/debug/safe_iterator.h	(working copy)
@@ -56,10 +56,9 @@
   { return __it == __seq->_M_base().begin(); }
 };
 
-  /** Iterators that derive from _Safe_iterator_base but that aren't
-   *  _Safe_iterators can be determined singular or non-singular via
-   *  _Safe_iterator_base.
-   */
+  /** Iterators that derive from _Safe_iterator_base can be determined singular
+   *  or non-singular.
+   **/
   inline bool 
   __check_singular_aux(const _Safe_iterator_base* __x)
   { return __x->_M_singular(); }
Index: testsuite/23_containers/unordered_set/debug/debug_functions.cc
===
--- testsuite/23_containers/unordered_set/debug/debug_functions.cc	(revision 0)
+++ testsuite/23_containers/unordered_set/debug/debug_functions.cc	(revision 0)
@@ -0,0 +1,92 @@
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistr

Re: [Patch, C++] Add C++ FE support for #pragma GCC ivdep

[Tobias Burnus]

Another small update: Due to a ME review comment, the way ANNOTATE_EXPR 
are built has changed.


The patch was tested together with the (now committed) ME/C/Fortran 
patch in an all-language bootstrap and regtesting on x86-64-gnu-linux.

Is the C++ patch okay for the trunk?

Tobias


On October 22, 2013, Tobias Burnus wrote:
*PING* - with a slightly updated patch attached. Changes: New test 
case for an error message plus matching the wording to the C version.


Tobias

On October 10, 2013, Tobias Burnus wrote:
This patch depends on the middle-end / C FE patch: 
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00655.html


It adds parsing support for #pragma ivdep and annotates the condition 
of C-like for loops such that one can later set the vectorization 
safe length (loop->safelen) to INT_MAX.  I considered to add the 
annotation also to C++11's range-based loops, but as those are 
unlikely to vectorize, I didn't do so. (If one does, one might end up 
having a CLEANUP_POINT_EXPR around the annotate; that implies that 
the annotate internal function is not the direct predecessor of the 
GIMPLE_COND.)


Another question is how much diagnostic one gives, e.g. when there is 
no condition: Should there be an error, a warning or should the 
pragma then silently ignored?


Build and regtested on x86-64-gnu-linux.
OK for the trunk?

Tobias




2013-08-24  Tobias Burnus  

	PR other/33426
	* parser.c (cp_parser_iteration_statement,
	cp_parser_for, cp_parser_c_for, cp_parser_pragma): Handle
	IVDEP pragma.

	* g++.dg/parse/ivdep.C: New.
	* g++.dg/vect/pr33426-ivdep.cc: New.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index c5d19a4..8deffc3 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -1970,13 +1970,13 @@ static tree cp_parser_selection_statement
 static tree cp_parser_condition
   (cp_parser *);
 static tree cp_parser_iteration_statement
-  (cp_parser *);
+  (cp_parser *, bool);
 static bool cp_parser_for_init_statement
   (cp_parser *, tree *decl);
 static tree cp_parser_for
-  (cp_parser *);
+  (cp_parser *, bool);
 static tree cp_parser_c_for
-  (cp_parser *, tree, tree);
+  (cp_parser *, tree, tree, bool);
 static tree cp_parser_range_for
   (cp_parser *, tree, tree, tree);
 static void do_range_for_auto_deduction
@@ -9231,7 +9231,7 @@ cp_parser_statement (cp_parser* parser, tree in_statement_expr,
 	case RID_WHILE:
 	case RID_DO:
 	case RID_FOR:
-	  statement = cp_parser_iteration_statement (parser);
+	  statement = cp_parser_iteration_statement (parser, false);
 	  break;
 
 	case RID_BREAK:
@@ -9892,7 +9892,7 @@ cp_parser_condition (cp_parser* parser)
not included. */
 
 static tree
-cp_parser_for (cp_parser *parser)
+cp_parser_for (cp_parser *parser, bool ivdep)
 {
   tree init, scope, decl;
   bool is_range_for;
@@ -9906,11 +9906,11 @@ cp_parser_for (cp_parser *parser)
   if (is_range_for)
 return cp_parser_range_for (parser, scope, init, decl);
   else
-return cp_parser_c_for (parser, scope, init);
+return cp_parser_c_for (parser, scope, init, ivdep);
 }
 
 static tree
-cp_parser_c_for (cp_parser *parser, tree scope, tree init)
+cp_parser_c_for (cp_parser *parser, tree scope, tree init, bool ivdep)
 {
   /* Normal for loop */
   tree condition = NULL_TREE;
@@ -9924,7 +9924,19 @@ cp_parser_c_for (cp_parser *parser, tree scope, tree init)
 
   /* If there's a condition, process it.  */
   if (cp_lexer_next_token_is_not (parser->lexer, CPP_SEMICOLON))
-condition = cp_parser_condition (parser);
+{
+  condition = cp_parser_condition (parser);
+  if (ivdep)
+	condition = build2 (ANNOTATE_EXPR, TREE_TYPE (condition), condition,
+			build_int_cst (integer_type_node,
+	   annot_expr_ivdep_kind));
+}
+  else if (ivdep)
+{
+  cp_parser_error (parser, "missing loop condition in loop with "
+		   "% pragma");
+  condition = error_mark_node;
+}
   finish_for_cond (condition, stmt);
   /* Look for the `;'.  */
   cp_parser_require (parser, CPP_SEMICOLON, RT_SEMICOLON);
@@ -10287,7 +10299,7 @@ cp_parser_range_for_member_function (tree range, tree identifier)
Returns the new WHILE_STMT, DO_STMT, FOR_STMT or RANGE_FOR_STMT.  */
 
 static tree
-cp_parser_iteration_statement (cp_parser* parser)
+cp_parser_iteration_statement (cp_parser* parser, bool ivdep)
 {
   cp_token *token;
   enum rid keyword;
@@ -10360,7 +10372,7 @@ cp_parser_iteration_statement (cp_parser* parser)
 	/* Look for the `('.  */
 	cp_parser_require (parser, CPP_OPEN_PAREN, RT_OPEN_PAREN);
 
-	statement = cp_parser_for (parser);
+	statement = cp_parser_for (parser, ivdep);
 
 	/* Look for the `)'.  */
 	cp_parser_require (parser, CPP_CLOSE_PAREN, RT_CLOSE_PAREN);
@@ -30909,6 +30921,20 @@ cp_parser_pragma (cp_parser *parser, enum pragma_context context)
 		"%<#pragma omp sections%> construct");
   break;
 
+case PRAGMA_IVDEP:
+  {
+	cp_parser_skip_to_pragma_eol (parser, pragma_tok);
+	cp_token *tok;
+	tok = cp_lexer_peek_token (the_parser->lexer);
+	if (tok->type != 

Go patch committed: Support three-index slices

[Ian Lance Taylor]

This patch from Chris Manghane adds support for three-index slices to
the Go frontend.  Three-index slices are new language feature in Go 1.2
(http://tip.golang.org/doc/go1.2#three_index).  Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian

diff -r 886731829abf go/expressions.cc
--- a/go/expressions.cc	Wed Oct 23 16:56:39 2013 -0700
+++ b/go/expressions.cc	Thu Oct 24 12:12:12 2013 -0700
@@ -10235,7 +10235,9 @@
   if (Expression::traverse(&this->left_, traverse) == TRAVERSE_EXIT
   || Expression::traverse(&this->start_, traverse) == TRAVERSE_EXIT
   || (this->end_ != NULL
-	  && Expression::traverse(&this->end_, traverse) == TRAVERSE_EXIT))
+	  && Expression::traverse(&this->end_, traverse) == TRAVERSE_EXIT)
+  || (this->cap_ != NULL
+  && Expression::traverse(&this->cap_, traverse) == TRAVERSE_EXIT))
 return TRAVERSE_EXIT;
   return TRAVERSE_CONTINUE;
 }
@@ -10250,6 +10252,7 @@
   Expression* left = this->left_;
   Expression* start = this->start_;
   Expression* end = this->end_;
+  Expression* cap = this->cap_;
 
   Type* type = left->type();
   if (type->is_error())
@@ -10260,20 +10263,27 @@
   return Expression::make_error(location);
 }
   else if (type->array_type() != NULL)
-return Expression::make_array_index(left, start, end, location);
+return Expression::make_array_index(left, start, end, cap, location);
   else if (type->points_to() != NULL
 	   && type->points_to()->array_type() != NULL
 	   && !type->points_to()->is_slice_type())
 {
   Expression* deref = Expression::make_unary(OPERATOR_MULT, left,
 		 location);
-  return Expression::make_array_index(deref, start, end, location);
+  return Expression::make_array_index(deref, start, end, cap, location);
 }
   else if (type->is_string_type())
-return Expression::make_string_index(left, start, end, location);
+{
+  if (cap != NULL)
+{
+  error_at(location, "invalid 3-index slice of string");
+  return Expression::make_error(location);
+}
+  return Expression::make_string_index(left, start, end, location);
+}
   else if (type->map_type() != NULL)
 {
-  if (end != NULL)
+  if (end != NULL || cap != NULL)
 	{
 	  error_at(location, "invalid slice of map");
 	  return Expression::make_error(location);
@@ -10292,14 +10302,15 @@
 }
 }
 
-// Write an indexed expression (expr[expr:expr] or expr[expr]) to a
-// dump context
+// Write an indexed expression
+// (expr[expr:expr:expr], expr[expr:expr] or expr[expr]) to a dump context.
 
 void
 Index_expression::dump_index_expression(Ast_dump_context* ast_dump_context, 
 	const Expression* expr, 
 	const Expression* start,
-	const Expression* end)
+	const Expression* end,
+	const Expression* cap)
 {
   expr->dump_expression(ast_dump_context);
   ast_dump_context->ostream() << "[";
@@ -10309,6 +10320,11 @@
   ast_dump_context->ostream() << ":";
   end->dump_expression(ast_dump_context);
 }
+  if (cap != NULL)
+{
+  ast_dump_context->ostream() << ":";
+  cap->dump_expression(ast_dump_context);
+}
   ast_dump_context->ostream() << "]";
 }
 
@@ -10319,16 +10335,16 @@
 const
 {
   Index_expression::dump_index_expression(ast_dump_context, this->left_, 
-  this->start_, this->end_);
+  this->start_, this->end_, this->cap_);
 }
 
 // Make an index expression.
 
 Expression*
 Expression::make_index(Expression* left, Expression* start, Expression* end,
-		   Location location)
-{
-  return new Index_expression(left, start, end, location);
+		   Expression* cap, Location location)
+{
+  return new Index_expression(left, start, end, cap, location);
 }
 
 // An array index.  This is used for both indexing and slicing.
@@ -10337,9 +10353,9 @@
 {
  public:
   Array_index_expression(Expression* array, Expression* start,
-			 Expression* end, Location location)
+			 Expression* end, Expression* cap, Location location)
 : Expression(EXPRESSION_ARRAY_INDEX, location),
-  array_(array), start_(start), end_(end), type_(NULL)
+  array_(array), start_(start), end_(end), cap_(cap), type_(NULL)
   { }
 
  protected:
@@ -10363,6 +10379,9 @@
 	(this->end_ == NULL
 	 ? NULL
 	 : this->end_->copy()),
+	(this->cap_ == NULL
+	 ? NULL
+	 : this->cap_->copy()),
 	this->location());
   }
 
@@ -10394,6 +10413,9 @@
   // The end index of a slice.  This may be NULL for a simple array
   // index, or it may be a nil expression for the length of the array.
   Expression* end_;
+  // The capacity argument of a slice.  This may be NULL for an array index or
+  // slice.
+  Expression* cap_;
   // The type of the expression.
   Type* type_;
 };
@@ -10412,6 +10434,11 @@
   if (Expression::traverse(&this->end_, traverse) == TRAVERSE_EXIT)
 	return TRAVERSE_EXIT;
 }
+  if (this->cap_ != NULL)
+

Go testsuite patch committed: Combine strings in comments

[Ian Lance Taylor]

The master Go testsuite uses lines like
// ERROR "first error" "second error"
to match multiple errors on a second line.  This patch to the Go
testsuite driver supports that format.  It accepts any of the errors,
but does not require that all of them be present.  Ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian


2013-10-24  Ian Lance Taylor  

* go.test/go-test.exp (errchk): Combine quoted strings in
comments.


Index: go.test/go-test.exp
===
--- go.test/go-test.exp	(revision 203578)
+++ go.test/go-test.exp	(working copy)
@@ -90,6 +90,21 @@ proc errchk { test opts } {
 	puts $fdout $copy_line
 	continue
 	}
+
+	# Combine quoted strings in comments, so that
+	# // ERROR "first error" "second error"
+	# turns into
+	# // ERROR "first error|second error"
+	# This format is used by the master testsuite to recognize
+	# multiple errors on a single line.  We don't require that all
+	# the errors be present, but we do want to accept any of them.
+	set changed ""
+	while { $changed != $copy_line } {
+	set changed $copy_line
+	regsub "\(// \[^\"\]*\"\[^\"\]*\)\" \"" $copy_line "\\1|" out_line
+	set copy_line $out_line
+	}
+
 	regsub "// \(GCCGO_\)?ERROR \"\(\[^\"\]*\)\".*$" $copy_line "// \{ dg-error \"\\2\" \}" out_line
 	if [string match "*dg-error*\\\[*" $out_line] {
 	set index [string first "dg-error" $out_line]

Re: [ARM][PATCH] Fix testsuite testcase neon-vcond-[ltgt,unordered].c

[Kugan]

> I can't seem to get it to fail on my checkout of the linaro 4.8 branch.
> I tried both arm-none-eabi and arm-none-linux-gnueabihf. What kind of
> options/configuration are needed to reproduce this? Also, what kind of
> assembly is produced when the testcase fails? It'd be nice to make sure
> that the allocator doesn't end up doing something sub-optimal and
> unnecessarily moving stuff around to satisfy the alternative constraints
> that produce the other bit-select variants.
> 

Hi Kyrill,

It happens for armv5te arm-none-linux-gnueabi. --with-mode=arm
--with-arch=armv5te --with-float=soft

You can also find the logs here in
http://cbuild.validation.linaro.org/build/gcc-linaro-4.8-2013.10/logs/armv7l-precise-cbuild461-calxeda02_21_00_precise_armel-armv5r2/

I changed neon-vcond-gt.c too.

Thanks,
Kugan

2013-10-23  Kugan Vivekanandarajah  

* gcc.target/arm/neon-vcond-gt.c: Scan for vbsl or vbit or vbif.
* gcc.target/arm/neon-vcond-ltgt.c: Scan for vbsl or vbit or vbif.
* gcc.target/arm/neon-vcond-unordered.c: Scan for vbsl or vbit or vbif.





diff --git a/gcc/testsuite/gcc.target/arm/neon-vcond-gt.c 
b/gcc/testsuite/gcc.target/arm/neon-vcond-gt.c
index 86ccf95..8e9f378 100644
--- a/gcc/testsuite/gcc.target/arm/neon-vcond-gt.c
+++ b/gcc/testsuite/gcc.target/arm/neon-vcond-gt.c
@@ -14,4 +14,4 @@ void foo (int ilast,float* w, float* w2)
 }
 
 /* { dg-final { scan-assembler "vcgt\\.f32\[\\t \]*q\[0-9\]+,\[\\t 
\]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
-/* { dg-final { scan-assembler "vbit\[\\t \]*q\[0-9\]+,\[\\t 
\]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
+/* { dg-final { scan-assembler "vbsl|vbit|vbif\[\\t \]*q\[0-9\]+,\[\\t 
\]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
diff --git a/gcc/testsuite/gcc.target/arm/neon-vcond-ltgt.c 
b/gcc/testsuite/gcc.target/arm/neon-vcond-ltgt.c
index acb23a9..c8306e3 100644
--- a/gcc/testsuite/gcc.target/arm/neon-vcond-ltgt.c
+++ b/gcc/testsuite/gcc.target/arm/neon-vcond-ltgt.c
@@ -15,4 +15,4 @@ void foo (int ilast,float* w, float* w2)
 
 /* { dg-final { scan-assembler-times "vcgt\\.f32\[\\t \]*q\[0-9\]+,\[\\t 
\]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" 2 } } */
 /* { dg-final { scan-assembler "vorr\[\\t \]*q\[0-9\]+,\[\\t 
\]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
-/* { dg-final { scan-assembler "vbsl\[\\t \]*q\[0-9\]+,\[\\t 
\]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
+/* { dg-final { scan-assembler "vbsl|vbit|vbif\[\\t \]*q\[0-9\]+,\[\\t 
\]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
diff --git a/gcc/testsuite/gcc.target/arm/neon-vcond-unordered.c 
b/gcc/testsuite/gcc.target/arm/neon-vcond-unordered.c
index c3e448d..3bb67d3 100644
--- a/gcc/testsuite/gcc.target/arm/neon-vcond-unordered.c
+++ b/gcc/testsuite/gcc.target/arm/neon-vcond-unordered.c
@@ -16,4 +16,4 @@ void foo (int ilast,float* w, float* w2)
 /* { dg-final { scan-assembler "vcgt\\.f32\[\\t \]*q\[0-9\]+,\[\\t 
\]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
 /* { dg-final { scan-assembler "vcge\\.f32\[\\t \]*q\[0-9\]+,\[\\t 
\]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
 /* { dg-final { scan-assembler "vorr\[\\t \]*q\[0-9\]+,\[\\t 
\]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
-/* { dg-final { scan-assembler "vbsl\[\\t \]*q\[0-9\]+,\[\\t 
\]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */
+/* { dg-final { scan-assembler "vbsl|vbit|vbif\[\\t \]*q\[0-9\]+,\[\\t 
\]*q\[0-9\]+,\[\\t \]*q\[0-9\]+" } } */

Re: [PATCH] more robust check for multiplier in addressing mode when determining the costs

[Jeff Law]

On 10/22/13 17:42, Igor Shevlyakov wrote:

2013-10-22  Igor Shevlyakov

* tree-ssa-loop-ivopts.c (multiplier_allowed_in_address_p ): Check both
   [reg+mult*reg] and [mult*reg] to determine if multiplier is allowed.
Thanks.  I've re-bootstrapped & regtested on x86_64-unknown-linux-gnu 
with the trunk and installed this patch on your behalf.


Thanks,
Jeff

Re: [PATCH] Fixing improper conversion from sin() to sinf() in optimization mode.

[Cong Hou]

I have updated the patch according to your suggestion, and have
committed the patch as the bootstrapping and make check both get
passed.

Thank you for your patient help on this patch! I learned a lot from it.


thanks,
Cong


On Wed, Oct 23, 2013 at 1:13 PM, Joseph S. Myers
 wrote:
> On Mon, 7 Oct 2013, Cong Hou wrote:
>
>> +  if (type != newtype)
>> +break;
>
> That comparison would wrongly treat as different cases where the types
> differ only in one being a typedef, having qualifiers, etc. - or if in
> future GCC implemented proposed TS 18661-3, cases where they differ in
> e.g. one being float and the other _Float32 (defined as distinct types
> that are not compatible although they have the same representation and
> alignment).  I think the right test here, bearing in mind the _Float32
> case where types may not be compatible, is TYPE_MODE (type) != TYPE_MODE
> (newtype) - if the types have the same mode, they have the same set of
> values and so are not different in any way that matters for this
> optimization.  OK with that change.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: [PATCH, MPX, 2/X] Pointers Checker [2/25] Builtins

[Jeff Law]

On 10/23/13 16:31, Richard Henderson wrote:

On 10/23/2013 02:41 PM, Jeff Law wrote:

Out of curiosity, did you consider and/or discuss with Richard whether or not
to make these target-dependent or target-independent builtins?  I realize it's
a bit problematic with Richard being involved during the NDA portion and
someone else during the review/integration portion, but that's unfortunately
where we are.


I suggested that they be target independent.

I suggested that there was nothing in MPX that couldn't be
done generically, if slower, on non-MPX hardware.
The primary concern is that while we have some builtins that are 
disabled for a subset of targets, I think this is the first significant 
class of builtins that are only available on a single target.


It's a bit of a slippery slope as we clearly don't want to move to a 
model were we're regularly allowing classes of builtins that are only 
implemented for a single target.


What saves the say with this stuff is from what I can gather (and which 
you've confirmed), someone ought to be able to build a pointer bounds 
checking implementation on top of this w/o using MPX hardware.


Ironically removal of mudflap came up in a different thread yesterday :-)

Jeff

Re: [patch] Patch to fix garbage collection problem with cgraph_fnver_htab

[Jan Hubicka]

> Hi Honza,
> 
> It looks like cgraph_fnver_htab defined in cgraph.c is not added
> to gc root in gt-cgraph.h. This patch fixes it.
> 
> * cgraph.c (cgraph_fnver_htab): Move GTY((...)) to be before htab_t.
> Change param_is to use
> the struct and not the pointer to the struct.

OK,
thanks!
Honza
> 
> Index: gcc/cgraph.c
> ===
> --- gcc/cgraph.c (revision 204022)
> +++ gcc/cgraph.c (working copy)
> @@ -138,7 +138,7 @@ bool cpp_implicit_aliases_done;
> The cgraph_function_version_info has a THIS_NODE field that is the
> corresponding cgraph_node..  */
> 
> -static htab_t GTY((param_is (struct cgraph_function_version_info *)))
> +static GTY((param_is (struct cgraph_function_version_info))) htab_t
>cgraph_fnver_htab = NULL;
> 
>  /* Hash function for cgraph_fnver_htab.  */
> 
> Ok to submit?
> 
> Thanks
> Sri

[patch] Patch to fix garbage collection problem with cgraph_fnver_htab

[Sriraman Tallam]

Hi Honza,

It looks like cgraph_fnver_htab defined in cgraph.c is not added
to gc root in gt-cgraph.h. This patch fixes it.

* cgraph.c (cgraph_fnver_htab): Move GTY((...)) to be before htab_t.
Change param_is to use
the struct and not the pointer to the struct.

Index: gcc/cgraph.c
===
--- gcc/cgraph.c (revision 204022)
+++ gcc/cgraph.c (working copy)
@@ -138,7 +138,7 @@ bool cpp_implicit_aliases_done;
The cgraph_function_version_info has a THIS_NODE field that is the
corresponding cgraph_node..  */

-static htab_t GTY((param_is (struct cgraph_function_version_info *)))
+static GTY((param_is (struct cgraph_function_version_info))) htab_t
   cgraph_fnver_htab = NULL;

 /* Hash function for cgraph_fnver_htab.  */

Ok to submit?

Thanks
Sri

Re: [PATCH] Fix part of PR58712

[Jeff Law]

On 10/24/13 04:50, Markus Trippelsdorf wrote:

On 2013.10.21 at 09:33 +0200, Markus Trippelsdorf wrote:

Ping.
I do not have write access...



LTO bootstrapped and tested on x86_64-unknown-linux-gnu.

I would be grateful if one of you guys could apply it.
Thanks.

2013-10-21  Markus Trippelsdorf  

PR ipa/58712
* cgraph.c (cgraph_create_edge_1): Add indirect_unknown_callee
as argument.
(cgraph_create_edge): Use the new argument.
(cgraph_create_indirect_edge): Likewise.

Installed on your behalf.

Thanks,
Jeff

Re: RFA: Remove some assumptions from gcc.dg tests

[Jeff Law]

On 10/24/13 10:45, Nick Clifton wrote:

Hi Guys,

   The patch below includes a selection of improvements for the tests in
   the gcc.dg part of the gcc testsuite.  It basically annotates tests
   that have some implicit assumptions about the target that is being
   tested (word size, supported features, etc).

   I started making this patch originally just for the MSP430, and so I
   was adding target specific exceptions.  Then I realised that the
   exceptions would apply to other targets too and that it was better to
   add dg-require-effective-target-foo statements instead.

   Tested with an msp430-elf toolchain and an i686-pc-linux-gnu toolchain
   with no regressions and several improvements.

   OK to apply ?

Cheers
   Nick

gcc/testsuite/ChangeLog
2013-10-24  Nick Clifton  

* c-c++-common/pr57793.c: Add expected error messages for
targets with small integers.
 * gcc.dg/c99-stdint-1.c: Only run on 32-bit plus targets.
 * gcc.dg/c99-stdint-2.c: Likewise.
 * gcc.dg/cdce1.c: Likewise.
 * gcc.dg/fold-overflow-1.c: Likewise.
 * gcc.dg/utf-cvt.c: Likewise.
 * gcc.dg/ftrapv-1.c: Only run on targets that support trapping
arithmetic.
 * gcc.dg/ftrapv-2.c: Likewise.
 * gcc.dg/pr30286.c: Likewise.
 * gcc.dg/pr19340.c: Only run on targets that support
scheduling.
 * lib/target-supports.exp (check_effective_target_trapping): New
proc.  Returns true if the target supports trapping arithmetic.

This is OK.

Thanks,
Jeff

Committed: arc_ccfsm_post_advance: Fix 1->3 state transition for TYPE_UNCOND_BRANCH

[Joern Rennecke]

* gcc/config/arc/arc.c (arc_ccfsm_post_advance): Also handle
TYPE_UNCOND_BRANCH.
(arc_ifcvt) : Check that arc_ccfsm_post_advance
changes statep->state.

Re: [PATCH 1/n] Add conditional compare support

[Richard Henderson]

On 10/24/2013 09:37 AM, Richard Earnshaw wrote:
> It still needs to put out the right final condition based on the
> comparisons that were previously done.  At least traditionaly (in the
> existing ARM code) the comparison was just EQ or NE even if the original
> tests were inequalities; so the only way to convey the real comparison
> information was through the condition code (where select_cc_mode could
> work out what was really needed).
> 
> I guess if the branch had more information about the comparison, then
> the need to encode information through CC mode; but it's always been the
> case that the CC mode can modify the final branch condition needed in
> the instruction -- consider for example use of bpl vs bge for
> non-overflowing >= 0 tests.

Yes, the arm flags are not so dissimilar to i386 flags in that way.

In the i386 port, we do use the "real" comparison code plus a CCmode
in order to select between branches.

I missed the fact that these modes are pre-existing in the arm backend,
wrongly assuming that the ccmp patches were adding them.  Thus all my
comments on the subject are spurious.


r~

Re: [PATCH 1/n] Add conditional compare support

[Richard Henderson]

On 10/24/2013 09:24 AM, Richard Earnshaw wrote:
> On 24/10/13 17:15, Richard Henderson wrote:
>> On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
 Why would you need to encode comparisons in CCmodes?
 That looks like a mis-design to me.
>>>
>>> The CCmodes are used to check whether the result of a previous conditional 
>>> compare can combine with current compare. By changing it to rtx_code, I can 
>>> reuse current code (arm_select_dominance_cc_mode_1) to check it.
>>> The CCmodes are also used to emit the "condition code" for a conditional 
>>> execution. E.g.
>>>
>>>   CC1 (CC_DGEmode) = CCMP (a >= 0, b >= 0)
>>> ==> cmp a, #0
>>>  cmpge b, #0
>>>   CC2 = CCMP ( CC1 != 0, c >= 0)
>>> ==> cmpge c, #0
>>> The "ge" is from the mode of CC1 in "CC1 != 0". And the mode of CC2 is not 
>>> necessary the same as CC1.
>>
>> But since you've got the previous comparison operator, why do you need
>> the same data encoded into the mode?
>>
>>
>> r~
>>
> 
> The branch instruction doesn't have that information, only the CC mode.

Why would the branch instruction need that information?  Havn't we
already validated whether the comparisons can combine?


r~

Re: [ARM][PATCH] Fix testsuite testcase neon-vcond-[ltgt,unordered].c

[Kyrill Tkachov]

On 24/10/13 15:52, Christophe Lyon wrote:

Hi Kyrill,

Kugan only fixes the tests we have observed to fail.
The different allocation is not caused by LRA, since we haven't
backported it to our 4.8-based branch.
The different allocation is caused by another difference between 4.8 and trunk.
I can't seem to get it to fail on my checkout of the linaro 4.8 branch. I tried 
both arm-none-eabi and arm-none-linux-gnueabihf. What kind of 
options/configuration are needed to reproduce this? Also, what kind of assembly 
is produced when the testcase fails? It'd be nice to make sure that the 
allocator doesn't end up doing something sub-optimal and unnecessarily moving 
stuff around to satisfy the alternative constraints that produce the other 
bit-select variants.


Kyrill



Christophe.


On 24 October 2013 16:39, Kyrill Tkachov  wrote:

On 24/10/13 00:04, Kugan wrote:

Hi,

arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
instruction, with other vector instructions. However, as per the comment
   for "neon_vbsl_internal" md pattern defined in neon.md, gcc can
generate vbsl or vbit or vbif depending on the register allocation.
Therfore, these testcases should scan for one of these three
instructions instead of just vbsl. I have updated the testcases to scan
vbsl or vbit or vbif now.

Is this OK?

Thanks,
Kugan

2013-10-23  Kugan Vivekanandarajah  
 * gcc.target/arm/neon-vcond-ltgt.c: Scan for vbsl or vbit or vbif.
 * gcc.target/arm/neon-vcond-unordered.c: Scan for vbsl or vbit or
vbif.

Hi Kugan,

Hmmm... What about neon-vcond-gt.c? Could it conceivably start up using vbsl
or vbif as the register allocator changes (I assume this different
allocation is happening because of LRA?)

Otherwise looks sensible to me, but I cannot approve it.

Thanks,
Kyrill

Re: [PATCH v2] Fix libgfortran cross compile configury w.r.t newlib

[Steve Ellcey]

On Thu, 2013-10-24 at 15:53 +0100, Marcus Shawcroft wrote:

> Steve,
> 
> Can your build be fixed allowing us to back out:
> http://gcc.gnu.org/ml/fortran/2013-06/msg00038.html
> 
> ?
> 
> I'd really like to make some progress on this, while my proposed patch
> does resolve the regression introduced by the above patch I am
> concerned that this is going in the wrong direction and that we
> should, as Mike suggests above fix the build issue such that autoconf
> behaves, rather than attempting to hardwire configure details of
> newlib into libgfortran...
> 
> /Marcus

I am not sure how we would fix the build issue to allow us to not
hardcode the newlib configure details into the libgfortran configure
script.  The linker script that needs to be used to get a good link is
different depending on what options one is compiling with on a multilib
MIPS system and I have no idea on how one could create (or use) a dummy
linker script.  Ideally, I think we would want a check that does not
depend on linking at all.

Note that this problem is not just in libgfortran, it affects libstdc++
and libjava too and those configure scripts also have hardcoded the
newlib assumptions.  The only difference between libgfortran and the
other two libraries is that the newlib assumptions for libgfortran are
not static like they are for libstdc++ and libjava.  They vary (for one
function) based on whether or not long double is supported.

If we want to come up with a better solution it should be used for all
the libraries and not just for libgfortran.

Steve Ellcey
sell...@mips.com

RFA: Remove some assumptions from gcc.dg tests

[Nick Clifton]

Hi Guys,

  The patch below includes a selection of improvements for the tests in
  the gcc.dg part of the gcc testsuite.  It basically annotates tests
  that have some implicit assumptions about the target that is being
  tested (word size, supported features, etc).

  I started making this patch originally just for the MSP430, and so I
  was adding target specific exceptions.  Then I realised that the
  exceptions would apply to other targets too and that it was better to
  add dg-require-effective-target-foo statements instead.

  Tested with an msp430-elf toolchain and an i686-pc-linux-gnu toolchain
  with no regressions and several improvements.

  OK to apply ?

Cheers
  Nick

gcc/testsuite/ChangeLog
2013-10-24  Nick Clifton  

* c-c++-common/pr57793.c: Add expected error messages for
targets with small integers.
* gcc.dg/c99-stdint-1.c: Only run on 32-bit plus targets.
* gcc.dg/c99-stdint-2.c: Likewise.
* gcc.dg/cdce1.c: Likewise.
* gcc.dg/fold-overflow-1.c: Likewise.
* gcc.dg/utf-cvt.c: Likewise.
* gcc.dg/ftrapv-1.c: Only run on targets that support trapping
arithmetic.
* gcc.dg/ftrapv-2.c: Likewise.
* gcc.dg/pr30286.c: Likewise.
* gcc.dg/pr19340.c: Only run on targets that support
scheduling.
* lib/target-supports.exp (check_effective_target_trapping): New
proc.  Returns true if the target supports trapping arithmetic.

Index: gcc/testsuite/c-c++-common/pr57793.c
===
--- gcc/testsuite/c-c++-common/pr57793.c(revision 204016)
+++ gcc/testsuite/c-c++-common/pr57793.c(working copy)
@@ -3,8 +3,8 @@
 struct A { unsigned a : 1; unsigned b : 1; };
 struct B /* { dg-error "type .B. is too large" "" { target { c++ && ilp32 
} } } */
 {
-  unsigned char c[0x4000];
-  unsigned char d[0x4ff0];
+  unsigned char c[0x4000]; /* { dg-error "size of array .c. is too large" 
"" { target { ! int32plus } } } */
+  unsigned char d[0x4ff0];/* { dg-error "size of array .d. is too large" 
"" { target { ! int32plus } } } */
   struct A e;
 }; /* { dg-error "type .struct B. is too large" "" { target { c && ilp32 } } } 
*/
 
Index: gcc/testsuite/gcc.dg/c99-stdint-1.c
===
--- gcc/testsuite/gcc.dg/c99-stdint-1.c (revision 204016)
+++ gcc/testsuite/gcc.dg/c99-stdint-1.c (working copy)
@@ -9,6 +9,7 @@
version).  */
 /* { dg-do compile } */
 /* { dg-options "-std=iso9899:1999 -pedantic-errors -fhosted" } */
+/* { dg-require-effective-target ptr32plus } */
 
 #include 
 #include 
@@ -214,7 +215,6 @@
 void
 test_misc_limits (void)
 {
-/* { dg-bogus  "size" "ptrdiff is 16bits" { xfail avr-*-* } 56 } */
   CHECK_SIGNED_LIMITS_2(__PTRDIFF_TYPE__, PTRDIFF_MIN, PTRDIFF_MAX, -65535L, 
65535L);
 #ifndef SIGNAL_SUPPRESS
   CHECK_LIMITS_2(sig_atomic_t, SIG_ATOMIC_MIN, SIG_ATOMIC_MAX, -127, 127, 255);
Index: gcc/testsuite/gcc.dg/c99-stdint-2.c
===
--- gcc/testsuite/gcc.dg/c99-stdint-2.c (revision 204016)
+++ gcc/testsuite/gcc.dg/c99-stdint-2.c (working copy)
@@ -2,7 +2,7 @@
Freestanding version.  */
 /* { dg-do compile } */
 /* { dg-options "-std=iso9899:1999 -pedantic-errors -ffreestanding" } */
-/* { dg-xfail-if "ptrdiff size is 16bits" { avr-*-* } } */
+/* { dg-require-effective-target ptr32plus } */
 /* The test is that there are no diagnostics, so just include the
hosted version.  */
 #include "c99-stdint-1.c"
Index: gcc/testsuite/gcc.dg/cdce1.c
===
--- gcc/testsuite/gcc.dg/cdce1.c(revision 204016)
+++ gcc/testsuite/gcc.dg/cdce1.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do  run  } */
 /* { dg-options "-O2 -fmath-errno -fdump-tree-cdce-details  -lm" } */
-/* { dg-final { scan-tree-dump  "cdce1.c:16: note: function call is 
shrink-wrapped into error conditions\."  "cdce" } } */
+/* { dg-require-effective-target int32plus } */
+/* { dg-final { scan-tree-dump  "cdce1.c:17: note: function call is 
shrink-wrapped into error conditions\."  "cdce" } } */
 /* { dg-final { cleanup-tree-dump "cdce" } } */
 /* { dg-require-effective-target large_double } */
 
Index: gcc/testsuite/gcc.dg/fold-overflow-1.c
===
--- gcc/testsuite/gcc.dg/fold-overflow-1.c  (revision 204016)
+++ gcc/testsuite/gcc.dg/fold-overflow-1.c  (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-skip-if "consts are shorts, not longs" { "m32c-*-*" "avr-*-*" } { "*" 
} { "" } } */
+/* { dg-require-effective-target int32plus } */
 /* { dg-skip-if "No Inf support" { spu-*-* } } */
 /* { dg-options "-O -ftrapping-math" } */
 
Index: gcc/testsuite/gcc.dg/ftrapv-1.c
===
--- gcc/testsuite/gcc.dg/ftrapv-1.c (r

Re: [PATCH 1/n] Add conditional compare support

[Richard Earnshaw]

On 24/10/13 17:26, Richard Henderson wrote:
> On 10/24/2013 09:24 AM, Richard Earnshaw wrote:
>> On 24/10/13 17:15, Richard Henderson wrote:
>>> On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
> Why would you need to encode comparisons in CCmodes?
> That looks like a mis-design to me.

 The CCmodes are used to check whether the result of a previous conditional 
 compare can combine with current compare. By changing it to rtx_code, I 
 can reuse current code (arm_select_dominance_cc_mode_1) to check it.
 The CCmodes are also used to emit the "condition code" for a conditional 
 execution. E.g.

   CC1 (CC_DGEmode) = CCMP (a >= 0, b >= 0)
 ==> cmp a, #0
  cmpge b, #0
   CC2 = CCMP ( CC1 != 0, c >= 0)
 ==> cmpge c, #0
 The "ge" is from the mode of CC1 in "CC1 != 0". And the mode of CC2 is not 
 necessary the same as CC1.
>>>
>>> But since you've got the previous comparison operator, why do you need
>>> the same data encoded into the mode?
>>>
>>>
>>> r~
>>>
>>
>> The branch instruction doesn't have that information, only the CC mode.
> 
> Why would the branch instruction need that information?  Havn't we
> already validated whether the comparisons can combine?
> 
> 
> r~
> 
> 

It still needs to put out the right final condition based on the
comparisons that were previously done.  At least traditionaly (in the
existing ARM code) the comparison was just EQ or NE even if the original
tests were inequalities; so the only way to convey the real comparison
information was through the condition code (where select_cc_mode could
work out what was really needed).

I guess if the branch had more information about the comparison, then
the need to encode information through CC mode; but it's always been the
case that the CC mode can modify the final branch condition needed in
the instruction -- consider for example use of bpl vs bge for
non-overflowing >= 0 tests.

R.

Re: [PATCH] Add a test which will fail without r201824

[Dehao Chen]

Committed to trunk, and verified that FSF 4.8 will also fail this test.

Quick question, is it possible that these two patches will trigger
other bugs? The reason I ask is that I saw you have many other patches
later for devirtualization related code, which made me a little
nervous about this.

Thanks,
Dehao

On Thu, Oct 24, 2013 at 9:15 AM, Jan Hubicka  wrote:
>> This test will fail if we don't have
>> http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=r201824
>>
>> Bootstrapped and passed regression test.
>>
>> OK for trunk?
> This is OK. Thanks!
> If they fail on FSF 4.8, I can work on backporting the patch.
> it is quite self contained and safe.
>
> Honza
>>
>> gcc/testsuite/ChangeLog:
>> 2013-10-24  Dehao Chen  
>>
>> * g++.dg/opt/devirt3.C: New test.
>>
>> Index: gcc/testsuite/g++.dg/opt/devirt3.C
>> ===
>> --- gcc/testsuite/g++.dg/opt/devirt3.C (revision 0)
>> +++ gcc/testsuite/g++.dg/opt/devirt3.C (revision 0)
>> @@ -0,0 +1,24 @@
>> +// { dg-do compile }
>> +// { dg-options "-O2" }
>> +
>> +class ert_RefCounter {
>> + protected:
>> +  int refCounterE;
>> +  virtual ~ert_RefCounter() {}
>> +};
>> +
>> +class ebs_Object : virtual public ert_RefCounter {
>> +};
>> +
>> +class dpr_App : public ebs_Object {
>> + public:
>> +  virtual void run();
>> +};
>> +
>> +class dpr_Job : public ebs_Object {};
>> +
>> +void dpr_run(ebs_Object& objectA) {
>> +  ((dpr_App&)objectA).run();
>> +  dpr_Job jobL;
>> +  dpr_run(jobL);
>> +}

Re: [PATCH 1/n] Add conditional compare support

[Richard Earnshaw]

On 24/10/13 17:15, Richard Henderson wrote:
> On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
>>> Why would you need to encode comparisons in CCmodes?
>>> That looks like a mis-design to me.
>>
>> The CCmodes are used to check whether the result of a previous conditional 
>> compare can combine with current compare. By changing it to rtx_code, I can 
>> reuse current code (arm_select_dominance_cc_mode_1) to check it.
>> The CCmodes are also used to emit the "condition code" for a conditional 
>> execution. E.g.
>>
>>   CC1 (CC_DGEmode) = CCMP (a >= 0, b >= 0)
>> ==> cmp a, #0
>>  cmpge b, #0
>>   CC2 = CCMP ( CC1 != 0, c >= 0)
>> ==> cmpge c, #0
>> The "ge" is from the mode of CC1 in "CC1 != 0". And the mode of CC2 is not 
>> necessary the same as CC1.
> 
> But since you've got the previous comparison operator, why do you need
> the same data encoded into the mode?
> 
> 
> r~
> 

The branch instruction doesn't have that information, only the CC mode.

R.

Re: [PATCH] Add a test which will fail without r201824

[Jan Hubicka]

> This test will fail if we don't have
> http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=r201824
> 
> Bootstrapped and passed regression test.
> 
> OK for trunk?
This is OK. Thanks!
If they fail on FSF 4.8, I can work on backporting the patch.
it is quite self contained and safe.

Honza
> 
> gcc/testsuite/ChangeLog:
> 2013-10-24  Dehao Chen  
> 
> * g++.dg/opt/devirt3.C: New test.
> 
> Index: gcc/testsuite/g++.dg/opt/devirt3.C
> ===
> --- gcc/testsuite/g++.dg/opt/devirt3.C (revision 0)
> +++ gcc/testsuite/g++.dg/opt/devirt3.C (revision 0)
> @@ -0,0 +1,24 @@
> +// { dg-do compile }
> +// { dg-options "-O2" }
> +
> +class ert_RefCounter {
> + protected:
> +  int refCounterE;
> +  virtual ~ert_RefCounter() {}
> +};
> +
> +class ebs_Object : virtual public ert_RefCounter {
> +};
> +
> +class dpr_App : public ebs_Object {
> + public:
> +  virtual void run();
> +};
> +
> +class dpr_Job : public ebs_Object {};
> +
> +void dpr_run(ebs_Object& objectA) {
> +  ((dpr_App&)objectA).run();
> +  dpr_Job jobL;
> +  dpr_run(jobL);
> +}

Re: [PATCH 1/n] Add conditional compare support

[Richard Henderson]

On 10/24/2013 01:11 AM, Zhenqiang Chen wrote:
>> Why would you need to encode comparisons in CCmodes?
>> That looks like a mis-design to me.
> 
> The CCmodes are used to check whether the result of a previous conditional 
> compare can combine with current compare. By changing it to rtx_code, I can 
> reuse current code (arm_select_dominance_cc_mode_1) to check it.
> The CCmodes are also used to emit the "condition code" for a conditional 
> execution. E.g.
> 
>   CC1 (CC_DGEmode) = CCMP (a >= 0, b >= 0)
> ==> cmp a, #0
>  cmpge b, #0
>   CC2 = CCMP ( CC1 != 0, c >= 0)
> ==> cmpge c, #0
> The "ge" is from the mode of CC1 in "CC1 != 0". And the mode of CC2 is not 
> necessary the same as CC1.

But since you've got the previous comparison operator, why do you need
the same data encoded into the mode?


r~

Re: [PATCH] libgomp testsuite fixes

[Cesar Philippidis]

On 6/20/13 9:49 AM, Mike Stump wrote:
> On May 30, 2013, at 12:59 PM, Cesar Philippidis  
> wrote:
>> Here is a patch from our backlog at Mentor Graphics that addresses a 
>> libgomp issue where setting ENABLE_LTO=1 in site.exp causes the following 
>> error with dejagnu
> 
>> Is it OK for trunk?
> 
> Ok.
> 
> Committed revision 200253.

Please backport this patch along with the libitm fix to 4.8. Thank you.
(The libitm patch was discussed here
.)

Cesar

Index: libgomp/testsuite/libgomp.fortran/fortran.exp
===
--- libgomp/testsuite/libgomp.fortran/fortran.exp   (revision 199267)
+++ libgomp/testsuite/libgomp.fortran/fortran.exp   (working copy)
@@ -1,4 +1,6 @@
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
+load_gcc_lib gfortran-dg.exp
 
 global shlib_ext
 global ALWAYS_CFLAGS
Index: libgomp/testsuite/lib/libgomp.exp
===
--- libgomp/testsuite/lib/libgomp.exp   (revision 199267)
+++ libgomp/testsuite/lib/libgomp.exp   (working copy)
@@ -9,24 +9,27 @@
 }
 
 load_lib dg.exp
+
+# Required to use gcc-dg.exp - however, the latter should NOT be
+# loaded until ${tool}_target_compile is defined since it uses that
+# to determine default LTO options.
+
+load_gcc_lib prune.exp
+load_gcc_lib target-libpath.exp
+load_gcc_lib wrapper.exp
+load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout.exp
+load_gcc_lib target-supports.exp
 load_gcc_lib file-format.exp
-load_gcc_lib target-supports.exp
 load_gcc_lib target-supports-dg.exp
 load_gcc_lib scanasm.exp
 load_gcc_lib scandump.exp
 load_gcc_lib scanrtl.exp
 load_gcc_lib scantree.exp
 load_gcc_lib scanipa.exp
-load_gcc_lib prune.exp
-load_gcc_lib target-libpath.exp
-load_gcc_lib wrapper.exp
-load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout-dg.exp
 load_gcc_lib torture-options.exp
-load_gcc_lib timeout.exp
-load_gcc_lib timeout-dg.exp
 load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
-load_gcc_lib gfortran-dg.exp
 
 set dg-do-what-default run
 
Index: libgomp/testsuite/libgomp.c/c.exp
===
--- libgomp/testsuite/libgomp.c/c.exp   (revision 199267)
+++ libgomp/testsuite/libgomp.c/c.exp   (working copy)
@@ -7,6 +7,7 @@
 }
 
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
 
 # If a testcase doesn't have special options, use these.
 if ![info exists DEFAULT_CFLAGS] then {
Index: libgomp/testsuite/libgomp.graphite/graphite.exp
===
--- libgomp/testsuite/libgomp.graphite/graphite.exp (revision 199267)
+++ libgomp/testsuite/libgomp.graphite/graphite.exp (working copy)
@@ -23,6 +23,7 @@
 }
 
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
 
 if ![check_effective_target_pthread] {
   return
Index: libgomp/testsuite/libgomp.c++/c++.exp
===
--- libgomp/testsuite/libgomp.c++/c++.exp   (revision 199267)
+++ libgomp/testsuite/libgomp.c++/c++.exp   (working copy)
@@ -1,4 +1,5 @@
 load_lib libgomp-dg.exp
+load_gcc_lib gcc-dg.exp
 
 global shlib_ext
 
@@ -53,7 +54,7 @@
 }
 
 # Main loop.
-gfortran-dg-runtest $tests $libstdcxx_includes
+dg-runtest $tests "" $libstdcxx_includes
 }
 
 # All done.
Index: libitm/testsuite/lib/libitm.exp
===
--- libitm/testsuite/lib/libitm.exp (revision 199267)
+++ libitm/testsuite/lib/libitm.exp (working copy)
@@ -23,23 +23,27 @@
 }
 
 load_lib dg.exp
+
+# Required to use gcc-dg.exp - however, the latter should NOT be
+# loaded until ${tool}_target_compile is defined since it uses that
+# to determine default LTO options.
+
+load_gcc_lib prune.exp
+load_gcc_lib target-libpath.exp
+load_gcc_lib wrapper.exp
+load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout.exp
+load_gcc_lib target-supports.exp
 load_gcc_lib file-format.exp
-load_gcc_lib target-supports.exp
 load_gcc_lib target-supports-dg.exp
 load_gcc_lib scanasm.exp
 load_gcc_lib scandump.exp
 load_gcc_lib scanrtl.exp
 load_gcc_lib scantree.exp
 load_gcc_lib scanipa.exp
-load_gcc_lib prune.exp
-load_gcc_lib target-libpath.exp
-load_gcc_lib wrapper.exp
-load_gcc_lib gcc-defs.exp
+load_gcc_lib timeout-dg.exp
 load_gcc_lib torture-options.exp
-load_gcc_lib timeout.exp
-load_gcc_lib timeout-dg.exp
 load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
 
 set dg-do-what-default run
 
Index: libitm/testsuite/libitm.c++/c++.exp
===
--- libitm/testsuite/libitm.c++/c++.exp (revision 199267)
+++ libitm/testsuite/libitm.c++/c++.exp (working copy)
@@ -15,6 +15,7 @@
 # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, 
USA.
 
 load_lib libitm-dg.exp
+load_gcc_lib gcc-dg.exp
 
 global shlib_ext
 
Index: libitm/testsuite/libitm.c/c.exp
=

Re: [patch] Relocate a couple of va_arg_expr routines.

[Andrew MacLeod]

On 10/24/2013 09:40 AM, Richard Biener wrote:

On Thu, Oct 24, 2013 at 3:38 PM, Andrew MacLeod  wrote:

On 10/24/2013 09:11 AM, Richard Biener wrote:

On Thu, Oct 24, 2013 at 3:06 PM, Andrew MacLeod 
wrote:

I originally shuffled std_gimplify_va_arg_expr () to gimplify.c, but i
believe the suggestion was to eventually move it to targhooks.c.

build_va_arg_indirect_ref seems to  hang around with it, and used by all
the
same things that use  std_gimplify_va_arg_expr, so this patch currently
lumps it in targhooks.c as well (which means they will get it with the
same
header file).   Really, I suppose it should go elsewhere.. and I'd guess
tree.c...  but its nots 100% obvious... suggestions welcome.   I'd think
someday this file will get split into gimple-targhooks and rtl-targhooks,
but not today i think. :-)

It also seems appropriate to move gimplify_va_arg_expr from builtins.c to
gimplify.c since its a gimplification routiine.. This showed up as I was
splitting gimple.h into gimplify.h... the prototype is in gimple.h and it
made sense to become part of gimplify.h as I try to move towards an
interface from front-ends that only requires gimplfy.h and not gimple.h
or
other middle end things.

bootstraps on x86_64-unknown-linux-gnu with no new regressions.  OK?

Ok.

Err ...

Index: targhooks.c
===
*** targhooks.c (revision 203915)
--- targhooks.c (working copy)
*** along with GCC; see the file COPYING3.
*** 71,76 
--- 71,77 
#include "tree-ssa.h"
#include "tree-ssa-alias.h"
#include "insn-codes.h"
+ #include "tree-mudflap.h"

we were supposed to remove mudflap for 4.9, no?



Really?  I guess it hasn't been removed yet since the include is still
there?  who is doing that?

Yeah, nobody has done it yet appearantly :/

Richard.

I'll leave it in an let whoever removes mudflap can take the include and 
those lines out, Otherwise we get a dozen regressions.  They woud have 
had to do the same thing where ever it was located.


Andrew

[Patch Preview/RFC] tree-optimization/57994: Constant folding of infinity

[Paolo Carlini]

Hi,

this is just a preview, but I decided to send it out early to understand 
if I'm on the right track or not. As you can see in the Bug, this 
started as a spin-off of a library issue with complex pow, which led us to:


__builtin_exp(-__builtin_huge_val())

not being folded to a constant at compile-time. The reason is simple: 
the various do_mpfr_arg*, etc, all check real_isfinite on the arguments. 
In the audit trail of the bug we came to the conclusion that allowing 
non-NANs could make sense (the mpfr facilities appear to be quite solid 
in this case - maybe for NANs too, at least in the non-complex case, but 
that's another story). However, when today I started fiddling with this 
kind of change, I noticed that isn't enough for the kind of code we 
really care about for the original issue, involving logs too, thus 
something like:


  long double num = __builtin_logl(0L);
  long double res = __builtin_expl(num);

because the log isn't folded at all for zero: fold_builtin_logarithm 
calls do_mpfr_arg1 with true as last argument. We can make progress if, 
when it's safe - is !flag_trapping_math && !flag_errno_math enough? - we 
pass true instead. Then we also have to tweak do_mpfr_ckconv, because it 
checks mpfr_number_p (and real_isfinite) on the result of the folding, 
thus ruling out infinities. Then we are almost there: the latter can be 
actually fully folded if -O1 is used, -O0 is not Ok, because otherwise 
num isn't const propagated to the evaluation of res. Is this so far by 
and large Ok? I'm attaching a corresponding patchlet (it of course lacks 
testcases and testsuite adjustments)


Note: in the patchlet I'm not trying to handle NaNs; neither complex 
numbers; neither bessel, remquo and lgamma (which could probably be 
added?) Also, I suppose we could discover other cases like 
fold_builtin_logarithm, where, in the context of folding infinities too, 
we may have to tweak a bit the way do_mpfr_* functions are called


Thanks!
Paolo.

PS: there are interesting issues about the non-compile-time constant 
case, especially vs long double, which I didn't touch here.






Index: builtins.c
===
--- builtins.c  (revision 204016)
+++ builtins.c  (working copy)
@@ -8191,7 +8191,9 @@ fold_builtin_logarithm (location_t loc, tree fndec
   const enum built_in_function fcode = builtin_mathfn_code (arg);
 
   /* Calculate the result when the argument is a constant.  */
-  if ((res = do_mpfr_arg1 (arg, type, func, &dconst0, NULL, false)))
+  if ((res = do_mpfr_arg1 (arg, type, func, &dconst0, NULL,
+  !flag_trapping_math && !flag_errno_math
+  ? true : false)))
return res;
 
   /* Special case, optimize logN(expN(x)) = x.  */
@@ -13527,7 +13529,7 @@ do_mpfr_ckconv (mpfr_srcptr m, tree type, int inex
   /* Proceed iff we get a normal number, i.e. not NaN or Inf and no
  overflow/underflow occurred.  If -frounding-math, proceed iff the
  result of calling FUNC was exact.  */
-  if (mpfr_number_p (m) && !mpfr_overflow_p () && !mpfr_underflow_p ()
+  if (!mpfr_nan_p (m) && !mpfr_overflow_p () && !mpfr_underflow_p ()
   && (!flag_rounding_math || !inexact))
 {
   REAL_VALUE_TYPE rr;
@@ -13537,7 +13539,7 @@ do_mpfr_ckconv (mpfr_srcptr m, tree type, int inex
 check for overflow/underflow.  If the REAL_VALUE_TYPE is zero
 but the mpft_t is not, then we underflowed in the
 conversion.  */
-  if (real_isfinite (&rr)
+  if (!real_isnan (&rr)
  && (rr.cl == rvc_zero) == (mpfr_zero_p (m) != 0))
 {
  REAL_VALUE_TYPE rmode;
@@ -13623,7 +13625,7 @@ do_mpfr_arg1 (tree arg, tree type, int (*func)(mpf
 {
   const REAL_VALUE_TYPE *const ra = &TREE_REAL_CST (arg);
 
-  if (real_isfinite (ra)
+  if (!real_isnan (ra)
  && (!min || real_compare (inclusive ? GE_EXPR: GT_EXPR , ra, min))
  && (!max || real_compare (inclusive ? LE_EXPR: LT_EXPR , ra, max)))
 {
@@ -13669,7 +13671,7 @@ do_mpfr_arg2 (tree arg1, tree arg2, tree type,
   const REAL_VALUE_TYPE *const ra1 = &TREE_REAL_CST (arg1);
   const REAL_VALUE_TYPE *const ra2 = &TREE_REAL_CST (arg2);
 
-  if (real_isfinite (ra1) && real_isfinite (ra2))
+  if (!real_isnan (ra1) && !real_isnan (ra2))
 {
  const struct real_format *fmt = REAL_MODE_FORMAT (TYPE_MODE (type));
  const int prec = fmt->p;
@@ -13717,7 +13719,7 @@ do_mpfr_arg3 (tree arg1, tree arg2, tree arg3, tre
   const REAL_VALUE_TYPE *const ra2 = &TREE_REAL_CST (arg2);
   const REAL_VALUE_TYPE *const ra3 = &TREE_REAL_CST (arg3);
 
-  if (real_isfinite (ra1) && real_isfinite (ra2) && real_isfinite (ra3))
+  if (!real_isnan (ra1) && !real_isnan (ra2) && !real_isnan (ra3))
 {
  const struct real_format *fmt = REAL_MODE_FORMAT (TYPE_MODE (type));
  const int 

[PATCH] Add a test which will fail without r201824

[Dehao Chen]

This test will fail if we don't have
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=r201824

Bootstrapped and passed regression test.

OK for trunk?

gcc/testsuite/ChangeLog:
2013-10-24  Dehao Chen  

* g++.dg/opt/devirt3.C: New test.

Index: gcc/testsuite/g++.dg/opt/devirt3.C
===
--- gcc/testsuite/g++.dg/opt/devirt3.C (revision 0)
+++ gcc/testsuite/g++.dg/opt/devirt3.C (revision 0)
@@ -0,0 +1,24 @@
+// { dg-do compile }
+// { dg-options "-O2" }
+
+class ert_RefCounter {
+ protected:
+  int refCounterE;
+  virtual ~ert_RefCounter() {}
+};
+
+class ebs_Object : virtual public ert_RefCounter {
+};
+
+class dpr_App : public ebs_Object {
+ public:
+  virtual void run();
+};
+
+class dpr_Job : public ebs_Object {};
+
+void dpr_run(ebs_Object& objectA) {
+  ((dpr_App&)objectA).run();
+  dpr_Job jobL;
+  dpr_run(jobL);
+}

Re: [RFC] [Testsuite,ARM] Neon intrinsics executable tests

[Christophe Lyon]

Ping?

On 10 October 2013 00:16, Christophe Lyon  wrote:
> Hi,
>
> This patch is a first small sample of dejagnu-ization of my ARM Neon
> intrinsics tests.
>
> It's derived from my previous work at
> http://gitorious.org/arm-neon-tests/arm-neon-tests which supports all
> the ARM intrinsics, with executable tests. As I have to manually
> transform each test (to include the expected data, and a few other
> modifications), it's quite a bit tedious.
>
> I'd like your feedback before continuing, as there are a lot more
> files to come.
>
> I have made some cleanup to help review, but the two .h files will
> need to grow as more intrinsics will be added (see the original ones).
>
> I'd like to keep the modifications at a minimal level, to save my time
> when adapting each test (there are currently 145 test files, so 143
> left :-).
>
> Thanks,
>
> Christophe.
>
> This patch only introduces new files.
> 2013-10-03  Christophe Lyon  
>
> testsuite/gcc.target/arm/neon-intrinsics/
> * neon-intrinsics.exp: New driver file.
> * arm-neon-ref.h: New file, with common vector construction
> helpers.
> * compute_ref_data.h: New file, with helpers for input data
> initialization.
> * ref_vaba.c: New test file for the vaba family of intrinsics.
> * ref_vld1.c: New test file for vld1.

Re: [PATCH v2] Fix libgfortran cross compile configury w.r.t newlib

[Marcus Shawcroft]

On 15 October 2013 22:35, Mike Stump  wrote:

> Would be nice for a build/config person to weigh in or to upgrade and make 
> bullet proof the system against such failures.  My take, by default, the 
> compile line should do something useful, and that should be enough for 
> autoconf style tests to smell the library.  Now, we can observe that Steve's 
> mips-mti-elf newlib port apparently violates that, but it is lost on me why 
> that is and why that is a good thing.  Steve?  Is there some reason why by 
> default, a suitable linker script can't be added by the compiler, or, if none 
> suitable, a stub one that isn't suitable in general, but, is complete enough 
> to allow autoconf to function normally?


Steve,

Can your build be fixed allowing us to back out:
http://gcc.gnu.org/ml/fortran/2013-06/msg00038.html

?

I'd really like to make some progress on this, while my proposed patch
does resolve the regression introduced by the above patch I am
concerned that this is going in the wrong direction and that we
should, as Mike suggests above fix the build issue such that autoconf
behaves, rather than attempting to hardwire configure details of
newlib into libgfortran...

/Marcus

Re: [ARM][PATCH] Fix testsuite testcase neon-vcond-[ltgt,unordered].c

[Christophe Lyon]

Hi Kyrill,

Kugan only fixes the tests we have observed to fail.
The different allocation is not caused by LRA, since we haven't
backported it to our 4.8-based branch.
The different allocation is caused by another difference between 4.8 and trunk.

Christophe.


On 24 October 2013 16:39, Kyrill Tkachov  wrote:
> On 24/10/13 00:04, Kugan wrote:
>>
>> Hi,
>>
>> arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
>> Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
>> Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
>> instruction, with other vector instructions. However, as per the comment
>>   for "neon_vbsl_internal" md pattern defined in neon.md, gcc can
>> generate vbsl or vbit or vbif depending on the register allocation.
>> Therfore, these testcases should scan for one of these three
>> instructions instead of just vbsl. I have updated the testcases to scan
>> vbsl or vbit or vbif now.
>>
>> Is this OK?
>>
>> Thanks,
>> Kugan
>>
>> 2013-10-23  Kugan Vivekanandarajah  
>> * gcc.target/arm/neon-vcond-ltgt.c: Scan for vbsl or vbit or vbif.
>> * gcc.target/arm/neon-vcond-unordered.c: Scan for vbsl or vbit or
>> vbif.
>
> Hi Kugan,
>
> Hmmm... What about neon-vcond-gt.c? Could it conceivably start up using vbsl
> or vbif as the register allocator changes (I assume this different
> allocation is happening because of LRA?)
>
> Otherwise looks sensible to me, but I cannot approve it.
>
> Thanks,
> Kyrill
>
>

Re: [PATCH] Generate fused widening multiply-and-accumulate operations only when the widening multiply has single use

[Yufeng Zhang]

On 10/24/13 01:29, Richard Henderson wrote:

On 10/21/2013 03:01 PM, Yufeng Zhang wrote:


This patch changes the widening_mul pass to fuse the widening multiply with
accumulate only when the multiply has single use.  The widening_mul pass
currently does the conversion regardless of the number of the uses, which can
cause poor code-gen in cases like the following:

typedef int ArrT [10][10];

void
foo (ArrT Arr, int Idx)
{
   Arr[Idx][Idx] = 1;
   Arr[Idx + 10][Idx] = 2;
}

On AArch64, after widening_mul, the IR is like

   _2 = (long unsigned int) Idx_1(D);
   _3 = Idx_1(D) w* 40;<
   _5 = Arr_4(D) + _3;
   *_5[Idx_1(D)] = 1;
   _8 = WIDEN_MULT_PLUS_EXPR;<
   _9 = Arr_4(D) + _8;
   *_9[Idx_1(D)] = 2;

Where the arrows point, there are redundant widening multiplies.


So they're redundant.  Why does this imply poor code-gen?

If a target has more than one FMA unit, then the target might
be able to issue the computation for _3 and _8 in parallel.

Even if the target only has one FMA unit, but the unit is
pipelined, the computations could overlap.


Thanks for the review.

I think it is a fair point that redundancy doesn't always indicate poor 
code-gen, but there are a few reasons that I think this patch makes sense.


Firstly, the generated WIDEN_MULT_PLUS_EXPR can prevents other 
optimization passes from analyzing the IR sequence effectively.  Like in 
the above example, the widening multiply can be part of a larger common 
sub-expression (Arr_4(D) + Idx_1(D) w* 40 + Idx_1(D) * 4); by blindly 
merging the multiply with accumulate, it makes the recognition of the 
common sub-expression rather difficult.


Secondly, it is generally more expensive (in terms of both latency and 
energy) to multiply than accumulate.  Even though there are multiple MAC 
units* or well-working pipeline, it is not always the case that multiple 
widening multiply-and-accumulate instructions can be scheduled 
(statically or dynamically) together.  Merged multiply-and-accumulate 
can add to the register pressure as well.  So maybe it is better to let 
the backend do the conversion (when the multiply has more uses).


Also, isn't it in general that new common sub-expression (widening 
multiply in this case) shall not be created in the gimple IR when there 
is no obvious benefit?  I can sense that it may be a difference case for 
the floating-point multiply-and-accumulate, as on one hand the 
arithmetic is usually for pure data-processing instead of other purposes 
like address calculation (as what its integer peers may do), and on the 
other hand, on micro-architectures where there are more FMA units than 
FADD units, it probably makes more sense to generate more FMA 
instructions in order to take advantage of the throughput capacity.


The area where this patch tries to tackle is only about the integer 
widening multiply-and-accumulate, and it doesn't seem beneficial to me 
to merge the widening multiply with accumulate so aggressively; you 
could argue that other optimization passes shall be extended to be able 
to handle WIDEN_MULT_PLUS_EXPR and its friends; while it is an option 
I'm considering, it is more likely to be a longer-term solution.


Regards,
Yufeng

*) I think I had abused the word 'fused' in my previous emails.  It 
seems like 'fused' is more often used to refer to the floating-point 
multiply-and-accumulate with a single rounding.

Re: [PATCH, MPX, 2/X] Pointers Checker [5/25] Tree and gimple ifaces

[Ilya Enkovich]

Here is an updated version with changes due to renames in basic bounds type 
patch.

Thanks,
Ilya
--

gcc/

2013-10-23  Ilya Enkovich  

* tree-core.h (tree_index): Add TI_POINTER_BOUNDS_TYPE.
* tree.h (POINTER_BOUNDS_P): New.
(BOUNDED_TYPE_P): New.
(BOUNDED_P): New.
(pointer_bounds_type_node): New.
* tree.c (build_common_tree_nodes): Initialize
pointer_bounds_type_node.
* gimple.h (gimple_call_get_nobnd_arg_index): New.
(gimple_call_num_nobnd_args): New.
(gimple_call_nobnd_arg): New.
(gimple_return_retbnd): New.
(gimple_return_set_retbnd): New
* gimple.c (gimple_build_return): Increase number of ops
for return statement.
(gimple_call_get_nobnd_arg_index): New.
* gimple-pretty-print.c (dump_gimple_return): Print second op.


diff --git a/gcc/gimple-pretty-print.c b/gcc/gimple-pretty-print.c
index 1e985e0..fddcee0 100644
--- a/gcc/gimple-pretty-print.c
+++ b/gcc/gimple-pretty-print.c
@@ -535,11 +535,12 @@ dump_gimple_assign (pretty_printer *buffer, gimple gs, 
int spc, int flags)
 static void
 dump_gimple_return (pretty_printer *buffer, gimple gs, int spc, int flags)
 {
-  tree t;
+  tree t, t2;
 
   t = gimple_return_retval (gs);
+  t2 = gimple_return_retbnd (gs);
   if (flags & TDF_RAW)
-dump_gimple_fmt (buffer, spc, flags, "%G <%T>", gs, t);
+dump_gimple_fmt (buffer, spc, flags, "%G <%T %T>", gs, t, t2);
   else
 {
   pp_string (buffer, "return");
@@ -548,6 +549,11 @@ dump_gimple_return (pretty_printer *buffer, gimple gs, int 
spc, int flags)
  pp_space (buffer);
  dump_generic_node (buffer, t, spc, flags, false);
}
+  if (t2)
+   {
+ pp_string (buffer, ", ");
+ dump_generic_node (buffer, t2, spc, flags, false);
+   }
   pp_semicolon (buffer);
 }
 }
diff --git a/gcc/gimple.c b/gcc/gimple.c
index e12f7d9..59ca78a 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -179,7 +179,7 @@ gimple_build_with_ops_stat (enum gimple_code code, unsigned 
subcode,
 gimple
 gimple_build_return (tree retval)
 {
-  gimple s = gimple_build_with_ops (GIMPLE_RETURN, ERROR_MARK, 1);
+  gimple s = gimple_build_with_ops (GIMPLE_RETURN, ERROR_MARK, 2);
   if (retval)
 gimple_return_set_retval (s, retval);
   return s;
@@ -371,6 +371,26 @@ gimple_build_call_from_tree (tree t)
 }
 
 
+/* Return index of INDEX's non bound argument of the call.  */
+
+unsigned
+gimple_call_get_nobnd_arg_index (const_gimple gs, unsigned index)
+{
+  unsigned num_args = gimple_call_num_args (gs);
+  for (unsigned n = 0; n < num_args; n++)
+{
+  if (POINTER_BOUNDS_P (gimple_call_arg (gs, n)))
+   continue;
+  else if (index)
+   index--;
+  else
+   return n;
+}
+
+  gcc_unreachable ();
+}
+
+
 /* Extract the operands and code for expression EXPR into *SUBCODE_P,
*OP1_P, *OP2_P and *OP3_P respectively.  */
 
diff --git a/gcc/gimple.h b/gcc/gimple.h
index 376fda2..484b467 100644
--- a/gcc/gimple.h
+++ b/gcc/gimple.h
@@ -910,6 +910,7 @@ extern tree get_initialized_tmp_var (tree, gimple_seq *, 
gimple_seq *);
 extern tree get_formal_tmp_var (tree, gimple_seq *);
 extern void declare_vars (tree, gimple, bool);
 extern void annotate_all_with_location (gimple_seq, location_t);
+extern unsigned gimple_call_get_nobnd_arg_index (const_gimple, unsigned);
 
 /* Validation of GIMPLE expressions.  Note that these predicates only check
the basic form of the expression, they don't recurse to make sure that
@@ -2379,6 +2380,31 @@ gimple_call_arg (const_gimple gs, unsigned index)
 }
 
 
+/* Return the number of arguments used by call statement GS.  */
+
+static inline unsigned
+gimple_call_num_nobnd_args (const_gimple gs)
+{
+  unsigned num_args = gimple_call_num_args (gs);
+  unsigned res = num_args;
+  for (unsigned n = 0; n < num_args; n++)
+if (POINTER_BOUNDS_P (gimple_call_arg (gs, n)))
+  res--;
+  return res;
+}
+
+
+/* Return INDEX's call argument ignoring bound ones.  */
+static inline tree
+gimple_call_nobnd_arg (const_gimple gs, unsigned index)
+{
+  /* No bound args may exist if pointers checker is off.  */
+  if (!flag_check_pointers)
+return gimple_call_arg (gs, index);
+  return gimple_call_arg (gs, gimple_call_get_nobnd_arg_index (gs, index));
+}
+
+
 /* Return a pointer to the argument at position INDEX for call
statement GS.  */
 
@@ -4886,6 +4912,26 @@ gimple_return_set_retval (gimple gs, tree retval)
 }
 
 
+/* Return the return bounds for GIMPLE_RETURN GS.  */
+
+static inline tree
+gimple_return_retbnd (const_gimple gs)
+{
+  GIMPLE_CHECK (gs, GIMPLE_RETURN);
+  return gimple_op (gs, 1);
+}
+
+
+/* Set RETVAL to be the return bounds for GIMPLE_RETURN GS.  */
+
+static inline void
+gimple_return_set_retbnd (gimple gs, tree retval)
+{
+  GIMPLE_CHECK (gs, GIMPLE_RETURN);
+  gimple_set_op (gs, 1, retval);
+}
+
+
 /* Returns true when the gimple statement STMT is any of the OpenMP types.  */
 
 #d

Re: [ARM][PATCH] Fix testsuite testcase neon-vcond-[ltgt,unordered].c

[Kyrill Tkachov]

On 24/10/13 00:04, Kugan wrote:

Hi,

arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
instruction, with other vector instructions. However, as per the comment
  for "neon_vbsl_internal" md pattern defined in neon.md, gcc can
generate vbsl or vbit or vbif depending on the register allocation.
Therfore, these testcases should scan for one of these three
instructions instead of just vbsl. I have updated the testcases to scan
vbsl or vbit or vbif now.

Is this OK?

Thanks,
Kugan

2013-10-23  Kugan Vivekanandarajah  
* gcc.target/arm/neon-vcond-ltgt.c: Scan for vbsl or vbit or vbif.
* gcc.target/arm/neon-vcond-unordered.c: Scan for vbsl or vbit or vbif.

Hi Kugan,

Hmmm... What about neon-vcond-gt.c? Could it conceivably start up using vbsl or 
vbif as the register allocator changes (I assume this different allocation is 
happening because of LRA?)


Otherwise looks sensible to me, but I cannot approve it.

Thanks,
Kyrill

Re: [PATCH][AArch64] Get %c output template tests to pass for -fPIC

[Marcus Shawcroft]

On 21 October 2013 09:41, Kyrill Tkachov  wrote:

> [gcc/testsuite]
> 2013-10-21  Kyrylo Tkachov  
>
> * gcc.target/aarch64/c-output-mod-2.c: Fix for -fPIC.
> * gcc.target/aarch64/c-output-mod-3.c: Likewise.

OK
/Marcus

Re: [PATCH, MPX, 2/X] Pointers Checker [2/25] Builtins

[Ilya Enkovich]

esOn 21 Oct 12:08, Joseph S. Myers wrote:
> On Mon, 21 Oct 2013, Ilya Enkovich wrote:
> 
> > +  if (flag_check_pointers)
> > +{
> > +  if (flag_lto)
> > +   sorry ("Pointers checker is not yet fully supported for link-time 
> > optimization");
> 
> That sounds wrong.  It suggests some bug somewhere in your patch series 
> failing to allow for LTO, which should be fixed.  At least give a more 
> detailed explanation in a comment of what would need to change to remove 
> this call to sorry ().

I made some Pointers Checker tests with LTO.  Currently instrumented code 
causes ICE in LTO streamer.  Since it happens on early stage, I do not know if 
other significant problems exist.  I added a comment for now and will 
investigate it further.  I also fixed error messages.

Thanks,
Ilya

> 
> > +  if (targetm.chkp_bound_mode () == VOIDmode)
> > +   error ("-fcheck-pointers is not supported for this target.");
> 
> Also note GNU Coding Standards for diagnostics.  They should not start 
> with uppercase letters or end with ".".
> 
> -- 
> Joseph S. Myers
> joseph@codesourcery.

--

gcc/

diff --git a/gcc/builtin-types.def b/gcc/builtin-types.def
index 2634ecc..c6c5e5c 100644
--- a/gcc/builtin-types.def
+++ b/gcc/builtin-types.def
@@ -224,12 +224,15 @@ DEF_FUNCTION_TYPE_1 (BT_FN_DFLOAT64_DFLOAT64, 
BT_DFLOAT64, BT_DFLOAT64)
 DEF_FUNCTION_TYPE_1 (BT_FN_DFLOAT128_DFLOAT128, BT_DFLOAT128, BT_DFLOAT128)
 DEF_FUNCTION_TYPE_1 (BT_FN_VOID_VPTR, BT_VOID, BT_VOLATILE_PTR)
 DEF_FUNCTION_TYPE_1 (BT_FN_VOID_PTRPTR, BT_VOID, BT_PTR_PTR)
+DEF_FUNCTION_TYPE_1 (BT_FN_VOID_CONST_PTR, BT_VOID, BT_CONST_PTR)
 DEF_FUNCTION_TYPE_1 (BT_FN_UINT_UINT, BT_UINT, BT_UINT)
 DEF_FUNCTION_TYPE_1 (BT_FN_ULONG_ULONG, BT_ULONG, BT_ULONG)
 DEF_FUNCTION_TYPE_1 (BT_FN_ULONGLONG_ULONGLONG, BT_ULONGLONG, BT_ULONGLONG)
 DEF_FUNCTION_TYPE_1 (BT_FN_UINT16_UINT16, BT_UINT16, BT_UINT16)
 DEF_FUNCTION_TYPE_1 (BT_FN_UINT32_UINT32, BT_UINT32, BT_UINT32)
 DEF_FUNCTION_TYPE_1 (BT_FN_UINT64_UINT64, BT_UINT64, BT_UINT64)
+DEF_FUNCTION_TYPE_1 (BT_FN_PTR_CONST_PTR, BT_PTR, BT_CONST_PTR)
+DEF_FUNCTION_TYPE_1 (BT_FN_CONST_PTR_CONST_PTR, BT_CONST_PTR, BT_CONST_PTR)
 
 DEF_POINTER_TYPE (BT_PTR_FN_VOID_PTR, BT_FN_VOID_PTR)
 
@@ -341,6 +344,10 @@ DEF_FUNCTION_TYPE_2 (BT_FN_VOID_VPTR_INT, BT_VOID, 
BT_VOLATILE_PTR, BT_INT)
 DEF_FUNCTION_TYPE_2 (BT_FN_BOOL_VPTR_INT, BT_BOOL, BT_VOLATILE_PTR, BT_INT)
 DEF_FUNCTION_TYPE_2 (BT_FN_BOOL_SIZE_CONST_VPTR, BT_BOOL, BT_SIZE,
 BT_CONST_VOLATILE_PTR)
+DEF_FUNCTION_TYPE_2 (BT_FN_PTR_CONST_PTR_SIZE, BT_PTR, BT_CONST_PTR, BT_SIZE)
+DEF_FUNCTION_TYPE_2 (BT_FN_PTR_CONST_PTR_CONST_PTR, BT_PTR, BT_CONST_PTR, 
BT_CONST_PTR)
+DEF_FUNCTION_TYPE_2 (BT_FN_VOID_PTRPTR_CONST_PTR, BT_VOID, BT_PTR_PTR, 
BT_CONST_PTR)
+DEF_FUNCTION_TYPE_2 (BT_FN_VOID_CONST_PTR_SIZE, BT_VOID, BT_CONST_PTR, BT_SIZE)
 
 DEF_POINTER_TYPE (BT_PTR_FN_VOID_PTR_PTR, BT_FN_VOID_PTR_PTR)
 
@@ -425,6 +432,7 @@ DEF_FUNCTION_TYPE_3 (BT_FN_VOID_VPTR_I2_INT, BT_VOID, 
BT_VOLATILE_PTR, BT_I2, BT
 DEF_FUNCTION_TYPE_3 (BT_FN_VOID_VPTR_I4_INT, BT_VOID, BT_VOLATILE_PTR, BT_I4, 
BT_INT)
 DEF_FUNCTION_TYPE_3 (BT_FN_VOID_VPTR_I8_INT, BT_VOID, BT_VOLATILE_PTR, BT_I8, 
BT_INT)
 DEF_FUNCTION_TYPE_3 (BT_FN_VOID_VPTR_I16_INT, BT_VOID, BT_VOLATILE_PTR, 
BT_I16, BT_INT)
+DEF_FUNCTION_TYPE_3 (BT_FN_PTR_CONST_PTR_CONST_PTR_SIZE, BT_PTR, BT_CONST_PTR, 
BT_CONST_PTR, BT_SIZE)
 
 DEF_FUNCTION_TYPE_4 (BT_FN_SIZE_CONST_PTR_SIZE_SIZE_FILEPTR,
 BT_SIZE, BT_CONST_PTR, BT_SIZE, BT_SIZE, BT_FILEPTR)
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 3b16d59..b8dec3f 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -5861,7 +5861,18 @@ expand_builtin (tree exp, rtx target, rtx subtarget, 
enum machine_mode mode,
   && fcode != BUILT_IN_EXECVE
   && fcode != BUILT_IN_ALLOCA
   && fcode != BUILT_IN_ALLOCA_WITH_ALIGN
-  && fcode != BUILT_IN_FREE)
+  && fcode != BUILT_IN_FREE
+  && fcode != BUILT_IN_CHKP_SET_PTR_BOUNDS
+  && fcode != BUILT_IN_CHKP_INIT_PTR_BOUNDS
+  && fcode != BUILT_IN_CHKP_NULL_PTR_BOUNDS
+  && fcode != BUILT_IN_CHKP_COPY_PTR_BOUNDS
+  && fcode != BUILT_IN_CHKP_NARROW_PTR_BOUNDS
+  && fcode != BUILT_IN_CHKP_STORE_PTR_BOUNDS
+  && fcode != BUILT_IN_CHKP_CHECK_PTR_LBOUNDS
+  && fcode != BUILT_IN_CHKP_CHECK_PTR_UBOUNDS
+  && fcode != BUILT_IN_CHKP_CHECK_PTR_BOUNDS
+  && fcode != BUILT_IN_CHKP_GET_PTR_LBOUND
+  && fcode != BUILT_IN_CHKP_GET_PTR_UBOUND)
 return expand_call (exp, target, ignore);
 
   /* The built-in function expanders test for target == const0_rtx
@@ -6905,6 +6916,50 @@ expand_builtin (tree exp, rtx target, rtx subtarget, 
enum machine_mode mode,
   expand_builtin_set_thread_pointer (exp);
   return const0_rtx;
 
+case BUILT_IN_CHKP_INIT_PTR_BOUNDS:
+case BUILT_IN_CHKP_NULL_PTR_BOUNDS:
+case BUILT_IN_CHKP_COPY_PTR_BOUNDS:
+  return expand_normal (CALL_EXPR_ARG (exp, 0));
+
+case BUILT_IN_CHKP_CHECK_PTR_LBOUNDS:
+case BUILT_IN_CHKP_C

[PATCH] Fix PR58626, compute proper partition dependences in loop distribution

[Richard Biener]

This finally computes a valid partition ordering (or if not possible
merge partitions again) in loop distribution.  This is the only
place where data dependences are relevant, so we delay computing them
(and also do not compute all N^2 dependences).

Bootstrapped and tested on x86_64-unknown-linux-gnu with BOOT_CFLAGS
-O2 -ftree-loop-distribution, BOOT_CFLAGS -O3 still running.

Richard.

2013-10-24  Richard Biener  

PR tree-optimization/58626
* tree-loop-distribution.c (enum rdg_dep_type): Remove
anti_dd, output_dd and input_dd.
(struct rdg_edge): Remove level and relation members.
(RDGE_LEVEL, RDGE_RELATION): Remove.
(dot_rdg_1): Adjust.
(create_rdg_edge_for_ddr): Remove.
(create_rdg_edges_for_scalar): Adjust.
(create_edge_for_control_dependence): Likewise.
(create_rdg_edges): Split into ...
(create_rdg_flow_edges): ... this
(create_rdg_cd_edges): ... and this.
(free_rdg): Adjust.
(build_rdg): Likewise, do not compute data dependences or
add edges for them.
(pg_add_dependence_edges): New function.
(pgcmp): Likewise.
(distribute_loop): First apply all non-dependence based
partition mergings.  Then compute dependences between partitions
and merge and order partitions according to them.

* gcc.dg/torture/pr58626.c: New testcase.

Index: gcc/tree-loop-distribution.c
===
*** gcc/tree-loop-distribution.c.orig   2013-10-24 12:44:13.0 +0200
--- gcc/tree-loop-distribution.c2013-10-24 16:01:29.163862370 +0200
*** enum rdg_dep_type
*** 96,110 
/* Read After Write (RAW).  */
flow_dd = 'f',
  
-   /* Write After Read (WAR).  */
-   anti_dd = 'a',
- 
-   /* Write After Write (WAW).  */
-   output_dd = 'o',
- 
-   /* Read After Read (RAR).  */
-   input_dd = 'i',
- 
/* Control dependence (execute conditional on).  */
control_dd = 'c'
  };
--- 96,101 
*** typedef struct rdg_edge
*** 115,133 
  {
/* Type of the dependence.  */
enum rdg_dep_type type;
- 
-   /* Levels of the dependence: the depth of the loops that carry the
-  dependence.  */
-   unsigned level;
- 
-   /* Dependence relation between data dependences, NULL when one of
-  the vertices is a scalar.  */
-   ddr_p relation;
  } *rdg_edge_p;
  
  #define RDGE_TYPE(E)((struct rdg_edge *) ((E)->data))->type
- #define RDGE_LEVEL(E)   ((struct rdg_edge *) ((E)->data))->level
- #define RDGE_RELATION(E)((struct rdg_edge *) ((E)->data))->relation
  
  /* Dump vertex I in RDG to FILE.  */
  
--- 106,114 
*** dot_rdg_1 (FILE *file, struct graph *rdg
*** 215,237 
 for (e = v->succ; e; e = e->succ_next)
   switch (RDGE_TYPE (e))
 {
-case input_dd:
-  fprintf (file, "%d -> %d [label=input] \n", i, e->dest);
-  break;
- 
-case output_dd:
-  fprintf (file, "%d -> %d [label=output] \n", i, e->dest);
-  break;
- 
 case flow_dd:
   /* These are the most common dependences: don't print these. */
   fprintf (file, "%d -> %d \n", i, e->dest);
   break;
  
-case anti_dd:
-  fprintf (file, "%d -> %d [label=anti] \n", i, e->dest);
-  break;
- 
   case control_dd:
   fprintf (file, "%d -> %d [label=control] \n", i, e->dest);
   break;
--- 196,206 
*** rdg_vertex_for_stmt (struct graph *rdg A
*** 273,324 
return index;
  }
  
- /* Creates an edge in RDG for each distance vector from DDR.  The
-order that we keep track of in the RDG is the order in which
-statements have to be executed.  */
- 
- static void
- create_rdg_edge_for_ddr (struct graph *rdg, ddr_p ddr)
- {
-   struct graph_edge *e;
-   int va, vb;
-   data_reference_p dra = DDR_A (ddr);
-   data_reference_p drb = DDR_B (ddr);
-   unsigned level = ddr_dependence_level (ddr);
- 
-   /* For non scalar dependences, when the dependence is REVERSED,
-  statement B has to be executed before statement A.  */
-   if (level > 0
-   && !DDR_REVERSED_P (ddr))
- {
-   data_reference_p tmp = dra;
-   dra = drb;
-   drb = tmp;
- }
- 
-   va = rdg_vertex_for_stmt (rdg, DR_STMT (dra));
-   vb = rdg_vertex_for_stmt (rdg, DR_STMT (drb));
- 
-   if (va < 0 || vb < 0)
- return;
- 
-   e = add_edge (rdg, va, vb);
-   e->data = XNEW (struct rdg_edge);
- 
-   RDGE_LEVEL (e) = level;
-   RDGE_RELATION (e) = ddr;
- 
-   /* Determines the type of the data dependence.  */
-   if (DR_IS_READ (dra) && DR_IS_READ (drb))
- RDGE_TYPE (e) = input_dd;
-   else if (DR_IS_WRITE (dra) && DR_IS_WRITE (drb))
- RDGE_TYPE (e) = output_dd;
-   else if (DR_IS_WRITE (dra) && DR_IS_READ (drb))
- RDGE_TYPE (e) = flow_dd;
-   else if (DR_I

Re: Patch: Add #pragma ivdep support to the ME and C FE

[Richard Biener]

On Thu, 24 Oct 2013, Jakub Jelinek wrote:

> On Thu, Oct 24, 2013 at 03:59:14PM +0200, Tobias Burnus wrote:
> > +  FOR_EACH_LOOP (li, loop, 0)
> > +if (loop->latch)
> > +  FOR_EACH_EDGE (e, ei, loop->latch->succs)
> 
> Isn't the only successor of loop->latch loop->header?
> Thus, can't you just remove the above two lines and use loop->header
> instead of e->dest?

Yes, of course.

Richard.

Commit: testsuite/gcc.dg/20020312-2.c: Update for RL78 and MSP430

[Nick Clifton]

Hi Guys,

  I am applying the patch below as an obvious update to the 20020312-2.c
  test for the RL78 and MSP430 targets.  Neither of them use a specific
  regiser for PIC support, but the test needs to be explicitly told
  that.

Cheers
  Nick

gcc/testsuite/ChangeLog
2013-10-24  Nick Clifton  

* gcc.dg/20020312-2.c: No PIC register for RL78 or MSP430.

Index: gcc/testsuite/gcc.dg/20020312-2.c
===
--- gcc/testsuite/gcc.dg/20020312-2.c   (revision 204007)
+++ gcc/testsuite/gcc.dg/20020312-2.c   (working copy)
@@ -96,6 +96,10 @@
 #endif
 #elif defined (__aarch64__)
 /* No pic register -- yet.  */
+#elif defined(__RL78__)
+/* No pic register.  */
+#elif defined(__MSP430__)
+/* No pic register.  */
 #else
 # error "Modify the test for your target."
 #endif


  

Re: Patch: Add #pragma ivdep support to the ME and C FE

[Jakub Jelinek]

On Thu, Oct 24, 2013 at 03:59:14PM +0200, Tobias Burnus wrote:
> +  FOR_EACH_LOOP (li, loop, 0)
> +if (loop->latch)
> +  FOR_EACH_EDGE (e, ei, loop->latch->succs)

Isn't the only successor of loop->latch loop->header?
Thus, can't you just remove the above two lines and use loop->header
instead of e->dest?

Jakub

Re: Patch: Add #pragma ivdep support to the ME and C FE

[Richard Biener]

On Thu, 24 Oct 2013, Tobias Burnus wrote:

> Richard Biener wrote:
> > Please instead amend tree-cfg.c:execute_build_cfg and do after
> > loop_optimizer_init sth like
> > [...]
> > possibly doing after it
> >FOR_EACH_BB (bb)
> > [...]
> > +DEFTREECODE (ANNOTATE_EXPR, "annotate_expr", tcc_expression, 1)
> > 
> > FIXME?  Btw, not using a tree operand here is somewhat of a premature
> > optimization I think ...
> 
> I have now moved the code to a new function in tree-cfg.c. As it was not
> completely clear to me after the IRC discussion whether it is sufficient to
> assume that loop->latch == NULL won't occur (and rely on the assert in
> internal_fn), I created a version with FOR_EACH_BB and without. (see #if 0
> code in tree-cfg.c).
> 
> For  both versions, I did a true all-language bootstrap+ regtesting on
> x86-64-gnu-linux.
> 
> Additionally, the ID is now stored in an INTEGER_CST and I also documented
> ANNOTATE_EXPR in generic.texi.
> 
> OK? Or are there more comments?

Looks good to me now ...

> Tobias
> 
> PS: Before committal, I will remove the #if 0 code - or enable it, as
> preferred.

... I think it's "easy" to trigger.

entry:
#pragma GCC ivdep
  for (i = 0; i < n; ++i) {
a[i] = b[i] + c[i];
if (i == 5)
  goto entry;
a[i] = a[i] + 1;
  }

or by using setjmp/longjmp and thus having some abnormal edges
into a function call inside a loop.

The whole point is that execute_build_cfg passes AVOID_CFG_MODIFICATIONS
to loop_optimizer_init and thus it won't disambiguate loops with
multiple latches.  We could eventually change that and pass
LOOPS_HAVE_SIMPLE_LATCHES, but I'm not sure if that works well enough
alone (it's not really tested besides of in combination LOOPS_NORMAL).

Richard.

patch: Fix gengtype to really detect same files

[Michael Matz]

Hi,

I just hit this problem where gengtype thought an existing gt-*.h header 
was the same as what it wanted to write because its prefix was indeed 
equal to the buffer, but contained some additional things afterwards.  
gengtype simply forgot to check that the file end is reached at buffer 
end.  Done with the below obivious patch.  Fixed the problem I have on 
x86_64-linux, otherwise creates same gt files, regstrapped with some other 
patches, no regressions.  Applied as r204015.


Ciao,
Michael.
-- 
* gengtype.c (is_file_equal): Check that files will be same
length.

Index: gengtype.c
===
--- gengtype.c  (revision 204007)
+++ gengtype.c  (working copy)
@@ -2344,6 +2344,8 @@ is_file_equal (outf_p of)
  break;
}
 }
+  if (equal && EOF != fgetc (newfile))
+equal = false;
   fclose (newfile);
   return equal;
 }

Re: Patch: Add #pragma ivdep support to the ME and C FE

[Tobias Burnus]

Richard Biener wrote:

Please instead amend tree-cfg.c:execute_build_cfg and do after 
loop_optimizer_init sth like
[...]
possibly doing after it
   FOR_EACH_BB (bb)
[...]
+DEFTREECODE (ANNOTATE_EXPR, "annotate_expr", tcc_expression, 1)

FIXME?  Btw, not using a tree operand here is somewhat of a premature
optimization I think ...


I have now moved the code to a new function in tree-cfg.c. As it was not 
completely clear to me after the IRC discussion whether it is sufficient 
to assume that loop->latch == NULL won't occur (and rely on the assert 
in internal_fn), I created a version with FOR_EACH_BB and without. (see 
#if 0 code in tree-cfg.c).


For  both versions, I did a true all-language bootstrap+ regtesting on 
x86-64-gnu-linux.


Additionally, the ID is now stored in an INTEGER_CST and I also 
documented ANNOTATE_EXPR in generic.texi.


OK? Or are there more comments?

Tobias

PS: Before committal, I will remove the #if 0 code - or enable it, as 
preferred.
2013-08-24  Tobias Burnus  

	PR other/33426
* c-pragma.c (init_pragma) Add #pragma ivdep handling.
* c-pragma.h (pragma_kind): Add PRAGMA_IVDEP.

	PR other/33426
* c-parser.c (c_parser_pragma, c_parser_for_statement):
Handle PRAGMA_IVDEP.
(c_parser_statement_after_labels): Update call.

	PR other/33426
* tree-cfg.c (replace_loop_annotate): New function.
(execute_build_cfg): Call it.
* gimplify.c (gimple_boolify, gimplify_expr): Handle ANNOTATE_EXPR.
* internal-fn.c (expand_ANNOTATE): New function.
* internal-fn.def (ANNOTATE): Define as new internal function.
* tree-core.h (tree_node_kind): Add annot_expr_ivdep_kind.
* tree-pretty-print.c (dump_generic_node): Handle ANNOTATE_EXPR.
* tree.def (ANNOTATE_EXPR): New DEFTREECODE.
	* doc/extend.texi (Pragmas): Document #pragma ivdep.
	* doc/generic.texi (Expressions): Document ANNOTATE_EXPR.

	PR other/33426
	* testsuite/gcc.dg/ivdep.c: New.
	* testsuite/gcc.dg/vect/vect-ivdep-1.c: New.

diff --git a/gcc/c-family/c-pragma.c b/gcc/c-family/c-pragma.c
index be5748b..1656000 100644
--- a/gcc/c-family/c-pragma.c
+++ b/gcc/c-family/c-pragma.c
@@ -1362,6 +1362,8 @@ init_pragma (void)
 cpp_register_deferred_pragma (parse_in, "GCC", "pch_preprocess",
   PRAGMA_GCC_PCH_PREPROCESS, false, false);
 
+  cpp_register_deferred_pragma (parse_in, "GCC", "ivdep", PRAGMA_IVDEP, false,
+false);
 #ifdef HANDLE_PRAGMA_PACK_WITH_EXPANSION
   c_register_pragma_with_expansion (0, "pack", handle_pragma_pack);
 #else
diff --git a/gcc/c-family/c-pragma.h b/gcc/c-family/c-pragma.h
index c421284..705bcb4 100644
--- a/gcc/c-family/c-pragma.h
+++ b/gcc/c-family/c-pragma.h
@@ -53,6 +53,7 @@ typedef enum pragma_kind {
   PRAGMA_OMP_TEAMS,
 
   PRAGMA_GCC_PCH_PREPROCESS,
+  PRAGMA_IVDEP,
 
   PRAGMA_FIRST_EXTERNAL
 } pragma_kind;
diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 4d6c930..4f25078 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -1159,7 +1159,7 @@ static void c_parser_if_statement (c_parser *);
 static void c_parser_switch_statement (c_parser *);
 static void c_parser_while_statement (c_parser *);
 static void c_parser_do_statement (c_parser *);
-static void c_parser_for_statement (c_parser *);
+static void c_parser_for_statement (c_parser *, bool);
 static tree c_parser_asm_statement (c_parser *);
 static tree c_parser_asm_operands (c_parser *);
 static tree c_parser_asm_goto_operands (c_parser *);
@@ -4585,7 +4585,7 @@ c_parser_statement_after_labels (c_parser *parser)
 	  c_parser_do_statement (parser);
 	  break;
 	case RID_FOR:
-	  c_parser_for_statement (parser);
+	  c_parser_for_statement (parser, false);
 	  break;
 	case RID_GOTO:
 	  c_parser_consume_token (parser);
@@ -5038,7 +5038,7 @@ c_parser_do_statement (c_parser *parser)
 */
 
 static void
-c_parser_for_statement (c_parser *parser)
+c_parser_for_statement (c_parser *parser, bool ivdep)
 {
   tree block, cond, incr, save_break, save_cont, body;
   /* The following are only used when parsing an ObjC foreach statement.  */
@@ -5144,8 +5144,17 @@ c_parser_for_statement (c_parser *parser)
 	{
 	  if (c_parser_next_token_is (parser, CPP_SEMICOLON))
 	{
-	  c_parser_consume_token (parser);
-	  cond = NULL_TREE;
+	  if (ivdep)
+		{
+		  c_parser_error (parser, "missing loop condition in loop with "
+  "% pragma");
+		  cond = error_mark_node;
+		}
+	  else
+		{
+		  c_parser_consume_token (parser);
+		  cond = NULL_TREE;
+		}
 	}
 	  else
 	{
@@ -5159,6 +5168,10 @@ c_parser_for_statement (c_parser *parser)
 	  c_parser_skip_until_found (parser, CPP_SEMICOLON,
 	 "expected %<;%>");
 	}
+	  if (ivdep && cond != error_mark_node)
+	cond = build2 (ANNOTATE_EXPR, TREE_TYPE (cond), cond,
+			   build_int_cst (integer_type_node,
+			   annot_expr_ivdep_kind));
 	}
   /* Parse the increment expression (the third expression in a
 	 for-statement).  In the case of a foreach-statement, this is

Re: [c++-concepts] small tidbits to get it to build

[Andrew Sutton]

Hi Ed,

I committed half of your patch (the unused variable part) in r204011
and removed the unused keywords as a resolution for the other half in
r204012.

Changelog/patch follow:

2013-10-24  Andrew Sutton  
* gcc/cp/c-common.c (c_common_r): Remove unused keywords "assume",
"axiom", and "forall".
* gcc/cp/c-common.h (rid): Removed unused reserved word ids.

Andrew


On Wed, Oct 23, 2013 at 8:05 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> On 10/23/2013 08:36 AM, Andrew Sutton wrote:
>>
>> Hi Ed,
>>
>> It looks like we did reserve "assume" as a keyword, but it's not being
>> used... By any chance, did you configure without --disable-bootstrap?
>>
>> I think it would be a better solution to remove the unused keywords --
>> there were a couple of others that we grabbed for some other
>> concepts-related work, but which aren't included in Concepts Lite.
>>
>> I'll apply the typeck fix.
>>
>> Andrew Sutton
>>
>>
>> On Tue, Oct 22, 2013 at 10:02 PM, Ed Smith-Rowland <3dw...@verizon.net>
>> wrote:
>>>
>>> I had to get past two small bugs to get c++-concepts to build.
>>> Take a good look because I'm not sure if they're right.  The solutions
>>> should be harmless though.
>>>
>>> Ed
>>>
> I did this:
> $ ../gcc_concepts/configure --prefix=/home/ed/bin_concepts
> --enable-languages=c,c++,lto
>
> This is pretty base bones - no special treatment configure and the branch
> worked pretty well.
>
> Ed
>


keyword.patch
Description: Binary data

Re: [C++ PATCH] Fix PR58705

[Marek Polacek]

On Thu, Oct 24, 2013 at 09:16:05AM -0400, Jason Merrill wrote:
> On 10/14/2013 08:23 AM, Marek Polacek wrote:
> >We were ICEing on the attached testcase, because in check_narrowing,
> >for = {{}}, we wanted to check recursively the CONSTRUCTOR_ELTs,
> >even though init in this case has 0 CONSTRUCTOR_NELTS.  So I added
> >the check for CONSTRUCTOR_NELTS > 0.  Moreover, since empty scalar
> >initializers are forbidden in C FE, I think we should error out here
> >too.  (Complex type is considered as an arithmetic type as a GNU
> >extension and arithmetic types are scalar types.)
> 
> Empty scalar initializers are allowed in C++11, so we shouldn't give
> an error.  Your initial patch from bugzilla is OK, with an
> appropriately adjusted testcase.

Thanks, will commit the following.

2013-10-24  Marek Polacek  

PR c++/58705
cp/
* typeck2.c (check_narrowing): Don't check narrowing when the scalar
initializer is empty.
testsuite/
* g++.dg/parse/pr58705.C: New test.

--- gcc/cp/typeck2.c.mp 2013-10-24 15:34:39.225244689 +0200
+++ gcc/cp/typeck2.c2013-10-24 15:37:19.045825247 +0200
@@ -834,7 +834,8 @@ check_narrowing (tree type, tree init)
   && TREE_CODE (type) == COMPLEX_TYPE)
 {
   tree elttype = TREE_TYPE (type);
-  check_narrowing (elttype, CONSTRUCTOR_ELT (init, 0)->value);
+  if (CONSTRUCTOR_NELTS (init) > 0)
+check_narrowing (elttype, CONSTRUCTOR_ELT (init, 0)->value);
   if (CONSTRUCTOR_NELTS (init) > 1)
check_narrowing (elttype, CONSTRUCTOR_ELT (init, 1)->value);
   return;
--- gcc/testsuite/g++.dg/parse/pr58705.C.mp 2013-10-24 15:38:41.023132022 
+0200
+++ gcc/testsuite/g++.dg/parse/pr58705.C2013-10-24 15:38:25.035071911 
+0200
@@ -0,0 +1,5 @@
+// PR c++/58705
+// { dg-do compile }
+// { dg-options "-Wnarrowing" }
+
+_Complex float f = {{}};

Marek

Re: [patch] Relocate a couple of va_arg_expr routines.

[Richard Biener]

On Thu, Oct 24, 2013 at 3:38 PM, Andrew MacLeod  wrote:
> On 10/24/2013 09:11 AM, Richard Biener wrote:
>>
>> On Thu, Oct 24, 2013 at 3:06 PM, Andrew MacLeod 
>> wrote:
>>>
>>> I originally shuffled std_gimplify_va_arg_expr () to gimplify.c, but i
>>> believe the suggestion was to eventually move it to targhooks.c.
>>>
>>> build_va_arg_indirect_ref seems to  hang around with it, and used by all
>>> the
>>> same things that use  std_gimplify_va_arg_expr, so this patch currently
>>> lumps it in targhooks.c as well (which means they will get it with the
>>> same
>>> header file).   Really, I suppose it should go elsewhere.. and I'd guess
>>> tree.c...  but its nots 100% obvious... suggestions welcome.   I'd think
>>> someday this file will get split into gimple-targhooks and rtl-targhooks,
>>> but not today i think. :-)
>>>
>>> It also seems appropriate to move gimplify_va_arg_expr from builtins.c to
>>> gimplify.c since its a gimplification routiine.. This showed up as I was
>>> splitting gimple.h into gimplify.h... the prototype is in gimple.h and it
>>> made sense to become part of gimplify.h as I try to move towards an
>>> interface from front-ends that only requires gimplfy.h and not gimple.h
>>> or
>>> other middle end things.
>>>
>>> bootstraps on x86_64-unknown-linux-gnu with no new regressions.  OK?
>>
>> Ok.
>>
>> Err ...
>>
>> Index: targhooks.c
>> ===
>> *** targhooks.c (revision 203915)
>> --- targhooks.c (working copy)
>> *** along with GCC; see the file COPYING3.
>> *** 71,76 
>> --- 71,77 
>>#include "tree-ssa.h"
>>#include "tree-ssa-alias.h"
>>#include "insn-codes.h"
>> + #include "tree-mudflap.h"
>>
>> we were supposed to remove mudflap for 4.9, no?
>>
>>
> Really?  I guess it hasn't been removed yet since the include is still
> there?  who is doing that?

Yeah, nobody has done it yet appearantly :/

Richard.

>  so I guess should remove this bit too then..?
>
>   tree
>   build_va_arg_indirect_ref (tree addr)
>   {
> addr = build_simple_mem_ref_loc (EXPR_LOCATION (addr), addr);
>
> -   if (flag_mudflap) /* Don't instrument va_arg INDIRECT_REF.  */
> - mf_mark (addr);
> -
> return addr;
>  }
>

Re: [patch] Relocate a couple of va_arg_expr routines.

[Andrew MacLeod]

On 10/24/2013 09:11 AM, Richard Biener wrote:

On Thu, Oct 24, 2013 at 3:06 PM, Andrew MacLeod  wrote:

I originally shuffled std_gimplify_va_arg_expr () to gimplify.c, but i
believe the suggestion was to eventually move it to targhooks.c.

build_va_arg_indirect_ref seems to  hang around with it, and used by all the
same things that use  std_gimplify_va_arg_expr, so this patch currently
lumps it in targhooks.c as well (which means they will get it with the same
header file).   Really, I suppose it should go elsewhere.. and I'd guess
tree.c...  but its nots 100% obvious... suggestions welcome.   I'd think
someday this file will get split into gimple-targhooks and rtl-targhooks,
but not today i think. :-)

It also seems appropriate to move gimplify_va_arg_expr from builtins.c to
gimplify.c since its a gimplification routiine.. This showed up as I was
splitting gimple.h into gimplify.h... the prototype is in gimple.h and it
made sense to become part of gimplify.h as I try to move towards an
interface from front-ends that only requires gimplfy.h and not gimple.h or
other middle end things.

bootstraps on x86_64-unknown-linux-gnu with no new regressions.  OK?

Ok.

Err ...

Index: targhooks.c
===
*** targhooks.c (revision 203915)
--- targhooks.c (working copy)
*** along with GCC; see the file COPYING3.
*** 71,76 
--- 71,77 
   #include "tree-ssa.h"
   #include "tree-ssa-alias.h"
   #include "insn-codes.h"
+ #include "tree-mudflap.h"

we were supposed to remove mudflap for 4.9, no?


Really?  I guess it hasn't been removed yet since the include is still 
there?  who is doing that?


 so I guess should remove this bit too then..?

  tree
  build_va_arg_indirect_ref (tree addr)
  {
addr = build_simple_mem_ref_loc (EXPR_LOCATION (addr), addr);

-   if (flag_mudflap) /* Don't instrument va_arg INDIRECT_REF.  */
- mf_mark (addr);
-
return addr;
 }

Re: [PATCH, PR 57748] Check for out of bounds access, Part 2

[Richard Biener]

On Thu, Oct 24, 2013 at 3:13 PM, Jakub Jelinek  wrote:
> On Thu, Oct 24, 2013 at 02:55:59PM +0200, Bernd Edlinger wrote:
>> On Thu, 24 Oct 2013 12:18:43, Richard Biener wrote:
>> >
>> > On Thu, Oct 24, 2013 at 10:48 AM, Eric Botcazou  
>> > wrote:
>> >>> I think that is common practice to write array[1]; at the end of the
>> >>> structure, and use it as a flexible array. The compute_record_mode has no
>> >>> way to decide if that is going to be a flexible array or not.
>> >>>
>> >>> Sorry Eric, but now I have no other choice than to go back to my previous
>> >>> version of part 2:
>> >>>
>> >>> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00222.html
>> >>
>> >> Why? Just set BLKmode in this case as well.
>> >
>> > Works for me if it works ABI-wise (which you say it should unless the
>> > backend is buggy). Note that means mode_for_array should unconditionally
>> > return BLKmode.
>>
>> Did you just propose:
>
> But why would we want to penalize the generated code for this?
> I mean, if some structure has a flexible array member or something similar
> to it that we allow to be used as one, if we pass it as arguments, return
> from functions etc., it will not have any bits beyond those and thus it
> should be just fine to be passed in registers etc.  We can only use those
> extra bits if either we allocate them on the heap/stack (malloc, alloca,
> ...) or as a global or automatic variable with initializer that fills in the
> zero sized array or flexible array member (GNU extensions?), but in either
> of these cases the DECL_MODE or TYPE_MODE should be irrelevant.
>
> So to me this really sounds like a bug in the expansion, certainly not
> stor-layout.

Sure, that was what I was saying all along ... but still, if we want to fix it
in stor-layout.c then we have to fix it for all cases there, not just the
zero-size array case (which I showed is not the only relevant case).

Richard.

> Jakub

GCC 4.9.0 Status Report (2013-10-24), Stage 1 ends Nov 21

[Richard Biener]

Status
==

The trunk is scheduled to transition from Stage 1 to Stage 3 at the end
of Thursday, Nov. 21 (use your timezone to your advantage).

We have been in Stage 1 for more than 7 months now with almost a full
month still to go.  Still now is a good time to look into bugzilla
and pick one or two regressions in your area of expertise and fix them
(you may want to prioritize regressions against both 4.8 and 4.9).


Somewhat misleading quality data below (so I omit deltas), P3 bugs
have not been re-prioritized for quite some time now.  We promise
to do this before entering Stage 3.


Quality Data


Priority  #   Change from Last Report
---   ---
P11
P2   72 
P3  142
---   ---
Total   215


Previous Report
===

http://gcc.gnu.org/ml/gcc/2013-03/msg00125.html


The next report will be sent by me when entering Stage 3.

RE: [PATCH, PR 57748] Check for out of bounds access, Part 2

[Bernd Edlinger]

>> Did you just propose:
>>
>> --- stor-layout.c.orig 2013-10-22 10:46:49.233261818 +0200
>> +++ stor-layout.c 2013-10-24 14:54:00.425259062 +0200
>> @@ -471,27 +471,7 @@
>> static enum machine_mode
>> mode_for_array (tree elem_type, tree size)
>> {
>> - tree elem_size;
>> - unsigned HOST_WIDE_INT int_size, int_elem_size;
>> - bool limit_p;
>> -
>> - /* One-element arrays get the component type's mode. */
>> - elem_size = TYPE_SIZE (elem_type);
>> - if (simple_cst_equal (size, elem_size))
>> - return TYPE_MODE (elem_type);
>> -
>> - limit_p = true;
>> - if (host_integerp (size, 1) && host_integerp (elem_size, 1))
>> - {
>> - int_size = tree_low_cst (size, 1);
>> - int_elem_size = tree_low_cst (elem_size, 1);
>> - if (int_elem_size> 0
>> - && int_size % int_elem_size == 0
>> - && targetm.array_mode_supported_p (TYPE_MODE (elem_type),
>> - int_size / int_elem_size))
>> - limit_p = false;
>> - }
>> - return mode_for_size_tree (size, MODE_INT, limit_p);
>> + return BLKmode;
>> }
>>
>> ???
>
> Yes. Does it work?
>
> Richard.
>

I will give it a try.

I could also explicitly catch the case "struct { a[x]; };"
in compute_record_mode. That might work too.
But one way or the other that fix will be ugly.

Note:
struct Y { char c[1]; char c2; };

is "invalid" even if the expander would not fail,
because the code in tree-ssa-alias.c will not see the alias,
between c[2] and c2, that works only for the last array.
So that is no ICE but all generated code at -O1 and higher
will be wrong.

Bernd.

Re: Fix scheduler ix86_issue_rate and ix86_adjust_cost for modern x86 chips

[Jan Hubicka]

> Hi, 
> 
> > Is this with -fschedule-insns? Or only with default settings?  Did you test 
> > the compile time implications of increasing the lookahead? (value of 8 is 
> > very large, we may consider enbling it only for -Ofast, limiting for 
> > postreload only or something similar).
> 
> The improvement is seen with the options "-fschedule-insns  -fschedule-insns2 
> -fsched-pressure"
> 
> Below are the build times of some of the SPEC benchmarks
> 
>   dfa8   no_lookahead
> 
> perlbench   - 196s  193s
> bzip2   - 19s   19s
> gcc - 439s  429s
> mcf - 3s3s
> gobmk   - 119s  115s
> hmmer   - 62s   60s
> sjeng   - 18s   17s
> libquantum  - 6s6s
> h264ref - 110s  107s
> omnetpp - 132s  128s
> astar   - 7s7s
> bwaves  - 4s5s
> gamess  - 1996s 1957s
> milc- 18s   18s
> GemsFDTD- 276s  272s
> 
> I think we can enable it by default rather than for -Ofast.
> Please let me know your inputs.

OK, so it is about 2%.  Did you try if you need lookahead even in the early
pass (before reload)?  My guess would be so, but if not, it could cut the cost
to half.  For -Ofast/-O3 it looks resonable to me, but we will need to announce
it on the ML.  For other settings I think we need to work on more improvmeents 
or cut
the expenses.

Honza
> 
> Regards
> Ganesh
> 
> -Original Message-
> From: Jan Hubicka [mailto:hubi...@ucw.cz] 
> Sent: Thursday, October 24, 2013 2:54 PM
> To: Gopalasubramanian, Ganesh
> Cc: gcc-patches@gcc.gnu.org; Uros Bizjak (ubiz...@gmail.com); hubi...@ucw.cz; 
> H.J. Lu (hjl.to...@gmail.com)
> Subject: Re: Fix scheduler ix86_issue_rate and ix86_adjust_cost for modern 
> x86 chips
> 
> > Attached is the patch which does the following scheduler related changes.
> > * re-models bdver3 decoder.
> > * It enables lookahead with value 8 for all BD architectures. The patch 
> > doesn't consider if reloading is completed or not (an area that needs to be 
> > worked on).
> > * The issue rate for BD architectures are set to 4.
> > 
> > I see the following performance improvements on bdver3 machine.
> > * GemsFDTD improves by 6-7% with lookahead value changed to 8.
> > * Hmmer improves by 9% when issue rate when set to 4 .
> 
> Is this with -fschedule-insns? Or only with default settings?  Did you test 
> the compile time implications of increasing the lookahead? (value of 8 is 
> very large, we may consider enbling it only for -Ofast, limiting for 
> postreload only or something similar).
> 
> > 
> > I have considered the following hardware details for the model.
> > * There are four decoders inside a hardware decoder block.
> > * These four independent decoders can execute in parallel.  (They can take 
> > 8B from four different instructions and decode).
> > * These four decoders are pipelined 4 cycles deep and are non-stalling.
> > * Each decoder takes 8B of instruction data every cycle and tries decoding 
> > it. 
> > * Issue rate is 4.
> What is the overall limitation on number of bytes the instructions can occupy?
> I think they need to fit into 2 16 byte windows, right?
> In that case we may want to tweak the existing corei7 scheduling code to take 
> care of this.  Making scheduler not overly optimistic about the parallelism 
> is good since it will make less register pressure during the first pass..
> > 
> > Is it OK for upstream?
> 
> Otherwise the patch seems OK, but I would like to know the compile time 
> effect first.
> 
> Honza
> > 
> > Changelog
> > 
> > 2013-10-24  Ganesh Gopalasubramanian  
> > 
> > 
> > * config/i386/bdver3.md : Added two additional decoder units 
> > to support issue rate of 4 and remodeled vector unit.
> > 
> > * config/i386/i386.c (ix86_issue_rate): Issue rate for BD
> > architectures is set to 4.
> > 
> > * config/i386/i386.c (ia32_multipass_dfa_lookahead): DFA
> > lookahead is set to 8 for BD architectures.
> > 
> > Regards
> > Ganesh
> > 
> 
> 
> 

Re: [C++ PATCH] Fix PR58705

[Jason Merrill]

On 10/14/2013 08:23 AM, Marek Polacek wrote:

We were ICEing on the attached testcase, because in check_narrowing,
for = {{}}, we wanted to check recursively the CONSTRUCTOR_ELTs,
even though init in this case has 0 CONSTRUCTOR_NELTS.  So I added
the check for CONSTRUCTOR_NELTS > 0.  Moreover, since empty scalar
initializers are forbidden in C FE, I think we should error out here
too.  (Complex type is considered as an arithmetic type as a GNU
extension and arithmetic types are scalar types.)


Empty scalar initializers are allowed in C++11, so we shouldn't give an 
error.  Your initial patch from bugzilla is OK, with an appropriately 
adjusted testcase.


Jason

Re: [PATCH, PR 57748] Check for out of bounds access, Part 2

[Jakub Jelinek]

On Thu, Oct 24, 2013 at 02:55:59PM +0200, Bernd Edlinger wrote:
> On Thu, 24 Oct 2013 12:18:43, Richard Biener wrote:
> >
> > On Thu, Oct 24, 2013 at 10:48 AM, Eric Botcazou  
> > wrote:
> >>> I think that is common practice to write array[1]; at the end of the
> >>> structure, and use it as a flexible array. The compute_record_mode has no
> >>> way to decide if that is going to be a flexible array or not.
> >>>
> >>> Sorry Eric, but now I have no other choice than to go back to my previous
> >>> version of part 2:
> >>>
> >>> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00222.html
> >>
> >> Why? Just set BLKmode in this case as well.
> >
> > Works for me if it works ABI-wise (which you say it should unless the
> > backend is buggy). Note that means mode_for_array should unconditionally
> > return BLKmode.
> 
> Did you just propose:

But why would we want to penalize the generated code for this?
I mean, if some structure has a flexible array member or something similar
to it that we allow to be used as one, if we pass it as arguments, return
from functions etc., it will not have any bits beyond those and thus it
should be just fine to be passed in registers etc.  We can only use those
extra bits if either we allocate them on the heap/stack (malloc, alloca,
...) or as a global or automatic variable with initializer that fills in the
zero sized array or flexible array member (GNU extensions?), but in either
of these cases the DECL_MODE or TYPE_MODE should be irrelevant.

So to me this really sounds like a bug in the expansion, certainly not
stor-layout.

Jakub

Re: [patch] Relocate a couple of va_arg_expr routines.

[Richard Biener]

On Thu, Oct 24, 2013 at 3:06 PM, Andrew MacLeod  wrote:
> I originally shuffled std_gimplify_va_arg_expr () to gimplify.c, but i
> believe the suggestion was to eventually move it to targhooks.c.
>
> build_va_arg_indirect_ref seems to  hang around with it, and used by all the
> same things that use  std_gimplify_va_arg_expr, so this patch currently
> lumps it in targhooks.c as well (which means they will get it with the same
> header file).   Really, I suppose it should go elsewhere.. and I'd guess
> tree.c...  but its nots 100% obvious... suggestions welcome.   I'd think
> someday this file will get split into gimple-targhooks and rtl-targhooks,
> but not today i think. :-)
>
> It also seems appropriate to move gimplify_va_arg_expr from builtins.c to
> gimplify.c since its a gimplification routiine.. This showed up as I was
> splitting gimple.h into gimplify.h... the prototype is in gimple.h and it
> made sense to become part of gimplify.h as I try to move towards an
> interface from front-ends that only requires gimplfy.h and not gimple.h or
> other middle end things.
>
> bootstraps on x86_64-unknown-linux-gnu with no new regressions.  OK?

Ok.

Err ...

Index: targhooks.c
===
*** targhooks.c (revision 203915)
--- targhooks.c (working copy)
*** along with GCC; see the file COPYING3.
*** 71,76 
--- 71,77 
  #include "tree-ssa.h"
  #include "tree-ssa-alias.h"
  #include "insn-codes.h"
+ #include "tree-mudflap.h"

we were supposed to remove mudflap for 4.9, no?

Thanks,
Richard.

> Anrdew
>
>

Re: [PATCH, PR 57748] Check for out of bounds access, Part 2

[Richard Biener]

On Thu, Oct 24, 2013 at 2:55 PM, Bernd Edlinger
 wrote:
> On Thu, 24 Oct 2013 12:18:43, Richard Biener wrote:
>>
>> On Thu, Oct 24, 2013 at 10:48 AM, Eric Botcazou  
>> wrote:
 I think that is common practice to write array[1]; at the end of the
 structure, and use it as a flexible array. The compute_record_mode has no
 way to decide if that is going to be a flexible array or not.

 Sorry Eric, but now I have no other choice than to go back to my previous
 version of part 2:

 http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00222.html
>>>
>>> Why? Just set BLKmode in this case as well.
>>
>> Works for me if it works ABI-wise (which you say it should unless the
>> backend is buggy). Note that means mode_for_array should unconditionally
>> return BLKmode.
>
> Did you just propose:
>
> --- stor-layout.c.orig2013-10-22 10:46:49.233261818 +0200
> +++ stor-layout.c2013-10-24 14:54:00.425259062 +0200
> @@ -471,27 +471,7 @@
>  static enum machine_mode
>  mode_for_array (tree elem_type, tree size)
>  {
> -  tree elem_size;
> -  unsigned HOST_WIDE_INT int_size, int_elem_size;
> -  bool limit_p;
> -
> -  /* One-element arrays get the component type's mode.  */
> -  elem_size = TYPE_SIZE (elem_type);
> -  if (simple_cst_equal (size, elem_size))
> -return TYPE_MODE (elem_type);
> -
> -  limit_p = true;
> -  if (host_integerp (size, 1) && host_integerp (elem_size, 1))
> -{
> -  int_size = tree_low_cst (size, 1);
> -  int_elem_size = tree_low_cst (elem_size, 1);
> -  if (int_elem_size> 0
> -  && int_size % int_elem_size == 0
> -  && targetm.array_mode_supported_p (TYPE_MODE (elem_type),
> - int_size / int_elem_size))
> -limit_p = false;
> -}
> -  return mode_for_size_tree (size, MODE_INT, limit_p);
> +  return BLKmode;
>  }
>
> ???

Yes.  Does it work?

Richard.

>
>> Richard.
>>
>>> --
>>> Eric Botcazou