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

[su at cs dot ucdavis.edu]

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

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

It affects 6.x and later, and is a regression from 5.x. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20161218 (experimental) [trunk revision 243783] (GCC) 
$ 
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-5.4 -O3 small.c; ./a.out
$ 
$ gcc-trunk -O3 small.c
$ timeout -s 9 5 ./a.out
Killed
$ 





int a, b, c, d, e, f[3]; 

int main() 
{
  while (d)
while (1)
  ;
  int g = 0, h, i = 0;
  for (; g < 21; g += 9) 
{
  int j = 1;
  for (h = 0; h < 3; h++)
f[h] = 1;
  for (; j < 10; j++) {
d = i && (b ? 0 : c); 
i = 1;
if (g)
  a = e;
  }
  }
  return 0;
}

[Bug libstdc++/78851] Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
On linux with glibc, both versions output the same number, so your libm is to
blame. Normally, the int version, implemented with multiplications, may be less
accurate than the general version. And gcc does generate multiplications for
you if you pass it the flag -ffast-math (probably something a little weaker is
sufficient), meaning that you are ok with the slight loss of precision as long
as the program is faster. Depending on the flags (-fwhole-program or -flto for
instance), you may even get f inlined and the result of pow is computed at
compile-time by MPFR ;-)

The template version right below in cmath catches the int case, uses
__builtin_powl, which gcc's optimizers know they can replace with
__builtin_powil if the second argument is converted from an integer and the
circumstances are right (command-line flags). I don't see what in the comment
in cmath makes it look like a temporary patch, we tend to add those DR markers
as documentation of past changes, not as FIXME. Actually, I guess we could
remove those overloads completely, even in C++03, since we have the template
version. But it might confuse users who were relying on the performance benefit
(and relaxed accuracy) in C++03 even without suitable command-line flags.
Everyone should move to C++14 anyway...

[Bug driver/78772] -fstrict-aliasing should turn on Wstrict-aliasing automaticly

[ma.jiang at zte dot com.cn]

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

--- Comment #12 from ma.jiang at zte dot com.cn ---
(In reply to Jim Wilson from comment #11)
Hi Jim,
  Thank you for your patient explanations. 
> 
> If you have code with a lot of pointer casts, you should probably be
> compiling with -fno-strict-aliasing and/or -Wstrict-aliasing.  The handling
> of these options was decided a while ago, and we won't be making any changes
> here.
  OK, Now I understand the basic strategy of gcc for the strict-alias stuff(and
other similar optimizations).

[Bug target/78855] New: -mtune=generic should keep cmp/jcc together. AMD and Intel both macro-fuse

[peter at cordes dot ca]

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

Bug ID: 78855
   Summary: -mtune=generic should keep cmp/jcc together. AMD and
Intel both macro-fuse
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: x86-64-*-*

-mtune=generic and -mtune=intel currently don't optimize for macro-fusion of
CMP/JCC or TEST/JCC.  They should, since it helps most CPUs from the last ~5
years or so, and I think barely hurts old / low-power (atom) ones at all.

int ffs_loop(unsigned *nums) {
int total = 0;
for (int i = 0; i < 1024; i++)
total +=  __builtin_ffs(nums[i]);
return total;
}

gcc7.0 20161113 -O3 produces:

leaq4096(%rdi), %rsi
xorl%eax, %eax
movl$-1, %ecx
.L2:
bsfl(%rdi), %edx
cmove   %ecx, %edx
addq$4, %rdi

cmpq%rdi, %rsi # can't macro-fuse: separated by LEA
leal1(%rdx,%rax), %eax
jne .L2# loop branch
ret

instead of this (with -mtune=haswell):
...
leal1(%rdx,%rax), %eax
cmpq%rdi, %rsi # can macro-fuse with jne on AMD and Intel
jne .L2

Intel Nehalem and Sandybridge-family can macro-fuse that.  So can AMD
Bulldozer-family.  In 32-bit mode, Core2 can also macro-fuse that cmp/jcc. 
(See Agner's microarch pdf: http://agner.org/optimize/).  Sandybridge-family
can even macro-fuse many ALU ops (like dec and sub) with some flavours of JCC,
but AMD can only fuse TEST and CMP (but can do it with any JCC, even obscure
ones like JP).

Bizarrely, not even -mtune=intel tries to keep compare-and-branches together.

IMO, that should be enabled in -mtune=generic and -mtune=intel, and only
disabled in -mtune=atom, silvermont, k8, and k10.  (and other specific -mtune
options for even older CPUs).

The penalty for doing the compare a couple instructions later on CPUs that
don't support fusion might increasing the mispredict penalty by a couple
cycles, I think.  So I don't think we'd be hurting Atom a lot to help more
common CPUs a little.

[Bug libstdc++/78851] Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11

[vz-gcc at zeitlins dot org]

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

--- Comment #2 from Vadim Zeitlin  ---
Sorry if I misunderstood but what exactly am I misinterpreting? Looking at the
code (and comment) at
https://github.com/gcc-mirror/gcc/blob/6514c52372bb36e555843b0419d71cf55eda0409/libstdc++-v3/include/c_global/cmath#L395
I thought that this check was supposed to be temporary and could be removed now
that the DR 550 has been resolved without requiring these functions to be
removed. If this is supposed to be the permanent solution then at least the
comment and the defect marker should be removed, shouldn't it?

However it seems to me that it would be better to remove the check. Not because
some code doesn't currently compile, but because the generated code with
-std=c++11 is different (certainly) and suboptimal (probably) than with
-std=c++98. E.g. if you compile and run this program

-- >8 --
#include 
#include 

void f(long double x) {
int n = -10;

printf("%.40Lf\n", std::pow(x, n));
}

int main() {
f(10.0L);
}
-- >8 --

with gcc version 6.2.0 (i686-win32-sjlj-rev1, Built by MinGW-W64 project),
it will output 0.0100018377930496 in C++98 mode but
0.0100397031165002 in C++11.

Moreover, looking at the generated assembly, in C++98 the result is computed
directly with a few multiplication and a single inverse operation, which seems
to be consistent with __builtin_powil() being used. However in C++11 mode there
is a call to _powl() instead.

Wouldn't it be better to continue to use __builtin_powil() even in C++11? If
not, this should be just closed, of course, but I'd appreciate it if you could
please explain why. TIA!

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||jvdelisle at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Blocks||78661

--- Comment #1 from janus at gcc dot gnu.org ---
This essentially blocks PR 78661, for which it is very hard to write a proper
test case as long as this bug is unfixed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661
[Bug 78661] [OOP] Namelist output missing object designator under DTIO

[Bug fortran/78854] New: [F03] DTIO namelist output not working on internal unit

[janus at gcc dot gnu.org]

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

Bug ID: 78854
   Summary: [F03] DTIO namelist output not working on internal
unit
   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: ---

Found when working on PR78661:


MODULE m
  IMPLICIT NONE
  TYPE :: t
CHARACTER :: c
  CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED) => write_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
END MODULE

PROGRAM p
  USE m
  IMPLICIT NONE
  character(len=4), dimension(3) :: buffer
  TYPE(t) :: x
  NAMELIST /nml/ x
  x = t('a')
  WRITE (buffer, nml)
  print *, buffer
END



This test case prints:

a
  / 

It seems that DTIO namelist output does not work on internal units (i.e. when
writing to a string): The second line is the output of the buffer, which is
missing the 'a'. The latter appears in a separate line. Apparently it is
written to std output instead of the buffer?!?

[Bug target/78853] aligned reads/writes (vmovdqa) emitted when no such guarantee can be made

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
IIRC __m512i, __m256i, and __m128i all have alignment requirements which is why
you are getting this code.

I think your code does not check for alignment which is broken.

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #10)
> Agree, I will look further Janus, unless you are digging into it already?

I'm currently looking into PR 78661. Would be great if you could take care of
this one. Thanks!

[Bug c/78853] New: aligned reads/writes (vmovdqa) emitted when no such guarantee can be made

[gonnet at google dot com]

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

Bug ID: 78853
   Summary: aligned reads/writes (vmovdqa) emitted when no such
guarantee can be made
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gonnet at google dot com
  Target Milestone: ---

I have an example on https://godbolt.org/g/qZ4SuT, this produces incorrect code
since at least gcc-4.9.1 (didn't test earlier).

I have a function that swaps to pieces of memory using vectorized read/write
instructions. When I pass it a 28-byte struct that has been padded to 32 bytes,
it emits two vmovdqa reads and writes.

The problem is that it does this even when it can't guarantee that the pointers
provided to it are aligned correctly.

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
(In reply to janus from comment #8)
> I think this needs to be reopened. As mentioned in comment 0, the original
> test case in itself is valid, but is invalidated by adding an I/O statement
> that references the namelist, like so:
> 

Agree, I will look further Janus, unless you are digging into it already?

[Bug target/78385] Build of libgcc2 for target arm-eabi fails, if configuration --with-abi=apcs-gnu is used (in GCC-Build)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|bootstrap   |target

--- Comment #1 from Andrew Pinski  ---
>OABI

I thought that was deprecated and/or removed :).

[Bug middle-end/78665] Unexpected warning about "assuming signed overflow does not occur when simplifying conditional"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-12-18
  Component|c   |middle-end
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Can you attach the preprocessed source?

[Bug tree-optimization/78608] [7 Regression] gimple-ssa-sprintf.c:570:17: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |7.0
Summary|gimple-ssa-sprintf.c:570:17 |[7 Regression]
   |: runtime error: negation   |gimple-ssa-sprintf.c:570:17
   |of -9223372036854775808 |: runtime error: negation
   |cannot be represented in|of -9223372036854775808
   |type 'long int' |cannot be represented in
   ||type 'long int'

[Bug target/78567] [7 Regression] GCC trunk fails to compile all-stage2-gcc in i386.c with x32 enabled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build, diagnostic
 Target||x86_64-linux-gnu
  Component|c++ |target
   Target Milestone|--- |7.0
Summary|GCC trunk fails to compile  |[7 Regression] GCC trunk
   |all-stage2-gcc in i386.c|fails to compile
   ||all-stage2-gcc in i386.c
   ||with x32 enabled

--- Comment #2 from Andrew Pinski  ---
Does this still happen?

[Bug libstdc++/78851] Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
You are misinterpreting Howard's answer. Please show code that currently
doesn't compile and you would like to be able to compile, or code that compiles
(specify the flags used) to asm that isn't as fast as you would like.

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #9 from janus at gcc dot gnu.org ---
Btw, here is another case similar to the original problem in comment 0 (from PR
78661 comment 5):


MODULE m
  IMPLICIT NONE
  TYPE :: t
CHARACTER :: c
  CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED) => write_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
END MODULE

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


Although it is supposed to be valid, this is still rejected with 

   NAMELIST /nml/ x
   1
Error: NAMELIST object ‘x’ in namelist ‘nml’ at (1) is polymorphic and requires
a defined input/output procedure

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #8 from janus at gcc dot gnu.org ---
I think this needs to be reopened. As mentioned in comment 0, the original test
case in itself is valid, but is invalidated by adding an I/O statement that
references the namelist, like so:

MODULE ma
  IMPLICIT NONE
  TYPE :: ta
INTEGER, ALLOCATABLE :: array(:)
  END TYPE ta
END MODULE ma

PROGRAM p
  USE ma
  TYPE(ta) :: x
  NAMELIST /nml/ x
  WRITE (*, nml)
END PROGRAM p

This case is not rejected after r243308 and runs into an ICE.

With gfortran 6, it is rejected with the old error. Although it is not quite
correct that the error is thrown on the namelist statement instead of the write
statement, the ICE is technically a regression.

Problem with Factory Generated code g++ 4.x, 5.x, 6.x

[Eduardo Yÿffffffffffe1nez via gcc-bugs]

Hi, I hope you are fine.

I wish to report a problem with g++ 4.x, g++ 5.x, g++ 6.x. I'm trying to 
implement a very classic Factory Method Pattern in C++, I can do it very easily 
in MS-Visual C++, but in Linux with g++ the code compiles but I get a 
segmentation fault when I run it. The code is very simple to follow and I 
reduced it to a very academic code example to try to diagnose the problem. I am 
building with the C++11 version.

I tested the problem with Netbeans in Ubuntu 14.04 (g++ 4.x and g++5.x), and 
Codeblocks in Fedora 24 (g++ 6.x) with exactly the same results. Another 
important information is that when you put all the code in a single compilation 
unit, it runs well. That's why I think is the compiler that is failing.

So, I Wish to contribute to the proyect reporting this issue. Here is the code:

*** File: resourcefactory.h ***

#ifndef RESOURCEFACTORY_H
#define RESOURCEFACTORY_H

#include 
#include 
using namespace std;

typedef map TMap;

class Resource {
public:
virtual void get(const TMap& vars) = 0;
virtual ~Resource() {}
};

typedef map TResourceMap;

class Factory
{
public:
static Resource* getResource(const string& resourcePath);
protected:
static TResourceMap registry;
};

#endif // RESOURCEFACTORY_H

*** File: resourcefactory.cpp ***
***
#include 

TResourceMap Factory::registry;
Resource* Factory::getResource(const string& resourcePath) {
return registry[resourcePath];
}

*** File: brands.h ***

#ifndef BRANDS_H
#define BRANDS_H

#include 

class Brands : public Resource
{
public:
void get(const TMap& vars) override;
virtual ~Brands() {}
};

#endif // BRANDS_H

*** File: brands.cpp ***
***
#include 
#include 
using namespace std;

void Brands::get(const TMap& vars) {
cout << "I am a BrandsResource\n";
}

class BrandsFactory : public Factory {
BrandsFactory() {
static Brands resource;
registry["/vehicle/brands"] =  // <<== here is the problem!
}
static BrandsFactory createThisFactory;
};
BrandsFactory BrandsFactory::createThisFactory;


*** File: main.cpp ***
*
#include 

int main() {
// "virtual construction" based on a string value.

Resource* res = Factory::getResource("/vehicle/brands");
TMap vars;
res->get(vars);
return 0;
}

***
When running, Codeblocks reports me the error in: stl_tree.h
   ...
  _Self&
  operator--() _GLIBCXX_NOEXCEPT
  {
_M_node = _Rb_tree_decrement(_M_node); // <== here is the error
return *this;
  }
   ...

How could I help to fix the problem? I am not very good in generic programming, 
but the error stack dump (as Codeblocks presents it) is:

#0 0x77af60aa??() (/lib64/libstdc++.so.6:??)

#1 0x4028edstd::_Rb_tree_iterator const, Resource*> 
>::operator--(this=0x7fffe410) (/usr/include/c++/6.2.1/bits/stl_tree.h:224)

#2 0x40284fstd::_Rb_tree, 
std::pair const, Resource*>, 
std::_Select1st const, Resource*> >, 
std::less >, 
std::allocator const, Resource*> > 
>::_M_get_insert_unique_pos(this=0x6062e0 , 
__k="/vehicle/brands") (/usr/include/c++/6.2.1/bits/stl_tree.h:1845)

#3 0x401fffstd::_Rb_tree, 
std::pair const, Resource*>, 
std::_Select1st const, Resource*> >, 
std::less >, 
std::allocator const, Resource*> > 
>::_M_get_insert_hint_unique_pos(this=0x6062e0 , 
__position=..., __k="/vehicle/brands") 
(/usr/include/c++/6.2.1/bits/stl_tree.h:1942)

#4 0x401c6cstd::_Rb_tree, 
std::pair const, Resource*>, 
std::_Select1st const, Resource*> >, 
std::less >, 
std::allocator const, Resource*> > 

[Bug c++/78852] ICE with Boost.Variant 1.62

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Original testcase ICEs with all supported gcc versions.

Here is a small testcase that only ICEs on trunk:

template  struct A { template  A(T, int = 0); };
using var_base = A<>;
struct B : var_base {
  using var_base::var_base;
};
int main() { B a = 0; }

[Bug target/57583] large switches with jump tables are horribly broken on m68k

[mikpelinux at gmail dot com]

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

--- Comment #8 from Mikael Pettersson  ---
Created attachment 40362
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40362=edit
patch adding -mlong-jump-table-offsets option for m68k

This is the crude patch I mentioned in an older comment, forward-ported to
trunk.  It's only a compile-time option for using long offsets, plus needed
adjustments here and there.

I haven't tried to implement CASE_VECTOR_SHORTEN_MODE since I don't think it's
useful without per-insn length attributes.

Why does the backend have three identical definitions of ASM_RETURN_CASE_JUMP?

[Bug c++/78852] New: ICE with Boost.Variant 1.62

[igorr at il dot ibm.com]

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

Bug ID: 78852
   Summary: ICE with Boost.Variant 1.62
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igorr at il dot ibm.com
  Target Milestone: ---

GCC crashes, when compiling the following code with Boost 1.62:

#include 

template
struct node1_type;

struct var_type;

using var_base = boost::variant
>;

template
struct node1_type
{
 Node child;
};

struct var_type : var_base
{
  using var_base::var_base;
};

int main()
{
  var_type v1 = 1;
}

//

prog.cc: In function 'int main()':
prog.cc:25:17: internal compiler error: in push_access_scope, at cp/pt.c:228
   var_type v1 = 1;
 ^
0x603dc7 push_access_scope
/home/heads/gcc/gcc-source/gcc/cp/pt.c:227
0x61c267 tsubst_default_argument(tree_node*, tree_node*, tree_node*, int)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:11668
0x5d5948 convert_default_arg(tree_node*, tree_node*, tree_node*, int, int)
/home/heads/gcc/gcc-source/gcc/cp/call.c:7256
0x5daac5 build_over_call
/home/heads/gcc/gcc-source/gcc/cp/call.c:7839
0x5d7b2a convert_like_real
/home/heads/gcc/gcc-source/gcc/cp/call.c:6702
0x5d7c46 convert_like_real
/home/heads/gcc/gcc-source/gcc/cp/call.c:6830
0x5df8b7 build_user_type_conversion(tree_node*, tree_node*, int, int)
/home/heads/gcc/gcc-source/gcc/cp/call.c:3987
0x6a1a15 ocp_convert(tree_node*, tree_node*, int, int, int)
/home/heads/gcc/gcc-source/gcc/cp/cvt.c:881
0x6a9a75 expand_default_init
/home/heads/gcc/gcc-source/gcc/cp/init.c:1715
0x6a9a75 expand_aggr_init_1
/home/heads/gcc/gcc-source/gcc/cp/init.c:1894
0x6a9da9 build_aggr_init(tree_node*, tree_node*, int, int)
/home/heads/gcc/gcc-source/gcc/cp/init.c:1633
0x5f3cb5 build_aggr_init_full_exprs
/home/heads/gcc/gcc-source/gcc/cp/decl.c:6159
0x5f3cb5 check_initializer
/home/heads/gcc/gcc-source/gcc/cp/decl.c:6307
0x5f71ab cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/heads/gcc/gcc-source/gcc/cp/decl.c:7019
0x684ea9 cp_parser_init_declarator
/home/heads/gcc/gcc-source/gcc/cp/parser.c:19339
0x6854ed cp_parser_simple_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:12757
0x686065 cp_parser_block_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:12592
0x686969 cp_parser_declaration_statement
/home/heads/gcc/gcc-source/gcc/cp/parser.c:12201
0x66885f cp_parser_statement
/home/heads/gcc/gcc-source/gcc/cp/parser.c:10688
0x6694fd cp_parser_statement_seq_opt
/home/heads/gcc/gcc-source/gcc/cp/parser.c:11020
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug fortran/78545] Possible correction to online LTIME documentation

[dominiq at gcc dot gnu.org]

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

--- Comment #6 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Dec 18 18:03:36 2016
New Revision: 243785

URL: https://gcc.gnu.org/viewcvs?rev=243785=gcc=rev
Log:
2016-12-18  Dominique d'Humieres  

PR fortran/78545
* intrinsic.texi: Fix documentation for GMTIME and LTIME.

* intrinsics/date_and_time.c: Fix comments for GMTIME and LTIME.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/intrinsic.texi
trunk/libgfortran/ChangeLog
trunk/libgfortran/intrinsics/date_and_time.c

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

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin15   |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-12-18
 CC||ebotcazou at gcc dot gnu.org
   Host|x86_64-apple-darwin15   |
 Ever confirmed|0   |1
  Build|x86_64-apple-darwin15   |

--- Comment #1 from Eric Botcazou  ---
Confirmed.

[Bug target/60028] TIC6X: B3 register (return address) is saved on stack when real call is replaced with sibling call in a leaf function

[wojtek.golf at interia dot pl]

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

--- Comment #2 from Wojciech Migda  ---
Still visible with gcc 5.4.1 and 6.2.1

[Bug libstdc++/78851] New: Resolve DR 550 in cmath and continue using __builtin_powil() even in C++11

[vz-gcc at zeitlins dot org]

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

Bug ID: 78851
   Summary: Resolve DR 550 in cmath and continue using
__builtin_powil() even in C++11
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vz-gcc at zeitlins dot org
  Target Milestone: ---

It looks like the `long double pow(long double, int)` overload in `` was
disabled because of the [DR
550](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3286.html#550) to
the C++11 standard which proposed removing these overloads. However [this
answer](http://stackoverflow.com/a/5627278/15275) by Howard Hinnant, who
submitted the DR in the first place, indicates that these overloads were kept
in the final version of the standard and so, AFAICS, shouldn't be disabled for
C++11 in the header.

One reason for enabling them would be (presumably, I didn't measure it, but
#11706 wouldn't have been done without it, I think) to improve performance but
another one, which is actually the one that led me to open this bug, is to
avoid gratuitous inconsistencies between C++03 and C++11.

See also #70299.

[Bug fortran/78848] [7 Regression] [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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #10)
> If you were asking if the non-typebound form using interface instead is
> valid form, yes it is.

I was wondering mainly what the non-typebound form is supposed do at runtime,
as opposed to the typebound form, but I guess I have figured that out by now.

r243784 should implement what is specified in the F03 standard in section 
9.5.3.7.3 ("Resolving derived-type input/output procedure references"). I think
this issue can be closed.

[Bug fortran/65045] [5 Regression] [F08] ICE when using the same name for a block and a variable

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #13 from Paul Thomas  ---
The invalid read in the case of comment #1 has transformed itself into a
definite memory leak of 200bytes from the same location. Given the difficulty
of tracking down problems with error recovery, this seems to me to be so benign
that I am inclined to close the PR.

Cheers

Paul

[Bug fortran/78848] [7 Regression] [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

--- Comment #10 from Jerry DeLisle  ---
(In reply to janus from comment #4)
> Sorry, actually the example in comment 3 only ICEs if the type-binding of
> the DTIO is commented out:
> 
> module m
>   type :: t
> integer :: i     contains
> ! procedure :: wf
> ! generic :: write(formatted) => wf
>   end type
>   interface write(formatted)
> procedure wf
>   end interface

If you were asking if the non-typebound form using interface instead is valid
form, yes it is. I was looking down at the main body of your program and
wandering what should the print statement do. I have not looked yet, but I
assume it should compile a call to st_write followed by a call to
st_write_done, in the empty type case. Possibly with a call to transfer_derived
in between

[Bug c++/69681] C/C++ FEs do not consider comparisons of distinct function pointers to be constant expressions

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #6 from Georg-Johann Lay  ---
(In reply to Patrick Palka from comment #3)
> Either way, such code still fails to compile.

I still don't see how the compiler could determine the addresses of functions
as they are only determined at link time.  Just suppose functions drawn from a
library or where you are def'ing symbols in the linker description file or by
means of -Wl,--defsym,foo=bar.

There are even cases where functions with different prototypes reside at the
came address (because the functions are built-in, their implementation is in
libgcc and the compiler knows that the binary code is exactly the same even
though the prototypes are not.  The avr back-end has an example of this, cf.
PR78562 for an example).

So even if there are situations where such expressions can be folded to a
compile time constant, this is not possible in general.

If an application relies on this, it's likely to have a design problem.

[Bug c++/78850] New: Parameter of returned generic lambda allegedly shadows parameter of free function

[daiw at gmx dot net]

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

Bug ID: 78850
   Summary: Parameter of returned generic lambda allegedly shadows
parameter of free function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daiw at gmx dot net
  Target Milestone: ---

Compiling the following code

template 
auto apply(X x, F f)
{
return f(x);
}

template 
auto add_value(Y y)
{
return [y](auto x)
{
return x + y;
};
}

int main()
{
apply(1, add_value(2));
}

with g++ (e.g. v. 5.4, but also newer ones) gives false shadow warnings:
https://godbolt.org/g/MMJ51o

$ g++ -Wshadow -Werror -std=c++14 shadow_test.cpp 
shadow_test.cpp: In instantiation of ‘add_value(Y):: [with
auto:1 = int; Y = int]’:
shadow_test.cpp:4:13:   required from ‘auto apply(X, F) [with X = int; F =
add_value(Y) [with Y = int]::]’
shadow_test.cpp:18:26:   required from here
shadow_test.cpp:10:22: error: declaration of ‘int x’ shadows a parameter
[-Werror=shadow]
 return [y](auto x)
  ^
shadow_test.cpp:2:14: note: shadowed declaration is here
 auto apply(X x, F f)
  ^
cc1plus: all warnings being treated as errors

Corresponding SO post:
http://stackoverflow.com/questions/41208811/parameter-of-returned-generic-lambda-allegedly-shadows-parameter-of-free-functio

[Bug fortran/78848] [7 Regression] [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 #9 from janus at gcc dot gnu.org ---
Author: janus
Date: Sun Dec 18 13:22:13 2016
New Revision: 243784

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

PR fortran/78848
* trans-io.c (get_dtio_proc): Generate non-typebound DTIO call for
class
variables, if no typebound DTIO procedure is available.

2016-12-18  Janus Weil  

PR fortran/78848
* gfortran.dg/dtio_22.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_22.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-io.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/78749] [7 Regression] bogus warning for friend member function in anonymous namespace

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
The patch looks good to me. Would you mind posting it to the list?
Thanks.

[Bug fortran/78592] [7 Regression] ICE in gfc_find_specific_dtio_proc, at fortran/interface.c:4939

[janus at gcc dot gnu.org]

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

--- Comment #4 from janus at gcc dot gnu.org ---
Author: janus
Date: Sun Dec 18 11:03:41 2016
New Revision: 243783

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

PR fortran/78592
* interfac.c (gfc_find_specific_dtio_proc): Fixup for r243005, making
sure that the generic list is followed through until the end.

2016-12-18  Janus Weil  

PR fortran/78592
* gfortran.dg/dtio_21.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dtio_21.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/78848] [7 Regression] [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 #8 from janus at gcc dot gnu.org ---
Created attachment 40361
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40361=edit
patch

The attached patch implements what I think needs to happen (and regtests
cleanly).

[Bug fortran/78848] [7 Regression] [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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug fortran/78848] [7 Regression] [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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[OOP] ICE on writing CLASS  |[7 Regression] [OOP] ICE on
   |variable with non-typebound |writing CLASS variable with
   |DTIO procedure  |non-typebound DTIO
   ||procedure

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to janus from comment #5)
> BTW, I suspect the ICE might be a regression introduced by r243609 (my fix
> for PR 78737).

Mikael's observation at https://gcc.gnu.org/ml/fortran/2016-12/msg00236.html
supports this.

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

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #6 from Mikael Morin  ---
No ICE here at r243465.

[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 #5 from janus at gcc dot gnu.org ---
BTW, I suspect the ICE might be a regression introduced by r243609 (my fix for
PR 78737).

[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 #4 from janus at gcc dot gnu.org ---
Sorry, actually the example in comment 3 only ICEs if the type-binding of the
DTIO is commented out:

module m
  type :: t
integer :: i
  contains
! procedure :: wf
! generic :: write(formatted) => wf
  end type
  interface write(formatted)
procedure wf
  end interface
contains
  subroutine wf(this, unit, b, c, iostat, iomsg)
class(t), intent(in) :: this
integer, intent(in) :: unit
character, intent(in) :: b
integer, intent(in) :: c(:)
integer, intent(out) :: iostat
character, intent(inout) :: iomsg
  WRITE (unit, "(i3)", IOSTAT=iostat, IOMSG=iomsg) this%i
  end subroutine
end

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

[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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #2)
> I think its invalid in that the type contains no object that could be
> written or even allocated.

I think empty types are valid in principle, but that's not the point. Here is a
slightly expanded test case (with a non-empty type) that should actually print
something. Still it ICEs:

module m
  type :: t
integer :: i
  contains
procedure :: wf
generic :: write(formatted) => wf
  end type
  interface write(formatted)
procedure wf
  end interface
contains
  subroutine wf(this, unit, b, c, iostat, iomsg)
class(t), intent(in) :: this
integer, intent(in) :: unit
character, intent(in) :: b
integer, intent(in) :: c(:)
integer, intent(out) :: iostat
character, intent(inout) :: iomsg
  WRITE (unit, "(i3)", IOSTAT=iostat, IOMSG=iomsg) this%i
  end subroutine
end

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