[Bug tree-optimization/77485] Missed dead store elimination of aggregate store followed by partial stores

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Thu, 8 Dec 2016, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77485
> 
> --- Comment #4 from Jeffrey A. Law  ---
> So my patches for 33562 will detect the partial dead store in "foo", but I
> never wrote the bits to narrow partial dead stores.
> 
> The difficulty in optimizing this particular case will be rewriting the
> CONSTRUCTOR node.  Though it may be as simple as walking down the CONSTRUCTOR
> and splicing out components which correspond to dead assignments -- I'll have
> to familiarize myself with the guts of how to walk CONSTRUCTOR nodes. 
> Hopefully they're at least in-order and extracting byte offsets is easy :-)

Should be.

But I still think any "real" DSE work should be done by unifying what
SRA, update-address-taken, store-merging and current DSE do (eventually 
even the bswap pass).  Those are all related and they share basic analysis
(and dataflow) parts and would benefit from each other transform "tricks".

And all of them would benefit from being flow-sensitive in a way to
consider parts of the CFG where for example addresses do not escape
and doing some (eventually expensive) stuff at such (cold?) region 
boundaries.

[Bug rtl-optimization/78671] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213 with -Og -march=skylake-avx512

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Assuming fixed.

[Bug tree-optimization/78731] Possible bug with switch when optimization is turned on.

[wilson at gcc dot gnu.org]

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

--- Comment #2 from Jim Wilson  ---
The compiler is failing in jump threading as called by dom2.  Jeff's 2015-09-30
patch is triggering in dom1, and changing the CFG just enough to prevent the
jump threading bug from triggering.  So it isn't a proper fix.

Disabling it, and bisecting again, I found bug 67892, another patch from Jeff,
which looks like a proper fix.  However, there is a problem.  The bug was
reported against gcc 5, fixed in gcc 6, and then closed, but is still broken in
gcc 5.  I think it is in the wrong state.  Presumably, it should still be open,
and then fixed in gcc 5 if reasonably safe, or documented as a known bug that
we won't fix in gcc 5.

[Bug middle-end/50481] builtin to reverse the bit order

[matthijsvanduin at gmail dot com]

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

Matthijs van Duin  changed:

   What|Removed |Added

 CC||matthijsvanduin at gmail dot 
com

--- Comment #3 from Matthijs van Duin  ---
Bump!  Proper intrinsics for bitreverse would be much appreciated!  A plain C
implementation is ugly and results in equally awful code output, while using
inline asm breaks portability and can't be constant-folded or used in
constexpr.

What makes the continued lack of a __builtin_arm_rbit() in gcc a bit bizarre is
that the (identically named) Neon versions of this instruction on AArch64
actually *did* receive proper intrinsics! [1]

It's worth mentioning that clang does support __builtin_arm_rbit(), and they've
actually generalized this to a full set of target-independent bitreverse
builtins [2].

[1] https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01913.html
[2] http://clang.llvm.org/docs/LanguageExtensions.html#builtin-bitreverse

[Bug c/77531] __attribute__((alloc_size(1,2))) could also warn on multiplication overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #6 from Martin Sebor  ---
Implemented in r243470.

[Bug c/77531] __attribute__((alloc_size(1,2))) could also warn on multiplication overflow

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Author: msebor
Date: Thu Dec  8 23:50:40 2016
New Revision: 243470

URL: https://gcc.gnu.org/viewcvs?rev=243470&root=gcc&view=rev
Log:
PR c/77531 - __attribute__((alloc_size(1,2))) could also warn on multiplication
overflow
PR c/78284 - warn on malloc with very large arguments

gcc/c-family/ChangeLog:

PR c/78284
* c.opt (-Walloc-zero, -Walloc-size-larger-than): New options.

gcc/ChangeLog:

PR c/78284
* builtin-attrs.def (ATTR_ALLOC_SIZE, ATTR_RETURNS_NONNULL): New
identifier tree nodes.
(ATTR_ALLOCA_SIZE_1_NOTHROW_LEAF_LIST): New attribute list.
(ATTR_MALLOC_SIZE_1_NOTHROW_LIST): Same.
(ATTR_MALLOC_SIZE_1_NOTHROW_LEAF_LIST): Same.
(ATTR_MALLOC_SIZE_1_2_NOTHROW_LEAF_LIST): Same.
(ATTR_ALLOC_SIZE_2_NOTHROW_LEAF_LIST): Same.
* builtins.c (expand_builtin_alloca): Call
maybe_warn_alloc_args_overflow.
* builtins.def (aligned_alloc, calloc, malloc, realloc):
Add attribute alloc_size.
(alloca): Add attribute alloc_size and returns_nonnull.
* calls.h (maybe_warn_alloc_args_overflow): Declare.
* calls.c (alloc_max_size, operand_signed_p): New functions.
(maybe_warn_alloc_args_overflow): Define.
(initialize_argument_information): Diagnose overflow in functions
declared with attaribute alloc_size.
* doc/invoke.texi (Warning Options): Document -Walloc-zero and
-Walloc-size-larger-than.

gcc/testsuite/ChangeLog:

PR c/78284
* gcc.dg/attr-alloc_size-3.c: New test.
* gcc.dg/attr-alloc_size-4.c: New test.
* gcc.dg/attr-alloc_size-5.c: New test.
* gcc.dg/attr-alloc_size-6.c: New test.
* gcc.dg/attr-alloc_size-7.c: New test.
* gcc.dg/attr-alloc_size-8.c: New test.
* gcc.dg/attr-alloc_size-9.c: New test.
* gcc/testsuite/gcc.dg/errno-1.c: Adjust.


Added:
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-3.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-4.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-5.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-6.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-7.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-8.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/calls.c
trunk/gcc/calls.h
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/errno-1.c

[Bug c/78284] warn on malloc with very large arguments

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Thu Dec  8 23:50:40 2016
New Revision: 243470

URL: https://gcc.gnu.org/viewcvs?rev=243470&root=gcc&view=rev
Log:
PR c/77531 - __attribute__((alloc_size(1,2))) could also warn on multiplication
overflow
PR c/78284 - warn on malloc with very large arguments

gcc/c-family/ChangeLog:

PR c/78284
* c.opt (-Walloc-zero, -Walloc-size-larger-than): New options.

gcc/ChangeLog:

PR c/78284
* builtin-attrs.def (ATTR_ALLOC_SIZE, ATTR_RETURNS_NONNULL): New
identifier tree nodes.
(ATTR_ALLOCA_SIZE_1_NOTHROW_LEAF_LIST): New attribute list.
(ATTR_MALLOC_SIZE_1_NOTHROW_LIST): Same.
(ATTR_MALLOC_SIZE_1_NOTHROW_LEAF_LIST): Same.
(ATTR_MALLOC_SIZE_1_2_NOTHROW_LEAF_LIST): Same.
(ATTR_ALLOC_SIZE_2_NOTHROW_LEAF_LIST): Same.
* builtins.c (expand_builtin_alloca): Call
maybe_warn_alloc_args_overflow.
* builtins.def (aligned_alloc, calloc, malloc, realloc):
Add attribute alloc_size.
(alloca): Add attribute alloc_size and returns_nonnull.
* calls.h (maybe_warn_alloc_args_overflow): Declare.
* calls.c (alloc_max_size, operand_signed_p): New functions.
(maybe_warn_alloc_args_overflow): Define.
(initialize_argument_information): Diagnose overflow in functions
declared with attaribute alloc_size.
* doc/invoke.texi (Warning Options): Document -Walloc-zero and
-Walloc-size-larger-than.

gcc/testsuite/ChangeLog:

PR c/78284
* gcc.dg/attr-alloc_size-3.c: New test.
* gcc.dg/attr-alloc_size-4.c: New test.
* gcc.dg/attr-alloc_size-5.c: New test.
* gcc.dg/attr-alloc_size-6.c: New test.
* gcc.dg/attr-alloc_size-7.c: New test.
* gcc.dg/attr-alloc_size-8.c: New test.
* gcc.dg/attr-alloc_size-9.c: New test.
* gcc/testsuite/gcc.dg/errno-1.c: Adjust.


Added:
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-3.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-4.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-5.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-6.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-7.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-8.c
trunk/gcc/testsuite/gcc.dg/attr-alloc_size-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/calls.c
trunk/gcc/calls.h
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/errno-1.c

[Bug c/78284] warn on malloc with very large arguments

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Implemented in r243470.

[Bug fortran/78737] linking error with deferred, undefined user-defined derived-type I/O

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
I am not sure what you are expecting. The module has an empty main program and
nothing allocated to link to.. Since the interface is abstract it creates
nothing until it is used I think.

$ gfc pr78737.f03 
/tmp/ccBH9og7.o: In function `__object_interface_MOD_assert':
pr78737.f03:(.text+0x59): undefined reference to `write_formatted_interface_'
collect2: error: ld returned 1 exit status

$ gfc -c pr78737.f03 
$

[Bug tree-optimization/78742] New: internal compiler error: in int_cst_value, at tree.c:10782

[dabler at gmail dot com]

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

Bug ID: 78742
   Summary: internal compiler error: in int_cst_value, at
tree.c:10782
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dabler at gmail dot com
  Target Milestone: ---

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

On x86_64 Linux:

$ gcc -v -save-temps -O3 -o libmp-test.o libmp.c -c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux
Configured with: ../configure --build=x86_64-linux --with-arch=core2
--with-tune=westmere --with-thread=posix --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --with-system-zlib --program-suffix=-5.4
Thread model: posix
gcc version 5.4.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-o' 'libmp-test.o' '-c'
'-mtune=westmere' '-march=core2'
 /usr/local/libexec/gcc/x86_64-linux/5.4.0/cc1 -E -quiet -v libmp.c
-mtune=westmere -march=core2 -O3 -fpch-preprocess -o libmp.i
ignoring duplicate directory
"/usr/local/lib/gcc/x86_64-linux/5.4.0/../../../../x86_64-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/x86_64-linux/5.4.0/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-linux/5.4.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-o' 'libmp-test.o' '-c'
'-mtune=westmere' '-march=core2'
 /usr/local/libexec/gcc/x86_64-linux/5.4.0/cc1 -fpreprocessed libmp.i -quiet
-dumpbase libmp.c -mtune=westmere -march=core2 -auxbase-strip libmp-test.o -O3
-version -o libmp.s
GNU C11 (GCC) version 5.4.0 (x86_64-linux)
compiled by GNU C version 5.4.0, GMP version 4.3.1, MPFR version 2.4.1,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.4.0 (x86_64-linux)
compiled by GNU C version 5.4.0, GMP version 4.3.1, MPFR version 2.4.1,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6af85bd5d50765bfdcb33ae94df5c82d
libmp.c: In function ‘func’:
libmp.c:3:6: internal compiler error: in int_cst_value, at tree.c:10782
 void func()
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ cat libmp.c
void foo();

void func()
{
int m;

int tab[m];

__int128 j;
for(; j; j++)
{
tab[j] = 0;
tab[j+1] = 0;
}

foo();
}

Affected gcc versions I have found: 5.x.x, 6.x.x

[Bug fortran/78737] linking error with deferred, undefined user-defined derived-type I/O

[damian at sourceryinstitute dot org]

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

--- Comment #2 from Damian Rouson  ---
Upon further investigation, the workaround mentioned in the final line of the
original report appears not to work.  The only workaround I have come up with
is to make the "object" type non-abstract, which then necessitates making the
write_formatted binding non-deferred, which then necessitates replacing the
abstract interface with an actual implementation. It's pretty major surgery,
but not the worst problem in the world.

[Bug tree-optimization/77485] Missed dead store elimination of aggregate store followed by partial stores

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
So my patches for 33562 will detect the partial dead store in "foo", but I
never wrote the bits to narrow partial dead stores.

The difficulty in optimizing this particular case will be rewriting the
CONSTRUCTOR node.  Though it may be as simple as walking down the CONSTRUCTOR
and splicing out components which correspond to dead assignments -- I'll have
to familiarize myself with the guts of how to walk CONSTRUCTOR nodes. 
Hopefully they're at least in-order and extracting byte offsets is easy :-)

[Bug fortran/78737] linking error with deferred, undefined user-defined derived-type I/O

[jvdelisle at gcc dot gnu.org]

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

--- Comment #1 from Jerry DeLisle  ---
I cc'ed Paul on this one. Not sure what is going on here, but I will be looking
at it.

[Bug fortran/78350] ICE in gfc_code2string(): Bad code, at fortran/misc.c:193

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|WAITING |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #4 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Closing.

[Bug fortran/65173] ICE while compiling wrong code

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.0
   Severity|minor   |normal

--- Comment #14 from kargl at gcc dot gnu.org ---
Fixed on trunk. Closing.

[Bug fortran/69064] [5/6/7 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when LEN is set to a variable with no explicit type

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|5.5 |7.0
   Severity|minor   |normal

--- Comment #55 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Closing.

[Bug fortran/69859] Non-deterministic ICEs on incomplete character declaration statement

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.0

--- Comment #8 from kargl at gcc dot gnu.org ---
Fixed on trunk.  Closing

[Bug fortran/65173] ICE while compiling wrong code

[kargl at gcc dot gnu.org]

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

--- Comment #13 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec  8 21:26:11 2016
New Revision: 243463

URL: https://gcc.gnu.org/viewcvs?rev=243463&root=gcc&view=rev
Log:
2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.h (gfc_namespace): Remove old_cl_list member.
* parse.c (use_modules, next_statement): old_cl_list is gone.
(clear_default_charlen): Remove no longer used function.
(reject_statement): Do not try ot clean up gfc_charlen structure(s)
that may have been added to a cl_list list.
* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.dg/misplaced_implicit_character.f90: Adjust errors.
* gfortran.dg/charlen_01.f90: New test.
* gfortran.dg/charlen_02.f90: Ditto.
* gfortran.dg/charlen_03.f90: Ditto.
* gfortran.dg/charlen_04.f90: Ditto.
* gfortran.dg/charlen_05.f90: Ditto.
* gfortran.dg/charlen_06.f90: Ditto.
* gfortran.dg/charlen_07.f90: Ditto.
* gfortran.dg/charlen_08.f90: Ditto.
* gfortran.dg/charlen_09.f90: Ditto.
* gfortran.dg/charlen_10.f90: Ditto.
* gfortran.dg/charlen_11.f90: Ditto.
* gfortran.dg/charlen_12.f90: Ditto.
* gfortran.dg/charlen_13.f90: Ditto.
* gfortran.dg/charlen_14.f90: Ditto.
* gfortran.dg/charlen_15.f90: Ditto.
* gfortran.dg/charlen_16.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/charlen_01.f90
trunk/gcc/testsuite/gfortran.dg/charlen_02.f90
trunk/gcc/testsuite/gfortran.dg/charlen_03.f90
trunk/gcc/testsuite/gfortran.dg/charlen_04.f90
trunk/gcc/testsuite/gfortran.dg/charlen_05.f90
trunk/gcc/testsuite/gfortran.dg/charlen_06.f90
trunk/gcc/testsuite/gfortran.dg/charlen_07.f90
trunk/gcc/testsuite/gfortran.dg/charlen_08.f90
trunk/gcc/testsuite/gfortran.dg/charlen_09.f90
trunk/gcc/testsuite/gfortran.dg/charlen_10.f90
trunk/gcc/testsuite/gfortran.dg/charlen_11.f90
trunk/gcc/testsuite/gfortran.dg/charlen_12.f90
trunk/gcc/testsuite/gfortran.dg/charlen_13.f90
trunk/gcc/testsuite/gfortran.dg/charlen_14.f90
trunk/gcc/testsuite/gfortran.dg/charlen_15.f90
trunk/gcc/testsuite/gfortran.dg/charlen_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90

[Bug fortran/69064] [5/6/7 Regression] ICE: in gfc_typenode_for_spec, at fortran/trans-types.c:1062 when LEN is set to a variable with no explicit type

[kargl at gcc dot gnu.org]

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

--- Comment #54 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec  8 21:26:11 2016
New Revision: 243463

URL: https://gcc.gnu.org/viewcvs?rev=243463&root=gcc&view=rev
Log:
2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.h (gfc_namespace): Remove old_cl_list member.
* parse.c (use_modules, next_statement): old_cl_list is gone.
(clear_default_charlen): Remove no longer used function.
(reject_statement): Do not try ot clean up gfc_charlen structure(s)
that may have been added to a cl_list list.
* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.dg/misplaced_implicit_character.f90: Adjust errors.
* gfortran.dg/charlen_01.f90: New test.
* gfortran.dg/charlen_02.f90: Ditto.
* gfortran.dg/charlen_03.f90: Ditto.
* gfortran.dg/charlen_04.f90: Ditto.
* gfortran.dg/charlen_05.f90: Ditto.
* gfortran.dg/charlen_06.f90: Ditto.
* gfortran.dg/charlen_07.f90: Ditto.
* gfortran.dg/charlen_08.f90: Ditto.
* gfortran.dg/charlen_09.f90: Ditto.
* gfortran.dg/charlen_10.f90: Ditto.
* gfortran.dg/charlen_11.f90: Ditto.
* gfortran.dg/charlen_12.f90: Ditto.
* gfortran.dg/charlen_13.f90: Ditto.
* gfortran.dg/charlen_14.f90: Ditto.
* gfortran.dg/charlen_15.f90: Ditto.
* gfortran.dg/charlen_16.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/charlen_01.f90
trunk/gcc/testsuite/gfortran.dg/charlen_02.f90
trunk/gcc/testsuite/gfortran.dg/charlen_03.f90
trunk/gcc/testsuite/gfortran.dg/charlen_04.f90
trunk/gcc/testsuite/gfortran.dg/charlen_05.f90
trunk/gcc/testsuite/gfortran.dg/charlen_06.f90
trunk/gcc/testsuite/gfortran.dg/charlen_07.f90
trunk/gcc/testsuite/gfortran.dg/charlen_08.f90
trunk/gcc/testsuite/gfortran.dg/charlen_09.f90
trunk/gcc/testsuite/gfortran.dg/charlen_10.f90
trunk/gcc/testsuite/gfortran.dg/charlen_11.f90
trunk/gcc/testsuite/gfortran.dg/charlen_12.f90
trunk/gcc/testsuite/gfortran.dg/charlen_13.f90
trunk/gcc/testsuite/gfortran.dg/charlen_14.f90
trunk/gcc/testsuite/gfortran.dg/charlen_15.f90
trunk/gcc/testsuite/gfortran.dg/charlen_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90

[Bug fortran/78350] ICE in gfc_code2string(): Bad code, at fortran/misc.c:193

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec  8 21:26:11 2016
New Revision: 243463

URL: https://gcc.gnu.org/viewcvs?rev=243463&root=gcc&view=rev
Log:
2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.h (gfc_namespace): Remove old_cl_list member.
* parse.c (use_modules, next_statement): old_cl_list is gone.
(clear_default_charlen): Remove no longer used function.
(reject_statement): Do not try ot clean up gfc_charlen structure(s)
that may have been added to a cl_list list.
* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.dg/misplaced_implicit_character.f90: Adjust errors.
* gfortran.dg/charlen_01.f90: New test.
* gfortran.dg/charlen_02.f90: Ditto.
* gfortran.dg/charlen_03.f90: Ditto.
* gfortran.dg/charlen_04.f90: Ditto.
* gfortran.dg/charlen_05.f90: Ditto.
* gfortran.dg/charlen_06.f90: Ditto.
* gfortran.dg/charlen_07.f90: Ditto.
* gfortran.dg/charlen_08.f90: Ditto.
* gfortran.dg/charlen_09.f90: Ditto.
* gfortran.dg/charlen_10.f90: Ditto.
* gfortran.dg/charlen_11.f90: Ditto.
* gfortran.dg/charlen_12.f90: Ditto.
* gfortran.dg/charlen_13.f90: Ditto.
* gfortran.dg/charlen_14.f90: Ditto.
* gfortran.dg/charlen_15.f90: Ditto.
* gfortran.dg/charlen_16.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/charlen_01.f90
trunk/gcc/testsuite/gfortran.dg/charlen_02.f90
trunk/gcc/testsuite/gfortran.dg/charlen_03.f90
trunk/gcc/testsuite/gfortran.dg/charlen_04.f90
trunk/gcc/testsuite/gfortran.dg/charlen_05.f90
trunk/gcc/testsuite/gfortran.dg/charlen_06.f90
trunk/gcc/testsuite/gfortran.dg/charlen_07.f90
trunk/gcc/testsuite/gfortran.dg/charlen_08.f90
trunk/gcc/testsuite/gfortran.dg/charlen_09.f90
trunk/gcc/testsuite/gfortran.dg/charlen_10.f90
trunk/gcc/testsuite/gfortran.dg/charlen_11.f90
trunk/gcc/testsuite/gfortran.dg/charlen_12.f90
trunk/gcc/testsuite/gfortran.dg/charlen_13.f90
trunk/gcc/testsuite/gfortran.dg/charlen_14.f90
trunk/gcc/testsuite/gfortran.dg/charlen_15.f90
trunk/gcc/testsuite/gfortran.dg/charlen_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90

[Bug fortran/69859] Non-deterministic ICEs on incomplete character declaration statement

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Dec  8 21:26:11 2016
New Revision: 243463

URL: https://gcc.gnu.org/viewcvs?rev=243463&root=gcc&view=rev
Log:
2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.h (gfc_namespace): Remove old_cl_list member.
* parse.c (use_modules, next_statement): old_cl_list is gone.
(clear_default_charlen): Remove no longer used function.
(reject_statement): Do not try ot clean up gfc_charlen structure(s)
that may have been added to a cl_list list.
* symbol.c (gfc_new_charlen): old_cl_list structure is gone.

2016-12-07  Steven G. Kargl  

PR fortran/65173
PR fortran/69064
PR fortran/69859
PR fortran/78350
* gfortran.dg/misplaced_implicit_character.f90: Adjust errors.
* gfortran.dg/charlen_01.f90: New test.
* gfortran.dg/charlen_02.f90: Ditto.
* gfortran.dg/charlen_03.f90: Ditto.
* gfortran.dg/charlen_04.f90: Ditto.
* gfortran.dg/charlen_05.f90: Ditto.
* gfortran.dg/charlen_06.f90: Ditto.
* gfortran.dg/charlen_07.f90: Ditto.
* gfortran.dg/charlen_08.f90: Ditto.
* gfortran.dg/charlen_09.f90: Ditto.
* gfortran.dg/charlen_10.f90: Ditto.
* gfortran.dg/charlen_11.f90: Ditto.
* gfortran.dg/charlen_12.f90: Ditto.
* gfortran.dg/charlen_13.f90: Ditto.
* gfortran.dg/charlen_14.f90: Ditto.
* gfortran.dg/charlen_15.f90: Ditto.
* gfortran.dg/charlen_16.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/charlen_01.f90
trunk/gcc/testsuite/gfortran.dg/charlen_02.f90
trunk/gcc/testsuite/gfortran.dg/charlen_03.f90
trunk/gcc/testsuite/gfortran.dg/charlen_04.f90
trunk/gcc/testsuite/gfortran.dg/charlen_05.f90
trunk/gcc/testsuite/gfortran.dg/charlen_06.f90
trunk/gcc/testsuite/gfortran.dg/charlen_07.f90
trunk/gcc/testsuite/gfortran.dg/charlen_08.f90
trunk/gcc/testsuite/gfortran.dg/charlen_09.f90
trunk/gcc/testsuite/gfortran.dg/charlen_10.f90
trunk/gcc/testsuite/gfortran.dg/charlen_11.f90
trunk/gcc/testsuite/gfortran.dg/charlen_12.f90
trunk/gcc/testsuite/gfortran.dg/charlen_13.f90
trunk/gcc/testsuite/gfortran.dg/charlen_14.f90
trunk/gcc/testsuite/gfortran.dg/charlen_15.f90
trunk/gcc/testsuite/gfortran.dg/charlen_16.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/parse.c
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/misplaced_implicit_character.f90

[Bug rtl-optimization/78671] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213 with -Og -march=skylake-avx512

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
Author: vmakarov
Date: Thu Dec  8 21:14:42 2016
New Revision: 243462

URL: https://gcc.gnu.org/viewcvs?rev=243462&root=gcc&view=rev
Log:
2016-12-08  Vladimir Makarov  

PR rtl-optimization/78671
* lra-assign.c (lra-assigns.c): Check prohibited regs for an
allocno class.

2016-12-08  Vladimir Makarov  

PR rtl-optimization/78671
* gcc.target/i386/pr78671.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr78671.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/testsuite/ChangeLog

[Bug c/78165] avoid printing type suffix for constants in %E output

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Committed in r243461.

[Bug c/78165] avoid printing type suffix for constants in %E output

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Thu Dec  8 21:08:06 2016
New Revision: 243461

URL: https://gcc.gnu.org/viewcvs?rev=243461&root=gcc&view=rev
Log:
PR c/78165 - avoid printing type suffix for constants in %E output

gcc/c-family/ChangeLog:

PR c/78165
   * c-pretty-print (pp_c_integer_constant): Avoid formatting type
 suffix.
gcc/testsuite/ChangeLog:


Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pretty-print.c
trunk/gcc/testsuite/g++.dg/debug/dwarf2/integer-typedef.C
trunk/gcc/testsuite/g++.dg/debug/dwarf2/typedef1.C
trunk/gcc/testsuite/g++.dg/inherit/covariant7.C

[Bug middle-end/78738] [7 Regression] ICE in extract_insn, at recog.c:2311

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|rtl-optimization|middle-end
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |7.0

--- Comment #4 from Uroš Bizjak  ---
Testing a patch.

[Bug c++/64380] Missed optimization: smarter dead store elimination in dtors

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-08
 CC||law at redhat dot com
 Ever confirmed|0   |1

[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #9 from Gerhard Steinmetz  
---

Frankly speaking, it's difficile. Smells more invalid than valid.
As a side note, I do not have any production code using a contruct 
similar to that in comment 0 or in recursive_interface_*.


Still affects some examples from testsuite/gfortran.dg :
  - data_value_1.f90
  - recursive_interface_1.f90
  - recursive_interface_2.f90


$ gfortran-7-20161204 -c recursive_interface_1.f90
$ gfortran-7-20161204 -fimplicit-none -c recursive_interface_1.f90
recursive_interface_1.f90:16:0:

   function baz() result(r3)

internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1064
0x7c7b83 gfc_typenode_for_spec(gfc_typespec*, bool)
../../gcc/fortran/trans-types.c:1064
0x7c5c03 gfc_sym_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:2167
0x7c670b gfc_get_function_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:3030
0x7c68bc gfc_get_function_type(gfc_symbol*)
../../gcc/fortran/trans-types.c:3023
0x75130f build_function_decl
../../gcc/fortran/trans-decl.c:2157
0x75674b gfc_create_function_decl(gfc_namespace*, bool)
../../gcc/fortran/trans-decl.c:2833
0x733137 gfc_generate_module_code(gfc_namespace*)
../../gcc/fortran/trans.c:2149
0x6e72fd translate_all_program_units
../../gcc/fortran/parse.c:6025
0x6e72fd gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug rtl-optimization/54421] Extra movdqa when accessing quadwords in a 128-bit SSE register

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #2 from Jeffrey A. Law  ---
It looks like we went through a series of improvements resulting in the current
compiler generating:

   movhlps %xmm0, %xmm1
movq%xmm0, %rdx
movq%xmm1, %rax
orq %rax, %rdx
sete%al
movzbl  %al, %eax
ret


ie, it operates solely on registers and thus avoids the unnecessary stack
loads/stores.

Given it was a progression over time, I'm not going to bisect each improvement.
 It's just not worth the effort.

[Bug middle-end/35302] Missing partial dead store elimination

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #2 from Jeffrey A. Law  ---
Richi fixed this back in 2009:

2009-11-23  Richard Guenther  

* tree-dfa.c (get_ref_base_and_extent): Adjust maximum access
size for DECL bases.

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #15 from Nathan Sidwell  ---
Fixed on 5, 6 & HEAD

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[nathan at gcc dot gnu.org]

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

--- Comment #14 from Nathan Sidwell  ---
Author: nathan
Date: Thu Dec  8 19:27:32 2016
New Revision: 243457

URL: https://gcc.gnu.org/viewcvs?rev=243457&root=gcc&view=rev
Log:
PR c++/78551
* constexpr.c (extract_string_elt): New.  Broken out of ...
(cxx_eval_array_reference): ... here.  Call it.
(cxx_eval_store_expression): Convert init by STRING_CST into
CONSTRUCTOR, if needed.

PR c++/78551
* g++.dg/cpp1y/pr78551.C: New.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/pr78551.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/constexpr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/78733] [7 Regression] bootstrap broken on aarch64-linux-gnu

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from wilco at gcc dot gnu.org ---
Fixed in r243456.

[Bug target/78733] [7 Regression] bootstrap broken on aarch64-linux-gnu

[wilco at gcc dot gnu.org]

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

--- Comment #10 from wilco at gcc dot gnu.org ---
Author: wilco
Date: Thu Dec  8 19:18:33 2016
New Revision: 243456

URL: https://gcc.gnu.org/viewcvs?rev=243456&root=gcc&view=rev
Log:
This patch fixes an issue in aarch64_classify_address.  TImode and TFmode
can either use a 64-bit LDP/STP or 128-bit LDR/STR.  The addressing mode
must be carefully modelled as the intersection of both.  This is done for
the immediate offsets, however load_store_pair_p must be set as well to
avoid LDP with a PC-relative address if aarch64_pcrelative_literal_loads
is true.

gcc/
PR target/78733
* config/aarch64/aarch64.c (aarch64_classify_address):
Set load_store_pair_p for TImode and TFmode.

testsuite/
* gcc.target/aarch64/pr78733.c: New test.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/testsuite/ChangeLog

[Bug other/78252] C++ demangler crashes with infinite recursion with lambda (auto)

[curlypaul924 at gmail dot com]

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

Paul Brannan  changed:

   What|Removed |Added

 CC||curlypaul924 at gmail dot com

--- Comment #4 from Paul Brannan  ---
I can confirm Nathan's patch fixes the crash I was seeing with
_ZSt7forwardIRZN3Foo3BarEvEUlRT_iE_EOS1_RNSt16remove_referenceIS1_E4typeE

[Bug rtl-optimization/78738] [7 Regression] ICE in extract_insn, at recog.c:2311

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Following patch fixes the failure:

--cut here--
Index: toplev.c
===
--- toplev.c(revision 243444)
+++ toplev.c(working copy)
@@ -1691,6 +1691,8 @@ init_excess_precision (void)
 {
   gcc_assert (flag_excess_precision_cmdline != EXCESS_PRECISION_DEFAULT);
   flag_excess_precision = flag_excess_precision_cmdline;
+  if (flag_unsafe_math_optimizations)
+flag_excess_precision = EXCESS_PRECISION_FAST;
 }

 /* Initialize things that are both lang-dependent and target-dependent.
--cut here--

[Bug rtl-optimization/78738] [7 Regression] ICE in extract_insn, at recog.c:2311

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-08
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Uroš Bizjak  ---
Looks like the effect of excess_precision changes.

In i386.h, we define:

/* Whether to allow x87 floating-point arithmetic on MODE (one of
   SFmode, DFmode and XFmode) in the current excess precision
   configuration.  */
#define X87_ENABLE_ARITH(MODE) \
  (flag_excess_precision == EXCESS_PRECISION_FAST || (MODE) == XFmode)

/* Likewise, whether to allow direct conversions from integer mode
   IMODE (HImode, SImode or DImode) to MODE.  */
#define X87_ENABLE_FLOAT(MODE, IMODE)   \
  (flag_excess_precision == EXCESS_PRECISION_FAST   \
   || (MODE) == XFmode  \
   || ((MODE) == DFmode && (IMODE) == SImode)   \
   || (IMODE) == HImode)

and relevant pattern in i386.md:

(define_insn "*fop__comm"
  [(set (match_operand:MODEF 0 "register_operand" "=f,x,v")
(match_operator:MODEF 3 "binary_fp_operator"
  [(match_operand:MODEF 1 "nonimmediate_operand" "%0,0,v")
   (match_operand:MODEF 2 "nonimmediate_operand" "fm,xm,vm")]))]
  "((SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
|| (TARGET_80387 && X87_ENABLE_ARITH (mode)))
   && COMMUTATIVE_ARITH_P (operands[3])
   && !(MEM_P (operands[1]) && MEM_P (operands[2]))"

The testcase generates the insn from ix86_emit_i387_round, where
flag_excess_precision is set to EXCESS_PRECISION_STANDARD.

IMO, we want to set flag_excess_precision to EXCESS_PRECISION_FAST for
-ffast-math.

Confirmed, CC author of the patch.

[Bug c/78666] conflicting attribute alloc_size accepted

[joseph at codesourcery dot com]

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

--- Comment #6 from joseph at codesourcery dot com  ---
On Thu, 8 Dec 2016, msebor at gcc dot gnu.org wrote:

> But what is specifying multiple declarations of the same function with
> different sets of attributes supposed to mean?  Is it supposed to apply the
> union of all of them?  How should conflicts be resolved?  Should the rules be
> expected to be consistent across attributes with different names?

It should be the result of merging them (taking the union), with conflicts 
diagnosed.  What conflicts depends on the attribute in question.  We have 
e.g. the comp_type_attributes hook for targets to use to detect conflicts 
(which x86 uses for regparm and other calling convention attributes).

Note that glibc relies on being able to apply both attributes (hidden 
visibility, at least) and asm renaming to built-in functions after their 
built-in and explicit declarations (see include/string.h).

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[nathan at gcc dot gnu.org]

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

--- Comment #13 from Nathan Sidwell  ---
Author: nathan
Date: Thu Dec  8 18:37:03 2016
New Revision: 243451

URL: https://gcc.gnu.org/viewcvs?rev=243451&root=gcc&view=rev
Log:
PR c++/78551
* constexpr.c (extract_string_elt): New.  Broken out of ...
(cxx_eval_array_reference): ... here.  Call it.
(cxx_eval_store_expression): Convert init by STRING_CST into
CONSTRUCTOR, if needed.

PR c++/78551
* g++.dg/cpp1y/pr78551.C: New.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/pr78551.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/78551] [5/6/7 Regression] Internal compiler error with constexpr initialization of union

[nathan at gcc dot gnu.org]

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

--- Comment #12 from Nathan Sidwell  ---
Author: nathan
Date: Thu Dec  8 18:34:04 2016
New Revision: 243448

URL: https://gcc.gnu.org/viewcvs?rev=243448&root=gcc&view=rev
Log:
PR c++/78551
* constexpr.c (extract_string_elt): New.  Broken out of ...
(cxx_eval_array_reference): ... here.  Call it.
(cxx_eval_store_expression): Convert init by STRING_CST into
CONSTRUCTOR, if needed.

PR c++/78551
* g++.dg/cpp1y/pr78551.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr78551.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69398] [OOP] ICE on class with duplicate dimension attribute specified

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4) 
> The problem is that the class container is built too early (and thus we
> build a container for a scalar class variable).

To fix this, we have the following options:
1) "Rebuild" the class container when the relevant attributes change (such as
DIMENSION). That is probably the simplest solution, but a bit inefficient,
since we build containers that we don't need.
2) Or: Defer the container building to resolution stage, at least for scalar
class variables, since we don't know if a dimension declaration follows
somewhere after the class declaration. This might be a bit more tricky.
3) Defer the container building to resolution stage for all class variables, no
matter if it would be possible earlier. This might be the cleanest solution,
but might require major reworking of CLASS-specific code.

[Bug fortran/78741] New: ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1534

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78741
   Summary: ICE in gfc_get_symbol_decl, at
fortran/trans-decl.c:1534
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

With invalid code (symbol "g" name clash), down to at least 4.8.


$ cat z1.f90
subroutine s(n, x)
   integer :: n
   character(n) :: x
   character, pointer :: z(:)
   x = 'a'
   return
entry g(n, x)
   x = 'b'
contains
   subroutine g
  z(1) = x(1:1)
   end
end


$ gfortran-7-20161204 -c z1.f90
z1.f90:11:0:

   z(1) = x(1:1)

internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1534
0x75b49a gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1533
0x7731af gfc_conv_variable
../../gcc/fortran/trans-expr.c:2494
0x76ee42 gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.c:7771
0x7789e2 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:9821
0x72e687 trans_code
../../gcc/fortran/trans.c:1790
0x75f708 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6271
0x75f557 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5251
0x75f557 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6200
0x6e73d0 translate_all_program_units
../../gcc/fortran/parse.c:6038
0x6e73d0 gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug fortran/69860] ICE on missing end apostrophe with character(kind=4)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #15)
> Confirmed, this ICE is now completely gone on my environment.

Great! Closing.

[Bug testsuite/78740] New: test case powerpc/pr78691-ppc.c fails starting with its introduction in r243335

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 78740
   Summary: test case powerpc/pr78691-ppc.c fails starting with
its introduction in r243335
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

This fails on LE and probably just needs a test case change to restrict where
it runs.

spawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.target/powerpc/pr78691-ppc.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -Os -m32 -S -o
pr78691-ppc.s
cc1: error: -m32 not supported in this configuration
compiler exited with status 1
output is:
cc1: error: -m32 not supported in this configuration

FAIL: gcc.target/powerpc/pr78691-ppc.c (test for excess errors)
Excess errors:
cc1: error: -m32 not supported in this configuration

[Bug fortran/78739] New: ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1477

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 78739
   Summary: ICE in gfc_get_symbol_decl, at
fortran/trans-decl.c:1477
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

A tiny snippet of _invalid_ code, ICEs down to at least 4.8.
Backtrace similar to that of pr68846 comment 4 and pr70864 comment 3.


$ cat z1.f90
function f(n)
   f() = n
end


$ gfortran-7-20161204 -c z1.f90
z1.f90:1:0:

 function f(n)

internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:1477
0x75a352 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1477
0x75e5b7 generate_local_decl
../../gcc/fortran/trans-decl.c:5327
0x71825b do_traverse_symtree
../../gcc/fortran/symbol.c:3994
0x75f412 generate_local_vars
../../gcc/fortran/trans-decl.c:5527
0x75f412 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6206
0x6e73d0 translate_all_program_units
../../gcc/fortran/parse.c:6038
0x6e73d0 gfc_parse_file()
../../gcc/fortran/parse.c:6238
0x72b182 gfc_be_parse_file
../../gcc/fortran/f95-lang.c:202

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
(In reply to Pádraig Brady from comment #15)
> So it would be good to set the "Target Milestone" to 5.5

But it was also fixed for 4.9.4, so that's what the target milestone says.

You can't reliably use that query for "bugs fixed in 5.5" because it doesn't
find bugs fixed in (for example) both 4.9.4 and 5.5

And if we set the milestone to 5.5 you would just have the same problem trying
to find bugs fixed in 4.9.4

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[P at draigBrady dot com]

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

--- Comment #15 from Pádraig Brady  ---
Actually it is backported to 5.

So it would be good to set the "Target Milestone" to 5.5
so this is obvious from this bug and from the list of bugs fixed in 5.5
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&list_id=166767&resolution=FIXED&target_milestone=5.5

thanks!

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[jason at gcc dot gnu.org]

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

--- Comment #14 from Jason Merrill  ---
(In reply to Pádraig Brady from comment #13)
> It would be good to have this backported to the 5 branch.

What do you mean?  I applied the bug fix to the 5 branch back in July (comment
#7), and the testcase fix was applied in August.

[Bug fortran/68225] ICE with -Wrealloc-lhs-all on structure constructor with allocatable scalar component(s)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #8 from Gerhard Steinmetz  
---
Addendum  :


$ cat zzp.f90
program p
   type t
  integer :: a
  character(:), allocatable :: c
   end type
   type(t) :: x
   x = t(a=1)   ; print *, x%a, x%c
   x = t(a=2, c=null()) ; print *, x%a, x%c
   x = t(c=null(), a=3) ; print *, x%a, x%c
   x = t(a=4, c='c4')   ; print *, x%a, x%c
   x = t(a=5)   ; print *, x%a, x%c
   x = t(6, 'c6')   ; print *, x%a, x%c
   x = t(c='c7', a=7)   ; print *, x%a, x%c
   x = t(c=null(), a=8) ; print *, x%a, x%c
   x = t(9, c='c9') ; print *, x%a, x%c
   x = t(10, null()); print *, x%a, x%c
   x = t(11, 'c11') ; print *, x%a, x%c
   x = t(12); print *, x%a, x%c
end


$ gfortran-7-20161204 -O2 zzp.f90
$ a.out
   1
   2
   3
   4 c4
   5
   6 c6
   7 c7
   8
   9 c9
  10
  11 c11
  12



Compiling with -O0 or -Og :

$ gfortran-7-20161204 -g -O0 -Wall -fcheck=all zzp.f90
$ a.out
   1
   2

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x2ad486c4711f in ???
#1  0x2ad486ca38ee in ???
#2  0x410f1a in list_formatted_write_scalar
at ../../../libgfortran/io/write.c:1887
#3  0x4023d7 in p
at .../zzp.f90:9
#4  0x402e53 in main
at .../zzp.f90:19
Segmentation fault

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

[gerhard.steinmetz.fort...@t-online.de]

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

Bug 68439 Summary: ICE in alloc_scalar_allocatable_for_subcomponent_assignment, 
at fortran/trans-expr.c:6711
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68439

   What|Removed |Added

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

[Bug fortran/68225] ICE with -Wrealloc-lhs-all on structure constructor with allocatable scalar component(s)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #7 from Gerhard Steinmetz  
---
*** Bug 68439 has been marked as a duplicate of this bug. ***

[Bug fortran/68439] ICE in alloc_scalar_allocatable_for_subcomponent_assignment, at fortran/trans-expr.c:6711

[gerhard.steinmetz.fort...@t-online.de]

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

Gerhard Steinmetz  changed:

   What|Removed |Added

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

--- Comment #4 from Gerhard Steinmetz  
---

Should compile with no error, it's legal F2008 :
If an allocatable component has no corresponding component-data-source,
then that component has an allocation status of unallocated.

Because this ICE is gone and runtime behaviour is similar to that
described in pr68225, it can now be regarded as a subcase/duplicate.

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

[Bug fortran/69860] ICE on missing end apostrophe with character(kind=4)

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #15 from Gerhard Steinmetz  
---
Confirmed, this ICE is now completely gone on my environment.

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[P at draigBrady dot com]

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

Pádraig Brady  changed:

   What|Removed |Added

 CC||P at draigBrady dot com

--- Comment #13 from Pádraig Brady  ---
It would be good to have this backported to the 5 branch.
thanks

[Bug fortran/69398] [OOP] ICE on class with duplicate dimension attribute specified

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Note that we also have a rejects-valid problem with the following code:


program p
   type t
   end type
   class(t), allocatable :: z
   target :: z(:)
   allocate (z(2))
end


which is rejected with:

allocate (z(2))
  1
Error: Syntax error in ALLOCATE statement at (1)



The problem is that the class container is built too early (and thus we build a
container for a scalar class variable).

[Bug fortran/66544] [F03] ICE on function with procedure-pointer result in combination with implicit none

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> Btw, I don't fully understand why "implicit none" should make any difference
> here.

The problem is that we simply do not know which typespec to give to 'z' (and
thus to 'f'), therefore it stays with BT_UNKNOWN which causes the ICE. When
omitting the 'implicit none', the symbols get typed implicitly, which is not
really correct either.

If you believe it's valid, one could hack around the ICE using BT_VOID or so:

Index: resolve.c
===
--- resolve.c   (revision 243433)
+++ resolve.c   (working copy)
@@ -220,6 +220,8 @@ resolve_procedure_interface (gfc_symbol *sym)
  sym->attr.class_ok = ifc->result->attr.class_ok;
  sym->as = gfc_copy_array_spec (ifc->result->as);
  sym->result = sym;
+ if (sym->ts.type == BT_UNKNOWN && ifc->result->attr.proc_pointer)
+   sym->ts.type = BT_VOID;
}
   else
{


But that's certainly not a very nice and clean solution and I have no idea if
it would produce the expected results at runtime.

I'm still a bit doubtful if it's really valid. Are there any other compilers
which accept such a construct?

[Bug rtl-optimization/78738] [7 Regression] ICE in extract_insn, at recog.c:2311

[doko at gcc dot gnu.org]

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

--- Comment #1 from Matthias Klose  ---
Created attachment 40282
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40282&action=edit
preprocessed source

[Bug rtl-optimization/78738] New: [7 Regression] ICE in extract_insn, at recog.c:2311

[doko at gcc dot gnu.org]

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

Bug ID: 78738
   Summary: [7 Regression] ICE in extract_insn, at recog.c:2311
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

seen with r243219 on i686-linux-gnu, either omitting the -std=c99 or
-ffast-math works around it:

$ cat fractal_cache.i
double a;
long double roundl();
void b() {
  int c = roundl(a);
  b(c);
}

$ gcc -c -O2 -std=c99 -ffast-math fractal_cache.i 
fractal_cache.i: In function 'b':
fractal_cache.i:6:1: error: unrecognizable insn:
 }
 ^
(insn 10 9 11 2 (set (reg:DF 93)
(plus:DF (reg:DF 92)
(reg:DF 95))) "fractal_cache.i":4 -1
 (nil))
fractal_cache.i:6:1: internal compiler error: in extract_insn, at recog.c:2311
0x85c48cf _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0x85c490c _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../src/gcc/rtl-error.c:116
0x8596890 extract_insn(rtx_insn*)
../../src/gcc/recog.c:2311
0x83eb32d instantiate_virtual_regs_in_insn
../../src/gcc/function.c:1589
0x83eb32d instantiate_virtual_regs
../../src/gcc/function.c:1956
0x83eb32d execute
../../src/gcc/function.c:2005
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug libstdc++/42679] RTLD_DEEPBIND dlopen option for shared library that uses libstdc++ std::ostream crashes

[maemarcus at gmail dot com]

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

maemarcus at gmail dot com changed:

   What|Removed |Added

 CC||maemarcus at gmail dot com

--- Comment #23 from maemarcus at gmail dot com ---
FWIW, I came across this issue with SEGFAULT in cerr on g++ 4.8.5.
Interestingly, cout in the same time works fine. Got resolved either by
removing RTLD_DEEPBIND, or by adding -static-libstdc++ to link line. Hint on
adding -fPIC was not helpful, as it is already added everywhere.

Program received signal SIGSEGV, Segmentation fault.
0x77b5af40 in std::ostream::sentry::sentry (this=0x7fffcf10,
__os=...)
at
/build/gcc-4.8-Iyjgor/gcc-4.8-4.8.5/build/x86_64-linux-gnu/libstdc++-v3/include/bits/ostream.tcc:51
51if (__os.tie() && __os.good())

[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #10 from Bill Schmidt  ---
Excellent, thanks.

I am out of the office today but will have a look at this tomorrow.

[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-08
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #9 from Markus Trippelsdorf  ---
Confirmed with -fstack-protector:

Program received signal SIGSEGV, Segmentation fault.
0x10cf2918 in find_alignment_op (insn=0x3fffaf641a00,
base_reg=0x3fffaf580300) at ../../gcc/gcc/config/rs6000/rs6000.c:41445
41445 rtx_insn *and_insn = DF_REF_INSN (base_def_link->ref);
(gdb) l
41440
41441 struct df_link *base_def_link = DF_REF_CHAIN (base_use);
41442 if (!base_def_link || base_def_link->next)
41443   break;
41444
41445 rtx_insn *and_insn = DF_REF_INSN (base_def_link->ref);
41446 and_operation = alignment_mask (and_insn);
41447 if (and_operation != 0)
41448   break;
41449   }
(gdb) p base_def_link->ref->base->insn_info
$1 = (df_insn_info *) 0x0

[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu

[doko at gcc dot gnu.org]

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

--- Comment #8 from Matthias Klose  ---
still seen with r243430, but you need -fstack-protector or
-fstack-protector-strong

[Bug libstdc++/78264] [7 regression] ICE in build_noexcept_spec, at cp/except.c:1196

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

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

[Bug libstdc++/78264] [7 regression] ICE in build_noexcept_spec, at cp/except.c:1196

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  ---
Author: ebotcazou
Date: Thu Dec  8 15:52:11 2016
New Revision: 243443

URL: https://gcc.gnu.org/viewcvs?rev=243443&root=gcc&view=rev
Log:
PR libstdc++/78264
* include/bits/c++config (_GLIBCXX_NOEXCEPT_PARM): Turn _N into _NE.
(_GLIBCXX_NOEXCEPT_QUAL): Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/c++config

[Bug fortran/78737] New: linking error with deferred, undefined user-defined derived-type I/O

[damian at sourceryinstitute dot org]

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

Bug ID: 78737
   Summary: linking error with deferred, undefined user-defined
derived-type I/O
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

A linking error results when an abstract type defers a user-defined derived
type output binding that is not implemented anywhere in the program:

$ cat undefined-ud-dtio.f90 
module object_interface
  type, abstract :: object
  contains
procedure(write_formatted_interface), deferred ::write_formatted 
generic :: write(formatted)=>write_formatted
  end type 
  abstract interface
subroutine write_formatted_interface(this,unit,iotype,vlist,iostat,iomsg)
  import object
  class(object), intent(in) :: this
  integer, intent(in) :: unit
  character (len=*), intent(in) :: iotype
  integer, intent(in) :: vlist(:)
  integer, intent(out) :: iostat
  character (len=*), intent(inout) :: iomsg
end subroutine
  end interface
contains
  subroutine assert(a)
class(object):: a
write(*,*) a 
  end subroutine
end module

end

$ gfortran undefined-ud-dtio.f90 
Undefined symbols for architecture x86_64:
  "_write_formatted_interface_", referenced from:
  ___object_interface_MOD_assert in ccMQHXbf.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
rouson@localhost:~/xfr$ gfortran --version
GNU Fortran (MacPorts gcc7 7-20161127_0) 7.0.0 20161127 (experimental)

Adding a type that defines the binding eliminates the linking error.

[Bug c/78666] conflicting attribute alloc_size accepted

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
They sure are!  (We should document it.)

But what is specifying multiple declarations of the same function with
different sets of attributes supposed to mean?  Is it supposed to apply the
union of all of them?  How should conflicts be resolved?  Should the rules be
expected to be consistent across attributes with different names?

FWIW, I would be inclined to accept just the set of attributes on the first
declaration and ignore all the others (with a warning), and give an error on
conflicts in the same declaration.

Alternatively, take a union of non-conflicting attributes across all
declarations and warn about conflicts.  This would suffer from the problem that
if the function were called after only a subset of its declarations were seen
only the set of attributes seen so far would likely apply (and it would likely
change with optimization and inlining.)

[Bug target/78733] [7 Regression] bootstrap broken on aarch64-linux-gnu

[wilco at gcc dot gnu.org]

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

--- Comment #9 from wilco at gcc dot gnu.org ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00653.html

[Bug middle-end/78726] [5/6/7 Regression] Incorrect unsigned arithmetic optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug ipa/77674] [7 Regression] ICE in binds_to_current_def_p with -fkeep-inline-functions

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka  ---
I am testing the following:
Index: symtab.c
===
--- symtab.c(revision 243291)
+++ symtab.c(working copy)
@@ -2214,6 +2214,8 @@ symtab_node::binds_to_current_def_p (sym
 {
   if (!definition)
 return false;
+  if (transparent_alias)
+return symtab_node::binds_to_current_def_p (get_alias_target ());
   if (decl_binds_to_current_def_p (decl))
 return true;

[Bug tree-optimization/78720] [7 Regression] Illegal instruction in generated code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Already the >> -14 looks wrong.

[Bug libstdc++/67807] [5/6/7 Regression] call to public member function catalog failed on Linux -std=c++03

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
The testcase doesn't show any problem, and nothing fails as claimed.

The return value 1 does not mean opening the catalog failed, it is not an error
code, it's a handle for a catalog. After calling do_open() twice you have two
different handles (which happen to refer to the same catalog, but that's beside
the point).

The behaviour you see is conforming, and not a bug.

[Bug c/78666] conflicting attribute alloc_size accepted

[joseph at codesourcery dot com]

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

--- Comment #4 from joseph at codesourcery dot com  ---
Multiple format attributes for the same function, naming different 
arguments as a format string, are perfectly valid; they mean the function 
uses multiple format strings (each of which has to match the arguments 
indicated by the attribute).

[Bug tree-optimization/78720] [7 Regression] Illegal instruction in generated code

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization

--- Comment #4 from Markus Trippelsdorf  ---
From:

void foo() ()   
{   
  signed char var_13.0_1;   
  signed char _2;   
  int _3;   
  int _4;   
  int _5;   
  long int _6;  

   [0.0%]:
  var_13.0_1 = var_13;  
  _2 = var_13.0_1 >> -14;   
  _3 = (int) _2;
  _4 = _3 & 2097152;
  _5 = 1 % _4;  
  _6 = (long int) _5;   
  rrr = _6; 
  return;   

}

To (ccp1):

void foo() ()   
{   
  signed char var_13.0_1;   
  int _5;   
  long int _6;  

   [0.0%]:
  var_13.0_1 = var_13;  
  _5 = 1 % 0;   
  _6 = (long int) _5;   
  rrr = _6; 
  return;   

}

[Bug middle-end/78720] [7 Regression] Illegal instruction in generated code

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c/78736] enum warnings in GCC

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
And it's included in -Wall

[Bug fortran/61767] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1491

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to janus from comment #9)
> Thus: The patch in comment #7 should be discarded, and comment #5 is the way
> to go here.

I just realized that also comment #5 is not fully correct. Instead the problem
originates from a different place: The function 'has_finalizer_component' is
buggy and can be fixed like this ...



Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (revision 243433)
+++ gcc/fortran/class.c (working copy)
@@ -841,20 +841,19 @@ has_finalizer_component (gfc_symbol *derived)
gfc_component *c;

   for (c = derived->components; c; c = c->next)
-{
-  if (c->ts.type == BT_DERIVED && c->ts.u.derived->f2k_derived
- && c->ts.u.derived->f2k_derived->finalizers)
-   return true;
+if (c->ts.type == BT_DERIVED && !c->attr.pointer && !c->attr.allocatable)
+  {
+   if (c->ts.u.derived->f2k_derived
+   && c->ts.u.derived->f2k_derived->finalizers)
+ return true;

-  /* Stop infinite recursion through this function by inhibiting
-calls when the derived type and that of the component are
-the same.  */
-  if (c->ts.type == BT_DERIVED
- && !gfc_compare_derived_types (derived, c->ts.u.derived)
- && !c->attr.pointer && !c->attr.allocatable
- && has_finalizer_component (c->ts.u.derived))
-   return true;
-}
+   /* Stop infinite recursion through this function by inhibiting
+ calls when the derived type and that of the component are
+ the same.  */
+   if (!gfc_compare_derived_types (derived, c->ts.u.derived)
+   && has_finalizer_component (c->ts.u.derived))
+ return true;
+  }
   return false;
 }

[Bug libstdc++/77459] [6 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #14 from Jonathan Wakely  ---
Fixed for 6.3

[Bug libstdc++/71856] [6/7 Regression] _GLIBCXX_DEBUG-mode breaks GNU parallel extension

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #13 from Jonathan Wakely  ---
Fixed for 6.3

[Bug libstdc++/71856] [6/7 Regression] _GLIBCXX_DEBUG-mode breaks GNU parallel extension

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
Author: redi
Date: Thu Dec  8 12:41:07 2016
New Revision: 243436

URL: https://gcc.gnu.org/viewcvs?rev=243436&root=gcc&view=rev
Log:
PR71856 try to fix Parallel Mode assertions again

PR libstdc++/71856
* doc/xml/manual/using.xml: Document macro.
* include/bits/c++config [_GLIBCXX_DEBUG || _GLIBCXX_PARALLEL]
(__glibcxx_assert): Rename to __glibcxx_assert_impl.
[_GLIBCXX_DEBUG] (__glibcxx_assert): Expand to __glibcxx_assert_impl.
* include/parallel/base.h [_GLIBCXX_PARALLEL_ASSERTIONS]
(_GLIBCXX_PARALLEL_ASSERT): Expand to __glibcxx_assert_impl.
[!_GLIBCXX_PARALLEL_ASSERTIONS] (_GLIBCXX_PARALLEL_ASSERT): Define as
empty.
* testsuite/25_algorithms/headers/algorithm/
parallel_algorithm_assert2.cc: New test.

Added:
   
branches/gcc-6-branch/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/doc/xml/manual/using.xml
branches/gcc-6-branch/libstdc++-v3/include/bits/c++config
branches/gcc-6-branch/libstdc++-v3/include/parallel/base.h

[Bug libstdc++/77459] [6 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
Author: redi
Date: Thu Dec  8 12:40:58 2016
New Revision: 243435

URL: https://gcc.gnu.org/viewcvs?rev=243435&root=gcc&view=rev
Log:
PR77459 avoid snprintf for debug mode diagnostics

Backport from mainline
2016-11-10  François Dumont  

PR libstdc++/77459
* src/c++11/debug.cc (format_word): Delete.
(print_literal): New. Replace call to print_word for literals.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/src/c++11/debug.cc

[Bug c/78736] enum warnings in GCC

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
We already have -Wenum-compare if that's what you want.

[Bug middle-end/78716] [7 Regression] ICE in gimplify_va_arg_expr, at gimplify.c:12650 (i686-linux-gnu)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c/78736] New: enum warnings in GCC

[erika.molnar at cyberthorstudios dot com]

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

Bug ID: 78736
   Summary: enum warnings in GCC
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erika.molnar at cyberthorstudios dot com
  Target Milestone: ---

Hi,

This is not a bug but when compiling with gcc-6.2 the following code:

***
#include 

typedef enum {brandon, jon, mitch} name_t;
typedef enum {fred, dog, cat} name2_t;
name2_t name = brandon;
name_t hik = 3;


int hal_entry(void)
{

if (hik < name)

return(0);
return 1;
}

int main ()
{
printf ("%d\n", hal_entry());
return 0;
}
***

There is no warning about the enum(which is correct in C) however when I
compile the same code with a different/proprietary compiler I get the following
warning:

W0511180:The evaluation period has expired.
../src/cc.c(33):W0520188:Enumerated type mixed with another type
../src/cc.c(34):W0520188:Enumerated type mixed with another type


Would you consider implementing such a warning in GCC?

__
Thank you,
Erika Molnar

[Bug libstdc++/71856] [6/7 Regression] _GLIBCXX_DEBUG-mode breaks GNU parallel extension

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
Author: redi
Date: Thu Dec  8 12:08:14 2016
New Revision: 243434

URL: https://gcc.gnu.org/viewcvs?rev=243434&root=gcc&view=rev
Log:
PR71856 try to fix Parallel Mode assertions again

PR libstdc++/71856
* doc/xml/manual/using.xml: Document macro.
* include/bits/c++config [_GLIBCXX_DEBUG || _GLIBCXX_PARALLEL]
(__glibcxx_assert): Rename to __glibcxx_assert_impl.
[_GLIBCXX_DEBUG] (__glibcxx_assert): Expand to __glibcxx_assert_impl.
* include/parallel/base.h [_GLIBCXX_PARALLEL_ASSERTIONS]
(_GLIBCXX_PARALLEL_ASSERT): Expand to __glibcxx_assert_impl.
[!_GLIBCXX_PARALLEL_ASSERTIONS] (_GLIBCXX_PARALLEL_ASSERT): Define as
empty.
* testsuite/25_algorithms/headers/algorithm/
parallel_algorithm_assert2.cc: New test.

Added:
   
trunk/libstdc++-v3/testsuite/25_algorithms/headers/algorithm/parallel_algorithm_assert2.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/doc/xml/manual/using.xml
trunk/libstdc++-v3/include/bits/c++config
trunk/libstdc++-v3/include/parallel/base.h

[Bug target/78733] [7 Regression] bootstrap broken on aarch64-linux-gnu

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #8 from wilco at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #7)
> (In reply to Matthias Klose from comment #6)
> > yes, I'm configuring with --enable-fix-cortex-a53-843419
> 
> And running the testsuite with -mfix-cortex-a53-843419 shows the failures.
> 
> So the problem is visible with either -mcmodel=tiny or
> -mfix-cortex-a53-843419

It's -mpc-relative-literal-loads (which is set by both). There is an issue in
aarch64_classify_address that doesn't correctly identify TI/TFmode as possible
LDP/STP instructions. I'm testing a fix.

[Bug rtl-optimization/78735] New: profiledbootstrap with --enable-checking=yes,rtl fails on trunk due to -Werror=strict-overflow

[sirl at gcc dot gnu.org]

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

Bug ID: 78735
   Summary: profiledbootstrap with --enable-checking=yes,rtl fails
on trunk due to -Werror=strict-overflow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Hi,

current trunk (tried r243299 and r243376) on x86_64 fails a profiledbootstrap
with --enable-checking=yes,rtl like that:

/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/./prev-gcc/xg++
-B/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/./prev-gcc/
-B/usr/x86_64-suse-linux/bin/ -nostdinc++
-B/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/src/.libs
-B/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/libsupc++/.libs

-I/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include/x86_64-suse-linux

-I/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/include
 -I/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/libstdc++-v3/libsupc++
-L/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/src/.libs
-L/home/fsirl/rpmbuild/BUILD/gcc-7.0.0-r243376/obj-x86_64-suse-linux/prev-x86_64-suse-linux/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchronous-unwind-tables -U_FORTIFY_SOURCE -fprofile-use -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include 
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc/../libbacktrace   -o combine.o -MT combine.o -MMD -MP -MF
./.deps/combine.TPo ../../gcc/combine.c
In file included from ../../gcc/combine.c:83:0:
../../gcc/combine.c: In function 'int recog_for_combine(rtx_def**, rtx_insn*,
rtx_def**)':
../../gcc/rtl.h:1076:17: error: assuming signed overflow does not occur when
assuming that (X - c) > X is always false [-Werror=strict-overflow]
  if (_i < 0 || _i >= GET_NUM_ELEM (_rtvec))\
 ^
../../gcc/rtl.h:702:45: note: in definition of macro 'GET_CODE'
 #define GET_CODE(RTX) ((enum rtx_code) (RTX)->code)
 ^~~
../../gcc/rtl.h:1298:28: note: in expansion of macro 'RTVEC_ELT'
 #define XVECEXP(RTX, N, M) RTVEC_ELT (XVEC (RTX, N), M)
^
../../gcc/combine.c:11088:21: note: in expansion of macro 'XVECEXP'
   if (GET_CODE (XVECEXP (pat, 0, i)) == CLOBBER
 ^~~
../../gcc/rtl.h:1076:17: error: assuming signed overflow does not occur when
assuming that (X - c) > X is always false [-Werror=strict-overflow]
  if (_i < 0 || _i >= GET_NUM_ELEM (_rtvec))\
 ^
../../gcc/rtl.h:702:45: note: in definition of macro 'GET_CODE'
 #define GET_CODE(RTX) ((enum rtx_code) (RTX)->code)
 ^~~
../../gcc/rtl.h:1298:28: note: in expansion of macro 'RTVEC_ELT'
 #define XVECEXP(RTX, N, M) RTVEC_ELT (XVEC (RTX, N), M)
^
../../gcc/combine.c:11088:21: note: in expansion of macro 'XVECEXP'
   if (GET_CODE (XVECEXP (pat, 0, i)) == CLOBBER
 ^~~
../../gcc/rtl.h:1076:17: error: assuming signed overflow does not occur when
assuming that (X - c) > X is always false [-Werror=strict-overflow]
  if (_i < 0 || _i >= GET_NUM_ELEM (_rtvec))\
 ^
../../gcc/rtl.h:702:45: note: in definition of macro 'GET_CODE'
 #define GET_CODE(RTX) ((enum rtx_code) (RTX)->code)
 ^~~
../../gcc/rtl.h:1298:28: note: in expansion of macro 'RTVEC_ELT'
 #define XVECEXP(RTX, N, M) RTVEC_ELT (XVEC (RTX, N), M)
^
../../gcc/combine.c:11088:21: note: in expansion of macro 'XVECEXP'
   if (GET_CODE (XVECEXP (pat, 0, i)) == CLOBBER
 ^~~
More of the same errors follow. A simple "make bootstrap" works fine.

The build (actually the SRCRPM from OBS with updated sources) was configured
like that:

CFLAGS='-O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchronous-unwind-tables -U_FORTIFY_SOURCE'
CXXFLAGS='-O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -funwind-tables
-fasynchronous-unwind-tables -U_FORTIFY_SOURCE'
XCFLAGS='-O2 -g -fmessage-length=0 -D_FORTIFY_SOURCE=2 -funw

[Bug libstdc++/78264] [7 regression] ICE in build_noexcept_spec, at cp/except.c:1196

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #7 from Eric Botcazou  ---
It's the new macro in c++config:

#if __cpp_noexcept_function_type
#define _GLIBCXX_NOEXCEPT_PARM , bool _N
#define _GLIBCXX_NOEXCEPT_QUAL noexcept (_N)
#else
#define _GLIBCXX_NOEXCEPT_PARM
#define _GLIBCXX_NOEXCEPT_QUAL
#endif

See this comment a few lines below in the same file:

// This marks string literals in header files to be extracted for eventual
// translation.  It is primarily used for messages in thrown exceptions; see
// src/functexcept.cc.  We use __N because the more traditional _N is used
// for something else under certain OSes (see BADNAMES).
#define __N(msgid) (msgid)

Testing trivial fix...

[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-checking
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org
   Target Milestone|--- |7.0

--- Comment #13 from ktkachov at gcc dot gnu.org ---
Looks like dump_minipool should be doing a copy_rtx before emitting the
patterns.

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

[pmderodat at gcc dot gnu.org]

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

--- Comment #19 from pmderodat at gcc dot gnu.org ---
Author: pmderodat
Date: Thu Dec  8 11:04:11 2016
New Revision: 243433

URL: https://gcc.gnu.org/viewcvs?rev=243433&root=gcc&view=rev
Log:
Add the missing ChangeLog entry for r243432

2016-12-08  Pierre-Marie de Rodat  

PR debug/78112
* g++.dg/pr78112.C: Remove platform-dependent checks.
* g++.dg/pr78112-2.C: New testcase.

Modified:
trunk/gcc/testsuite/ChangeLog

[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes

[pmderodat at gcc dot gnu.org]

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

--- Comment #18 from pmderodat at gcc dot gnu.org ---
Author: pmderodat
Date: Thu Dec  8 11:01:03 2016
New Revision: 243432

URL: https://gcc.gnu.org/viewcvs?rev=243432&root=gcc&view=rev
Log:
[PR78112] Remove platform-dependent checks in g++.dg/pr78112.C

... as there checks failed on many platforms. As a replacement, this
commit also adds a new testcase from source reduction. The hope is that
this new testcase will get a consistent output across all platforms.

gcc/testsuite/
PR debug/78112
* g++.dg/pr78112.C: Remove platform-dependent checks.
* g++.dg/pr78112-2.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/pr78112-2.C
Modified:
trunk/gcc/testsuite/g++.dg/pr78112.C

[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074

[amker at gcc dot gnu.org]

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

--- Comment #9 from amker at gcc dot gnu.org ---
Author: amker
Date: Thu Dec  8 10:56:41 2016
New Revision: 243431

URL: https://gcc.gnu.org/viewcvs?rev=243431&root=gcc&view=rev
Log:
PR middle-end/78684
* tree-vect-loop-manip.c (create_intersect_range_checks_index): Check
sign bit for index step of data reference.
gcc/testsuite
PR middle-end/78684
* g++.dg/torture/pr78684.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr78684.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop-manip.c

[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2

[sebastian.hu...@embedded-brains.de]

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

--- Comment #12 from Sebastian Huber  ---
Its strange that it is so hard to reproduce.  Maybe it has something to do with
the default architecture version.

It fails with:

-mthumb -O2 -ftls-model=local-exec -march=armv4t
-mthumb -O2 -ftls-model=local-exec -march=armv5t
-mthumb -O2 -ftls-model=local-exec -march=armv6

It works with:

-mthumb -O2 -ftls-model=local-exec -march=armv7

[Bug tree-optimization/78721] [7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in set_value_range, at tree-vrp.c:371

[kugan at gcc dot gnu.org]

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

kugan at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kugan at gcc dot gnu.org

--- Comment #3 from kugan at gcc dot gnu.org ---
Created attachment 40280
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40280&action=edit
untested patch

[Bug libstdc++/77459] [6 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-08
 Ever confirmed|0   |1

--- Comment #12 from Jonathan Wakely  ---
I'm backporting this to gcc-6-branch too.

[Bug middle-end/78726] [5/6/7 Regression] Incorrect unsigned arithmetic optimization

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Most likely one of the endless reassoc bugs not properly updating or
invalidating range information.  Before reassoc1 we have:
  # RANGE [4294967040, 4294967295]
  a_11 = (unsigned int) _3;
  c.1_4 = c;
  # RANGE [0, 255] NONZERO 255
  _5 = (unsigned int) c.1_4;
  # RANGE ~[1, 4294902015]
  _6 = _5 * a_11;
  # RANGE ~[1, 4278320895]
  _7 = _5 * _6;
which looks correct, a_11 is int [-256, 1] converted to unsigned int, and c is
unsigned char.
But reassoc1 turns this into:
  # RANGE [4294967040, 4294967295]
  a_11 = (unsigned int) _3;
  c.1_4 = c;
  # RANGE [0, 255] NONZERO 255
  _5 = (unsigned int) c.1_4;
  # RANGE ~[1, 4278320895]
  _7 = _5 * _5;
  _13 = _7 + 1023094746;
  _14 = _13 * a_11;
It should have reused the SSA_NAME (_7) for something different, _5 * _5 has a
range of [0, 65025] and could have been used in debug stmts later on.

[Bug rtl-optimization/78727] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

[marxin at gcc dot gnu.org]

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

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

[Bug rtl-optimization/78727] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

[marxin at gcc dot gnu.org]

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

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

[Bug rtl-optimization/78727] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

[marxin at gcc dot gnu.org]

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

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

[Bug rtl-optimization/78728] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

[Bug rtl-optimization/78730] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

[Bug rtl-optimization/78729] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2656 (error: flow control insn inside a basic block)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

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