[Bug fortran/70233] New: Missing diagnostic in array constructor, different size strings

[jvdelisle at gcc dot gnu.org]

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

Bug ID: 70233
   Summary: Missing diagnostic in array constructor, different
size strings
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org
  Target Milestone: ---

In the following code, one case of the constructor gives an error and one does
not.

integer, parameter :: char_len = 32
character(char_len), allocatable :: ch_array(:)
character(char_len) :: ch, bh

allocate(ch_array(5))
print *,lbound(ch_array), ubound(ch_array)
ch = "a"
bh = "b"
!ch_array = [bh, "def", ch, ch, bh]! no error given
ch_array = ["def", bh, ch, ch, ch] ! error given
print *, ch_array
deallocate(ch_array)
end

[PATCH] Fix 70199

[Richard Henderson]

The problem here is that

  void* labels[] = {
&, &, &
  };

gets gimplified to

  labels = *.LC0;

but .LC0 is not in the set of local decls, so that when copy_forbidden is 
called during sra versioning we fail to forbid the copy.  We could set a 
different flag, but I think it's easiest to just add the artificial decl to 
where it can be seen.


Ok?


r~
* gimplify.c (gimplify_init_constructor): Add the constant def decl
to the function's local decls.


diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index b331e41..884482e 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -4016,6 +4016,7 @@ gimplify_init_constructor (tree *expr_p, gimple_seq 
*pre_p, gimple_seq *post_p,
 
walk_tree (, force_labels_r, NULL, NULL);
ctor = tree_output_constant_def (ctor);
+   add_local_decl (cfun, ctor);
if (!useless_type_conversion_p (type, TREE_TYPE (ctor)))
  ctor = build1 (VIEW_CONVERT_EXPR, type, ctor);
TREE_OPERAND (*expr_p, 1) = ctor;

[Bug middle-end/70199] [5/6 Regression] Crash at -O2 when using labels.

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||rth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rth at gcc dot gnu.org

--- Comment #5 from Richard Henderson  ---
Mine.

[Bug c++/15272] lookup, dependent base

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2013-01-19 00:00:00 |2016-3-14
 CC||msebor at gcc dot gnu.org
  Known to fail|5.2.0   |4.5.3, 4.8.3, 4.9.3, 5.3.0,
   ||6.0

--- Comment #13 from Martin Sebor  ---
Reconfirming as still present in 6.0 (and all prior versions):

$ cat v.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic -xc++ v.c
struct X { void f (); };
struct Y { void f (); };

template 
struct A: T, X {
  void foo () {
f ();
  }
};

template struct A;
v.c: In instantiation of ‘void A::foo() [with T = Y]’:
v.c:11:17:   required from here
v.c:7:5: error: request for member ‘f’ is ambiguous
 f ();
 ^
v.c:1:17: note: candidates are: void X::f()
 struct X { void f (); };
 ^
v.c:2:17: note: void Y::f()
 struct Y { void f (); };
 ^

[Bug c++/55992] constexpr static member function not recognised in templated using statement

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2013-01-15 00:00:00 |2016-3-14
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.1.0, 6.0

--- Comment #7 from Martin Sebor  ---
Reconfirmed with today's top of trunk of 6.0 and with all prior supported
versions.  Below is an ever-so-slightly simpler test case:

$ cat v.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic -xc++ v.c
template  struct A { };

template 
struct B
{
  static constexpr int f (int i) { return i; }

  template 
  using C = A;   // error

  C c;
};
v.c: In substitution of ‘template template using C = A
[with int J = I; int I = I]’:
v.c:11:6:   required from here
v.c:9:17: error: ‘f’ was not declared in this scope
   using C = A;   // error
   ~~^~~

[Bug sanitizer/70147] [6 Regression] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[bernd.edlinger at hotmail dot de]

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

--- Comment #15 from Bernd Edlinger  ---
Yep, maybe this would be a compromise:

Index: cp-ubsan.c
===
--- cp-ubsan.c  (revision 234184)
+++ cp-ubsan.c  (working copy)
@@ -285,6 +285,15 @@ cp_ubsan_dfs_initialize_vtbl_ptrs (tree binfo, voi

   if (!BINFO_PRIMARY_P (binfo) || BINFO_VIRTUAL_P (binfo))
 {
+  tree if_stmt = NULL_TREE;
+
+  if (BINFO_VIRTUAL_P (binfo))
+  {
+   tree flag = DECL_CHAIN (DECL_ARGUMENTS (current_function_decl));
+   if_stmt = begin_if_stmt ();
+   finish_if_stmt_cond (flag, if_stmt);
+  }
+
   tree base_ptr = TREE_VALUE ((tree) data);

   base_ptr = build_base_path (PLUS_EXPR, base_ptr, binfo, /*nonnull=*/1,
@@ -301,6 +310,11 @@ cp_ubsan_dfs_initialize_vtbl_ptrs (tree binfo, voi
   tree vtbl = build_zero_cst (TREE_TYPE (vtbl_ptr));
   finish_expr_stmt (cp_build_modify_expr (vtbl_ptr, NOP_EXPR, vtbl,
  tf_warning_or_error));
+  if (if_stmt != NULL_TREE)
+  {
+   finish_then_clause (if_stmt);
+   finish_if_stmt (if_stmt);
+  }
 }

   return NULL_TREE;


It does not catch the calls to i() but, it slightly improves
this test case and avoids the eh-problem from the previous example:

cat test1.cc
struct A { A () {} A (int x) : a (x) {} virtual int i () { return 0; } int a;
};
__attribute__((noinline,noclone)) int foo (A* x) { return x->i(); }
struct B : virtual A { B () {} B (int x) : A (foo (this)) {} };
struct C : virtual B { C () : A (foo (this)), B (foo (this)) {} };

int
main ()
{
  C cc;
}

this invalid example does not crash as it would with my other patch,
which never erases the virtual vptr.

g++ -fsanitize=undefined -fno-sanitize-recover=undefined test1.cc
./a.out
test1.cc:2:64: runtime error: load of null pointer of type ' *'

note the message is about null pointer not undefined vptr, but at
least it is not a segfault.

[Bug rtl-optimization/69941] bogus zero_extend transformation in postreload on aarch64

[bernds at gcc dot gnu.org]

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

--- Comment #7 from Bernd Schmidt  ---
Author: bernds
Date: Tue Mar 15 03:14:38 2016
New Revision: 234210

URL: https://gcc.gnu.org/viewcvs?rev=234210=gcc=rev
Log:
Backport PR69941 patch from mainline.

PR rtl-optimization/69941
* postreload.c (reload_combine_recognize_pattern): Ensure all uses of
the reg share its mode.

PR rtl-optimization/69941
* gcc.dg/torture/pr69941.c: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr69941.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/postreload.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69941] bogus zero_extend transformation in postreload on aarch64

[bernds at gcc dot gnu.org]

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

--- Comment #6 from Bernd Schmidt  ---
Author: bernds
Date: Tue Mar 15 03:10:31 2016
New Revision: 234209

URL: https://gcc.gnu.org/viewcvs?rev=234209=gcc=rev
Log:
Backport PR69941 patch from mainline.

PR rtl-optimization/69941
* postreload.c (reload_combine_recognize_pattern): Ensure all uses of
the reg share its mode.

PR rtl-optimization/69941
* gcc.dg/torture/pr69941.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr69941.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/postreload.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c++/55004] [meta-bug] constexpr issues

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 53792, which changed state.

Bug 53792 Summary: [C++11] improving compiler-time constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53792

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug c++/53792] [C++11] improving compiler-time constexpr evaluation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Martin Sebor  ---
Fixed.

[Bug c++/53792] [C++11] improving compiler-time constexpr evaluation

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
Author: msebor
Date: Tue Mar 15 03:05:17 2016
New Revision: 234208

URL: https://gcc.gnu.org/viewcvs?rev=234208=gcc=rev
Log:
PR c++/53792 - [C++11] improving compiler-time constexpr evaluation

gcc/testsuite/ChangeLog:
2016-03-14  Martin Sebor  

PR c++/53792
* g++.dg/cpp0x/constexpr-inline.C: New test.
* g++.dg/cpp0x/constexpr-inline-1.C: Same.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-inline-1.C
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-inline.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug c++/53792] [C++11] improving compiler-time constexpr evaluation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to work||6.0

--- Comment #9 from Martin Sebor  ---
This now works as expected (i.e., the calls to constexpr functions are folded
regardless of whether or not they are invoked in a constexpr context) provided
inlining is enabled.  Without inlining the calls are not folded outside of
constexpr (this was changed in r233671).  I've added tests for this bug and
will close it as fixed/resolved.

Re: C++ PATCH for range-for tweak

[Jason Merrill]

On 03/14/2016 05:30 PM, Florian Weimer wrote:

* Jason Merrill:


P08184R0: Generalizing the Range-Based For Loop


How can one resolve this reference?  It's obviously not a PR number in
GCC Bugzilla.

I found this after some searching:



But it lacks the additional “8”.


Oops, typo.  Fixed, along with adjusting the feature-test macro.


commit 83c74d69d3cc41bc764d75d52effadd2802140ec
Author: Jason Merrill 
Date:   Mon Mar 14 22:55:55 2016 -0400

	* c-cppbuiltin.c (c_cpp_builtins): Bump __cpp_range_based_for.

diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
index 1c7..dc1f426 100644
--- a/gcc/c-family/c-cppbuiltin.c
+++ b/gcc/c-family/c-cppbuiltin.c
@@ -871,7 +871,7 @@ c_cpp_builtins (cpp_reader *pfile)
 	  cpp_define (pfile, "__cpp_namespace_attributes=201411");
 	  cpp_define (pfile, "__cpp_enumerator_attributes=201411");
 	  cpp_define (pfile, "__cpp_nested_namespace_definitions=201411");
-	  cpp_define (pfile, "__cpp_fold_expressions=201411");
+	  cpp_define (pfile, "__cpp_fold_expressions=201603");
 	  cpp_define (pfile, "__cpp_nontype_template_args=201411");
 	}
   if (flag_concepts)

Re: [PATCH] PR69195, Reload confused by invalid reg equivs

[Alan Modra]

On Mon, Mar 14, 2016 at 01:00:39PM -0600, Jeff Law wrote:
> Right.  Tolerant as in not crash.

So can someone please approve my ira.c:indirect_jump_optimize patch?
I'm not quite audacious enough to claim it is obvious.  The original
is at https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00720.html,
reposted here with some additional comments.  Bootstrapped and
regression tested powerpc64le-linux and x86_64-linux.

(In the thread I mentioned we could use DF_REF_INSN_INFO in place of
!DF_REF_IS_ARTIFICAL.  I believe that is true, and it saves an access
to another field of df_ref, but !DF_REF_IS_ARTIFICIAL before access to
DF_REF_INSN or DF_REF_INSN_UID is somewhat more prevalent in the gcc
sources.)

PR rtl-optimization/69195
PR rtl-optimization/47992
* ira.c (indirect_jump_optimize): Ignore artificial defs.
Add comments.

diff --git a/gcc/ira.c b/gcc/ira.c
index 5e7a2ed..a543d90 100644
--- a/gcc/ira.c
+++ b/gcc/ira.c
@@ -3842,7 +3842,8 @@ update_equiv_regs (void)
   free (pdx_subregs);
 }
 
-/* A pass over indirect jumps, converting simple cases to direct jumps.  */
+/* A pass over indirect jumps, converting simple cases to direct jumps.
+   Combine does this optimization too, but only within a basic block.  */
 static void
 indirect_jump_optimize (void)
 {
@@ -3862,14 +3863,23 @@ indirect_jump_optimize (void)
   int regno = REGNO (SET_SRC (x));
   if (DF_REG_DEF_COUNT (regno) == 1)
{
- rtx_insn *def_insn = DF_REF_INSN (DF_REG_DEF_CHAIN (regno));
- rtx note = find_reg_note (def_insn, REG_LABEL_OPERAND, NULL_RTX);
-
- if (note)
+ df_ref def = DF_REG_DEF_CHAIN (regno);
+ if (!DF_REF_IS_ARTIFICIAL (def))
{
- rtx lab = gen_rtx_LABEL_REF (Pmode, XEXP (note, 0));
- if (validate_replace_rtx (SET_SRC (x), lab, insn))
-   rebuild_p = true;
+ rtx_insn *def_insn = DF_REF_INSN (def);
+ rtx note = find_reg_note (def_insn, REG_LABEL_OPERAND, NULL_RTX);
+
+ if (note)
+   {
+ /* Substitute a LABEL_REF to the label given by the
+note rather than using SET_SRC of DEF_INSN.
+DEF_INSN might be loading the label constant from
+a constant pool, which isn't what we want in a
+direct branch.  */
+ rtx lab = gen_rtx_LABEL_REF (Pmode, XEXP (note, 0));
+ if (validate_replace_rtx (SET_SRC (x), lab, insn))
+   rebuild_p = true;
+   }
}
}
 }

-- 
Alan Modra
Australia Development Lab, IBM

[Bug target/70220] [x86] interrupt attribute optionally needs to provide read, write and control the set of saved registers

[wink at saville dot com]

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

--- Comment #15 from Wink Saville  ---
(In reply to H.J. Lu from comment #14)
> (In reply to Wink Saville from comment #13)
> > > Compiler should be free to use rbp in anyway it sees fit. Spec shouldn't
> > > say anything other than rbp is special to compiler.
> > 
> > If the compiler does decide to change rbp it must save original value,
> > correct?
> 
> Yes.  But you don't know how/when it happens.

For the debugger use case and maybe for the thread context switch I need access
to all registers original values, rbp included.

I'd like to propose, for the narrow case of using the "all" parameter we
specify that the compiler will either always not use rbp or that it always
saves rbp at a known location. In all other cases rbp is unavailable for use by
C code.

[Bug target/70188] [4.9/5/6 Regression] gcc 4.9+ miscompiles code on hppa

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

  Component|ipa |target

--- Comment #8 from John David Anglin  ---
Culprit is constraints.md hunk in r220681 (4.9 branch).  On hppa, it's
not possible to reload all memory operands to a base register.  So, we
can't use define_memory_constraint for the Q and T constraints.

Reverting fixes kernel build.

[Bug fortran/70231] Runtime error: Different CHARACTER lengths in array constructor with allocatable array and -O0

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-15
 CC||jvdelisle at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
Interesting: -fdump-tree-original snippets

 snip 

ch_array.dim[0].lbound = 1;
ch_array.dim[0].ubound = 0;

 snip 

D.3452 = ch_array.dim[0].lbound;
D.3453 = ch_array.dim[0].ubound;
 snip 

  S.6 = D.3452;
  while (1)
{
  if (S.6 > D.3453) goto L.1;
  __builtin_memmove ((void *) &(*(character(kind=1)[1][1:32] *
restrict) atmp.4.data)[offset.5][1]{lb: 1 sz: 1}, (void *) &(*D.3450)[S.6 +
D.3451], 32);
  len.3 = 32;
  offset.5 = offset.5 + 1;
  S.6 = S.6 + 1;
}
  L.1:;
}
  }
  __builtin_memmove ((void *) &(*(character(kind=1)[1][1:32] *
restrict) atmp.4.data)[offset.5][1]{lb: 1 sz: 1}, (void *) , 32);
  if ((integer(kind=8)) (len.3 != 32))
{
  _gfortran_runtime_error_at (&"At line 8 of file
pr70231.f90"[1]{lb: 1 sz: 1}, &"Different CHARACTER lengths (%ld/%ld) in array
constructor"[1]{lb: 1 sz: 1}, (integer(kind=8)) len.3, 32);
}

len.3 does not get set because the lower bound of ch_array is greater than the
upperbound, so when the check is done, len.3 is uninitialized.

Re: [RFA][PATCH][PR tree-optimization/64058] Improve and stabilize sorting of coalesce pairs

[Trevor Saunders]

On Mon, Mar 14, 2016 at 04:32:06PM -0600, Jeff Law wrote:
> On 03/11/2016 03:02 AM, Richard Biener wrote:
> >
> >
> >For the other part I noticed a few things
> >  1) having a bitmap_count_ior_bits () would be an improvement
> Yea, I almost built one.  That's easy enough to add.
> 
> >  2) you might end up with redundant work(?) as you are iterating
> >  over SSA name coalesce candidates but look at partition conflicts
> We'd have redundant work if the elements mapped back to SSA_NAMEs which in
> turn mapped to partitions which appeared as a coalescing pair already.  But
> there's no way to know that in advance.
> 
> This is mitigated somewhat in the next version which computes the conflict
> sizes lazily when the qsort comparison function is given two conflict pairs
> with an equal cost.
> 
> 
> 
> >  3) having this extra heuristic might be best guarded by
> >flag_expensive_optimizations
> Perhaps.  I don't see this tie breaker as being all that expensive.  But I
> won't object to guarding with flag_expensive_optimizations.
> 
> >  as it is a quite expensive "tie breaker" - maybe even improve things
> >by first sorting
> >  after cost and then only doing the tie breaking when necessary, re-sorting 
> > the
> >  sub-sequence with same original cost.  It may also be enough to only 
> > perform
> >  this for "important" candidates, say within the first 100 of the function 
> > or so
> >  or with cost > X.
> The problem with this is qsort's interface into the comparison function has
> a terribly narrow API and I don't think we want to rely on qsort_r.  In fact
> that's the whole reason why I didn't do lazy evaluation on the conflict
> sizes initially.
> 
> To work around the narrow API in the comparison function we have to either
> store additional data in each node or have them available in globals.  The
> former would be horribly wasteful, the latter is just ugly.  I choose the
> latter in the lazy evaluation of the conflicts version.

its a bit ugly in C++98, but you can give std::sort a random object with
operator () to compare with.

Trev

[Bug target/70220] [x86] interrupt attribute optionally needs to provide read, write and control the set of saved registers

[hjl.tools at gmail dot com]

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

--- Comment #14 from H.J. Lu  ---
(In reply to Wink Saville from comment #13)
> > Compiler should be free to use rbp in anyway it sees fit. Spec shouldn't
> > say anything other than rbp is special to compiler.
> 
> If the compiler does decide to change rbp it must save original value,
> correct?

Yes.  But you don't know how/when it happens.

[Bug target/70232] excessive stack usage with -O2

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
>I have only tested on 32-bit ARM, 

Looks only to be an 32bit ARM issue.  AARCH64 both LP64 and ILP32 does not have
a stack size issue.  
For both of those we get:
stp x29, x30, [sp, -128]!

So only 128 bytes.

[Bug c/70232] New: excessive stack usage with -O2

[arnd at linaro dot org]

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

Bug ID: 70232
   Summary: excessive stack usage with -O2
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Created attachment 37964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37964=edit
partially reduced test case

Using gcc-6.0 for building the Linux kernel, I see one file (out of many
hundred randconfig test builds so far) that occasionally hits the maximum
per-function stack size limit. I have only tested on 32-bit ARM, and I have
manually reduced the test case:

$ arm-linux-gnueabi-gcc -o lpfc_scsi.o -O2 -Wframe-larger-than=1024
lpfc_scsi.c: In function 'lpfc_find_next_oas_lun':
lpfc_scsi.c:117:1: warning: the frame size of 1152 bytes is larger than 1024
bytes [-Wframe-larger-than=]
$ arm-linux-gnueabi-gcc --version   
arm-linux-gnueabi-gcc (GCC) 6.0.0 20160313 (experimental)

I see this with all options as long as -O2 is set, but not with -O3 or -O1 or
-Os. Normal stack usage for this function is usually 128 bytes.

Re: [PATCH] genrecog: Fix crash on invalid input

[Bernd Schmidt]

On 03/14/2016 09:00 PM, Segher Boessenkool wrote:

There is just the single caller, and pred is set right before the call
there.  How about this patch, then?


Looks alright.


Bernd

Re: [PATCH, testsuite] Fix ifcvt-4.c for PowerPC

[David Edelsohn]

On Mon, Mar 14, 2016 at 7:35 PM, Jeff Law  wrote:
> On 03/14/2016 02:23 PM, Pat Haugen wrote:
>>
>> As stated in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68232, this
>> test needs -misel on powerpc to pass. Verified the following fixes the
>> test on both powerpc64/powerpc64le. Ok for trunk?
>>
>> -Pat
>>
>> testsuite/ChangeLog:
>> 2016-03-14  Pat Haugen  
>>
>>  * gcc.dg/ifcvt-4.c: Add -misel for powerpc* and remove skip for
>> powerpc64le.
>
> OK.
> jeff

The change is going to fail on PowerPC systems that don't support
ISEL, so it needs to be adjusted.

- David

[Bug rtl-optimization/70224] [6 regression] ICE: RTL flag check: CROSSING_JUMP_P used with unexpected rtx code 'insn' in relax_delay_slots, at reorg.c:3310

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
I've got the obvious patch bootstrap testing on sparc linux via qemu in
progress.  It'll be interesting to see how long this takes.

Re: [PATCH, testsuite] Fix ifcvt-4.c for PowerPC

[Jeff Law]

On 03/14/2016 02:23 PM, Pat Haugen wrote:

As stated in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68232, this
test needs -misel on powerpc to pass. Verified the following fixes the
test on both powerpc64/powerpc64le. Ok for trunk?

-Pat

testsuite/ChangeLog:
2016-03-14  Pat Haugen  

 * gcc.dg/ifcvt-4.c: Add -misel for powerpc* and remove skip for
powerpc64le.

OK.
jeff

[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typ

[ian at airs dot com]

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

--- Comment #9 from Ian Lance Taylor  ---
Yes.  The relevant bits in the mangling ABI are


   ::= [gs] 
   ::= sr  
   ::= srN  + E

   ::= [gs] sr + E 


   ::= 
   ::= on 
   ::= on  
   ::= dn 

 ::= 

 ::=  [  ]

 ::=  


srT_ must be sr  , where the T_ is the
, so it must be followed by . 
 can only start with a digit or "on" or "dn".  So I see
no way that srT_cl could meet the requirements of the ABI.  It has to be
srT_oncl, where the "on" is needed to indicate that "cl" is an operator name.

That said, GCC is not crazy, as there is no other way to parse this.  The
result is unambiguous.  But it doesn't meet the documented standard.

I think the bug may be that cp/mangle.c:write_member_name needs to check
IDENTIFIER_OPNAME_P and print "on" if it is true, as write_expression does. 
But I'm not sure.

[Bug target/70220] [x86] interrupt attribute optionally needs to provide read, write and control the set of saved registers

[wink at saville dot com]

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

--- Comment #13 from Wink Saville  ---
(In reply to H.J. Lu from comment #12)
> (In reply to Wink Saville from comment #11)
> > > > The rsp is always saved/restored by the hardware, and your struct frame
> > > > pointer provides access to it so no problem there. It is special because
> > > > when there are local variables the compiler needs to modify it and 
> > > > currently
> > > > it does that after the registers are saved. How will we coordinate the
> > > > compiler initializing rsp and the programming saving the registers?
> > > 
> > > Why is it a problem if IRS doesn't assume what/how compiler does?
> > 
> > I'm in total agreement, the programmer cannot assume anything and must rely
> > on what the interrupt attribute specification says.
> > 
> > At the moment the technique for saving the registers using mov's instead of
> > push/pop's looks to resolve a possible problem of the programmer
> > manipulating rsp. So the only problem seems to be how make rbp accessible
> > because its special. I suggest the interrupt attribute specification say
> > something along the lines of:
> > 
> > "The interrupt attribute takes optional parameters. The parameters are a
> > list of registers that the compiler will NOT save and it will be the
> > responsibility of the programmer to save them. As a convenience to the
> > programmer a single "all" parameter maybe used instead of a specific list.
> > The only register not allowed is RBP as its reserved for use by the 
> > compiler.
> 
> So far so good.
> 
> > If there is a list of registers to not save then original value of rbp will
> > be saved to RAM and rbp will be set to its location."
> 
> Compiler should be free to use rbp in anyway it sees fit. Spec shouldn't
> say anything other than rbp is special to compiler.

If the compiler does decide to change rbp it must save original value, correct?

Re: [PATCH, 4/16] Implement -foffload-alias

[Tom de Vries]

On 14/03/16 14:16, Tom de Vries wrote:

On 02/12/15 10:58, Jakub Jelinek wrote:

On Fri, Nov 27, 2015 at 01:03:52PM +0100, Tom de Vries wrote:

Handle non-declared variables in kernels alias analysis

2015-11-27  Tom de Vries  

* gimplify.c (gimplify_scan_omp_clauses): Initialize
OMP_CLAUSE_ORIG_DECL.
* omp-low.c (install_var_field_1): Handle base_pointers_restrict for
pointers.
(map_ptr_clause_points_to_clause_p)
(nr_map_ptr_clauses_pointing_to_clause): New function.
(omp_target_base_pointers_restrict_p): Handle GOMP_MAP_POINTER.
* tree-pretty-print.c (dump_omp_clause): Print OMP_CLAUSE_ORIG_DECL.
* tree.c (omp_clause_num_ops): Set num_ops for OMP_CLAUSE_MAP to 3.
* tree.h (OMP_CLAUSE_ORIG_DECL): New macro.

* c-c++-common/goacc/kernels-alias-10.c: New test.
* c-c++-common/goacc/kernels-alias-9.c: New test.


I don't like this (mainly the addition of OMP_CLAUSE_ORIG_DECL),
but it also sounds wrong to me.
The primary question is how do you handle GOMP_MAP_POINTER
(which is something we don't use for C/C++ OpenMP anymore,
and Fortran OpenMP will stop using it in GCC 7 or 6.2?) on the OpenACC
libgomp side, does it work like GOMP_MAP_ALLOC or GOMP_MAP_FORCE_ALLOC?


When a GOMP_MAP_POINTER mapping is encountered, first we check if it has
been mapped before:
- if it hasn't been mapped before, we check if the area the pointer
   points to has been mapped, and if not, error out. Else we map the
   pointer to a device pointer, and write the device pointer value
   to the device pointer variable.
- if the pointer has been mapped before, we reuse the mapping and write
   the device pointer value to the device pointer variable.


Similarly GOMP_MAP_TO_PSET.
If it works like GOMP_MAP_ALLOC (it does
on the OpenMP side in target.c, so if something is already mapped, no
further pointer assignment happens), then your change looks wrong.
If it works like GOMP_MAP_FORCE_ALLOC, then you just should treat
GOMP_MAP_POINTER on all OpenACC constructs as opcode that allows the
restrict operation.


I guess it works mostly like GOMP_MAP_ALLOC, but I don't understand the
relevance of the comparison for the patch. What is interesting for the
restrict optimization is whether what GOMP_MAP_POINTER points to has
been mapped with or without the force flag during the same mapping
sequence.


If it should behave differently depending on
if the corresponding array section has been mapped with GOMP_MAP_FORCE_*
or without it,


The mapping itself shouldn't behave differently.


then supposedly you should use a different code for
those two.


I could add f.i. an unsigned int aux_flags to struct tree_omp_clause,
set a new POINTS_TO_FORCE_VAR flag when translating the acc clause into
mapping clauses, and use that flag later on when dealing with the
GOMP_MAP_POINTER clause. Is that an acceptable approach?

[ Instead I could define a new gcc-internal-only
GOMP_MAP_POINTER_POINTS_TO_FORCE kind, but I'd rather avoid this, given
that it would be handled the same as GOMP_MAP_POINTER everywhere, except
for a single point in the source code. ]


I found the example of OMP_CLAUSE_MAP_ZERO_BIAS_ARRAY_SECTION and 
OMP_CLAUSE_MAP_MAYBE_ZERO_LENGTH_ARRAY_SECTION, which re-purpose 
existing but unused fields, and used something similar in attached patch 
(untested, c-only for the moment).


Thanks,
- Tom

2016-03-14  Tom de Vries  

	* omp-low.c (install_var_field): Handle base_pointers_restrict for
	pointers.
	(omp_target_base_pointers_restrict_p): Handle GOMP_MAP_POINTER.
	* tree.h (OMP_CLAUSE_MAP_POINTER_TO_FORCED): define.

	* c-typeck.c (handle_omp_array_sections): Set
	OMP_CLAUSE_MAP_POINTER_TO_FORCED on GOMP_MAP_POINTER clause.

	* c-c++-common/goacc/kernels-alias-10.c: New test.
	* c-c++-common/goacc/kernels-alias-9.c: New test.

Handle non-declared variables in kernels alias analysis

---
 gcc/c/c-typeck.c   | 15 ++-
 gcc/omp-low.c  | 48 ++
 .../c-c++-common/goacc/kernels-alias-10.c  | 29 +
 gcc/testsuite/c-c++-common/goacc/kernels-alias-9.c | 29 +
 gcc/tree.h |  3 ++
 5 files changed, 123 insertions(+), 1 deletion(-)

diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index 6aa0f03..a05831d 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -12446,7 +12446,20 @@ handle_omp_array_sections (tree c, bool is_omp)
 	  }
   tree c2 = build_omp_clause (OMP_CLAUSE_LOCATION (c), OMP_CLAUSE_MAP);
   if (!is_omp)
-	OMP_CLAUSE_SET_MAP_KIND (c2, GOMP_MAP_POINTER);
+	{
+	  OMP_CLAUSE_SET_MAP_KIND (c2, GOMP_MAP_POINTER);
+	  switch (OMP_CLAUSE_MAP_KIND (c))
+	{
+	case GOMP_MAP_FORCE_ALLOC:
+	case GOMP_MAP_FORCE_TO:
+	case GOMP_MAP_FORCE_FROM:
+	case GOMP_MAP_FORCE_TOFROM:
+	  OMP_CLAUSE_MAP_POINTER_TO_FORCED (c2) = 1;
+	  break;
+	default:
+	  break;
+	}
+	

[Bug sanitizer/70147] [6 Regression] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[bernd.edlinger at hotmail dot de]

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

--- Comment #14 from Bernd Edlinger  ---
Hi Jakub,

I played a bit with your proposed patch.

consider this test case:

cat test2.cc
struct A { ~A() {} A () {} A (int x) : a (x) {} virtual void f () {} virtual
int i () { return 0; } int a; };
struct E { E () { throw "something"; } E (int x) : e (x) {} virtual void f ()
{} virtual int g () { return 0; } int e; };
struct F { F () {} F (int x) : f (x) {} virtual int h () { return 0; } int f;
};
struct B : virtual A, public E, public F { B () : E (), F () {} virtual void f
() {} int b; };
struct D { D () {} D (int x) : d (x) {} virtual void f () {} int d; };
struct C : B, virtual A { C () {} } ;

int
main ()
{
  try {
C c;
  }
  catch(...)
  {
  }
}
g++ -fsanitize=vptr  test2.cc -fdump-tree-gimple
test2.cc:6:32: runtime error: member call on address 0x7ffdf760fea0 which does
not point to an object of type 'A'
0x7ffdf760fea0: note: object has invalid vptr
 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00
00 00 00  c5 9e 26 d9
  ^~~
  invalid vptr

this happens only due to the redundant initialization of vptr.A in B::B(),
it is not undefined behavior:

C::C()
{
if (1 != 0) goto ; else goto ;
:
D.2986 = >D.2844;
A::A (D.2986);
goto ;
:
:
try
  {
D.2988 = &_ZTT1C + 8;
D.2989 = >D.2842;
B::B (D.2989, D.2988);
...
  }
catch
  {
if (1 != 0) goto ; else goto ;
:
D.3000 = >D.2844;
D.3001 = D.3000->_vptr.A;  -- B initialized vptr.A to null
D.3002 = (long unsigned int) D.3001;
UBSAN_VPTR (D.3000, D.3002, 18446725454765570473, &_ZTI1A, 4B);
A::~A (D.3000);
goto ;
:
:
  }

B::B() (struct B * const this, const void * * __vtt_parm)
{
  MEM[(struct  &)this] = {CLOBBER};
  this->D.2711._vptr.E = 0B;
  D.3012 = MEM[(int (*__vtbl_ptr_type) () * *)__vtt_parm];
  D.3013 = D.3012 + 18446744073709551592;
  D.3014 = MEM[(long int *)D.3013];
  D.3015 = (sizetype) D.3014;
  D.3016 = this + D.3015;
  D.3016->_vptr.A = 0B;
  this->D.2712._vptr.F = 0B;
  {
if (0 != 0) goto ; else goto ;
:
D.3019 = >D.2716;
A::A (D.3019);
goto ;
:
:
try
  {
D.3021 = >D.2711;
E::E (D.3021);  -- this throws "something"

Re: [PATCH] Fix PR56365

[Bernhard Reutner-Fischer]

On March 14, 2016 9:21:25 PM GMT+01:00, Richard Biener 
 wrote:
>On March 14, 2016 7:25:31 PM GMT+01:00, Bernhard Reutner-Fischer
> wrote:
>>On March 14, 2016 12:58:20 PM GMT+01:00, Richard Biener
>> wrote:

>>>+ 
>>>+ int test_01 (int a)
>>>+ {
>>>+   if (127 <= a)
>>
>>Shouldn't this be >= ?
>
>No, note how the constant is left of the <=.
>
Right, I managed to misread this.
Sorry for the noise!

Re: [RFA][PATCH][PR tree-optimization/64058] Improve and stabilize sorting of coalesce pairs

[Jeff Law]

On 03/11/2016 03:02 AM, Richard Biener wrote:



For the other part I noticed a few things
  1) having a bitmap_count_ior_bits () would be an improvement

Yea, I almost built one.  That's easy enough to add.


  2) you might end up with redundant work(?) as you are iterating
  over SSA name coalesce candidates but look at partition conflicts
We'd have redundant work if the elements mapped back to SSA_NAMEs which 
in turn mapped to partitions which appeared as a coalescing pair 
already.  But there's no way to know that in advance.


This is mitigated somewhat in the next version which computes the 
conflict sizes lazily when the qsort comparison function is given two 
conflict pairs with an equal cost.





  3) having this extra heuristic might be best guarded by
flag_expensive_optimizations
Perhaps.  I don't see this tie breaker as being all that expensive.  But 
I won't object to guarding with flag_expensive_optimizations.



  as it is a quite expensive "tie breaker" - maybe even improve things
by first sorting
  after cost and then only doing the tie breaking when necessary, re-sorting the
  sub-sequence with same original cost.  It may also be enough to only perform
  this for "important" candidates, say within the first 100 of the function or 
so
  or with cost > X.
The problem with this is qsort's interface into the comparison function 
has a terribly narrow API and I don't think we want to rely on qsort_r. 
 In fact that's the whole reason why I didn't do lazy evaluation on the 
conflict sizes initially.


To work around the narrow API in the comparison function we have to 
either store additional data in each node or have them available in 
globals.  The former would be horribly wasteful, the latter is just 
ugly.  I choose the latter in the lazy evaluation of the conflicts version.




And finally - if we really think that looking at the conflict size
increase is the way to go
it would maybe be better to use a fibheap updating keys in attempt_coalesce
when we merge the conflicts.  That would also mean to work on a list (fibheap)
of coalesces of partitions rather than SSA names.
I really doubt it's worth this effort.  The literature I've been looking 
at in this space essentially says that given a reasonable coalescer, 
improvements, while measurable, are very very small in terms of the 
efficiency of the final code.


Thus I rejected conservative coalescing + iteration, biased coalescing, 
& trial coalescing as too expensive given the trivial benefit. 
Similarly I rejected trying to update the costs as we coalesce 
partitions.  A single successful coalesce could have a significant 
ripple effect.  Perhaps that could be mitigated by realizing that many 
updates wouldn't be needed, but it's just a level of complexity that's 
not needed here.


And note we work on partitions, not SSA_NAMEs.  It just happens that we 
start with each SSA_NAME in its own partition.  Most SSA_NAMEs actually 
don't participate in coalescing as they're not used in a copy 
instruction or as a phi arg/result.   That's why we compact the 
partitions after we've scanned the IL for names that are going to 
participate in coalescing.








I think the patch is reasonable enough for GCC 6 if we can bring compile-time
cost down a bit (it can be quadratic in the number of SSA names if we have
a lot of coalesce candidates and nearly full conflict bitmaps - of course that's
not a case we handle very well right now but still).  I would have hoped the
index part of the patch fixed the regression (by luck)...
I'd hoped it'd fix the regression by luck as well, but that was not the 
case :(





As far as a testcase goes we want to scan the dumps for the actual coalesces
being done.  Might be a bit fragile though...
I suspect that's going to be quite fragile and may have more target 
dependencies than we'd like (due to branch costing and such).




Jeff

[Bug target/70220] [x86] interrupt attribute optionally needs to provide read, write and control the set of saved registers

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu  ---
(In reply to Wink Saville from comment #11)
> > > The rsp is always saved/restored by the hardware, and your struct frame
> > > pointer provides access to it so no problem there. It is special because
> > > when there are local variables the compiler needs to modify it and 
> > > currently
> > > it does that after the registers are saved. How will we coordinate the
> > > compiler initializing rsp and the programming saving the registers?
> > 
> > Why is it a problem if IRS doesn't assume what/how compiler does?
> 
> I'm in total agreement, the programmer cannot assume anything and must rely
> on what the interrupt attribute specification says.
> 
> At the moment the technique for saving the registers using mov's instead of
> push/pop's looks to resolve a possible problem of the programmer
> manipulating rsp. So the only problem seems to be how make rbp accessible
> because its special. I suggest the interrupt attribute specification say
> something along the lines of:
> 
> "The interrupt attribute takes optional parameters. The parameters are a
> list of registers that the compiler will NOT save and it will be the
> responsibility of the programmer to save them. As a convenience to the
> programmer a single "all" parameter maybe used instead of a specific list.
> The only register not allowed is RBP as its reserved for use by the compiler.

So far so good.

> If there is a list of registers to not save then original value of rbp will
> be saved to RAM and rbp will be set to its location."

Compiler should be free to use rbp in anyway it sees fit. Spec shouldn't
say anything other than rbp is special to compiler.

[Bug middle-end/70219] [6 Regression] ICE: in delete_move_and_clobber, at lra-constraints.c:5864 with -O2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/70219] [6 Regression] ICE: in delete_move_and_clobber, at lra-constraints.c:5864 with -O2

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Mar 14 22:19:32 2016
New Revision: 234201

URL: https://gcc.gnu.org/viewcvs?rev=234201=gcc=rev
Log:
PR middle-end/70219
* lra-constraints.c (delete_move_and_clobber): Change assertion
to also allow dregno == 0.

* gcc.dg/pr70219.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr70219.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/70147] [6 Regression] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
See my mail to gcc-patches.  According to Jonathan, calling i() is invalid,
which your patch would not catch.  And, the virtual vptrs should be at least
initialized in the in-chrg ctor even if we'd want to accept those, so that
would mean applying my patch + for BINFO_VIRTUAL_P wrap up the clearing of the
vtable pointer with if (__in_chrg) if that parameter exists.

[Bug libgcc/66382] POWER8 Vector optimized implementation of __float128 (IEEE754 128-bit Binary Floating Point)

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
On Mon, 14 Mar 2016, dan.parrot at mail dot com wrote:

> However, I am still unable to get gcc to compile a very simple program 
> when passed the -msoft-float option. Here is the program (test.c)

For 32-bit, -msoft-float is a distinct ABI from -mhard-float, and requires 
its own copies of libgcc, libc, etc.; you can't just build and run a 
soft-float program on a hard-float system without building all those 
separate libraries and arranging for the program to find them at link time 
and run time.

For 64-bit, -msoft-float is not supported, and hard-float is always 
available.  (__float128 might use software or hardware floating point - 
software before POWER9, hardware with POWER9 - but that's controlled by 
other options.)

Re: [PATCH] extend.texi: Expand on the perils of using the 'leaf' attribute.

[Sandra Loosemore]

On 03/14/2016 12:40 PM, Carlos O'Donell wrote:

Using the 'leaf' attribute is difficult in certain use cases, and the
documentation rightly points out that signals is one such problem.

We should additionally document the following caveats:

* Indirect function resolvers (thanks to Florian Weimer for catching this).
* Indirect function implementations
* ELF symbol interposition.

[snip]

gcc/
2016-03-14  Carlos O'Donell  

* doc/extend.texi (Common Function Attributes): Describe ifunc impact
on leaf attribute.



H.  Both your patch and the original text really need some 
copy-editing to fix noun/verb agreement, punctuation, etc.  How about 
something like the attached patch?  I just threw this together and 
haven't tested this in any way, but you confirm that it builds and it 
looks OK to you, feel free to check it in.


-Sandra

Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 234198)
+++ gcc/doc/extend.texi	(working copy)
@@ -2773,22 +2773,33 @@ refer to the following subsections for d
 @item leaf
 @cindex @code{leaf} function attribute
 Calls to external functions with this attribute must return to the current
-compilation unit only by return or by exception handling.  In particular, leaf
-functions are not allowed to call callback function passed to it from the current
-compilation unit or directly call functions exported by the unit or longjmp
-into the unit.  Leaf function might still call functions from other compilation
+compilation unit only by return or by exception handling.  In particular,
+a leaf function is not allowed to invoke callback functions passed to it
+from the current compilation unit, directly call functions exported by the
+unit, or @code{longjmp} into the unit.  
+Leaf functions might still call functions from other compilation
 units and thus they are not necessarily leaf in the sense that they contain no
 function calls at all.
 
 The attribute is intended for library functions to improve dataflow analysis.
-The compiler takes the hint that any data not escaping the current compilation unit can
-not be used or modified by the leaf function.  For example, the @code{sin} function
+The compiler takes the hint that any data not escaping the current
+compilation unit cannot be used or modified by the leaf function.  
+For example, the @code{sin} function
 is a leaf function, but @code{qsort} is not.
 
-Note that leaf functions might invoke signals and signal handlers might be
-defined in the current compilation unit and use static variables.  The only
-compliant way to write such a signal handler is to declare such variables
-@code{volatile}.
+Note that leaf functions might indirectly run a signal handler
+defined in the current compilation unit that uses static variables.  Similarly,
+when lazy symbol resolution is in effect, leaf functions might invoke indirect
+functions whose resolver function or implementation function is defined
+in the current compilation unit and uses static variables. There is no 
+standard-compliant way to write such a signal handler, resolver function, or
+implementation function, and the best that you can do is to remove the
+@code{leaf} attribute or mark all such static variables @code{volatile}.  
+Lastly, for ELF-based
+systems that support symbol interposition, you should take care that functions
+defined in the current compilation unit do not unexpectedly interpose other
+symbols based on the defined standards mode; otherwise an inadvertent callback
+would be added.
 
 The attribute has no effect on functions defined within the current compilation
 unit.  This is to allow easy merging of multiple compilation units into one,

Re: [PATCH] c++/67376 Comparison with pointer to past-the-end, of array fails inside constant expression

[Jakub Jelinek]

On Mon, Mar 14, 2016 at 03:25:07PM -0600, Martin Sebor wrote:
> PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end
>   of array fails inside constant expression
> PR c++/70170 - [6 regression] bogus not a constant expression error comparing
>   pointer to array to null
> PR c++/70172 - incorrect reinterpret_cast from integer to pointer error
>   on invalid constexpr initialization
> PR c++/60760 - arithmetic on null pointers should not be allowed in constant
>   expressions
> PR c++/70228 - insufficient detail in diagnostics for a constexpr out of 
> bounds
>   array subscript

Can you please check up the formatting in the patch?
Seems e.g. you've replaced tons of tabs with 8 spaces etc. (check your
editor setting, and check the patch with contrib/check-GNU-style.sh).
There is some trailing whitespace too, spaces before [, etc.

Jakub

[Bug target/70117] ppc long double isinf() is wrong?

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  ---
On Mon, 14 Mar 2016, rguenth at gcc dot gnu.org wrote:

> but it will end up with libcalls for isinf, isfinite and isnormal for
> IBM extended double.  I'm told glibc does the right thing for the gnulib

And corresponding libcalls don't exist (or at least GCC doesn't know of 
them; glibc has some functions such as __isinfl internally).

For the question of correctness of LDBL_MAX - and the related question of 
whether LDBL_EPSILON, although correct by the current standard definition, 
should change - see DR#467 (open).  (But the reference there to DBL_MAX*2 
as a finite number does not apply to the IBM long double format 
implemented by GCC, because of the rule about the round-to-nearest sum of 
the two parts equalling the top part.)  
(libgcc/config/rs6000/ibm-ldouble-format defines values with more than 106 
mantissa bits not to be normal - denormal but not subnormal.)

[Bug c++/53181] static_assert sees as non constant the comparison between a constexpr and a template argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #4 from Martin Sebor  ---
Confirmed with all supported versions of GCC including the current trunk of
6.0.

A slightly simplified test case:

$ cat v.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
-xc++ v.c
struct S {
static constexpr char a[] = "A";
static constexpr char b[] = "A";

template 
static bool f () {
constexpr bool isa = S == a;
constexpr bool isb = S == b;
return isa || isb;
}
};

template bool S::f();
template bool S::f();

v.c: In instantiation of ‘static bool S::f() [with const char* S = ((const
char*)(& S::a))]’:
v.c:13:26:   required from here
v.c:8:32: error: ‘(((const char*)(& S::a)) == ((const char*)(& S::b)))’ is not
a constant expression
 constexpr bool isb = S == b;
  ~~^~~~
v.c: In instantiation of ‘static bool S::f() [with const char* S = ((const
char*)(& S::b))]’:
v.c:14:26:   required from here
v.c:7:32: error: ‘(((const char*)(& S::b)) == ((const char*)(& S::a)))’ is not
a constant expression
 constexpr bool isa = S == a;
  ~~^~~~

[Bug fortran/70231] New: Runtime error: Different CHARACTER lengths in array constructor with allocatable array and -O0

[vladimir.fuka at gmail dot com]

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

Bug ID: 70231
   Summary: Runtime error: Different CHARACTER lengths in array
constructor with  allocatable array  and -O0
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.fuka at gmail dot com
  Target Milestone: ---

integer, parameter :: char_len = 32
character(char_len), allocatable :: ch_array(:)
character(char_len) :: ch

allocate(ch_array(0))
ch = "a"
ch_array = [ch_array, ch]
print *,ch_array(1)
end

compiled with

gfortran -fcheck=all char_array.f90

causes runtime error

At line 7 of file char_array.f90
Fortran runtime error: Different CHARACTER lengths (32709/32) in array
constructor

Works with -O1 and higher.

[Bug target/70220] [x86] interrupt attribute optionally needs to provide read, write and control the set of saved registers

[wink at saville dot com]

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

--- Comment #11 from Wink Saville  ---
(In reply to H.J. Lu from comment #10)
> (In reply to Wink Saville from comment #9)
> > (In reply to H.J. Lu from comment #8)
> > > (In reply to Wink Saville from comment #7)
> > > >
> > > > In my opinion, even if rbp is special, it still needs to be available 
> > > > in the
> > > > struct full_stack_frame.
> > > 
> > > The whole idea of extending interrupter attribute is to avoid
> > > full_stack_frame.
> > > ISR shouldn't assume that compiler will save and restore registers in any
> > > specific way, order or form.  As far as ISR is concerned, it is just black
> > > magic.
> > 
> > From my perspective the goal is not to avoid struct full_stack_frame but to
> > allow it to be created and always consistent.
> 
> Compiler is free to do whatever is the best.  You shouldn't assume anything
> from compiler beyond the interrupt attribute spec.  If you insist that
> compiler must save registers in certain way, interrupt attribute isn't
> appropriate for your use case.
> 
> > > 
> > > > Also, isn't rsp special? Would the compiler or programmer be 
> > > > responsible for
> > > > initializing it. It seems to me it has to be the compiler, but could be
> > > > wrong.
> > > 
> > > If you change rsp in asm statement, you have to restore it in asm 
> > > statement.
> > 
> > The rsp is always saved/restored by the hardware, and your struct frame
> > pointer provides access to it so no problem there. It is special because
> > when there are local variables the compiler needs to modify it and currently
> > it does that after the registers are saved. How will we coordinate the
> > compiler initializing rsp and the programming saving the registers?
> 
> Why is it a problem if IRS doesn't assume what/how compiler does?

I'm in total agreement, the programmer cannot assume anything and must rely on
what the interrupt attribute specification says.

At the moment the technique for saving the registers using mov's instead of
push/pop's looks to resolve a possible problem of the programmer manipulating
rsp. So the only problem seems to be how make rbp accessible because its
special. I suggest the interrupt attribute specification say something along
the lines of:

"The interrupt attribute takes optional parameters. The parameters are a list
of registers that the compiler will NOT save and it will be the responsibility
of the programmer to save them. As a convenience to the programmer a single
"all" parameter maybe used instead of a specific list. The only register not
allowed is RBP as its reserved for use by the compiler.

If there is a list of registers to not save then original value of rbp will be
saved to RAM and rbp will be set to its location."

Re: [PATCH] Fix LRA ICE (PR middle-end/70219)

[Jeff Law]

On 03/14/2016 03:32 PM, Jakub Jelinek wrote:

Hi!

The newly added assert in delete_move_and_clobber requires dregno > 0,
but dregno == 0 is also normal (e.g. in the testcase below we get dregno ==
0, because it uses %rax).  Only dregno < 0 is special and we shouldn't see
it here.

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

2016-03-14  Jakub Jelinek  

PR middle-end/70219
* lra-constraints.c (delete_move_and_clobber): Change assertion
to also allow dregno == 0.

* gcc.dg/pr70219.c: New test.

OK.

Jeff

[C++ PATCH] Fix -fsanitize=vptr (PR c++/70147)

[Jakub Jelinek]

Hi!

My recent patch for PR70035 broke -fsanitize=vptr, the early clearing
of _vptr.* pointers in the objects can crash in constructors with _vtt_parm
parameter.

This patch arranges to use in them *_vtt_parm instead the base vptr (which
we clear, instead of initialize).

The first testcase is just to make sure we don't crash, the second one
is an attempt to find out what is and what is not valid C++ and what can we
(easily) diagnose.

According to Jonathan, in the second testcase in B::B() all the calls
to g(), h() and i() methods before the E and F base classes are constructed
are invalid, while in the non-static data member mem initializers and
within body they are ok.  With the patch we diagnose all but the
g() call in F() base constructor argument (because the E() construction
initializes the vptr and we don't clear it once again afterwards).
clang doesn't instrument any of these, but they warn at compile time about
the g() call in E(g() + ...) and both h() calls (in E() and F()), but e.g.
doesn't warn about either of the calls to i().  At the point where they are
called, A() is already constructed, but other bases aren't constructed yet.
If we should instrument just what clang complains about at compile time,
we could e.g. in addition to this patch conditionalize the clearing of virtual
base vptr pointers by test on the __in_chrg argument, thus only clear those
in the comp ctor.

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

2016-03-14  Jakub Jelinek  

PR c++/70147
* cp-ubsan.c (cp_ubsan_maybe_initialize_vtbl_ptrs): Temporarily
set in_base_initializer.

* g++.dg/ubsan/pr70147-1.C: New test.
* g++.dg/ubsan/pr70147-2.C: New test.

--- gcc/cp/cp-ubsan.c.jj2016-03-04 23:09:53.0 +0100
+++ gcc/cp/cp-ubsan.c   2016-03-14 15:08:18.107919371 +0100
@@ -318,9 +318,15 @@ cp_ubsan_maybe_initialize_vtbl_ptrs (tre
 
   tree type = TREE_TYPE (TREE_TYPE (addr));
   tree list = build_tree_list (type, addr);
+  /* We cannot rely on the vtable being set up.  We have to indirect via the
+ vtt_parm.  */
+  int save_in_base_initializer = in_base_initializer;
+  in_base_initializer = 1;
 
   /* Walk through the hierarchy, initializing the vptr in each base
  class to NULL.  */
   dfs_walk_once (TYPE_BINFO (type), cp_ubsan_dfs_initialize_vtbl_ptrs,
 NULL, list);
+
+  in_base_initializer = save_in_base_initializer;
 }
--- gcc/testsuite/g++.dg/ubsan/pr70147-1.C.jj   2016-03-14 15:20:03.648332034 
+0100
+++ gcc/testsuite/g++.dg/ubsan/pr70147-1.C  2016-03-14 15:18:52.0 
+0100
@@ -0,0 +1,12 @@
+// PR c++/70147
+// { dg-do run }
+// { dg-options "-fsanitize=vptr" }
+
+struct A { A () {} virtual void f () {} };
+struct B : virtual A { B () {} virtual void f () {} };
+struct C : B, virtual A { C () {} } c;
+
+int
+main ()
+{
+}
--- gcc/testsuite/g++.dg/ubsan/pr70147-2.C.jj   2016-03-14 17:07:19.638824667 
+0100
+++ gcc/testsuite/g++.dg/ubsan/pr70147-2.C  2016-03-14 18:09:45.934170053 
+0100
@@ -0,0 +1,83 @@
+// PR c++/70147
+// { dg-do run }
+// { dg-skip-if "" { *-*-* }  { "*" } { "-O0" } }
+// { dg-options "-fsanitize=vptr" }
+
+struct A
+{
+  A () : a (0) {}
+  A (int x) : a (x) {}
+  virtual void f () {}
+  virtual int i () { int r = 0; __asm ("" : "+r" (r)); return r; }
+  int a;
+};
+struct E
+{
+  E () : e (0) {}
+  E (int x) : e (x) {}
+  virtual void f () {}
+  virtual int g () { int r = 0; __asm ("" : "+r" (r)); return r; }
+  int e;
+};
+struct F
+{
+  F () : f (0) {}
+  F (int x) : f (x) {}
+  virtual int h () { int r = 0; __asm ("" : "+r" (r)); return r; }
+  int f;
+};
+struct B : virtual A, public E, public F
+{
+  B ()
+: E (
+ g ()
+ + h ()
+ + i ()
+),
+  F (g ()
+ + h ()
+ + i ()),
+  b (g () + h () + i ())   // It is ok to call the methods here.
+  {
+b += g () + h () + i ();   // And here too.
+  }
+  virtual void f () {}
+  int b;
+};
+struct C : B, virtual A
+{
+  C () {}
+};
+
+int
+main ()
+{
+  C c;
+}
+
+// { dg-output "\[^\n\r]*pr70147-2.C:33:\[0-9]*: runtime error: member call on 
address 0x\[0-9a-fA-F]* which does not point to an object of type 
'E'(\n|\r\n|\r)" }
+// { dg-output "0x\[0-9a-fA-F]*: note: object has invalid vptr(\n|\r\n|\r)" }
+// { dg-output "  ?.. .. .. ..  ?.. .. .. ..  ?.. .. .. .. 
\[^\n\r]*(\n|\r\n|\r)" }
+// { dg-output "  ?\\^~~\[^\n\r]*(\n|\r\n|\r)" }
+// { dg-output "  ?invalid vptr(\n|\r\n|\r)" }
+// { dg-output "\[^\n\r]*pr70147-2.C:34:\[0-9]*: runtime error: member call on 
address 0x\[0-9a-fA-F]* which does not point to an object of type 
'F'(\n|\r\n|\r)" }
+// { dg-output "0x\[0-9a-fA-F]*: note: object has invalid vptr(\n|\r\n|\r)" }
+// { dg-output "  ?.. .. .. ..  ?.. .. .. ..  ?.. .. .. .. 
\[^\n\r]*(\n|\r\n|\r)" }
+// { dg-output "  ?\\^~~\[^\n\r]*(\n|\r\n|\r)" }
+// { dg-output "  ?invalid 

[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Richard Henderson  ---
Fixed.

[PATCH] Fix LRA ICE (PR middle-end/70219)

[Jakub Jelinek]

Hi!

The newly added assert in delete_move_and_clobber requires dregno > 0,
but dregno == 0 is also normal (e.g. in the testcase below we get dregno ==
0, because it uses %rax).  Only dregno < 0 is special and we shouldn't see
it here.

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

2016-03-14  Jakub Jelinek  

PR middle-end/70219
* lra-constraints.c (delete_move_and_clobber): Change assertion
to also allow dregno == 0.

* gcc.dg/pr70219.c: New test.

--- gcc/lra-constraints.c.jj2016-03-13 21:39:24.0 +0100
+++ gcc/lra-constraints.c   2016-03-14 09:16:39.849241403 +0100
@@ -5861,7 +5861,7 @@ delete_move_and_clobber (rtx_insn *insn,
   rtx_insn *prev_insn = PREV_INSN (insn);
 
   lra_set_insn_deleted (insn);
-  lra_assert (dregno > 0);
+  lra_assert (dregno >= 0);
   if (prev_insn != NULL && NONDEBUG_INSN_P (prev_insn)
   && GET_CODE (PATTERN (prev_insn)) == CLOBBER
   && dregno == get_regno (XEXP (PATTERN (prev_insn), 0)))
--- gcc/testsuite/gcc.dg/pr70219.c.jj   2016-03-14 09:15:48.887941755 +0100
+++ gcc/testsuite/gcc.dg/pr70219.c  2016-03-14 09:13:58.0 +0100
@@ -0,0 +1,18 @@
+/* PR middle-end/70219 */
+/* { dg-do compile { target int128 } } */
+/* { dg-options "-O1 -w -Wno-psabi" } */
+
+typedef int B __attribute__ ((vector_size (32)));
+typedef int D __attribute__ ((vector_size (32)));
+typedef long E __attribute__ ((vector_size (32)));
+typedef __int128 F;
+typedef __int128 G __attribute__ ((vector_size (32)));
+
+F
+foo (int a, unsigned b, F c, B d, G e, B f, D g, E h, G i)
+{
+  b /= c;
+  e /= (G) ~d;
+  h -= (E){ g[4], e[1], 64, ~f[1] };
+  return b + e[1] + h[0] + h[1] + i[1];
+}

Jakub

[Bug c++/70228] insufficient detail in diagnostics for a constexpr out of bounds array subscript

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00796.html

[Bug c++/60760] arithmetic on null pointers should not be allowed in constant expressions

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00796.html

[Bug c++/70172] incorrect reinterpret_cast from integer to pointer error on invalid constexpr initialization

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00796.html

[Bug c++/70170] [6 regression] bogus not a constant expression error comparing pointer to array to null

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|mpolacek at gcc dot gnu.org|msebor at gcc dot 
gnu.org

--- Comment #11 from Martin Sebor  ---
Marek, since I posted my patch for review I've reassigned this bug to myself:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00796.html

Re: C++ PATCH for range-for tweak

[Florian Weimer]

* Jason Merrill:

>   P08184R0: Generalizing the Range-Based For Loop

How can one resolve this reference?  It's obviously not a PR number in
GCC Bugzilla.

I found this after some searching:



But it lacks the additional “8”.

[Bug c++/67376] [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression

[msebor at gcc dot gnu.org]

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

--- Comment #16 from Martin Sebor  ---
Patch for the outstanding issues noted in comment #10 has been posted for
review:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00796.html

Re: [PATCH] 69517 - [5/6 regression] SEGV on a VLA with excess initializer elements

[Martin Sebor]

Ping:
  https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00441.html

On 03/06/2016 06:38 PM, Martin Sebor wrote:

GCC 4.9 had added support for C++ VLAs as specified in WG21
document N3639 expected to be included in C++ 14.  However,
WG21 ultimately decided not to include N3639 in C++ 14 and
the G++ support was partially removed in 5.1.  Unfortunately,
the removal rendered some safe albeit erroneous G++ 4.9 code
undefined.  This patch restores the well-defined behavior of
such code by having it throw an exception in response to
the erroneous conditions.

While testing the patch I found a number of other problems in
the G++ support for VLAs, including PR c++/70019 - VLA size
overflow not detected, which was never implemented (not even
in 4.9).  Since this is closely related to the regression
discussed in 69517 the patch also provides that support.

There are a few additional points to note about the patch:

1) It restores the std::bad_array_length exception from N3639,
even though the class isn't specified by the C++ standard.
At first I thought that introducing a different (private)
type would be more appropriate, but in the end couldn't come
up with a good argument for not keeping the same type.  Using
the same type also allows programs that rely on the exception
and that were built with GCC 4.9 to be ported to GCC 6 without
change.

2) It hardwires a rather arbitrarily restrictive limit of 64 KB
on the size of the biggest C++ VLA.  (This could stand to be
improved and made more intelligent, and perhaps integrated
with stack  checking via -fstack-limit, after the GCC 6
release.)

3) By throwing an exception for erroneous VLAs the patch largely
defeats the VLA Sanitizer.  The sanitizer is still useful in
C++ 98 mode where the N3639 VLA runtime checking is disabled,
and when exceptions are disabled via -fno-exceptions.
Disabling  the VLA checking in C++ 98 mode doesn't seem like
a useful feature, but I didn't feel like reverting what was
a deliberate decision.

Martin

[PATCH] c++/67376 Comparison with pointer to past-the-end, of array fails inside constant expression

[Martin Sebor]

The attached patch fixes the outstanding cases mentioned in comment
10 on bug c++/67376.  While testing the fix I uncovered a number of
other related problems without which the test would have been
incomplete.  They include:

PR c++/70170 - [6 regression] bogus not a constant expression error
comparing pointer to array to null
PR c++/70172 - incorrect reinterpret_cast from integer to pointer
error on invalid constexpr initialization
PR c++/60760 - arithmetic on null pointers should not be allowed
in constant expressions

In addition, I include a fix for the issue below that I also came
across while testing the patch and that makes root causing constexpr
problems due to out-of-bounds array subscripts easier:
PR c++/70228 - insufficient detail in diagnostics for a constexpr
out of bounds array subscript

In a discussion of bug 70170 between those CC'd Marek posted
a prototype patch for match.pd.  While the patch seems to do
the right thing as far as the bug goes, like my own first attempt
at a fix in const-fold.c it caused a couple of regressions (in
pr21294.c and in pr44555.c).  Since I'm not yet familiar enough
with match.pd, in the interest of time I solved those regressions
in const-fold.c rather than in match.pd.

Tested on x86_64.

Martin
PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end
	of array fails inside constant expression
PR c++/70170 - [6 regression] bogus not a constant expression error comparing
	pointer to array to null
PR c++/70172 - incorrect reinterpret_cast from integer to pointer error
	on invalid constexpr initialization
PR c++/60760 - arithmetic on null pointers should not be allowed in constant
	expressions
PR c++/70228 - insufficient detail in diagnostics for a constexpr out of bounds
	array subscript

gcc/testsuite/ChangeLog:
2016-03-14  Martin Sebor  

	PR c++/67376
	PR c++/70170
	PR c++/70172
	PR c++/60760
	PR c++/70228
	* g++.dg/cpp0x/constexpr-array-ptr10.C: New test.
	* g++.dg/cpp0x/constexpr-array-ptr11.C: New test.
	* g++.dg/cpp0x/constexpr-array-ptr9.C: New test.
	* g++.dg/cpp0x/constexpr-array5.C: Adjust text of expected diagnostic.
	* g++.dg/cpp0x/constexpr-string.C: Same.
	* g++.dg/cpp0x/constexpr-wstring2.C: Same.
	* g++.dg/cpp0x/pr65398.C: Same.
	* g++.dg/ext/constexpr-vla1.C: Same.
	* g++.dg/ext/constexpr-vla2.C: Same.
	* g++.dg/ext/constexpr-vla3.C: Same.
	* g++.dg/ubsan/pr63956.C: Same.

gcc/cp/ChangeLog:
2016-03-14  Martin Sebor  

	PR c++/67376
	PR c++/70170
	PR c++/70172
	PR c++/60760
	PR c++/70228
	(cxx_eval_binary_expression): Add argument.
	(cxx_eval_component_reference): Same.
	(cxx_eval_constant_expression): Same.
	(cxx_eval_indirect_ref): Same.
	(cxx_eval_outermost_constant_expr): Same.
	(diag_array_subscript): New function.
	* constexpr.c (cxx_eval_call_expression): Adjust.
	(cxx_eval_conditional_expression): Same.
	(cxx_eval_array_reference): Detect null pointers.
	(cxx_eval_statement_list): Adjust.

gcc/ChangeLog:
2016-03-14  Martin Sebor  

	PR c++/67376
	* fold-const.c (fold_comparison): Fold equality and relational
	expressions involving null pointers.

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 5f97c9d..5ec5034 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -918,7 +918,8 @@ struct constexpr_ctx {
 static GTY (()) hash_table *constexpr_call_table;
 
 static tree cxx_eval_constant_expression (const constexpr_ctx *, tree,
-	  bool, bool *, bool *, tree * = NULL);
+	  bool, bool *, bool *, bool * = NULL,
+  tree * = NULL);
 
 /* Compute a hash value for a constexpr call representation.  */
 
@@ -1390,7 +1391,7 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree t,
 	  tree jump_target = NULL_TREE;
 	  cxx_eval_constant_expression (ctx, body,
 	lval, non_constant_p, overflow_p,
-	_target);
+NULL, _target);
 
 	  if (DECL_CONSTRUCTOR_P (fun))
 	/* This can be null for a subobject constructor call, in
@@ -1607,20 +1608,21 @@ cxx_eval_unary_expression (const constexpr_ctx *ctx, tree t,
 static tree
 cxx_eval_binary_expression (const constexpr_ctx *ctx, tree t,
 			bool /*lval*/,
-			bool *non_constant_p, bool *overflow_p)
+			bool *non_constant_p, bool *overflow_p,
+bool *nullptr_p)
 {
   tree r = NULL_TREE;
   tree orig_lhs = TREE_OPERAND (t, 0);
   tree orig_rhs = TREE_OPERAND (t, 1);
   tree lhs, rhs;
   lhs = cxx_eval_constant_expression (ctx, orig_lhs, /*lval*/false,
-  non_constant_p, overflow_p);
+  non_constant_p, overflow_p, nullptr_p);
   /* Don't VERIFY_CONSTANT here, it's unnecessary and will break pointer
  subtraction.  */
   if (*non_constant_p)
 return t;
   rhs = cxx_eval_constant_expression (ctx, orig_rhs, /*lval*/false,
-  non_constant_p, overflow_p);
+  non_constant_p, overflow_p, nullptr_p);
   if (*non_constant_p)
 return 

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

[glisse at gcc dot gnu.org]

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

--- Comment #14 from Marc Glisse  ---
Note that I don't think we ever got a proper bug report for GMP. Verified
instructions on how to reproduce the issue with just the latest version of GMP
(without having to download the sources of mpfr, mpc, isl, gcc, etc) would be
nice...

[Bug libgcc/66382] POWER8 Vector optimized implementation of __float128 (IEEE754 128-bit Binary Floating Point)

[dan.parrot at mail dot com]

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

--- Comment #3 from dan.parrot at mail dot com ---
I am trying to configure gcc so that instead of generating instructions 
that use the hardware floating point unit, it will generate instructions 
that utilize integer operations to emulate floating point operations.

The description of the bug by David Edelsohn on Bugzilla implies that 
such emulation is currently available and would be made more efficient 
if integer operations are replaced by vector operations. It is this 
replacement that I'm trying to effect.

However, I am still unable to get gcc to compile a very simple program 
when passed the -msoft-float option. Here is the program (test.c)

==
#include 
#include 
#include 

int
main()
{
 printf("\n No. of bytes in a long double is %d.\n", sizeof(long 
double));

 long double x = 5.55L;
 long double y = -5.56L;

 long double z = x + y;
 long double w = x - y;
 printf("\n Sum   : \n x = %Lf \n y = %Lf \n z = %Lf \n", x, y, z);
 printf("\n Diff. : \n x = %Lf \n y = %Lf \n w = %llf \n", x, y, w);

 return (int)(z + w);
}
===

Without the -msoft-float flag to gcc, it prints the expected result.

With the -msoft-float flag, linking fails.

My questions is this: Can you successfully compile the simple program 
above in any version of gcc? If yes, what is the output of "gcc -v"? If 
not, does it mean there is in fact no software emulation available?

Thanks.
Dan.

On 03/14/2016 03:43 PM, munroesj at us dot ibm.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66382
>
> --- Comment #2 from Steven Munroe  ---
> What is the issue? You want to configure __float128 without also configuring
> altivec/VMX/VSX?
>
> The PowerPC 64-bit ABI is defined to pass __float128 values in 128-bit vector
> registers and return _float128 values in VR2.
>
> How parameters are passed is independent of the computation.
>

[Bug regression/70230] New: 11 test regressions when building GCC 6 with --enable-default-ssp

[psturm at computervoice dot com]

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

Bug ID: 70230
   Summary: 11 test regressions when building GCC 6 with
--enable-default-ssp
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: psturm at computervoice dot com
  Target Milestone: ---

Created attachment 37963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37963=edit
gcc 6 testsuite summary --enable-default-ssp

I built GCC6 snapshot 20160313 after applying the patch for PR driver/70192:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00708.html

The test suite finished with no errors for gcc.

Next I rebuilt GCC6 using the exact same configuration but adding
--enable-default-ssp to the configure. I got 11 unexpected failures in
gcc:

FAIL: gcc.dg/stack-usage-1.c scan-file foo\\t(256|264)\\tstatic
FAIL: gcc.dg/superblock.c scan-rtl-dump-times sched2 "ADVANCING TO" 2
FAIL: gcc.target/i386/avx-vzeroupper-17.c scan-assembler-times avx_vzeroupper 1
FAIL: gcc.target/i386/pr67317-1.c scan-assembler-not addb
FAIL: gcc.target/i386/pr67317-1.c scan-assembler-not setn?c
FAIL: gcc.target/i386/pr67317-2.c scan-assembler-not addb
FAIL: gcc.target/i386/pr67317-2.c scan-assembler-not setn?c
FAIL: gcc.target/i386/pr67317-3.c scan-assembler-not addb
FAIL: gcc.target/i386/pr67317-4.c scan-assembler-not addb
FAIL: gcc.target/i386/shrink_wrap_1.c scan-rtl-dump pro_and_epilogue
"Performing shrink-wrapping"
FAIL: gcc.target/i386/sw-1.c scan-rtl-dump pro_and_epilogue "Performing
shrink-wrapping"

Test suite summary attached.

[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison

[rth at gcc dot gnu.org]

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

--- Comment #8 from Richard Henderson  ---
Author: rth
Date: Mon Mar 14 20:48:15 2016
New Revision: 234196

URL: https://gcc.gnu.org/viewcvs?rev=234196=gcc=rev
Log:
PR tree-opt/68714

  * tree-ssa-reassoc.c (ovce_extract_ops, optimize_vec_cond_expr): New.
  (can_reassociate_p): Allow ANY_INTEGRAL_TYPE_P.
  (reassociate_bb): Use optimize_vec_cond_expr; avoid
  optimize_range_tests, attempt_builtin_copysign and attempt_builtin_powi
  on vectors.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr68714.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

[bneumeier at gmail dot com]

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

--- Comment #13 from Brett Neumeier  ---
OK, then it would make sense to have a documentation fix for GCC that specifies
those exact versions for GMP, MPC, and MPFR as the versions that must be used,
rather than claiming -- inaccurately! -- "x.y.z or later".

[Bug libgcc/66382] POWER8 Vector optimized implementation of __float128 (IEEE754 128-bit Binary Floating Point)

[munroesj at us dot ibm.com]

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

--- Comment #2 from Steven Munroe  ---
What is the issue? You want to configure __float128 without also configuring
altivec/VMX/VSX?

The PowerPC 64-bit ABI is defined to pass __float128 values in 128-bit vector
registers and return _float128 values in VR2.

How parameters are passed is independent of the computation.

[Bug c++/70229] error: constexpr constructor does not have empty body

[pangbw at gmail dot com]

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

--- Comment #1 from baoshan  ---
The error is triggered by the typedef clause, but it is valid according
standard C++11
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf:

...
— either its function-body shall be = default, or the compound-statement of its
function-body shall
contain only
— null statements,
— static_assert-declarations
— typedef declarations and alias-declarations that do not define classes or
enumerations,
...

[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typ

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
(In reply to Ian Lance Taylor from comment #7)
> For the record, I've fixed these cases in
> github.com/ianlancetaylor/demangle.  Looking at the patch there should show
> how to fix it elsewhere.
> 
> https://github.com/ianlancetaylor/demangle/commit/
> 33b3934fafc5026e0b38854a7976b91ad0014a02

Thanks. So are you saying that gcc's mangling
_ZN5folly12addBenchmarkIUliE_EENSt9enable_ifIXeqsrN5boost14function_types14function_arityIDTadsrT_clEEE5valueLi2EEvE4typeEPKcSC_OS6_
instead of
_ZN5folly12addBenchmarkIUliE_EENSt9enable_ifIXeqsrN5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typeEPKcSC_OS6_
may be a wrong code bug?

[Bug c++/70229] New: error: constexpr constructor does not have empty body

[pangbw at gmail dot com]

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

Bug ID: 70229
   Summary: error: constexpr constructor does not have empty body
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pangbw at gmail dot com
  Target Milestone: ---

$ cat x.cpp
#define _CONST_FUN constexpr

template
class duration
{ // represents a time duration 
public:
  typedef duration<_Rep, _Period> _Myt;
  typedef _Rep rep;
  typedef _Period period;

  template
  _CONST_FUN duration(int xx)
  { // construct from a duration
typedef int test;

static_assert(0 == 0,
  "period not an instance of std::ratio");
  }
};

$ ./xgcc -c -std=c++11 x.cpp -B.
x.cpp: In constructor ‘duration<_Rep, _Period>::duration(int)’: 
x.cpp:21:3: error: constexpr constructor does not have empty body  
}  
  |
   ^

$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++
Thread model: posix
gcc version 6.0.0 20160314 (experimental) (GCC)

[Bug c++/70228] insufficient detail in diagnostics for a constexpr out of bounds array subscript

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-03-14
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.0

--- Comment #1 from Martin Sebor  ---
I have a simple fix for this.

[Bug c++/70228] New: insufficient detail in diagnostics for a constexpr out of bounds array subscript

[msebor at gcc dot gnu.org]

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

Bug ID: 70228
   Summary: insufficient detail in diagnostics for a constexpr out
of bounds array subscript
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Diagnostics issued for out of bounds array references in non-trivial constexpr
don't provide sufficient detail to quickly root cause the problem.  For
example, the diagnostic printed for the program below makes determining the
value that exceeded the bounds of the array and what those bounds are more
difficult than it should be.  Since the index value and the bounds are known at
translation time, they both should be mentioned in the text of the diagnostic.

$ cat v.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -o/dev/null
-xc++ v.c
constexpr int a[] = { 1, 2, 3 };

constexpr int f (int i)
{
int j = i + 1;
return a[j];
}

constexpr int g (int i)
{
int j = i + 1;
return f (j);
}

constexpr int i = g (0);
constexpr int x = g (i);
v.c:16:21:   in constexpr expansion of ‘g(3)’
v.c:12:14:   in constexpr expansion of ‘f(j)’
v.c:16:23: error: array subscript out of bound
 constexpr int x = g (i);
   ^

For an example of what a more helpful diagnostic might look like consider the
output printed by Clang for the same program:

v.c:16:15: error: constexpr variable 'x' must be initialized by a constant
  expression
constexpr int x = g (i);
  ^   ~
v.c:6:12: note: cannot refer to element 5 of array of 3 elements in a constant
  expression
return a[j];
   ^
v.c:12:12: note: in call to 'f(4)'
return f (j);
   ^
v.c:16:19: note: in call to 'g(3)'
constexpr int x = g (i);
  ^
1 error generated.

[PATCH, testsuite] Fix ifcvt-4.c for PowerPC

[Pat Haugen]

As stated in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68232, this 
test needs -misel on powerpc to pass. Verified the following fixes the 
test on both powerpc64/powerpc64le. Ok for trunk?


-Pat

testsuite/ChangeLog:
2016-03-14  Pat Haugen  

* gcc.dg/ifcvt-4.c: Add -misel for powerpc* and remove skip for 
powerpc64le.



Index: testsuite/gcc.dg/ifcvt-4.c
===
--- testsuite/gcc.dg/ifcvt-4.c  (revision 234189)
+++ testsuite/gcc.dg/ifcvt-4.c  (working copy)
@@ -1,5 +1,6 @@
 /* { dg-options "-fdump-rtl-ce1 -O2 --param 
max-rtl-if-conversion-insns=3" } */
-/* { dg-skip-if "Multiple set if-conversion not guaranteed on all 
subtargets" { "arm*-*-* powerpc64le*-*-* visium-*-*" } {"*"} { "" } }  */

+/* { dg-additional-options "-misel" { target { powerpc*-*-* } } } */
+/* { dg-skip-if "Multiple set if-conversion not guaranteed on all 
subtargets" { "arm*-*-* visium-*-*" } {"*"} { "" } }  */


 int
 foo (int x, int y, int a)

Re: [PATCH] Fix PR56365

[Richard Biener]

On March 14, 2016 7:25:31 PM GMT+01:00, Bernhard Reutner-Fischer 
 wrote:
>On March 14, 2016 12:58:20 PM GMT+01:00, Richard Biener
> wrote:
>>
>>I am testing the following patch to fix the regression in min/max
>>detection introduced by comparison canonicalization like a < 267
>>to a <= 266.  The patch allows us to identify all four min/max
>>cases in the testcase below.
>>
>>Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
>>InLikew/testsuite/gcc.dg/tree-ssa/phi-opt-14.c
>>===
>>*** gcc/testsuite/gcc.dg/tree-ssa/phi-opt-14.c(revision 0)
>>--- gcc/testsuite/gcc.dg/tree-ssa/phi-opt-14.c(working copy)
>>***
>>*** 0 
>>--- 1,37 
>>+ /* { dg-do compile } */
>>+ /* { dg-options "-O -fdump-tree-phiopt1" } */
>>+ 
>>+ int test_01 (int a)
>>+ {
>>+   if (127 <= a)
>
>Shouldn't this be >= ?

No, note how the constant is left of the <=.

Richard.

>>+ a = 127;
>>+   else if (a <= -128)
>>+ a = -128;
>>+   return a;
>>+ }
>>+ int test_02 (int a)
>>+ {
>>+   if (127 < a)
>
>and this >
>
>>+ a = 127;
>>+   else if (a <= -128)
>>+ a = -128;
>>+   return a;
>>+ }
>>+ int test_03 (int a)
>>+ {
>>+   if (127 <= a)
>
>and this >=
>
>>+ a = 127;
>>+   else if (a < -128)
>>+ a = -128;
>>+   return a;
>>+ }
>>+ int test_04 (int a)
>>+ {
>>+   if (127 < a)
>
>and >
>
>TIA,
>>+ a = 127;
>>+   else if (a < -128)
>>+ a = -128;
>>+   return a;
>>+ }
>>+ 
>>+ /* { dg-final { scan-tree-dump-not "if" "phiopt1" } } */

[Bug target/70179] PPC64 ICE with -mabi=ieeelongdouble and long double complex

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Target|powerpc64*  |powerpc64*-linux
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-14
 CC||dje at gcc dot gnu.org,
   ||meissner at gcc dot gnu.org,
   ||seurer at linux dot 
vnet.ibm.com,
   ||wschmidt at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

[Bug target/70131] PowerPC ISA 2.07 is inefficient at doint (float)(int)x.

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Michael Meissner  ---
Fixed in the trunk on svn id 234155, gcc-5-branch on svn id 234186.

Re: [PATCH] genrecog: Fix crash on invalid input

[Segher Boessenkool]

On Mon, Mar 14, 2016 at 01:41:38PM -0500, Segher Boessenkool wrote:
> On Mon, Mar 14, 2016 at 06:39:12PM +0100, Bernd Schmidt wrote:
> > On 03/14/2016 04:38 PM, Segher Boessenkool wrote:
> > >If your machine description refers to a non-existent predicate genrecog
> > >crashes.  This fixes it.
> > 
> > Might be better to fix the caller?
> 
> Yeah maybe.  The next function that takes a pred also tests for !pred,
> but let me see what the caller of the failing case is.

There is just the single caller, and pred is set right before the call
there.  How about this patch, then?


Segher


Subject: [PATCH] genrecog: Fix crash on invalid input

If your machine description refers to a non-existent predicate genrecog
crashes.  This fixes it.


2016-03-14  Segher Boeesenkool  

* genrecog.c (match_pattern_2): If pred is NULL don't call
safe_predicate_mode on it.

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

diff --git a/gcc/genrecog.c b/gcc/genrecog.c
index f8b8ef4..47e4266 100644
--- a/gcc/genrecog.c
+++ b/gcc/genrecog.c
@@ -4037,7 +4037,7 @@ match_pattern_2 (state *s, md_rtx_info *info, position 
*pos, rtx pattern)
/* Check the mode first, to distinguish things like SImode
   and DImode register_operands, as described above.  */
machine_mode mode = GET_MODE (e->pattern);
-   if (safe_predicate_mode (pred, mode))
+   if (pred && safe_predicate_mode (pred, mode))
  s = add_decision (s, rtx_test::mode (e->pos), mode, true);
 
/* Assign to operands[] first, so that the rtx usually doesn't
-- 
1.9.3

[Bug sanitizer/70147] [6 Regression] testcase from hana testsuite gets miscompiled with -fsanitize=undefined

[bernd.edlinger at hotmail dot de]

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

--- Comment #12 from Bernd Edlinger  ---
I think it is normal, that A's vptr is initialized first to
an A which means that f points to A::f and i points to A::i.
these overloads are usable while A's constructor runs.
The vptr is later changed to the overloads that B defines,
so f points to B::f, while B's constructor runs and finally
f points to C::f while and after C's constructor finished.

I think we should not erase A's vptr again to zero after
A's constructor has run, A is now fully constructed.
All that changes is, if f points to A::f, or B::f, or C::f.
That is why the vptr is repeatedly written.

So I still think that my patch would do the right thing,
even when I try the new test cases.

C++ PATCH for range-for tweak

[Jason Merrill]

A proposal accepted at the last meeting allows the deduced iterator and 
end variables in range-based for to have different types, as long as 
they can be compared.  This is a very simple change, limited to C++1z 
mode, and desired by some of the heaviest users of concepts, so I'm 
going to go ahead and make it.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 196599301ea3a46cda7eb633623b0dfd2079bc45
Author: Jason Merrill 
Date:   Sat Mar 5 07:45:02 2016 -0500

	P08184R0: Generalizing the Range-Based For Loop

	* parser.c (cp_convert_range_for): Set the type of __end separately.
	(cp_parser_perform_range_for_lookup): Allow different begin/end
	types if they are comparable.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 6ae45b0..d38f1dd 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -11353,6 +11353,8 @@ cp_convert_range_for (tree statement, tree range_decl, tree range_expr,
 		  /*is_constant_init*/false, NULL_TREE,
 		  LOOKUP_ONLYCONVERTING);
 
+  if (cxx_dialect >= cxx1z)
+iter_type = cv_unqualified (TREE_TYPE (end_expr));
   end = build_decl (input_location, VAR_DECL,
 		get_identifier ("__for_end"), iter_type);
   TREE_USED (end) = 1;
@@ -11488,9 +11490,21 @@ cp_parser_perform_range_for_lookup (tree range, tree *begin, tree *end)
 	  /* The unqualified type of the __begin and __end temporaries should
 	 be the same, as required by the multiple auto declaration.  */
 	  if (!same_type_p (iter_type, cv_unqualified (TREE_TYPE (*end
-	error ("inconsistent begin/end types in range-based % "
-		   "statement: %qT and %qT",
-		   TREE_TYPE (*begin), TREE_TYPE (*end));
+	{
+	  if (cxx_dialect >= cxx1z
+		  && (build_x_binary_op (input_location, NE_EXPR,
+	 *begin, ERROR_MARK,
+	 *end, ERROR_MARK,
+	 NULL, tf_none)
+		  != error_mark_node))
+		/* P08184R0 allows __begin and __end to have different types,
+		   but make sure they are comparable so we can give a better
+		   diagnostic.  */;
+	  else
+		error ("inconsistent begin/end types in range-based % "
+		   "statement: %qT and %qT",
+		   TREE_TYPE (*begin), TREE_TYPE (*end));
+	}
 	  return iter_type;
 	}
 }
diff --git a/gcc/testsuite/g++.dg/cpp0x/range-for5.C b/gcc/testsuite/g++.dg/cpp0x/range-for5.C
index bf04406..2a20db4 100644
--- a/gcc/testsuite/g++.dg/cpp0x/range-for5.C
+++ b/gcc/testsuite/g++.dg/cpp0x/range-for5.C
@@ -31,7 +31,7 @@ struct Explicit
 void test1()
 {
   container c;
-  for (int x : c) // { dg-error "inconsistent|conversion" }
+  for (int x : c) // { dg-error "inconsistent|conversion|comparison" }
 ;
 
   int a[2] = {1,2};
diff --git a/gcc/testsuite/g++.dg/cpp1z/range-for1.C b/gcc/testsuite/g++.dg/cpp1z/range-for1.C
new file mode 100644
index 000..370381a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/range-for1.C
@@ -0,0 +1,23 @@
+// P08184R0: Generalizing the Range-Based For Loop
+// { dg-options "-std=c++1z" }
+
+struct A {
+  int ar[4];
+  int *begin() { return ar; }
+  struct end_t {
+int *p;
+friend bool operator!= (int *p, end_t e) { return p != e.p; }
+  };
+  end_t end() { return { [4] }; }
+};
+
+int main()
+{
+  A a { 1, 2, 3, 4 };
+  int i = 1;
+  for (auto x: a)
+if (x != i++)
+  __builtin_abort ();
+  if (i != 5)
+__builtin_abort ();
+}

[Bug target/70220] [x86] interrupt attribute optionally needs to provide read, write and control the set of saved registers

[hjl.tools at gmail dot com]

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

--- Comment #10 from H.J. Lu  ---
(In reply to Wink Saville from comment #9)
> (In reply to H.J. Lu from comment #8)
> > (In reply to Wink Saville from comment #7)
> > >
> > > In my opinion, even if rbp is special, it still needs to be available in 
> > > the
> > > struct full_stack_frame.
> > 
> > The whole idea of extending interrupter attribute is to avoid
> > full_stack_frame.
> > ISR shouldn't assume that compiler will save and restore registers in any
> > specific way, order or form.  As far as ISR is concerned, it is just black
> > magic.
> 
> From my perspective the goal is not to avoid struct full_stack_frame but to
> allow it to be created and always consistent.

Compiler is free to do whatever is the best.  You shouldn't assume anything
from compiler beyond the interrupt attribute spec.  If you insist that
compiler must save registers in certain way, interrupt attribute isn't
appropriate for your use case.

> > 
> > > Also, isn't rsp special? Would the compiler or programmer be responsible 
> > > for
> > > initializing it. It seems to me it has to be the compiler, but could be
> > > wrong.
> > 
> > If you change rsp in asm statement, you have to restore it in asm statement.
> 
> The rsp is always saved/restored by the hardware, and your struct frame
> pointer provides access to it so no problem there. It is special because
> when there are local variables the compiler needs to modify it and currently
> it does that after the registers are saved. How will we coordinate the
> compiler initializing rsp and the programming saving the registers?

Why is it a problem if IRS doesn't assume what/how compiler does?

[Bug c++/70182] c++filt fails to demangle _ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBenchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_types14function_arityIDTadsrT_onclEEE5valueLi2EEvE4typ

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #7 from Ian Lance Taylor  ---
For the record, I've fixed these cases in github.com/ianlancetaylor/demangle. 
Looking at the patch there should show how to fix it elsewhere.

https://github.com/ianlancetaylor/demangle/commit/33b3934fafc5026e0b38854a7976b91ad0014a02

Re: [AArch64] Emit square root using the Newton series

[Wilco Dijkstra]

Evandro Menezes  wrote:
>
> I got the scalar version going, but I'm stuck with the vector version.
> As you can see above, I need to use the complement of the mask produced
> by FCMEQ to squelch the offending vector element. However, the way in
> which FCMEQ is defined in GCC, it produces an integer vector and the
> SIMD AND only takes integer vectors.  I'm stuck at how to pass an FP
> vector to AND and then its integer vector back to an FP insn.

You can use gen_rtx_SUBREG(mcmp, xsqrt, 0) to change the mode to an 
integer vector on the AND instruction and back to mode for the destination.

Wilco

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

[bernd.edlinger at hotmail dot de]

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

--- Comment #12 from Bernd Edlinger  ---
It is on purpose that the in-tree gmp is configured to use no assembly,
but the in-tree configuration does not really work with gmp-6.1.0,
and apparently disables the assembly only half-way.  It is not possible
to fix that without breaking compatibility to gmp-4.3.2 at the same time.

I fully agree that it is time to move to a new gmp version for gcc-7,
but if we do so we will also require a specific mpfr and mpc version
too.  And from the experience in the past, I would bet that you
will not be able to simply use any future gmp version,
without very careful testing, and updating mpfr and mpc to compatible
versions at the same time.

As a matter of fact, even when not building in-tree, there are often
incompatibilities:

For instance mpfr-2.4.2/INSTALL says:
0. You first need to install GMP. See .
   MPFR requires GMP version 4.1 or later.

And gmp-6.1.0/INSTALL does not mention MPFR at all.
But building mpfr-2.4.2 with gmp-6.1.0 fails.

For instance mpc-0.8.1/INSTALL says:
0. You first need to install GMP and MPFR. See 
   and .
   MPC requires GMP version 4.2 or later and MPFR version 2.3.1 or later.

And again mpfr-3.1.3/INSTALL does not mention MPC at all.
But building mpc-0.8.1 with gmp-6.1.0 and mpfr-3.1.3 fails.

So it is simply impossible to give any guarantees of that kind.
All we can do is update to a specific gmp/mpfr/mpc version,
and guarantee that exactly that combination will actually work.

[Bug c++/70194] [6 regression] missing -Waddress on constexpr pointer

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
This patch fixes the missing warning:

--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -4520,14 +4520,16 @@ cp_build_binary_op (location_t location,
  else
result_type = type0;

- if (TREE_CODE (op0) == ADDR_EXPR
- && decl_with_nonnull_addr_p (TREE_OPERAND (op0, 0)))
+ tree cop0 = fold_non_dependent_expr (op0);
+
+ if (TREE_CODE (cop0) == ADDR_EXPR
+ && decl_with_nonnull_addr_p (TREE_OPERAND (cop0, 0)))
{
  if ((complain & tf_warning)
  && c_inhibit_evaluation_warnings == 0
- && !TREE_NO_WARNING (op0))
+ && !TREE_NO_WARNING (cop0))
warning (OPT_Waddress, "the address of %qD will never be NULL",
-TREE_OPERAND (op0, 0));
+TREE_OPERAND (cop0, 0));
}

  if (CONVERT_EXPR_P (op0)
@@ -4559,14 +4561,16 @@ cp_build_binary_op (location_t location,
  else
result_type = type1;

- if (TREE_CODE (op1) == ADDR_EXPR 
- && decl_with_nonnull_addr_p (TREE_OPERAND (op1, 0)))
+ tree cop1 = fold_non_dependent_expr (op1);
+
+ if (TREE_CODE (cop1) == ADDR_EXPR
+ && decl_with_nonnull_addr_p (TREE_OPERAND (cop1, 0)))
{
  if ((complain & tf_warning)
  && c_inhibit_evaluation_warnings == 0
- && !TREE_NO_WARNING (op1))
+ && !TREE_NO_WARNING (cop1))
warning (OPT_Waddress, "the address of %qD will never be NULL",
-TREE_OPERAND (op1, 0));
+TREE_OPERAND (cop1, 0));
}

  if (CONVERT_EXPR_P (op1)

Re: [PATCH] PR69195, Reload confused by invalid reg equivs

[Jeff Law]

On 03/14/2016 03:56 AM, Richard Biener wrote:


Undefined?  Most likely.  But we still have to do something sensible. As
Jakub noted, a user could create the problematic code just as easily as
DCE/DSE, so IRA probably needs to be tolerant of this situation.

So it seems like you're suggesting we leave DCE/DSE alone (declaring this
usage undefined) and fix IRA to be tolerant, right?


Tolerant as in not crash?  Yes.

Right.  Tolerant as in not crash.




Using alloca to create/jump to code on the stack should work (we might
transform that into a decl though).


Given that executable stacks are a huge security hole, I'd be willing to go
out on a limb and declare that undefined as well.  It's not as clear cut,
but that's the argument I'd make.


Well, I thought about somebody trying to build trampolines in a way exposed
to GCC.

Right or other dynamic, short-lived code fragments.




And yes, I realize that goes in opposition to what GCC has allowed for 20+
years.  I still think it'd be the right thing to do.


Did we allow this?  Not by design but rather by accident I suppose.
I don't think it was ever specifically allowed or disallowed; like many 
of the old extensions, it was never crisply defined.


I can distinctly remember having to declare that taking the address of a 
blob of code on the stack, then calling/jumping to it after the 
containing function went out of scope as undefined.  I think it was the 
address of a trampoline, but I'm not entirely sure -- there's a small 
chance it was user-created code.  I only remember it because I was 
surprised at how controversial it was to declare that as undefined :(


That most likely predates egcs, so the discussion is not likely in the 
public archives.  It may have been a private discussion between Kenner, 
Jim, Doug and myself or some subset thereof.



jeff

[Bug c++/68722] [4.9/5/6 Regression] internal compiler error: in merge_exception_specifiers, at cp/typeck2.c:2108

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
I wonder if in such cases, where we run out of tokens and we issue:

   error_at (token->location, "file ends in default argument");

from cp_parser_cache_defarg we should instead use something like a fatal_error
and stop the meaningless chain of redundant errors. Certainly that avoids the
error recovery ICE at issue and passes testing...

[Bug fortran/69423] [6 Regression] Invalid optimization with deferred-length character

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Paul Thomas  ---
Fixed on trunk and 5-branch

Thanks for the report

Paul

[Bug fortran/68241] [meta-bug] Deferred-length character

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 69423, which changed state.

Bug 69423 Summary: [6 Regression] Invalid optimization with deferred-length 
character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69423

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

Re: [PATCH] genrecog: Fix crash on invalid input

[Segher Boessenkool]

On Mon, Mar 14, 2016 at 06:39:12PM +0100, Bernd Schmidt wrote:
> On 03/14/2016 04:38 PM, Segher Boessenkool wrote:
> >If your machine description refers to a non-existent predicate genrecog
> >crashes.  This fixes it.
> 
> Might be better to fix the caller?

Yeah maybe.  The next function that takes a pred also tests for !pred,
but let me see what the caller of the failing case is.


Segher

[PATCH] extend.texi: Expand on the perils of using the 'leaf' attribute.

[Carlos O'Donell]

Using the 'leaf' attribute is difficult in certain use cases, and the
documentation rightly points out that signals is one such problem.

We should additionally document the following caveats:

* Indirect function resolvers (thanks to Florian Weimer for catching this).
* Indirect function implementations
* ELF symbol interposition.

Note that neither the C nor C++ standards talks at all about how
memory is synchronized between the current execution context and that
of a signal handler. Therefore this patch rewords the text to say
"There is no standards compliant way..." although in practice is just
works and one would expect the standards (POSIX) to adopt such language
that existing practice works.

Lastly, we mention that the 'leaf' attribute might simply be removed
if that is the easiest option.

OK to checkin?

For completeness the motivating example from a user was like this:
cat >> leaf.c <
#include 
#include 
#include 

static int tst;

void my_h(int sig)
{
  if (tst == 1)
_exit (0);
  _exit (1);
}

int main()
{
  signal(SIGUSR1, my_h);
  tst++;
  pthread_kill(pthread_self(), SIGUSR1);
  tst--;
  return 2;
}
EOF
gcc -g3 -O3 -o leaf leaf.c -lpthread
./test; echo $?
1

Where the global write of tst is elided by the compiler because
pthread_kill is marked __THROW (includes leaf). It's an open
question if pthread_kill should or should not use __THROWNL.
Even if we fix that in glibc, the changes below to the docs are
still important clarifications.

gcc/
2016-03-14  Carlos O'Donell  

* doc/extend.texi (Common Function Attributes): Describe ifunc impact
on leaf attribute.

Index: extend.texi
===
--- extend.texi (revision 234183)
+++ extend.texi (working copy)
@@ -2786,9 +2786,17 @@
 is a leaf function, but @code{qsort} is not.
 
 Note that leaf functions might invoke signals and signal handlers might be
-defined in the current compilation unit and use static variables.  The only
-compliant way to write such a signal handler is to declare such variables
-@code{volatile}.
+defined in the current compilation unit and use static variables.  Similarly,
+when lazy symbol resolution is in effect, leaf functions might invoke indirect
+functions whose resolver function or implementation function might be defined
+in the current compilation unit and use static variables. There is no standards
+compliant way to write such a signal handler, resolver function, or
+implementation function, and the best that you can do is to remove the leaf
+attribute or mark all such variables @code{volatile}.  Lastly, for ELF-based
+systems which support symbol interposition one should take care that functions
+defined in the current compilation unit do not unexpectedly interpose other
+symbols based on the defined standards mode otherwise an inadvertent callback
+would be added.
 
 The attribute has no effect on functions defined within the current compilation
 unit.  This is to allow easy merging of multiple compilation units into one,
--
Cheers,
Carlos.

Re: [PATCH][PR rtl-optimization/69307] Handle hard registers in modes that span more than one register properly

[Jeff Law]

On 03/14/2016 03:56 AM, Andrey Belevantsev wrote:


Thank you for checking this in.  I've also tested this patch in the
similar way (forcing selective scheduling for 2nd and both schedulers)
both on x86-64 and ia64.  I've posted the patches for remaining
sel-sched PRs just now -- it took some time bringing our Itaniums back
to life.
No problem.  I found it trolling the P4/P5 regression list.  It was the 
only one that I could wrap my head around easily that night.


Thanks for following-up on the others.  Hopefully between Alexander, 
Bernd and myself we can get them reviewed and work towards getting those 
BZs resolved.


jeff

Re: [gimplefe] [gsoc16] Gimple Front End Project

[Michael Matz]

Hi,

On Thu, 10 Mar 2016, Richard Biener wrote:

> Then I'd like to be able to re-construct SSA without jumping through 
> hoops (usually you can get close but if you require copies propagated in 
> a special way you are basically lost for example).
> 
> Thus my proposal to make the GSoC student attack the unit-testing 
> problem by doing modifications to the pass manager and "extending" an 
> existing frontend (C for simplicity).

I think it's wrong to try to shoehorn the gimple FE into the C FE.  C is 
fundamentally different from gimple and you'd have to sprinkle 
gimple_dialect_p() all over the place, and maintaining that while 
developing future C improvements will turn out to be much work.  Some 
differences of C and gimple:

* C has recursive expressions, gimple is n-op stmts, no expressions at all
* C has type promotions, gimple is explicit
* C has all other kinds of automatic conversion (e.g. pointer decay)
* C has scopes, gimple doesn't (well, global and local only), i.e. symbol 
  lookup is much more complicated
* C doesn't have exceptions
* C doesn't have class types, gimple has
* C doesn't have SSA (yes, I'm aware of your suggestions for that)
* C doesn't have self-referential types
* C FE generates GENERIC, not GIMPLE (so you'd need to go through the
  gimplifier and again would feed gimple directly into the passes)

I really don't think changing the C FE to accept gimple is a useful way 
forward.

I agree with others that the gimple FE is rather more similar to a textual 
form of LTO bytecode.  In difference to the byte code its syntax has to be 
defined and kept stable, and yes, it's sensible to get inspiration from C 
syntax.

> It's true that in the ideal world a "GIMPLE frontend" has to work 
> differently but then to get a 100% GIMPLE frontend you indeed arrive at 
> what LTO does and then I agree we should attack that from the LTO side 
> and not develop another thing besides it.  But this is a _much_ larger 
> task and I don't see anyone finishing that.

So, you think the advantage of starting with the C FE would be faster 
return on investment?  Even if it were true (and I'm not sure it is), what 
would it help if it ultimately wouldn't be acceptable for inclusion in GCC 
proper?

> Also keep in mind that the LTO side will likely simplify a lot by 
> stripping out the ability to stream things that are only required for 
> debug information (I hopefully will finish LTO early debug for GCC 7).

Btw. I'm not suggesting to fit the gimple FE into the LTO infrastructure, 
that's also leading to a mess IMO.  But I do think creating a gimple FE 
from scratch is easier than fitting it into the C FE.  Taking some 
infrastructure from the LTO frontend (namely all the tree/gimple building 
routines) and some from the C frontend (namely parts of the parsers, at 
least for types).

> So - can we please somehow focus on the original question about a GSoC 
> project around the "GIMPLE frontend"?  Of course you now can take Davids 
> promise of spending some development time on this into consideration.  
> Try drafting something that can be reasonably accomplished with giving 
> us something to actually use in the GCC 7 timeframe.

Okay, here's a rough plan:

1) take the LTO frontend, remove all bytecode 
   routines, partitioning stuff, lto symtab merging stuff, tree merging 
   stuff, WPA stuff; i.e. retain only the few pieces needed for creating 
   tree and those that every frontend needs to provide.  Now that 
   frontend should be able to generate an empty compilation unit.
2) implement two stub functions: parsetype and lookuptype, the first 
   always generates a type named 'int32' with the obvious INTEGER_TYPE 
   tree, the second always gives back that type.  Now hack on the frontend
   long enough that this simple input can be parsed and the obvious asm 
   file is generated: "int32 i;".  Then "int32 i = 0;".

   Now the frontend knows global decls and initializers, but the type
   parsing problem is deferred.
3) implement function parsing.  Hack on the frontend long enough
   that this program is accepted and generates the obvious gimple:
 int32 main(int32 argc) {
   int32 a;
   a_1 = argc_0;
   _2 = a_1 - argc_0;
   return _2;
 }
   While doing this, think about how to represent default defs, and 
   generally SSA names.
4) implement some more operators for one and two-op statements
5) implement syntax for conditional code, for instance:
 {
   L0: if (argc_0 == 1) goto L1; else goto L2;
   L1: $preds (L0)
   return 1;
   L2: $preds (L0)
   return 2;
 }
5) think about and implement syntax for PHI nodes, e.g.:
 {
   int a;
   L0: if (argc_0 == 1) goto L1; else goto L2;
   L1: $preds (L0)
   a_1 = 1;
   goto L3;
   L2: $preds (L0)
   a_2 = 42 + argc_0;
   goto L3;
   L3: $preds (L1, L2)
   a_3 = $phi (a_1, a_2);
   return a_3;
 }

   See for instance how 

[Bug target/70123] [5 Regression] Miscompilation of cfitsio testcase on s390x-linux starting with r222144

[bernds at gcc dot gnu.org]

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

--- Comment #8 from Bernd Schmidt  ---
I'll take your comment as approval and install on gcc-5 as well.

Re: [PATCH] Fix PR56365

[Bernhard Reutner-Fischer]

On March 14, 2016 12:58:20 PM GMT+01:00, Richard Biener  
wrote:
>
>I am testing the following patch to fix the regression in min/max
>detection introduced by comparison canonicalization like a < 267
>to a <= 266.  The patch allows us to identify all four min/max
>cases in the testcase below.
>
>Bootstrap and regtest running on x86_64-unknown-linux-gnu.

>InLikew/testsuite/gcc.dg/tree-ssa/phi-opt-14.c
>===
>*** gcc/testsuite/gcc.dg/tree-ssa/phi-opt-14.c (revision 0)
>--- gcc/testsuite/gcc.dg/tree-ssa/phi-opt-14.c (working copy)
>***
>*** 0 
>--- 1,37 
>+ /* { dg-do compile } */
>+ /* { dg-options "-O -fdump-tree-phiopt1" } */
>+ 
>+ int test_01 (int a)
>+ {
>+   if (127 <= a)

Shouldn't this be >= ?

>+ a = 127;
>+   else if (a <= -128)
>+ a = -128;
>+   return a;
>+ }
>+ int test_02 (int a)
>+ {
>+   if (127 < a)

and this >

>+ a = 127;
>+   else if (a <= -128)
>+ a = -128;
>+   return a;
>+ }
>+ int test_03 (int a)
>+ {
>+   if (127 <= a)

and this >=

>+ a = 127;
>+   else if (a < -128)
>+ a = -128;
>+   return a;
>+ }
>+ int test_04 (int a)
>+ {
>+   if (127 < a)

and >

TIA,
>+ a = 127;
>+   else if (a < -128)
>+ a = -128;
>+   return a;
>+ }
>+ 
>+ /* { dg-final { scan-tree-dump-not "if" "phiopt1" } } */

[Bug target/70168] [5 Regression] Wrong code generation in __sync_val_compare_and_swap on PowerPC

[meissner at gcc dot gnu.org]

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

--- Comment #7 from Michael Meissner  ---
Author: meissner
Date: Mon Mar 14 18:18:45 2016
New Revision: 234188

URL: https://gcc.gnu.org/viewcvs?rev=234188=gcc=rev
Log:
[gcc]
2016-03-14  Michael Meissner  

Backport from mainline
2016-03-11  Michael Meissner  

PR target/70131
* config/rs6000/rs6000.md (round322_fprs): Do not do the
optimization if we have direct move.
(roundu322_fprs): Likewise.

2016-03-14  Rainer Orth  

Backport from mainline
2016-03-07  Rainer Orth  

PR target/62281
* config/i386/sol2.h (STACK_REALIGN_DEFAULT): Define.

2016-03-10  Ulrich Weigand  

PR target/70168
* config/rs6000/rs6000.c (rs6000_expand_atomic_compare_and_swap):
Handle overlapping retval and newval.

[gcc/testsuite]
2016-03-14  Michael Meissner  

Backport from mainline
2016-03-11  Michael Meissner  

PR target/70131
* gcc.target/powerpc/ppc-round2.c: New test.

2016-03-14  Dominique d'Humieres  

PR fortran/45076
gfortran.dg/prof/prof.exp: New script.
gfortran.dg/prof/dynamic_dispatch_6.f03: New test.


Added:
branches/ibm/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/ppc-round2.c
  - copied unchanged from r234186,
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/ppc-round2.c
branches/ibm/gcc-5-branch/gcc/testsuite/gfortran.dg/prof/
  - copied from r234186,
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/prof/
Modified:
branches/ibm/gcc-5-branch/gcc/ChangeLog
branches/ibm/gcc-5-branch/gcc/DATESTAMP
branches/ibm/gcc-5-branch/gcc/config/i386/sol2.h
branches/ibm/gcc-5-branch/gcc/config/rs6000/rs6000.c
branches/ibm/gcc-5-branch/gcc/config/rs6000/rs6000.md
branches/ibm/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/70131] PowerPC ISA 2.07 is inefficient at doint (float)(int)x.

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Mon Mar 14 18:18:45 2016
New Revision: 234188

URL: https://gcc.gnu.org/viewcvs?rev=234188=gcc=rev
Log:
[gcc]
2016-03-14  Michael Meissner  

Backport from mainline
2016-03-11  Michael Meissner  

PR target/70131
* config/rs6000/rs6000.md (round322_fprs): Do not do the
optimization if we have direct move.
(roundu322_fprs): Likewise.

2016-03-14  Rainer Orth  

Backport from mainline
2016-03-07  Rainer Orth  

PR target/62281
* config/i386/sol2.h (STACK_REALIGN_DEFAULT): Define.

2016-03-10  Ulrich Weigand  

PR target/70168
* config/rs6000/rs6000.c (rs6000_expand_atomic_compare_and_swap):
Handle overlapping retval and newval.

[gcc/testsuite]
2016-03-14  Michael Meissner  

Backport from mainline
2016-03-11  Michael Meissner  

PR target/70131
* gcc.target/powerpc/ppc-round2.c: New test.

2016-03-14  Dominique d'Humieres  

PR fortran/45076
gfortran.dg/prof/prof.exp: New script.
gfortran.dg/prof/dynamic_dispatch_6.f03: New test.


Added:
branches/ibm/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/ppc-round2.c
  - copied unchanged from r234186,
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/ppc-round2.c
branches/ibm/gcc-5-branch/gcc/testsuite/gfortran.dg/prof/
  - copied from r234186,
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/prof/
Modified:
branches/ibm/gcc-5-branch/gcc/ChangeLog
branches/ibm/gcc-5-branch/gcc/DATESTAMP
branches/ibm/gcc-5-branch/gcc/config/i386/sol2.h
branches/ibm/gcc-5-branch/gcc/config/rs6000/rs6000.c
branches/ibm/gcc-5-branch/gcc/config/rs6000/rs6000.md
branches/ibm/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/45076] [OOP] gfortran.dg/dynamic_dispatch_6.f03 ICEs with -fprofile-use

[meissner at gcc dot gnu.org]

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

--- Comment #12 from Michael Meissner  ---
Author: meissner
Date: Mon Mar 14 18:18:45 2016
New Revision: 234188

URL: https://gcc.gnu.org/viewcvs?rev=234188=gcc=rev
Log:
[gcc]
2016-03-14  Michael Meissner  

Backport from mainline
2016-03-11  Michael Meissner  

PR target/70131
* config/rs6000/rs6000.md (round322_fprs): Do not do the
optimization if we have direct move.
(roundu322_fprs): Likewise.

2016-03-14  Rainer Orth  

Backport from mainline
2016-03-07  Rainer Orth  

PR target/62281
* config/i386/sol2.h (STACK_REALIGN_DEFAULT): Define.

2016-03-10  Ulrich Weigand  

PR target/70168
* config/rs6000/rs6000.c (rs6000_expand_atomic_compare_and_swap):
Handle overlapping retval and newval.

[gcc/testsuite]
2016-03-14  Michael Meissner  

Backport from mainline
2016-03-11  Michael Meissner  

PR target/70131
* gcc.target/powerpc/ppc-round2.c: New test.

2016-03-14  Dominique d'Humieres  

PR fortran/45076
gfortran.dg/prof/prof.exp: New script.
gfortran.dg/prof/dynamic_dispatch_6.f03: New test.


Added:
branches/ibm/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/ppc-round2.c
  - copied unchanged from r234186,
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/ppc-round2.c
branches/ibm/gcc-5-branch/gcc/testsuite/gfortran.dg/prof/
  - copied from r234186,
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/prof/
Modified:
branches/ibm/gcc-5-branch/gcc/ChangeLog
branches/ibm/gcc-5-branch/gcc/DATESTAMP
branches/ibm/gcc-5-branch/gcc/config/i386/sol2.h
branches/ibm/gcc-5-branch/gcc/config/rs6000/rs6000.c
branches/ibm/gcc-5-branch/gcc/config/rs6000/rs6000.md
branches/ibm/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/62281] gcc doesn't conform to Solaris 32-bit ABI by expecting 16-byte stack alignment

[meissner at gcc dot gnu.org]

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

--- Comment #18 from Michael Meissner  ---
Author: meissner
Date: Mon Mar 14 18:18:45 2016
New Revision: 234188

URL: https://gcc.gnu.org/viewcvs?rev=234188=gcc=rev
Log:
[gcc]
2016-03-14  Michael Meissner  

Backport from mainline
2016-03-11  Michael Meissner  

PR target/70131
* config/rs6000/rs6000.md (round322_fprs): Do not do the
optimization if we have direct move.
(roundu322_fprs): Likewise.

2016-03-14  Rainer Orth  

Backport from mainline
2016-03-07  Rainer Orth  

PR target/62281
* config/i386/sol2.h (STACK_REALIGN_DEFAULT): Define.

2016-03-10  Ulrich Weigand  

PR target/70168
* config/rs6000/rs6000.c (rs6000_expand_atomic_compare_and_swap):
Handle overlapping retval and newval.

[gcc/testsuite]
2016-03-14  Michael Meissner  

Backport from mainline
2016-03-11  Michael Meissner  

PR target/70131
* gcc.target/powerpc/ppc-round2.c: New test.

2016-03-14  Dominique d'Humieres  

PR fortran/45076
gfortran.dg/prof/prof.exp: New script.
gfortran.dg/prof/dynamic_dispatch_6.f03: New test.


Added:
branches/ibm/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/ppc-round2.c
  - copied unchanged from r234186,
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/ppc-round2.c
branches/ibm/gcc-5-branch/gcc/testsuite/gfortran.dg/prof/
  - copied from r234186,
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/prof/
Modified:
branches/ibm/gcc-5-branch/gcc/ChangeLog
branches/ibm/gcc-5-branch/gcc/DATESTAMP
branches/ibm/gcc-5-branch/gcc/config/i386/sol2.h
branches/ibm/gcc-5-branch/gcc/config/rs6000/rs6000.c
branches/ibm/gcc-5-branch/gcc/config/rs6000/rs6000.md
branches/ibm/gcc-5-branch/gcc/testsuite/ChangeLog

Re: [04/05] Fix PR 69032

[Alexander Monakov]

On Mon, 14 Mar 2016, Andrey Belevantsev wrote:
> We fail to find the proper seqno for the fresh bookkeeping copy in this PR.
> The problem is that in get_seqno_by_preds we are iterating over bb from the
> given insn backwards up to the first bb insn.  We skip the initial insn when
> iterating over bb, yet we should take seqno from it.
> 
> The code in question originally didn't include bb head when iterating, and was
> patched to do so in 2011.  The patch was wrong and instead of including bb
> head managed to exclude the original insn itself.  By reading the original and
> patched code I've convinced myself that the right fix will be to do what the
> patch intended and include both the initial insn and the bb head in the
> iteration.
> 
> Ok for trunk?
> 
> gcc/
> 
> 2016-03-14  Andrey Belevantsev  
> 
> PR rtl-optimization/69032
> * sel-sched-ir.c (get_seqno_by_preds): Include both tmp and head when 
> looping backwards over basic block insns.

"both 'insn' and 'head'" (not tmp).

> diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
> index ec59280..c1a9e55 100644
> --- a/gcc/sel-sched-ir.c
> +++ b/gcc/sel-sched-ir.c
> @@ -4103,11 +4103,14 @@ get_seqno_by_preds (rtx_insn *insn)
>insn_t *preds;
>int n, i, seqno;
>  
> -  while (tmp != head)
> +  /* Loop backwards from insn to head including both.  */

"from INSN to HEAD" (uppercase).

The following structure is equivalent, but would look a bit more canonical:

  for (rtx_insn *tmp = insn; ; tmp = PREV_INSN (tmp))
{
  if (INSN_P (tmp))
return INSN_SEQNO (tmp);
  if (tmp == head)
break;
}

> +  while (1)
>  {
> -  tmp = PREV_INSN (tmp);
>if (INSN_P (tmp))
>  return INSN_SEQNO (tmp);
> +  if (tmp == head)
> + break;
> +  tmp = PREV_INSN (tmp);
>  }
>  
>cfg_preds (bb, , );

OK with formatting nits fixed ('while'/'for' spelling change at your choice).

Thanks.
Alexander

[Bug target/70131] PowerPC ISA 2.07 is inefficient at doint (float)(int)x.

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Mon Mar 14 18:06:45 2016
New Revision: 234186

URL: https://gcc.gnu.org/viewcvs?rev=234186=gcc=rev
Log:
[gcc]
2016-03-11  Michael Meissner  

PR target/70131
* config/rs6000/rs6000.md (round322_fprs): Do not do the
optimization if we have direct move.
(roundu322_fprs): Likewise.

[gcc/testsuite]
2016-03-11  Michael Meissner  

PR target/70131
* gcc.target/powerpc/ppc-round2.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/ppc-round2.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/rs6000.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/70224] [6 regression] ICE: RTL flag check: CROSSING_JUMP_P used with unexpected rtx code 'insn' in relax_delay_slots, at reorg.c:3310

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
  rtx_jump_insn *delay_jump_insn =
dyn_cast  (delay_insn);
  if (! delay_jump_insn || !(condjump_p (delay_jump_insn)
  || condjump_in_parallel_p (delay_jump_insn)))
continue;
delay_jump_insn is always a JUMP_INSN here.

Re: Is test case with 700k lines of code a valid test case?

[Richard Biener]

On March 14, 2016 4:31:57 PM GMT+01:00, Andrey Tarasevich 
 wrote:
>Hi,
>
>I have a source file with 700k lines of code 99% of which are printf()
>statements. Compiling this test case crashes GCC 5.3.0 with
>segmentation fault. 
>Can such test case be considered valid or source files of size 35 MB
>are too much for a C compiler and it should crash? It crashes on Ubuntu
>14.04 64bit with 16GB of RAM. 

It is supposed to compile fine with -O1 at least.

Richard.

>Cheers,
>Andrey

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

[andrewm.roberts at sky dot com]

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

--- Comment #11 from Andrew Roberts  ---
On Native ARM platform the bootstrap does work with the old in tree GMP 4.3.2,
regardless of wether you use none-linux-gnu or armv7l-linux-gnu when
configuring GMP.

Bulding by patching toplevel Makefile to remove none- and replace with armv7l-
../gcc-6.0.0/configure ...
uname_m=`uname -m`
sed -i "s/none-/${uname_m}-/" Makefile
make
make install

Using:
gmp -> ../gmp-4.3.2
mpc -> ../mpc-0.8.1
mpfr -> ../mpfr-2.4.2 (plus latest patches to mpfr to 2.4.2)
isl -> ../isl-0.16.1

^ Builds Ok and compiles simple program (not bootstrapped due to time taken)

Using:
gmp -> ../gmp-4.3.2
mpc -> ../mpc-0.8.1
mpfr -> ../mpfr-2.4.2 (plus latest patches to mpfr 2.4.2)
isl -> ../isl-0.15 (download_prerequisites version)

^ Builds Ok and compiles simple program (not bootstrapped due to time taken)


Bulding by WITHOUT patching toplevel Makefile but with bootstrapping
../gcc-6.0.0/configure ... --enable-bootstrap
make bootstrap-lean
make install

Using:
gmp -> ../gmp-4.3.2
mpc -> ../mpc-0.8.1
mpfr -> ../mpfr-2.4.2 (plus latest patches to mpfr 2.4.2)
isl -> ../isl-0.15 (download_prerequisites version)

^ Builds and bootstraps Ok and compiles simple program

This is all as expected. But as noted the docs suggest later versions of GMP
are ok as well.

If the build was fixed to use correct CPU for configuring GMP it would build
with both old and new versions of GMP. If there are some specific tests which
would exercise the GMP/ISL parts of gcc I could give them a go as well, but
running the entire test suite would take forever due to the slow storage.

[Bug rtl-optimization/70224] [6 regression] ICE: RTL flag check: CROSSING_JUMP_P used with unexpected rtx code 'insn' in relax_delay_slots, at reorg.c:3310

[law at redhat dot com]

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

--- Comment #6 from Jeffrey A. Law  ---
Ah, nevermind, I see where we filter out non-jump insns.

[Bug rtl-optimization/70224] [6 regression] ICE: RTL flag check: CROSSING_JUMP_P used with unexpected rtx code 'insn' in relax_delay_slots, at reorg.c:3310

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
Also note that delay_insn may be an INSN or CALL_INSN AFAICT here.  So just
setting it blindly on DELAY_INSN may not be correct either.  I'm still looking
at those possibilities.

[Bug driver/70192] -fno-pic doesn't work with --enable-default-pie

[psturm at computervoice dot com]

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

--- Comment #5 from psturm at computervoice dot com ---
Created attachment 37962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37962=edit
gcc6 --enable-default-pie

I built GCC6 snapshot 03132016 after applying the PIC patch.

The test suite finished with no errors for gcc or g++.

Next I rebuilt GCC6 using the exact same configuration but adding
--enable-default-pie to the configure. I got 26 errors in g++ and 46 errors in
gcc. Many of them appear to be related to lto.

Attached are the test suite results with --enable-default-pie.

[Bug bootstrap/67728] Build fails when cross-compiling with in-tree GMP and ISL

[bneumeier at gmail dot com]

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

--- Comment #10 from Brett Neumeier  ---
Bernd, I don't think there is any argument that those specific versions of the
library dependencies work.

My sense is that it is a bug to assert "GNU Multiple Precision Library (GMP)
version 4.3.2 (or later)" as a prerequisite to GCC on
https://gcc.gnu.org/install/prerequisites.html if versions of GMP later than
4.3.2 do not work in some circumstances.

If it is OK that GCC builds will fail on one or more supported architectures
when using stable released versions of GMP later than 4.3.2, then the
documentation should assert "GMP version 4.3.2" as the prerequisite.

If it is not OK that GCC builds will fail in those circumstances, then the
build machinery for GCC should be fixed.