[Bug tree-optimization/78574] [7 Regression] ice on valid C code at -O2 and -O3 in both 32- and 64-bit modes on x86_64-linux-gnu (internal compiler error: Segmentation fault (program cc1))

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #7 from Markus Trippelsdorf  ---
fixed

[Bug libstdc++/78677] New: __gthread_key_create assumed not to fail in eh_globals.cc

[chrisj at rtems dot org]

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

Bug ID: 78677
   Summary: __gthread_key_create assumed not to fail in
eh_globals.cc
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrisj at rtems dot org
  Target Milestone: ---

Some operating system, for example RTEMS, may fail to create a POSIX key if not
configured with enough resources. The lack of any error reporting in
__eh_globals_init::__eh_globals_init() means exceptions are silently switched
from thread safe to not being thread safe and this is not a concern for RTEMS.

A way to report errors would be welcomed by RTEMS. We could hook this is a
fatal error so the user is aware there is a critical issue that needs to be
addressed.

Thanks
Chris

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

[wilson at gcc dot gnu.org]

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

--- Comment #17 from Jim Wilson  ---
I still haven't been able to reproduce this, but I do see a problem.

In the original bug report, the only difference is that the code uses x4 in the
first part of the diff, and x24 in the second part of the diff, which seems
unimportant.  However, this value lives across a call to memcpy.  x24 is a safe
register here because it is callee saved.  x4 is not safe though, as it is an
argument passing/return value register, which may be clobbered by a call. 
Whether it gets clobbered depends on the memcpy implementation that is linked
with.  If people are linking with different memcpy implementations, that might
affect whether the bug is reproducible.

Disassembling my testcase, I don't see the same code sequence though.  I see
  401530:   d2800802mov x2, #0x40   // #64
  401534:   52800b01mov w1, #0x58   // #88
  401538:   aa1303e0mov x0, x19
  40153c:   94d1bl  401880 
  401540:   9121c324add x4, x25, #0x870
  401544:   91001663add x3, x19, #0x5   
which is OK, because the "add x3, x19, #0x5" instruction comes after the memset
call.

Maybe there is something subtly different about how I'm configuring or building
the toolchain that results in the different LTO optimized code.

[Bug fortran/78676] Optimizer bug exposed by program with many bit operations.

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Try -fwrapv .

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

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Nope, backports are needed.

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

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
No, we probably still want backports.

[Bug fortran/78676] Optimizer bug exposed by program with many bit operations.

[mecej4 at operamail dot com]

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

--- Comment #2 from mecej4 at operamail dot com ---
(In reply to Andrew Pinski from comment #1)
> This sounds like overflows are happening. Overflow in fortran is undefined.

Very much so, but integer overflow happens a lot in random number generation
routines, where the algorithms usually employ unsigned integer arithmetic.
There is a long tradition of Fortran compilers ignoring integer overflow and
this feature is being exploited to implement RNG programs. 

If the compiler's error trapping capability includes detecting integer
overflow, that should be turned off for running the test program (or
Marsaglia's RNG software). For example, with the NAG Fortran compiler the -C
option makes some checking happen, but integer overflow is not checked. There
is a -C=all option that traps overflow, so it should definitely not be used.

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

[asolokha at gmx dot com]

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

--- Comment #3 from Arseny Solokha  ---
Should this PR be closed now?

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

[asolokha at gmx dot com]

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

--- Comment #10 from Arseny Solokha  ---
Should this PR be closed now?

[Bug fortran/78676] Optimizer bug exposed by program with many bit operations.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This sounds like overflows are happening. Overflow in fortran is undefined.

[Bug fortran/78676] New: Optimizer bug exposed by program with many bit operations.

[mecej4 at operamail dot com]

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

Bug ID: 78676
   Summary: Optimizer bug exposed by program with many bit
operations.
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mecej4 at operamail dot com
  Target Milestone: ---

Created attachment 40244
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40244=edit
Test program to demonstrate bug; run with (i) -O and (ii) -O2, and compare the
output

The attached test program runs and gives correct results when compiled with
Gfortran 6.2 without any optimization or with -O. It gives incorrect results
when compiled with -O2. Since the program works entirely with integer
variables, exact results are to be expected.

The bug was encountered when running George Marsaglia's KISS random number
generator, see http://mathforum.org/kb/message.jspa?messageID=6914945 . His
benchmark program runs a billion iterations, whereas the attached program does
only ten iterations. The errors appear to be small but, by increasing the
parameter QSIZ to a few millions, it can be seen that the errors grow
catastrophically. 

Again, since no real number arithmetic is involved, there is no expectation of
obtaining different results on different platforms. The results given by
Gfortran with -O or without any optimization are in agreement with results from
other compilers (NAG, Intel).

[Bug tree-optimization/78675] New: [7 Regression] ICE: verify_gimple failed (error: integral result type precision does not match field size of BIT_FIELD_REF)

[asolokha at gmx dot com]

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

Bug ID: 78675
   Summary: [7 Regression] ICE: verify_gimple failed (error:
integral result type precision does not match field
size of BIT_FIELD_REF)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-pc-linux-gnu

gcc-7.0.0-alpha20161127 and gcc-7.0.0-alpha20161204 snapshots ICE when
compiling the following reduced snippet w/ -O3 (or -Ofast) -mavx512[??]:

long int br;

long int
cm (long int og)
{
  long int yh;

  while (br < 1)
{
  yh = br && og;
  ++br;
}

  return yh;
}

% x86_64-pc-linux-gnu-gcc-7.0.0-alpha20161204 -O3 -mavx512bw -c uwzruiav.c 
uwzruiav.c: In function 'cm':
uwzruiav.c:4:1: error: integral result type precision does not match field size
of BIT_FIELD_REF
 cm (long int og)
 ^~
BIT_FIELD_REF 
cc1: note: in statement
_51 = BIT_FIELD_REF ;
uwzruiav.c:4:1: internal compiler error: verify_gimple failed

[Bug middle-end/17308] nonnull attribute not as useful as it could

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Sebor  ---
Testing a patch.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[kkojima at gcc dot gnu.org]

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

--- Comment #6 from Kazumoto Kojima  ---
I've tried a bi-sect on git tree.  The ICE went away with

commit c95f3fa2db12f22bbb2158d18c95f6714b4292b8
Author: krebbel 
Date:   Fri Dec 2 08:32:40 2016 +

Do not simplify "(and (reg) (const bit)" to if_then_else.

which corresponds to

2016-12-02  Dominik Vogt  

* combine.c (combine_simplify_rtx):  Suppress replacement of
"(and (reg) (const_int bit))" with "if_then_else".

on svn.  The ICE pops up again with reverting it on HAED.
I don't get what was going on without it, though.

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle  ---
Note: PR66310 is a related issue.

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

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-05
 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
I will look at this one. Ian, thanks for the testing. We have had very little
feedback on this new feature. Much appreciated. Yes technically invalid but I
cab examine closer.

[Bug middle-end/78519] missing warning for sprintf %s with null pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic, patch

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg00304.html

[Bug other/61460] Demangler crash (GDB PR 17043)

[mark at gcc dot gnu.org]

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

--- Comment #3 from Mark Wielaard  ---
The patch proposed in bug #70909 does prevent the infinite recursiong crashing
the demangler. But it doesn't demangle the symbol (just rejects it).

[Bug other/67738] infinite recursion in libiberty/cp-demangle.c

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

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

--- Comment #4 from Mark Wielaard  ---
The patch proposed form bug 70909 does prevent the infinite recursion, but that
doesn't help demangling the symbol. See the comments in bug #70909 which
suggest the demangling should be:

[Bug c++/70909] Libiberty Demangler segfaults (4)

[mark at gcc dot gnu.org]

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

--- Comment #38 from Mark Wielaard  ---
For reference the symbols in comment #4 and the reduced case from comment #14
are fixed by the patch proposed for Bug 78252 - C++ demangler crashes with
infinite recursion with lambda (auto).

The patch proposed for this bug is for generic infinite recursion protection
for symbols like in the original description (or fuzzed ones like in bug
#67264).

[Bug other/67264] Infinite recursion of demangler on fuzzed input

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org
 Depends on||70909

--- Comment #3 from Mark Wielaard  ---
The proposed patch for Bug 70909 - Libiberty Demangler segfaults (4) stops
these kind of infinite recursion.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
[Bug 70909] Libiberty Demangler segfaults (4)

[Bug c++/68383] Demangler stack overflow

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org
 Depends on||78252

--- Comment #15 from Mark Wielaard  ---
This seems related to Bug 78252 - C++ demangler crashes with infinite recursion
with lambda (auto). With the patch proposed in for that bug this demangles to:

Write::DataMapGrammar::DataMapGrammar()::{lambda(auto&)#1} const&
std::forward::DataMapGrammar()::{lambda(auto&)#1}
const&>(std::remove_reference::DataMapGrammar()::{lambda(auto&)#1} const&>::type&)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78252
[Bug 78252] C++ demangler crashes with infinite recursion with lambda (auto)

[Bug fortran/78674] [cleanup] merge gfc_convert_type_warn and gfc_convert_chartype

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-04
   Assignee|unassigned at gcc dot gnu.org  |janus at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug other/61805] Demangler crash (GDB PR 17157)

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #2 from Mark Wielaard  ---
GNU c++filt (GNU Binutils) 2.27.51.20161118 doesn't crash and demangles it to:

std::enable_if::type niven::Color::operator/(float) const

[Bug other/62279] Demangler crash

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org

--- Comment #6 from Mark Wielaard  ---
This seems to have been resolved some time ago and now (GNU c++filt (GNU
Binutils) 2.27.51.20161118) demangles to:

QList
Utils::transform(ProjectExplorer::BuildConfiguration::knownStepLists()
const::{lambda(ProjectExplorer::BuildStepList*)#1} const&,
ProjectExplorer::BuildConfiguration::knownStepLists()
const::{lambda(ProjectExplorer::BuildStepList*)#1})

[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

  Attachment #40154|0   |1
is obsolete||

--- Comment #12 from Janne Blomqvist  ---
Created attachment 40243
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40243=edit
Updated patch

Updated patch with a few more improvements. Still fails the char_result_8.f90
testcase with -O1, though.

[Bug fortran/45516] [F08] allocatable compontents of recursive type

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #11 from Paul Thomas  ---
I had thought about applying it to 6-branch but leaving it for a decent period
has made it too late :-(

Closing the PR

Paul

[Bug fortran/39627] [meta-bug] Fortran 2008 support

[pault at gcc dot gnu.org]

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

Bug 45516 Summary: [F08] allocatable compontents of recursive type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45516

   What|Removed |Added

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

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #33 from janus at gcc dot gnu.org ---
(In reply to janus from comment #30)
> It might even be a good idea to merge the two functions into one, in order
> to get rid of the code duplication. But I'm not sure if there are any
> obstacles. Will open a follow-up PR to investigate this.

I have opened PR 78674 for this.

[Bug fortran/78674] New: [cleanup] merge gfc_convert_type_warn and gfc_convert_chartype

[janus at gcc dot gnu.org]

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

Bug ID: 78674
   Summary: [cleanup] merge gfc_convert_type_warn and
gfc_convert_chartype
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

Follow-up to PR78618 ...

The functions gfc_convert_type_warn and gfc_convert_chartype in intrinsic.c
have a lot of code duplication. The latter is almost a subset / special case of
the former.

One should investigate whether it's possible to merge both into one general
function.

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #32 from janus at gcc dot gnu.org ---
r243232 should fix the failure of char_conversion.f90, so I'm closing this PR
for good.

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #31 from janus at gcc dot gnu.org ---
Author: janus
Date: Sun Dec  4 20:31:26 2016
New Revision: 243232

URL: https://gcc.gnu.org/viewcvs?rev=243232=gcc=rev
Log:
2016-12-04  Janus Weil  

PR fortran/78618
* intrinsic.c (gfc_convert_type_warn): Do not set the full typespec for
the conversion symbol, but only type and kind. Set the full typespec
for the expression.
(gfc_convert_chartype): Ditto.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.c

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #30 from janus at gcc dot gnu.org ---
(In reply to janus from comment #29)
> I'm now regtesting this:

No failures! Will commit this soon.

For gfc_convert_type_warn the changes are possibly not really necessary (since
it deals with non-char types which normally do not have a charlen), but they do
not hurt either.

It might even be a good idea to merge the two functions into one, in order to
get rid of the code duplication. But I'm not sure if there are any obstacles.
Will open a follow-up PR to investigate this.

[Bug c++/69481] ICE with C++11 alias using with templates

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

 CC||tulipawn at gmail dot com

--- Comment #10 from PeteVine  ---
I've just hit the same ICE trying to build HHVM on aarch64 with g++7 20161202:

[  5%] Building CXX object
third-party/folly/CMakeFiles/folly.dir/src/folly/ThreadCachedArena.cpp.o
In file included from
/mnt/odroid/hhvm/third-party/folly/folly/detail/ThreadLocalDetail.h:32:0,
 from
/mnt/odroid/hhvm/third-party/folly/folly/ThreadLocal.h:59,
 from
/mnt/odroid/hhvm/third-party/folly/folly/ThreadCachedArena.h:24,
 from
/mnt/odroid/hhvm/third-party/folly/src/folly/ThreadCachedArena.cpp:17:
/mnt/odroid/hhvm/third-party/folly/folly/Function.h:653:3: internal compiler
error: same canonical type node for different types
folly::Function::Traits and
folly::detail::function::FunctionTraits
   SharedProxy asSharedProxy() && {
   ^~~
[  5%] Building CXX object
third-party/folly/CMakeFiles/folly.dir/src/folly/ThreadCachedArena.cpp.o
In file included from
/mnt/odroid/hhvm/third-party/folly/folly/detail/ThreadLocalDetail.h:32:0,
 from
/mnt/odroid/hhvm/third-party/folly/folly/ThreadLocal.h:59,
 from
/mnt/odroid/hhvm/third-party/folly/folly/ThreadCachedArena.h:24,
 from
/mnt/odroid/hhvm/third-party/folly/src/folly/ThreadCachedArena.cpp:17:
/mnt/odroid/hhvm/third-party/folly/folly/Function.h:653:3: internal compiler
error: same canonical type node for different types
folly::Function::Traits and
folly::detail::function::FunctionTraits
   SharedProxy asSharedProxy() && {
   ^~~

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #29 from janus at gcc dot gnu.org ---
I'm now regtesting this:


Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c (revision 243224)
+++ gcc/fortran/intrinsic.c (working copy)
@@ -4984,12 +4984,14 @@ gfc_convert_type_warn (gfc_expr *expr, gfc_typespe
   new_expr->value.function.name = sym->lib_name;
   new_expr->value.function.isym = sym;
   new_expr->where = old_where;
+  new_expr->ts = *ts;
   new_expr->rank = rank;
   new_expr->shape = gfc_copy_shape (shape, rank);

   gfc_get_ha_sym_tree (sym->name, _expr->symtree);
   new_expr->symtree->n.sym->result = new_expr->symtree->n.sym;
-  new_expr->symtree->n.sym->ts = *ts;
+  new_expr->symtree->n.sym->ts.type = ts->type;
+  new_expr->symtree->n.sym->ts.kind = ts->kind;
   new_expr->symtree->n.sym->attr.flavor = FL_PROCEDURE;
   new_expr->symtree->n.sym->attr.function = 1;
   new_expr->symtree->n.sym->attr.elemental = 1;
@@ -5055,11 +5057,13 @@ gfc_convert_chartype (gfc_expr *expr, gfc_typespec
   new_expr->value.function.name = sym->lib_name;
   new_expr->value.function.isym = sym;
   new_expr->where = old_where;
+  new_expr->ts = *ts;
   new_expr->rank = rank;
   new_expr->shape = gfc_copy_shape (shape, rank);

   gfc_get_ha_sym_tree (sym->name, _expr->symtree);
-  new_expr->symtree->n.sym->ts = *ts;
+  new_expr->symtree->n.sym->ts.type = ts->type;
+  new_expr->symtree->n.sym->ts.kind = ts->kind;
   new_expr->symtree->n.sym->attr.flavor = FL_PROCEDURE;
   new_expr->symtree->n.sym->attr.function = 1;
   new_expr->symtree->n.sym->attr.elemental = 1;

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[dominiq at lps dot ens.fr]

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

--- Comment #28 from Dominique d'Humieres  ---
> Do you mean gfc_convert_type_warn?

Yes, copy with two left thumbs!-(

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #27 from Steve Kargl  ---
On Sun, Dec 04, 2016 at 07:17:52PM +, dominiq at lps dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618
> 
> --- Comment #25 from Dominique d'Humieres  ---
> Confirmed here too!
> 
> There is a similar construct for gfc_convert_chartype. Should not the same
> patch apply there too?
> 

Do you mean gfc_convert_type_warn?  The answer is 'probably, yes'.

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #26 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #25)
> There is a similar construct for gfc_convert_chartype. Should not the same
> patch apply there too?

I guess you mean gfc_convert_type_warn? gfc_convert_chartype is what my patch
in comment 21 deals with.

Except for this confusion, you're probably right ...

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[dominiq at lps dot ens.fr]

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

--- Comment #25 from Dominique d'Humieres  ---
Confirmed here too!

There is a similar construct for gfc_convert_chartype. Should not the same
patch apply there too?

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #24 from janus at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #23)
> > This fixes the SIGSEGV on i686-*-freebsd.  I'm starting
> > a full regression test now.  I think you found the 
> > solution!
> 
> Regression testing on x86_64-*-freebsd completed.
> It seems that you've found the fix.  Patch is OK
> to commit.

Great! Thank god we finally nailed this one. Will commit soon ...

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #23 from Steve Kargl  ---
On Sun, Dec 04, 2016 at 06:43:08PM +, sgk at troutmask dot
apl.washington.edu wrote:
> 
> This fixes the SIGSEGV on i686-*-freebsd.  I'm starting
> a full regression test now.  I think you found the 
> solution!

Regression testing on x86_64-*-freebsd completed.
It seems that you've found the fix.  Patch is OK
to commit.  Thanks for in the dark on this issue.

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
I think we need __builtin_memchr et al to be usable in constant expressions,
because replacing them with hand-written loops would be a step backwards. For
uses outside constant expressions we want to go to libc and benefit from the
optimization work put into the libc routines.

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #22 from Steve Kargl  ---
On Sun, Dec 04, 2016 at 06:01:29PM +, janus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618
> 
> --- Comment #21 from janus at gcc dot gnu.org ---
> (In reply to janus from comment #20)
> > So I guess one should find out where the symbol '__convert_s4_s1' obtains
> > its charlen and prevent that from happening ...
> 
> 
> I think that this is accomplished by the following:
> 
> Index: gcc/fortran/intrinsic.c
> ===
> --- gcc/fortran/intrinsic.c (revision 243224)
> +++ gcc/fortran/intrinsic.c (working copy)
> @@ -5055,11 +5055,13 @@ gfc_convert_chartype (gfc_expr *expr, gfc_typespec
>new_expr->value.function.name = sym->lib_name;
>new_expr->value.function.isym = sym;
>new_expr->where = old_where;
> +  new_expr->ts = *ts;
>new_expr->rank = rank;
>new_expr->shape = gfc_copy_shape (shape, rank);
> 
>gfc_get_ha_sym_tree (sym->name, _expr->symtree);
> -  new_expr->symtree->n.sym->ts = *ts;
> +  new_expr->symtree->n.sym->ts.type = ts->type;
> +  new_expr->symtree->n.sym->ts.kind = ts->kind;
>new_expr->symtree->n.sym->attr.flavor = FL_PROCEDURE;
>new_expr->symtree->n.sym->attr.function = 1;
>new_expr->symtree->n.sym->attr.elemental = 1;
> 
> 
> Could someone please check if that helps?
> 

This fixes the SIGSEGV on i686-*-freebsd.  I'm starting
a full regression test now.  I think you found the 
solution!

[Bug c/78673] sprintf missing attribute nonnull on destination argument

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-12-04
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Testing a patch.

[Bug c/78673] New: sprintf missing attribute nonnull on destination argument

[msebor at gcc dot gnu.org]

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

Bug ID: 78673
   Summary: sprintf missing attribute nonnull on destination
argument
   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: ---

Thew first argument of the sprintf function designates the destination into
which the function writes the formatted output followed a terminating nul
character.  Thus the argument must be a non-null pointer.  The declarations of
GCC sprintf built-ins (sprintf, vsprintf, and their checking counterparts) are
missing attribute nonnull on their first argument.  The test case below shows
that the built-ins do have the attribute on the format argument (hence the
-Wnonnull warning).  It also shows that the -Wformat-length option duplicates
the warning in the null pointer constant cases.

$ cat a.c && gcc -S -Wall -Wextra -Wpedantic a.c
void f0 (char *d)
{
  __builtin_sprintf (d, (char*)0);
}

void f1 (void)
{
  __builtin_sprintf ((char*)0, "%i", 1);   // missing warning
}

void f2 (char *d, __builtin_va_list va)
{
  __builtin_vsprintf (d, (char*)0, va);
}

void f3 (__builtin_va_list va)
{
  __builtin_vsprintf ((char*)0, "%i", va);   // missing warning
}

void f4 (char *d, unsigned n)
{
  __builtin___sprintf_chk (d, 0, n, (char*)0);
}

void f5 (unsigned n)
{
  __builtin___sprintf_chk ((char*)0, 0, n, "%i", 1);   // missing warning
}

void f6 (char *d, unsigned n, __builtin_va_list va)
{
  __builtin___vsprintf_chk (d, 0, n, (char*)0, va);
}

void f7 (unsigned n, __builtin_va_list va)
{
  __builtin___vsprintf_chk ((char*)0, 0, n, "%i", va);   // missing warning
}


a.c: In function ‘f0’:
a.c:3:3: warning: null argument where non-null required (argument 2)
[-Wnonnull]
   __builtin_sprintf (d, (char*)0);
   ^
a.c: In function ‘f2’:
a.c:13:3: warning: null argument where non-null required (argument 2)
[-Wnonnul]
   __builtin_vsprintf (d, (char*)0, va);
   ^~
a.c:13:3: warning: too many arguments for format [-Wformat-extra-args]
a.c: In function ‘f4’:
a.c:23:3: warning: null argument where non-null required (argument 4)
[-Wnonnul]
   __builtin___sprintf_chk (d, 0, n, (char*)0);
   ^~~
a.c: In function ‘f6’:
a.c:33:3: warning: null argument where non-null required (argument 4)
[-Wnonnul]
   __builtin___vsprintf_chk (d, 0, n, (char*)0, va);
   ^~~~
a.c:33:3: warning: too many arguments for format [-Wformat-extra-args]
a.c: In function ‘f0’:
a.c:1:6: warning: null format string [-Wformat-length=]
 void f0 (char *d)
  ^~
a.c: In function ‘f2’:
a.c:11:6: warning: null format string [-Wformat-length=]
 void f2 (char *d, __builtin_va_list va)
  ^~
a.c: In function ‘f4’:
a.c:21:6: warning: null format string [-Wformat-length=]
 void f4 (char *d, unsigned n)
  ^~
a.c: In function ‘f6’:
a.c:31:6: warning: null format string [-Wformat-length=]
 void f6 (char *d, unsigned n, __builtin_va_list va)
  ^~

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #21 from janus at gcc dot gnu.org ---
(In reply to janus from comment #20)
> So I guess one should find out where the symbol '__convert_s4_s1' obtains
> its charlen and prevent that from happening ...


I think that this is accomplished by the following:

Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c (revision 243224)
+++ gcc/fortran/intrinsic.c (working copy)
@@ -5055,11 +5055,13 @@ gfc_convert_chartype (gfc_expr *expr, gfc_typespec
   new_expr->value.function.name = sym->lib_name;
   new_expr->value.function.isym = sym;
   new_expr->where = old_where;
+  new_expr->ts = *ts;
   new_expr->rank = rank;
   new_expr->shape = gfc_copy_shape (shape, rank);

   gfc_get_ha_sym_tree (sym->name, _expr->symtree);
-  new_expr->symtree->n.sym->ts = *ts;
+  new_expr->symtree->n.sym->ts.type = ts->type;
+  new_expr->symtree->n.sym->ts.kind = ts->kind;
   new_expr->symtree->n.sym->attr.flavor = FL_PROCEDURE;
   new_expr->symtree->n.sym->attr.function = 1;
   new_expr->symtree->n.sym->attr.elemental = 1;


Could someone please check if that helps?

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[baker at usgs dot gov]

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

--- Comment #14 from Larry Baker  ---
(In reply to Waldemar Brodkorb from comment #11)

> diff -Nur gcc.orig/libgcc/config.host gcc/libgcc/config.host
> --- gcc.orig/libgcc/config.host   2016-02-26 21:02:28.0 +0100
> +++ gcc/libgcc/config.host2016-04-29 09:18:40.377989160 +0200
> @@ -812,7 +812,7 @@
>  m68k*-*-openbsd*)
> ;;
>  m68k-*-uclinux*)   # Motorola m68k/ColdFire running uClinux with uClibc
> -   tmake_file="$tmake_file m68k/t-floatlib m68k/t-linux"
> +   tmake_file="$tmake_file m68k/t-floatlib"
> md_unwind_header=m68k/linux-unwind.h
> ;;
>  m68k-*-linux*) # Motorola m68k's running GNU/Linux

This is exactly the same patch I was referring to in Comment #9 that I used to
work around the problem for gcc 4.7 and 4.8 in 2012 (see Bug 53833).

[Bug c++/68700] demangler failed with signal 11

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org
 Depends on||78252

--- Comment #2 from Mark Wielaard  ---
This seems related to Bug 78252 - C++ demangler crashes with infinite recursion
with lambda (auto)

With the patch proposed for that bug the symbol demangles to:

service::storage_proxy::init_messaging_service()::{lambda(unsigned int,
utils::UUID)#10}::operator()(unsigned int, utils::UUID)
const::{lambda(auto&&)#1} futurize::apply(unsigned int,
service::storage_proxy::init_messaging_service()::{lambda(unsigned int,
utils::UUID)#10}::operator()(unsigned int, utils::UUID)
const::{lambda(auto&&)#1})::{lambda()#1}&>(future
seastar::sharded::invoke_on(unsigned int,
service::storage_proxy::init_messaging_service()::{lambda(unsigned int,
utils::UUID)#10}::operator()(unsigned int, utils::UUID)
const::{lambda(auto&&)#1})::{lambda()#1}&)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78252
[Bug 78252] C++ demangler crashes with infinite recursion with lambda (auto)

[Bug other/70517] c++filt crashes when demangling a symbol

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org
 Depends on||78252

--- Comment #4 from Mark Wielaard  ---
This related to Bug 78252 - C++ demangler crashes with infinite recursion with
lambda (auto)

With the patch proposed for that bug there is no crash anymore and the symbols
demangle.

_ZSt4moveIRZN11tconcurrent6futureIvE4thenIZ5awaitIS2_EDaOT_EUlRKS6_E_EENS1_INSt5decayIDTclfp_defpTEEE4typeEEES7_EUlvE_EONSt16remove_referenceIS6_E4typeES7_

demangles to:

std::remove_reference tconcurrent::future::then >(tconcurrent::future&&)::{lambda(auto&&
const&)#1}>(auto await(tconcurrent::future&&)::{lambda(auto&& const&)#1}&&
const)::{lambda()#1}&>::type&&
std::move
tconcurrent::future::then
>(tconcurrent::future
tconcurrent::future::then
>(tconcurrent::future&&)::{lambda(auto&& const&)#1}>(auto
await(tconcurrent::future&&)::{lambda(auto&&
const&)#1}&& const)::{lambda()#1}&)::{lambda(auto&&
const&)#1}>(tconcurrent::future
tconcurrent::future::then
>(tconcurrent::future&&)::{lambda(auto&& const&)#1}>(auto
await(tconcurrent::future&&)::{lambda(auto&&
const&)#1}&& const)::{lambda()#1}&
const)::{lambda()#1}&>(tconcurrent::future tconcurrent::future::then >(tconcurrent::future&&)::{lambda(auto&&
const&)#1}>(auto await(tconcurrent::future&&)::{lambda(auto&& const&)#1}&&
const)::{lambda()#1}& const)

_Z4moveIRZ5awaitIRiEDaOT_EUlRKS3_E_ES4_S4_

demangles to:

auto await(int&)::{lambda(auto&& const&)#1}& const move(auto await(int&)::{lambda(auto&& const&)#1}&)::{lambda(auto&&
const&)#1}&>(auto await(int&)::{lambda(auto&& const&)#1}& const)

_Z4moveIRZ5awaitIRiEDaOT_EUlRKS2_E_ES3_S3_

demangles to:

auto await(int&)::{lambda(auto const&)#1}& move(auto
await(int&)::{lambda(auto const&)#1}&)::{lambda(auto const&)#1}&>(auto
await(int&)::{lambda(auto const&)#1}&)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78252
[Bug 78252] C++ demangler crashes with infinite recursion with lambda (auto)

[Bug c/78668] aligned_alloc, realloc, et al. missing attribute alloc_size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Blocks||78284
 Resolution|--- |FIXED

--- Comment #3 from Martin Sebor  ---
Fixed by r243231.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78284
[Bug 78284] warn on malloc with very large arguments

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

Bug 78668 Summary: aligned_alloc, realloc, et al. missing attribute alloc_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78668

   What|Removed |Added

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

[Bug c/78668] aligned_alloc, realloc, et al. missing attribute alloc_size

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Sun Dec  4 17:48:44 2016
New Revision: 243231

URL: https://gcc.gnu.org/viewcvs?rev=243231=gcc=rev
Log:
PR c/78668 - aligned_alloc, realloc, et al. missing attribute alloc_size

gcc/ChangeLog:

PR c/78668
* 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.def (aligned_alloc, calloc, malloc, realloc):
Add attribute alloc_size.
(alloca): Add attribute alloc_size and returns_nonnull.

gcc/testsuite/ChangeLog:

PR c/78668
* gcc.dg/builtin-alloc-size.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/builtin-alloc-size.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtin-attrs.def
trunk/gcc/builtins.def
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #20 from janus at gcc dot gnu.org ---
Possibly the origin of the problem lies in the fact that the symbol
'__convert_s4_s1' gets a constant ts.u.cl of '1' after all?

IIUC __convert_s4_s1 is used to convert character strings of any length. So any
expression involving this function can have a constant charlen (which equals to
the charlen of the function argument). But the function symbol itself does not
have a particular charlen associated with it, since it can be applied to
different arguments, right?

So I guess one should find out where the symbol '__convert_s4_s1' obtains its
charlen and prevent that from happening ...

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #19 from janus at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #18)
> On Sun, Dec 04, 2016 at 04:24:21PM +, janus at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618
> > 
> > Maybe one can instead try to nullify the memory in gfc_free charlen, so 
> > that we
> > at least know that cl->lengh is not a valid pointer? (Something similar is 
> > also
> > done in gfc_free_expr / free_expr0 in expr.c.)
> > 
> > Index: symbol.c
> > ===
> > --- symbol.c(revision 243224)
> > +++ symbol.c(working copy)
> > @@ -3838,6 +3838,7 @@ gfc_free_charlen (gfc_charlen *cl, gfc_charlen *en
> > 
> >cl2 = cl->next;
> >gfc_free_expr (cl->length);
> > +  memset (cl, '\0', sizeof (gfc_charlen));
> >free (cl);
> >  }
> >  }
> > 
> 
> Doesn't that leak memory?  The 'free(cl)' in the line
> after memset() should be a NOP, so whatever cl pointed
> to before the memset() is leaked.

I guess memset does not nullify the pointer 'cl' itself, but the memory it
points to, right? (As mentioned, we do the same thing in gfc_free_expr.)


> Hmmm, doesn't seem to help.

Too bad :(

[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[janus at gcc dot gnu.org]

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

--- Comment #16 from janus at gcc dot gnu.org ---
(In reply to janus from comment #15)
> > Interpretation request F08/0001 / 10-145 changes this ("EDITS to 10-007")"
> > 
> > '[286:4] In 12.4.3.4.5p3, after "the other has the POINTER attribute",
> > Insert "and not the INTENT(IN) attribute".'
> > Cf. http://j3-fortran.org/doc/meeting/193/10-199.txt
> 
> Unfortunately this was forgotten in the above commit. To do!

That is, we need to reject this example, because both interfaces are compatible
with the call (i.e. they are not distinguishable):

  INTERFACE gen
SUBROUTINE suba(a)
  REAL,ALLOCATABLE :: a(:)
END SUBROUTINE
SUBROUTINE subp(p)
  REAL,POINTER,INTENT(IN) :: p(:)
END SUBROUTINE
  END INTERFACE
  REAL,ALLOCATABLE,TARGET :: x(:)
  ALLOCATE(x(100))
  CALL gen(x)
end

For the explanation see the link above.

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

[mark at gcc dot gnu.org]

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

Mark Wielaard  changed:

   What|Removed |Added

 CC||mark at gcc dot gnu.org
Summary|C++ demangler crashes with  |C++ demangler crashes with
   |infinite recursion  |infinite recursion with
   ||lambda (auto)

--- Comment #3 from Mark Wielaard  ---
Nathan posted a patch on gcc-patches:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg03102.html
http://patchwork.ozlabs.org/patch/701137/

[Bug fortran/45516] [F08] allocatable compontents of recursive type

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to janus from comment #9)
> Paul, can we close this PR, or is there anything left to do?

ping!

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #18 from Steve Kargl  ---
On Sun, Dec 04, 2016 at 04:24:21PM +, janus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618
> 
> Maybe one can instead try to nullify the memory in gfc_free charlen, so that 
> we
> at least know that cl->lengh is not a valid pointer? (Something similar is 
> also
> done in gfc_free_expr / free_expr0 in expr.c.)
> 
> Index: symbol.c
> ===
> --- symbol.c(revision 243224)
> +++ symbol.c(working copy)
> @@ -3838,6 +3838,7 @@ gfc_free_charlen (gfc_charlen *cl, gfc_charlen *en
> 
>cl2 = cl->next;
>gfc_free_expr (cl->length);
> +  memset (cl, '\0', sizeof (gfc_charlen));
>free (cl);
>  }
>  }
> 

Doesn't that leak memory?  The 'free(cl)' in the line
after memset() should be a NOP, so whatever cl pointed
to before the memset() is leaked.  

Hmmm, doesn't seem to help.  Setting a break point in
gdb at gfc_free_charlen, I see 

Breakpoint 1, gfc_free_charlen (cl=0x0, end=0x0) at
/mnt/kargl/gcc/gcc/fortran/symbol.c:3832
3832{
(gdb) 
Continuing.

Program received signal SIGSEGV, Segmentation fault.
gfc_is_constant_expr (e=0x193e) at /mnt/kargl/gcc/gcc/fortran/expr.c:897
897   switch (e->expr_type)

Note, gfc_charlen_free() was called 43 times before the SIGSEGV. In
only one call, cl was non-NULL.

[Bug fortran/78570] ICE in free_expr0, at fortran/expr.c:494

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
Slightly reduced variant:

type t
  character(len=2), dimension(2) :: c = '' // ['a']
end type
type(t) :: z
end


On this I get a "double free or corruption" followed by an ICE:

0xfd7a14 crash_signal
/home/jweil/gcc/gcc7/trunk/gcc/toplev.c:333
0x8abbfd gfc_free_charlen(gfc_charlen*, gfc_charlen*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/symbol.c:3841
0x8abd58 gfc_free_namespace(gfc_namespace*)
/home/jweil/gcc/gcc7/trunk/gcc/fortran/symbol.c:3890
0x8abe78 gfc_symbol_done_2()
/home/jweil/gcc/gcc7/trunk/gcc/fortran/symbol.c:3926
0x827ccb gfc_done_2()
/home/jweil/gcc/gcc7/trunk/gcc/fortran/misc.c:264
0x85d6d9 translate_all_program_units
/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6057
0x85dc94 gfc_parse_file()
/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6238
0x8b6f18 gfc_be_parse_file
/home/jweil/gcc/gcc7/trunk/gcc/fortran/f95-lang.c:202


The code is supposed to be valid, I guess?

[Bug fortran/78443] [OOP] Incorrect behavior with non_overridable keyword

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from janus at gcc dot gnu.org ---
I have backported the fix to all open branches, so that it should be included
in the upcoming releases 5.5, 6.3 and 7.0. Closing.

[Bug fortran/78443] [OOP] Incorrect behavior with non_overridable keyword

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org ---
Author: janus
Date: Sun Dec  4 16:34:13 2016
New Revision: 243230

URL: https://gcc.gnu.org/viewcvs?rev=243230=gcc=rev
Log:
2016-12-04  Janus Weil  

Backport from trunk
PR fortran/78443
* class.c (add_proc_comp): Add a vtype component for non-overridable
procedures that are overriding.

2016-12-04  Janus Weil  

Backport from trunk
PR fortran/78443
* gfortran.dg/typebound_proc_35.f90: New test case.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/typebound_proc_35.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/class.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/78226] Fill out location information everywhere

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> It appears that the patch at
>
> https://gcc.gnu.org/ml/fortran/2016-12/msg00040.html
>
> actually catches more errors than the original one.

Confirmed.

[Bug target/78642] [7 regression] ICE: invalid rtl sharing found in the insn on sparc

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #4 from Eric Botcazou  ---
>> Is your compiler configured with --enable-checking=rtl ?
>
> Yes, but I don't think Rainer's is.

not explicitly: I have

S["stage1_checking"]="--enable-checking=yes,types,extra"

in gcc/config.status which implies rtl checking.

>> Perhaps it can be only reproduced natively, or relies on particular
>> auto-host.h content (I don't have cross-binutils to Solaris around).
>
> Or it was fixed by your emit-rtl.c change.

I'm still seeing it on Solaris 10, 11 and 12 between 20161201 (r243113)
and 20161204 (r243227), both when using as and gas:

$ cc1 -fpreprocessed 20030917-1.i -quiet -mcpu=v9 -O3 -ftracer
-finline-functions -o 20030917-1.s
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/compile/20030917-1.c:9:1:
warning: return type defaults to 'int' [-Wimplicit-int]
 blah(size,strp)
 ^~~~
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/compile/20030917-1.c:
In function 'blah':
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/compile/20030917-1.c:17:1:
error: invalid rtl sharing found in the insn
 }
 ^
(insn 196 94 197 (clobber (reg/i:SI 8 %o0 [24]))
"/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/compile/20030917-1.c":17
-1
 (nil))
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/compile/20030917-1.c:17:1:
error: shared rtx
(clobber (reg/i:SI 8 %o0 [24]))
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/compile/20030917-1.c:17:1:
internal compiler error: internal consistency failure
0x64d74f verify_rtx_sharing
/vol/gcc/src/hg/trunk/local/gcc/emit-rtl.c:2751
0x64deff verify_insn_sharing
/vol/gcc/src/hg/trunk/local/gcc/emit-rtl.c:2837
0x652fc3 verify_rtl_sharing()
/vol/gcc/src/hg/trunk/local/gcc/emit-rtl.c:2860
0x8fc603 execute_function_todo
/vol/gcc/src/hg/trunk/local/gcc/passes.c:1982
0x8fd543 do_per_function
/vol/gcc/src/hg/trunk/local/gcc/passes.c:1649
0x8fd767 execute_todo
/vol/gcc/src/hg/trunk/local/gcc/passes.c:2015

Rainer

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #17 from janus at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #16)
> Index: resolve.c
> ===
> --- resolve.c   (revision 243227)
> +++ resolve.c   (working copy)
> @@ -12010,6 +12010,9 @@ resolve_fl_procedure (gfc_symbol *sym, i
>  {
>gfc_charlen *cl = sym->ts.u.cl;
>  
> +  if (strcmp (sym->name, "__convert_s4_s1") == 0)
> +   return false;
> +
>if (cl && cl->length && gfc_is_constant_expr (cl->length)
>  && !resolve_charlen (cl))
> return false;
> 
> It's not pretty, but seems to work. :(

I don't really think that sort of workaround is a good idea.

Maybe one can instead try to nullify the memory in gfc_free charlen, so that we
at least know that cl->lengh is not a valid pointer? (Something similar is also
done in gfc_free_expr / free_expr0 in expr.c.)

Index: symbol.c
===
--- symbol.c(revision 243224)
+++ symbol.c(working copy)
@@ -3838,6 +3838,7 @@ gfc_free_charlen (gfc_charlen *cl, gfc_charlen *en

   cl2 = cl->next;
   gfc_free_expr (cl->length);
+  memset (cl, '\0', sizeof (gfc_charlen));
   free (cl);
 }
 }

Steve, could you check if this fixes the ICE?

[Bug fortran/78226] Fill out location information everywhere

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig  ---
It appears that the patch at

https://gcc.gnu.org/ml/fortran/2016-12/msg00040.html

actually catches more errors than the original one.

So, more cases to find... Nice thing is, one
fix can fix quite a large number of test cases.

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #16 from Steve Kargl  ---
On Sun, Dec 04, 2016 at 10:07:16AM +, janus at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78618
> 
> --- Comment #15 from janus at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #10)
> > This looks like a used-after-freed bug.
> 
> Yes, it does.
> 
> My first suspicion was that the problematic freeing happens at the end of
> variable_decl (decl.c:2450):
> 
>   gfc_free_expr (initializer);
> 
> It seems the initializer here has the same ts.u.cl (not a copy) as the symbol
> 'c'. However, gfc_free_expr (surprisingly) does not free anything in the
> typespec.
> 
> Instead it seems the charlen is freed via gfc_free_charlen in
> 'reject_statement'. Not sure what to do about it ...
> 

Looks like you have done a nice bit of debugging.  I went in a different
direction.  In intrinsic.c (gfc_convert_chartype), I tried to allocate a
gfc_charlen and then copy ts.u.cl from the char(255,4) in the ts.u.cl for
'c'.  This occurs before 'reject_statement', so of course it failed.

I've a possible kludge under testing.  In resolve.c (resolve_fl_procedure),
the offending chunk of code is (line 12013 or so)

if (cl && cl->length && gfc_is_constant_expr (cl->length)
 && !resolve_charlen (cl))
return false;

where cl->length is invalid but not NULL.

I simply forced a 'return false' in gdb to see what would
happen, and char_constant.f90 compiled without the ICE error.
Thus, I've came up with

Index: resolve.c
===
--- resolve.c   (revision 243227)
+++ resolve.c   (working copy)
@@ -12010,6 +12010,9 @@ resolve_fl_procedure (gfc_symbol *sym, i
 {
   gfc_charlen *cl = sym->ts.u.cl;

+  if (strcmp (sym->name, "__convert_s4_s1") == 0)
+   return false;
+
   if (cl && cl->length && gfc_is_constant_expr (cl->length)
 && !resolve_charlen (cl))
return false;

It's not pretty, but seems to work. :(

[Bug fortran/78443] [OOP] Incorrect behavior with non_overridable keyword

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
Author: janus
Date: Sun Dec  4 16:00:27 2016
New Revision: 243229

URL: https://gcc.gnu.org/viewcvs?rev=243229=gcc=rev
Log:
2016-12-04  Janus Weil  

Backport from trunk
PR fortran/78443
* class.c (add_proc_comp): Add a vtype component for non-overridable
procedures that are overriding.

2016-12-04  Janus Weil  

Backport from trunk
PR fortran/78443
* gfortran.dg/typebound_proc_35.f90: New test case.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/typebound_proc_35.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/class.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/70322] STV doesn't optimize andn

[uros at gcc dot gnu.org]

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

--- Comment #10 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Dec  4 14:38:05 2016
New Revision: 243228

URL: https://gcc.gnu.org/viewcvs?rev=243228=gcc=rev
Log:
PR target/70322
* config/i386/i386.c (dimode_scalar_to_vector_candidate_p): Handle NEG.
(dimode_scalar_chain::compute_convert_gain): Ditto.
(dimode_scalar_chain::convert_insn): Ditto.

testsuite/ChangeLog:

PR target/70322
* gcc.target/i386/pr70322-4.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr70322-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78672] New: Gfortran test suite failures with a sanitized compiler

[dominiq at lps dot ens.fr]

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

Bug ID: 78672
   Summary: Gfortran test suite failures with a sanitized compiler
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

Created attachment 40242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40242=edit
Results for sanitized gfortran

Running a sanitized gcc with

time make -k -j8 check-gfortran RUNTESTFLAGS="--target_board=unix
--tool_opts='-Wl,-lasan,-lubsan'" > & ../check_gf-243224p18.log &

gives several failures (almost) not seen with a regular build (see attachment).

Some of these failures are quite repetitive:

(1) Coarray failures

FAIL: gfortran.dg/coarray/alloc_comp_4.f90 -fcoarray=single  -O2  -latomic
(test for excess errors)
FAIL: gfortran.dg/coarray/alloc_comp_4.f90 -fcoarray=single  -O2  -latomic
(test for excess errors)
FAIL: gfortran.dg/coarray/atomic_1.f90 -fcoarray=single  -O2  -latomic (test
for excess errors)
FAIL: gfortran.dg/coarray/atomic_1.f90 -fcoarray=lib  -O2  -lcaf_single
-latomic (test for excess errors)
FAIL: gfortran.dg/coarray/event_1.f90 -fcoarray=single  -O2  -latomic (test for
excess errors)
FAIL: gfortran.dg/coarray/atomic_2.f90 -fcoarray=single  -O2  -latomic (test
for excess errors)
FAIL: gfortran.dg/coarray/atomic_2.f90 -fcoarray=lib  -O2  -lcaf_single
-latomic (test for excess errors)
FAIL: gfortran.dg/coarray/cosubscript_1.f90 -fcoarray=single  -O2  -latomic
(test for excess errors)
FAIL: gfortran.dg/coarray/cosubscript_1.f90 -fcoarray=lib  -O2  -lcaf_single
-latomic (test for excess errors)
FAIL: gfortran.dg/coarray/image_index_2.f90 -fcoarray=single  -O2  -latomic
(test for excess errors)
FAIL: gfortran.dg/coarray/image_index_2.f90 -fcoarray=lib  -O2  -lcaf_single
-latomic (test for excess errors)
FAIL: gfortran.dg/coarray/lock_1.f90 -fcoarray=single  -O2  -latomic (test for
excess errors)
FAIL: gfortran.dg/coarray/registering_1.f90 -fcoarray=single  -O2  -latomic
(test for excess errors)
FAIL: gfortran.dg/coarray/registering_1.f90 -fcoarray=lib  -O2  -lcaf_single
-latomic (test for excess errors)
FAIL: gfortran.dg/coarray/this_image_2.f90 -fcoarray=single  -O2  -latomic
(test for excess errors)
FAIL: gfortran.dg/coarray/this_image_2.f90 -fcoarray=lib  -O2  -lcaf_single
-latomic (test for excess errors)
FAIL: gfortran.dg/coarray_lib_token_1.f90   -O  (test for excess errors)
FAIL: gfortran.dg/coarray_lib_token_2.f90   -O  (test for excess errors)
FAIL: gfortran.dg/coarray_send_by_ref_1.f08   -O*  (test for excess errors)
FAIL: gfortran.dg/coarray_stat_2.f90   -O*  (test for excess errors)
FAIL: gfortran.dg/coarray_stat_function.f90   -O  (test for excess errors)
FAIL: gfortran.dg/coarray_stat_whitespace.f90   -O  (test for excess errors)
FAIL: gfortran.dg/coarray_40.f90   -O*  (test for excess errors)
FAIL: gfortran.dg/coarray_11.f90   -O  (test for excess errors)
FAIL: gfortran.dg/coarray_atomic_4.f90   -O  (test for excess errors)
FAIL: gfortran.dg/coarray_atomic_5.f90   -O  (test for excess errors)
FAIL: gfortran.dg/coarray_atomic_6.f90   -O  (test for excess errors)
FAIL: gfortran.dg/coarray_lock_6.f90   -O  (test for excess errors)
FAIL: gfortran.dg/pr71688.f90   -O  (test for excess errors)
FAIL: gfortran.dg/bound_simplification_4.f90   -O*  (test for excess errors)
FAIL: gfortran.dg/bound_simplification_5.f90   -O*  (test for excess errors)
FAIL: gfortran.dg/coarray_alloc_comp_1.f08   -O*  (test for excess errors)
FAIL: gfortran.dg/coarray_alloc_comp_2.f08   -O*  (test for excess errors)
FAIL: gfortran.dg/coarray_alloc_comp_4.f08   -O  (test for excess errors)
FAIL: gfortran.dg/class_optional_2.f90   -O*  (test for excess errors)
FAIL: gfortran.dg/pr63331.f90   -O  (test for excess errors)
FAIL: gfortran.dg/coarray_21.f90   -O  (test for excess errors)
FAIL: gfortran.dg/coarray_23.f90   -O  (test for excess errors)
FAIL: gfortran.dg/coarray_29_2.f90   -O  (test for excess errors)
FAIL: gfortran.dg/coarray_allocate_7.f08   -O*  (test for excess errors)
FAIL: gfortran.dg/coarray_allocate_8.f08   -O*  (test for excess errors)
FAIL: gfortran.dg/coarray_allocate_9.f08   -O*  (test for excess errors)
FAIL: gfortran.dg/intent_out_7.f90   -O  (test for excess errors)

with

../../work/gcc/fortran/trans-decl.c:1042:10: runtime error: index -1 out of
bounds for type 'tree_node *[7]'

i.e., the line

  && GFC_TYPE_ARRAY_UBOUND (type, as->rank - 1) != NULL_TREE

(2)

FAIL: gfortran.dg/allocate_with_source_8.f08   -O*  (test for excess errors)
FAIL: gfortran.dg/unlimited_polymorphic_1.f03   -O*  (test for excess errors)
FAIL: gfortran.dg/unlimited_polymorphic_16.f90   -O  (test for excess errors)
FAIL: gfortran.dg/alloc_comp_class_5.f03   -O*  (test for excess errors)

with

../../work/gcc/fortran/interface.c:2948:33: runtime error: load of value

[Bug rtl-optimization/78669] [7 Regression]: ICE: in combine_and_move_insns, at ira.c:3665 with -Os -fno-tree-ter -mavx512bw

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-04
  Component|target  |rtl-optimization
   Target Milestone|--- |7.0
Summary|ICE: in |[7 Regression]: ICE: in
   |combine_and_move_insns, at  |combine_and_move_insns, at
   |ira.c:3665 with -Os |ira.c:3665 with -Os
   |-fno-tree-ter -mavx512bw|-fno-tree-ter -mavx512bw
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Confirmed, the compilation breaks at:

(gdb) up
#2  0x00c0fc8a in combine_and_move_insns () at
/home/uros/gcc-svn/trunk/gcc/ira.c:3665
3665  gcc_assert (use_insn);
(gdb)
3651  if (!reg_equiv[regno].replace)
3652continue;
3653
3654  rtx_insn *use_insn = 0;
3655  for (df_ref use = DF_REG_USE_CHAIN (regno);
3656   use;
3657   use = DF_REF_NEXT_REG (use))
3658if (DF_REF_INSN_INFO (use))
3659  {
3660if (DEBUG_INSN_P (DF_REF_INSN (use))) 
3661  continue;
3662gcc_assert (!use_insn);
3663use_insn = DF_REF_INSN (use);
3664  }
3665  gcc_assert (use_insn);
3666
3667  /* Don't substitute into jumps.  indirect_jump_optimize does
3668 this for anything we are prepared to handle.  */
3669  if (JUMP_P (use_insn))
3670continue;

(gdb) p regno
$2 = 125

Suggesting, that there are no uses of r125.

But, we have in _.267r.asmcons:

(insn 24 23 25 2 (set (reg:V4DI 125)
(const_vector:V4DI [
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])) 1217 {movv4di_internal}
 (nil))
(insn 25 24 152 2 (set (reg:V8DI 119)
(vec_concat:V8DI (reg:V4DI 124)
(reg:V4DI 125))) 4519 {avx_vec_concatv8di}
 (expr_list:REG_DEAD (reg:V4DI 125)
(expr_list:REG_DEAD (reg:V4DI 124)
(expr_list:REG_EQUAL (const_vector:V8DI [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 3 [0x3])
(const_int 0 [0])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
(const_int -1 [0x])
])
(nil)

Looks like rtl-optimization problem, either dataflow or RA.

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

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||ra
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-04
 CC||vmakarov at gcc dot gnu.org
  Component|target  |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
(In reply to Zdenek Sojka from comment #0)
> Created attachment 40241 [details]
> reduced testcase
> 
> Compiler output:
> $ x86_64-pc-linux-gnu-gcc -Og -march=skylake-avx512 testcase.c
> testcase.c: In function 'foo':
> testcase.c:15:1: error: insn does not satisfy its constraints:
>  }
>  ^
> (insn 554 165 166 14 (set (reg:TI 44 r15 [orig:149 _84 ] [149])
> (reg:TI 40 r11 [orig:149 _84 ] [149])) "testcase.c":12 80
> {*movti_internal}
>  (nil))

64bit r15 was allocated as a TImode register, and there is no r16 to form
TImode register pair.

[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn

[olegendo at gcc dot gnu.org]

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

--- Comment #5 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #1)
> Here is a trial patch
> 
> diff --git a/config/sh/sh.md b/config/sh/sh.md
> index c6956a0..c83bf08 100644
> --- a/config/sh/sh.md
> +++ b/config/sh/sh.md
> @@ -858,7 +858,8 @@
>operands of the tstsi_t insn, which is generally the case.  */
>if (dump_file)
>   fprintf (dump_file, "cmpeqsi_t: replacing with tstsi_t\n");
> -  emit_insn (gen_tstsi_t (XEXP (op.set_src, 0), XEXP (op.set_src, 1)));
> +  emit_insn (gen_tstsi_t (copy_rtx (XEXP (op.set_src, 0)),
> +   XEXP (op.set_src, 1)));
>DONE;
>  }
>  
> Oleg, could you take a look at the issue?  Although the patch fixes
> the ICE, I'm not sure if it's OK and enough.

Hm ... if this is a latent bug, I would like to understand why it's wrong to
reference a reg rtx in the insn input operands.  I've been doing that in
several places in similar ways...

[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #7)
> Unfortunately, __builtin_memchr is not usable in constexpr contexts.  Hardly
> any of these builtins are.

Can you explain why?  Most of the builtins that can fold on GENERIC should be
usable in constexpr contexts.  The constexpr folder invokes the middle-end
builtin folder.

[Bug fortran/78226] Fill out location information everywhere

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> Current regressions with the patch at
>
> https://gcc.gnu.org/ml/fortran/2016-12/msg00039.html :
>
> allocate_with_source_10.f08 allocate_with_source_11.f08
> ...

What are the failures? I have an older version of the patch in my working tree
and I don't see any failure related to this PR.

[Bug ada/48835] porting GNAT to m68k-linux

[glaubitz at physik dot fu-berlin.de]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #60 from John Paul Adrian Glaubitz  ---
I don't see the patch which adds support for "M68K Linux" to Ada in the current
trunk or gcc-7 [1]. Am I missing something?

Adrian

> [1] 
> https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/ada/gcc-interface/Makefile.in?view=markup

[Bug fortran/78226] Fill out location information everywhere

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Current regressions with the patch at

https://gcc.gnu.org/ml/fortran/2016-12/msg00039.html :

allocate_with_source_10.f08 allocate_with_source_11.f08
allocate_with_source_13.f03 allocate_with_source_14.f03
allocate_with_source_15.f03 allocate_with_source_5.f90
allocate_with_source_6.f90 alloc_comp_class_4.f03
auto_dealloc_2.f90 class_11.f03 class_28.f03 class_48.f90
class_allocate_13.f90 class_allocate_17.f90 class_allocate_20.f90
class_allocate_5.f90 class_array_12.f03 class_array_21.f03
class_optional_1.f90 class_to_type_1.f03 coarray_27.f90
coarray_39.f90 coarray_class_1.f90 deferred_character_11.f90
deferred_character_5.f90 defined_assignment_11.f90
defined_assignment_2.f90 dynamic_dispatch_4.f03 dynamic_dispatch_8.f03
elemental_subroutine_10.f90 finalize_10.f90 finalize_12.f90
finalize_15.f90 finalize_17.f90 finalize_19.f90 finalize_24.f90
finalize_27.f90 finalize_29.f08 finalize_4.f03 intent_out_7.f90
move_alloc_17.f90 pr57904.f90 pr63331.f90 pr68864.f90
proc_ptr_comp_37.f90 proc_ptr_comp_45.f90 ptr_func_assign_2.f08
recursive_alloc_comp_1.f08 recursive_alloc_comp_2.f08
recursive_alloc_comp_3.f08 select_type_10.f03 select_type_19.f03
select_type_27.f03 select_type_32.f90 submodule_6.f08
typebound_assignment_1.f03 typebound_assignment_2.f03
typebound_operator_12.f03 typebound_operator_13.f03
typebound_operator_9.f03 type_to_class_1.f03
unlimited_polymorphic_12.f90 unlimited_polymorphic_19.f90
unlimited_polymorphic_21.f90 unlimited_polymorphic_25.f90
unlimited_polymorphic_26.f90 whole_file_27.f90

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[wbx at openadk dot org]

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

--- Comment #13 from Waldemar Brodkorb  ---
Okay.
So what is your opinion, how we proceed here?

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

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

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

--- Comment #12 from Andreas Schwab  ---
linux-atomic is independent of libc and libpthread, it implements compiler
intrinsics and only depends on the kernel support for CAS on Coldfire.

[Bug target/78671] New: ICE: in extract_constrain_insn, at recog.c:2213 with -Og -march=skylake-avx512

[zsojka at seznam dot cz]

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

Bug ID: 78671
   Summary: ICE: in extract_constrain_insn, at recog.c:2213 with
-Og -march=skylake-avx512
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 40241
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40241=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Og -march=skylake-avx512 testcase.c
testcase.c: In function 'foo':
testcase.c:15:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 554 165 166 14 (set (reg:TI 44 r15 [orig:149 _84 ] [149])
(reg:TI 40 r11 [orig:149 _84 ] [149])) "testcase.c":12 80
{*movti_internal}
 (nil))
testcase.c:15:1: internal compiler error: in extract_constrain_insn, at
recog.c:2213
0xc25ec3 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.c:108
0xc25f34 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.c:119
0xbdc17d extract_constrain_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.c:2213
0xae38a5 check_rtl
/repo/gcc-trunk/gcc/lra.c:2109
0xaea510 lra(_IO_FILE*)
/repo/gcc-trunk/gcc/lra.c:2517
0xa90a99 do_reload
/repo/gcc-trunk/gcc/ira.c:5386
0xa90a99 execute
/repo/gcc-trunk/gcc/ira.c:5570
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-243200-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-243200-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161202 (experimental) (GCC)

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[wbx at openadk dot org]

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

--- Comment #11 from Waldemar Brodkorb  ---
I talking about following change:
diff -Nur gcc.orig/libgcc/config.host gcc/libgcc/config.host
--- gcc.orig/libgcc/config.host   2016-02-26 21:02:28.0 +0100
+++ gcc/libgcc/config.host2016-04-29 09:18:40.377989160 +0200
@@ -812,7 +812,7 @@
 m68k*-*-openbsd*)
;;
 m68k-*-uclinux*)   # Motorola m68k/ColdFire running uClinux with uClibc
-   tmake_file="$tmake_file m68k/t-floatlib m68k/t-linux"
+   tmake_file="$tmake_file m68k/t-floatlib"
md_unwind_header=m68k/linux-unwind.h
;;
 m68k-*-linux*) # Motorola m68k's running GNU/Linux


This would allow to create a working toolchain. 
m68k-nommu (coldfire) is only supported by uClibc-ng and not GNU libc.
There is only support for Linuxthreads, so TLS/libatomic is disabled at
configure time.
C++ support still seems to work fine.
The m68k (full MMU) support isn't changed with this patch.

>From the embedded build system maintainer view, I think the patch is fine to at
least
get some working toolchain until the ICE is solved.

The patch is used for some time in Buildroot/OpenADK.

[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
Created attachment 40240
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40240=edit
Patch from Iain Sandoe

Results with the patch at
https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg00469.html.

[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

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

[ian_harvey at bigpond dot com]

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

Bug ID: 78670
   Summary: Incorrect file position with namelist read under DTIO
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ian_harvey at bigpond dot com
  Target Milestone: ---

When compiled with recent trunk, the attached demonstrates that the position of
a file is incorrect when a user defined derived type input procedure is invoked
to process namelist input.  The character read from the file by the user
defined derived type input procedure appears to be the `=` character that
separates the object designator from the value in the namelist input.  The file
position when the user defined derived type input procedure is invoked should
be after that `=`.

(As a result of picking up the `=` the defined input procedure leaves the file
positioned prior to the value `a`, which then confuses the Fortran runtime and
results in an end of file condition - that's not a problem in itself.)


MODULE m
  IMPLICIT NONE

  TYPE :: t
CHARACTER :: c
  CONTAINS
PROCEDURE :: read_formatted
GENERIC :: READ(FORMATTED) => read_formatted

! Work around for PR78659.
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED) => write_formatted
  END TYPE t
CONTAINS
  ! Workaround for PR78659.
  SUBROUTINE write_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
CLASS(t), INTENT(IN) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(*), INTENT(INOUT) :: iomsg

iostat = 0
  END SUBROUTINE write_formatted

  SUBROUTINE read_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
CLASS(t), INTENT(INOUT) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(*), INTENT(INOUT) :: iomsg

CHARACTER :: ch

dtv%c = ''

DO
  READ (unit, "(A)", IOSTAT=iostat, IOMSG=iomsg) ch
  IF (iostat /= 0) RETURN

  ! for debugging only.
  print "('Got ''',A,)", ch

  ! Store first non-blank
  IF (ch /= '') THEN
dtv%c = ch
RETURN
  END IF
END DO

READ (unit, "(A)", IOSTAT=iostat, IOMSG=iomsg) dtv%c
  END SUBROUTINE read_formatted
END MODULE m

PROGRAM p
  USE m
  IMPLICIT NONE
  TYPE(t) :: x
  NAMELIST /nml/ x
  INTEGER :: unit

  OPEN(NEWUNIT=unit, STATUS='SCRATCH', ACTION='READWRITE')

  WRITE (unit, "(A)") ''
  WRITE (unit, "(A)") 'x = a'
  WRITE (unit, "(A)") '/'

  REWIND (unit)

  READ (unit, nml)
  PRINT *, x%c   ! expect `a`.
END PROGRAM p


$ gfortran -g 2016-12-04\ namelist3.f90 && ./a.out
Got '='
At line 72 of file 2016-12-04 namelist3.f90
Fortran runtime error: End of file

Error termination. Backtrace:
#0  0x7f19aad29321 in nml_get_obj_data
at ../../.././vanilla/libgfortran/io/list_read.c:3494
#1  0x7f19aad31700 in finalize_transfer
at ../../.././vanilla/libgfortran/io/transfer.c:3813
#2  0x40101e in p
at /home/MEGMS2/ian/srv/home/projects/FortranMisc/2016/2016-12-04
namelist3.f90:72
#3  0x4010b5 in main
at /home/MEGMS2/ian/srv/home/projects/FortranMisc/2016/2016-12-04
namelist3.f90:58



(The program is technically non-conforming because it executes an output
statement to an external unit while parent READ statement is active, if
necessary the print statement in read_formatted can be removed and the value of
dtv%c in the read_formatted procedure inspected after a read using a debugger.)

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

[coollpe at hotmail dot com]

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

--- Comment #24 from peien luo  ---
(In reply to Dmitry Vyukov from comment #23)
> Please provide disassembly of the function that contains the PC
> (__gnu_cxx::__normal_iterator...).
> Did we fix any bugs that lead to missed __tsan_func_exit callbacks?
> 
> Before we go any deeper, I would suggest to retest with the latest gcc.
> There might have been bugs, and they may be fixed now. Even if a fix will be
> backported to 4.8 branch, you will still need to update the compiler.

I tried 4.9.4 today, and there seems to be a different error in gdb.

   0x7fe763ba774e <+0>: push   %rbp
   0x7fe763ba774f <+1>: mov%rsp,%rbp
   0x7fe763ba7752 <+4>: push   %r14
   0x7fe763ba7754 <+6>: push   %r13
   0x7fe763ba7756 <+8>: push   %r12
   0x7fe763ba7758 <+10>:push   %rbx
   0x7fe763ba7759 <+11>:sub$0x1000f0,%rsp
=> 0x7fe763ba7760 <+18>:mov%rdi,-0x1000e8(%rbp)
   0x7fe763ba7767 <+25>:mov%rsi,-0x1000f0(%rbp)
   0x7fe763ba776e <+32>:mov%rdx,-0x1000f8(%rbp)
   0x7fe763ba7775 <+39>:mov%rcx,-0x100100(%rbp)
   0x7fe763ba777c <+46>:mov%r8,-0x100108(%rbp)
   0x7fe763ba7783 <+53>:mov%r9d,-0x10010c(%rbp)
   0x7fe763ba778a <+60>:mov0x8(%rbp),%rax
   0x7fe763ba778e <+64>:mov%rax,%rdi
   0x7fe763ba7791 <+67>:callq  0x7fe763871660
<__tsan_func_entry(void*)>

[Bug fortran/78618] ICE in gfc_check_rank, at fortran/check.c:3670

[janus at gcc dot gnu.org]

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

--- Comment #15 from janus at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #10)
> This looks like a used-after-freed bug.

Yes, it does.


My first suspicion was that the problematic freeing happens at the end of
variable_decl (decl.c:2450):

  gfc_free_expr (initializer);

It seems the initializer here has the same ts.u.cl (not a copy) as the symbol
'c'. However, gfc_free_expr (surprisingly) does not free anything in the
typespec.

Instead it seems the charlen is freed via gfc_free_charlen in
'reject_statement'. Not sure what to do about it ...

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

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

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

--- Comment #10 from Andreas Schwab  ---
The fact that libcalls aren't using the C ABI is likely hurting everyone.

[Bug fortran/59694] [F03] no finalization of an unused variable

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to Damian Rouson from comment #7)
> Hopefully this PR is finally back in the correct state.

I think so. Thanks.

[Bug fortran/59694] [F03] no finalization of an unused variable

[damian at sourceryinstitute dot org]

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

--- Comment #7 from Damian Rouson  ---
> On Dec 4, 2016, at 12:45 AM, janus at gcc dot gnu.org 
>  wrote:
> 
> --- Comment #5 from janus at gcc dot gnu.org ---
> (In reply to Damian Rouson from comment #4)
>> I meant to mark a different PR as invalid but marked this one mistakenly.
> 
> Which one?

78161, which I have now marked as invalid.

> So, should we reopen this one?

Yes.  I didn’t previously understand the options. I just discovered the
“reopened” option and submitted the change to reopen this.  Hopefully this PR
is finally back in the correct state.

Damian

[Bug fortran/37336] [F03] Finish derived-type finalization

[damian at sourceryinstitute dot org]

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

Bug 59694 Summary: [F03] no finalization of an unused variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59694

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

[Bug fortran/59694] [F03] no finalization of an unused variable

[damian at sourceryinstitute dot org]

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

Damian Rouson  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #6 from Damian Rouson  ---
Mistakenly closed. Reopening.

[Bug other/78161] contrib/download_prerequisites fails on MacOS, Lubuntu, and Windows

[damian at sourceryinstitute dot org]

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

Damian Rouson  changed:

   What|Removed |Added

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

--- Comment #5 from Damian Rouson  ---
Closing as invalid. See the earlier messages.

[Bug target/78669] New: ICE: in combine_and_move_insns, at ira.c:3665 with -Os -fno-tree-ter -mavx512bw

[zsojka at seznam dot cz]

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

Bug ID: 78669
   Summary: ICE: in combine_and_move_insns, at ira.c:3665 with -Os
-fno-tree-ter -mavx512bw
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Created attachment 40239
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40239=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -fno-tree-ter -mavx512bw testcase.c
testcase.c: In function 'bar':
testcase.c:18:1: internal compiler error: in combine_and_move_insns, at
ira.c:3665
 }
 ^
0xa94929 combine_and_move_insns
/repo/gcc-trunk/gcc/ira.c:3665
0xa9c1ed ira
/repo/gcc-trunk/gcc/ira.c:5186
0xa9c1ed execute
/repo/gcc-trunk/gcc/ira.c:5527
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-243200-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --without-cloog --without-ppl --without-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-243200-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161202 (experimental) (GCC) 

Tested revisions:
r243200 - FAIL
r242857 - FAIL
r242657 - OK
r242541 - OK

[Bug fortran/59694] [F03] no finalization of an unused variable

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Damian Rouson from comment #4)
> I meant to mark a different PR as invalid but marked this one mistakenly.

Which one? So, should we reopen this one?


> Now I just tried to reset its status duplicate and got the following message:
> 
> "You cannot mark bug 59694 as a duplicate of bug 67472, because it would
> create a duplicate loop."

That's because PR 67472 is already marked as a duplicate of PR 59694.