[Bug c++/77656] New: 64-bit integral template parameter gets incorrectly sized as 32-bits

[matt at matthewfagan dot com]

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

Bug ID: 77656
   Summary: 64-bit integral template parameter gets incorrectly
sized as 32-bits
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at matthewfagan dot com
  Target Milestone: ---

GCC incorrectly sizes 64-bit integer template parameters, resulting in spurious
warnings (and perhaps incorrect code generation - unable to test this part).
The following sample code demonstrates the error: (Compiled for Target:
x86_64-pc-linux-gnu)

#include 

template<
uint64_t _Val,
int _Val2 = (_Val >> 32)
> class Test {
};

template
class Test2 : Test<_X> {};

template
class Test3 : Test<(uint64_t) _X> {};

Upon compilation, Test2 produces a spurious warning, but Test3 does not.

[Bug c++/51242] [C++11] Unable to use strongly typed enums as bit fields

[sashab at chromium dot org]

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

Sasha B  changed:

   What|Removed |Added

 CC||sashab at chromium dot org

--- Comment #28 from Sasha B  ---
I contribute to Chromium and have also hit problems such as Comment 27. I'm in
the process of submitting a patch to Clang (https://reviews.llvm.org/D24289)
that warns when enums used in bitfields are not given an unsigned underlying
type, since MSVC defaults to signed underlying types and this gives
inconsistencies when reading/writing the bitfield in multi-platform code.

With the patch, the following code:

enum Foo { A, B };
struct Bar { Foo x : 1 };

will give the following warning with Clang:
"enums in the Microsoft ABI are signed integers by default; consider giving the
enum Foo an unsigned underlying type to make this code portable"

But then if it's changed to

enum Foo : unsigned { A, B };
struct Bar { Foo x : 1 };

GCC will give the warning:
"'Bar::x' is too small to hold all values of 'enum Foo'"

The C++ standard says:
9.6.4 says: If the value of an enumerator is stored into a bit-field of the
same enumeration type and the number of bits in the bit-field is large enough
to hold all the values of that enumeration type (7.2), the original enumerator
value and the value of the bit-field shall compare equal.

You can disregard whether the underlying type is fixed or not. So, GCC should
not give a warning unless a bitfield containing Foo really is too small to hold
a given value of Foo, warning on the assignment makes sense.

[Bug c/77650] struct with a nested flexible array followed by another member accepted

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
Anything based on whether things are in system headers won't work for 
building glibc as the headers don't look like system headers when building 
glibc (which uses -Wall -Werror).

[Bug c++/77655] New: ICE on invalid c++ code on x86_64-linux-gnu (internal compiler error: Segmentation fault (program cc1plus))

[chengniansun at gmail dot com]

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

Bug ID: 77655
   Summary: ICE on invalid c++ code on x86_64-linux-gnu (internal
compiler error: Segmentation fault (program cc1plus))
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160919 (experimental) [trunk revision 240232] (GCC) 
$ 
$ gcc-trunk small.C
small.C: In instantiation of ‘decltype (g(0, (g<decltype(h::a)>)(h::a)...))
h(A&& ...) [with A = {}; decltype (g(0, (g<decltype(h::a)>)(h::a)...)) = void;
decltype (a) = ]’:
small.C:8:5:   required from here
small.C:4:4: error: no matching function for call to ‘h(h(A&& ...) [with A =
{}; decltype (g(0, (g<decltype(h::a)>)(h::a)...)) = void; decltype (a) =
]::<lambda()>)’
   h([] {});
   ~^~~
small.C:3:6: note: candidate: template decltype (g(0,
(g<decltype(h::a)>)(h::a)...)) h(A&& ...)
 auto h(A &&... a) -> decltype(g(0, g<decltype(a)>(a)...)) {
  ^
small.C:3:6: note:   template argument deduction/substitution failed:
gcc-trunk: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 
$ cat small.C
template  void g(F);
template 
auto h(A &&... a) -> decltype(g(0, g<decltype(a)>(a)...)) {
  h([] {});
}

int main() { 
  h(); 
  return 0; 
}
$

[Bug c++/77434] warn about suspicious precedence of ternary operator (?:)

[edlinger at gcc dot gnu.org]

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

--- Comment #12 from Bernd Edlinger  ---
Author: edlinger
Date: Mon Sep 19 22:10:11 2016
New Revision: 240251

URL: https://gcc.gnu.org/viewcvs?rev=240251=gcc=rev
Log:
gcc:
2016-09-19  Bernd Edlinger  

PR c++/77434
* doc/invoke.texi: Document -Wint-in-bool-context.

c-family:
2016-09-19  Bernd Edlinger  

PR c++/77434
* c.opt (Wcond-in-bool-context): New warning.
* c-common.c (c_common_truthvalue_conversion): Warn on integer
constants in boolean context.

cp:
2016-09-19  Bernd Edlinger  

PR c++/77434
* cvt.c (cp_convert_and_check): Suppress Wint-in-bool-context here.

testsuite:
2016-09-19  Bernd Edlinger  

PR c++/77434
* c-c++-common/Wint-in-bool-context.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wint-in-bool-context.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c/77650] struct with a nested flexible array followed by another member accepted

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Thanks for the background.  It's unfortunate but I hope the Glibc code can be
accommodated without preventing GCC from detecting the same problem in user
code (and rejecting it with a hard error).  One approach might be to base the
kind of the diagnostic (pedantic warning vs hard error) on whether the code
appears in a system header.  Longer term, Glibc could be changed to use a
zero-length array instead of a flexible array member so that the GCC workaround
could eventually be removed.  Another, perhaps more appropriate, approach might
be to add a new warning under -Wall and use it to diagnose this constraint
violation.  The warning would be suppressed for system headers, allowing GCC to
silently accept the Glibc code.

[Bug other/77421] Bugs found in GCC with the help of PVS-Studio

[edlinger at gcc dot gnu.org]

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

--- Comment #15 from Bernd Edlinger  ---
Author: edlinger
Date: Mon Sep 19 21:57:46 2016
New Revision: 240250

URL: https://gcc.gnu.org/viewcvs?rev=240250=gcc=rev
Log:
2016-09-19  Bernd Edlinger  

PR middle-end/77421
* dwarf2out.c (output_loc_operands): Fix an assertion.

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

[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call

[vmakarov at gcc dot gnu.org]

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

--- Comment #10 from Vladimir Makarov  ---
Author: vmakarov
Date: Mon Sep 19 21:38:27 2016
New Revision: 240247

URL: https://gcc.gnu.org/viewcvs?rev=240247=gcc=rev
Log:
2016-09-19  Vladimir Makarov  

PR rtl-optimization/77416
* lra-remat.c (operand_to_remat): Process hard coded insn
registers.

2016-09-19  Vladimir Makarov  

PR rtl-optimization/77416
* gcc.target/powerpc/pr77416.c: New.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr77416.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-remat.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/77654] restrict pointer attribute not preserved with -fprefetch-loop-arrays

[doug.gilmore at imgtec dot com]

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

--- Comment #2 from Doug Gilmore  ---
Created attachment 39652
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39652=edit
Prototype fix for bug.

[Bug tree-optimization/77654] restrict pointer attribute not preserved with -fprefetch-loop-arrays

[doug.gilmore at imgtec dot com]

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

--- Comment #1 from Doug Gilmore  ---
Created attachment 39651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39651=edit
Additional tracing used to identify problem.

[Bug tree-optimization/77654] New: restrict pointer attribute not preserved with -fprefetch-loop-arrays

[doug.gilmore at imgtec dot com]

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

Bug ID: 77654
   Summary: restrict pointer attribute not preserved with
-fprefetch-loop-arrays
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doug.gilmore at imgtec dot com
  Target Milestone: ---

Compiling the test example:

void daxpy(int n, double da, double * __restrict dx, double * __restrict dy)
{
int i;

for (i = 0;i < n; i++) {
dy[i] = dy[i] + da*dx[i];
}
}

via:

mips-img-linux-gnu-gcc -fprefetch-loop-arrays daxpy.c -c -O2 -save-temps
-fsched-verbose=9 -fdump-rtl-sched2

The following code is generated for the main loop:

$L4:
ldc1$f2,0($5)
pref6,0($2)
ldc1$f8,-120($2)
addiu   $2,$2,32
ldc1$f6,-144($2)
addiu   $5,$5,32
ldc1$f4,-136($2)
addiu   $3,$3,4
maddf.d $f8,$f2,$f0
ldc1$f2,-128($2)
sdc1$f8,-152($2)
ldc1$f1,-24($5)
maddf.d $f6,$f0,$f1
sdc1$f6,-144($2)
ldc1$f1,-16($5)
maddf.d $f4,$f0,$f1
sdc1$f4,-136($2)
ldc1$f1,-8($5)
maddf.d $f2,$f0,$f1
bne $3,$8,$L4
sdc1$f2,-128($2)

Due to the __restrict attributes on the pointer declarations, after
scheduling we should see that loads through $5 should move above the
stores through $2.  However, during the transformation done by the
phase that is enabled by -fprefetch-loop-arrays, the points-to
information is lost.  This prevents the loads to move above the stores
during scheduling.

The attached uses logic borrowed from IVS phase:

0002-Ensure-points-to-information-is-maintained-for-prefe.patch

After applying the patch, the points-to information is maintained,
which results in good code being generated after scheduling (which is
very important when running on in-order processors):

$L4:
addiu   $5,$5,32
ldc1$f8,-120($2)
ldc1$f6,-112($2)
pref6,0($2)
ldc1$f4,-104($2)
addiu   $3,$3,4
ldc1$f2,-96($2)
addiu   $2,$2,32
ldc1$f7,-32($5)
ldc1$f5,-24($5)
ldc1$f3,-16($5)
ldc1$f1,-8($5)
maddf.d $f8,$f7,$f0
maddf.d $f6,$f0,$f5
maddf.d $f4,$f0,$f3
maddf.d $f2,$f0,$f1
sdc1$f8,-152($2)
sdc1$f6,-144($2)
sdc1$f4,-136($2)
sdc1$f2,-128($2)
bnec$3,$8,$L4

I am not sure what to do about a test case.  One possibility is to
commit some of the tracing in debugging patch:

0001-Add-more-tracing-for-missing-points-to-information.patch

and we could scan for the RE "pi. is NULL", in the dump file
created by -fdump-rtl-sched2.

[Bug tree-optimization/77648] [4.9/5/6/7 Regression] Setting conversion to a integer to double to 0 3/4 through a loop

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||rguenth at gcc dot gnu.org
  Component|fortran |tree-optimization
  Known to work||4.8.5
Summary|Setting conversion to a |[4.9/5/6/7 Regression]
   |integer to double to 0 3/4  |Setting conversion to a
   |through a loop  |integer to double to 0 3/4
   ||through a loop
  Known to fail||4.9.3, 5.4.0, 6.2.0, 7.0

--- Comment #3 from Dominique d'Humieres  ---
Confirmed from 4.9 up to trunk (7.0). Compiling poly_module.f90 with the
options '-O2 -ftree-loop-vectorize -fpeel-loops' is enough to get the bad
outputs. The change occurred between revisions r205798 (2013-12-09, OK) and
r206002 (2013-12-15, bad).

[Bug tree-optimization/77653] New: wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)

[su at cs dot ucdavis.edu]

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

Bug ID: 77653
   Summary: wrong code at -Os and above on x86_64-linux-gnu (in
both 32-bit and 64-bit modes)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This is a regression from 6.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160919 (experimental) [trunk revision 240229] (GCC) 
$ 
$ gcc-6.2 -Os small.c; ./a.out
$ gcc-trunk -O1 small.c; ./a.out
$ 
$ gcc-trunk -Os small.c
$ ./a.out
Aborted (core dumped)
$ 


--


int a, b, c, d, e, h, i, j, k, l;
const int f; 
static int g;

void fn1 (int p1)
{
  k = d ? c % k : a * b;
  h &= j ^ i ^ 1;
}

int main ()
{
  const int *m = , **n = 
  l && (*n = );
  if (m != )
__builtin_abort ();
  fn1 (g);
  return 0;
}

[Bug c/77650] struct with a nested flexible array followed by another member accepted

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
On Mon, 19 Sep 2016, msebor at gcc dot gnu.org wrote:

> While testing my patch for C++ bug 71912 and gathering material for WG14 paper
> N2083 I noticed that GCC isn't completely consistent in diagnosing invalid 
> uses
> of flexible array members.  In the following example, it rejects the 
> definition
> of struct Y with a hard error because the flexible array member a is followed
> by another member, j.  But GCC issues only a pedantic warning for the similar
> definition of struct T where the flexible array member defined in a nested
> struct is also followed by another member.  I think it would be better (more
> consistent and safer(*)) if both structs were rejected with an error.

The nested struct is accepted to work with glibc headers, as I noted in 
.  gconv.h has

typedef struct __gconv_info
{
  size_t __nsteps;
  struct __gconv_step *__steps;
  __extension__ struct __gconv_step_data __data __flexarr;
} *__gconv_t;

and _G_config.h has

typedef union
{
  struct __gconv_info __cd;
  struct
  {
struct __gconv_info __cd;
struct __gconv_step_data __data;
  } __combined;
} _G_iconv_t;

where the inner struct has struct __gconv_info (which ends with a flexible 
array member) followed by another struct.

[Bug c++/77616] A variadic polymorphic lambda call fails with zero arguments

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
Looks like a dup of 64095 (and 68071).

[Bug fortran/77648] Setting conversion to a integer to double to 0 3/4 through a loop

[raynman4451 at tamu dot edu]

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

--- Comment #2 from Raymond Fontenot  ---
Created attachment 39650
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39650=edit
Test Case for Bug

I've attached a test case for this. The code will produce the incorrect
polynomial function p at the end of the routine for the given parameters. The
code will generate the following polynomial (a 1D Wendland function):
  -0.352E-01
   0.000E+00 x  
   0.446E-01 x^ 2   
   0.000E+00 x^ 3   
  -0.298E-02 x^ 4   
   0.000E+00 x^ 5   
   0.208E-01 x^ 6   
  -0.476E-01 x^ 7   
   0.521E-01 x^ 8   
  -0.317E-01 x^ 9   
   0.000E+00 x^10   
   0.000E+00 x^11  

The correct output from the code should be:
 -0.451E-04
   0.000E+00 x  
   0.496E-03 x^ 2   
   0.000E+00 x^ 3   
  -0.298E-02 x^ 4   
   0.000E+00 x^ 5   
   0.208E-01 x^ 6   
  -0.476E-01 x^ 7   
   0.521E-01 x^ 8   
  -0.317E-01 x^ 9   
   0.104E-01 x^10   
  -0.144E-02 x^11   

The bug in question happens in the function (in poly_module.f90)
integrate_poly_indefinite, called in generate_wendland.f90.

[Bug c++/77651] [7 Regression] c++ -Wno-aligned-new ICEs

[guille at cal dot berkeley.edu]

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

--- Comment #4 from Guille  ---
For what it's worth, any call to 'c++  -Waligned-new=none ...' will also ICE.

[Bug fortran/77652] Invalid rank error in ASSOCIATED when rank is remapped

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (7.0).

[Bug fortran/77652] New: Invalid rank error in ASSOCIATED when rank is remapped

[pault at gcc dot gnu.org]

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

Bug ID: 77652
   Summary: Invalid rank error in ASSOCIATED when rank is remapped
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pault at gcc dot gnu.org
  Target Milestone: ---

real, dimension(100), target  :: array
real, dimension(:,:), pointer :: matrix
matrix(1:20,1:5) => array
write( *, '(a,l)' )   'Associated? ', associated(matrix,array)
end

 write( *, '(a,l)' )   'Associated? ', associated(matrix,array)
1
Error: ‘pointer’ argument of ‘associated’ intrinsic at (1) must be of rank 2

See https://groups.google.com/forum/#!topic/comp.lang.fortran/BQfpeDZxX3Q

This appears to be erroneous and, indeed, perverse :-)

Paul

[Bug c++/77639] [6/7 Regression] ICE on x86_64-linux-gnu (internal compiler error: tree check: accessed elt 1 of tree_vec with 0 elts in unify, at cp/pt.c:19674)

[ppalka at gcc dot gnu.org]

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

--- Comment #3 from Patrick Palka  ---
Author: ppalka
Date: Mon Sep 19 18:12:36 2016
New Revision: 240245

URL: https://gcc.gnu.org/viewcvs?rev=240245=gcc=rev
Log:
Fix PR c++/77639 (ICE during error recovery)

gcc/cp/ChangeLog:

PR c++/77639
* parser.c (cp_parser_class_head): When
processing_template_parmlist, don't assume that the
class-head may start an explicit specialization.

gcc/testsuite/ChangeLog:

PR c++/77639
* g++.dg/template/error-recovery4.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/template/error-recovery4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug target/53659] ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark

[tulipawn at gmail dot com]

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

--- Comment #5 from PeteVine  ---
Created attachment 39649
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39649=edit
Annotated ARMv7 assembly

[Bug target/53659] ARM: Using -mcpu=cortex-a9 option results in bad performance for Cortex-A9 processor in C-Ray phoronix benchmark

[tulipawn at gmail dot com]

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

--- Comment #4 from PeteVine  ---
I've just done the obvious and run the resulting ARMv7 binaries on a Cortex A53
 in aarch32 mode and the difference is there (GCC 6.2.1 and 7.0.0) so I can
confirm the issue is present to this day.

Cortex-A5 vs Cortex-A9 codegen yields a 0.81x performance ratio.

[Bug libstdc++/77645] Python xmethods tests failing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed on all branches.

[Bug c++/77651] [7 Regression] c++ -Wno-aligned-new ICEs

[guille at cal dot berkeley.edu]

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

--- Comment #3 from Guille  ---
Excuses, I take that back. 
I use placement new on a properly aligned piece of memory, gcc complains
(warning) that: 

* 'note: uses ‘void* operator new(std::size_t, void*)’, which does not have an
alignment parameter'
* 'note: use ‘-faligned-new’ to enable C++17 over-aligned new support'

then I run with '-faligned-new', and it still gives me the same warning.

[Bug libstdc++/77645] Python xmethods tests failing

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Mon Sep 19 17:17:47 2016
New Revision: 240243

URL: https://gcc.gnu.org/viewcvs?rev=240243=gcc=rev
Log:
libstdc++/77645 fix deque and vector xmethods for Python 3

PR libstdc++/77645
* python/libstdcxx/v6/xmethods.py (DequeWorkerBase.__init__)
(DequeWorkerBase.index, VectorWorkerBase.get): Cast results of
division to int to work with Python 3.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/python/libstdcxx/v6/xmethods.py

[Bug libstdc++/77645] Python xmethods tests failing

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Author: redi
Date: Mon Sep 19 17:14:11 2016
New Revision: 240242

URL: https://gcc.gnu.org/viewcvs?rev=240242=gcc=rev
Log:
libstdc++/77645 fix deque and vector xmethods for Python 3

PR libstdc++/77645
* python/libstdcxx/v6/xmethods.py (DequeWorkerBase.__init__)
(DequeWorkerBase.index, VectorWorkerBase.get): Cast results of
division to int to work with Python 3.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/python/libstdcxx/v6/xmethods.py

[Bug libstdc++/77645] Python xmethods tests failing

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Mon Sep 19 17:09:04 2016
New Revision: 240241

URL: https://gcc.gnu.org/viewcvs?rev=240241=gcc=rev
Log:
libstdc++/77645 fix deque and vector xmethods for Python 3

PR libstdc++/77645
* python/libstdcxx/v6/xmethods.py (DequeWorkerBase.__init__)
(DequeWorkerBase.index, VectorWorkerBase.get): Cast results of
division to int to work with Python 3.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/libstdcxx/v6/xmethods.py

[Bug c++/77651] [7 Regression] c++ -Wno-aligned-new ICEs

[guille at cal dot berkeley.edu]

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

--- Comment #2 from Guille  ---

Correction: There is no issue with '-faligned-new', only with
'-Wno-aligned-new'.

[Bug c++/77651] [7 Regression] c++ -Wno-aligned-new ICEs

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-19
 CC||trippels at gcc dot gnu.org
Summary|c++ -Wno-aligned-new ICEs   |[7 Regression] c++
   ||-Wno-aligned-new ICEs
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
 % echo | g++ -c -x c++ -Wno-aligned-new -
cc1plus: internal compiler error: in decode_cmdline_option, at
opts-common.c:671
0x1533fed decode_cmdline_option
../../gcc/gcc/opts-common.c:671
0x1533fed decode_cmdline_options_to_array(unsigned int, char const**, unsigned
int, cl_decoded_option**, unsigned int*)
../../gcc/gcc/opts-common.c:836
Please submit a full bug report

[Bug c++/77651] New: c++ -Wno-aligned-new ICEs

[guille at cal dot berkeley.edu]

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

Bug ID: 77651
   Summary: c++ -Wno-aligned-new ICEs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guille at cal dot berkeley.edu
  Target Milestone: ---

I'm getting ICEs on any call to c++ with option '-Wno-aligned-new'

(Incidentally, overaligned structs can be allocated with 'new' using option
'-faligned-new', but then c++ still complains 'C++17 over-aligned new support'
has to be activated with '-faligned-new', even though that option was already
passed). 

I assume this is a very minor thing, but I thought I'd send it since it ICEs. 


$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin13.4.0/7.0.0/lto-wrapper
Target: x86_64-apple-darwin13.4.0
Configured with: ../configure --disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 7.0.0 20160918 (experimental) (GCC)

[Bug tree-optimization/77647] Missed opportunity to use register value causes additional load

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-19
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
In the case of -, during VPR (or DOM), folds the - to 0.  While in the + case,
it does not pick up it should be a + a instead of a + b.

Confirmed.

[Bug fortran/77648] Setting conversion to a integer to double to 0 3/4 through a loop

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-19
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Please post a full test.

[Bug c/77650] New: struct with a nested flexible array followed by another member accepted

[msebor at gcc dot gnu.org]

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

Bug ID: 77650
   Summary: struct with a nested flexible array followed by
another member accepted
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing my patch for C++ bug 71912 and gathering material for WG14 paper
N2083 I noticed that GCC isn't completely consistent in diagnosing invalid uses
of flexible array members.  In the following example, it rejects the definition
of struct Y with a hard error because the flexible array member a is followed
by another member, j.  But GCC issues only a pedantic warning for the similar
definition of struct T where the flexible array member defined in a nested
struct is also followed by another member.  I think it would be better (more
consistent and safer(*)) if both structs were rejected with an error.

$ cat v.c && /build/gcc-trunk-git/gcc/xgcc -B /build/gcc-trunk-git/gcc -O2 -S
-Wall -Wextra -Wpedantic v.c
struct X { int i, a[]; };
struct Y { int i, a[], j; };

struct S { struct X x; };
struct T { struct X x; int j; };
v.c:2:19: error: flexible array member not at end of struct
 struct Y { int i, a[], j; };
   ^
v.c:4:21: warning: invalid use of structure with flexible array member
[-Wpedantic]
 struct S { struct X x; };
 ^
v.c:5:21: warning: invalid use of structure with flexible array member
[-Wpedantic]
 struct T { struct X x; int j; };
 ^

Rejecting the flexible array would be safer because with the definition of
struct Y commented out, a complete program with the definition of main below
aborts, indicating that GCC assumes that members of struct T do not alias. 
That assumption is violated by allowing the flexible array member to be
followed by another member in an enclosing struct.

void f (struct T *t, struct X *x)
{
  t->j = 0x12345678;
  x->a [0] = 0xdeadbeef;
  if (0 < t->j)
__builtin_abort ();
}

int main (void)
{
  struct T *t = __builtin_malloc (sizeof (struct T));
  f (t, >x);
  return 0;
}

[Bug libstdc++/77645] Python xmethods tests failing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|[6/7 Regression] Python |Python xmethods tests
   |xmethods tests failing  |failing

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> The xmethods.list.cc error is a regression, caused by switching to gnu++14
> in GCC 6.

The list.cc test is fixed on trunk and gcc-6-branch.

> Also, these tests should cause a FAIL rather than UNSUPPORTED.

The deque and vector tests now FAIL on trunk.

[Bug libstdc++/77645] [6/7 Regression] Python xmethods tests failing

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Mon Sep 19 15:50:53 2016
New Revision: 240235

URL: https://gcc.gnu.org/viewcvs?rev=240235=gcc=rev
Log:
libstdc++/77645 Fix xmethods for std::list

PR libstdc++/77645
* python/libstdcxx/v6/xmethods.py (DequeWorkerBase.index): Rename
argument.
(ListWorkerBase.get_value_from_node): Define new method.
(ListFrontWorker.__call__, ListBackWorker.__call__): Use it.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/python/libstdcxx/v6/xmethods.py

[Bug libstdc++/77645] [6/7 Regression] Python xmethods tests failing

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Mon Sep 19 15:49:19 2016
New Revision: 240233

URL: https://gcc.gnu.org/viewcvs?rev=240233=gcc=rev
Log:
libstdc++/77645 Fix xmethods for std::list

PR libstdc++/77645
* python/libstdcxx/v6/xmethods.py (DequeWorkerBase.index): Rename
argument.
(ListWorkerBase.get_value_from_node): Define new method.
(ListFrontWorker.__call__, ListBackWorker.__call__): Use it.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/python/libstdcxx/v6/xmethods.py

[Bug c++/77338] [7 Regression] ICE on invalid C++11 code on x86_64-linux-gnu: Segmentation fault

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #6 from Paolo Carlini  ---
Fixed then.

[Bug go/77642] GO Bootstrap fail starting with r239872 splitstack signature does not match

[krebbel at gcc dot gnu.org]

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

--- Comment #1 from Andreas Krebbel  ---
On s390 32 bit size_t is "unsigned long". __splitstack_find in libgcc is
defined as follows:

extern void*   
__splitstack_find (void *, void *, size_t *, void **, void **, void **)

However, libgo/go/runtime/runtime2.go uses uintptr for gcstacksize and this
gets passed as pointer in libgo/runtime/proc.c for the third operand:

static void
doentersyscall()
{
// Disable preemption because during this function g is in _Gsyscall
status,
// but can have inconsistent g->sched, do not let GC observe it.
g->m->locks++;

// Leave SP around for GC and traceback.
#ifdef USING_SPLIT_STACK
g->gcstack = __splitstack_find(nil, nil, >gcstacksize,
   >gcnextsegment, >gcnextsp,
   >gcinitialsp);
#else


Since neither of the two types can be changed we probably have to convert back
and fort here (untested):

diff --git a/libgo/runtime/proc.c b/libgo/runtime/proc.c
index 6ac8857..134ab6a 100644
--- a/libgo/runtime/proc.c
+++ b/libgo/runtime/proc.c
@@ -2052,9 +2052,11 @@ doentersyscall()

// Leave SP around for GC and traceback.
 #ifdef USING_SPLIT_STACK
-   g->gcstack = __splitstack_find(nil, nil, >gcstacksize,
+   size_t gcstacksize = (size_t)g->gcstacksize;
+   g->gcstack = __splitstack_find(nil, nil, ,
   >gcnextsegment, >gcnextsp,
   >gcinitialsp);
+   g->gcstacksize = (uintptr)gcstacksize;
 #else
{
void *v;

[Bug fortran/77649] New: Wrong error reported with bound checking enabled

[mrestelli at gmail dot com]

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

Bug ID: 77649
   Summary: Wrong error reported with bound checking enabled
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrestelli at gmail dot com
  Target Milestone: ---

When compiled with  -fcheck=all  the following code produces an
incorrect error at runtime:


$ gfortran test.f90 -fcheck=all -o test
$ ./test
At line 13 of file test.f90
Fortran runtime error: Index '2' of dimension 1 of array 'text' above upper
bound of 1


$ gfortran --version
GNU Fortran (GCC) 7.0.0 20160919 (experimental)


program p
 implicit none
 character(len=10) :: s

 s = fs((/"abc","d  "/))

 write(*,*) s
contains

 function fs(text) result(s)
  character(len=*), intent(in) :: text(:)
  integer :: i
  character(len=sum((/(len_trim(text(i)) , i=1,size(text))/))) :: s

   write(*,*) "len(s) = ", len(s)
   s = "XYZ"
 end function fs

end program p

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #7)

> So it seems V2DFmode is available but discouraged via the above hook when
> tuning for atom.
> 
> Indeed:
> 
> static machine_mode
> ix86_preferred_simd_mode (machine_mode mode)
> {
> ...
> case DFmode:
>   if (!TARGET_VECTORIZE_DOUBLE)
> return word_mode;

This part should be OK, the hook documentation says:

 -- Target Hook: machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE
  (machine_mode MODE)
 This hook should return the preferred mode for vectorizing scalar
 mode MODE.  The default is equal to 'word_mode', because the
 vectorizer can do some transformations even in absence of
 specialized SIMD hardware.

IIUC, word_mode should be returned for unsupported scalar modes.

> but targetm.vector_mode_supported_p happily returns true for V2DFmode.

Yes, also following the documentation:

 -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE)
 Define this to return nonzero if the port is prepared to handle
 insns involving vector mode MODE.  At the very least, it must have
 move patterns for this mode.

We *do* have V2DF move patterns.

> This means the above is _not_ a good way to achieve what it tries to
> (make the vectorizer not use V2DFmode).  A more proper way would be to
> handle this in ix86_add_stmt_cost, increasing the cost for double type
> vectorization.
> 
> Nevertheless the vectorizer shouldn't ICE on this inconsistency, I'll see
> what it takes to "fix" it on the vectorizer side.

Please note that we have similar situation with TARGET_PREFER_AVX128, the
difference is that we still vectorize with narrower vector mode, whereas
V2DFmode falls back to a word_mode.

[Bug tree-optimization/77646] [5/6/7 Regression] GCC Segfault with -O3

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org
  Known to work||4.9.4
Summary|GCC Segfault with -O3   |[5/6/7 Regression] GCC
   ||Segfault with -O3
  Known to fail||5.4.0, 6.2.0, 7.0

--- Comment #2 from Markus Trippelsdorf  ---
struct ccl_iterator_ccl_pointer_iterator_st {
  int (*has_more_elements)();
  void (*next_element)();
} * c;
int a;
void *ccl_real_calloc();
typedef struct {
  struct ccl_iterator_ccl_pointer_iterator_st super;
} poset_iterator;
int s_poset_iterator_has_more_elements() { return a; }
const struct ccl_iterator_ccl_pointer_iterator_st b = {
s_poset_iterator_has_more_elements};
void ar_poset_log() {
  poset_iterator *d = ccl_real_calloc();
  d->super = b;
  c = (struct ccl_iterator_ccl_pointer_iterator_st *)d;
  struct ccl_iterator_ccl_pointer_iterator_st *i = c;
  if (i->has_more_elements(c))
while (i->has_more_elements(c))
  i->next_element();
}

[Bug tree-optimization/77646] [5/6/7 Regression] GCC Segfault with -O3

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Or with creduce's rename-toks:

struct e {
  int (*f)();
  void (*g)();
} * c;
int a;
void *h();
typedef struct { struct e j; } k;
int l() { return a; }
const struct e b = {l};
void m() {
  k *d = h();
  d->j = b;
  c = (struct e *)d;
  struct e *i = c;
  if (i->f(c))
while (i->f(c))
  i->g();
}

[Bug fortran/77648] New: Setting conversion to a integer to double to 0 3/4 through a loop

[raynman4451 at tamu dot edu]

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

Bug ID: 77648
   Summary: Setting conversion to a integer to double to 0 3/4
through a loop
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raynman4451 at tamu dot edu
  Target Milestone: ---

Howdy,
I am using gfortran 5.3.1 on OSX 10.11. My code is compiled with -m64 -O3
-fdefault-real-8 -fdefault-double-8, and when compiled for debugging  -m64
-fdefault-real-8 -fdefault-double-8 -fcheck=all -fbacktrace
-ffpe-trap=zero,underflow,denormal,invalid -g) does not throw any errors.
Additionally, I have statically debugged with FORCHECK. My issue is as follows.
Take the following block of code which updates the coefficients of a polynomial
type after integration:

  p_int%coefficients(0) = 0.0d0
  do i = 0, p%order
   p_int%coefficients(i+1) = 1.0d0/dble(i+1)*p%coefficients(i)
  end do

For both Intel and Absoft compilers using similar options, that loop works just
fine, and the conversion of integer to a double is ok. For gfortran, however,
1.0d0/dble(i+1) will equal 0 roughly 3/4 though the number of steps in the
loop. So, if p%order = 7, at about 5 gfortran makes that factor 0. It does not
do this if I place a write statement for 1.0d0/dble(i+1) in the loop, nor does
it do it when the debug options are thrown. To get around it, I had to change
the above block of code to the following:  

   fac = 0.0d0
   do i = 0, p%order
   fac = fac + 1.0d0
   p_int%coefficients(i+1) = p%coefficients(i)/fac
end do

which avoids the conversion altogether.

[Bug c++/71827] [5/6/7 Regression] ICE on invalid C++11 code with non constant diff between two labels

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  ---
*** Bug 77556 has been marked as a duplicate of this bug. ***

[Bug c++/77556] [6/7 Regression] ICE on invalid C++ code with non-constant non-type template argument: in convert_nontype_argument, at cp/pt.c:6416

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Paolo Carlini  ---
Dup.

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

[Bug target/77571] __clear_cache is broken on arm64 for big.little where the cache line sizes are different between cores

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Richard Earnshaw  ---
This is something the kernel has to address.  If the system has processors with
differently sized cache line lengths, then the OS needs to virtualize the
relevant system registers to report an appropriate (safe) line length.  Any
other approach will likely have race conditions.

[Bug ipa/77587] [5/6/7 Regression] C compiler produces incorrect stack alignment with __attribute__((weak))

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon Sep 19 14:36:38 2016
New Revision: 240232

URL: https://gcc.gnu.org/viewcvs?rev=240232=gcc=rev
Log:
PR target/77587
* cgraph.c (cgraph_node::rtl_info): Pass  to
ultimate_alias_target call, return NULL if avail < AVAIL_AVAILABLE.
Call ultimate_alias_target just once, not up to 4 times.

* gcc.dg/pr77587.c: New test.
* gcc.dg/pr77587a.c: New file.

Added:
trunk/gcc/testsuite/gcc.dg/pr77587.c
trunk/gcc/testsuite/gcc.dg/pr77587a.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/77646] GCC Segfault with -O3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
  Component|c   |tree-optimization
   Severity|critical|normal

--- Comment #1 from Marek Polacek  ---
Reproduced with trunk:
$ ./cc1 -quiet q.ii -O3
q.ii: In function ‘ar_poset_log’:
q.ii:3238:1: internal compiler error: tree check: expected ssa_name, have
var_decl in vuse_ssa_val, at tree-ssa-sccvn.c:339
 ar_poset_log(ccl_log_type log, ar_poset *poset,
 ^~~~
0x10e181c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marek/src/gcc/gcc/tree.c:9742
0x7143c1 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marek/src/gcc/gcc/tree.h:3031
0xfe6c5d vuse_ssa_val
/home/marek/src/gcc/gcc/tree-ssa-sccvn.c:339
0xfeda7c vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool)
/home/marek/src/gcc/gcc/tree-ssa-sccvn.c:2425
0xff0b54 visit_reference_op_load
/home/marek/src/gcc/gcc/tree-ssa-sccvn.c:3520
0xff194e visit_use
/home/marek/src/gcc/gcc/tree-ssa-sccvn.c:3853
0xff24e9 process_scc
/home/marek/src/gcc/gcc/tree-ssa-sccvn.c:4104
0xff2834 extract_and_process_scc_for_name
/home/marek/src/gcc/gcc/tree-ssa-sccvn.c:4160
0xff29de DFS
/home/marek/src/gcc/gcc/tree-ssa-sccvn.c:4212
0xff42ed sccvn_dom_walker::before_dom_children(basic_block_def*)
/home/marek/src/gcc/gcc/tree-ssa-sccvn.c:4665
0x1700ef2 dom_walker::walk(basic_block_def*)
/home/marek/src/gcc/gcc/domwalk.c:265
0xff4981 run_scc_vn(vn_lookup_kind)
/home/marek/src/gcc/gcc/tree-ssa-sccvn.c:4789
0xfc63b0 execute
/home/marek/src/gcc/gcc/tree-ssa-pre.c:5010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/77646] GCC Segfault with -O3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-19
 Ever confirmed|0   |1

[Bug tree-optimization/77352] ICE: verify_ssa failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/77647] New: Missed opportunity to use register value causes additional load

[npiggin at gmail dot com]

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

Bug ID: 77647
   Summary: Missed opportunity to use register value causes
additional load
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: npiggin at gmail dot com
  Target Milestone: ---

static inline long load(long *p)
{
long ret;
asm ("movq  %1,%0\n\t" : "=r" (ret) : "m" (*p));
if (ret != *p)
__builtin_unreachable();
return ret;
}

long foo(long *mem)
{
long ret;
ret = load(mem);
return ret - *mem;
}

foo() compiles down to 'xorl %eax,%eax ; ret' which is great. Changing the
minus to plus gives

movq(%rdi),%rax
addq(%rdi),%rax
ret

[Bug c/77646] New: GCC Segfault with -O3

[pictavien at free dot fr]

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

Bug ID: 77646
   Summary: GCC Segfault with -O3
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pictavien at free dot fr
  Target Milestone: ---

Created attachment 39648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39648=edit
poset.c file

Hi,

I obtain the same compiler internal error when I compile the attached file with
gcc 5.4 (either on MacPorts or Linux Ubuntu).

gcc -O3 poset.c -c -o poset.o
poset.c: In function 'ar_poset_log':
poset.c:3238:1: internal compiler error: Segmentation fault
 ar_poset_log(ccl_log_type log, ar_poset *poset,
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug libstdc++/77645] [6/7 Regression] Python xmethods tests failing

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-19
  Known to work||5.4.0
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
Summary|Python xmethods tests   |[6/7 Regression] Python
   |failing |xmethods tests failing
 Ever confirmed|0   |1
  Known to fail||6.1.0

--- Comment #1 from Jonathan Wakely  ---
The xmethods.list.cc error is a regression, caused by switching to gnu++14 in
GCC 6.

Also, these tests should cause a FAIL rather than UNSUPPORTED.

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|NEW |ASSIGNED
 CC||uros at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #7 from Richard Biener  ---
Mine.  The issue is that we have a non-vectorizable load as part of an
interleaving group (that stmt is later not used in the SLP).

But the odd part of this testcase is that we have

t.c:7:1: note: not vectorized: no vectype for stmt: _51 = *x_18(D);
 scalar_type: double
t.c:7:1: note: got vectype for stmt: _32 = *_33;
vector(4) int
t.c:7:1: note: got vectype for stmt: _25 = *_28;
vector(2) double

this seems to be a backend issue with targetm.vectorize.preferred_simd_mode
(DFmode) which seems to return SImode (!?) but once we fixed vector size
by looking for a SImode vector mode (V4SImode) mode_for_vector happily
returns V2DFmode for us to use.

So it seems V2DFmode is available but discouraged via the above hook when
tuning for atom.

Indeed:

static machine_mode
ix86_preferred_simd_mode (machine_mode mode)
{
...
case DFmode:
  if (!TARGET_VECTORIZE_DOUBLE)
return word_mode;

but targetm.vector_mode_supported_p happily returns true for V2DFmode.

This means the above is _not_ a good way to achieve what it tries to
(make the vectorizer not use V2DFmode).  A more proper way would be to
handle this in ix86_add_stmt_cost, increasing the cost for double type
vectorization.

Nevertheless the vectorizer shouldn't ICE on this inconsistency, I'll see
what it takes to "fix" it on the vectorizer side.

[Bug libstdc++/77645] New: Python xmethods tests failing

[redi at gcc dot gnu.org]

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

Bug ID: 77645
   Summary: Python xmethods tests failing
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Python Exception  Argument to arithmetic operation not a
number or boolean.: 
deque.gdb:22: Error in sourced command file:
Error while executing Python code.
skipping: Python Exception  Argument to arithmetic operation
not a number or boolean.: 
skipping: deque.gdb:22: Error in sourced command file:
skipping: Error while executing Python code.
UNSUPPORTED: libstdc++-xmethods/deque.cc

Python Exception  There is no member or method named
_M_data.: 
list.gdb:13: Error in sourced command file:
Error while executing Python code.
skipping: Python Exception  There is no member or method
named _M_data.: 
skipping: list.gdb:13: Error in sourced command file:
skipping: Error while executing Python code.
UNSUPPORTED: libstdc++-xmethods/list.cc

Python Exception  Argument to arithmetic operation not a
number or boolean.: 
skipping: Python Exception  Argument to arithmetic operation
not a number or boolean.: 
vector.gdb:13: Error in sourced command file:
Error while executing Python code.
skipping: vector.gdb:13: Error in sourced command file:
skipping: Error while executing Python code.
UNSUPPORTED: libstdc++-xmethods/vector.cc


The std::list failure is because the list node has a different structure in
C++11 and later, which is easy to fix.

The deque and vector failures are also related to C++11, but I don't understand
them yet. Pointer arithmetic is failing for a pointer type, maybe because the
code uses a typedef that doesn't look like a pointer.

[Bug middle-end/77624] [5/6/7 Regression] ICE on x86_64-linux-gnu (internal compiler error: in fold_builtin_atomic_always_lock_free, at builtins.c:5583)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 39647
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39647=edit
gcc7-pr77624-alt.patch

Alternate untested patch.  The problem right now is that because these
intrinsics are prototyped, whatever type user used is implicitly cast to const
volatile *, and because of the implicit cast it is hard to find out what is
implicit and what is explicit conversion.  This patch attempts to make the arg
non-prototyped, and only checked afterwards.  In the quick testing, it seems to
work for C, but not for C++, which ignores changes to argarray arguments.

[Bug target/77267] MPX does not work in a presence of "-Wl,-as-needed" option (Ubuntu default)

[aivchenk at gmail dot com]

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

--- Comment #8 from Alexander Ivchenko  ---
Thanks, Matthias, that's a valid point about changing linker on a runtime. In
my defense, I see that right now MPX does not work with '-fuse-ld=bfd' anyways:

>gcc test.c -fcheck-pointer-bounds -mmpx -fuse-ld=gold
/usr/bin/ld.gold: bndplt: unknown -z option
/usr/bin/ld.gold: use the --help option for usage information

That's not a surprise, because the check for '--push-state' is done exactly
like the check for '-z bndplt'.

Would it be possible to probe the 'other' linker (the one that is not the
default one) during a configure time? If so we may end up with something like
HAVE_BFD_PUSHPOPSTATE_SUPPORT/HAVE_GOLD_PUSHPOPSTATE_SUPPORT

[Bug middle-end/77624] [5/6/7 Regression] ICE on x86_64-linux-gnu (internal compiler error: in fold_builtin_atomic_always_lock_free, at builtins.c:5583)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 39646
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39646=edit
gcc7-pr77624.patch

Untested fix.

[Bug tree-optimization/77644] New: missed optimization with sqrt in comparison

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 77644
   Summary: missed optimization with sqrt in comparison
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

> cat t.f90
LOGICAL FUNCTION F1(A,B)
  REAL :: A,B
  F1=(abs(A)0 and b>0.

[Bug fortran/71952] [Coarray, F2008] Rejects valid coarray access with array partref

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING

[Bug fortran/77643] New: ICE with "character(len=:), pointer :: p => null()"

[mrestelli at gmail dot com]

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

Bug ID: 77643
   Summary: ICE with "character(len=:), pointer :: p => null()"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrestelli at gmail dot com
  Target Milestone: ---

The attached code produces an internal compiler error. It seems that,
in order to trigger the error, both  LEN=:  and  =>NULL()  are
necessary.


module m
 implicit none
 character(len=:), pointer :: r   ! works
 character(len=5), pointer :: s => null() ! works
 character(len=:), pointer :: p => null() ! ICE
end module m



$ gfortran --version
GNU Fortran (GCC) 7.0.0 20160919 (experimental)


$ gfortran -c m.f90 
f951: internal compiler error: in gfc_get_symbol_decl, bei
fortran/trans-decl.c:1695
0x6b1022 gfc_get_symbol_decl(gfc_symbol*)
gcc/fortran/trans-decl.c:1695
0x6b2e18 gfc_create_module_variable
gcc/fortran/trans-decl.c:4727
0x67b75b do_traverse_symtree
gcc/fortran/symbol.c:3939
0x6b57bb gfc_generate_module_vars(gfc_namespace*)
gcc/fortran/trans-decl.c:5170
0x694319 gfc_generate_module_code(gfc_namespace*)
gcc/fortran/trans.c:2030
0x64bfcb translate_all_program_units
gcc/fortran/parse.c:5923
0x64bfcb gfc_parse_file()
gcc/fortran/parse.c:6142
0x68d7c2 gfc_be_parse_file
gcc/fortran/f95-lang.c:198

[Bug go/77642] New: GO Bootstrap fail starting with r239872 splitstack signature does not match

[krebbel at gcc dot gnu.org]

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

Bug ID: 77642
   Summary: GO Bootstrap fail starting with r239872 splitstack
signature does not match
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: krebbel at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

/home/dailybuild/gnu-dailybuild/arena/20160918/gcc-head/src/libgo/runtime/proc.c:
In function 'doentersyscall':
/home/dailybuild/gnu-dailybuild/arena/20160918/gcc-head/src/libgo/runtime/proc.c:2055:43:
error: passing argument 3 of '__splitstack_find' from incompatible pointer type
[-Werror=incompatible-pointer-types]
  g->gcstack = __splitstack_find(nil, nil, >gcstacksize,
   ^
/home/dailybuild/gnu-dailybuild/arena/20160918/gcc-head/src/libgo/runtime/proc.c:35:14:
note: expected 'size_t * {aka long unsigned int *}' but argument is of type
'uintptr_t * {aka unsigned int *}'
 extern void *__splitstack_find(void *, void *, size_t *, void **, void **,
  ^
/home/dailybuild/gnu-dailybuild/arena/20160918/gcc-head/src/libgo/runtime/proc.c:
In function 'runtime_entersyscallblock':
/home/dailybuild/gnu-dailybuild/arena/20160918/gcc-head/src/libgo/runtime/proc.c:2102:43:
error: passing argument 3 of '__splitstack_find' from incompatible pointer type
[-Werror=incompatible-pointer-types]
  g->gcstack = __splitstack_find(nil, nil, >gcstacksize,
   ^
/home/dailybuild/gnu-dailybuild/arena/20160918/gcc-head/src/libgo/runtime/proc.c:35:14:
note: expected 'size_t * {aka long unsigned int *}' but argument is of type
'uintptr_t * {aka unsigned int *}'
 extern void *__splitstack_find(void *, void *, size_t *, void **, void **,
  ^
/\*
Makefile:2344: recipe for target 'proc.lo' failed
make[8]: *** [proc.lo] Error 1

[Bug sanitizer/77538] segmentation fault: thread sanitizer shadow stack overflow

[dvyukov at google dot com]

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

--- Comment #6 from Dmitry Vyukov  ---
It hangs trying to dump core file to some pipe:

[] pipe_wait+0x70/0xc0
[] pipe_write+0x236/0x5b0
[] do_sync_write+0x8d/0xd0
[] dump_write+0x52/0x70
[] dump_seek+0xa4/0xe0
[] elf_core_dump+0x896/0x950
[] do_coredump+0x882/0xb10
[] get_signal_to_deliver+0x1c7/0x6d0
[] do_signal+0x57/0x6c0
[] do_notify_resume+0x5f/0xb0
[] retint_signal+0x48/0x8c

Tsan allocates 100+TB of virtual memory. It's unsurprising that it hangs. Tsan
should disable core dumps by default (done by DisableCoreDumperIfNecessary
function). Not sure why core dumps are not disabled in your case. Try to run
with TSAN_OPTIONS=disable_coredump=1 environment variable.

[Bug middle-end/66391] suboptimal code for assignment of SImode struct with bitfields

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|middle-end
   Severity|normal  |enhancement

[Bug libstdc++/77641] std::variant copy-initialization fails for type with non-trivial constexpr ctor

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> std::string_view is a literal type, but is not trivially default
> constructible.

Oops, I meant X is a literal type (my original code uses variant but I reduced it to variant for this report).

[Bug libstdc++/77641] std::variant copy-initialization fails for type with non-trivial constexpr ctor

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Testing this:

--- a/libstdc++-v3/include/std/variant
+++ b/libstdc++-v3/include/std/variant
@@ -168,7 +168,7 @@ namespace __variant
   template
 using __storage = typename __storage_type<_Type>::type;

-  template>
+  template>
 struct _Uninitialized;

   template

[Bug libstdc++/77641] std::variant copy-initialization fails for type with non-trivial constexpr ctor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-19
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The problem is the use of is_literal_type in _Uninitialized:

  template>
struct _Uninitialized;

That assumes that a literal type is trivially default-constructible, but that
isn't necessarily true.

std::string_view is a literal type, but is not trivially default constructible.

Is literal type the correct condition? Should it be trivially default
constructible and trivially destructible?

[Bug testsuite/63299] ASan reported alloc-dealloc-mismatch in g++.old-deja/g++.jason/init3.C

[m.ostapenko at samsung dot com]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Maxim Ostapenko  ---
No, the issue isn't reproducible on current trunk. Closing.

[Bug target/76731] [AVX512] _mm512_i32gather_epi32 and other scatter/gather routines have incorrect signature

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Kyrill/Uros, is this something we should change?
Any comments on the #c1 questions?

[Bug c++/77639] [6/7 Regression] ICE on x86_64-linux-gnu (internal compiler error: tree check: accessed elt 1 of tree_vec with 0 elts in unify, at cp/pt.c:19674)

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug target/66433] Arm NEON postincrement optimization missed

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug libstdc++/77641] New: std::variant copy-initialization fails for non-trivial literal type

[redi at gcc dot gnu.org]

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

Bug ID: 77641
   Summary: std::variant copy-initialization fails for non-trivial
literal type
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: timshen at gcc dot gnu.org
  Target Milestone: ---

#include 

struct X {
  constexpr X() { }
};

int main() {
  std::variant v1 = X{};
}

In file included from v.cc:1:0:
/home/jwakely/gcc/7/include/c++/7.0.0/variant: In instantiation of
‘std::__detail::__variant::_Variant_base<_Types>::_Variant_base(std::__detail::__variant::_Variant_base<_Types>&&)
[with _Types = {X}]’:
/home/jwakely/gcc/7/include/c++/7.0.0/variant:995:7:   required from here
/home/jwakely/gcc/7/include/c++/7.0.0/variant:369:44: error: use of deleted
function ‘std::__detail::__variant::_Variant_storage<_First, _Rest
...>::_Variant_storage() [with _First = X; _Rest = {}]’
   : _Storage(), _M_index(__rhs._M_index)
^
/home/jwakely/gcc/7/include/c++/7.0.0/variant:297:17: note:
‘std::__detail::__variant::_Variant_storage<_First, _Rest
...>::_Variant_storage() [with _First = X; _Rest = {}]’ is implicitly deleted
because the default definition would be ill-formed:
   constexpr _Variant_storage() = default;
 ^~~~
/home/jwakely/gcc/7/include/c++/7.0.0/variant:321:36: error: union member
‘std::__detail::__variant::_Variant_storage_M_first’ with
non-trivial ‘constexpr std::__detail::__variant::_Uninitialized<_Type,
true>::_Uninitialized() [with _Type = X]’
  _Uninitialized<__storage<_First>> _M_first;
^~~~
/home/jwakely/gcc/7/include/c++/7.0.0/variant: In instantiation of ‘constexpr
void std::__detail::__variant::__erased_ctor(void*, void*) [with _Lhs = X&;
_Rhs = X&&]’:
/home/jwakely/gcc/7/include/c++/7.0.0/variant:373:30:   required from
‘std::__detail::__variant::_Variant_base<_Types>::_Variant_base(std::__detail::__variant::_Variant_base<_Types>&&)
[with _Types = {X}]’
/home/jwakely/gcc/7/include/c++/7.0.0/variant:995:7:   required from here
/home/jwakely/gcc/7/include/c++/7.0.0/variant:239:58: error: use of
‘decltype(auto) std::__detail::__variant::__get_alternative(void*) [with
_Qualified_storage = X&&]’ before deduction of ‘auto’
 { ::new (__lhs) decay_t<_Lhs>(__get_alternative<_Rhs>(__rhs)); }
   ~~~^~~

[Bug c++/77626] [6/7 Regression] ICE with -Wall on x86_64-linux-gnu (internal compiler error: Segmentation fault, byte_from_pos, cxx_fold_indirect_ref)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 39645
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39645=edit
gcc7-pr77626.patch

Untested fix.

[Bug fortran/77584] Unclassifiable statement error with procedure pointer using template named "structure_"

[foreese at gcc dot gnu.org]

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

--- Comment #2 from foreese at gcc dot gnu.org ---
Author: foreese
Date: Mon Sep 19 11:32:09 2016
New Revision: 240230

URL: https://gcc.gnu.org/viewcvs?rev=240230=gcc=rev
Log:
2016-09-19  Fritz Reese  

PR fortran/77584
* gcc/fortran/decl.c (match_record_decl, gfc_match_decl_type_spec):
Fixes to handling of structure/record from declaration-type-spec.

* gcc/testsuite/gfortran.dg/dec_structure_15.f90: New testcase.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/66339] g++ 5.1.0 Generates memory leak

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Note the pool was made dynamic (and effectively larger) exactly for a QOI
issue...
[the dynamic nature is to make its size controllable by the environment, sth
that didn't materialize yet]

The difficulty with freeing is that it is necessary until the dynamic loader
can get rid of the C++ runtime.  There isn't a way to enforce releasing at that
point
(apart from making it static storage).

[Bug middle-end/77558] [6/7 regression] c-c++-common/va-arg-va-list-type.c fails for arm/aarch64

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
Patch bootstrapped and reg-tested on x86_64.

Patch build and reg-tested on arm, no issues found.

Todo: submit to gcc-patches.

[Bug target/66491] x86_64 target cross-compiler generates stack protector code unsuitable for the Linux kernel if the compiler wasn't built against a C library

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
This is how I build my gcc that is not building against a libc:
# glibc will provide ssp as it is new enough
gcc_cv_libc_provides_ssp=yes  ${PMAKE} configure-gcc || return 1


This is after doing configure too.

[Bug middle-end/77558] [6/7 regression] c-c++-common/va-arg-va-list-type.c fails for arm/aarch64

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #5 from Uroš Bizjak  ---
(In reply to Christophe Lyon from comment #4)
> > Applying the patch from comment 1 fixes this as well.
> 
> Indeed the same patch fixes the ICE on arm. Thanks.

The patch also fixes test for error failure on alpha.

[Bug sanitizer/66514] UBSAN: Add -fsanitize=lifetime

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|REOPENED|NEW
 CC||rguenth at gcc dot gnu.org
  Component|target  |tree-optimization

--- Comment #6 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #5)
> Started to ICE with r230310.

Confirmed.

Reduced testcase fails with -O3 -msse2 -mtune=atom for 32bit and 64bit x86
targets in:

Program received signal SIGSEGV, Segmentation fault.
0x006de13e in tree_class_check (__t=0x0, __class=tcc_type,
__f=0x215b580 "../../git/gcc/gcc/tree-vect-data-refs.c", __l=761, 
__g=0x215d260

"vect_compute_data_ref_alignment")
at ../../git/gcc/gcc/tree.h:3148
3148  if (TREE_CODE_CLASS (TREE_CODE (__t)) != __class)
(gdb) bt
#0  0x006de13e in tree_class_check (__t=0x0, __class=tcc_type,
__f=0x215b580 "../../git/gcc/gcc/tree-vect-data-refs.c", __l=761, 
__g=0x215d260

"vect_compute_data_ref_alignment")
at ../../git/gcc/gcc/tree.h:3148
#1  0x0199f40d in vect_compute_data_ref_alignment (dr=0x29688e0) at
../../git/gcc/gcc/tree-vect-data-refs.c:759

(gdb) f 1
#1  0x0199f40d in vect_compute_data_ref_alignment (dr=0x29688e0) at
../../git/gcc/gcc/tree-vect-data-refs.c:759
759   if (tree_fits_shwi_p (step)
(gdb) list
754   else
755 {
756   tree step = DR_STEP (dr);
757   unsigned vf = loop ? LOOP_VINFO_VECT_FACTOR (loop_vinfo) : 1;
758
759   if (tree_fits_shwi_p (step)
760   && ((tree_to_shwi (step) * vf)
761   % GET_MODE_SIZE (TYPE_MODE (vectype)) != 0))
762 {
763   if (dump_enabled_p ())
(gdb) p vectype
$1 = (tree) 0x0

CC author.

[Bug target/77633] AVX512: shuffle intrinsic has incorrect signature when optimizations are enabled

[wen...@mitsuba-renderer.org]

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

--- Comment #4 from Wenzel Jakob  ---
Aha, interesting -- that breaks it:

test.cpp(9): error: argument of type "int" is incompatible with parameter of
type "_MM_PERM_ENUM={_MM_PERM_ENUM}"
  _mm512_shuffle_epi32(_mm512_setzero_epi32(), _MM_SHUFFLE(0, 3, 0, 1));

Definitely not a very nice API design! I assume the right course of action then
will be to mark this issue INVALID and change my code to cast to _MM_PERM_ENUM?

[Bug libstdc++/66339] g++ 5.1.0 Generates memory leak

[frankhb1989 at gmail dot com]

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

--- Comment #12 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #10)
> This behaviour is by design and is not a bug. Valgrind no longer shows the
> allocation as reachable. Other tools might still show the memory as unfreed,
> but it's still not a bug.

Clarification of "by design" is good. Better put some note elsewhere, maybe. 


(In reply to Jonathan Wakely from comment #11)
> (In reply to frankhb1989 from comment #9)
> > Following your narrow definition of "leak", it implies that any system using
> > GC could never leak. That's absurd.
> 
> Wikipedia: "a memory leak is a type of resource leak that occurs when a
> computer program incorrectly manages memory allocations in such a way that
> memory which is no longer needed is not released."
> 
> This memory is still needed up until exit.
> 
> Google: "a failure in a program to release discarded memory, causing
> impaired performance or failure."
> 
> This is not discarded memory, and does not impair performance or cause
> failure.
> 
> MSDN: "When an application dynamically allocates memory, and does not free
> that memory when it is finished using it, that program has a memory leak."
> 
> The memory is in use right until exit, so the application hasn't finished
> using it.
> 
>  
> > A leak of resource may occur when the client (either the code of the
> > application or the underlying runtime responsible to deal with the allocated
> > resource) has lost the control of the lifetime of that resource.
> 
> The runtime hasn't lost control of it.
> 
> > If that
> > resource is not needed and there is no other way to transfer the ownership,
> > it is leaked.
> 
> It's still needed.
> 
> > Still reachable memory can be leaked, depends on the
> > intention. Sometimes the leak detector has no clue to figure out whether the
> > memory should be still here or not, but we humans have, though it may be
> > arguable.
> > 
> > The situation necessitating "exit()" to cleanup almost always meets the
> > condition of leak above. This is feasible only when the users can rely on
> > the fact that the hosting environment will cleanup the (already leaked)
> > resources of that program (likely in some magical ways unrelated to the
> > program itself). This is not portable in general.
> 
> We're not talking about arbitrary resources in the general case, we're
> talking about heap memory in the GNU C++ runtime. That memory is freed on
> exit. If you want to waffle about it further please take it somewhere else.
> 
> 
> 
>  (And abuse of exit() will
> > easily cause other problems.) I don't see "most" programs do that seriously
> > because it is not easy to guarantee the behavior predictable.


I'm not sure if you are talking about the general cases here.

In general, attributing leaks to unreachable resources despite the need, is
nonsense; as my previous reply.

For this issue, you are correct that GNU C++ runtime does not "cause impaired
performance or failure".

I just know the memory "is still needed" (by the runtime) by design. Fine.

It can still be a QoI issue for user programs because when don't need it (as
the original case), though.

[Bug target/77633] AVX512: shuffle intrinsic has incorrect signature when optimizations are enabled

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Does it work even if you
#define __INTEL_COMPILER_USE_INTRINSIC_PROTOTYPES 1
before including immintrin.h?

[Bug target/77621] [6/7 Regression] Internal compiler error for mtune=atom + msse2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |6.3
Summary|Internal compiler error for |[6/7 Regression] Internal
   |mtune=atom + msse2  |compiler error for
   ||mtune=atom + msse2

--- Comment #5 from Jakub Jelinek  ---
Reduced testcase:
/* { dg-do compile } */
/* { dg-options "-O3" } */
/* { dg-additional-options "-march=i686 -mtune=atom -msse2" { target ia32 } }
*/

void
foo (double *x, int *y)
{
  int i;
  for (i = 0; i < 8; i++)
x[i] -= y[i] * x[i + 1];
}

Started to ICE with r230310.

[Bug c++/77639] [6/7 Regression] ICE on x86_64-linux-gnu (internal compiler error: tree check: accessed elt 1 of tree_vec with 0 elts in unify, at cp/pt.c:19674)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r225706.

[Bug c++/77638] [6/7 Regression] ICE on x86_64-linux-gnu (internal compiler error: tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in cp_parser_template_declaration_

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 39644
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39644=edit
gcc7-pr77638.patch

Untested fix.

[Bug libstdc++/66339] g++ 5.1.0 Generates memory leak

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to frankhb1989 from comment #9)
> Following your narrow definition of "leak", it implies that any system using
> GC could never leak. That's absurd.

Wikipedia: "a memory leak is a type of resource leak that occurs when a
computer program incorrectly manages memory allocations in such a way that
memory which is no longer needed is not released."

This memory is still needed up until exit.

Google: "a failure in a program to release discarded memory, causing impaired
performance or failure."

This is not discarded memory, and does not impair performance or cause failure.

MSDN: "When an application dynamically allocates memory, and does not free that
memory when it is finished using it, that program has a memory leak."

The memory is in use right until exit, so the application hasn't finished using
it.


> A leak of resource may occur when the client (either the code of the
> application or the underlying runtime responsible to deal with the allocated
> resource) has lost the control of the lifetime of that resource.

The runtime hasn't lost control of it.

> If that
> resource is not needed and there is no other way to transfer the ownership,
> it is leaked.

It's still needed.

> Still reachable memory can be leaked, depends on the
> intention. Sometimes the leak detector has no clue to figure out whether the
> memory should be still here or not, but we humans have, though it may be
> arguable.
> 
> The situation necessitating "exit()" to cleanup almost always meets the
> condition of leak above. This is feasible only when the users can rely on
> the fact that the hosting environment will cleanup the (already leaked)
> resources of that program (likely in some magical ways unrelated to the
> program itself). This is not portable in general.

We're not talking about arbitrary resources in the general case, we're talking
about heap memory in the GNU C++ runtime. That memory is freed on exit. If you
want to waffle about it further please take it somewhere else.



 (And abuse of exit() will
> easily cause other problems.) I don't see "most" programs do that seriously
> because it is not easy to guarantee the behavior predictable.

[Bug libstdc++/66339] g++ 5.1.0 Generates memory leak

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
This behaviour is by design and is not a bug. Valgrind no longer shows the
allocation as reachable. Other tools might still show the memory as unfreed,
but it's still not a bug.

[Bug libstdc++/66339] g++ 5.1.0 Generates memory leak

[frankhb1989 at gmail dot com]

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

--- Comment #9 from frankhb1989 at gmail dot com ---
(In reply to Andrew Pinski from comment #8)
> (In reply to frankhb1989 from comment #7)
> > This is definitely a leak from the view of libc. Why is the status INVALID
> > instead of WONTFIX?
> 
> It is still reachable.  Since it is reachable, a pointer at deconstructor
> time could use it.  This pool is used to low memory situations.  And can be
> used even near exit.  There is no leak; a leak means it is no longer
> reachable.
> Most programs will not free some of their memory at the end of their program
> anyways; they would just call exit.

Following your narrow definition of "leak", it implies that any system using GC
could never leak. That's absurd.

A leak of resource may occur when the client (either the code of the
application or the underlying runtime responsible to deal with the allocated
resource) has lost the control of the lifetime of that resource. If that
resource is not needed and there is no other way to transfer the ownership, it
is leaked. Still reachable memory can be leaked, depends on the intention.
Sometimes the leak detector has no clue to figure out whether the memory should
be still here or not, but we humans have, though it may be arguable.

The situation necessitating "exit()" to cleanup almost always meets the
condition of leak above. This is feasible only when the users can rely on the
fact that the hosting environment will cleanup the (already leaked) resources
of that program (likely in some magical ways unrelated to the program itself).
This is not portable in general. (And abuse of exit() will easily cause other
problems.) I don't see "most" programs do that seriously because it is not easy
to guarantee the behavior predictable.

[Bug target/77633] AVX512: shuffle intrinsic has incorrect signature when optimizations are enabled

[wen...@mitsuba-renderer.org]

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

--- Comment #2 from Wenzel Jakob  ---
I just tried compiling this snippet with ICC 17.0.0. It accepts it without
warnings (-Wall -Wconversion -Wextra). So even if the signature is different,
ICC seems to be more relaxed about passing an integer value to an enum
parameter.

[Bug bootstrap/77512] gcc compilation stops with Arithmetic Exception

[michael at mijobe dot org]

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

--- Comment #8 from michael at mijobe dot org ---
will do
think this will take roughly 8 hours ...

[Bug bootstrap/77512] gcc compilation stops with Arithmetic Exception

[ebotcazou at gcc dot gnu.org]

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

--- Comment #7 from Eric Botcazou  ---
> ../gcc-6.2.0/configure --prefix=/export/home2/mi/gcc-6.2.0-bin --with-gnu-as
> --with-gnu-ld --disable-libgcj --enable-languages=c,c++

Please add --build=sparc-sun-solaris2.10 and use an absolute path.

[Bug c++/77637] ICE on x86_64-linux-gnu (Segmentation fault, tree_check, cp_parser_std_attribute_list...)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 39643
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39643=edit
gcc7-pr77637.patch

Untested fix.

[Bug bootstrap/77512] gcc compilation stops with Arithmetic Exception

[michael at mijobe dot org]

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

--- Comment #6 from michael at mijobe dot org ---
../gcc-6.2.0/configure --prefix=/export/home2/mi/gcc-6.2.0-bin --with-gnu-as
--with-gnu-ld --disable-libgcj --enable-languages=c,c++

[Bug debug/77640] New: FDHBNFGJ

[violetblue23 at jr9fds46y97 dot com]

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

Bug ID: 77640
   Summary: FDHBNFGJ
   Product: gcc
   Version: new-ra
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: violetblue23 at jr9fds46y97 dot com
  Target Milestone: ---

THTFYJTYJ

[Bug fortran/77636] OpenMP SIMD rejects an array in ALIGNED clause list

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
GCC doesn't implement OpenMP 4.5 for Fortran yet, only C/C++ so far (WIP for
Fortran is on a branch).  And OpenMP 4.0 says on page 71, lines 14-15:
"The type of list items appearing in the aligned clause must be C_PTR or Cray
pointer, or the list item must have the POINTER or ALLOCATABLE attribute."

[Bug c++/77637] ICE on x86_64-linux-gnu (Segmentation fault, tree_check, cp_parser_std_attribute_list...)

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
This:

commit e829f68a9b1f4f3e34588704710c6e88f3703a28
Author: jason 
Date:   Fri May 8 04:42:06 2015 +

PR c++/59012
* parser.c (cp_parser_std_attribute_list): Handle attribute expansion.
(cp_parser_std_attribute_spec): Handle alignas pack expansion.
* decl2.c (is_late_template_attribute): An attribute exp is dependent.
* pt.c (make_pack_expansion): Allow TREE_LIST for attribute expansion.
(apply_late_template_attributes): Handle attribute pack expansion.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@222902
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/77637] ICE on x86_64-linux-gnu (Segmentation fault, tree_check, cp_parser_std_attribute_list...)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
No, that's the change of default std.

[Bug c++/77637] ICE on x86_64-linux-gnu (Segmentation fault, tree_check, cp_parser_std_attribute_list...)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r225272.

[Bug target/77633] AVX512: shuffle intrinsic has incorrect signature when optimizations are enabled

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Looking at ICC 16.0.2, it uses the same prototypes though, again with
_MM_PERM_ENUM as the type of this argument.
It is true the AVX512 manual states int rather than _MM_PERM_ENUM, so I don't
know what is right.  The reason it "works" with -O0 is that for -O0 it uses
preprocessor macros rather than inline functions, so there is no type checking
whatsoever in that case.