[Bug fortran/78848] [OOP] ICE on writing CLASS variable with non-typebound DTIO procedure

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---
I think its invalid in that the type contains no object that could be written
or even allocated. Or at least the example makes no sense to me. Regardless it
ICEs so should it be an error, i dont know what it should say?

"Attempting to use an empty type" or "baseless type"

or if it is valid, it should compile nothing since there is nothing to print
with print *, z. What is it allocating? NIL?

[Bug target/71216] [4.9/5/6/7 Regression] Incorrect PPC assembly due to inserted .machine pseudo-op

[rin at NetBSD dot org]

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

--- Comment #9 from Rin Okuyama  ---
Hi Segher,

Thank you for your kind reply. I committed your fix to NetBSD's local
tree of GCC 5.4.

> > However, I have a question on this fix. How about the case where
> > "-Wa,-mXXX" option is given without "-mcpu=YYY" option specified?
> 
> That might or might not work; the user had better know what he is
> doing if he uses an assembler option.

Hmm, I understand. Is this documented explicitly anywhere?

> > This may sound pedantic to you. However, this is dangerous because
> > some special mnemonics in inline assembler codes can be misassembled.
> > In addition, for example, "-mcpu=e500" is forbidden whereas "-Wa,-me500"
> > is possible; the user cannot use instructions for e500 in inline
> > assembler codes.
> 
> GCC does not support -me500, right.  You need to configure your compiler
> for a powerpc-*-eabispe* target as far as I know (I'm no expert on this).

We use -Wa,-me500 option to compile kernel on some machines. As they
share userland with other machines, we cannot configure GCC for a
powerpc-*-eabispe* target. Instead, I found a workaround to specify
-mcpu=powerpc option. It passes -mppc option to assembler, but as it
is preceding to -me500, the latter is prior to the former.

[Bug target/78849] New: ICE on initialization of global struct containing __int20 array at varasm.c:4968

[awygle at gmail dot com]

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

Bug ID: 78849
   Summary: ICE on initialization of global struct containing
__int20 array at varasm.c:4968
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: awygle at gmail dot com
  Target Milestone: ---

The following code (constructor_bug.i) produces an internal compiler error when
compiled for the msp430-elf target:

# 1 "constructor_bug.c"
# 1 ""
# 1 ""
# 1 "constructor_bug.c"

struct causes_problems {
  __int20 array[2];
  char value;
};

struct causes_problems instance = {
  {
0,
1,
  },
  0,
};

void main(void) {
  while(1);
}

% msp430-elf-gcc -msim constructor_bug.i
constructor_bug.c:17:1: internal compiler error: in
output_constructor_regular_field, at varasm.c:4968
 }
 ^
0xb06039 output_constructor_regular_field
../../gcc-6.2.0/gcc/varasm.c:4968
0xb06039 output_constructor
../../gcc-6.2.0/gcc/varasm.c:5276
0xb05254 assemble_variable_contents
../../gcc-6.2.0/gcc/varasm.c:2062
0xb0bdca assemble_variable(tree_node*, int, int, int)
../../gcc-6.2.0/gcc/varasm.c:2238
0xb0fadd varpool_node::assemble_decl()
../../gcc-6.2.0/gcc/varpool.c:582
0x600403 output_in_order
../../gcc-6.2.0/gcc/cgraphunit.c:2231
0x6006a3 symbol_table::compile()
../../gcc-6.2.0/gcc/cgraphunit.c:2468
0x6025d9 symbol_table::finalize_compilation_unit()
../../gcc-6.2.0/gcc/cgraphunit.c:2564
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

% msp430-elf-gcc -v
Using built-in specs.
COLLECT_GCC=msp430-elf-gcc
COLLECT_LTO_WRAPPER=/home/awygle/toolchain/install/libexec/gcc/msp430-elf/6.2.0/lto-wrapper
Target: msp430-elf
Configured with: ../gcc-6.2.0/configure
--prefix=/home/awygle/toolchain/install/ --target=msp430-elf --without-headers
--with-newlib --enable-languages=c,c++ -v
Thread model: single
gcc version 6.2.0 (GCC)


As far as I can tell this is a minimal test case, by which I mean that any of
the following prevents the error:

* Reducing the length of the array to 1
* Removing the "value" field from the struct
* Moving the array field to the end of the struct
* Not initializing the struct
* Moving the struct variable definition and initialization into the main()
function

I filed this under "target" but I suspect it would apply to any
non-byte-aligned __intN type - however, only one of those seems to exist right
now and it's in the msp430 target. I tried to reproduce this bug on the AVR
target using __int24 without success, but my avr-gcc version is 4.8.2 rather
than 6.2.

Thanks

[Bug fortran/78746] charlen_03, charlen_10 ICE

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
I have removed the two failing testcase and attached them to this PR.

It is likely the dg-error will need to be updated when the bug is
fixed.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Created attachment 40360
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40360=edit
charlen_10.f90 source code

[Bug fortran/78746] charlen_03, charlen_10 ICE

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Created attachment 40359
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40359=edit
charlen_30.f90 testcase

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #17 from janus at gcc dot gnu.org ---
(In reply to paul.richard.tho...@gmail.com from comment #16)
> I suppose that one would have to set up the namelist or the input
> stream to determine what the dynamic type is, have the code allocate
> the variable to that type and then do the input.

Huh, is it actually valid to do input on an unallocated CLASS (or TYPE)
variable? If it is, one can only rely on the declared type for choosing the
input procedure.

When doing input on an allocated variable, which has a well-defined dynamic
type, one can certainly do a polymorphic call of the input procedure.


> Best of all would be that namelist incorporated constructors :-)

Yes, that would also determine the dynamic type, but I assume the Fortran
standard does not support anything like this?


> I see no reason to require that both input and output be present.

Good. Then my patch is partially wrong and incomplete.

[Bug fortran/78746] charlen_03, charlen_10 ICE

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Dec 17 23:10:01 2016
New Revision: 243778

URL: https://gcc.gnu.org/viewcvs?rev=243778=gcc=rev
Log:
2016-12-17  Steven G. Kargl  

PR fortran/78746
* charlen_03.f90: Remove test. 
* charlen_10.f90: Ditto.

Removed:
trunk/gcc/testsuite/gfortran.dg/charlen_03.f90
trunk/gcc/testsuite/gfortran.dg/charlen_10.f90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78848] [OOP] ICE on writing CLASS variable with non-typebound DTIO procedure

[janus at gcc dot gnu.org]

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

--- Comment #1 from janus at gcc dot gnu.org ---
Also one can wonder what kind of code should be generated here.

When using the type-bound form of the DTIO procedure, we generate a truly
polymorphic reference to the DTIO procedure when printing a CLASS variable,
i.e. z._vptr->wf in our example. This was implemented in PR 78737.

If we have no typebound DTIO procedure, but rather a non-typebound one, we
cannot do that, so we probably have to call the DTIO procedure in a
non-polymorphic fashion (based on the declared type), as if we were printing a
TYPE variable (?).

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[paul.richard.thomas at gmail dot com]

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

--- Comment #16 from paul.richard.thomas at gmail dot com  ---
Dear Janus,

What troubles me is that most times I have used namelist, it has been
primarily for input to codes; especially where there is a default set
of initial conditions
and a subset is changed for each run.

I suppose that one would have to set up the namelist or the input
stream to determine what the dynamic type is, have the code allocate
the variable to that type and then do the input. Namelist output is,
of course, rather more obvious.

Best of all would be that namelist incorporated constructors :-)

I see no reason to require that both input and output be present.

Cheers

Paul

On 17 December 2016 at 19:07, janus at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
>
> --- Comment #14 from janus at gcc dot gnu.org ---
> (In reply to paul.richard.tho...@gmail.com from comment #13)
>> Why do you think that both input and output is required?
>
> Don't know. My intuitive reaction was that comment 5 should be valid, but I
> haven't looked in the standard. If it is valid, we probably need to move the
> check, which currently triggers on the namelist declaration, regardless of
> whether it's actually used in any input or output statements.
>
>
>> How is namelist supposed to work with classes? Just with the declared type?
>
> As with 'normal' I/O, I'd say, i.e. calling the DTIO procedure according to 
> the
> dynamic type (not the declared type!). At least that's what my patch does ...
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/78848] New: [OOP] ICE on writing CLASS variable with non-typebound DTIO procedure

[janus at gcc dot gnu.org]

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

Bug ID: 78848
   Summary: [OOP] ICE on writing CLASS variable with non-typebound
DTIO procedure
   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: ---

Here is a variant of a testcase posted by Mikael at
https://gcc.gnu.org/ml/fortran/2016-12/msg00232.html:


module m
   type :: t
   contains
!  procedure :: wf
!  generic :: write(formatted) => wf
   end type
   interface write(formatted)
  procedure wf
   end interface
contains
   subroutine wf(this, a, b, c, d, e)
  class(t), intent(in) :: this
  integer, intent(in) :: a
  character, intent(in) :: b
  integer, intent(in) :: c(:)
  integer, intent(out) :: d
  character, intent(inout) :: e
   end subroutine
end

program p
  use m
  class(t), allocatable :: z
  allocate(z)
  print *, z
end


I assume this is valid code, but it results in an ICE:

f951: internal compiler error: Bad IO basetype (7)
0x7949b3 gfc_internal_error(char const*, ...)
/home/jweil/gcc/trunk/gcc/fortran/error.c:1346
0x9128fa transfer_expr
/home/jweil/gcc/trunk/gcc/fortran/trans-io.c:2429

Note that the ICE goes away when using the typebound version of the DTIO
procedure (commented out in the above example).

[Bug middle-end/78847] New: pointer arithmetic from c++ ranged-based for loop not optimized

[krister.walfridsson at gmail dot com]

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

Bug ID: 78847
   Summary: pointer arithmetic from c++ ranged-based for loop not
optimized
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krister.walfridsson at gmail dot com
  Target Milestone: ---

GCC has some problems eliminating overhead from C++ range-based for loops.
Consider the program

#include 
#include 
#include 
using string_view = std::experimental::string_view;

class Foo {
constexpr static size_t Length = 9;
char ascii_[Length];
public:
Foo();
string_view view() const {
return string_view(ascii_, Length);
}
};

void testWithLoopValue(const Foo foo, size_t ptr, char *buf_) {
  for (auto c : foo.view())
buf_[ptr++] = c;
}

compiled as
  g++ -O3 -S -std=c++1z k.cpp


ldist determines that this is a memcpy of length expressed as _14

  _18 = (unsigned long) [(void *) + 9B];
  _4 = _ + 1;
  _3 = (unsigned long) _4;
  _16 = _18 + 1;
  _14 = _16 - _3;

and dom3 improves this to

  _18 = (unsigned long) [(void *) + 9B];
  _3 = (unsigned long) [(void *) + 1B];
  _16 = _18 + 1;
  _14 = _16 - _3;

But this is not further simplified to 9 until combine, where it is too late,
and a call to memcpy is generated instead of the expected inlined version.

[Bug sanitizer/78832] [7 Regression] -fcompare-debug failure (length) with -fsanitize=address

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug sanitizer/78832] [7 Regression] -fcompare-debug failure (length) with -fsanitize=address

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Sat Dec 17 19:10:39 2016
New Revision: 243777

URL: https://gcc.gnu.org/viewcvs?rev=243777=gcc=rev
Log:
PR sanitizer/78832
* sanopt.c (sanitize_asan_mark_unpoison): Remove next variable, use
continue if gsi_next should be skipped.
(sanitize_asan_mark_poison): Remove prev variable, use continue if
gsi_prev should be skipped.  When removing ASAN_MARK, do gsi_prev
first and gsi_remove on a previously made copy of the iterator.

* gcc.dg/asan/pr78832.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/asan/pr78832.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sanopt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle  ---
(In reply to janus from comment #11)
> (In reply to janus from comment #10)
> > The attached patch seems to make the original comment 0 as well as the
> > polymorphic version in comment 7 work. Regtesting now ...
> 
> Regtesting was successful. There might be some commas missing in the output,
> though (not sure). Comments welcome.

The other half of this bug is the namelist reading which is 78670, the
description is misleading. So a similar approach in the library is needed in
list_read.c.  The placement of the call to the dtio procedures is important.
One must note that we can have arrays of objects and there is a mechanism for
looping over the array.

We should probably create a test case with more complex types with a mix of
derived and non derived components with mutliple levels of derived. One thing I
have not tried is to define a namelist within the use module such that one
could assign the dtv object into a namelist and invoke a namelist read/write
within the child procedure and nest these things. (is it legal to do so?, I
need to check) There is also a responsibility on the user to match there child
reads to there child writes so that things come out making sense. (generally
speaking, the child procedure should query the iotype variable to see if the
parent was a namelist read/write and do the right thing)

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #14 from janus at gcc dot gnu.org ---
(In reply to paul.richard.tho...@gmail.com from comment #13)
> Why do you think that both input and output is required?

Don't know. My intuitive reaction was that comment 5 should be valid, but I
haven't looked in the standard. If it is valid, we probably need to move the
check, which currently triggers on the namelist declaration, regardless of
whether it's actually used in any input or output statements.


> How is namelist supposed to work with classes? Just with the declared type?

As with 'normal' I/O, I'd say, i.e. calling the DTIO procedure according to the
dynamic type (not the declared type!). At least that's what my patch does ...

[Bug c++/78846] std1y compiler infinite output

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
(In reply to K from comment #0)
> Created attachment 40358 [details]
> .ii file
> 
> I created a c++14 program to implement lazy evaluation, but the compiler
> seems to be producing infinite output.
> 
> Machine (1)
> System: Darwin 13.4.0 x86_64 i386
> G++: g++-6 (Homebrew gcc 6.2.0) 6.2.0
> Command: g++-6 -std=c++1y binary_operation.cpp
> 
> Machine (2)
> System: Linux 4.4.0-53-generic x86_64 x86_64 x86_64 GNU/Linux
> G++: g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
> Command: g++ -std=c++1y binary_operation.cpp
> 
> (Actually, trying to compile with clang produces the same result).

If other compilers also reject your testcase why do you think this is a gcc
bug?
Please post your testcase to a more appropriate forum like stackoverflow.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[paul.richard.thomas at gmail dot com]

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

--- Comment #13 from paul.richard.thomas at gmail dot com  ---
Hi Janus,

Why do you think that both input and output is required?

How is namelist supposed to work with classes? Just with the declared type?

Cheers

Paul

On 17 December 2016 at 15:23, janus at gcc dot gnu.org
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
>
> --- Comment #6 from janus at gcc dot gnu.org ---
> (In reply to janus from comment #5)
>> Btw, this variant is wrongly rejected:
>>
>> [..]
>>
>>NAMELIST /nml/ x
>>1
>> Error: NAMELIST object ‘x’ in namelist ‘nml’ at (1) is polymorphic and
>> requires a defined input/output procedure
>
> Sorry, false alarm. In principle the error message is correct, although the
> wording is maybe a bit off: Both an input *and* output procedure is required!
>
> I'd suggest this change:
>
> Index: gcc/fortran/resolve.c
> ===
> --- gcc/fortran/resolve.c   (revision 243773)
> +++ gcc/fortran/resolve.c   (working copy)
> @@ -13871,8 +13871,8 @@ resolve_fl_namelist (gfc_symbol *sym)
>if (nl->sym->ts.type == BT_CLASS && !dtio)
> {
>   gfc_error ("NAMELIST object %qs in namelist %qs at %L is "
> -"polymorphic and requires a defined input/output "
> -"procedure", nl->sym->name, sym->name, 
> >declared_at);
> +"polymorphic and requires defined input and output "
> +"procedures", nl->sym->name, sym->name,
> >declared_at);
>   return false;
> }
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/78239] [5/6/7 Regression] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[tkoenig at gcc dot gnu.org]

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

--- Comment #10 from Thomas Koenig  ---
It helps to actually commit the fix, not only the test
case and the ChangeLog entry :-)

[Bug fortran/78239] [5/6/7 Regression] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Dec 17 17:03:49 2016
New Revision: 243776

URL: https://gcc.gnu.org/viewcvs?rev=243776=gcc=rev
Log:
2016-12-17  Thomas Koenig  

PR fortran/78239
* decl.c (char_len_param_value):  Actually commit
previous change.


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

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  ---
(In reply to janus from comment #9)
> Jerry, I don't want to steal this PR from you ;) but I think I have a rather
> complete patch by now. If you have any comments, please let me know!

You save me a lot of time. I will will review and test what you have. Very few
people delve into namelist.

[Bug libfortran/78833] Misleading IOMSG after failed WRITE(...,POS=) on unconnected formatted stream file

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jvdelisle at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #5 from Jerry DeLisle  ---
Yes, the bug is in your program. After failing to open the subsequent write
statements are assuming default open which is by definition, sequentiial, so
the error message is correct.

On the initial failure your program should not attempt any writes and probably
should gracefully exit.

[Bug c++/78846] New: std1y compiler infinite output

[k...@st-andrews.ac.uk]

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

Bug ID: 78846
   Summary: std1y compiler infinite output
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: k...@st-andrews.ac.uk
  Target Milestone: ---

Created attachment 40358
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40358=edit
.ii file

I created a c++14 program to implement lazy evaluation, but the compiler seems
to be producing infinite output.

Machine (1)
System: Darwin 13.4.0 x86_64 i386
G++: g++-6 (Homebrew gcc 6.2.0) 6.2.0
Command: g++-6 -std=c++1y binary_operation.cpp

Machine (2)
System: Linux 4.4.0-53-generic x86_64 x86_64 x86_64 GNU/Linux
G++: g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Command: g++ -std=c++1y binary_operation.cpp

(Actually, trying to compile with clang produces the same result).

For preprocessed file, see the attachment.

CODE
--

#include 

static const auto add = [](auto a, auto b) {return a + b;};
static const auto sub = [](auto a, auto b) {return a - b;};
static const auto mul = [](auto a, auto b) {return a * b;};
static const auto frac = [](auto a, auto b) {return a / b;};

template  class BinaryOP;

template  using Addition = BinaryOP ;
template  using Subtraction = BinaryOP ;
template  using Multiplication = BinaryOP ;
template  using Division = BinaryOP ;

static const auto make_binop = [](auto a, auto b, auto F) { return
BinaryOP(a, b, F); };
static const auto make_add = [](auto a, auto b) { return make_binop(a, b, add);
};
static const auto make_sub = [](auto a, auto b) { return
Subtraction(a, b, sub); };
static const auto make_mul = [](auto a, auto b) { return
Multiplication(a, b, mul); };
static const auto make_div = [](auto a, auto b) { return Division(a, b, frac); };

template 
class BinaryOP {
protected:
  typedef BinaryOP  THIS_T;
  A lhs;
  B rhs;
  F func;
public:
  BinaryOP(A lhs, B rhs, F ):
lhs(lhs), rhs(rhs), func(func)
  {}
  virtual ~BinaryOP()
  {}
  template 
  operator T() {
return func(T(lhs), T(rhs));
  }
  template 
  Addition operator+(const T ) {
return make_add(*this, other);
  }
  template 
  Subtraction operator-(const T ) {
return make_sub(*this, other);
  }
  template 
  Multiplication operator*(const T ) {
return make_mul(*this, other);
  }
  template 
  Division operator/(const T ) {
return make_div(*this, other);
  }

  friend std::ostream <<(std::ostream , const THIS_T ) {
os << "(binop: " << bin.lhs << ", " << bin.rhs << ")";
return os;
  }
};

int main() {
  std::cout << make_add(2, 3) + make_sub(5, 6) * make_add(3, 0) << std::endl;
}

--

The problem appeared when I changed:

static const auto make_add = [](auto a, auto b) { return Addition(a, b, add); };

into

static const auto make_add = [](auto a, auto b) { return make_binop(a, b, add);
};


OUTPUT (first few lines):
--

binary_operator.cpp: In instantiation of 'BinaryOP::operator T() [with
T = BinaryOP >,
BinaryOP >, BinaryOP >, const >,
const >; A = int; B = int; F = ]':
binary_operator.cpp:47:17:   required from 'BinaryOP::operator T()
[with T = BinaryOP >,
BinaryOP >, BinaryOP >, const >,
const >; A = BinaryOP >; B = BinaryOP >,
BinaryOP >, const >;
F = ]'
binary_operator.cpp:51:33:   required from 'Addition, T>
BinaryOP::operator+(const T&) [with T = BinaryOP >, BinaryOP >,
const >; A = int; B = int; F = ; Addition, T> = BinaryOP >, BinaryOP >, BinaryOP >, const >, const >]'
binary_operator.cpp:73:63:   required from here
binary_operator.cpp:47:17: 

[Bug fortran/78822] [cleanup] replace static char buffers by build_message_string

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #22 from Jerry DeLisle  ---
(In reply to janus from comment #0)
> Several functions in interface.c use static-size char buffers for
> constructing error messages, e.g.:
> 
> * gfc_compare_interfaces
> * gfc_check_result_characteristics
> * gfc_check_dummy_characteristics#
> * ...
> 
> It would be more efficient to replace those by std::string, in order to
> allocate the memory dynamically as needed (and only if needed at all).

Efficient in what way? Memory use? Insignificant. Performance? No.

I suggest leaving this alone and close it as dont bother. If its not broke
don't fix it. Just my 2 cents worth.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to janus from comment #10)
> The attached patch seems to make the original comment 0 as well as the
> polymorphic version in comment 7 work. Regtesting now ...

Regtesting was successful. There might be some commas missing in the output,
though (not sure). Comments welcome.

[Bug fortran/78239] [5/6/7 Regression] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #8 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #7)
> > URL: https://gcc.gnu.org/viewcvs?rev=243773=gcc=rev
> > ...
> 
> The two tests give an ICE: see
> https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg01810.html.

I also see both ICEs here:

$ gfortran-7 fimplicit_none_1.f90 -fimplicit-none
f951: internal compiler error: Segmentation fault
0xfdc762 crash_signal
/home/jweil/gcc/trunk/gcc/toplev.c:333
0x7c3ee1 char_len_param_value
/home/jweil/gcc/trunk/gcc/fortran/decl.c:926
0x7c7e4f gfc_match_char_spec(gfc_typespec*)
/home/jweil/gcc/trunk/gcc/fortran/decl.c:2850
0x7c84f3 gfc_match_decl_type_spec(gfc_typespec*, int)
/home/jweil/gcc/trunk/gcc/fortran/decl.c:3058
0x7cb8ca gfc_match_data_decl()
/home/jweil/gcc/trunk/gcc/fortran/decl.c:4820
0x852caa match_word
/home/jweil/gcc/trunk/gcc/fortran/parse.c:65
0x8538b2 decode_statement
/home/jweil/gcc/trunk/gcc/fortran/parse.c:376
0x8581fa next_free
/home/jweil/gcc/trunk/gcc/fortran/parse.c:1179
0x8587fd next_statement
/home/jweil/gcc/trunk/gcc/fortran/parse.c:1411
0x85b95f parse_spec
/home/jweil/gcc/trunk/gcc/fortran/parse.c:3599
0x85ea78 parse_progunit
/home/jweil/gcc/trunk/gcc/fortran/parse.c:5585
0x85f96c gfc_parse_file()
/home/jweil/gcc/trunk/gcc/fortran/parse.c:6101
0x8b90cd gfc_be_parse_file
/home/jweil/gcc/trunk/gcc/fortran/f95-lang.c:202

[Bug libfortran/78833] Misleading IOMSG after failed WRITE(...,POS=) on unconnected formatted stream file

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to mecej4 from comment #3)
> I understand what happens, and this is not a bug per se', but in normal
> usage the message wording can be confusing.
> 
> During the second run, the OPEN fails because 'NEW' is specified and the
> file already exists.
> 
> If the program does not stop when the OPEN failed and goes on to the WRITE,
> the unit is not open or connected, so an implicit OPEN is performed to file
> 'FORT10', with no keyword options in the implicit OPEN. Therefore, the newly
> created FORT10 is not a stream file. but a simple formatted sequential file,
> and the WRITE fails because it contains a POS= clause. 
> 
> These details are not immediately evident when one looks at the WRITE
> statement, hence the possibility of confusion. Wording such as "'POS='
> clause in WRITE to sequential formatted file FORT10" would alert the user to
> what went wrong and how to resolve the problem.

Looks like a programming error on the part of a user.  If a
programmer requests the iostat of an OPEN, and then refuses
to act of the return value then the programmer gets want
the get.  Specifically your bug is here:

if(iok /= 0)write(*,*) 'IOSTAT after OPEN: ',IOK,' ',trim(msg)

A properly written program would do

if(iok /= 0)then
  write(*,*) 'IOSTAT after OPEN: ',IOK,' ',trim(msg)
  stop
end if

or 

if(iok /= 0)then
  write(*,*) 'IOSTAT after OPEN: ',IOK,' ',trim(msg)
  call do_something_clever_here.
end if

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
Created attachment 40357
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40357=edit
draft patch

The attached patch seems to make the original comment 0 as well as the
polymorphic version in comment 7 work. Regtesting now ...

[Bug target/78105] ICE during LTO bootstrap on AARCH64 with gold linker

[tulipawn at gmail dot com]

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

--- Comment #13 from PeteVine  ---
Also, could these (sample) warnings actually matter when using ld.gold? NB,
lra-constraints.c features in the previously provided backtrace:

../../libdecnumber/decNumber.c:3582:0: note: code may be misoptimized unless
-fno-strict-aliasing is used
../../gcc/../libdecnumber/decNumber.h:118:0: warning: type of
‘decNumberFromString’ does not match original declaration [-Wlto-type-mismatch]
   decNumber * decNumberFromString(decNumber *, const char *, decContext *);

../../libdecnumber/decNumber.h:118:0: warning: type of ‘decNumberFromString’
does not match original declaration [-Wlto-type-mismatch]
   decNumber * decNumberFromString(decNumber *, const char *, decContext *);

../../libdecnumber/decNumber.h:118:0: warning: type of ‘decNumberFromString’
does not match original declaration [-Wlto-type-mismatch]
   decNumber * decNumberFromString(decNumber *, const char *, decContext *);

../../libdecnumber/decNumber.h:118:0: warning: type of ‘decNumberFromString’
does not match original declaration [-Wlto-type-mismatch]
   decNumber * decNumberFromString(decNumber *, const char *, decContext *);

../../libdecnumber/decNumber.c:489:0: note: ‘decNumberFromString’ was
previously declared here
 decNumber * decNumberFromString(decNumber *dn, const char chars[],

../../libdecnumber/decNumber.c:489:0: note: code may be misoptimized unless
-fno-strict-aliasing is used
../../gcc/vec.h:1552:1: warning: ‘safe_push’ violates the C++ One Definition
Rule  [-Wodr]
 vec::safe_push (const T  MEM_STAT_DECL)
 ^
../../gcc/vec.h:1552:1: note: return value type mismatch
 vec::safe_push (const T  MEM_STAT_DECL)
 ^
../../gcc/loop-invariant.c:100:8: note: type ‘struct invariant’ itself violate
the C++ One Definition Rule
 struct invariant
^
../../gcc/lra-constraints.c:4742:8: note: the incompatible type is defined here
 struct invariant
^
../../gcc/vec.h:1552:1: note: ‘safe_push’ was previously declared here
 vec::safe_push (const T  MEM_STAT_DECL)
 ^
../../gcc/vec.h:1552:1: note: code may be misoptimized unless
-fno-strict-aliasing is used
../../gcc/vec.h:1540:1: warning: ‘quick_push’ violates the C++ One Definition
Rule  [-Wodr]
 vec::quick_push (const T )
 ^
../../gcc/vec.h:1540:1: note: return value type mismatch
 vec::quick_push (const T )
 ^
../../gcc/loop-invariant.c:100:8: note: type ‘struct invariant’ itself violate
the C++ One Definition Rule
 struct invariant
^
../../gcc/lra-constraints.c:4742:8: note: the incompatible type is defined here
 struct invariant
^
../../gcc/vec.h:1540:1: note: ‘quick_push’ was previously declared here
 vec::quick_push (const T )
 ^
../../gcc/vec.h:1540:1: note: code may be misoptimized unless
-fno-strict-aliasing is used

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|jvdelisle at gcc dot gnu.org   |janus at gcc dot gnu.org

--- Comment #9 from janus at gcc dot gnu.org ---
Jerry, I don't want to steal this PR from you ;) but I think I have a rather
complete patch by now. If you have any comments, please let me know!

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
This patch seems to produce the correct dump for the example in comment 7:

Index: gcc/fortran/trans-io.c
===
--- gcc/fortran/trans-io.c  (revision 243773)
+++ gcc/fortran/trans-io.c  (working copy)
@@ -1713,6 +1713,32 @@ transfer_namelist_element (stmtblock_t * block, co
  vtable = gfc_build_addr_expr (pvoid_type_node, vtable);
}
 }
+  else if (ts->type == BT_CLASS)
+{
+  gfc_symbol *derived = ts->u.derived->components->ts.u.derived;
+  gfc_symtree *tb_io_st = gfc_find_typebound_dtio_proc (derived,
+   last_dt == WRITE,
true);
+  if (tb_io_st)
+   {
+ gfc_se se;
+ gfc_symtree *st = gfc_find_symtree (sym->ns->sym_root, sym->name);
+ // build vtable expr
+ gfc_expr *expr = gfc_get_variable_expr (st);
+ gfc_add_vptr_component (expr);
+ gfc_init_se (, NULL);
+ se.want_pointer = 1;
+ gfc_conv_expr (, expr);
+ vtable = se.expr;
+ // build dtio expr
+ gfc_add_component_ref (expr,
+tb_io_st->n.tb->u.generic->specific_st->name);
+ gfc_init_se (, NULL);
+ se.want_pointer = 1;
+ gfc_conv_expr (, expr);
+ gfc_free_expr (expr);
+ dtio_proc = se.expr;
+   }
+}

   if (ts->type == BT_CHARACTER)
 tmp = ts->u.cl->backend_decl;


The library call with this looks like:

_gfortran_st_set_nml_dtio_var (_parm.3, , &"x"[1]{lb: 1 sz: 1}, 0, 0, 56,
x._vptr->write_formatted, (struct __vtype_m_T *) x._vptr);

That seems correct to me, but still the output is wrong:


 X=�
 /

So I guess something in the library still fails, and I already have a suspicion
...

[Bug fortran/78239] [5/6/7 Regression] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> Author: tkoenig
> Date: Sat Dec 17 11:13:16 2016
> New Revision: 243773
>
> URL: https://gcc.gnu.org/viewcvs?rev=243773=gcc=rev
> ...

The two tests give an ICE: see
https://gcc.gnu.org/ml/gcc-testresults/2016-12/msg01810.html.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
So, here is a corrected test for the polymorphic case:

MODULE m
  IMPLICIT NONE
  TYPE :: t
CHARACTER :: c
  CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED) => write_formatted
PROCEDURE :: read_formatted
GENERIC :: READ(FORMATTED) => read_formatted
  END TYPE
CONTAINS
  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
WRITE (unit, "(A)", IOSTAT=iostat, IOMSG=iomsg) dtv%c
  END SUBROUTINE
  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
READ (unit, "(A)", IOSTAT=iostat, IOMSG=iomsg) dtv%c
  END SUBROUTINE read_formatted
END MODULE

PROGRAM p
  USE m
  IMPLICIT NONE
  class(t), allocatable :: x
  NAMELIST /nml/ x
  x = t('a')
  WRITE (*, nml)
END


It currently prints (with my patch from comment 4, but probably also without):


 X=
 /

Apparently 'write_formatted' is not called. The dump for the non-poly version
from comment 0/3 shows:

_gfortran_st_set_nml_dtio_var (_parm.3, x, &"x"[1]{lb: 1 sz: 1}, 0, 0, 40,
write_formatted, (void *) &__vtab_m_T);

But for the polymorphic version it has:

_gfortran_st_set_nml_dtio_var (_parm.3, , &"x"[1]{lb: 1 sz: 1}, 0, 0, 56,
0B, 0B);

Neither the DTIO procedure nor the vtab is called. The DTIO procedure we need
here is "x._vptr->write_formatted".

Btw why do we actually pass the vtab in the first case?

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> Btw, this variant is wrongly rejected:
> 
> [..]
> 
>NAMELIST /nml/ x
>1
> Error: NAMELIST object ‘x’ in namelist ‘nml’ at (1) is polymorphic and
> requires a defined input/output procedure

Sorry, false alarm. In principle the error message is correct, although the
wording is maybe a bit off: Both an input *and* output procedure is required!

I'd suggest this change:

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 243773)
+++ gcc/fortran/resolve.c   (working copy)
@@ -13871,8 +13871,8 @@ resolve_fl_namelist (gfc_symbol *sym)
   if (nl->sym->ts.type == BT_CLASS && !dtio)
{
  gfc_error ("NAMELIST object %qs in namelist %qs at %L is "
-"polymorphic and requires a defined input/output "
-"procedure", nl->sym->name, sym->name, >declared_at);
+"polymorphic and requires defined input and output "
+"procedures", nl->sym->name, sym->name,
>declared_at);
  return false;
}

[Bug libfortran/78833] Misleading IOMSG after failed WRITE(...,POS=) on unconnected formatted stream file

[mecej4 at operamail dot com]

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

--- Comment #3 from mecej4 at operamail dot com ---
I understand what happens, and this is not a bug per se', but in normal usage
the message wording can be confusing.

During the second run, the OPEN fails because 'NEW' is specified and the file
already exists.

If the program does not stop when the OPEN failed and goes on to the WRITE, the
unit is not open or connected, so an implicit OPEN is performed to file
'FORT10', with no keyword options in the implicit OPEN. Therefore, the newly
created FORT10 is not a stream file. but a simple formatted sequential file,
and the WRITE fails because it contains a POS= clause. 

These details are not immediately evident when one looks at the WRITE
statement, hence the possibility of confusion. Wording such as "'POS=' clause
in WRITE to sequential formatted file FORT10" would alert the user to what went
wrong and how to resolve the problem.

[Bug rtl-optimization/65618] [5/6/7 Regression] gnat bootstrap comparison failure on mips{,el}-linux-gnu

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
(In reply to James Cowgill from comment #9)
> Created attachment 40348 [details]
> pr-65618.patch

Thanks for the patch, looks like a correct fix to me FWIW.
It looks like we could also defer the calculation of "after"
until just before the emit_insn_after_setloc call.

[Bug libstdc++/71444] Error constants for MinGW-w64

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Proposed patch that enables all error codes in mingw-w64 v5 and above:

https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01533.html

[Bug target/78105] ICE during LTO bootstrap on AARCH64 with gold linker

[tulipawn at gmail dot com]

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

PeteVine  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #12 from PeteVine  ---
 The crash still reproduces on aarch64. Any suggestions on the ld.gold
connection?

[Bug fortran/78239] [5/6/7 Regression] ICE in char_len_param_value, at fortran/decl.c:926, with -fimplicit-none

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Dec 17 11:13:16 2016
New Revision: 243773

URL: https://gcc.gnu.org/viewcvs?rev=243773=gcc=rev
Log:
2016-12-17  Thomas Koenig  

PR fortran/78239
* decl.c(char_len_param_value): Also check for -fimplicit-none
when determining if implicit none is in force.

2016-12-17  Thomas Koenig  

PR fortran/78239
* gfortran.dg/fimplicit_none_1.f90:  New test.
* gfortran.dg/fimplicit_none_2.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/fimplicit_none_1.f90
trunk/gcc/testsuite/gfortran.dg/fimplicit_none_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78822] [cleanup] replace static char buffers by build_message_string

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[cleanup] replace static|[cleanup] replace static
   |char buffers by std:string  |char buffers by
   ||build_message_string

--- Comment #21 from janus at gcc dot gnu.org ---
Given the amount of discussion about std::string (and resistance against it), I
will for now go with using build_message_string (thus changing PR title) ...

[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #11 from Jan Hubicka  ---
I will take a look. I think we should try to fix the profile updating after
jump threading again and see if we need any hacks after that.

[Bug ada/78845] New: Inverse (Real_Matrix) result has wrong bounds

[simon at pushface dot org]

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

Bug ID: 78845
   Summary: Inverse (Real_Matrix) result has wrong bounds
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon at pushface dot org
  Target Milestone: ---
  Host: x86_64-apple-darwin15
Target: x86_64-apple-darwin15
 Build: x86_64-apple-darwin15

Created attachment 40356
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40356=edit
Reproducer

ARM G.3.1(72) for Inverse says

"... The index ranges of the result are A'Range(2) and A'Range(1). ..."

but with GCC’s code for Ada.Numerics.Real_Arrays.Inverse the second dimension’s
index range starts at 1, not A’First(1).

Demo:

with Ada.Numerics.Real_Arrays;
with Ada.Text_Io; use Ada.Text_Io;
procedure Inverse_Problem is
   A : Ada.Numerics.Real_Arrays.Real_Matrix (-10 .. -10, 12 .. 12)
 := (others => (others => -120.0));
   A_Inv : constant Ada.Numerics.Real_Arrays.Real_Matrix
 := Ada.Numerics.Real_Arrays.Inverse (A);
begin
   Put_Line ("1st index: " & Integer'Image (A_Inv'First (1))
   & " .. " & Integer'Image (A_Inv'Last (1)));
   Put_Line ("2nd index: " & Integer'Image (A_Inv'First (2))
   & " .. " & Integer'Image (A_Inv'Last (2)));
end Inverse_Problem;

Output:

$ ./inverse_problem 
1st index:  12 ..  12
2nd index:  1 ..  1

[Bug target/78844] [6 Regression] target_clones causes compiler memory corruption

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
On the trunk I get similar corruption ICE with r242607, r242608 turns it into
another ICE because of the broken avx5124fma patches, finally fixed with
r242627.
But 6 branch doesn't have the avx5124fma support, so r243404 should be enough.

[Bug middle-end/78419] ICE with target_clone on invalid target

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||steven at uplinklabs dot net

--- Comment #8 from Markus Trippelsdorf  ---
*** Bug 78844 has been marked as a duplicate of this bug. ***

[Bug target/78844] [6 Regression] target_clones causes compiler memory corruption

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #2)
> Hasn't this been fixed in r243404 already?  Then it would be a dup of
> PR78419.

Yeah, sorry my gcc-6 branch compiler is two months old.

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

[Bug target/78844] [6 Regression] target_clones causes compiler memory corruption

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Hasn't this been fixed in r243404 already?  Then it would be a dup of PR78419.

[Bug c++/78842] "error: declaration of 'bool icase' shadows a parameter" should be warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-17
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This is not a self-contained testcase, please include either a preprocessed
source, or reduced self-contained testcase.
There are several cases in the C++ FE that errors out rather than just warns
about shadowing, e.g.
void foo1 (int d)
{
  double d; // { dg-error "shadows a parameter" }
}
is an error rather than warning,
template // { dg-message "template parameter" }
void f()
{
int t = 1;   // { dg-error "shadows" }
}
as well, while 
void foo2 (int d)
{
  {
double d; // { dg-warning "shadows a parameter" }
  }
}
is a warning.  I haven't looked up the standard where it says the first case is
invalid, but as from your snippet is unclear what is going on, it would be a
waste of time.

[Bug target/78844] [6 Regression] target_clones causes compiler memory corruption

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-17
 CC||trippels at gcc dot gnu.org
  Component|other   |target
Summary|target_clones causes|[6 Regression]
   |compiler memory corruption  |target_clones causes
   ||compiler memory corruption
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed. trunk is fine. 
(the #pragma is not necessary)

[Bug other/78844] New: target_clones causes compiler memory corruption

[steven at uplinklabs dot net]

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

Bug ID: 78844
   Summary: target_clones causes compiler memory corruption
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steven at uplinklabs dot net
  Target Milestone: ---

Using modified version of test case from PR78808:

---
__attribute__((target_clones("avx2,fma,bmi,bmi2", "arch=sandybridge",
"default")))
static void _saxpy(int n, float a, float * restrict x, float * restrict y)
{
#pragma omp parallel for
for (int i = 0; i < n; ++i)
y[i] = a*x[i] + y[i];
}

void saxpy(int n, float a, float * restrict x, float * restrict y)
{
return _saxpy(n, a, x, y);
}
---

Only difference is the first argument for target_clones. Original intent was to
list the necessary features provided in arch=haswell without requiring an exact
architecture match (i.e. arch=haswell code path doesn't selected on a Skylake
host, so my theory was that feature checks would work better).

Attempting to compile the above results in memory corruption in cc1:

$ gcc -O3 -std=gnu11 -ffast-math -S test.c
*** Error in `/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1': malloc(): memory
corruption (fast): 0x02e5f690 ***
=== Backtrace: =
/usr/lib/libc.so.6(+0x70cdb)[0x7f8442a3fcdb]
/usr/lib/libc.so.6(+0x770b6)[0x7f8442a460b6]
/usr/lib/libc.so.6(+0x794e1)[0x7f8442a484e1]
/usr/lib/libc.so.6(__libc_malloc+0x54)[0x7f8442a49eb4]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(xmalloc+0x18)[0x10bd1f8]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1[0xff477a]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_ZN12symbol_table29call_cgraph_duplication_hooksEP11cgraph_nodeS1_+0x2c)[0x6e93bc]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_ZN11cgraph_node20create_version_cloneEP9tree_node3vecIP11cgraph_edge7va_heap6vl_ptrEP11bitmap_head+0x232)[0x6f9082]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_ZN11cgraph_node30create_version_clone_with_bodyE3vecIP11cgraph_edge7va_heap6vl_ptrEPS0_IP15ipa_replace_map5va_gc8vl_embedEP11bitmap_headbSD_P15basic_block_defPKc+0xb1)[0x6f9161]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1[0x101a7a0]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1[0x101a865]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_Z16execute_one_passP8opt_pass+0x163)[0x954113]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_Z21execute_ipa_pass_listP8opt_pass+0x92)[0x954d72]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1[0x6f57aa]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_ZN12symbol_table25finalize_compilation_unitEv+0xd3)[0x6f7533]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1[0xa02c85]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_ZN6toplev4mainEiPPc+0x6d4)[0x5de7d4]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(main+0x27)[0x5e09a7]
/usr/lib/libc.so.6(__libc_start_main+0xf1)[0x7f84429ef321]
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1(_start+0x2a)[0x5e0daa]
=== Memory map: 
0040-01a7b000 r-xp  fe:00 25167806  
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1
01c7b000-01c81000 r--p 0167b000 fe:00 25167806  
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1
01c81000-01c8e000 rw-p 01681000 fe:00 25167806  
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/cc1
01c8e000-01dd8000 rw-p  00:00 0 
02d47000-02ec1000 rw-p  00:00 0  [heap]
7f843c00-7f843c021000 rw-p  00:00 0 
7f843c021000-7f844000 ---p  00:00 0 
7f84423d6000-7f84423ec000 r-xp  fe:00 25171169  
/usr/lib/libgcc_s.so.1
7f84423ec000-7f84425eb000 ---p 00016000 fe:00 25171169  
/usr/lib/libgcc_s.so.1
7f84425eb000-7f84425ec000 r--p 00015000 fe:00 25171169  
/usr/lib/libgcc_s.so.1
7f84425ec000-7f84425ed000 rw-p 00016000 fe:00 25171169  
/usr/lib/libgcc_s.so.1
7f84425ed000-7f84427ed000 rw-p  00:00 0 
7f84427ed000-7f84429cf000 r--p  fe:00 25186508  
/usr/lib/locale/locale-archive
7f84429cf000-7f8442b64000 r-xp  fe:00 25171021  
/usr/lib/libc-2.24.90.so
7f8442b64000-7f8442d63000 ---p 00195000 fe:00 25171021  
/usr/lib/libc-2.24.90.so
7f8442d63000-7f8442d67000 r--p 00194000 fe:00 25171021  
/usr/lib/libc-2.24.90.so
7f8442d67000-7f8442d69000 rw-p 00198000 fe:00 25171021  
/usr/lib/libc-2.24.90.so
7f8442d69000-7f8442d6d000 rw-p  00:00 0 
7f8442d6d000-7f8442e7 r-xp  fe:00 25171130  
/usr/lib/libm-2.24.90.so
7f8442e7-7f844306f000 ---p 00103000 fe:00 25171130  
/usr/lib/libm-2.24.90.so
7f844306f000-7f844307 r--p 00102000 fe:00 25171130  
/usr/lib/libm-2.24.90.so
7f844307-7f8443071000 rw-p 00103000 fe:00 25171130  
/usr/lib/libm-2.24.90.so

[Bug c++/78843] error: 'functionname' was not declared in this scope

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-17
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
You haven't included preprocessed source, so it is hard to say for sure, but:
find.cpp:498:41: error: 'vsOSSortCompare' was not declared in this scope
 std::sort(dirs.begin(), dirs.end(), vsOSSortCompare);
and
bool VSOSUniqueCompare(std::string first, std::string second/*, bool
icase=false*/);

bool VSOSSortCompare(std::string first, std::string second/*, bool
icase=false*/);
are different identifiers, C/C++ is case sensitive.

[Bug c++/78840] [5/6/7 Regression] ICE with const variables in templates implicitly captured by nested lambda expressions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-17
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|ICE with const variables in |[5/6/7 Regression] ICE with
   |templates implicitly|const variables in
   |captured by nested lambda   |templates implicitly
   |expressions |captured by nested lambda
   ||expressions
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r216056.

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Component|other   |debug
   Target Milestone|--- |6.4
Summary|DWARF output different  |[6/7 Regression] DWARF
   |between GCC 5 and 6 |output different between
   ||GCC 5 and 6

--- Comment #7 from Jakub Jelinek  ---
The behavior changed with r231762, I haven't looked (yet) into details if it is
valid or not and why that changed.