[Bug tree-optimization/69039] [6 regression] segfault with ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
Created attachment 37135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37135&action=edit
tentative patch that fixes invalid phi argument error

[Bug other/69050] libbacktrace: bsearch over unsorted array in unit_addrs_search

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

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

--- Comment #2 from Yuri Gribov  ---
> This will return a consistent answer if low/high ranges are always
> subsets or supersets

You are right, that's the case which I'm seeing.

> If you are encountering a problem, please describe it in more detail.

This was detected with a custom debugging tool so not a real bug. I'm closing
the issue then.

[Bug c++/69057] New: constexpr static variable template assertion segmentation fault

[vittorio.romeo at outlook dot com]

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

Bug ID: 69057
   Summary: constexpr static variable template assertion
segmentation fault
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

gcc.godbolt.org example: https://goo.gl/yGCVOB

---

#include 

using GLenum = unsigned int;

template 
inline constexpr auto from_enum(const T& x) noexcept
{
// Comment this line to prevent segmentation fault:
assert(true);
// 

return (GLenum)x;
}

enum class buffer_target : GLenum
{
array
};

struct vbo
{
static constexpr GLenum target_value{from_enum(buffer_target::array)};
GLenum x{target_value};
};

int main()
{
return 0;
}

[Bug c++/69057] constexpr static variable template assertion segmentation fault

[vittorio.romeo at outlook dot com]

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

--- Comment #1 from Vittorio Romeo  ---
> in constexpr expansion of ‘from_enum(array)’
> internal compiler error: Segmentation fault
  static constexpr GLenum target_value{from_enum(buffer_target::array)};

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[slyfox at inbox dot ru]

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

--- Comment #32 from Sergei Trofimovich  ---
(In reply to Andreas Schwab from comment #31)
> @ltoffx on symbol+addend doesn't make any sense.  This computes an offset
> into the GOT, so any addend needs to be added _after_ loading the actual
> symbol address from the GOT.

Aha. That +addend seems to be some sort of hint to assembler how large addend
must be.

The real addend is 992.

The address '$r1 + 163312' points to a relocation of type R_IA64_REL64LSB
itself:
  (gdb) print *(void**)($r1 + 163312)
  $1 = (void *) 0x380052a60

  readelf -a ld.so
  ...
  Relocation section '.rela.dyn' at offset 0xdd0 contains 51 entries:
Offset  Info   Type   Sym. ValueSym. Name +
Addend
  ...
  00052910  006f R_IA64_REL64LSB  380052a60

(or how objdump shows the same) objdump -r -R ld.so:
  DYNAMIC RELOCATION RECORDS
  OFFSET   TYPE  VALUE 
  ...
  00052910 REL64LSB  *ABS*+0x000380052a60

That dynamic relocation is expected to be fixed after ld reads all elf header
types, not before (we see crash exactly at elf header read time):

   
https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/rtld.c;h=52160dfde6be42eba000c4e8136de0d190617270;hb=HEAD

 377   /* Figure out the run-time load address of the dynamic linker itself. 
*/
 378   bootstrap_map.l_addr = elf_machine_load_address ();
 379 
 380   /* Read our own dynamic section and fill in the info array.  */
 381   bootstrap_map.l_ld = (void *) bootstrap_map.l_addr + elf_machine_dynamic
();
 382   elf_get_dynamic_info (&bootstrap_map, NULL);
 383 
 ...
 392   if (bootstrap_map.l_addr || !
bootstrap_map.l_info[VALIDX(DT_GNU_PRELINKED)])
 393 {
 394   /* Relocate ourselves so we can do normal function calls and
 395  data access using the global offset table.  */
 396 
 397   ELF_DYNAMIC_RELOCATE (&bootstrap_map, 0, 0, 0);
 398 }
 399   bootstrap_map.l_relocated = 1;
 400 
 401   /* Please note that we don't allow profiling of this object and
 402  therefore need not test whether we have to allocate the array
 403  for the relocation results (as done in dl-reloc.c).  */
 404 
 405   /* Now life is sane; we can call functions and access global data.
 406  Set up to use the operating system facilities, and find out from
 407  the operating system's program loader where to find the program
 408  header table in core.  Put the rest of _dl_start into a separate
 409  function, that way the compiler cannot put accesses to the GOT
 410  before ELF_DYNAMIC_RELOCATE.  */

Note we crash at line 378 while relocations are processed later(!): at line
397. That's why writing simple selfcontained examples does not make the samples
crash: running the example already has relocations adjusted correctly.

Behaviour started exhibiting itself as constant propagation got smarter and
managed to specialise 'elf_get_dynamic_info ()' for 'elf_get_dynamic_info
(&_rtld_local, ...)' where

_rtld_local._dl_rtld_map.l_info[(0x6eff - dyn->d_tag) + 66]

specialises it to:

addl r14=163312,r1;;
ld8 r14=[r14];;
adds r14=992,r14

Numbers explanation:

printf "0x%x\n" $(( (0x6eff + 66) * 8 + 2520))
# 2520 is offset of '_rtld_local._dl_rtld_map.l_info'
0x383e0
# 0x3e0 = 992

large offset to an imm overflowing ${something} and pushes it (+ip offset?) out
to a separate relocation:
  DYNAMIC RELOCATION RECORDS
  OFFSET   TYPE  VALUE 
  ...
  00052910 REL64LSB  *ABS*+0x000380052a60

Sounds plausible?

Thus I'd say it's not a gcc/binutils bug and can/should be worked around in
glibc.

[Bug tree-optimization/69058] New: segfault with ftree-parallelize-loops=2 in libgo/go/strconv/decimal.go

[vries at gcc dot gnu.org]

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

Bug ID: 69058
   Summary: segfault with ftree-parallelize-loops=2 in
libgo/go/strconv/decimal.go
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

$ gccgo src/libgo/go/strconv/decimal.go -O2 -ftree-parallelize-loops=2 -S
src/libgo/go/strconv/decimal.go: In function
strconv.RoundedInteger.pN18_go.strconv.decimal�:
src/libgo/go/strconv/decimal.go:397:1: internal compiler error: Segmentation
fault
 func (a *decimal) RoundedInteger() uint64 {
 ^

0xb6ab1f crash_signal
src/gcc/toplev.c:334
0xdfa128 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
src/gcc/tree.h:3110
0xdfa128 build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**)
src/gcc/tree.c:11014
0xdfa36d build_call_expr(tree_node*, int, ...)
src/gcc/tree.c:11064
0xa220c3 expand_omp_atomic_mutex
src/gcc/omp-low.c:12257
0xa220c3 expand_omp_atomic
src/gcc/omp-low.c:12344
0xa220c3 expand_omp
src/gcc/omp-low.c:13195
0xa213e0 expand_omp
src/gcc/omp-low.c:13141
0xa23c2d execute_expand_omp
src/gcc/omp-low.c:13380
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/69055] Internal compiler error -fsanitize=float-cast-overflow

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to physiker from comment #0)
> Created attachment 37134 [details]
> Source code
> 
> t.f90
>   SUBROUTINE TSTD
> 
>   IMPLICIT NONE
> 
>   INTEGER*4 N
>  
>   COMMON /COMMI/DATEN(10)
> 
>   type T_daten
>   sequence
>  real(8) daten
>   end type T_daten
> 
>   type(T_daten) :: daten
> 
>   integer(4) ::  j=1
> 
>   N=daten(j)%daten
>  
>   END SUBROUTINE TSTD
> 
> peter@linux:~/devel/build-gcc> LANG=C gfortran-6 -v -save-temps -c t.f90
> -fby GNU C version 6.0.0 20151223 (experimental), GMP version 5.1.3,
> MPFR version 3.1.2, MPC version 1.0.2, isl version none
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> t.f90:18:0:
> 
>N=daten(j)%daten
>

The code is non-conforming Fortran.  daten(j)%daten is used uninitialized.
gfortan can do anything it wants with the code, including throwing an 
error.

-- 
steve

[Bug tree-optimization/69058] segfault with ftree-parallelize-loops=2 in libgo/go/strconv/decimal.go

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 37136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37136&action=edit
reduced test-case

[Bug fortran/69055] Internal compiler error -fsanitize=float-cast-overflow

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  ---
On Sat, Dec 26, 2015 at 05:15:27PM +, kargl at gcc dot gnu.org wrote:
> > 
> >N=daten(j)%daten
> >
> 
> The code is non-conforming Fortran.  daten(j)%daten is used uninitialized.
> gfortan can do anything it wants with the code, including throwing an 
> error.
> 

After making the code at least conform to the Fortran 
standard and removing the overuse of "daten", the error
still occurs.

subroutine tstd
   implicit none
   integer n
   type a
  real(8) b
   end type a
   type(a) :: daten(10)
   integer ::  j = 1
   daten(:)%b = 42
   n = daten(j)%b
end subroutine tstd

The -fdump-tree-original output is 

tstd ()
{
  struct a daten[10];
  static integer(kind=4) j = 1;
  integer(kind=4) n;

  {
integer(kind=4) S.0;

S.0 = 1;
while (1)
  {
if (S.0 > 10) goto L.1;
daten[S.0 + -1].b = 4.2e+1;
S.0 = S.0 + 1;
  }
L.1:;
  }
  n = (integer(kind=4)) daten[NON_LVALUE_EXPR  + -1].b;
}

which looks like what I expect.  It seems that -fsanitize=float-cast-overflow
option has a false positive.

[Bug fortran/69055] Internal compiler error -fsanitize=float-cast-overflow

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Sat, Dec 26, 2015 at 05:43:56PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69055
> 
> --- Comment #2 from Steve Kargl  ---
> On Sat, Dec 26, 2015 at 05:15:27PM +, kargl at gcc dot gnu.org wrote:
> > > 
> > >N=daten(j)%daten
> > >
> > 
> > The code is non-conforming Fortran.  daten(j)%daten is used uninitialized.
> > gfortan can do anything it wants with the code, including throwing an 
> > error.
> > 
> 
> After making the code at least conform to the Fortran 
> standard and removing the overuse of "daten", the error
> still occurs.
> 
> subroutine tstd
>implicit none
>integer n
>type a
>   real(8) b
>end type a
>type(a) :: daten(10)
>integer ::  j = 1
>daten(:)%b = 42
>n = daten(j)%b
> end subroutine tstd
> 
> The -fdump-tree-original output is 
> 
> tstd ()
> {
>   struct a daten[10];
>   static integer(kind=4) j = 1;
>   integer(kind=4) n;
> 
>   {
> integer(kind=4) S.0;
> 
> S.0 = 1;
> while (1)
>   {
> if (S.0 > 10) goto L.1;
> daten[S.0 + -1].b = 4.2e+1;
> S.0 = S.0 + 1;
>   }
> L.1:;
>   }
>   n = (integer(kind=4)) daten[NON_LVALUE_EXPR  + -1].b;
> }
> 
> which looks like what I expect.  It seems that -fsanitize=float-cast-overflow
> option has a false positive.
> 

Here's the backtrace.

Program received signal SIGSEGV, Segmentation fault.
0x08a9852b in build_call_expr_loc_array(unsigned int, tree_node*, int,
tree_nod**) ()
(gdb) bt
#0  0x08a9852b in build_call_expr_loc_array(unsigned int, tree_node*, int,
treenode**) ()
#1  0x08a986d0 in build_call_expr_loc(unsigned int, tree_node*, int, ...) ()
#2  0x08808f7a in ubsan_instrument_float_cast (loc=, 
type=, expr=, arg=)
at /mnt/kargl/gcc/gcc/ubsan.c:1609
#3  0x083df160 in convert_to_integer_1 (type=0x296533c0, expr=0x2a10d654, 
dofold=) at /mnt/kargl/gcc/gcc/convert.c:923
#4  0x083de656 in convert_to_integer (type=0x296533c0, expr=0x2a114214)
at /mnt/kargl/gcc/gcc/convert.c:968
#5  0x08293b1f in convert (type=, expr=0x2a114214)
at /mnt/kargl/gcc/gcc/fortran/convert.c:101
#6  0x08309ce8 in gfc_conv_intrinsic_conversion (se=0xbfbfe318, 
expr=) at /mnt/kargl/gcc/gcc/fortran/trans-intrinsic.c:336
#7  0x082ff1cb in gfc_conv_intrinsic_function (se=0xbfbfe318, expr=0x29e13690)
at /mnt/kargl/gcc/gcc/fortran/trans-intrinsic.c:7877
#8  0x082fad05 in gfc_conv_function_expr (se=0xbfbfe318, expr=0x29e13690)
at /mnt/kargl/gcc/gcc/fortran/trans-expr.c:6527
#9  0x082e2a4f in gfc_conv_expr (se=0xbfbfe318, expr=0x29e13690)
at /mnt/kargl/gcc/gcc/fortran/trans-expr.c:7522
#10 0x082eac96 in gfc_trans_assignment_1 (expr1=0x29e13620, 
expr2=, init_flag=, dealloc=)
at /mnt/kargl/gcc/gcc/fortran/trans-expr.c:9249
#11 gfc_trans_assignment (expr1=0x29e13620, expr2=0x29e13690, init_flag=false, 
dealloc=) at /mnt/kargl/gcc/gcc/fortran/trans-expr.c:9485
#12 0x082fb64b in gfc_trans_assign (code=0x29e13770)
at /mnt/kargl/gcc/gcc/fortran/trans-expr.c:9497
#13 0x082af9b2 in trans_code (code=, cond=0x0)
at /mnt/kargl/gcc/gcc/fortran/trans.c:1660
#14 0x082dd58c in gfc_generate_function_code (ns=)
at /mnt/kargl/gcc/gcc/fortran/trans-decl.c:6083
#15 0x0824737f in translate_all_program_units (
gfc_global_ns_list=)
at /mnt/kargl/gcc/gcc/fortran/parse.c:5612
#16 gfc_parse_file () at /mnt/kargl/gcc/gcc/fortran/parse.c:5818
#17 0x082974b8 in gfc_be_parse_file ()
at /mnt/kargl/gcc/gcc/fortran/f95-lang.c:201
#18 0x087e4e38 in compile_file () at /mnt/kargl/gcc/gcc/toplev.c:464
#19 0x087e4a9d in do_compile () at /mnt/kargl/gcc/gcc/toplev.c:1977
#20 toplev::main (this=, argc=, 
argv=) at /mnt/kargl/gcc/gcc/toplev.c:2084
#21 0x08fcd3ee in main (argc=, argv=)
at /mnt/kargl/gcc/gcc/main.c:39

Note, using an explicit Fortran conversion function, avoids the ICE.

subroutine tstd
   implicit none
   integer n
   type a
  real(8) b
   end type a
   type(a) :: daten(10)
   integer ::  j = 1
   daten(:)%b = 42
   n = int(daten(j)%b)
end subroutine tstd

Note, the -ftree-dump-original is identical to the above dump!
Looks like -fsanitize=float-cast-overflow does not understand
Fortran mix-mode math semantics.

[Bug c++/69059] New: [C++14] Invalid rejection of expression as not-a-constant-expression

[ldionne.2 at gmail dot com]

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

Bug ID: 69059
   Summary: [C++14] Invalid rejection of expression as
not-a-constant-expression
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

The following code does not compile with GCC trunk (g++ 6.0.0 20151226
experimental):

template 
struct holder { T value; };

template 
constexpr holder make_holder_impl(T&& t) {
return {static_cast(t)};
}

template 
constexpr auto make_holder(T&& t) {
return make_holder_impl(static_cast(t));
}


constexpr int my_strlen(char const* s) {
int n = 0;
while (*s++ != '\0')
++n;
return n;
}

constexpr int len = my_strlen(make_holder("name").value);


The error is 

[snip]/bin/g++ -pedantic -std=c++1y -W -Wall -Wextra -c ../test/worksheet.cpp
../test/worksheet.cpp:1221:30:   in constexpr expansion of 
  ‘my_strlen(make_holder("name").holder::value)’
../test/worksheet.cpp:1216:12: error: ‘t’ is not a constant expression
 while (*s++ != '\0')
^~~~


Live example: http://melpon.org/wandbox/permlink/77rNCLjwmz1P1xG2

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[slyfox at inbox dot ru]

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

--- Comment #33 from Sergei Trofimovich  ---
Sent glibc workaround for review as:
https://sourceware.org/ml/libc-alpha/2015-12/msg00556.html

[Bug c++/69060] New: Invalid 'cannot bind lvalue to rvalue' error

[ldionne.2 at gmail dot com]

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

Bug ID: 69060
   Summary: Invalid 'cannot bind lvalue to rvalue' error
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

The following code does not compile on GCC trunk (g++ 6.0.0 20151226
experimental):

template 
struct hold {
T value;
T&& operator()() && {
return static_cast(value);
}
};

bool result = hold{true}();


The error is 

[snip]/bin/g++ -pedantic -std=c++1y -W -Wall -Wextra -c ../test/worksheet.cpp
../test/worksheet.cpp: In instantiation of ‘T&& hold::operator()() && [with
T = bool&&]’:
../test/worksheet.cpp:1209:34:   required from here
../test/worksheet.cpp:1205:38: error: cannot bind ‘bool’ lvalue to ‘bool&&’
 return static_cast(value);
  ^


Live example: http://melpon.org/wandbox/permlink/m9qGlrfGJLm218uh

[Bug fortran/69061] New: gfortran not using appropriate memory space for ( architecture x86_64 Darwin )

[testuser021845 at gmail dot com]

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

Bug ID: 69061
   Summary: gfortran not using appropriate memory space for (
architecture x86_64 Darwin )
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: testuser021845 at gmail dot com
  Target Milestone: ---

Created attachment 37137
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37137&action=edit
This is a fortran program that can produce the bug.

Dear All:

I am not a computer scientist.  I apologize for any limitation in my
understanding during this bug report.  I appreciate gcc and gfortran
developers.  Thank you for years of providing me with compilers and other
tools.  I am a physical scientist.  My code is not compiling. I am using a
MacBookPro with Mavericks.  The uname response is:

Darwin mbp.home 13.4.0 Darwin Kernel Version 13.4.0: Wed Mar 18 16:20:14 PDT
2015; root:xnu-2422.115.14~1/RELEASE_X86_64 x86_64

Here is the invocation and the result:

gfortran TEST_CASE.F03 -o test.x
final section layout:
__TEXT/__text addr=0x114D2, size=0x190E, fileOffset=0x14D2,
type=1
__TEXT/__stubs addr=0x12DE0, size=0x003C, fileOffset=0x2DE0,
type=28
__TEXT/__stub_helper addr=0x12E1C, size=0x0074,
fileOffset=0x2E1C, type=32
__TEXT/__cstring addr=0x12E90, size=0x000E, fileOffset=0x2E90,
type=13
__TEXT/__const addr=0x12EA0, size=0x00C8, fileOffset=0x2EA0,
type=0
__TEXT/__eh_frame addr=0x12F68, size=0x0090, fileOffset=0x2F68,
type=19
__DATA/__nl_symbol_ptr addr=0x13000, size=0x0010,
fileOffset=0x3000, type=29
__DATA/__la_symbol_ptr addr=0x13010, size=0x0050,
fileOffset=0x3010, type=27
__DATA/__data addr=0x13060, size=0x0008, fileOffset=0x3060,
type=0
__DATA/__bss5 addr=0x13068, size=0x, fileOffset=0x,
type=25
__DATA/__huge addr=0x13080, size=0x1D5547000, fileOffset=0x,
type=25
ld: 32-bit RIP relative reference out of range (5624320835 max is +/-4GB): from
_MAIN__ (0x114D2) to _pxz.3401 (0x24F3C8080) in '_MAIN__' from
/var/folders/rl/_4n9h0mj0yz05b_xdsrjq6f0gn/T//cc27pzQo.o for architecture
x86_64
collect2: error: ld returned 1 exit status

The attached program TEST_CASE.F03 can be compiled on a local system.  There is
a parameter currently set as 520 which can be changed.  If this parameter is
set to less than about 350 on my computer, it will compile.  I want to set it
to 800 or so.  This is just a snippet of my code that has been compiling and
running correctly with really old copies of gfortran.  These copies also did
not have the DO CONCURRENTLY.  

The GCC version is 5.3.0.  I compiled it yesterday.  Again, thank you for gnu
compilers and tools.

[Bug target/69061] Huge (~7GB of them) Static arrays are not fully usable on Darwin

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||link-failure
 Target||x86_64-*-darwin
  Component|fortran |target
Summary|gfortran not using  |Huge (~7GB of them) Static
   |appropriate memory space|arrays are not fully usable
   |for ( architecture x86_64   |on Darwin
   |Darwin )|
   Severity|major   |normal

--- Comment #1 from Andrew Pinski  ---
>real, dimension(1:n,1:n,1:n) :: gamma, CR, PXX, PXY, PXZ,  PYX, PYY, PYZ, PZY, 
>PZX, PZZ, SX, SY, SZ


With n being 520, these arrays add up to 7.8GB.  Way more than +/-4GB.

For Linux you would use -mcmodel=large but I don't know if this works on Mac OS
X.  

Maybe you should change it to be dynamically allocated rather than statically
allocated.

[Bug target/69061] Huge (~7GB of them) Static arrays are not fully usable on Darwin

[testuser021845 at gmail dot com]

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

--- Comment #2 from Test User  ---
Created attachment 37138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37138&action=edit
compiler response with mcmodel=large

[Bug c++/69056] GCC failed with variadic template and pointer to member function

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-12-26
 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Patrick Palka  ---
Reduced test case:

template 
void resolver(int (*) (T, Args...));

int funcA(int, float) { return 0; }
int funcA(double) { return 0; }

int
main (void)
{
  resolver (&funcA);
}

[Bug target/69061] Huge (~7GB of them) Static arrays are not fully usable on Darwin

[howarth.at.gcc at gmail dot com]

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

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #3 from Jack Howarth  ---
I can reproduce the linkage error when compiling the test case on both gfortran
5.3.0 and current 6.0svn without optimization flags or -O0. However, if pass
-O1/-O2/-O3/-Os/-Ofast, the linkage error disappears. The resulting executables
appear to run successfully on x86_64-apple-darwin15. Note that you can't resort
to -mcmodel=large as it will produce the linkage error...

$ gfortran-fsf-5 -O3 -mcmodel=large TEST_CASE.F03 -o test.x --save-temps
TEST_CASE.s:35:27: error: invalid variant 'PLTOFF'
movabsq $__gfortran_rand@PLTOFF, %rbp
 ^
TEST_CASE.s:38:19: error: invalid variant 'PLTOFF'
movabsq $_memset@PLTOFF, %rbx
 ^
TEST_CASE.s:146:16: error: invalid variant 'PLTOFF'
movabsq $_exp@PLTOFF, %r14
  ^
TEST_CASE.s:261:30: error: invalid variant 'PLTOFF'
movabsq $__gfortran_st_open@PLTOFF, %rax
^
TEST_CASE.s:319:31: error: invalid variant 'PLTOFF'
movabsq $__gfortran_st_write@PLTOFF, %rdx
 ^
TEST_CASE.s:328:42: error: invalid variant 'PLTOFF'
movabsq $__gfortran_transfer_real_write@PLTOFF, %r9
^
TEST_CASE.s:335:47: error: invalid variant 'PLTOFF'
movabsq $__gfortran_transfer_character_write@PLTOFF, %r10
 ^
TEST_CASE.s:362:36: error: invalid variant 'PLTOFF'
movabsq $__gfortran_st_write_done@PLTOFF, %rdx
  ^
TEST_CASE.s:409:31: error: invalid variant 'PLTOFF'
movabsq $__gfortran_set_args@PLTOFF, %rax
 ^
TEST_CASE.s:417:34: error: invalid variant 'PLTOFF'
movabsq $__gfortran_set_options@PLTOFF, %rax
^
Note that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793#c14 describes the
lack of support for @GOTOFF on darwin so @PLTOFF may be a similar situation.

[Bug tree-optimization/69062] New: invalid PHI argument error with ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

Bug ID: 69062
   Summary: invalid PHI argument error with
ftree-parallelize-loops=2
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37139
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37139&action=edit
ira-color.cc

$ gcc -O2 ira-color.cc -S  -ftree-parallelize-loops=2
ira-color.cc: In function ‘’:
ira-color.cc:69:8: error: invalid PHI argument
  r < conflict_hregno + conflict_nregs; r++)
^

&conflicting_regs
ira-color.cc:69:8: error: location references block not in block tree
&conflicting_regs
prephitmp_39 = PHI <_40(16), &conflicting_regs(7)>
ira-color.cc:69:8: internal compiler error: verify_gimple failed
0x11b7aca verify_gimple_in_cfg(function*, bool)
/home/vries/gcc_versions/devel/src/gcc/tree-cfg.c:5119
0xf9c3d2 execute_function_todo
/home/vries/gcc_versions/devel/src/gcc/passes.c:1958
0xf9b4a5 do_per_function
/home/vries/gcc_versions/devel/src/gcc/passes.c:1645
0xf9c5ae execute_todo
/home/vries/gcc_versions/devel/src/gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/69062] invalid PHI argument error with ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Tentative patch at: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69039#c8

[Bug tree-optimization/69039] [6 regression] segfault with ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
(In reply to vries from comment #7)
> (In reply to vries from comment #6)
> > Created attachment 37132 [details]
> > tentative patch
> 
> The tentative patch fixes the reduced test-case, but we run into another ICE
> with the full test-case:
> ...
> ira-color.c: In function ‘’:
> ira-color.c:110833:8: error: invalid PHI argument
>   r < conflict_hregno + conflict_nregs;
> ^
> 
> &conflicting_regs
> ira-color.c:110833:8: error: location references block not in block tree
> &conflicting_regs
> prephitmp_59 = PHI <_60(22), &conflicting_regs(11)>
> ira-color.c:110833:8: internal compiler error: verify_gimple failed
> 0x11b7aca verify_gimple_in_cfg(function*, bool)
>   src/gcc/tree-cfg.c:5119
> 0xf9c3d2 execute_function_todo
>   src/gcc/passes.c:1958
> 0xf9b4a5 do_per_function
>   src/gcc/passes.c:1645
> 0xf9c5ae execute_todo
>   src/gcc/passes.c:2010
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> ...

Filed as: PR69062 - invalid PHI argument error with ftree-parallelize-loops=2

[Bug fortran/69063] New: Internal compiler error, -Wunused-parameter

[physiker at toast2 dot net]

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

Bug ID: 69063
   Summary: Internal compiler error, -Wunused-parameter
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: physiker at toast2 dot net
  Target Milestone: ---
  Host: x86_64-apple-darwin13.4.0
Target: x86_64-apple-darwin13.4.0
 Build: gcc-5.3.0

Created attachment 37140
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37140&action=edit
Source code

bash-3.2$ LANG=C  gfortran -v -c -Wunused-parameter t.f90
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-apple-darwin13.4.0
Configured with: ../gcc-5.3.0/configure --prefix=/sw --prefix=/sw/lib/gcc5
--mandir=/sw/share/man --infodir=/sw/lib/gcc5/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-mpc=/sw --with-system-zlib
--program-suffix=-fsf-5
Thread model: posix
gcc version 5.3.0 (GCC) 

COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.4' '-v' '-c'
'-Wunused-parameter' '-mtune=core2'
 /sw/lib/gcc5/libexec/gcc/x86_64-apple-darwin13.4.0/5.3.0/f951 t.f90 -fPIC
-quiet -dumpbase t.f90 -mmacosx-version-min=10.9.4 -mtune=core2 -auxbase t
-Wunused-parameter -version -fintrinsic-modules-path
/sw/lib/gcc5/lib/gcc/x86_64-apple-darwin13.4.0/5.3.0/finclude -o
/var/folders/97/4qnhjhtn25s86s9hkz0h37_mgn/T//cc6mEFr6.s
GNU Fortran (GCC) version 5.3.0 (x86_64-apple-darwin13.4.0)
compiled by GNU C version 5.3.0, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3
warning: GMP header version 6.0.0 differs from library version 6.1.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 5.3.0 (x86_64-apple-darwin13.4.0)
compiled by GNU C version 5.3.0, GMP version 6.0.0, MPFR version 3.1.3,
MPC version 1.0.3
warning: GMP header version 6.0.0 differs from library version 6.1.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
'
t.f90:8:0:

   end function f
 ^
in pp_format, at pretty-print.c:614

Internal compiler error: Error reporting routines re-entered.
gfortran: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Compiling t.c with the comand line option -Wunused-parameter causes also an
internal compiler error on linux (gcc 5.2).

[Bug fortran/69064] New: Unhelpful error message when a module variable was not included in the only list

[kottinge at utk dot edu]

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

Bug ID: 69064
   Summary: Unhelpful error message when a module variable was not
included in the only list
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kottinge at utk dot edu
  Target Milestone: ---

Created attachment 37141
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37141&action=edit
preprocessed source file with bug

This is pretty trivial and I figured it out so no hurry, but I thought you guys
might want to fix it.  

Bug:

I forgot to list a variable in the only list 'max_line_len2' used at line 2663
of the attached input file (I did the -save-temps option but the files weren't
*.i* they were just .f90, but they were preprocessed) and it gave me this weird
error instead of just telling me the variable wasn't defined.  I did compile
the compiler from scratch, which I haven't done before so I could have messed
something up there, but the only option I used was something that turned off 32
bit libraries, because it wouldn't compile otherwise.  


Compiler info:

GNU Fortran2008 (GCC) version 5.3.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1


Error message and compile command:

gcc -I/usr/lib/openmpi/include -pthread -I/usr/lib/openmpi/lib -L/usr//lib
-L/usr/lib/openmpi/lib -lmpi_f90 -lmpi_f77 -lmpi -ldl -lhwloc -o lwropt.exe
-ggdb -ffree-line-length-none -fcheck=all -fbacktrace -J src -cpp
src/calc_param_mod.f90 src/input_var_mod.f90 src/soln_struct_mod.f90
src/mpi_mod.f90 src/utility_mod.f90 src/v2m_mod.f90 src/cr_pos_mod.f90
src/plot_var_mod.f90 src/sort_mod.f90 src/read_nestle_in_mod.f90
src/plot_mod.f90 src/find_loc_mod.f90 src/soln_pack_unpack_mod.f90
src/soln_mpi_xfer_mod.f90 src/read_nestle_out_mod.f90 src/new_type_line_mod.f90
src/sample_mod.f90 src/write_nestle_in_mod.f90 src/of_mod.f90
src/crp_gen_mod.f90 src/read_input_mod.f90 src/archive_mod.f90
src/evaluate_solution_mod.f90 src/accept1.f90 src/lwr_opt_driver.f90
src/lwr_opt.f90 src/fuel_cost.f90 src/initialize_lp.f90 src/manual_shuffle.f90
src/num_fresh_change.f90 src/psa.f90 src/random_num_init.f90 src/read_soln.f90
src/restart_read.f90 src/restart_write.f90 src/soln_allocate.f90
src/soln_deallocate.f90 src/soln_sample.f90 src/soln_store.f90
src/soln_write.f90 src/soln_unique.f90 src/write_crp_stat.f90
src/write_output.f90 src/write_soln.f90 
src/read_input_mod.f90:7:0:

 SUBROUTINE READ_INPUT(s,input,inp_lines)
 1
internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1084
0x73386b gfc_typenode_for_spec(gfc_typespec*)
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/trans-types.c:1084
0x733b7f gfc_sym_type(gfc_symbol*)
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/trans-types.c:2170
0x6e833a gfc_get_symbol_decl(gfc_symbol*)
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/trans-decl.c:1511
0x6eb137 generate_local_decl
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/trans-decl.c:5055
0x6eb50e expr_decls
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/trans-decl.c:5003
0x6414a9 gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*,
gfc_symbol*, int*), int)
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/expr.c:4161
0x6eb448 generate_expr_decls
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/trans-decl.c:5010
0x6eb448 generate_dependency_declarations
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/trans-decl.c:5025
0x6eb448 generate_local_decl
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/trans-decl.c:5052
0x6b7a5b do_traverse_symtree
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/symbol.c:3646
0x6eb67a generate_local_vars
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/trans-decl.c:5245
0x6eb67a gfc_generate_function_code(gfc_namespace*)
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/trans-decl.c:5781
0x6cf081 gfc_generate_module_code(gfc_namespace*)
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/trans.c:2036
0x6898bd translate_all_program_units
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/parse.c:5330
0x6898bd gfc_parse_file()
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/parse.c:5540
0x6c8f15 gfc_be_parse_file
/home/keith/Downloads/gcc-5.3.0/gcc/fortran/f95-lang.c:229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [all] Error 1

Thanks, 
Keith

[Bug fortran/69064] Unhelpful error message when a module variable was not included in the only list

[kottinge at utk dot edu]

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

--- Comment #1 from kottinge at utk dot edu ---
Instead of gcc in the compile command it should be gfortran.