[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 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 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 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=gcc=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] 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 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=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/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 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 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 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 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=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

[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 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 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/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/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 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=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 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 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

[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/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 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=edit
Proposed patch

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

Patch in testing.

[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 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=edit
gcc7-pr80234.patch

Untested fix.

[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 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 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 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 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 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=edit
Proposed test case for mingw

[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 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 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 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=gcc=rev
Log:

Use this branch for work on PR 80108.


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

[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 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 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 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 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=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/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 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 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/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=gcc=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 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 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 ada/67205] eliminate No_Implicit_Dynamic_Code restriction violations

[ebotcazou at gcc dot gnu.org]

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

Bug 80146 Summary: [7 regression] ICE in copy_to_mode_reg, at explow.c:612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80146

   What|Removed |Added

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

[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
Bug 80117 depends on bug 80146, which changed state.

Bug 80146 Summary: [7 regression] ICE in copy_to_mode_reg, at explow.c:612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80146

   What|Removed |Added

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

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

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

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

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

[ebotcazou at gcc dot gnu.org]

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

--- Comment #5 from Eric Botcazou  ---
So the proper thing to do might be to restore Pmode as in the first version:
  https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01988.html

[Bug libstdc++/80251] 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

--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
I'm sorry for the inconvenience! I didn't see that is_aggregate was just a
recent addition to the standard [1]. I just wanted to see if I can check at
compile time if my data structure is an aggregate type, like I can do with
is_pod. And I just happened to find such a function on cppreference, but I
didn't realize that this  was added quite recently.

[1] http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0625r0.html#2911

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed Mar 29 21:37:45 2017
New Revision: 246576

URL: https://gcc.gnu.org/viewcvs?rev=246576=gcc=rev
Log:
2017-03-29  Jerry DeLisle  

PR libgfortran/78670
* io/list_read.c (nml_get_obj_data): Delete code which calls the
child read procedure. (nml_read_obj): Insert the code which
calls the child procedure. Don't need to touch nodes if using
dtio since parent will not be traversing the components.

PR libgfortran/78670
* gfortran.dg/dtio_25.f90: Use 'a1' format when trying to read
a character of length 1. Update test for success.
* gfortran.dg/dtio_28.f03: New test.
* gfortran.dg/dtio_4.f90: Update to open test file with status =
'scratch' to delete the file when done.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_28.f03
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/dtio_25.f90
trunk/gcc/testsuite/gfortran.dg/dtio_4.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c

[Bug ipa/80258] On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS

[tmyklebu at gmail dot com]

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

--- Comment #4 from Tor Myklebust  ---
I suppose the program attached doesn't demonstrate that.

I ran:

info gcc 'C ext' 'thread'

I read the following text:

When the address-of operator is applied to a thread-local variable, it is
evaluated at run time and returns the address of the current thread's instance
of that variable.  An address so obtained may be used by any thread.  When a
thread terminates, any pointers to thread-local variables in that thread become
invalid.

This states that I get the address of the current thread's instance of a
thread-local variable when I '&' a variable declared __thread.  I edited f() to
take the address of foo and pass the address to dump(), and edited dump() to
print both the const char ** passed in and the string pointed to by the
pointed-to pointer.  The result is attached.

The program continues to fail with '-O3 -fPIC.'  (It also fails with only
'-O3.')  But now the program relies on the documentation snippet above; it
takes the address of the thread-local variable foo once before the call to
switch_thread and once after the call to switch_thread and prints the string
pointed to by the pointer obtained by taking the address of the thread-local
variable foo.

Before the call to switch_thread, the current thread's instance of foo points
to the string ":(" and dump() faithfully prints a sad face.  However, after the
call to switch_thread, the current thread's instance of the thread-local
variable foo points to the string ":)."  With '-O3 -fPIC', the second call to
dump() erroneously prints ":(."

Since the observed behaviour of the program when compiled with '-O3 -fPIC'
deviates from the behaviour specified for the program by the compiler's
documentation, I conclude that there is a bug either in the compiler or its
documentation---this is a bug.

Your comment about swapcontext appears to be a red herring.  Whether
swapcontext is aware of TLS is irrelevant.  I am not aware of any language in
the C standard or in gcc's documentation that forbids changing the thread
executing a given piece of code with a given stack while it is running. 
Although gcc has done no analysis to prove that this assumption is sound, the
code being generated by gcc effectively assumes that a global pointer is not
mutated within a function call.

[Bug ipa/80258] On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS

[tmyklebu at gmail dot com]

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

--- Comment #5 from Tor Myklebust  ---
Created attachment 41084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41084=edit
Program referenced in comment 4

[Bug ipa/80258] On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS

[tmyklebu at gmail dot com]

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

--- Comment #6 from Tor Myklebust  ---
Created attachment 41085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41085=edit
Program referenced in comment 4

[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 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

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
I think it would be preferable to make VLA initialization work the way it was
supposed to.  A patch to handle it properly exists (bug 69517) and I plan
(hope) to dust it off for GCC 8 and submit it.

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

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
Hi Kelvin,

405 does not have VSX (or even VMX).  The instructions enabled by
-mpower9-minmax require VSX.  The following behaviours all make
sense, for -mcpu=405 -mpower9-minmax:

1) Ignore the latter option;
2) Give a warning;
3) Give an error.

The following do not make sense:

1) Enable VSX;
2) Select -mcpu=power9 instead;
3) Omelette du fromage.

[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.

[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 #5 from Segher Boessenkool  ---
Author: segher
Date: Wed Mar 29 20:53:59 2017
New Revision: 246575

URL: https://gcc.gnu.org/viewcvs?rev=246575=gcc=rev
Log:
combine: Fix PR80233

If combine has added an unconditional trap there will be a new basic
block as well.  It will then end up considering the NOTE_INSN_BASIC_BLOCK
as the last_combined_insn, but then it tries to take the DF_INSN_LUID
of that and that dereferences a NULL pointer (since such a note is not
an INSN_P).

This fixes it by not taking non-insns as last_combined_insn.


PR rtl-optimization/80233
* combine.c (combine_instructions): Only take NONDEBUG_INSN_P insns
as last_combined_insn.  Do not test for BARRIER_P separately.

gcc/testsuite/
PR rtl-optimization/80233
* gcc.c-torture/compile/pr80233.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr80233.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug libquadmath/68686] tgammaq(x) is always negative for noninteger x < 0

[3dw4rd at verizon dot net]

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

--- Comment #4 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
Created attachment 41079
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41079=edit
Correct sign of negative arg tgammaq.

Basically,

return (x > 0.0Q || (int)(-x) & 1) ? +res : -res;

CL:
2017-03-29  Edward Smith-Rowland  <3dw...@verizon.net>

PR libquadmath/68686
* math/tgammaq.c: Correct sign for negative argument.
* testsuite/pr68686.c

We need a testsuite for libquadmath?

pr68686.c

#include 
#include 

int
main(void)
{
  __float128 result = tgammaq(-1.5Q);
  assert(result > 0.0Q);

  result = tgammaq(-2.5Q);
  assert(result < 0.0Q);

  return 0;
}

[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=gcc=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 c++/80243] c++ doesn't allow function to return a struct (or object?) - same thing

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
I'm afraid comment #6 still doesn't give us enough to go on.  It looks like a
bunch of syntax errors for a source file that doesn't even seem obviously
related to the snippets posted in comment #0 and comment #1.

What we need to confirm and investigate a suspected GCC problem is a standalone
test case and the command line options used to invoke the compiler so we can
reproduce the errors.  Quoting from the What we need section in
https://gcc.gnu.org/bugs:

 *  the options given when GCC was configured/built;
 *  the complete command line that triggers the bug;
 *  the compiler output (error messages, warnings, etc.); and
 *  the preprocessed file (*.i*) that triggers the bug

Quoting from From What we do not want on the same page:

 *  A code snippet that won't cause the compiler to produce the exact output
mentioned in the bug report.

The last item on the first list can be obtained by preprocessing the source
file with the -E option.  Note, however, that preprocessing atoi64.cpp and
providing atoi64.i is not going to help here because of the syntax errors.  You
need to investigate and (unless they are caused by a compiler bug) fix those
yourself first.  It is very unlikely that the syntax errors in comment #6 are
caused by a compiler bug.

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

[jmichae3 at yahoo dot com]

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

Jim Michaels  changed:

   What|Removed |Added

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

--- Comment #5 from Jim Michaels  ---
Mr. wakely, your statement is invalid.

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

[jmichae3 at yahoo dot com]

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

--- Comment #6 from Jim Michaels  ---
here is another incorrect type spouted out:
atoi64.cpp:1101:389: error: request for member 'v' in 'vecstruct[i]', which is
of non-class type 'size_t {aka long long unsigned int}'
vecstruct[i].v

mBaseVal is std::vector which struct has a member v. v is type int,
not type size_t which is unsigned int for 32-bit and long long unsigned int for
64-bit.

[Bug fortran/80256] New: Cygwin bind_c_array_params_2.f90 test fails for scan-assembler-times

[nightstrike at gmail dot com]

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

Bug ID: 80256
   Summary: Cygwin bind_c_array_params_2.f90 test fails for
scan-assembler-times
   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: ---

Created attachment 41080
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41080=edit
Potential patch to the test

FAIL: gfortran.dg/bind_c_array_params_2.f90   -O   scan-assembler-times [
\t][$,_0-9]*myBindC 1

Running that test fails on cygwin.  I don't exactly know why, as the call it is
looking for is in the assembler.  Modifying the test as in the attachment makes
it work, but someone smarter than me could probably make the default regex
account for cygwin better.  I'll also attach the assembler output in a followup
post, since I cannot make two attachments in my initial problem report.

[Bug fortran/80256] Cygwin bind_c_array_params_2.f90 test fails for scan-assembler-times

[nightstrike at gmail dot com]

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

--- Comment #1 from nightstrike  ---
Created attachment 41081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41081=edit
Assembler output

Attaching the assembler output that dejagnu is trying to scan.  As mentioned in
the first post, someone skilled with regular expressions can probably find a
way to make dejagnu catch this instead of using the patch I provided.  dominiq
on irc suggested that perhaps it is failing because the actual text of myBindC
is found twice in the assembler output.  I changed the regex to be
"call\tmyBindC", which would only match once.

[Bug fortran/80257] New: Cygwin test fail: pointer_check_1.f90 output test

[nightstrike at gmail dot com]

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

Bug ID: 80257
   Summary: Cygwin test fail: pointer_check_1.f90 output test
   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: ---

Created attachment 41082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41082=edit
Assembly output from compiling the testcase

This test fails due to an early segmentation fault on either of these two
lines:

  call ppTest(pptr)
  call ppTest2(pptr)

Commenting out both of those allows the test to get to the point where it
correctly gives the "At line 53..." output.  It still seg faults after that,
though.

Since back traces are not usable on cygwin, I attached the assembler output. 
Maybe that's useful to someone.

[Bug ipa/80258] On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS

[tmyklebu at gmail dot com]

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

--- Comment #1 from Tor Myklebust  ---
Created attachment 41083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41083=edit
A program that breaks with -O3 -fPIC

[Bug rtl-optimization/60818] ICE in validate_condition_mode on powerpc*-linux-gnu*

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

  Known to fail||7.0

--- Comment #17 from Arseny Solokha  ---
(In reply to Arseny Solokha from comment #15)
> (In reply to Segher Boessenkool from comment #14)
> > I cannot get any of the testcases to fail with current trunk (but
> > they do fail with GCC 6).  Combine always merges the compare into
> > the if_then_else pattern, and there are no such patterns in rs6000
> > (this could be done with a cmp+isel define_insn_and_split, and is
> > probably a good idea, but we do not have that currently).
> 
> OK, I'll post another one or two the next week. This is still reproducible
> on the trunk, but the actual code pattern causing the ICE seems to be a
> moving target.

int no;

void
gn (int d3)
{
  while (no != 0)
  {
if ((no > d3) > (no < d3))
  ++no;

while (d3 != 0)
{
}
  }
}

% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20170326 -misel -Os -w -c qb3j6i03.c
qb3j6i03.c: In function 'gn':
qb3j6i03.c:15:1: internal compiler error: in validate_condition_mode, at
config/rs6000/rs6000.c:20752
 }
 ^
0x2b53add47a3 validate_condition_mode(rtx_code, machine_mode)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/config/rs6000/rs6000.c:20751
0x2b53b0171a7 branch_comparison_operator(rtx_def*, machine_mode)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/config/rs6000/predicates.md:1243
0x2b53b01731b scc_rev_comparison_operator(rtx_def*, machine_mode)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/config/rs6000/predicates.md:1300
0x2b53b0362d4 recog_10
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/config/rs6000/rs6000.md:344
0x2b53b0362d4 recog_11
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/config/rs6000/altivec.md:224
0x2b53b0362d4 recog_12
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/config/rs6000/rs6000.md:5090
0x2b53b0703e5 recog_137
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/config/rs6000/altivec.md:1760
0x2b53b09ff2b recog_for_combine_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/combine.c:11145
0x2b53b0a6aed recog_for_combine
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/combine.c:11401
0x2b53b0b2601 try_combine
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/combine.c:4033
0x2b53b0b8ea0 combine_instructions
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/combine.c:1372
0x2b53b0b8ea0 rest_of_handle_combine
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/combine.c:14650
0x2b53b0b8ea0 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170326/work/gcc-7-20170326/gcc/combine.c:14695

The same for powerpc-e500v2-linux-gnuspe. As before, toggling -fPIC may be
necessary as well.

[Bug ipa/80258] On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS

[tmyklebu at gmail dot com]

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

--- Comment #2 from Tor Myklebust  ---
For completeness, this issue was raised as Stackoverflow question 43081742 by
user merlin2011.

[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 #8 from Sumit  ---
(In reply to Markus Trippelsdorf from comment #7)
> (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.

Thanks Markus for the pointer. I closely checked that besides -std=c++11,
-nostdinc was also being passed which was causing this problem.

Thanks.
Sumit

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

[jmichae3 at yahoo dot com]

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

--- Comment #8 from Jim Michaels  ---
you are right, that code does work, my example needed debugging.
so if I can return a struct here, why not in my other code, unless gcc is
confused somehow?
alas, I cannot supply source or .ii files because the library cannot be under
the GNU license.

here's some fun free example code, and yeah, it works too.
#include 
#include 
#include 
#include 
typedef struct {std::string s;int i;} Structsb;
typedef std::vector VStructsb;
VStructsb files={{"abcd",1},{"efgh",2}};
VStructsb& fn(std::string s1, int i1) {//can be with or without &, & faster
files.push_back({s1,i1});
return files;
}
int main() {
std::cout< search starts 

[Bug ipa/80258] New: On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS

[tmyklebu at gmail dot com]

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

Bug ID: 80258
   Summary: On x86_64 with -fPIC, accesses to TLS can see the
wrong thread's TLS
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tmyklebu at gmail dot com
  Target Milestone: ---

The address of the running thread's TLS appears to be loaded only once although
the running thread may change.

This simple example:

__thread int foo;
void something();
void f() {
  foo = 1;
  something();
  foo = 2;
}

when built with -fPIC -O3, begets this code, where %fs:0x0 is loaded only once:

0760 :
 760:   53  push   %rbx
 761:   64 48 8b 04 25 00 00mov%fs:0x0,%rax
 768:   00 00
 76a:   48 8d 80 fc ff ff fflea-0x4(%rax),%rax
 771:   48 89 c3mov%rax,%rbx
 774:   c7 00 01 00 00 00   movl   $0x1,(%rax)
 77a:   31 c0   xor%eax,%eax
 77c:   e8 cf ff ff ff  callq  750 
 781:   c7 03 02 00 00 00   movl   $0x2,(%rbx)
 787:   5b  pop%rbx
 788:   c3  retq
 789:   0f 1f 80 00 00 00 00nopl   0x0(%rax)

The function called something could play around with the functions from
ucontext.h, meaning the value of %fs could change during that call.  The
attached program is a self-contained program reproducing the bug on my Linux
machine.  I get output like

5415 :(
5416 :)

if I pass at most one of '-fPIC' and '-O3'.  If I build the program like this:

gcc -pthread -O3 -fPIC -o foo255 foo255.c

and run, then I get the following output, which has two sad faces:

5448 :(
5449 :(

I used the following compiler:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-10'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch
--with-arch-32=i686 --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 6.3.0 20170321 (Debian 6.3.0-10)

[Bug ipa/80258] On x86_64 with -fPIC, accesses to TLS can see the wrong thread's TLS

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Why do you think this is a bug?  swapcontext is not TLS aware at all and was
not designed to be.

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

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #7 from Markus Trippelsdorf  ---
Jim, you have not reported one single valid bug in the past five years.
All of them were closed as invalid.
Your comments wasted valuable developer time.
I've blacklisted your account.

[Bug c++/80259] New: [5/6/7 Regression] ICE deleting friend function

[reichelt at gcc dot gnu.org]

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

Bug ID: 80259
   Summary: [5/6/7 Regression] ICE deleting friend function
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE since GCC 5.1.0:


void foo() {}

struct A
{
  friend void foo() = delete;
};


bug.cc: In function 'void foo()':
bug.cc:1:6: internal compiler error: tree check: expected block, have
error_mark in lower_function_body, at gimple-low.c:98
 void foo() {}
  ^~~
0x100a3ec tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9817
0x146eb3a tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3064
0x146eb3a lower_function_body
../../gcc/gcc/gimple-low.c:98
0x146eb3a execute
../../gcc/gcc/gimple-low.c:181
Please submit a full bug report [etc.]

[Bug middle-end/80006] loss of range information due to spurious widening conversion

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|tree-optimization   |middle-end

--- Comment #5 from Martin Sebor  ---
Adjusting Component per comment #4.

[Bug target/71294] [6 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[meissner at gcc dot gnu.org]

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

--- Comment #19 from Michael Meissner  ---
Author: meissner
Date: Wed Mar 29 23:15:51 2017
New Revision: 246577

URL: https://gcc.gnu.org/viewcvs?rev=246577=gcc=rev
Log:
[gcc]
2017-03-29  Michael Meissner  

Back port from trunk
2017-03-21  Aaron Sawdey  

PR target/80123
* doc/md.texi (Constraints): Document wA constraint.
* config/rs6000/constraints.md (wA): New.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Add wA reg_class.
(rs6000_init_hard_regno_mode_ok): Init wA constraint.
* config/rs6000/rs6000.h (RS6000_CONSTRAINT_wA): New.
* config/rs6000/vsx.md (vsx_splat_): Use wA constraint.

2017-03-16  Michael Meissner  

PR target/71294
* config/rs6000/vsx.md (vsx_splat_, VSX_D iterator): Allow a
SPLAT operation on ISA 2.07 64-bit systems that have direct move,
but no MTVSRDD support, by doing MTVSRD and XXPERMDI.

[gcc/testsuite]
2017-03-29  Michael Meissner  

Back port from trunk
2017-03-16  Michael Meissner  

PR target/71294
* g++.dg/pr71294.C: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/pr71294.C
  - copied unchanged from r246332, trunk/gcc/testsuite/g++.dg/pr71294.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/constraints.md
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/config/rs6000/rs6000.h
branches/gcc-6-branch/gcc/config/rs6000/vsx.md
branches/gcc-6-branch/gcc/doc/md.texi
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/80123] libgomp tests pr66199-2.c and pr66199-5.c fail with -mcpu=power9

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Author: meissner
Date: Wed Mar 29 23:15:51 2017
New Revision: 246577

URL: https://gcc.gnu.org/viewcvs?rev=246577=gcc=rev
Log:
[gcc]
2017-03-29  Michael Meissner  

Back port from trunk
2017-03-21  Aaron Sawdey  

PR target/80123
* doc/md.texi (Constraints): Document wA constraint.
* config/rs6000/constraints.md (wA): New.
* config/rs6000/rs6000.c (rs6000_debug_reg_global): Add wA reg_class.
(rs6000_init_hard_regno_mode_ok): Init wA constraint.
* config/rs6000/rs6000.h (RS6000_CONSTRAINT_wA): New.
* config/rs6000/vsx.md (vsx_splat_): Use wA constraint.

2017-03-16  Michael Meissner  

PR target/71294
* config/rs6000/vsx.md (vsx_splat_, VSX_D iterator): Allow a
SPLAT operation on ISA 2.07 64-bit systems that have direct move,
but no MTVSRDD support, by doing MTVSRD and XXPERMDI.

[gcc/testsuite]
2017-03-29  Michael Meissner  

Back port from trunk
2017-03-16  Michael Meissner  

PR target/71294
* g++.dg/pr71294.C: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/pr71294.C
  - copied unchanged from r246332, trunk/gcc/testsuite/g++.dg/pr71294.C
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/constraints.md
branches/gcc-6-branch/gcc/config/rs6000/rs6000.c
branches/gcc-6-branch/gcc/config/rs6000/rs6000.h
branches/gcc-6-branch/gcc/config/rs6000/vsx.md
branches/gcc-6-branch/gcc/doc/md.texi
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/69517] SEGV on a VLA with excess initializer elements

[msebor at gcc dot gnu.org]

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

--- Comment #17 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #16)

The bug here is in G++ accepting a VLA initializer with more elements than
there is room for in the VLA, and then trashing the stack at runtime with the
extra elements.  It is a regression with respect to GCC 4.9.3 which implements
C++ VLAs as specified in n3639
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3639.html).  This is
documented in GCC 4.9 changes (https://gcc.gnu.org/gcc-4.9/changes.html) which
highlights the feature using the following example:

  void f(int n) {
int a[n] = { 1, 2, 3 }; // throws std::bad_array_length if n < 3
...

VLAs were subsequently removed from C++, and also partially (but not
completely) removed from G++, which causes C++ programs developed and tested
with G++ 4.9 to break when ported to a later version.

C++ VLAs will be safer to use with the patch referenced in comment #9.  It
patch had to be reverted from GCC 6.0 because it caused problems in Java.  Java
has been removed and I plan/hope to resubmit the patch for GCC 8.  (I wanted to
do it for GCC 7 but didn't get to it.)

[Bug testsuite/72757] atomic test don't run with RUNTESTFLAGS=atomic.exp

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
I cannot reproduce this problem anymore.  It was likely due to a pilot error:
libatomic needs to have been built in order for the atomic tests to run. 
Though it would be nice if DejaGnu mentioned that in its output.

[Bug c/79730] [5/6/7 Regression] ICE tree check: expected var_decl, have function_decl in finish_decl, at c/c-decl.c:5063

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Wed Mar 29 23:40:36 2017
New Revision: 246578

URL: https://gcc.gnu.org/viewcvs?rev=246578=gcc=rev
Log:
PR c/79730
* c-decl.c (finish_decl): Check VAR_P.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr79730.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c/79730] [5/6/7 Regression] ICE tree check: expected var_decl, have function_decl in finish_decl, at c/c-decl.c:5063

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 7.

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

[jmichae3 at yahoo dot com]

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

Jim Michaels  changed:

   What|Removed |Added

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

--- Comment #5 from Jim Michaels  ---
returning a struct used to work. why not now?

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

[jmichae3 at yahoo dot com]

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

--- Comment #6 from Jim Michaels  ---
atoi64.cpp:1974:1: error: expected 'while' before 'ATOLDRESULT'
 ATOLDRESULT atold_(S str,bool oldCOctalEnabled=false,bool
groupCharEnabled=true,C groupChar=',',VS dimensionArr={""},bool
skipNonScientific=true,size_t pos=0,bool doMoney=false,bool
icaseDimensionArr=true,S charset="0123456789abcdef",bool icaseCharset=true,S
charsetPrefix="0d") {
 ^~~
atoi64.cpp:1974:1: error: expected '(' before 'ATOLDRESULT'
atoi64.cpp:1974:13: error: expected primary-expression before 'atold_'
 ATOLDRESULT atold_(S str,bool oldCOctalEnabled=false,bool
groupCharEnabled=true,C groupChar=',',VS dimensionArr={""},bool
skipNonScientific=true,size_t pos=0,bool doMoney=false,bool
icaseDimensionArr=true,S charset="0123456789abcdef",bool icaseCharset=true,S
charsetPrefix="0d") {
 ^~
atoi64.cpp:1974:13: error: expected ')' before 'atold_'
atoi64.cpp:1974:13: error: expected ';' before 'atold_'
atoi64.cpp:1974:22: error: expected primary-expression before 'str'
 ATOLDRESULT atold_(S str,bool oldCOctalEnabled=false,bool
groupCharEnabled=true,C groupChar=',',VS dimensionArr={""},bool
skipNonScientific=true,size_t pos=0,bool doMoney=false,bool
icaseDimensionArr=true,S charset="0123456789abcdef",bool icaseCharset=true,S
charsetPrefix="0d") {
  ^~~
atoi64.cpp:1974:26: error: expected primary-expression before 'bool'
 ATOLDRESULT atold_(S str,bool oldCOctalEnabled=false,bool
groupCharEnabled=true,C groupChar=',',VS dimensionArr={""},bool
skipNonScientific=true,size_t pos=0,bool doMoney=false,bool
icaseDimensionArr=true,S charset="0123456789abcdef",bool icaseCharset=true,S
charsetPrefix="0d") {
  ^~~~
atoi64.cpp:1974:54: error: expected primary-expression before 'bool'
 ATOLDRESULT atold_(S str,bool oldCOctalEnabled=false,bool
groupCharEnabled=true,C groupChar=',',VS dimensionArr={""},bool
skipNonScientific=true,size_t pos=0,bool doMoney=false,bool
icaseDimensionArr=true,S charset="0123456789abcdef",bool icaseCharset=true,S
charsetPrefix="0d") {
  ^~~~
atoi64.cpp:1974:83: error: expected primary-expression before 'groupChar'
 ATOLDRESULT atold_(S str,bool oldCOctalEnabled=false,bool
groupCharEnabled=true,C groupChar=',',VS dimensionArr={""},bool
skipNonScientific=true,size_t pos=0,bool doMoney=false,bool
icaseDimensionArr=true,S charset="0123456789abcdef",bool icaseCharset=true,S
charsetPrefix="0d") {
   
   ^
atoi64.cpp:1974:100: error: expected primary-expression before 'dimensionArr'
 ATOLDRESULT atold_(S str,bool oldCOctalEnabled=false,bool
groupCharEnabled=true,C groupChar=',',VS dimensionArr={""},bool
skipNonScientific=true,size_t pos=0,bool doMoney=false,bool
icaseDimensionArr=true,S charset="0123456789abcdef",bool icaseCharset=true,S
charsetPrefix="0d") {
   
^~~~
atoi64.cpp:1974:118: error: expected primary-expression before 'bool'
 ATOLDRESULT atold_(S str,bool oldCOctalEnabled=false,bool
groupCharEnabled=true,C groupChar=',',VS dimensionArr={""},bool
skipNonScientific=true,size_t pos=0,bool doMoney=false,bool
icaseDimensionArr=true,S charset="0123456789abcdef",bool icaseCharset=true,S
charsetPrefix="0d") {
   
  ^~~~
atoi64.cpp:1974:153: error: expected primary-expression before 'pos'
 ATOLDRESULT atold_(S str,bool oldCOctalEnabled=false,bool
groupCharEnabled=true,C groupChar=',',VS dimensionArr={""},bool
skipNonScientific=true,size_t pos=0,bool doMoney=false,bool
icaseDimensionArr=true,S charset="0123456789abcdef",bool icaseCharset=true,S
charsetPrefix="0d") {
   
 ^~~
atoi64.cpp:1974:159: error: expected primary-expression before 'bool'
 ATOLDRESULT atold_(S str,bool oldCOctalEnabled=false,bool
groupCharEnabled=true,C groupChar=',',VS dimensionArr={""},bool
skipNonScientific=true,size_t pos=0,bool doMoney=false,bool
icaseDimensionArr=true,S charset="0123456789abcdef",bool icaseCharset=true,S
charsetPrefix="0d") {
   
  
^~~~
atoi64.cpp:1974:178: error: expected primary-expression before 'bool'
 ATOLDRESULT atold_(S str,bool oldCOctalEnabled=false,bool
groupCharEnabled=true,C groupChar=',',VS dimensionArr={""},bool
skipNonScientific=true,size_t pos=0,bool doMoney=false,bool
icaseDimensionArr=true,S charset="0123456789abcdef",bool icaseCharset=true,S
charsetPrefix="0d") {

[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++/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++/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 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 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