[Bug rtl-optimization/80197] pgo dramatically pessimizes scimark2 MonteCarlo benchmark

[rguenther at suse dot de]

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

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 28 Mar 2017, amonakov at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80197
> 
> --- Comment #5 from Alexander Monakov  ---
> On trunk, manually fixing up inlining is not enough: trunk additionally needs
> -fno-tracer, otherwise crucial if-conversion of 'if (k < 0) k += m1;' is
> prevented.

That means -ftracer has similar issues as path splitting.  -ftracer
simply looks for a path with high probability so supposedly the
distorted profile might be the reason for this?

[Bug tree-optimization/80248] New: sparse access to Array of structures does not vectorize

[vincenzo.innocente at cern dot ch]

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

Bug ID: 80248
   Summary: sparse access to Array of structures does not
vectorize
   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: ---

in the following example "aos" does not vectorize  while the equivalent aos2
does vectorize using vgatherdps instruction

On a slight different matter:
"soa" vectorizes and produces code that is apparently 20% faster than "aos2":
I may open a different PR with a benchmark attached...


cat simpleGather.cc
struct float3 {
  float x;
  float y;
  float z;
};

#define N 1024
float fx[N], g[N];
float fy[N];
float fz[N]; 
int k[N];

float3 f3[N];


void
aos (void)
{
  int i;
  for (i = 0; i < N; i++)
g[i] = f3[k[i]].x+f3[k[i]].y+f3[k[i]].z;
}


// use gather
void
aos2 (void)
{
  float * ff = &(f3[0].x);
  int i;
  for (i = 0; i < N; i++)
g[i] = ff[3*k[i]]+ff[3*k[i]+1]+ff[3*k[i]+2];
}


// use gather
void
soa (void)
{
  int i;
  for (i = 0; i < N; i++)
g[i] = fx[k[i]]+fy[k[i]]+fz[k[i]];
}

[innocent@vinavx3 vectorize]$ c++ -Ofast -Wall -march=haswell -S
simpleGather.cc -fopt-info-vec
simpleGather.cc:31:17: note: loop vectorized
simpleGather.cc:41:17: note: loop vectorized
[innocent@vinavx3 vectorize]$ c++ -v
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)

[Bug c++/80247] 'nullptr' was not declared in this scope

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Provide a testcase.  It works for me.  Testcase:

void *p = nullptr;

> g++-4.8 t.C -S -std=c++11

Note that GCC 4.8 is no longer maintained, please use at least GCC 5.4.

[Bug c++/80244] [6/7 Regression] ICE with attribute in template alias

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||5.4.1
   Target Milestone|--- |6.4
  Known to fail||6.1.0

[Bug c++/80241] [5/6/7 Regression] Broken error message + ICE with invalid attribute

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery
   Priority|P3  |P2

[Bug target/80239] [7 regression] 9% regression on dhrystone when targetting Cortex-M7

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Testcase?

[Bug c++/80238] genmatch.c:(.text.startup+0x66c6): undefined reference to `operator delete(void*, unsigned long)'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Target||x86_64-linux
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-29
Version|unknown |6.3.0
 Ever confirmed|0   |1

[Bug libstdc++/68397] std::tr1::expint fails in __expint_En_cont_frac for some long double arguments due to low __max_iter value

[3dw4rd at verizon dot net]

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

--- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
I concur with this solution.
I can make a patch.

[Bug c++/80247] 'nullptr' was not declared in this scope

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Sumit from comment #0)
> I am migrating my code from 3.4.5 to 4.8.1 and enabled c++11 using

Why would you choose 4.8.1 and not 4.8.5 ? There are lots of bug fixes in later
4.8.x releases, especially if you're trying to use C++11 (which was not fully
supported by GCC 4.8.x and so labelled experimental, and under heavy
development with lots of fixes in later releases).

> -std=C++11

The correct option is -std=c++11 not -std=C++11

[Bug c++/80240] cannot dynamic_cast variable to intmax_t from variable of type intmax_t

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
http://en.cppreference.com/w/cpp/language/dynamic_cast

Please stop reporting a bug every time your code doesn't compile.

[Bug c++/80243] c++ doesn't allow function to return a struct (or object?) - same thing

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jim Michaels from comment #0)
> c++ doesn't allow function to return a struct.

Of course it does.

Please stop reporting a bug every time your code doesn't compile, or you
misunderstand how C++ works.

[Bug tree-optimization/80237] float to double conversion is not optimized away

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-29
  Component|c   |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
We have (after inlining g into foo):

foo (float x)
{
  float _3;
  float _4;
  double iftmp.0_5;
  double _6;
  double iftmp.0_7;
  double iftmp.0_8;

   [100.00%]:
  if (x_2(D) > 0.0)
goto ; [60.23%]
  else
goto ; [39.77%]

   [60.23%]:
  _3 = f (x_2(D));
  iftmp.0_5 = (double) _3;
  goto ; [100.00%]

   [39.77%]:
  _6 = (double) x_2(D);
  iftmp.0_7 = _6 + 1.0e+0;

   [100.00%]:
  # iftmp.0_8 = PHI 
  _4 = (float) iftmp.0_8;
  return _4;

thus the tailcall is not exposed at GIMPLE level.

For the above we fail to optimize the partial redundancy of the conversion
in PRE.  During phi translation we do see that _4 is equal to _3 on the
3->5 edge but phi translation fails because _3 is not antic-in in bb 5.
Not really relevant, I think the check is somewhat bogus.  With that fixed
we do detect the tailcall:

   [100.00%]:
  if (x_2(D) > 0.0)
goto ; [60.23%]
  else
goto ; [39.77%]

   [60.23%]:
  _3 = f (x_2(D)); [tail call]
  goto ; [100.00%]

   [39.77%]:
  _6 = (double) x_2(D);
  iftmp.0_7 = _6 + 1.0e+0;
  _9 = (float) iftmp.0_7;

   [100.00%]:
  # prephitmp_10 = PHI <_3(3), _9(4)>
  return prephitmp_10;

foo:
.LFB2:
.cfi_startproc
ucomiss .LC0(%rip), %xmm0
jbe .L7
jmp f
.p2align 4,,10
.p2align 3
.L7:
cvtss2sd%xmm0, %xmm0
addsd   .LC1(%rip), %xmm0
cvtsd2ss%xmm0, %xmm0
ret

Mine.

[Bug c++/80247] 'nullptr' was not declared in this scope

[sbansal at ciena dot com]

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

--- Comment #3 from Sumit  ---
(In reply to Richard Biener from comment #1)
> Provide a testcase.  It works for me.  Testcase:
> 
> void *p = nullptr;
> 
> > g++-4.8 t.C -S -std=c++11
> 
> Note that GCC 4.8 is no longer maintained, please use at least GCC 5.4.

The use case is :

060 class string_ref {
061  public:
062   // types
063   typedef const char* const_iterator;
064   typedef std::reverse_iterator const_reverse_iterator;
065 
066   // constants
067   const static size_t npos;
068 
069   // construct/copy.
070   string_ref() : data_(nullptr), length_(0) {}

[Bug c++/80247] 'nullptr' was not declared in this scope

[sbansal at ciena dot com]

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

--- Comment #4 from Sumit  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Sumit from comment #0)
> > I am migrating my code from 3.4.5 to 4.8.1 and enabled c++11 using
> 
> Why would you choose 4.8.1 and not 4.8.5 ? There are lots of bug fixes in
> later 4.8.x releases, especially if you're trying to use C++11 (which was
> not fully supported by GCC 4.8.x and so labelled experimental, and under
> heavy development with lots of fixes in later releases).
> 
> > -std=C++11
> 
> The correct option is -std=c++11 not -std=C++11

Yes, I am using -std=c++11.

Actually, we need to use 4.8.1 specifically. Do we have the list of C++11
patches based upon 4.8.5 which we can apply upon 4.8.1

[Bug c++/80247] 'nullptr' was not declared in this scope

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to Sumit from comment #4)
> (In reply to Jonathan Wakely from comment #2)
> > (In reply to Sumit from comment #0)
> > > I am migrating my code from 3.4.5 to 4.8.1 and enabled c++11 using
> > 
> > Why would you choose 4.8.1 and not 4.8.5 ? There are lots of bug fixes in
> > later 4.8.x releases, especially if you're trying to use C++11 (which was
> > not fully supported by GCC 4.8.x and so labelled experimental, and under
> > heavy development with lots of fixes in later releases).
> > 
> > > -std=C++11
> > 
> > The correct option is -std=c++11 not -std=C++11
> 
> Yes, I am using -std=c++11.
> 
> Actually, we need to use 4.8.1 specifically. Do we have the list of C++11
> patches based upon 4.8.5 which we can apply upon 4.8.1

Sorry, but then you are on your own.

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

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|7.0 |6.4

--- Comment #18 from Eric Botcazou  ---
Thanks.

[Bug target/80239] [7 regression] 9% regression on dhrystone when targetting Cortex-M7

[thopre01 at gcc dot gnu.org]

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

--- Comment #5 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #1)
> 
> I believe the problem is that the equivalence stays with NO_REGS as register
> class instead of being given that of a register (since it's going to be
> reloaded into a register). My patch follows that path and as said above
> works just after r235184 but the performance remains worse on recent trunk.
> 
> When looking at code generated by recent trunk, the issue mentionned in the
> original post is not there which suggest that something else is at play.

I bisect this issue down to r239561 and reverting that commit on top of current
trunk is enough to bring the performance back up. I'll still push the patch I
mentioned above forward but given the circumstances I will wait for GCC 8 stage
1 for doing so.

I'll post a testcase of the issue as soon as I have understood what is the
source of the slowdown with r239561 in current trunk.

[Bug libstdc++/68397] std::tr1::expint fails in __expint_En_cont_frac for some long double arguments due to low __max_iter value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-29
 Ever confirmed|0   |1

[Bug libstdc++/68397] std::tr1::expint fails in __expint_En_cont_frac for some long double arguments due to low __max_iter value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|trivial |normal

[Bug c++/80243] c++ doesn't allow function to return a struct (or object?) - same thing

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Your second example doesn't compile for a very simple reason:

(In reply to Jim Michaels from comment #1)
> #include 
> #include 
> typedef struct {std::string s;int i;} Structsb;
> Structsb fn(std::string s1, int i1) {
> return {s1,i1};
> }
> int main() {}

I'm guessing you didn't mean to put a closing brace here?

> Structsb structsb=fn("string",1);
> return strustsb.i;
> }

Do you see what I mean about reporting bugs every time your code doesn't
compile? This is a simple mistake, not a bug in GCC. Stop assuming everything
is a bug in GCC, which has hundreds of thousands of hours of development and
testing by very talented people who understand C++ very well. If something
trivial like returning a struct didn't work somebody would have noticed before
you did. You're not the only user of GCC.

[Bug tree-optimization/79534] [7 Regression] tree-ifcombine aarch64 performance regression with trunk@245151

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-29
 Ever confirmed|0   |1

--- Comment #5 from James Greenhalgh  ---
It is always helpful to provide the full command line and configuration used,
along with rough details of the platform you are using.

Compiling with:

  gcc -O3 -mcpu=cortex-a57

I can see the performance difference reported here when running on Cortex-A57,
Cortex-A72 and Cortex-A53 based systems, while with:

  gcc -O3

(i.e. using the generic tuning structures) I see no meaningful performance
differences across multiple microarchitectures.

So, confirmed. Though this is more likely to be a deficiency in the heuristics
in the back-end ifcvt cost model than a regression directly introduced by
Honza's patch.

[Bug c++/80244] [6/7 Regression] ICE with attribute in template alias

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-29
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r222530.

[Bug tree-optimization/80249] New: Failed to build SPEC 2006 483.xalancbmk with -fdump-tree-fre

[sudi.das at arm dot com]

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

Bug ID: 80249
   Summary: Failed to build SPEC 2006 483.xalancbmk with
-fdump-tree-fre
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sudi.das at arm dot com
  Target Milestone: ---

Created attachment 41071
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41071&action=edit
Reduced testcase

An ICE occurs while building 483.xalancbmk in SPEC2006 with the flag
-fdump-tree-fre (while compiling TokenFactory.cpp)

The attached test case has been reduced from it. It fails with both x86-64 and
AArch64 with the following command :

g++ -O3 -fdump-tree-fre reduced.cpp

reduced.cpp: In member function 'xercesc_2_5::Token*
xercesc_2_5::TokenFactory::getGraphemePattern()':
reduced.cpp:91:8: internal compiler error: in
dump_possible_polymorphic_call_targets, at ipa-devirt.c:3370
 Token* TokenFactory::getGraphemePattern() {
^~~~
0xb6eb3e dump_possible_polymorphic_call_targets(_IO_FILE*, tree_node*, long,
ipa_polymorphic_call_context const&)
/src/gcc/gcc/ipa-devirt.c:3370
0xf45739 eliminate_dom_walker::before_dom_children(basic_block_def*)
/src/gcc/gcc/tree-ssa-pre.c:4607
0x138620e dom_walker::walk(basic_block_def*)
/src/gcc/gcc/domwalk.c:265
0xf466f7 eliminate
/src/gcc/gcc/tree-ssa-pre.c:4763
0xf469b3 execute
/src/gcc/gcc/tree-ssa-pre.c:5197

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

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 CC||jiwang at gcc dot gnu.org

--- Comment #22 from Jiong Wang  ---
(In reply to Rainer Orth from comment #15)
> The new testcase FAILs on 64-bit Solaris/SPARC:

+ AArch64


> 
> +FAIL: gfortran.dg/dtio_26.f03   -O0  execution test
> +FAIL: gfortran.dg/dtio_26.f03   -O1  execution test
> +FAIL: gfortran.dg/dtio_26.f03   -O2  execution test
> +FAIL: gfortran.dg/dtio_26.f03   -O3 -fomit-frame-pointer -funroll-loops
> -fpeel-loops -ftracer -finline-functions  execution test
> +FAIL: gfortran.dg/dtio_26.f03   -O3 -g  execution test
> +FAIL: gfortran.dg/dtio_26.f03   -Os  execution test
> 
> Thread 2 received signal SIGABRT, Aborted.
> [Switching to Thread 1 (LWP 1)]
> 0x7f0e6920 in __lwp_sigqueue () from /lib/64/libc.so.1
> (gdb) where
> #0  0x7f0e6920 in __lwp_sigqueue () from /lib/64/libc.so.1
> #1  0x7f02949c in raise () from /lib/64/libc.so.1
> #2  0x7eff8174 in abort () from /lib/64/libc.so.1
> #3  0x2d039dc4 in _gfortrani_sys_abort ()
> at /vol/gcc/src/hg/trunk/local/libgfortran/runtime/error.c:180
> #4  0x2d11840c in _gfortran_abort ()
> at /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:32
> #5  0x0001236c in p ()
> at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/dtio_26.f03:64
> #6  0x000124d8 in main (argc=1, argv=0x784c)
> at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/dtio_26.f03:46
> #7  0x000114ac in _start ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> #5  0x0001236c in p ()
> at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/dtio_26.f03:64
> 64if (imsg.ne."End of record") call abort
> (gdb) p imsg
> $1 = ' ' 
> 
>   Rainer

[Bug target/80250] New: ICE in in final_scan_insn, at final.c:3025 for __builtin_ia32_vp4dpwssds_mask builtin

[marxin at gcc dot gnu.org]

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

Bug ID: 80250
   Summary: ICE in in final_scan_insn, at final.c:3025 for
__builtin_ia32_vp4dpwssds_mask builtin
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following test-case ICEs:

$ cat ice.i
typedef int a __attribute__ ((__vector_size__ (64)));
__attribute__ ((__vector_size__ (16 * sizeof (float int b ();
#pragma GCC target "avx5124vnniw"
a
c ()
{
  long *d;
  a e;
  a f;
  a g;
  a h;
  a i;
  short j = 0;
  return __builtin_ia32_vp4dpwssds_mask (h, g, f, e, i, 0, b (), j);
}

$ gcc -O1 -fno-dce ice.i
ice.i: In function ‘c’:
ice.i:15:1: error: could not split insn
 }
 ^
(insn 28 27 8 2 (set (reg:V64SI 25 xmm4 [orig:94 h ] [94])
(const_vector:V64SI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
])) "ice.i":14 4934 {movv64si}
 (expr_list:REG_UNUSED (reg:V64SI 25 xmm4 [orig:94 h ] [94])
(nil)))
ice.i:15:1: internal compiler error: in final_scan_insn, at final.c:3025
0xbab5a8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:108
0x8fac70 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/final.c:3025
0x8faf62 final(rtx_insn*, _IO_FILE*, int)
../../gcc/final.c:2051
0x8fb719 rest_of_handle_final
../../gcc/final.c:4489
0x8fb719 execute
../../gcc/final.c:4562

[Bug target/80250] ICE in in final_scan_insn, at final.c:3025 for __builtin_ia32_vp4dpwssds_mask builtin

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Started with r242569.

[Bug tree-optimization/80248] sparse access to Array of structures does not vectorize using gathers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-29
 CC||jakub at gcc dot gnu.org
 Blocks||53947
Summary|sparse access to Array of   |sparse access to Array of
   |structures does not |structures does not
   |vectorize   |vectorize using gathers
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
t.cc:20:17: note: not vectorized: not suitable for gather load _2 = f3[_1].x;
t.cc:20:17: note: bad data references.

that's because vect_check_gather_scatter computes a scale of 12 which isn't
supported by the HW (index _1, scale 12).

It seems to force a SSA name info->offset (_1) and thus doesn't handle
_1 * 3 to make scale == 4 supported.  In aos2 you conveniently expose
that as a SSA name yourself.

Looks like we need to split up scale by eventually emitting a multiplication
of the index vector separately.


Referenced Bugs:

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

[Bug tree-optimization/80181] [7 Regression] ICE in set_lattice_value, at tree-ssa-ccp.c:505

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Wed Mar 29 09:28:46 2017
New Revision: 246561

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

Backport from mainline
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.

2017-03-27  Richard Biener  

PR tree-optimization/80181
* tree-ssa-ccp.c (likely_value): UNDEFINED ^ X is UNDEFINED.

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

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr78644-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr78644-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr80181.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-ccp.c

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

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Wed Mar 29 09:28:46 2017
New Revision: 246561

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

Backport from mainline
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.

2017-03-27  Richard Biener  

PR tree-optimization/80181
* tree-ssa-ccp.c (likely_value): UNDEFINED ^ X is UNDEFINED.

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

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr78644-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr78644-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.dg/torture/pr80181.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/gcc/tree-ssa-ccp.c

[Bug tree-optimization/80249] Failed to build SPEC 2006 483.xalancbmk with -fdump-tree-fre

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Martin Liška  ---
Dup.

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

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||sudi.das at arm dot com

--- Comment #6 from Martin Liška  ---
*** Bug 80249 has been marked as a duplicate of this bug. ***

[Bug fortran/80235] ICE: coarrays, submodule

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-29
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed on 6.3.0 and trunk (7.0.1). If I compile the submodule file with an
instrumented gfortran I get

../../p_work/gcc/fortran/trans-decl.c:4694:14: runtime error: member access
within null pointer of type 'struct module_htab_entry'
ASAN:DEADLYSIGNAL
=
==98134==ERROR: AddressSanitizer: SEGV on unknown address 0x0010 (pc
0x00010050e94e bp 0x7fff5fbfd660 sp 0x7fff5fbfd590 T0)
==98134==The signal is caused by a READ memory access.
==98134==Hint: address points to the zero page.
#0 0x10050e94d in gfc_module_add_decl(module_htab_entry*, tree_node*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10050e94d)
#1 0x100510fe7 in gfc_build_qualified_array(tree_node*, gfc_symbol*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x100510fe7)
#2 0x100529fe6 in gfc_get_symbol_decl(gfc_symbol*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x100529fe6)
#3 0x1005a5fb8 in gfc_conv_variable(gfc_se*, gfc_expr*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1005a5fb8)
#4 0x100585f84 in gfc_conv_expr(gfc_se*, gfc_expr*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x100585f84)
#5 0x10059e348 in gfc_conv_expr_lhs(gfc_se*, gfc_expr*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10059e348)
#6 0x100445d15 in gfc_conv_ss_descriptor(stmtblock_t*, gfc_ss*, int)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x100445d15)
#7 0x100491e42 in gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x100491e42)
#8 0x100616c35 in gfc_conv_intrinsic_size(gfc_se*, gfc_expr*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x100616c35)
#9 0x10069d548 in gfc_conv_intrinsic_function(gfc_se*, gfc_expr*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10069d548)
#10 0x1005eb934 in gfc_conv_function_expr(gfc_se*, gfc_expr*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1005eb934)
#11 0x100585f6a in gfc_conv_expr(gfc_se*, gfc_expr*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x100585f6a)
#12 0x1005fd683 in gfc_trans_assignment_1(gfc_expr*, gfc_expr*, bool, bool,
bool, bool)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1005fd683)
#13 0x10060010e in gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool,
bool, bool)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10060010e)
#14 0x100600335 in gfc_trans_assign(gfc_code*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x100600335)
#15 0x100412e5f in trans_code(gfc_code*, tree_node*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x100412e5f)
#16 0x100414328 in gfc_trans_code(gfc_code*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x100414328)
#17 0x1005462de in gfc_generate_function_code(gfc_namespace*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1005462de)
#18 0x10042076d in gfc_generate_module_code(gfc_namespace*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10042076d)
#19 0x100278e07 in translate_all_program_units(gfc_namespace*)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x100278e07)
#20 0x1002933bb in gfc_parse_file()
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1002933bb)
#21 0x1003e803c in gfc_be_parse_file()
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1003e803c)
#22 0x10433ab18 in compile_file()
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10433ab18)
#23 0x10434360c in do_compile()
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x10434360c)
#24 0x1061e7b34 in toplev::main(int, char**)
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1061e7b34)
#25 0x1061ece11 in main
(/opt/gcc/gcc7gp/libexec/gcc/x86_64-apple-darwin16.4.0/7.0.1/f951+0x1061ece11)
#26 0x7fffb5a49234 in start (/usr/lib/system/libdyld.dylib+0x5234)

[Bug ada/79441] [7 regression] gnat.dg/pack9.adb fails

[vogt at linux dot vnet.ibm.com]

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

--- Comment #4 from Dominik Vogt  ---
Any chance of fixing that before gcc7?

[Bug testsuite/79356] XPASS in attr-alloc_size-11.c

[vogt at linux dot vnet.ibm.com]

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

--- Comment #12 from Dominik Vogt  ---
Still XPASSes on s390 (but not s390x with -m31 or -m64).

[Bug ada/79441] [7 regression] gnat.dg/pack9.adb fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
> Any chance of fixing that before gcc7?

Probably not, the underlying issue is in the SRA pass and not a regression.

[Bug testsuite/79356] XPASS in attr-alloc_size-11.c

[vogt at linux dot vnet.ibm.com]

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

--- Comment #13 from Dominik Vogt  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01468.html

[Bug c++/80247] 'nullptr' was not declared in this scope

[sbansal at ciena dot com]

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

Sumit  changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
 Resolution|INVALID |---

--- Comment #6 from Sumit  ---
Actually, once I have -std=c++11 included in CPPFLAGS, I am able to get rid of
nullptr problem.

But still in the same compilation environment, one another file is complaining
about nullptr not found.

I have ensured that both the files compiles with -std=c++11.

What can I check?

[Bug fortran/80235] ICE: coarrays, submodule

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Reduced submodule

submodule ( m ) sm

contains

  module subroutine cgca_pfem_map( origin, rot, bcol, bcou )
  implicit none
real( kind=rdef ), intent( in ) :: &
  origin(3),& ! origin of the "box" cs, in FE cs
  rot(3,3), & ! rotation tensor *from* FE cs *to* CA cs
  bcol(3),  & ! lower phys. coords of the coarray on image
  bcou(3) ! upper phys. coords of the coarray on image

integer( kind=idef ) :: maxfe

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

end subroutine cgca_pfem_map

end submodule sm

[Bug c++/80247] 'nullptr' was not declared in this scope

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Markus Trippelsdorf  ---
(In reply to Sumit from comment #6)
> Actually, once I have -std=c++11 included in CPPFLAGS, I am able to get rid
> of nullptr problem.
> 
> But still in the same compilation environment, one another file is
> complaining about nullptr not found.
> 
> I have ensured that both the files compiles with -std=c++11.
> 
> What can I check?

If there are several -std= in the command line, the last one wins.
But really this is not the right place to discuss these issues. 
Try the gcc-help mailing list.

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

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
How about this patch instead?

--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1250,7 +1250,8 @@ combine_instructions (rtx_insn *f, unsigned int nregs)
continue;

  while (last_combined_insn
-&& last_combined_insn->deleted ())
+&& (!INSN_P (last_combined_insn)
+|| last_combined_insn->deleted ()))
last_combined_insn = PREV_INSN (last_combined_insn);
  if (last_combined_insn == NULL_RTX
  || BARRIER_P (last_combined_insn)

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

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code

--- Comment #3 from Segher Boessenkool  ---
(ice-on-invalid of course, division by 0 is undefined behavior).

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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
But only at runtime, it is fine if it is never executed.  So I think it is
still ice-on-valid-code.

[Bug libstdc++/80251] New: Is the is_aggregate meta function missing?

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 80251
   Summary: Is the is_aggregate meta function missing?
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Hi gcc-team,

is is_aggregate [1] really missing or is it within some experimental
namespaces?

If I try to compile the following:

```c++
#include 

struct aggregate_t {
  int foo;
  int bar;
};

int main() {
  aggregate_t foo;
  static_assert(std::is_aggregate_v>);
  return 0;
}

```

It will result in the following error:

```terminal
bug_gcc_is_aggregate.cpp: In function ‘int main()’:
bug_gcc_is_aggregate.cpp:10:22: error: ‘is_aggregate_v’ is not a member of
‘std’
   static_assert(std::is_aggregate_v>);

  ^~
bug_gcc_is_aggregate.cpp:10:22: note: suggested alternative: ‘is_array_v’
   static_assert(std::is_aggregate_v>);
  ^~
  is_array_v
bug_gcc_is_aggregate.cpp:10:37: error: expected primary-expression before
‘decltype’
   static_assert(std::is_aggregate_v>);
 ^~~~
bug_gcc_is_aggregate.cpp:10:37: error: expected ‘,’ before ‘decltype’
bug_gcc_is_aggregate.cpp:10:37: error: expected string-literal before
‘decltype’
bug_gcc_is_aggregate.cpp:10:37: error: expected ‘)’ before ‘decltype’
zsh: exit 1 g++-7 -std=gnu++1z -Wall -Wextra bug_gcc_is_aggregate.cpp
```

[1] http://en.cppreference.com/w/cpp/types/is_aggregate

[Bug target/80239] [7 regression] 9% regression on dhrystone when targetting Cortex-M7

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Preud'homme  ---
(In reply to Thomas Preud'homme from comment #5)
> (In reply to Thomas Preud'homme from comment #1)
> > 
> > I believe the problem is that the equivalence stays with NO_REGS as register
> > class instead of being given that of a register (since it's going to be
> > reloaded into a register). My patch follows that path and as said above
> > works just after r235184 but the performance remains worse on recent trunk.
> > 
> > When looking at code generated by recent trunk, the issue mentionned in the
> > original post is not there which suggest that something else is at play.
> 
> I bisect this issue down to r239561 and reverting that commit on top of
> current trunk is enough to bring the performance back up. I'll still push
> the patch I mentioned above forward but given the circumstances I will wait
> for GCC 8 stage 1 for doing so.
> 
> I'll post a testcase of the issue as soon as I have understood what is the
> source of the slowdown with r239561 in current trunk.

Alright, that was due to a change in alignment. Adding a nop before anything in
main's prologue brings back performance. Thus closing the bug.

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

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #23 from Christophe Lyon  ---
(In reply to Jiong Wang from comment #22)
> (In reply to Rainer Orth from comment #15)
> > The new testcase FAILs on 64-bit Solaris/SPARC:
> 
> + AArch64
> 

For me, the tests pass on aarch64 (using qemu), but as I reported in
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01370.html
the tests fails for arm*linux-gnueabihf and pass for arm*linux-gnueabi (using
qemu too)

[Bug target/80252] New: ICE in plus_constant, at explow.c:88 with -fstack-check -mabi=ilp32

[sch...@linux-m68k.org]

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

Bug ID: 80252
   Summary: ICE in plus_constant, at explow.c:88 with
-fstack-check -mabi=ilp32
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: aarch64-*-*

$ cat stack-check.c
void g (char *);
int f (void)
{
  char i[32];
  i[16] = 0;
  g (i);
}
$ ./xgcc -B ./ -fstack-check stack-check.c -mabi=ilp32 -S
stack-check.c: In function ‘f’:
stack-check.c:7:1: internal compiler error: in plus_constant, at explow.c:88
 }
 ^
0x84a23f plus_constant(machine_mode, rtx_def*, long, bool)
../../gcc/gcc/explow.c:88
0xed235f aarch64_emit_probe_stack_range
../../gcc/gcc/config/aarch64/aarch64.c:2624
0xed786f aarch64_expand_prologue()
../../gcc/gcc/config/aarch64/aarch64.c:3592
0x105a53b gen_prologue()
../../gcc/gcc/config/aarch64/aarch64.md:558
0xed1abb target_gen_prologue
../../gcc/gcc/config/aarch64/aarch64.md:5799
0x8d27b7 make_prologue_seq
../../gcc/gcc/function.c:5842
0x8d29e3 thread_prologue_and_epilogue_insns()
../../gcc/gcc/function.c:5959
0x8d30b3 rest_of_handle_thread_prologue_and_epilogue
../../gcc/gcc/function.c:6428
0x8d30b3 execute
../../gcc/gcc/function.c:6470

stack_pointer_rtx is always of DImode.

[Bug target/80252] ICE in plus_constant, at explow.c:88 with -fstack-check -mabi=ilp32

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/80158] [7 Regression] ICE in all_phi_incrs_profitable

[wschmidt at gcc dot gnu.org]

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

--- Comment #20 from Bill Schmidt  ---
Author: wschmidt
Date: Wed Mar 29 12:56:26 2017
New Revision: 246567

URL: https://gcc.gnu.org/viewcvs?rev=246567&root=gcc&view=rev
Log:
2017-03-29  Bill Schmidt  

PR tree-optimization/80158
* gimple-ssa-strength-reduction.c (replace_mult_candidate):
Handle possible future case of more than one alternate
interpretation.
(replace_rhs_if_not_dup): Likewise.
(replace_one_candidate): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-strength-reduction.c

[Bug target/80252] ICE in plus_constant, at explow.c:88 with -fstack-check -mabi=ilp32

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-29
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
> stack_pointer_rtx is always of DImode.

That was my initial thought, but then:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00418.html

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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 41072
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41072&action=edit
gcc7-pr79993.patch

So, one option is to revert to the 4.8 and earlier behavior, disallow any VLA
initialization (like C does).  This patch should do it.

Otherwise, the behavior the C++ FE has when not using string literals as
initializers is that it is UB if the VLA is smaller than the size of the
initializer, and if it is larger or equal than that, it is initialized from the
initializer and excess elements if any are zero initialized (value
initialization or whatever it is).  Even when ignoring the bogus type on the
STRING_CST, we don't implement that right now for STRING_CST - we probably want
memcpy from the STRING_CST followed by whatever we do for other initializers.

[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

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

--- Comment #11 from Dominik Vogt  ---
Looks good.

[Bug target/79487] Invalid _Decimal32 comparison on s390x

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

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

--- Comment #26 from Dominik Vogt  ---
Fixed.

[Bug c/80253] New: Optimization silences __attribute__((fallthrough)) warning

[sirl at gcc dot gnu.org]

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

Bug ID: 80253
   Summary: Optimization silences __attribute__((fallthrough))
warning
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41073
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41073&action=edit
testcase

The attached testcase issues 2 warnings with -O0 and only 1 warning with -O1 or
higher. I believe 2 warnings should be issued in both cases.

# gcc-trunk -Wall -c fallthrough-1.c -O0
fallthrough-1.c: In function 'test':
fallthrough-1.c:4:21: warning: attribute 'fallthrough' not preceding a case
label or default label
 #define FALLTHROUGH __attribute__((fallthrough))
 ^
fallthrough-1.c:25:5: note: in expansion of macro 'FALLTHROUGH'
 FALLTHROUGH;
 ^~~
fallthrough-1.c:4:21: warning: attribute 'fallthrough' not preceding a case
label or default label
 #define FALLTHROUGH __attribute__((fallthrough))
 ^
fallthrough-1.c:32:4: note: in expansion of macro 'FALLTHROUGH'
FALLTHROUGH;
^~~


# gcc-trunk -Wall -c fallthrough-1.c -O1
fallthrough-1.c: In function 'test':
fallthrough-1.c:4:21: warning: attribute 'fallthrough' not preceding a case
label or default label
 #define FALLTHROUGH __attribute__((fallthrough))
 ^
fallthrough-1.c:25:5: note: in expansion of macro 'FALLTHROUGH'
 FALLTHROUGH;
 ^~~

[Bug target/80252] ICE in plus_constant, at explow.c:88 with -fstack-check -mabi=ilp32

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jiwang at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Jiong Wang  ---
Dupliate PR target/78002

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

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

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
(In reply to tim from comment #0)
> 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.

Note, in C++17, the definition of a constexpr static class member is inside of
the class, outside of the class is only a useless redeclaration.
That said, while the redundant redeclaration is deprecated, it has not been
removed from C++ yet and so it is ice-on-valid-code.

[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32

[jiwang at gcc dot gnu.org]

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

Jiong Wang  changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

--- Comment #4 from Jiong Wang  ---
*** Bug 80252 has been marked as a duplicate of this bug. ***

[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug libstdc++/80165] Constexpr tuple of variant doesn't work

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #2 from Ville Voutilainen  ---
Hmm, might be that this can be made to work before gcc 7 ships, since it's
apparently just a variant copy/move constructor issue.

[Bug rtl-optimization/80197] pgo dramatically pessimizes scimark2 MonteCarlo benchmark

[amonakov at gcc dot gnu.org]

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

--- Comment #7 from Alexander Monakov  ---
No, with fixed-up inlining -ftracer sees reasonable edge probabilities. The
reason tracer makes things worse here, is that it clones the path leading to a
50%/50% conditional branch (and correctly stops at that branch), making the
tiny BB under that branch ineligible(?) for if-conversion. We go from


if (!cond) goto 
  
  var = VAL;   // this can eventually become a cmov


to


if (!cond) goto 
goto 

...


if (!cond) goto 
  
  var = VAL;  // this doesn't become a cmov



I think in principle if-conversion could still do its job here by duplicating
the conditional var=VAL assignment under BB0_1.

Here's a silly compile-only sample where -O2 -ftracer is worse than -O2 due to
this effect:

void f(long n, signed char *x)
{
  for (; n; n--) {
long a=x[n], b;
if (!a)
  a = 42;
b = x[a];
if (b < 0)
  b += a;
x[b] = 0;
  }
}

[Bug ada/80146] [7 regression] ICE in copy_to_mode_reg, at explow.c:612

[schwab at gcc dot gnu.org]

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

--- Comment #8 from Andreas Schwab  ---
Author: schwab
Date: Wed Mar 29 14:18:07 2017
New Revision: 246570

URL: https://gcc.gnu.org/viewcvs?rev=246570&root=gcc&view=rev
Log:
PR ada/80146
* calls.c (prepare_call_address): Convert funexp to Pmode before
copying to temp reg.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c

[Bug fortran/80254] New: Windows test failure: dec_io_2.f90

[nightstrike at gmail dot com]

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

Bug ID: 80254
   Summary: Windows test failure: dec_io_2.f90
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
  Target Milestone: ---

(See https://gcc.gnu.org/ml/fortran/2017-03/msg00137.html)

On Windows platforms, the test for dec_io_2.f90 fails when calling the
second line in this trio:

call check_cc('none',fname, output_ccnone)
call check_cc('list',fname, output_cclist)
call check_cc('fortran', fname, output_ccfort)

Commenting the second line out makes it not abort.  It aborts because
the test is expecting that the output file should have unix based line
endings (LF).  On Windows platforms, it gets Windows based line
endings (CRLF).

[Bug fortran/80254] Windows test failure: dec_io_2.f90

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-29
 CC||foreese at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
CCed Fritz Reese.

[Bug tree-optimization/79534] [7 Regression] tree-ifcombine aarch64 performance regression with trunk@245151

[brzycki at gmail dot com]

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

--- Comment #6 from Brian Rzycki  ---
James, my apologies if it wasn't clear enough what the compile options were.
The test platform in this case is a Juno A57 running Ubuntu.

I actually never turned off -mcpu=cortex-a57 during my testing. I'll keep this
in mind too in the future.

[Bug middle-end/69578] -Wuninitialized not issuing warning.

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-29
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.3.1, 6.3.0, 7.0

--- Comment #2 from Martin Sebor  ---
Confirmed with the top of trunk (7.0).

[Bug target/80250] ICE in in final_scan_insn, at final.c:3025 for __builtin_ia32_vp4dpwssds_mask builtin

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-29
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #2 from Uroš Bizjak  ---
Created attachment 41074
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41074&action=edit
Proposed patch

We need to handle constant 0 in a more complicate way.

Patch in testing.

[Bug target/80250] ICE in in final_scan_insn, at final.c:3025 for __builtin_ia32_vp4dpwssds_mask builtin

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug fortran/80254] Windows test failure: dec_io_2.f90

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
It is probably best to run this test case only on Unixoid
systems, and create a separate one for Windows where the
output that is checked.

So, add something like

! { dg-do run { target { ! { *-*-mingw* *-*-cygwin* spu-*-* } } } }

to dec_io_2.f90

(check what SPU is, though)

and create a new test case with something like

! { dg-do run { target  *-*-mingw* *-*-cygwin* spu-*-* } }

...

character(*), parameter :: output_cclist = &
  "+ first"//CHAR(13)//CHAR(10)//&
  "-second line"//CHAR(13)//CHAR(10)//&
  "0now you know"//CHAR(13)//CHAR(10)//&
  "1this is the fourth line"//CHAR(13)//CHAR(10)//&
  "$finally we have a new challenger for the final line"//CHAR(13)//CHAR(10)//&
  CHAR(0)//"this is the end"//CHAR(13)//CHAR(10)//&
  " this is a plain old line"//CHAR(13)//CHAR(10)

[Bug target/32826] Reduction into a global variable causes a Load Hit Store Hazard (for the Cell)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-29
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Segher Boessenkool  ---
It generates different code now, but still a LHS:

vxor 0,0,0
li 10,16
lis 9,e@ha
vsldoi 13,1,0,8
vadduwm 1,1,13
vsldoi 0,1,0,4
vadduwm 1,1,0
stvx 1,1,10
lwz 10,16(1)
addi 1,1,32
stw 10,e@l(9)

(-m32 -mcpu=cell, but similar with different cpus or -m64).

[Bug middle-end/69578] -Wuninitialized not issuing warning.

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
It is a dup of all the uninit PRs caused by CCP turning PHI into X
(X=10 here).

[Bug fortran/80254] Windows test failure: dec_io_2.f90

[nightstrike at gmail dot com]

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

--- Comment #3 from nightstrike  ---
The cygwin default line ending style is UNIX like.

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

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 41075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41075&action=edit
gcc7-pr80234.patch

Untested fix.

[Bug target/31557] return 0x80000000UL code gen can be improved

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #5 from Segher Boessenkool  ---
Fixed on trunk, no backports planned, closing.

[Bug target/31557] return 0x80000000UL code gen can be improved

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Segher Boessenkool  ---
Actually, huh, *not* fixed on trunk yet.

[Bug middle-end/66447] -Werror=maybe-uninitialized indicates trashing of variable across longjmp

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #2 from Martin Sebor  ---
Standalone test case not provided as requested.  Resolving as invalid.

[Bug c++/80238] genmatch.c:(.text.startup+0x66c6): undefined reference to `operator delete(void*, unsigned long)'

[programmist.linuks at mail dot ru]

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

--- Comment #2 from Mike  ---
(In reply to Jonathan Wakely from comment #1)
> That's the sized-deallocation function which was new in GCC 5.
> 
> How did you configure gcc?
> 
> What is your existing compiler that you're using to build it?

My information for gcc:
<<< [ admin$: test] gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10) >>>

So I configured the assembly:

<<< #!/bin/sh
./configure --enable-languages=c,c++,java,objc,obj-c++ \
--prefix=/mnt/sda5/gcc --build=x86_64-linux-gnu \
--cache-file /mnt/sda5/gcc/CACHE-FILE --enable-multilib \
--enable-shared --enable-target-optspace --host=x86_64-pc-linux-gnu \
--program-transform-name='s/^gcc$/gcc-6.0.3;' 
>>>

[Bug fortran/80254] Windows test failure: dec_io_2.f90

[nightstrike at gmail dot com]

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

--- Comment #4 from nightstrike  ---
(In reply to nightstrike from comment #3)
> The cygwin default line ending style is UNIX like.

This test currently passes on cygwin as-is.

[Bug fortran/80254] Windows test failure: dec_io_2.f90

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
Created attachment 41076
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41076&action=edit
Proposed test case for mingw

[Bug fortran/80254] Windows test failure: dec_io_2.f90

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Created attachment 41077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41077&action=edit
Patch for failing test case

The patch works for me on linux (i.e. the test is still
execuated, and doesn't fail).  The _2a test case is not
executed, as expected.

How do the two work out on a mingw system?

[Bug c/80253] Optimization silences __attribute__((fallthrough)) warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-29
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  With -O we remove a pointless goto, and the next statement happens
to be the default label from the switch.

[Bug c/80253] Optimization silences __attribute__((fallthrough)) warning

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Looks like expand_FALLTHROUGH_r should be using case_label_p.

[Bug fortran/80254] Windows test failure: dec_io_2.f90

[nightstrike at gmail dot com]

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

--- Comment #7 from nightstrike  ---
(In reply to Thomas Koenig from comment #6)
> Created attachment 41077 [details]
> Patch for failing test case
> 
> The patch works for me on linux (i.e. the test is still
> execuated, and doesn't fail).  The _2a test case is not
> executed, as expected.
> 
> How do the two work out on a mingw system?

On mingw (I tested x86_64-w64-mingw32), the tests switch from FAIL to
UNSUPPORTED.

On cygwin, they go from PASS to PASS (as expected).

But what about Janne's comment here:
https://gcc.gnu.org/ml/fortran/2017-03/msg00141.html

?

[Bug target/80108] ICE in aggregate_value_p at function.c:2028

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kelvin at gcc dot gnu.org

--- Comment #2 from kelvin at gcc dot gnu.org ---
I'm seeking consensus on the "right thing to do". Should I make sure that
-mpower9-minmax turns on whatever additional target options are necessary in
order to make this work?

[Bug fortran/80254] Windows test failure: dec_io_2.f90

[nightstrike at gmail dot com]

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

--- Comment #8 from nightstrike  ---
(In reply to nightstrike from comment #7)
> (In reply to Thomas Koenig from comment #6)
> > Created attachment 41077 [details]
> > Patch for failing test case
> > 
> > The patch works for me on linux (i.e. the test is still
> > execuated, and doesn't fail).  The _2a test case is not
> > executed, as expected.
> > 
> > How do the two work out on a mingw system?
> 
> On mingw (I tested x86_64-w64-mingw32), the tests switch from FAIL to
> UNSUPPORTED.
> 
> On cygwin, they go from PASS to PASS (as expected).
> 
> But what about Janne's comment here:
> https://gcc.gnu.org/ml/fortran/2017-03/msg00141.html
> 
> ?

Sorry, I was being dumb.  I tested that the disabled testcase is actually
disabled.  I didn't notice that you added a new one just for mingw.  Testing
that now.

[Bug fortran/80254] Windows test failure: dec_io_2.f90

[nightstrike at gmail dot com]

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

--- Comment #9 from nightstrike  ---
Ok, your new _2a test just for mingw works like a champ:

# of expected passes12

[Bug target/80108] ICE in aggregate_value_p at function.c:2028

[kelvin at gcc dot gnu.org]

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

--- Comment #3 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Wed Mar 29 17:23:58 2017
New Revision: 246572

URL: https://gcc.gnu.org/viewcvs?rev=246572&root=gcc&view=rev
Log:

Use this branch for work on PR 80108.


Added:
branches/ibm/bz80108/
  - copied from r246571, trunk/

[Bug fortran/80254] Windows test failure: dec_io_2.f90

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
Author: tkoenig
Date: Wed Mar 29 17:30:58 2017
New Revision: 246573

URL: https://gcc.gnu.org/viewcvs?rev=246573&root=gcc&view=rev
Log:
2017-03-28  Thomas Koenig  

PR fortran/80254
* gfortran.dg/dec_io_2.f90:  Do not run on MINGW, run
* gfortran.dg/dec_io_2a.f90:  instead (new test).


Added:
trunk/gcc/testsuite/gfortran.dg/dec_io_2a.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dec_io_2.f90

[Bug fortran/80254] Windows test failure: dec_io_2.f90

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Thomas Koenig  ---
Fixed, closing.

[Bug fortran/80255] New: Segfault from accessing class(*) component in an array of any-type-wrappers

[pedsxing at gmx dot net]

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

Bug ID: 80255
   Summary: Segfault from accessing class(*) component in an array
of any-type-wrappers
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pedsxing at gmx dot net
  Target Milestone: ---

Created attachment 41078
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41078&action=edit
Test program that shows the problem.

The attached source file compiles fine but produces a segfault with gfortran
7.0.1 r153017.

Note that a segfault only occurs when printing element 1 and 3. Element 2
prints 'other type', even though I believe it should be caught by "is type
(real)".

Works fine with ifort 17.0.2 (Though one has to initialize the array in another
way, as they do not have assignment to class(*) implemented.)

[Bug fortran/80255] Segfault from accessing class(*) component in an array of any-type-wrappers

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
The code compiles with gfortran configured with --enable-checking=release, but
segfault at run time. However if gfortran is configured with
--enable-checking=yes, I get

pr80255.f90:1:0:

 program test

Error: conversion of register to a different size
VIEW_CONVERT_EXPR(_28);

MEM[(struct ftlany[0:] *)_29][_31].value = VIEW_CONVERT_EXPR(_28);
pr80255.f90:1:0: Error: conversion of register to a different size
VIEW_CONVERT_EXPR(_32);

MEM[(struct ftlany[0:] *)_33][_35].value = VIEW_CONVERT_EXPR(_32);
pr80255.f90:1:0: internal compiler error: verify_gimple failed

pr80255.f90:1:0: internal compiler error: Abort trap: 6
gfcc: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I don't have the patience to look at the standard, but I am not sure the code
is valid.

[Bug target/80108] ICE in aggregate_value_p at function.c:2028

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
(In reply to kelvin from comment #2)
> I'm seeking consensus on the "right thing to do". Should I make sure that
> -mpower9-minmax turns on whatever additional target options are necessary in
> order to make this work?

Use of -mcpu that is not power9 or higher together with a power9-specific
option is just wrong.  We should reject this combination of options with an
error message, in my view.

[Bug target/80108] ICE in aggregate_value_p at function.c:2028

[meissner at linux dot vnet.ibm.com]

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

--- Comment #5 from Michael Meissner  ---
On Wed, Mar 29, 2017 at 05:14:38PM +, kelvin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80108
> 
> kelvin at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>  CC||kelvin at gcc dot gnu.org
> 
> --- Comment #2 from kelvin at gcc dot gnu.org ---
> I'm seeking consensus on the "right thing to do". Should I make sure that
> -mpower9-minmax turns on whatever additional target options are necessary in
> order to make this work?

My opinion is if -mcpu= is not set, then -mpower9-minmax should set
-mcpu=power9.  However, -mno-power9-minmax should not set anything.

If -mcpu= is not -mcpu=power9, then this is an eror.

[Bug target/80108] ICE in aggregate_value_p at function.c:2028

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt  ---
For stage 4, fixing this particular error combination (along with what Mike
suggests) should be enough.  There is a vast array of ridiculous option
combinations that should no doubt be rejected, but let's not go there for
now...

[Bug c++/80177] wrong fixit hint for misspelled static_assert: __cpp_static_assert

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-29
 CC||dmalcolm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

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

lookup_name_fuzzy (..., FUZZY_LOOKUP_NAME) is called, but it runs
into two problems:

(a) It considers close matches in the preprocessor and will return *before*
considering reserved words.  Need to update it to consider the best match from
both.

(b) With (a) fixed, it would consider "static_assert":

  (gdb) p c_common_reswords[155]
  $11 = {word = 0x1a0f8c2 "static_assert", rid = RID_STATIC_ASSERT, disable =
522}

but it rejects it here:

  4998if (!cp_keyword_starts_decl_specifier_p (resword->rid))
  4999  continue;

Am working on a fix.

[Bug fortran/80046] [F03] Explicit interface required: pointer argument

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #4 from janus at gcc dot gnu.org ---
I'm currently regtesting a draft patch ...

[Bug middle-end/33086] warn for read-only uninitialized variables passed as arguments

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #6 from Martin Sebor  ---
I think it would be reasonable to issue a warning on the code in comment #3
(perhaps under -Wmaybe-uninitialized rather than -Wuninitialized).  For
uninitialized variables passed by reference to pure functions (that cannot
change objects pointed to by their arguments) I think it would make sense to
issue -Wunitialized.

Based on comment #4 and on my understanding of the two reports resolving as a
duplicate of bug 10138.

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

[Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments

[msebor at gcc dot gnu.org]

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

--- Comment #27 from Martin Sebor  ---
*** Bug 33086 has been marked as a duplicate of this bug. ***

[Bug middle-end/10138] warn for uninitialized arrays passed as const* arguments

[msebor at gcc dot gnu.org]

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

Bug 33086 Summary: warn for read-only uninitialized variables passed as 
arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33086

   What|Removed |Added

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

[Bug middle-end/79234] warn on past the end reads by library functions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=71501

--- Comment #1 from Martin Sebor  ---
See also bug 71501.

For another example consider the test case below.  Both functions attempt to
read a character array that isn't (necessarily) nul-terminated.  In f, the
function ends up reading the uninitialized contents of the local array and so
it should, arguably, be diagnosed by -Wuninitialized.  In g, the function reads
past the end of the local array so it could also be diagnosed by
-Wuninitialized, or 


$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic z.c
unsigned f (void)
{
  char d[4];
  __builtin_memcpy (d, "12", 2);
  return __builtin_strlen (d);   // missing warning
}

unsigned g (void)
{
  char d[4];
  __builtin_memcpy (d, "1234", 4);
  return __builtin_strlen (d);   // missing warning
}

[Bug target/80108] ICE in aggregate_value_p at function.c:2028

[kelvin at gcc dot gnu.org]

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

--- Comment #7 from kelvin at gcc dot gnu.org ---
I'll pursue the recommendations offered by Michael and Bill.

Aside: as I read the existing implementation, I believe the more "consistent"
behavior would be to behave as suggested in my original "proposal".  I don't
feel strongly about this, and I may have misunderstood some of the existing
code.

Here is my current understanding of how this behaves in general:

1. If someone specifies a particular CPU option (e.g. -mcpu=405), this has the
effect of setting a bunch of target options "implicitly".

2. If someone specifies a particular target option explicitly
(-mpower9-minmax), this has the effect of setting a bunch of additional target
options on which this option depends, and marking all of these dependent target
options as explicit, UNLESS any of the dependent target options have been
"explicitly" disabled, in which case we issue an error message and quit.

Feel free to correct my understanding if I'm still confused about this.  If we
feel that -mcpu=405 -mpower9-minmax should be an error, there are probably a
bunch of other option combinations that we should probably treat as errors as
well, whereas today we may be "fixing up the inconsistencies" silently.

In terms of "fixing this mess", I've been thinking the "right way" to handle
all the target options would be to "auto-generate"
rs6000_option_override_internal from tables that describe in a more manageable
way the lattice of dependencies between all of the different target options. 
That would be the best way to enforce consistent handling of everything.  But
it would require some "effort" and would probably break existing behavior...  
:(

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

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 41072 [details]
> gcc7-pr79993.patch
> 
> So, one option is to revert to the 4.8 and earlier behavior, disallow any
> VLA initialization (like C does).  This patch should do it.

I've been ambivalent about this.  I think it makes sense, but given the number
of testcases that hit the change, the functionality seems to be fairly popular.