date:20170328

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-03-28 Thread rguenther at suse dot de

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

--- Comment #73 from rguenther at suse dot de  ---
On Mon, 27 Mar 2017, jason at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
> 
> --- Comment #72 from Jason Merrill  ---
> (In reply to rguent...@suse.de from comment #69)
> > As I noted elsewhere union members in C++ seem to be pure convenience and a
> > union contains implicit members of all types (well, somehow factor in
> > alignment).  Of course Jason argues char[] is special and introduces this
> > but I can't find text anywhere to support that or require char[] and not,
> > say int[].
> 
> This is clarified somewhat in C++17, by
> 
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0137r1.html
> 
> Note that this wording makes only unsigned char[] special, not signed or plain
> char[].

Ah, I remember seeing this.  So this introduces object size as a way
to allow some TBAA to happen.  Specifically it forbids creating
a series of float sub-objects inside a char[sizeof(float)*4] sub-object
due to "there is no smaller array object that satisfies these 
constraints"(?).  One would need to use sth like

  struct { unsigned char storage[sizeof(float)]; } st[4];

to work around that "limitation".  Not if it's really possible to
take advantage of that size restriction in alias analysis though...

If we'd want to implement sth like this in the middle-end I'd suggest
to force frontends to mark these storage areas in some way.
In the C++ case all unsigned char arrays -- does the "array of N unsigned char"
wording allow for struct C {} to be created within a unsigned char
(no array!) member or has it to be unsigned char[1]?).

I suggest sth like

/* For an ARRAY_TYPE, indicates that when the dynamic type of the storage
   it provides differs from the declard type it is still valid to access
   it via the declared type or the type of a containing object.  */
#define ARRAY_TYPE_IS_STORAGE (NODE) \
  (ARRAY_TYPE_CHECK (NODE)->type_common.array_type_is_storage)

[Bug target/68028] [5/6/7 regression] Compilation error "lto1: error: target attribute or pragma changes single precision floating point" with LTO on PowerPC

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |5.5

[Bug preprocessor/36453] [DR 412] PR36320 breaks boost

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

 CC||sbansal at ciena dot com

--- Comment #16 from Richard Biener  ---
*** Bug 80231 has been marked as a duplicate of this bug. ***

[Bug preprocessor/80231] Error missing binary operator before token "("

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Richard Biener  ---
The PR suggests you write

 #elif (LINUX || ME_BSD_LIKE) && defined(KERNEL_VERSION)
 #if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0))
 ...
 #endif

*** This bug has been marked as a duplicate of bug 36453 ***

[Bug c++/80230] error accessing struct member, error says it's size_t, but it is int

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Richard Biener  ---
The compiler says 'vecstruct[vecstructfromi(5ll)]' is of non-class type
'size_t'.

[Bug libstdc++/80229] [7 Regression] shared_ptr gives an error when is_function is true

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |7.0

[Bug c++/80227] [5/6/7 Regression] SFINAE ambiguity with a pointer to array argument

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |5.5
Summary|[4.6/5/6/7 Regression]  |[5/6/7 Regression] SFINAE
   |SFINAE ambiguity with a |ambiguity with a pointer to
   |pointer to array argument   |array argument

[Bug libstdc++/80229] [7 Regression] shared_ptr gives an error when is_function is true

2017-03-28 Thread redi at gcc dot gnu.org

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Mar 28 07:35:04 2017
New Revision: 246520

URL: https://gcc.gnu.org/viewcvs?rev=246520&root=gcc&view=rev
Log:
PR libstdc++/80229 restore support for shared_ptr

PR libstdc++/80229
* include/bits/shared_ptr_base.h
(__shared_ptr::_M_enable_shared_from_this_with): Change parameters to
non-const and then use remove_cv to get unqualified type.
* testsuite/20_util/enable_shared_from_this/members/const.cc: Don't
cast away constness on object created const.
* testsuite/20_util/shared_ptr/cons/80229.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/80229.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/shared_ptr_base.h
   
trunk/libstdc++-v3/testsuite/20_util/enable_shared_from_this/members/const.cc

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-03-28 Thread bernd.edlinger at hotmail dot de

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

--- Comment #74 from Bernd Edlinger  ---
(In reply to rguent...@suse.de from comment #73)
> 
> Ah, I remember seeing this.  So this introduces object size as a way
> to allow some TBAA to happen.  Specifically it forbids creating
> a series of float sub-objects inside a char[sizeof(float)*4] sub-object
> due to "there is no smaller array object that satisfies these 
> constraints"(?).  One would need to use sth like
> 
>   struct { unsigned char storage[sizeof(float)]; } st[4];
> 

I think that is meant differently, but I am not sure if I
understand this kind of english good enough..., the sample uses:

template
struct AlignedUnion {
  alignas(T...) unsigned char data[max(sizeof(T)...)];
};

so that data array is max of sizeof(int) and sizeof(char)

... the more they write the less clear it becomes :)


> to work around that "limitation".  Not if it's really possible to
> take advantage of that size restriction in alias analysis though...
> 
> If we'd want to implement sth like this in the middle-end I'd suggest
> to force frontends to mark these storage areas in some way.
> In the C++ case all unsigned char arrays -- does the "array of N unsigned
> char"
> wording allow for struct C {} to be created within a unsigned char
> (no array!) member or has it to be unsigned char[1]?).
> 
> I suggest sth like
> 
> /* For an ARRAY_TYPE, indicates that when the dynamic type of the storage
>it provides differs from the declard type it is still valid to access
>it via the declared type or the type of a containing object.  */
> #define ARRAY_TYPE_IS_STORAGE (NODE) \
>   (ARRAY_TYPE_CHECK (NODE)->type_common.array_type_is_storage)

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-03-28 Thread rguenther at suse dot de

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

--- Comment #75 from rguenther at suse dot de  ---
On Tue, 28 Mar 2017, bernd.edlinger at hotmail dot de wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
> 
> --- Comment #74 from Bernd Edlinger  ---
> (In reply to rguent...@suse.de from comment #73)
> > 
> > Ah, I remember seeing this.  So this introduces object size as a way
> > to allow some TBAA to happen.  Specifically it forbids creating
> > a series of float sub-objects inside a char[sizeof(float)*4] sub-object
> > due to "there is no smaller array object that satisfies these 
> > constraints"(?).  One would need to use sth like
> > 
> >   struct { unsigned char storage[sizeof(float)]; } st[4];
> > 
> 
> I think that is meant differently, but I am not sure if I
> understand this kind of english good enough..., the sample uses:
> 
> template
> struct AlignedUnion {
>   alignas(T...) unsigned char data[max(sizeof(T)...)];
> };
> 
> so that data array is max of sizeof(int) and sizeof(char)
> 
> ... the more they write the less clear it becomes :)

I was thinking about how to arrange for _multiple_ objects to
be constructed inside a memory area, the interesting size clause
seems to require workarounds like above.  Otherwise the "array element"
choice doesn't make much sense I guess.

[Bug tree-optimization/80232] New: Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms

2017-03-28 Thread vincenzo.innocente at cern dot ch

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

Bug ID: 80232
   Summary: Ofast pessimizes Sparse matmult in scimark2 benchmark
on avx platforms
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

on my machine
after the usual
mkdir scimark2TMP
cd scimark2TMP
wget http://math.nist.gov/scimark2/scimark2_1c.zip .
unzip scimark2_1c.zip
gcc -v

I get 
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/afs/cern.ch/work/i/innocent/public/w5/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk//configure
--prefix=/afs/cern.ch/user/i/innocent/w5 -enable-languages=c,c++,lto,fortran
--enable-lto -enable-libitm -disable-multilib
Thread model: posix
gcc version 7.0.1 20170326 (experimental) [trunk revision 246485] (GCC) 

[innocent@vinavx3 scimark2TMP]$ gcc -O2 -march=haswell *.c -lm
[innocent@vinavx3 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult"
Sparse matmult  Mflops:  3271.69(N=1000, nz=5000)
[innocent@vinavx3 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult"
Sparse matmult  Mflops:  2946.76(N=10, nz=100)
[innocent@vinavx3 scimark2TMP]$ gcc -Ofast -march=nehalem *.c -lm
[innocent@vinavx3 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult"
Sparse matmult  Mflops:  3281.93(N=1000, nz=5000)
[innocent@vinavx3 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult"
Sparse matmult  Mflops:  2859.34(N=10, nz=100)
[innocent@vinavx3 scimark2TMP]$ gcc -Ofast -march=corei7-avx *.c -lm
[innocent@vinavx3 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult"
Sparse matmult  Mflops:  2987.40(N=1000, nz=5000)
[innocent@vinavx3 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult"
Sparse matmult  Mflops:  2869.35(N=10, nz=100)
[innocent@vinavx3 scimark2TMP]$ gcc -Ofast -march=haswell *.c -lm
[innocent@vinavx3 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult"
Sparse matmult  Mflops:  2579.52(N=1000, nz=5000)
[innocent@vinavx3 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult"
Sparse matmult  Mflops:  2381.40(N=10, nz=100)

so O2 and sse4.2 are the fastest, avx is already slower, avx2 is dramatically
slower
par of the difference can be due to gather operation as in #57796: not sure the
difference w/r/t O2


interesting to note that on KNL it makes almost not difference (not sure if
this is positive or negative...) with a hint of speedup for the large
problem...

[innocent@vinknl0 scimark2TMP]$ gcc -Ofast -march=knl *.c -lm
[innocent@vinknl0 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult"
./a.out -large 5 | grep "Sparse matmult"
Sparse matmult  Mflops:   348.13(N=1000, nz=5000)
[innocent@vinknl0 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult"
Sparse matmult  Mflops:   358.67(N=10, nz=100)
[innocent@vinknl0 scimark2TMP]$ gcc -O2 -march=knl *.c -lm
[innocent@vinknl0 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult"
Sparse matmult  Mflops:   329.33(N=1000, nz=5000)
[innocent@vinknl0 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult"
Sparse matmult  Mflops:   321.51(N=10, nz=100)
[innocent@vinknl0 scimark2TMP]$  gcc -Ofast -march=corei7-avx *.c -lm
[innocent@vinknl0 scimark2TMP]$ ./a.out 5 | grep "Sparse matmult"
Sparse matmult  Mflops:   343.12(N=1000, nz=5000)
[innocent@vinknl0 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult"
Sparse matmult  Mflops:   323.03(N=10, nz=100)
[innocent@vinknl0 scimark2TMP]$ gcc -Ofast -march=nehalem *.c -lm
 ./a.out 5 | grep "Sparse matmult"
[innocent@vinknl0 scimark2TMP]$  ./a.out 5 | grep "Sparse matmult"
Sparse matmult  Mflops:   343.57(N=1000, nz=5000)
[innocent@vinknl0 scimark2TMP]$ ./a.out -large 5 | grep "Sparse matmult"
Sparse matmult  Mflops:   321.00(N=10, nz=100)

[Bug libstdc++/80229] [7 Regression] shared_ptr gives an error when is_function is true

2017-03-28 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
Fixed.

[Bug c++/80230] error accessing struct member, error says it's size_t, but it is int

2017-03-28 Thread redi at gcc dot gnu.org

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

--- Comment #4 from Jonathan Wakely  ---
Please stop reporting a bug every time your code doesn't compile.

[Bug sanitizer/80067] [6/7 Regression] ICE in fold_comparison with -fsanitize=undefined

2017-03-28 Thread mpolacek at gcc dot gnu.org

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue Mar 28 08:13:04 2017
New Revision: 246521

URL: https://gcc.gnu.org/viewcvs?rev=246521&root=gcc&view=rev
Log:
PR sanitizer/80067
* fold-const.c (fold_comparison): Use protected_set_expr_location
instead of SET_EXPR_LOCATION.

* c-c++-common/ubsan/shift-10.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/shift-10.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/80067] [6/7 Regression] ICE in fold_comparison with -fsanitize=undefined

2017-03-28 Thread mpolacek at gcc dot gnu.org

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

--- Comment #4 from Marek Polacek  ---
Author: mpolacek
Date: Tue Mar 28 08:16:27 2017
New Revision: 246522

URL: https://gcc.gnu.org/viewcvs?rev=246522&root=gcc&view=rev
Log:
PR sanitizer/80067
* fold-const.c (fold_comparison): Use protected_set_expr_location
instead of SET_EXPR_LOCATION.

* c-c++-common/ubsan/shift-10.c: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/c-c++-common/ubsan/shift-10.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/fold-const.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug sanitizer/80067] [6/7 Regression] ICE in fold_comparison with -fsanitize=undefined

2017-03-28 Thread mpolacek at gcc dot gnu.org

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug ipa/79931] ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2

2017-03-28 Thread marxin at gcc dot gnu.org

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

--- Comment #4 from Martin Liška  ---
I can confirm that, it's not Ubuntu specific, easily reproducible on current
trunk.

Issues is that ODR type graph is built dynamically, starting just with types of
methods. During gimplification of functions, possible_polymorphic_call_targets
is asked and known results are put into polymorphic_call_target_hash. Problem
comes when a type receives a new derived type which can add possible target.
This happens in your test-case.

I prepared a simple patch validating that # of targets does not change during
time in the cache and there's example that fails:

class b
{
protected:
  enum
  {
c
  };
  virtual void d (int a) const;
  bool e ();
  char f;
};
bool
b::e ()
{
  d (123);
}
class g : b
{
  void
  d (int a) const
  {
  }
};

>From possible 2 targets, new result would be 1. Still it's partial list and
that can probably just make worse decisions.
But still, the inconsistency should be probably handled.

Honza?

[Bug ipa/79931] ICE in dump_possible_polymorphic_call_targets with -fdump-ipa-all -O2

2017-03-28 Thread marxin at gcc dot gnu.org

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

--- Comment #5 from Martin Liška  ---
Created attachment 41061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41061&action=edit
Verification patch

[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation

2017-03-28 Thread marxin at gcc dot gnu.org

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

--- Comment #2 from Martin Liška  ---
May I ask you Marek what would be use-case of such attribute? Thanks

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

2017-03-28 Thread tschwinge at gcc dot gnu.org

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

--- Comment #9 from Thomas Schwinge  ---
You could further optimize the script to omit "." locations: if the "dg-*"
directive actually is placed on the appropriate line already.

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

2017-03-28 Thread tschwinge at gcc dot gnu.org

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #8 from Thomas Schwinge  ---
(In reply to Mike Stump from comment #6)
> The . and .-1, .+1, .-2 forms are fine.  The .-62 forms are as problematic
> as the original I suspect.  I think we should exclude any number greater
> than some small int, say, 9.  So, .-9 .. .+9 in the new form only.  If
> outside that range, I think I'd rather punt.  The idea is that the absolute
> number at least has a line number that in an editor you can go directly to,
> and it corresponds with the number in the error messages directly, aiding
> understanding which one is referred to without having to ungoop the relative
> number first.

I would guess that a lange number of these are actually cases where all the
"dg-*" directives have been assembled at the end of the file?  In such cases,
it would perhaps make sense to move them onto or next to the lines they apply
to -- unless that doesn't make sense for other reasons (when they are grouped
together for a reason).

[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-28
 Blocks||53947
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So vectorization related.  gathers are known to be notoriously slow but
cost-wise they are not properly represented, in this case they are just
accounted as unaligned load...

It would be more appropriate to account them as VMAT_ELEMENTWISE I suppose
(N scalar loads plus gathering into a vector).  Thus:

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   (revision 246500)
+++ gcc/tree-vect-stmts.c   (working copy)
@@ -929,7 +929,8 @@ vect_model_store_cost (stmt_vec_info stm

   tree vectype = STMT_VINFO_VECTYPE (stmt_info);
   /* Costs of the stores.  */
-  if (memory_access_type == VMAT_ELEMENTWISE)
+  if (memory_access_type == VMAT_ELEMENTWISE
+  || memory_access_type == VMAT_GATHER_SCATTER)
 /* N scalar stores plus extracting the elements.  */
 inside_cost += record_stmt_cost (body_cost_vec,
 ncopies * TYPE_VECTOR_SUBPARTS (vectype),
@@ -938,7 +939,8 @@ vect_model_store_cost (stmt_vec_info stm
 vect_get_store_cost (dr, ncopies, &inside_cost, body_cost_vec);

   if (memory_access_type == VMAT_ELEMENTWISE
-  || memory_access_type == VMAT_STRIDED_SLP)
+  || memory_access_type == VMAT_STRIDED_SLP
+  || memory_access_type == VMAT_GATHER_SCATTER)
 inside_cost += record_stmt_cost (body_cost_vec,
 ncopies * TYPE_VECTOR_SUBPARTS (vectype),
 vec_to_scalar, stmt_info, 0, vect_body);
@@ -1056,7 +1058,8 @@ vect_model_load_cost (stmt_vec_info stmt
 }

   /* The loads themselves.  */
-  if (memory_access_type == VMAT_ELEMENTWISE)
+  if (memory_access_type == VMAT_ELEMENTWISE
+  || memory_access_type == VMAT_GATHER_SCATTER)
 {
   /* N scalar loads plus gathering them into a vector.  */
   tree vectype = STMT_VINFO_VECTYPE (stmt_info);
@@ -1069,7 +1072,8 @@ vect_model_load_cost (stmt_vec_info stmt
&inside_cost, &prologue_cost, 
prologue_cost_vec, body_cost_vec, true);
   if (memory_access_type == VMAT_ELEMENTWISE
-  || memory_access_type == VMAT_STRIDED_SLP)
+  || memory_access_type == VMAT_STRIDED_SLP
+  || memory_access_type == VMAT_GATHER_SCATTER)
 inside_cost += record_stmt_cost (body_cost_vec, ncopies, vec_construct,
 stmt_info, 0, vect_body);


changes cost-model for haswell from

SparseCompRow.c:37:17: note: Cost model analysis:
  Vector inside of loop cost: 13
  Vector prologue cost: 25
  Vector epilogue cost: 26
  Scalar iteration cost: 5
  Scalar outside cost: 7
  Vector outside cost: 51
  prologue iterations: 4
  epilogue iterations: 4
  Calculated minimum iters for profitability: 10

to

SparseCompRow.c:37:17: note: Cost model analysis:
  Vector inside of loop cost: 23
  Vector prologue cost: 25
  Vector epilogue cost: 26
  Scalar iteration cost: 5
  Scalar outside cost: 7
  Vector outside cost: 51
  prologue iterations: 4
  epilogue iterations: 4
  Calculated minimum iters for profitability: 10
SparseCompRow.c:37:17: note:   Runtime profitability threshold = 9
SparseCompRow.c:37:17: note:   Static estimate profitability threshold = 15

so no change in overall profitability...

We seem to peel for alignment which makes the runtime cost check quite
expensive:

   [12.75%]:
  _114 = (unsigned int) rowRp1_34;
  _112 = (unsigned int) rowR_33;
  niters.6_54 = _114 - _112;
  _92 = (long unsigned int) rowR_33;
  _91 = _92 * 4;
  vectp.7_93 = col_38(D) + _91;
  _89 = (unsigned long) vectp.7_93;
  _88 = _89 >> 2;
  _87 = -_88;
  _86 = (unsigned int) _87;
  prolog_loop_niters.8_90 = _86 & 7;
  _44 = (unsigned int) rowRp1_34;
  _43 = (unsigned int) rowR_33;
  _27 = _44 - _43;
  _26 = _27 + 4294967295;
  _25 = prolog_loop_niters.8_90 + 7;
  _24 = MAX_EXPR <_25, 8>;
  if (_26 < _24)

given that rowRp1 - rowR is 5 for the small case and 10 for the large
runtime profitability is not given for the small and on the border for
the large case...  also the col[] setup is so that the accesses to
x are continguous which means gather is overkill here.  Of course we have
no way to vectorize it otherwise (we don't "open-code" gather).

My first suggestion would be to split the profitability check from the
prologue niter computation.  And of course fix the cost computation like
suggested above.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

2017-03-28 Thread ro at CeBiTec dot Uni-Bielefeld.DE

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

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #16 from Jerry DeLisle  ---
> (In reply to Rainer Orth from comment #15)
>
> Can you change line:
>
> if (imsg.ne."End of record") call abort
>
> to:
>
> if (imsg.ne."End of record") print *, imsg
>
> and lets see what its saying.

Sure.  I see

ro@colima 27 >
LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs
./dtio_26.exe 


Program aborted. Backtrace:
Abort

matching the 256 x ' ' printed by gdb.

Rainer

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

2017-03-28 Thread tschwinge at gcc dot gnu.org

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

--- Comment #10 from Thomas Schwinge  ---
(In reply to Martin Sebor from comment #7)
> A more robust solution that wouldn't have to subject to a limit would be to
> add an annotation to dg-{error,message,warning} to indicate that the next
> dg-{bogus,error,message,warning} directive is meant to be applied to the
> same line as the current one.  For instance, something like this:

Instead of working "into the future"...

>   foobar;
>   /* { dg-warning "warning for foobar" continue }
>  { dg-warning "another warning for foobar" continue }
>  { dg-error "error for foobar" } */
> 
> (For brevity I omitted the comment and the { target ... } parts of the
> directives above.  It would also be nice to be able to do away with those
> when they're not necessary.)

..., perhaps it's easier to implement that idea the other way round: at the end
of a "dg-*" handling routine, store the current location into a global
variable, and if a later "dg-*" directive uses a "continue" location, use the
value of the global variable instead.  That is:

foobar;
/* { dg-warning "warning for foobar" .-1 }
   Bla, bla, reasoning.
   { dg-warning "another warning for foobar" continue }
   Bla, bla, more reasoning.
   { dg-error "error for foobar" continue } */

[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation

2017-03-28 Thread mpolacek at gcc dot gnu.org

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

--- Comment #3 from Marek Polacek  ---
E.g. if you have an application that is usually just busy waiting, waiting for
something to happen, but you're not interested in profiling that function, or
some function runs in a context where it is not safe to call into runtime
support code.

[Bug ipa/80104] ICE in initialize_argument_information, at calls.c:1748

2017-03-28 Thread marxin at gcc dot gnu.org

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Tue Mar 28 09:01:57 2017
New Revision: 246525

URL: https://gcc.gnu.org/viewcvs?rev=246525&root=gcc&view=rev
Log:
Fix calls.c for a _complex type (PR ipa/80104).

2017-03-28  Martin Liska  

PR ipa/80104
* cgraphunit.c (cgraph_node::expand_thunk): Mark argument of a
thunk call as DECL_GIMPLE_REG_P when vector or complex type.
2017-03-28  Martin Liska  

PR ipa/80104
* gcc.dg/ipa/pr80104.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/ipa/pr80104.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-03-28 Thread bernd.edlinger at hotmail dot de

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

--- Comment #76 from Bernd Edlinger  ---
FYI this is also on the same topic:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3296.html#US27
Question:
"Related to core issue 1027, consider:

int f() {
union U { double d; } u1, u2;
(int&)u1.d = 1;
u2 = u1;
return (int&)u2.d;
}

Does this involve undefined behavior? 3.8/4 seems to say that it's OK to
clobber u1 with an int object. Then union assignment copies the object
representation, possibly creating an int object in u2 and making the return
statement well-defined. If this is well-defined, compilers are significantly
limited in the assumptions they can make about type aliasing. On the other
hand, the variant where U has an array of unsigned char member must be
well-defined in order to support std::aligned_storage."

Proposed Resolution:
"Clarify that this testcase is undefined, but that adding an array of unsigned
char to union U would make it well-defined--if a storage location is allocated
with a particular type, it should be undefined to create an object in that
storage if it would be undefined to access the stored value of the object
through the allocated type."

Disposition:
"REJECTED

Resolving this question was not deemed essential for this revision of the
Standard, but core issues 1116 remains open for possible consideration in a
future revision."

Does this mean that the boost code is still invalid because there
is no array of unsigned char ?

Or does it not count because it was REJECTED ?

[Bug target/71922] arm: ifuncs are broken in for arm (gcc generates incorrect code in object file)

2017-03-28 Thread ramana at gcc dot gnu.org

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #9 from Ramana Radhakrishnan  ---
This appears to be a binutils issue - please take it up 
there.

http://sourceware.org/bugzilla/

[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation

2017-03-28 Thread marxin at gcc dot gnu.org

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

--- Comment #4 from Martin Liška  ---
I see. Simplest solution is to propagate the attribute to callers, or don't
allow inlining between a pair of function one w/ and second w/o the attribute?
Richi?

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

2017-03-28 Thread ramana at gcc dot gnu.org

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Target|arm-none-eabi   |
 CC||ramana at gcc dot gnu.org

--- Comment #14 from Ramana Radhakrishnan  ---
I don't think arm is a valid target for this given PR80155 was opened as a
consequence of fixing PR77498..

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-03-28 Thread redi at gcc dot gnu.org

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

--- Comment #77 from Jonathan Wakely  ---
It was rejected in 2010, but see
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1116 for the later
discussion, and:

"[Adopted at the June, 2016 meeting as document P0137R1.]"

Which Jason already pointed to in Comment 72.

[Bug testsuite/78529] [7 Regression] gcc.c-torture/execute/builtins/strcat-chk.c failed with lto/O2

2017-03-28 Thread ramana at gcc dot gnu.org

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org
  Component|lto |testsuite

--- Comment #34 from Ramana Radhakrishnan  ---
This is really a testsuite issue.

[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms

2017-03-28 Thread rguenth at gcc dot gnu.org

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

--- Comment #2 from Richard Biener  ---
--param vect-max-peeling-for-alignment=0 disables peeling for alignment (but
also makes the runtime profitability trigger at 6 loop iterations already).

I suspect gather has a quite high latency and the loop just doesn't have enough
work to compensate for that (given we have two gathers in the loop as well).
We're also using

  vect__15.18_120 = VEC_PERM_EXPR ;

for the index vector of the upper half of the gather but the upper half of the
vector is likely ignored and thus a representation with half of the vector
size and using a BIT_FIELD_REF would be more appropriate here.

.L10:
vmovdqa (%r15,%rax), %ymm2
vmovapd %ymm5, %ymm6
vmovapd %ymm5, %ymm7
addl$1, %edi
vgatherdpd  %ymm6, (%r9,%xmm2,8), %ymm3
vperm2i128  $17, %ymm2, %ymm2, %ymm2
vmovdqa %xmm2, %xmm4
vgatherdpd  %ymm7, (%r9,%xmm4,8), %ymm2
vmulpd  32(%r11,%rax,2), %ymm2, %ymm2
vfmadd231pd (%r11,%rax,2), %ymm3, %ymm2
addq$32, %rax
vaddpd  %ymm2, %ymm0, %ymm0
cmpl%edi, %r14d
ja  .L10

eventually the x86 cost hook needs to consider overall instruction count to
properly penaltize gather use.  I suspect two xmm loads from %r15/%rax
feeding the two gathers would be easier to pipeline.  The fma is likely
also pessimizing pipelining.

[Bug testsuite/79418] ERROR: gcc.dg/torture/stackalign/builtin-apply-2.c -O0 : syntax error in targe t selector "target arm_hf_eabi || avr-- || riscv--*" for "

2017-03-28 Thread ramana at gcc dot gnu.org

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Ramana Radhakrishnan  ---
Fixed I think by r245240

[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

 Depends on||57796

--- Comment #3 from Richard Biener  ---
The gather issue is a duplicate btw (by yourself), PR57796.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796
[Bug 57796] AVX2 gather vectorization: code bloat and reduction of performance

[Bug middle-end/80222] may_alias folded away

2017-03-28 Thread rguenth at gcc dot gnu.org

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 28 10:10:01 2017
New Revision: 246527

URL: https://gcc.gnu.org/viewcvs?rev=246527&root=gcc&view=rev
Log:
2017-03-28  Richard Biener  

PR middle-end/80222
* gimple-fold.c (gimple_fold_indirect_ref): Do not touch
TYPE_REF_CAN_ALIAS_ALL references.
* fold-const.c (fold_indirect_ref_1): Likewise.

* g++.dg/pr80222.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/pr80222.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/80222] may_alias folded away

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||7.0.1

--- Comment #2 from Richard Biener  ---
Fixed on trunk sofar.

[Bug target/57796] AVX2 gather vectorization: code bloat and reduction of performance

2017-03-28 Thread vincenzo.innocente at cern dot ch

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

--- Comment #8 from vincenzo Innocente  ---
My understanding of the gather latency is that it essentially corresponds to a
load per cacheline: fast if all items are closeby, slower than scalar loads if
items are all in different cachelines. Not sure how this can be turned in a
"cost model"

[Bug rtl-optimization/80233] New: [7 Regression] ICE in combine_instructions w/ -O2 (and above)

2017-03-28 Thread asolokha at gmx dot com

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

Bug ID: 80233
   Summary: [7 Regression] ICE in combine_instructions w/ -O2 (and
above)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu*

gcc-7.0.0-alpha20170326 snapshot ICEs on the following snippet w/ -O2 (-Os,
-O3, -Ofast):

int xg;

void
t4 (int o9)
{
  int it;

  if (o9 == 0)
{
  int fx;

  xg *= it;
  if (xg == 0)
it /= 0;

  fx = (it != 0) ? (xg < 0) : (xg / o9);
  if (fx != 0)
xg = 0;
}
}

% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20170326 -O2 -w -c hzfu8xgw.c
hzfu8xgw.c: In function 't4':
hzfu8xgw.c:20:1: internal compiler error: Segmentation fault
 }
 ^

(gdb) where
#0  0x02aaaba73033 in combine_instructions (nregs=,
f=)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/combine.c:1258
#1  rest_of_handle_combine ()
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/combine.c:14650
#2  (anonymous namespace)::pass_combine::execute (this=)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/combine.c:14695
#3  0x02aaab2d8ec6 in execute_one_pass (pass=pass@entry=0x2aaac493020)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/passes.c:2465
#4  0x02aaab2d98b8 in execute_pass_list_1 (pass=0x2aaac493020)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/passes.c:2554
#5  0x02aaab2d98ca in execute_pass_list_1 (pass=0x2aaac492480)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/passes.c:2555
#6  0x02aaab2d995c in execute_pass_list (fn=,
pass=)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/passes.c:2565
#7  0x02f2a87a in cgraph_node::expand (this=0x3fff72ab000)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/cgraphunit.c:2038
#8  0x02f2c4ca in expand_all_functions ()
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/cgraphunit.c:2174
#9  symbol_table::compile (this=0x3fff7127000)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/cgraphunit.c:2531
#10 0x02f2eb03 in symbol_table::finalize_compilation_unit
(this=0x3fff7127000)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/cgraphunit.c:2621
#11 0x02aaab3d9dfb in compile_file ()
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/toplev.c:492
#12 0x02d4b9c2 in do_compile ()
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/toplev.c:2000
#13 toplev::main (this=0x3ffc940, argc=23, argv=0x3ffca48)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/toplev.c:2134
#14 0x02d4e258 in main (argc=23, argv=0x3ffca48)
at
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/main.c:39

[Bug target/47847] PowerPC: ICE: -mcpu=8540 -meabi -msdata -fno-common -mfloat-gprs=double

2017-03-28 Thread segher at gcc dot gnu.org

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Segher Boessenkool  ---
So, not a bug.

[Bug target/47751] Wrong code with -mcpu=8540 -mfloat-gprs=double -mspe -Os on PowerPC

2017-03-28 Thread segher at gcc dot gnu.org

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #4 from Segher Boessenkool  ---
Not a bug.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-03-28 Thread bernd.edlinger at hotmail dot de

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

--- Comment #78 from Bernd Edlinger  ---
Ah, adopted is the opposite of rejected, fine.

Does this mean that the boost code is still incorrect,
because it is not using an array of unsigned char ?

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-03-28 Thread redi at gcc dot gnu.org

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

--- Comment #79 from Jonathan Wakely  ---
That's a new change for C++17, and I don't think today's GCC will treat it any
differently if it uses unsigned char[] instead of char[].

[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32

2017-03-28 Thread schwab at gcc dot gnu.org

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

--- Comment #15 from Andreas Schwab  ---
Author: schwab
Date: Tue Mar 28 10:29:34 2017
New Revision: 246528

URL: https://gcc.gnu.org/viewcvs?rev=246528&root=gcc&view=rev
Log:
Support for Ada on aarch64 with -mabi=ilp32

PR ada/80117
* system-linux-aarch64-ilp32.ads: New file.
* gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS_COMMON): Rename
from LIBGNAT_TARGET_PAIRS.
(LIBGNAT_TARGET_PAIRS_32, LIBGNAT_TARGET_PAIRS_64): Define.
(LIBGNAT_TARGET_PAIRS): Use LIBGNAT_TARGET_PAIRS_COMMON, and
LIBGNAT_TARGET_PAIRS_64 or LIBGNAT_TARGET_PAIRS_32 for -mabi=lp64
or -mabi=ilp32, resp.

Added:
trunk/gcc/ada/system-linux-aarch64-ilp32.ads
Modified:
trunk/gcc/ada/ChangeLog
trunk/gcc/ada/gcc-interface/Makefile.in

[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms

2017-03-28 Thread rguenth at gcc dot gnu.org

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

--- Comment #4 from Richard Biener  ---
I have (broadwell CPU) with -Ofast -march=native [-mno-avx]

Sparse matmult  Mflops:  2481.77(N=1000, nz=5000)  -mno-avx
Sparse matmult  Mflops:  2043.19(N=1000, nz=5000)
Sparse matmult  Mflops:  2248.71(N=10, nz=100)  -mno-avx
Sparse matmult  Mflops:  1664.08(N=10, nz=100)

for the small system it's the overhead when not taking the vectorized code-path
at runtime while for the large it is the overhead when taking the vectorized
code-path.  With -mno-avx we are not vectorizing the loop.

Note broadwell does not yet reach optimal latency/throughput for gathers
(2 lanes / cycle saturating the two load ports).  I don't have a skylake
machine for comparison though.

[Bug rtl-optimization/80233] [7 Regression] ICE in combine_instructions w/ -O2 (and above)

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |7.0

[Bug rtl-optimization/45498] Optimisations fail above arbitrary level of complexity

2017-03-28 Thread segher at gcc dot gnu.org

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Segher Boessenkool  ---
At least as far back as 4.9, GCC does not touch the stack in the inner
loop (except for stfiwx insns).  Closing as fixed.

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Mine.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-03-28 Thread bernd.edlinger at hotmail dot de

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

--- Comment #80 from Bernd Edlinger  ---
but they use just: "mutable char data;"

[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64

2017-03-28 Thread katsunori.kumatani at gmail dot com

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

Katsunori Kumatani  changed:

   What|Removed |Added

 CC||katsunori.kumatani at gmail 
dot co
   ||m

--- Comment #24 from Katsunori Kumatani  
---
I think this bug should be reopened because the current behavior is
restricting. Andy is right. The compiler should be a tool and the developer
using it should be allowed to shoot himself in the foot if that's what he
wants. In this particular case it restricts freedom and the compiler should be
the developer's tool not the other way around.

Simply remove the TARGET_SSE check and let the actual developer decide if he
wants the stack realigned instead of the compiler? There's even an attribute
for that (to force stack realignment). I don't understand why such a check is
even there, it servers NO purpose except to imply that the compiler knows
better than the person using it, which is just wrong -- if someone wants to use
SSE *and* 8-byte aligned stack, then let him do it.

This will simply force GCC to realign the stack if and *only if* it needs to
use an aligned SSE variable on the stack, just as it does with AVX already.

So if 99% of your functions *do not* use SSE, they won't use 16-byte alignment.

For that odd function that does use aligned SSE (or AVX), it will simply
realign the stack to 16 or 32-bytes in that function's prolog. Nothing special
and it won't crash. (as long as you don't call into library functions
obviously)

Just let the developer decide please, without having to recompile a custom
modified GCC to remove that check that screams "I'm the compiler and I know
better than you do what your code needs"...

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-03-28 Thread redi at gcc dot gnu.org

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

--- Comment #81 from Jonathan Wakely  ---
(In reply to Bernd Edlinger from comment #80)
> but they use just: "mutable char data;"

No, actually it doesn't, see comment 45. The original testcase that this reprot
came from is https://bugzilla.redhat.com/show_bug.cgi?id=1422456 which uses
Boost 1.63 and that has an array of char. Jakub used the wrong version of Boost
to create the code attached here.

[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32

2017-03-28 Thread ebotcazou at gcc dot gnu.org

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

--- Comment #16 from Eric Botcazou  ---
Feel free to backport it onto the 6 branch.

[Bug ipa/80205] [5/6/7 Regression] ICE in walk_ssa_copies at ipa-polymorphic-call.c:835

2017-03-28 Thread marxin at gcc dot gnu.org

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

--- Comment #1 from Martin Liška  ---
Author: marxin
Date: Tue Mar 28 11:37:22 2017
New Revision: 246530

URL: https://gcc.gnu.org/viewcvs?rev=246530&root=gcc&view=rev
Log:
Handle PHI nodes w/o a argument (PR ipa/80205).

2017-03-28  Martin Liska  

PR ipa/80205
* g++.dg/ipa/pr80205.C: New test.
2017-03-28  Richard Biener  

PR ipa/80205
* tree-inline.c (copy_phis_for_bb): Do not create PHI node
without arguments, generate default definition of a SSA name.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr80205.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-inline.c

[Bug ipa/80205] [5/6/7 Regression] ICE in walk_ssa_copies at ipa-polymorphic-call.c:835

2017-03-28 Thread marxin at gcc dot gnu.org

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed|2017-03-27 00:00:00 |2017-03-28
  Known to work||7.0
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.3.0

--- Comment #2 from Martin Liška  ---
Fixed on trunk so far.

[Bug ipa/80104] ICE in initialize_argument_information, at calls.c:1748

2017-03-28 Thread marxin at gcc dot gnu.org

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||7.0
  Known to fail|7.0 |

--- Comment #3 from Martin Liška  ---
Fixed on trunk so far.

[Bug sanitizer/79993] [5/6/7 Regression] ICE in tree_to_uhwi, at tree.c:7344

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug sanitizer/80168] [5/6 Regression] ICE in make_decl_rtl, at varasm.c:1311 w/ VLA and -fsanitize=address

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||7.0.1
Summary|[5/6/7 Regression] ICE in   |[5/6 Regression] ICE in
   |make_decl_rtl, at   |make_decl_rtl, at
   |varasm.c:1311 w/ VLA and|varasm.c:1311 w/ VLA and
   |-fsanitize=address  |-fsanitize=address

--- Comment #7 from Richard Biener  ---
Fixed on trunk sofar.

[Bug c++/80179] [6/7 Regression] ICE initializing a static local object with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P4

[Bug c++/80179] [6/7 Regression] ICE initializing a static local object with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|error-recovery  |
   Priority|P4  |P2

[Bug target/79262] [6/7 Regression] load gap with store gap causing performance regression in 462.libquantum

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include

2017-03-28 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-03-28 Thread rguenth at gcc dot gnu.org

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

--- Comment #82 from Richard Biener  ---
Btw, for the attached patch it would fail to handle the case of passing the
aggregate by value and the inliner introducing the aggregate copy:

inline void* operator new(__SIZE_TYPE__, void* __p) { return __p; }

struct X { union { int i; char s[4]; } u; };

static float foo (X y)
{
  return reinterpret_cast (y.u.s);
}

int main ()
{
  X x;
  new (&x.u.s) float (1.0);
  if (foo (x) != 1.0)
__builtin_abort ();
}

generates at -O2 after inlining:

int main() ()
{
  void * D.2385;
  float D.2383;
  struct X y;
  struct X x;
  float _7;
  bool retval.0_8;

   [100.00%]:
  MEM[(float *)&x] = 1.0e+0;
  y = x;
  _7 = MEM[(float &)&y];
...

[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64

2017-03-28 Thread ubizjak at gmail dot com

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

--- Comment #25 from Uroš Bizjak  ---
(In reply to Katsunori Kumatani from comment #24)
> I think this bug should be reopened because the current behavior is
> restricting.

[...]

I agree. Let's remove this artificial dependency on -msse.

Patch in testing:

--cut here--
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 246531)
+++ config/i386/i386.c  (working copy)
@@ -5927,9 +5927,8 @@ ix86_option_override_internal (bool main_args_p,
   ix86_preferred_stack_boundary = PREFERRED_STACK_BOUNDARY_DEFAULT;
   if (opts_set->x_ix86_preferred_stack_boundary_arg)
 {
-  int min = (TARGET_64BIT_P (opts->x_ix86_isa_flags)
-? (TARGET_SSE_P (opts->x_ix86_isa_flags) ? 4 : 3) : 2);
-  int max = (TARGET_SEH ? 4 : 12);
+  int min = TARGET_64BIT_P (opts->x_ix86_isa_flags)? 3 : 2;
+  int max = TARGET_SEH ? 4 : 12;

   if (opts->x_ix86_preferred_stack_boundary_arg < min
  || opts->x_ix86_preferred_stack_boundary_arg > max)
--cut here--

[Bug c++/80234] New: ICE in splice_child_die at dwarfout.c:5265

2017-03-28 Thread tim at array dot ca

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

Bug ID: 80234
   Summary: ICE in splice_child_die at dwarfout.c:5265
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tim at array dot ca
  Target Milestone: ---

Created attachment 41062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41062&action=edit
preprocessed source

In the fedora rawhide GCC 7.0.1-0.12 build (x86_64), I'm getting an ICE in the
following code when generating debug info:

class foo
{

public:

 static constexpr const char name_str[] = "foo";
 virtual ~foo();

};

constexpr const char foo::name_str[];

foo::~foo()
{
}

% /usr/bin/c++ -g -std=gnu++17 -Wall -Wextra -o /home/tim/tmp/foo.o -c
/home/tim/Projects/ugp/src/ugp/UGF/Core/src/component/foo.cc
/home/tim/Projects/ugp/src/ugp/UGF/Core/src/component/foo.cc:18:1: internal
compiler error: in splice_child_die, at dwarf2out.c:5265

The code snippet is about as minimal as I can get it and still reproduce the
error.  If I make the destructor non-virtual or get rid of the definition of
foo::name_str, the error disappears.

[Bug c++/80234] [7 Regression] ICE in splice_child_die at dwarfout.c:5265

2017-03-28 Thread mpolacek at gcc dot gnu.org

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-28
 CC||jakub at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Target Milestone|--- |7.0
Summary|ICE in splice_child_die at  |[7 Regression] ICE in
   |dwarfout.c:5265 |splice_child_die at
   ||dwarfout.c:5265
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r241753.

[Bug fortran/80235] New: ICE: coarrays, submodule

2017-03-28 Thread mexas at bristol dot ac.uk

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

Bug ID: 80235
   Summary: ICE: coarrays, submodule
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mexas at bristol dot ac.uk
  Target Milestone: ---

Created attachment 41063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41063&action=edit
module file

$ caf -c m.f90 
$ caf -c sm.f90 
sm.f90:22:0:

 maxfe = size( cgca_pfem_centroid_tmp%r, dim=2 )

internal compiler error: Segmentation fault

m.f90 - module, sm.f90 - submodule, both attached.

[Bug fortran/80235] ICE: coarrays, submodule

2017-03-28 Thread mexas at bristol dot ac.uk

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

--- Comment #1 from Anton Shterenlikht  ---
Created attachment 41064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41064&action=edit
submodule file

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.3.1
   Target Milestone|--- |7.0
Summary|10% performance drop in |[7 Regression] 10%
   |SciMark2 LU after r242550   |performance drop in
   ||SciMark2 LU after r242550

--- Comment #12 from Richard Biener  ---
On more recent trunk -fno-split-paths makes only a tiny difference (4882 vs.
4779 Mflops) while -ftree-loop-if-convert still results in 5432 Mflops.  GCC 6
scores 5523 Mflops for me (-O3 -march=native on a Broadwell CPU).

Marking as regression.

[Bug fortran/80235] ICE: coarrays, submodule

2017-03-28 Thread mexas at bristol dot ac.uk

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

--- Comment #2 from Anton Shterenlikht  ---
Can be triggered also with gfortran7 directly:

$ gfortran7 -c -fcoarray=lib m.f90
$ gfortran7 -c -fcoarray=lib sm.f90
sm.f90:22:0:

 maxfe = size( cgca_pfem_centroid_tmp%r, dim=2 )

internal compiler error: Segmentation fault

[Bug c++/80236] New: ARM NEON: Crash in std::map

2017-03-28 Thread d...@dominik-schmidt.de

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

Bug ID: 80236
   Summary: ARM NEON: Crash in std::map
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: d...@dominik-schmidt.de
  Target Milestone: ---

Created attachment 41065
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41065&action=edit
part 1 of minimal example

Hey,

we are facing a crash when compiling the attached cpp files with:

`arm-oe-linux-gnueabi-g++   -march=armv7ve -marm -mfpu=neon-vfpv4 
-mfloat-abi=hard -mcpu=cortex-a7
--sysroot=/home/build/openembedded_sdk/tmp/sysroots/raspberrypi3 -O0 ../bar.cpp
../main.cpp  -o crashTest`
The crash only happens with optimizations disabled, it already doesn't happen 
anymore with `-O1`.
Also we could not trigger the faulty behavior in a single file, so this example
is really the bare minimum we could find.

gcc is installed from openembedded standard repository in version 6.3.0. Full
`--version --verbose` output is provided via attachments.
We could also reproduce this for another ARM target with GCC 5.4. I'm currently
lacking more information on that myself, but I will try to provide it later on.

The bt for 6.3 looks like this:
(gdb) run
Starting program: /tmp/crashTest 

Program received signal SIGSEGV, Segmentation fault.
0x000121bc in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair const&)
()
(gdb) bt
#0  0x000121bc in void
__gnu_cxx::new_allocator >
>::construct, std::pair
const&>(std::pair*, std::pair const&) ()
#1  0x000120e0 in void
std::allocator_traits > > >::construct, std::pair const&>(std::allocator
> >&, std::pair*, std::pair const&) ()
#2  0x00011ffc in void std::_Rb_tree,
std::_Select1st >, std::less,
std::allocator >
>::_M_construct_node
const&>(std::_Rb_tree_node >*, std::pair const&) ()
#3  0x00011df0 in std::_Rb_tree_node >*
std::_Rb_tree, std::_Select1st >, std::less, std::allocator >
>::_M_create_node const&>(std::pair const&) ()
#4  0x00011c0c in std::_Rb_tree_node >*
std::_Rb_tree, std::_Select1st >, std::less, std::allocator >
>::_Alloc_node::operator() const&>(std::pair const&) const ()
#5  0x00011728 in std::_Rb_tree_iterator >
std::_Rb_tree, std::_Select1st >, std::less, std::allocator >
>::_M_insert_ const&, std::_Rb_tree, std::_Select1st >,
std::less, std::allocator >
>::_Alloc_node>(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*,
std::pair const&, std::_Rb_tree, std::_Select1st >, std::less,
std::allocator > >::_Alloc_node&) ()
#6  0x00010f7c in std::_Rb_tree_iterator >
std::_Rb_tree, std::_Select1st >, std::less, std::allocator >
>::_M_insert_unique_ const&, std::_Rb_tree, std::_Select1st >,
std::less, std::allocator >
>::_Alloc_node>(std::_Rb_tree_const_iterator >,
std::pair const&, std::_Rb_tree, std::_Select1st >, std::less,
std::allocator > >::_Alloc_node&) ()
#7  0x00010c8c in void std::_Rb_tree,
std::_Select1st >, std::less,
std::allocator > >::_M_insert_unique const*>(std::pair const*, std::pair const*) ()
#8  0x00010a90 in std::map,
std::allocator >
>::map(std::initializer_list >, std::less
const&, std::allocator > const&) ()
#9  0x0001227c in main ()

[Bug c++/80236] ARM NEON: Crash in std::map

2017-03-28 Thread d...@dominik-schmidt.de

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

--- Comment #1 from Dominik Schmidt  ---
Created attachment 41066
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41066&action=edit
part 2 of minimal example: bar.cpp

[Bug c++/80236] ARM NEON: Crash in std::map

2017-03-28 Thread d...@dominik-schmidt.de

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

--- Comment #2 from Dominik Schmidt  ---
Created attachment 41067
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41067&action=edit
g++ --version --verbose

[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled

2017-03-28 Thread rguenth at gcc dot gnu.org

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

--- Comment #18 from Richard Biener  ---
(In reply to Thomas Preud'homme from comment #17)
> (In reply to rguent...@suse.de from comment #16)
> > On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote:
> > > 
> > > Funnily this led back to the Cortex-M0+ reduced testcase. With the patch 
> > > in
> > > comment #13 applied we can still see a difference in the push (one 
> > > register
> > > pushed Vs 0).
> > 
> > I can't reproduce zero pushes here I get three with/without 
> > -fno-code-hoisting.  code hoisting hoists the two loads inside
> > the switch before it so we have
> 
> Ooops my apologize, it needs more flags indeed. -O2 -funroll-all-loops shows
> 2 registers pushed Vs 1 when -fno-code-hoisting is added.

Still can't reproduce.  I've configured with

/space/rguenther/src/svn/gcc-7-branch/configure --target=arm-suse-linux-gnueabi
--disable-libstdcxx-pch --enable-languages=c,c++

and am using

./cc1 -quiet cortex-m0plus_reproducer.c -O2 -mcpu=cortex-m0plus -mthumb -I
include  -fdump-tree-pre-details -fdump-tree-crited  -fdump-tree-all
-funroll-all-loops -fno-code-hoisting

seeing 3 pushes:

fn1:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
movsr3, #0
push{r4, r5, lr}

I see softfp being used, not sure how I could change that (if that's what I'm
missing).  Btw, -funroll-all-loops disqualifies this testcase ;)

[Bug c++/80095] [5/6/7 Regression] ICE with this pointer in NSDMI

2017-03-28 Thread mpolacek at gcc dot gnu.org

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
In store_init_value, we have

decl: a
type: const struct A &
value: D.2291.p = (void *) &;, (const struct A &)
&D.2291;

but because type isn't CLASS_TYPE_P, we're not calling replace_placeholders.

We cannot just call replace_placeholders, that would crash, because obj has
type "const struct A &" whereas *t is "".

[Bug c++/80236] ARM NEON: Crash in std::map

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-28
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Usually this happens when you return a reference to an automatic variable thus
invalidly extend an objects lifetime after destruction.

Did you try -fsanitize=address or -fsanitize=undefined?

[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled

2017-03-28 Thread thopre01 at gcc dot gnu.org

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

--- Comment #19 from Thomas Preud'homme  ---
(In reply to Richard Biener from comment #18)
> (In reply to Thomas Preud'homme from comment #17)
> > (In reply to rguent...@suse.de from comment #16)
> > > On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote:
> > > > 
> > > > Funnily this led back to the Cortex-M0+ reduced testcase. With the 
> > > > patch in
> > > > comment #13 applied we can still see a difference in the push (one 
> > > > register
> > > > pushed Vs 0).
> > > 
> > > I can't reproduce zero pushes here I get three with/without 
> > > -fno-code-hoisting.  code hoisting hoists the two loads inside
> > > the switch before it so we have
> > 
> > Ooops my apologize, it needs more flags indeed. -O2 -funroll-all-loops shows
> > 2 registers pushed Vs 1 when -fno-code-hoisting is added.
> 
> Still can't reproduce.  I've configured with
> 
> /space/rguenther/src/svn/gcc-7-branch/configure
> --target=arm-suse-linux-gnueabi --disable-libstdcxx-pch
> --enable-languages=c,c++
> 
> and am using
> 
> ./cc1 -quiet cortex-m0plus_reproducer.c -O2 -mcpu=cortex-m0plus -mthumb -I
> include  -fdump-tree-pre-details -fdump-tree-crited  -fdump-tree-all
> -funroll-all-loops -fno-code-hoisting

Oh my bad, I was still not clear enough. I meant using the Cortex-M0+ testcase
but build it for Cortex-M7. Hopefully with -mcpu=cortex-m7 you should see a
difference between with and without code hoisting.

[Bug debug/80234] [7 Regression] ICE in splice_child_die at dwarfout.c:5265

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
  Component|c++ |debug

[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled

2017-03-28 Thread rguenth at gcc dot gnu.org

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

--- Comment #20 from Richard Biener  ---
(In reply to Thomas Preud'homme from comment #19)
> (In reply to Richard Biener from comment #18)
> > (In reply to Thomas Preud'homme from comment #17)
> > > (In reply to rguent...@suse.de from comment #16)
> > > > On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote:
> > > > > 
> > > > > Funnily this led back to the Cortex-M0+ reduced testcase. With the 
> > > > > patch in
> > > > > comment #13 applied we can still see a difference in the push (one 
> > > > > register
> > > > > pushed Vs 0).
> > > > 
> > > > I can't reproduce zero pushes here I get three with/without 
> > > > -fno-code-hoisting.  code hoisting hoists the two loads inside
> > > > the switch before it so we have
> > > 
> > > Ooops my apologize, it needs more flags indeed. -O2 -funroll-all-loops 
> > > shows
> > > 2 registers pushed Vs 1 when -fno-code-hoisting is added.
> > 
> > Still can't reproduce.  I've configured with
> > 
> > /space/rguenther/src/svn/gcc-7-branch/configure
> > --target=arm-suse-linux-gnueabi --disable-libstdcxx-pch
> > --enable-languages=c,c++
> > 
> > and am using
> > 
> > ./cc1 -quiet cortex-m0plus_reproducer.c -O2 -mcpu=cortex-m0plus -mthumb -I
> > include  -fdump-tree-pre-details -fdump-tree-crited  -fdump-tree-all
> > -funroll-all-loops -fno-code-hoisting
> 
> Oh my bad, I was still not clear enough. I meant using the Cortex-M0+
> testcase but build it for Cortex-M7. Hopefully with -mcpu=cortex-m7 you
> should see a difference between with and without code hoisting.

I do.  Two pushes with code hoisting and three without.  Changed -mcpu above
to -mcpu=cortex-m7.

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

2017-03-28 Thread rguenth at gcc dot gnu.org

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Tue Mar 28 13:57:43 2017
New Revision: 246534

URL: https://gcc.gnu.org/viewcvs?rev=246534&root=gcc&view=rev
Log:
2017-03-28  Richard Biener  

PR tree-optimization/78644
* tree-ssa-ccp.c (evaluate_stmt): When we may not use the value
of a simplification result we may not use it at all.

* gcc.dg/pr78644-1.c: New testcase.
* gcc.dg/pr78644-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/pr78644-1.c
trunk/gcc/testsuite/gcc.dg/pr78644-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug tree-optimization/78542] [6 Regression] wrong code at -Og results in endless loop

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Bug 78644 Summary: [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og 
-fipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78644

   What|Removed |Added

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

[Bug ipa/78644] [7 Regression] ICE: SIGSEGV in is_gimple_reg_type with -Og -fipa-cp

2017-03-28 Thread rguenth at gcc dot gnu.org

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
Fixed.

[Bug ada/80117] Standard'Word_Size is wrong for aarch64 ILP32

2017-03-28 Thread schwab at gcc dot gnu.org

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

--- Comment #17 from Andreas Schwab  ---
Author: schwab
Date: Tue Mar 28 14:22:29 2017
New Revision: 246536

URL: https://gcc.gnu.org/viewcvs?rev=246536&root=gcc&view=rev
Log:
Backport "Support for Ada on aarch64 with -mabi=ilp32" from trunk

PR ada/80117
* system-linux-aarch64-ilp32.ads: New file.
* gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS_COMMON): Rename
from LIBGNAT_TARGET_PAIRS.
(LIBGNAT_TARGET_PAIRS_32, LIBGNAT_TARGET_PAIRS_64): Define.
(LIBGNAT_TARGET_PAIRS): Use LIBGNAT_TARGET_PAIRS_COMMON, and
LIBGNAT_TARGET_PAIRS_64 or LIBGNAT_TARGET_PAIRS_32 for -mabi=lp64
or -mabi=ilp32, resp.

Added:
branches/gcc-6-branch/gcc/ada/system-linux-aarch64-ilp32.ads
Modified:
branches/gcc-6-branch/gcc/ada/ChangeLog
branches/gcc-6-branch/gcc/ada/gcc-interface/Makefile.in

[Bug target/80225] ICE when using =@cc output operand incorrectly

2017-03-28 Thread jwjagersma at gmail dot com

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

jwjagersma at gmail dot com changed:

   What|Removed |Added

 Target|x86_64-w64-mingw32  |x86_64-w64-mingw32,
   ||i686-w64-mingw32,
   ||i586-pc-msdosdjgpp

--- Comment #1 from jwjagersma at gmail dot com ---
I should mention I also reproduced this issue on i686-w64-mingw32 and
i586-pc-msdosdjgpp (where I first encountered it).
Since the error occurs in a function called "print_reg", I imagine this would
be reproducible on any x86/amd64 target, as the flags register doesn't have a
printable name.

[Bug c++/80236] ARM NEON: Crash in std::map

2017-03-28 Thread d...@dominik-schmidt.de

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

--- Comment #4 from Dominik Schmidt  ---
AddressSanitizer output:

=
==597==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7e842bd0 at
pc 0x00013d20 bp 0x7e8428dc sp 0x7e8428d4
READ of size 16 at 0x7e842bd0 thread T0
#0 0x13d1f in void
__gnu_cxx::new_allocator >
>::construct, std::pair
const&>(std::pair*, std::pair const&)
(/tmp/crashTest+0x13d1f)
#1 0x13b0f in void
std::allocator_traits > > >::construct, std::pair const&>(std::allocator
> >&, std::pair*, std::pair const&)
(/tmp/crashTest+0x13b0f)
#2 0x13a27 in void std::_Rb_tree,
std::_Select1st >, std::less,
std::allocator >
>::_M_construct_node
const&>(std::_Rb_tree_node >*, std::pair const&) (/tmp/crashTest+0x13a27)
#3 0x1381b in std::_Rb_tree_node >*
std::_Rb_tree, std::_Select1st >, std::less, std::allocator >
>::_M_create_node const&>(std::pair const&) (/tmp/crashTest+0x1381b)
#4 0x1352f in std::_Rb_tree_node >*
std::_Rb_tree, std::_Select1st >, std::less, std::allocator >
>::_Alloc_node::operator() const&>(std::pair const&) const (/tmp/crashTest+0x1352f)
#5 0x12b23 in std::_Rb_tree_iterator >
std::_Rb_tree, std::_Select1st >, std::less, std::allocator >
>::_M_insert_ const&, std::_Rb_tree, std::_Select1st >,
std::less, std::allocator >
>::_Alloc_node>(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*,
std::pair const&, std::_Rb_tree, std::_Select1st >, std::less,
std::allocator > >::_Alloc_node&)
(/tmp/crashTest+0x12b23)
#6 0x11953 in std::_Rb_tree_iterator >
std::_Rb_tree, std::_Select1st >, std::less, std::allocator >
>::_M_insert_unique_ const&, std::_Rb_tree, std::_Select1st >,
std::less, std::allocator >
>::_Alloc_node>(std::_Rb_tree_const_iterator >,
std::pair const&, std::_Rb_tree, std::_Select1st >, std::less,
std::allocator > >::_Alloc_node&)
(/tmp/crashTest+0x11953)
#7 0x11337 in void std::_Rb_tree,
std::_Select1st >, std::less,
std::allocator > >::_M_insert_unique const*>(std::pair const*, std::pair const*) (/tmp/crashTest+0x11337)
#8 0x110a7 in std::map,
std::allocator >
>::map(std::initializer_list >, std::less
const&, std::allocator > const&)
(/tmp/crashTest+0x110a7)
#9 0x13e87 in main (/tmp/crashTest+0x13e87)
#10 0x766cb83f in __libc_start_main
(/test/crosscan-test/lib/libc.so.6+0x1683f)

Address 0x7e842bd0 is located in stack of thread T0 at offset 112 in frame
#0 0x13d8f in main (/tmp/crashTest+0x13d8f)

  This frame has 2 object(s):
[32, 56) 'j1'
[96, 120) 'j3' <== Memory access at offset 112 partially overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/tmp/crashTest+0x13d1f) in
void __gnu_cxx::new_allocator >
>::construct, std::pair
const&>(std::pair*, std::pair const&)
Shadow bytes around the buggy address:
  0x2fd08520: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd08530: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x2fd08540: 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x2fd08550: 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4 f3 f3 f3 f3
  0x2fd08560: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
=>0x2fd08570: 00 00 00 f4 f2 f2 f2 f2 00 00[00]f4 f3 f3 f3 f3
  0x2fd08580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd08590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd085a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd085b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd085c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==597==ABORTING

[Bug c++/80236] ARM NEON: Crash in std::map

2017-03-28 Thread d...@dominik-schmidt.de

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

--- Comment #5 from Dominik Schmidt  ---
-fsanitize=undefined does not make any difference.

[Bug c++/80236] ARM NEON: Crash in std::map

2017-03-28 Thread redi at gcc dot gnu.org

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

--- Comment #6 from Jonathan Wakely  ---
Are you using the right libstdc++.so that matches the gcc 6.3.0 compiler?

What does "ldd /tmp/crashTest" show?

[Bug c++/80236] ARM NEON: Crash in std::map

2017-03-28 Thread redi at gcc dot gnu.org

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

--- Comment #7 from Jonathan Wakely  ---
Also please build with -g so the backtraces and stack info are more useful.

[Bug c++/70387] -fnon-call-exceptions has no effect

2017-03-28 Thread jwjagersma at gmail dot com

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

--- Comment #5 from jwjagersma at gmail dot com ---
Bumping this, I hope it will be resolved someday.
I found a reference to the same issue, with another test case using posix
signal handlers:
https://cygwin.com/ml/cygwin/2010-07/msg00195.html
This claims it used to work on 3.3.4, and failed from 4.3.4 on.

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

2017-03-28 Thread msebor at gcc dot gnu.org

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

--- Comment #11 from Martin Sebor  ---
That would work too.  Yet another possibility is to surround all the dg-message
directives that apply to the same line in a pair of new directives (analogously
to dg-{begin,end}-multiline-output):

foobar;
/* { dg-begin-same-line-output .-1 }
   ...
   { dg-warning "warning for foobar" }
   ...
   { dg-message "note for foobar" }
   ...
   { dg-error "error for foobar" }
   ...
   { dg-end-same-line-output }  */

[Bug tree-optimization/80218] [6/7 Regression] tree-call-cdce does not update block frequencies

2017-03-28 Thread law at gcc dot gnu.org

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Tue Mar 28 15:14:36 2017
New Revision: 246538

URL: https://gcc.gnu.org/viewcvs?rev=246538&root=gcc&view=rev
Log:
gcc/
PR tree-optimization/80218
* tree-call-cdce.c (shrink_wrap_one_built_in_call_with_conds):
Update block frequencies and counts.

gcc/testsuite/
PR tree-optimization/80218
* gcc.dg/pr80218.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr80218.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-call-cdce.c

[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include

2017-03-28 Thread redi at gcc dot gnu.org

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

--- Comment #22 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #20)
> Also, I assume this is only a problem for -std=c++98 or -std=gnu++98,
> because if the system headers don't declare those functions for C++11 and
> later dialects then that's a bug in those system headers.

That's not true, because we (rather bizarrely) do this:

#if _GLIBCXX_HAVE_WCSTOF
#undef wcstof
#endif

namespace std {
#if _GLIBCXX_HAVE_WCSTOF
using ::wcstof
#endif
}

#if __cplusplus >= 201103L
namespace std {
#if _GLIBCXX_HAVE_WCSTOF
using std::wcstof
#endif
}
#endif

This means we unconditionally try to declare them in namespace std, then for
C++11 redeclare std::wcstof as std:wcstof (???).

[Bug target/24012] [5/6/7 regression] #define _POSIX_C_SOURCE breaks #include

2017-03-28 Thread redi at gcc dot gnu.org

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

--- Comment #23 from Jonathan Wakely  ---
Created attachment 41068
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41068&action=edit
Use dynamic checks for C99  functions

This fixes it and passes the testsuite on GNU/Linux and FreeBSD 11.0-RELEASE.

Even though this bug is a regression, this is too late in the gcc-7 process to
make a change like this. I'll commit it early for gcc-8 and backport it if it
doesn't cause any problems.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

2017-03-28 Thread jvdelisle at gcc dot gnu.org

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

--- Comment #18 from Jerry DeLisle  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #17)
> 
> ro@colima 27 >
> LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs
> ./dtio_26.exe 
> 
> 
> 
> Program aborted. Backtrace:
> Abort

I am sorry, I was not being clear. There are four similar lines that need to
replace abort with the print. We are invoking the Fortran ABORT procedure when
ever a test condition is not met. So I need to see what the condition is saved
in the iomsg variable and which line without aborting.

So something like this in place of the lines starting at line 57:

  read(unit=10, fmt='(dt)', iostat=istat, iomsg=imsg) foo
  if (imsg.ne."End of record") print *, 57, imsg
  rewind(10)
  read(unit=10, fmt=*, iostat=istat, iomsg=imsg) foo
  if (imsg.ne."End of record") print *, 60, imsg
  s = "hello"
  read( unit=s, fmt='(dt)', iostat=istat, iomsg=imsg) foo
  if (imsg.ne."End of record") print *, 63, imsg
  read( unit=s, fmt=*, iostat=istat, iomsg=imsg) foo
  if (imsg.ne."End of record") print *, 65
end program p

[Bug c/80237] New: float to double conversion is not optimized away

2017-03-28 Thread nsz at gcc dot gnu.org

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

Bug ID: 80237
   Summary: float to double conversion is not optimized away
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nsz at gcc dot gnu.org
  Target Milestone: ---

i get suboptimal code for

__attribute__((noinline))
static float f(float x)
{
  return x*x;
}

static double g(float x)
{
  return x>0 ? f(x) : x+1.0;
}

float foo(float x)
{
  return g(x);
}

i expected a tail call because for float x, (float)(double)x conversion is a
nop, but with -O3 i get

f:
mulss   %xmm0, %xmm0
ret
foo:
ucomiss .LC0(%rip), %xmm0
jbe .L8
callf / why not tail call?
cvtss2sd%xmm0, %xmm0
cvtsd2ss%xmm0, %xmm0
ret
.L8:
cvtss2sd%xmm0, %xmm0
addsd   .LC1(%rip), %xmm0
cvtsd2ss%xmm0, %xmm0
ret
.LC0:
.long   0
.LC1:
.long   0
.long   1072693248

[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times

2017-03-28 Thread redi at gcc dot gnu.org

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Ah, I tried that but not halving the epsilon, and so got a different result
that I wasn't happy with.

I sugested _RealType(0) because if the analysis at
http://stackoverflow.com/a/25669510 is correct then the current code is biased
against 0, so using it when we round up to 1.0 would offset that, to a greater
or lesser extent. I don't know which :-)

I'll go with your suggestion, thanks.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

2017-03-28 Thread ro at CeBiTec dot Uni-Bielefeld.DE

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

--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #18 from Jerry DeLisle  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #17)
>> 
>> ro@colima 27 >
>> LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs
>> ./dtio_26.exe 
>> 
>> 
>> 
>> Program aborted. Backtrace:
>> Abort
>
> I am sorry, I was not being clear. There are four similar lines that need to
> replace abort with the print. We are invoking the Fortran ABORT procedure when
> ever a test condition is not met. So I need to see what the condition is saved
> in the iomsg variable and which line without aborting.

Ah, I see.

> So something like this in place of the lines starting at line 57:
[...]

Here's the output I get:

  63
  65
Rainer

[Bug target/80211] ICE in curr_insn_transform, at lra-constraints.c:3816

2017-03-28 Thread vmakarov at gcc dot gnu.org

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

--- Comment #1 from Vladimir Makarov  ---
I can not reproduce it.  With the mentioned options I have

warning: implicit declaration of function '__builtin_dfp_dtstsfi_ov'; did you
mean '__builtin_fpclassify`?

The option set has no sense for me too.  -mpower9-dform-vector  implements new
load insns for power9 but -mcpu=401 sets up an ancient ppc architecture.  They
are exclusive options.

Even if the bug is reproducable, the PR should be marked as P4, IMHO.

[Bug target/79671] [7 Regression] mapnik miscompilation on armv7hl since r235622

2017-03-28 Thread jason at gcc dot gnu.org

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

--- Comment #83 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #81)
> Boost 1.63 has an array of char.

Seems they should change that to unsigned char (or std::byte).

[Bug c++/80236] ARM NEON: Crash in std::map

2017-03-28 Thread d...@dominik-schmidt.de

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

--- Comment #8 from Dominik Schmidt  ---
-fsanitize=address -g:
==539==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ebcac10 at
pc 0x00013d20 bp 0x7ebca90c sp 0x7ebca904
READ of size 16 at 0x7ebcac10 thread T0
#0 0x13d1f in void
__gnu_cxx::new_allocator >
>::construct, std::pair
const&>(std::pair*, std::pair const&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/ext/new_allocator.h:120
#1 0x13b0f in void
std::allocator_traits > > >::construct, std::pair const&>(std::allocator
> >&, std::pair*, std::pair const&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/alloc_traits.h:455
#2 0x13a27 in void std::_Rb_tree,
std::_Select1st >, std::less,
std::allocator >
>::_M_construct_node
const&>(std::_Rb_tree_node >*, std::pair const&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:543
#3 0x1381b in std::_Rb_tree_node >*
std::_Rb_tree, std::_Select1st >, std::less, std::allocator >
>::_M_create_node const&>(std::pair const&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:560
#4 0x1352f in std::_Rb_tree_node >*
std::_Rb_tree, std::_Select1st >, std::less, std::allocator >
>::_Alloc_node::operator() const&>(std::pair const&) const
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:473
#5 0x12b23 in std::_Rb_tree_iterator >
std::_Rb_tree, std::_Select1st >, std::less, std::allocator >
>::_M_insert_ const&, std::_Rb_tree, std::_Select1st >,
std::less, std::allocator >
>::_Alloc_node>(std::_Rb_tree_node_base*, std::_Rb_tree_node_base*,
std::pair const&, std::_Rb_tree, std::_Select1st >, std::less,
std::allocator > >::_Alloc_node&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:1535
#6 0x11953 in std::_Rb_tree_iterator >
std::_Rb_tree, std::_Select1st >, std::less, std::allocator >
>::_M_insert_unique_ const&, std::_Rb_tree, std::_Select1st >,
std::less, std::allocator >
>::_Alloc_node>(std::_Rb_tree_const_iterator >,
std::pair const&, std::_Rb_tree, std::_Select1st >, std::less,
std::allocator > >::_Alloc_node&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:2004
#7 0x11337 in void std::_Rb_tree,
std::_Select1st >, std::less,
std::allocator > >::_M_insert_unique const*>(std::pair const*, std::pair const*)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_tree.h:2250
#8 0x110a7 in std::map,
std::allocator >
>::map(std::initializer_list >, std::less
const&, std::allocator > const&)
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/bits/stl_map.h:215
#9 0x13e87 in main ../main.cpp:15
#10 0x7670783f in __libc_start_main (/lib/libc.so.6+0x1683f)

Address 0x7ebcac10 is located in stack of thread T0 at offset 112 in frame
#0 0x13d8f in main ../main.cpp:11

  This frame has 2 object(s):
[32, 56) 'j1'
[96, 120) 'j3' <== Memory access at offset 112 partially overflows this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
/usr/local/oecore-x86_64/sysroots/cortexa7hf-neon-vfpv4-oe-linux-gnueabi/usr/include/c++/6.3.0/ext/new_allocator.h:120
in void __gnu_cxx::new_allocator > >::construct, std::pair const&>(std::pair*, std::pair
const&)
Shadow bytes around the buggy address:
  0x2fd79530: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd79540: f1 f1 f1 f1 00 f4 f4 f4 f3 f3 f3 f3 00 00 00 00
  0x2fd79550: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 04 f4 f4 f4
  0x2fd79560: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd79570: 00 00 00 00 f1 f1 f1 f1 00 00 00 f4 f2 f2 f2 f2
=>0x2fd79580: 00 00[00]f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
  0x2fd79590: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd795a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd795b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd795c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x2fd795d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Contain

[Bug libstdc++/80137] [6/7 Regression] std::generate_canonical calls its generator a non-constant number of times

2017-03-28 Thread redi at gcc dot gnu.org

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Tue Mar 28 16:09:49 2017
New Revision: 246542

URL: https://gcc.gnu.org/viewcvs?rev=246542&root=gcc&view=rev
Log:
PR libstdc++/80137 use std::nextafter instead of looping

PR libstdc++/80137
* include/bits/random.tcc (generate_canonical): Use std::nextafter
or numeric_limits::epsilon() to reduce out-of-range values.
* testsuite/26_numerics/random/uniform_real_distribution/operators/
64351.cc: Verify complexity requirement is met.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/random.tcc
   
trunk/libstdc++-v3/testsuite/26_numerics/random/uniform_real_distribution/operators/64351.cc

1 2 >

1 - 100 of 160 matches

Mail list logo