[Bug tree-optimization/60914] ICE: SIGSEGV (use after free) in bitmap_obstack_alloc_stat() with -flto -fvtable-verify=preinit

[zsojka at seznam dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60914

--- Comment #3 from Zdenek Sojka  ---
(In reply to ctice from comment #2)
> Running your tests, I get a different ICE:
> 
>  gcc-fsf-root/usr/local/bin/gcc -O -flto -fvtable-verify=preinit pr59437.C
> pr59437.C: In function ‘_GLOBAL__sub_I.00099_cout’:
> pr59437.C:24:1: internal compiler error: Segmentation fault
>  }
>  ^
> 0xd6bfc1 crash_signal
>   ../../gcc-fsf.clean/gcc/toplev.c:337
> 0x8a8ea5 bitmap_obstack_free(bitmap_head*)
>   ../../gcc-fsf.clean/gcc/bitmap.c:408
> 0xdb3a83 cleanup_tree_cfg_1
>   ../../gcc-fsf.clean/gcc/tree-cfgcleanup.c:698
> 0xdb3ae8 cleanup_tree_cfg_noloop
>   ../../gcc-fsf.clean/gcc/tree-cfgcleanup.c:731
> 0xdb3bf5 cleanup_tree_cfg()
>   ../../gcc-fsf.clean/gcc/tree-cfgcleanup.c:786
> 0xc7a8dc execute_function_todo
>   ../../gcc-fsf.clean/gcc/passes.c:1741
> 0xc79cd8 do_per_function
>   ../../gcc-fsf.clean/gcc/passes.c:1504
> 0xc7ab37 execute_todo
>   ../../gcc-fsf.clean/gcc/passes.c:1817
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> 
> 
> I will investigate this, but I am concerned that I cannot seem to reproduce
> your problem?

I see the error only when run under valgrind:
$  g++ /mnt/svn/gcc-trunk/gcc/testsuite/g++.dg/ubsan/pr59437.C
-fvtable-verify=std -flto -c -wrapper valgrind,-q
==13523== Invalid write of size 8
==13523==at 0x8B9421: bitmap_obstack_alloc_stat(bitmap_obstack*)
(bitmap.h:277)
==13523==by 0xD5B512: (anonymous
namespace)::pass_build_ssa::execute(function*) (tree-into-ssa.c:2234)
==13523==by 0xBFDAD1: execute_one_pass(opt_pass*) (passes.c:2163)
==13523==by 0xBFDDC5: execute_pass_list(opt_pass*) (passes.c:2216)
==13523==by 0x93B4FE: cgraph_process_new_functions() [clone .part.42]
(cgraphunit.c:338)
==13523==by 0x845696: vtv_generate_init_routine()
(vtable-class-hierarchy.c:1191)
==13523==by 0x721F8D: cp_write_global_declarations() (decl2.c:4628)
==13523==by 0xCF18CC: compile_file() (toplev.c:562)
==13523==by 0xCF389F: toplev_main(int, char**) (toplev.c:1914)
==13523==by 0x5A46BF4: (below main) (in /lib64/libc-2.17.so)
==13523==  Address 0x686ebb0 is 96 bytes inside a block of size 4,064 free'd
==13523==at 0x4C2B57C: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==13523==by 0x5AA8144: obstack_free (in /lib64/libc-2.17.so)
==13523==by 0x93AC12: analyze_function(cgraph_node*) (cgraphunit.c:665)
==13523==by 0x93B4BF: cgraph_process_new_functions() [clone .part.42]
(cgraphunit.c:334)
==13523==by 0x845696: vtv_generate_init_routine()
(vtable-class-hierarchy.c:1191)
==13523==by 0x721F8D: cp_write_global_declarations() (decl2.c:4628)
==13523==by 0xCF18CC: compile_file() (toplev.c:562)
==13523==by 0xCF389F: toplev_main(int, char**) (toplev.c:1914)
==13523==by 0x5A46BF4: (below main) (in /lib64/libc-2.17.so)
==13523== 
... and 100s of other similar errors.
Due to the nature of the bug, writing to an already free'd memory, the bug may
end in a SIGSEGV, glibc reported memory corruption, any random-looking ICE, or
it may not cause any error at all.

[Bug sanitizer/59758] [4.9/4.10 Regression] bootstrap failure in libsanitizer/asan on sparc-linux-gnu

[doko at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758

--- Comment #7 from Matthias Klose  ---
still fails to build with the proposed patch on sparc-linux-gnu

In file included from
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:20:0:
../../../../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:257:72:
error: size of array 'assertion_failed__70' is negative
 typedef char IMPL_PASTE(assertion_failed_##_, line)[2*(int)(pred)-1]
^
../../../../src/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:251:30:
note: in expansion of macro 'IMPL_COMPILER_ASSERT'
 #define COMPILER_CHECK(pred) IMPL_COMPILER_ASSERT(pred, __LINE__)
  ^
../../../../src/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:70:1:
note: in expansion of macro 'COMPILER_CHECK'
 COMPILER_CHECK(struct_kernel_stat_sz == sizeof(struct stat));
 ^
make[6]: *** [sanitizer_platform_limits_linux.lo] Error 1

[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

Jerry DeLisle  changed:

   What|Removed |Added

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #9 from Jerry DeLisle  ---
Fixed on trunk. Closing

--- Comment #10 from Andreas Schwab  ---
Not fixed.

Breakpoint 1, MAIN__ ()
at ../../../../gcc/gcc/testsuite/gfortran.dg/namelist_utf8.f90:21
21  if (str2 /= str) call abort
(gdb) p str2
$1 = 4_'\x6100你好b  '

Obviously not endian safe.

[Bug fortran/56744] [meta-bug] Namelist bugs

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744
Bug 56744 depends on bug 52539, which changed state.

Bug 52539 Summary: I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist 
read and nml write
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

   What|Removed |Added

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

[Bug fortran/52251] Nonadvancing I/O and the t edit descriptor

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52251

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-27
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Still present at r209835 (4.10).

[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604

--- Comment #8 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Apr 27 10:48:56 2014
New Revision: 209836

URL: http://gcc.gnu.org/viewcvs?rev=209836&root=gcc&view=rev
Log:
2014-03-27  Thomas Koenig  

PR fortran/59604
PR fortran/58003
* gfortran.h (gfc_convert_mpz_to_signed):  Add prototype.
* arith.c (gfc_int2int):  Convert number to signed if
arithmetic overflow is not checked.
* simplify.c (convert_mpz_to_unsigned): Only trigger assert for
size if range checking is in force.
(convert_mpz_to_signed):  Make non-static, rename to
(gfc_convert_mpz_to_signed).
(simplify_dshift): Use gfc_convert_mpz_to_signed.
(gfc_simplify_ibclr):  Likewise.
(gfc_simplify_ibits):  Likewise.
(gfc_simplify_ibset):  Likewise.
(simplify_shift):  Likewise.
(gfc_simplify_ishiftc):  Likewise.
(gfc_simplify_maskr):  Likewise.
(gfc_simplify_maskl):  Likewise.

2014-03-27  Thomas Koenig  

PR fortran/59604
PR fortran/58003
* gfortran.dg/no_range_check_3.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/no_range_check_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/arith.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/58003] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:165

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58003

--- Comment #5 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Apr 27 10:48:56 2014
New Revision: 209836

URL: http://gcc.gnu.org/viewcvs?rev=209836&root=gcc&view=rev
Log:
2014-03-27  Thomas Koenig  

PR fortran/59604
PR fortran/58003
* gfortran.h (gfc_convert_mpz_to_signed):  Add prototype.
* arith.c (gfc_int2int):  Convert number to signed if
arithmetic overflow is not checked.
* simplify.c (convert_mpz_to_unsigned): Only trigger assert for
size if range checking is in force.
(convert_mpz_to_signed):  Make non-static, rename to
(gfc_convert_mpz_to_signed).
(simplify_dshift): Use gfc_convert_mpz_to_signed.
(gfc_simplify_ibclr):  Likewise.
(gfc_simplify_ibits):  Likewise.
(gfc_simplify_ibset):  Likewise.
(simplify_shift):  Likewise.
(gfc_simplify_ishiftc):  Likewise.
(gfc_simplify_maskr):  Likewise.
(gfc_simplify_maskl):  Likewise.

2014-03-27  Thomas Koenig  

PR fortran/59604
PR fortran/58003
* gfortran.dg/no_range_check_3.f90:  New test.


Added:
trunk/gcc/testsuite/gfortran.dg/no_range_check_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/arith.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

--- Comment #11 from Andreas Schwab  ---
Mixing push_char and push_char4 can't be right.

[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

--- Comment #12 from Andreas Schwab  ---
! { dg-do run }
! PR52539 UTF-8 support for namelist read and write

character(len=10, kind=4) :: str, str2
character(len=25, kind=4) :: str3

namelist /nml/ str

str = 4_'1a'//char (int (z'4F60'),4) &
  //char (int (z'597D'), 4)//4_'b'

open(99, encoding='utf-8',form='formatted')
write(99, '(3a)') '&nml str = "', str, '" /'
write(99, '(a)') str
rewind(99)

str = 4_''
str2 = 4_''
read(99,nml=nml)
read(99, *) str2
if (str2 /= str) call abort
rewind(99)

read(99,'(A)') str3
if (str3 /= 4_'&nml str = "' // str // 4_'" /') call abort
read(99,'(A)') str3
if (str3 /= str) call abort

close(99, status='delete')
end

[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

--- Comment #13 from Tobias Burnus  ---
(In reply to Andreas Schwab from comment #12)
> ! { dg-do run }
[...]

Which is essentially the following.

-str = 4_'a'//char (int (z'4F60'),4) &
+str = 4_'1a'//char (int (z'4F60'),4) &

If that's sufficient to make the test case pass with a different endianness, it
is fine with me.

However, I do not understand why it should make a difference.

In general, I do not understand why there is an endian problem. "a" or "1a"
should simply lead to two 4-byte characters. The "int(z'4F60'),4)" should lead
to a single character, which depending on the endianness maps to a different
glyph. All characters should be convertable to UTF-8, which has no endianness
dependence, and convertable back to the original string - which one compares
to.

[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

--- Comment #14 from Andreas Schwab  ---
Run it.

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-27
 Ever confirmed|0   |1

--- Comment #9 from Jonathan Wakely  ---
(In reply to Andrzej Krzemienski from comment #7)
> (It used to be legal in C++03, so you couldn't legally warn about it;

That's not  true, the compiler can (and does) warn about legal code.

I'm confirming this, we will want the warning at some point, and it would allow
us to improve this part of the -Weffc++ warnings:

* Item 11: Define a copy constructor and an assignment operator for classes
with dynamically allocated memory.

(see PR 16166 for more details)

Maybe we could call this warning -Wdeprecated-special-members, and have it
enabled -Weffc++ and in C++11 also by -Wdeprecated

[Bug c++/16166] -Weffc++ finer granularity

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16166

--- Comment #9 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> > # Item 11: Define a copy constructor and an assignment operator for classes 
> > with
> > dynamically allocated memory.
> 
> Replaced by Item 14: "Think carefully about copying behavior in
> resource-managing classes" - the advice is less specific, but more useful. 
> I'm not sure how to turn it into a warning though!

I think this could be replaced by a new warning for PR 58407

[Bug ada/60977] New: Float_IO.Put fails on large floats when 'digits exceeds 15

[georggcc at googlemail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60977

Bug ID: 60977
   Summary: Float_IO.Put fails on large floats when 'digits
exceeds 15
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: georggcc at googlemail dot com

with Ada.Text_IO;  use Ada.Text_IO;
with System;

procedure Float_Segfault is

   type Flt is digits System.Max_Digits;

   package Fio is new Float_IO (Flt);

begin
   Fio.Put (Item => Flt'Last,
Aft => 1,
Exp => 0);
end Float_Segfault;

Assumption:
Put should always print a large floating point number, or raise an exception.

The effects seen, however, on both Mac and on GNU/Linux include neither
a number output nor an exception such as Layout_Error. Rather, the
program hangs, or does other curious things.

Playing with some parameters, for example changing the Flt type,
  type Flt is digits System.Max_Digits - 2;
or dividing the parameter passed for Item by powers of 10 changes little. 

Seemingly this happens in System.Img_Real.Set_Real_Image, according to GDB.

On Mac:
$ uname -r -s -m
Darwin 11.4.2 x86_64
$ gnatmake -gnatVa -gnateF -gnatwa -gnatv float_segfault.adb 
gcc -c -gnatVa -gnateF -gnatwa -gnatv float_segfault.adb

GNAT 4.10.0 20140427 (experimental) [trunk revision 209835]
Copyright 1992-2014, Free Software Foundation, Inc.

Compiling: float_segfault.adb (source file time stamp: 2014-04-27 11:38:41)
 14 lines: No errors
gnatbind -x float_segfault.ali
gnatlink float_segfault.ali
$ ./float_segfault 
^C

(In this example screen, the program hangs.)

On GNU/Linux:

$ uname -r -o -m
2.6.32-5-amd64 x86_64 GNU/Linux
$ ./float_segfault 
Segmentation fault

Compilers used:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Users/bauhaus/mine/libexec/gcc/x86_64-apple-darwin11.4.2/4.10.0/lto-wrapper
Target: x86_64-apple-darwin11.4.2
Configured with: /Users/bauhaus/src/gcc/configure --prefix=/Users/bauhaus/mine
--disable-nls --disable-multilib --disable-libstdcxx-pch CC=gcc
--enable-languages=c,ada,c++,go --no-create --no-recursion
Thread model: posix
gcc version 4.10.0 20140427 (experimental) [trunk revision 209835] (GCC) 

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/bauhaus/opt/GNAT2013/bin/../libexec/gcc/x86_64-pc-linux-gnu/4.7.4/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../src/configure --enable-_cxa_atexit --enable-threads=posix
--enable-checking=release --enable-languages=ada,c,c++
--with-bugurl=URL:mailto:rep...@adacore.com --disable-nls
--without-libiconv-prefix --disable-libmudflap --disable-libstdcxx-pch
--disable-libada --disable-multilib
--with-mpfr=/draa.a/gnatmail/sandbox/gpl-2013/x86_64-linux/mpfr/install
--with-gmp=/draa.a/gnatmail/sandbox/gpl-2013/x86_64-linux/gmp/install
--with-mpc=/draa.a/gnatmail/sandbox/gpl-2013/x86_64-linux/mpc/install
--with-libelf=/draa.a/gnatmail/sandbox/gpl-2013/x86_64-linux/libelf/install
--with-build-time-tools=/draa.a/gnatmail/sandbox/gpl-2013/x86_64-linux/gcc/build/buildtools/bin
--prefix=/usr/gnat --build=x86_64-pc-linux-gnu : (reconfigured)
../src/configure --enable-_cxa_atexit --enable-threads=posix
--enable-checking=release --enable-languages=ada,c,c++
--with-bugurl=URL:mailto:rep...@adacore.com --disable-nls
--without-libiconv-prefix --disable-libmudflap --disable-libstdcxx-pch
--disable-libada --disable-multilib
--with-mpfr=/draa.a/gnatmail/sandbox/gpl-2013/x86_64-linux/mpfr/install
--with-gmp=/draa.a/gnatmail/sandbox/gpl-2013/x86_64-linux/gmp/install
--with-mpc=/draa.a/gnatmail/sandbox/gpl-2013/x86_64-linux/mpc/install
--with-libelf=/draa.a/gnatmail/sandbox/gpl-2013/x86_64-linux/libelf/install
--with-build-time-tools=/draa.a/gnatmail/sandbox/gpl-2013/x86_64-linux/gcc/build/buildtools/bin
--prefix=/usr/gnat --build=x86_64-pc-linux-gnu
Thread model: posix
gcc version 4.7.4 20130416 for GNAT GPL 2013 (20130314) (GCC)

[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

--- Comment #15 from Tobias Burnus  ---
(In reply to Andreas Schwab from comment #14)
> Run it.

First, Jerry, I think you really should also compare the results against the
original string.

Secondly, with the modification, I get for the original string, str and str2
(and 'open(6, encoding="UTF-8")'):
 1a你好b5
 1a你好b5
 愱你好b5

Thus, the namelist read is fine - but the list-directed read is not.

[Bug middle-end/60102] powerpc fp-bit ices at dwf_regno

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102

Sebastian Huber  changed:

   What|Removed |Added

 CC||hjl at gcc dot gnu.org

--- Comment #5 from Sebastian Huber  ---
With different starting points I found another commit that leads to a similar
failure:

561af01c2c9ba4c5df95348d8252896088147e32 is the first bad commit
commit 561af01c2c9ba4c5df95348d8252896088147e32
Author: hjl 
Date:   Wed Nov 27 23:54:26 2013 +

Also handle REG_XXX notes in spill_pseudos

PR rtl-optimization/59311
* dwarf2cfi.c (dwf_regno): Assert reg isn't pseudo register.
* lra-spills.c (spill_pseudos): Handle REG_XXX notes.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205468
138bc75d-0d04-0410-961f-82ee72b054a4

:04 04 518275c5696e814bd8f7970a5914e09f0fa7f5aa
16da683b4720ab0b343b910718ad7969b0713c2d M  gcc

This is the error message in this case:

/home/sh/git-build/b-gcc-git-powerpc-eabispe/./gcc/xgcc
-B/home/sh/git-build/b-gcc-git-powerpc-eabispe/./gcc/ -nostdinc
-B/home/sh/git-build/b-gcc-git-powerpc-eabispe/powerpc-eabispe/newlib/ -isystem
/home/sh/git-build/b-gcc-git-powerpc-eabispe/powerpc-eabispe/newlib/targ-include
-isystem /home/sh/archive/gcc-git/newlib/libc/include
-B/home/sh/install-gcc-git/powerpc-eabispe/bin/
-B/home/sh/install-gcc-git/powerpc-eabispe/lib/ -isystem
/home/sh/install-gcc-git/powerpc-eabispe/include -isystem
/home/sh/install-gcc-git/powerpc-eabispe/sys-include-g -O2 -msoft-float -O2
 -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include   -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc  -I. -I. -I../../.././gcc
-I/home/sh/archive/gcc-git/libgcc -I/home/sh/archive/gcc-git/libgcc/.
-I/home/sh/archive/gcc-git/libgcc/../gcc
-I/home/sh/archive/gcc-git/libgcc/../include  -DHAVE_CC_TLS  -o _divxc3.o -MT
_divxc3.o -MD -MP -MF _divxc3.dep -DL_divxc3 -c
/home/sh/archive/gcc-git/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
0x406285 dwf_regno
/home/sh/archive/gcc-git/gcc/dwarf2cfi.c:909
0x534aa4 vec::truncate(unsigned int)
/home/sh/archive/gcc-git/gcc/vec.h:892
0x534aa4 vec::truncate(unsigned int)
/home/sh/archive/gcc-git/gcc/vec.h:1559
0x534aa4 dwarf2out_flush_queued_reg_saves
/home/sh/archive/gcc-git/gcc/dwarf2cfi.c:996
0x53616f scan_trace
/home/sh/archive/gcc-git/gcc/dwarf2cfi.c:2522
0x536b1e create_cfi_notes
/home/sh/archive/gcc-git/gcc/dwarf2cfi.c:2565
0x536b1e execute_dwarf2_frame
/home/sh/archive/gcc-git/gcc/dwarf2cfi.c:2925
0x536b1e execute
/home/sh/archive/gcc-git/gcc/dwarf2cfi.c:3421
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions

In case I revert this patch on the current 4.9 branch
(5935f964089edccd96efa7f0bda85800dc0ee31d) I am able to build the
powerpc-eabispe target.

[Bug fortran/60922] [4.9/4.10 regression] Memory leak with INTENT(OUT) CLASS argument w/ allocatable CLASS components

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60922

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-04-27
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
On x86_64-apple-darwin* I see the memory leak for all the revisions I have
tested from 4.5 to trunk. For 4.8.2 on x86_64-apple-darwin10 valgrind reports;

 Iteration1
==16277== Conditional jump or move depends on uninitialised value(s)
==16277==at 0x112FF: __d_vect_mod_MOD_d_vect_bld_x (pr60922.f90:118)
==16277==by 0x11A33: MAIN__ (pr60922.f90:155)
==16277==by 0x11A7D: main (pr60922.f90:127)
==16277==  Uninitialised value was created by a stack allocation
==16277==at 0x11115: __d_vect_mod_MOD_d_vect_bld_x (pr60922.f90:111)
==16277== 
==16277== Conditional jump or move depends on uninitialised value(s)
==16277==at 0x11309: __d_vect_mod_MOD_d_vect_bld_x (pr60922.f90:118)
==16277==by 0x11A33: MAIN__ (pr60922.f90:155)
==16277==by 0x11A7D: main (pr60922.f90:127)
==16277==  Uninitialised value was created by a stack allocation
==16277==at 0x11115: __d_vect_mod_MOD_d_vect_bld_x (pr60922.f90:111)
==16277== 
 Iteration2
==16277== 
==16277== HEAP SUMMARY:
==16277== in use at exit: 2,097,288 bytes in 3 blocks
==16277==   total heap usage: 22 allocs, 19 frees, 6,295,373 bytes allocated
==16277== 
==16277== 48 bytes in 1 blocks are still reachable in loss record 1 of 3
==16277==at 0x100014679: malloc (vg_replace_malloc.c:266)
==16277==by 0x1124D: __d_vect_mod_MOD_d_vect_bld_x (pr60922.f90:116)
==16277==by 0x11A33: MAIN__ (pr60922.f90:155)
==16277==by 0x11A7D: main (pr60922.f90:127)
==16277== 
==16277== 2,097,152 bytes in 1 blocks are still reachable in loss record 3 of 3
==16277==at 0x100014679: malloc (vg_replace_malloc.c:266)
==16277==by 0x116FB: __d_vect_mod_MOD_array_bld (pr60922.f90:85)
==16277==by 0x11A0A: MAIN__ (pr60922.f90:145)
==16277==by 0x11A7D: main (pr60922.f90:127)
==16277== 
==16277== LEAK SUMMARY:
==16277==definitely lost: 0 bytes in 0 blocks
==16277==indirectly lost: 0 bytes in 0 blocks
==16277==  possibly lost: 0 bytes in 0 blocks
==16277==still reachable: 2,097,200 bytes in 2 blocks
==16277== suppressed: 88 bytes in 1 blocks
==16277== 
==16277== For counts of detected and suppressed errors, rerun with: -v
==16277== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 0 from 0)

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936

--- Comment #3 from Dominique d'Humieres  ---
> Fixed if one adds the code below (copied from gfc_conv_array_parameter).
> I'm afraid this could change a memory leak into a double free (see PR 40850).
> Also, not quite right (even if the middle-end optimizers are likely to fix 
> it) 
> because it adds cleanup code to both foo and bar.

With the patch in comment 2, the tests gfortran.dg/alloc_comp_basics_1.f90 and
gfortran.dg/alloc_comp_constructor_1.f90 fail because there are 21 occurrences
of "builtin_free". This is fixed by the following updated patch (against
r209838)

--- ../_clean/gcc/fortran/trans-expr.c2014-04-25 14:30:23.0 +0200
+++ gcc/fortran/trans-expr.c2014-04-27 16:03:28.0 +0200
@@ -6474,6 +6474,19 @@ gfc_conv_expr_reference (gfc_se * se, gf

   /* Take the address of that value.  */
   se->expr = gfc_build_addr_expr (NULL_TREE, var);
+  if ((expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
+  && expr->ts.u.derived->attr.alloc_comp && expr->rank
+  && expr->expr_type != EXPR_VARIABLE)
+{
+  tree tmp;
+
+  tmp = build_fold_indirect_ref_loc (input_location, se->expr);
+  tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
+  
+  /* The components shall be deallocated before
+ their containing entity.  */
+  gfc_prepend_expr_to_block (&se->post, tmp);
+}
 }

[Bug bootstrap/60830] [4.9 Regression] ICE on bootstrapping on cygwin

[mikpelinux at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60830

--- Comment #46 from Mikael Pettersson  ---
Using a binutils with the proposed patch for binutils' PR 16858 I can now
bootstrap gcc-4.8.2 with --disable-sjlj-exceptions on Cygwin.

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936

--- Comment #4 from Tobias Burnus  ---
(In reply to Dominique d'Humieres from comment #3)
> +  if ((expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
> +  && expr->ts.u.derived->attr.alloc_comp && expr->rank
> +  && expr->expr_type != EXPR_VARIABLE)
> +{
> +  tmp = build_fold_indirect_ref_loc (input_location, se->expr);
> +  tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);

Calling gfc_deallocate_alloc_comp for BT_CLASS looks wrong. You have to call
the finalization wrapper - to ensure that not only the allocatable components
of the declared type but also the ones of the effective/actual type are
deallocated. Additionally, that ensure that user's finalizer is called when it
exists.

(For BT_DERIVED, you may also have to call the finalization wrapper - but only
if the type has finalizers.)

[Bug fortran/41936] Memory leakage with allocatables and user-defined operators

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936

--- Comment #5 from Dominique d'Humieres  ---
> Calling gfc_deallocate_alloc_comp for BT_CLASS looks wrong. ...

I have only added " && expr->rank" to the three year old Mikael's patch.

> You have to call the finalization wrapper - to ensure that not only the 
> allocatable components of the declared type but also the ones of the
> effective/actual type are deallocated. Additionally, that ensure that
> user's finalizer is called when it exists.
>
> (For BT_DERIVED, you may also have to call the finalization wrapper - but only
> if the type has finalizers.)

Could you please provide a more explicit pointer?

[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

--- Comment #16 from Jerry DeLisle  ---
I have to get my head around this. A user should not have to artificially
construct a string to accommodate endianess.  Also, I think I see the buffer
overflow issue Andreas spotted. I appreciate the comments.

[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

--- Comment #17 from Tobias Burnus  ---
(In reply to Jerry DeLisle from comment #16)
> A user should not have to artificially construct a string to accommodate
> endianess.

In principle, the user doesn't have to do so. UTF-8 itself is agnostic to the
endianness of the system.

The endian issue only comes up in the source code. To solve this, we have to
handle UTF-8 when reading the source code. libcpp, which we use for the input,
handles multiple encodings. We should use find out how to use this - and use it
for 4_'strings'.

[Bug libstdc++/60497] unique_ptr tries to complete its type T even though it's not required to be a complete type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60497

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Sun Apr 27 16:32:55 2014
New Revision: 209839

URL: http://gcc.gnu.org/viewcvs?rev=209839&root=gcc&view=rev
Log:
PR libstdc++/60497
* include/std/tuple (get): Qualify calls to prevent ADL.
* testsuite/20_util/tuple/60497.cc: New.

Added:
branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/tuple/60497.cc
Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/std/tuple

[Bug libstdc++/60710] experimental::optional is using T::operator!=

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60710

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Sun Apr 27 16:33:06 2014
New Revision: 209841

URL: http://gcc.gnu.org/viewcvs?rev=209841&root=gcc&view=rev
Log:
2014-04-27  Lars Gullik Bjønnes  

PR libstdc++/60710
* include/experimental/optional (operator!=): Implement in terms of
operator==.
* testsuite/experimental/optional/relops/1.cc: Remove operator!=.
* testsuite/experimental/optional/relops/2.cc: Likewise.
* testsuite/experimental/optional/relops/3.cc: Likewise.
* testsuite/experimental/optional/relops/4.cc: Likewise.
* testsuite/experimental/optional/relops/5.cc: Likewise.
* testsuite/experimental/optional/relops/6.cc: Likewise.

Modified:
branches/gcc-4_9-branch/libstdc++-v3/ChangeLog
branches/gcc-4_9-branch/libstdc++-v3/include/experimental/optional
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/optional/relops/1.cc
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/optional/relops/2.cc
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/optional/relops/3.cc
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/optional/relops/4.cc
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/optional/relops/5.cc
   
branches/gcc-4_9-branch/libstdc++-v3/testsuite/experimental/optional/relops/6.cc

[Bug libstdc++/60710] experimental::optional is using T::operator!=

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60710

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
fixed on trunk and 4.9 branch

[Bug libstdc++/60497] unique_ptr tries to complete its type T even though it's not required to be a complete type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60497

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Sun Apr 27 16:36:26 2014
New Revision: 209842

URL: http://gcc.gnu.org/viewcvs?rev=209842&root=gcc&view=rev
Log:
PR libstdc++/60497
* include/std/tuple (get): Qualify calls to prevent ADL.
* testsuite/20_util/tuple/60497.cc: New.

Added:
branches/gcc-4_8-branch/libstdc++-v3/testsuite/20_util/tuple/60497.cc
Modified:
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/include/std/tuple

[Bug libstdc++/60497] unique_ptr tries to complete its type T even though it's not required to be a complete type

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60497

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.3

--- Comment #6 from Jonathan Wakely  ---
Fixed for 4.8.3, 4.9.1 and trunk.

[Bug fortran/59604] Constant comparisons with -fno-range-check and int(z'...')

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #9 from Thomas Koenig  ---
Fixed on trunk, closing.  I don't think this
is bad enough for a backport.

[Bug fortran/58003] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:165

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58003
Bug 58003 depends on bug 59604, which changed state.

Bug 59604 Summary: Constant comparisons with -fno-range-check and int(z'...')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59604

   What|Removed |Added

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

[Bug fortran/58003] internal compiler error: in convert_mpz_to_unsigned, at fortran/simplify.c:165

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58003

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Fixed on trunk, closing.  Not a regression,
therefore no backport.  (A workaround would
be to use TRANSFER).

[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

--- Comment #18 from Jerry DeLisle  ---
(In reply to Tobias Burnus from comment #15)
> (In reply to Andreas Schwab from comment #14)
> > Run it.
> 
> First, Jerry, I think you really should also compare the results against the
> original string.
> 
> Secondly, with the modification, I get for the original string, str and str2
> (and 'open(6, encoding="UTF-8")'):
>  1a你好b5
>  1a你好b5
>  愱你好b5
> 
> Thus, the namelist read is fine - but the list-directed read is not.

Here on x86_64 I am testing against the original string.
Breakpoint 1, MAIN__ () at test.f90:21
21if (str2 /= str) call abort
(gdb) p str
$1 = 4_'a你好b  '
(gdb) p str2
$2 = 4_'a你好b  '
(gdb) n
22rewind(99)
(gdb) n
24read(99,'(A)') str3
(gdb) n
25if (str3 /= 4_'&nml str = "' // str // 4_'" /') call abort
(gdb) p str3
$3 = 4_'&nml str = "a你好b  " /'
(gdb) n
26read(99,*) str3
(gdb) n
27if (str3 /= str) call abort
(gdb) p str3
$4 = 4_'a你好b', ' ' 

At line 26 is the list-directed read and line 27 is the check against the
original string.

The test case is namelist_utf8.f90.  Can someone show me the above results for
other endian.  If its aborting just do s/call abort/print *, "Fails"/

Thanks in advance.

[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

--- Comment #19 from Andreas Schwab  ---
Use the test case from #c12.

[Bug c++/58407] [C++11] Should warn about deprecated implicit generation of copy constructor/assignment

[akrzemi1 at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58407

--- Comment #10 from Andrzej Krzemienski  ---
I guess, by now "item 11" should read "either delete or define ..."

[Bug c++/60978] New: [4.9 Regression] -Wenum-compare warns too eagerly

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978

Bug ID: 60978
   Summary: [4.9 Regression] -Wenum-compare warns too eagerly
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Test case:

enum { A };
enum { B };

int foo(int x)
{
  return x ? A : B;
}

gcc -c -Wall t.c
# no warnings

g++ -c t.c
t.c: In function ‘int foo(int)’:
t.c:6:12: warning: enumeral mismatch in conditional expression: ‘’ vs ‘’ [-Wenum-compare]
   return x ? A : B;
^

First, there is nothing to warn about here (in real code, I return IPPROTO_ICMP
or IPPROTO_ICMPV66 depending on address family).

Second, why is this pointing to the comparison and references enum-compare?
There is no comparison of unrelated enums here.

[Bug c++/60978] [4.9 Regression] -Wenum-compare warns too eagerly

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978

--- Comment #1 from Andrew Pinski  ---
This is documented to do this even in 4.8
(http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Warning-Options.html):
 In C++ enumeral mismatches in conditional expressions are also diagnosed and
the warning is enabled by default.

[Bug c++/60978] [4.9 Regression] -Wenum-compare warns too eagerly

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978

--- Comment #2 from Paul Pluzhnikov  ---
(In reply to Andrew Pinski from comment #1)
> This is documented to do this even in 4.8
> (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Warning-Options.html):
>  In C++ enumeral mismatches in conditional expressions are also diagnosed
> and the warning is enabled by default.

It also says "In C this warning is enabled by -Wall", but in fact "gcc -Wall"
does NOT warn.

In any case, warning when two *anonymous* enums are used like they are here to
return an integer seems of no value whatsoever.

[Bug c++/60978] [4.9 Regression] -Wenum-compare warns too eagerly

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
I don't even understand what this code is trying to warn about:

  if (TREE_CODE (arg2_type) == ENUMERAL_TYPE
  && TREE_CODE (arg3_type) == ENUMERAL_TYPE)
{
  if (TREE_CODE (orig_arg2) == CONST_DECL
  && TREE_CODE (orig_arg3) == CONST_DECL
  && DECL_CONTEXT (orig_arg2) == DECL_CONTEXT (orig_arg3))
/* Two enumerators from the same enumeration can have different
   types when the enumeration is still being defined.  */;
  else if (complain & tf_warning)
warning_at (loc, OPT_Wenum_compare, "enumeral mismatch in "
"conditional expression: %qT vs %qT",
arg2_type, arg3_type);
}

What is the DECL_CONTEXT check doing there?

[Bug c++/60978] [4.9 Regression] -Wenum-compare warns too eagerly

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Manuel López-Ibáñez from comment #3)
> I don't even understand what this code is trying to warn about:
> 
>   if (TREE_CODE (arg2_type) == ENUMERAL_TYPE
> && TREE_CODE (arg3_type) == ENUMERAL_TYPE)
> {
> if (TREE_CODE (orig_arg2) == CONST_DECL
> && TREE_CODE (orig_arg3) == CONST_DECL
> && DECL_CONTEXT (orig_arg2) == DECL_CONTEXT (orig_arg3))
>   /* Two enumerators from the same enumeration can have different
>  types when the enumeration is still being defined.  */;
>   else if (complain & tf_warning)
> warning_at (loc, OPT_Wenum_compare, "enumeral mismatch in "
>   "conditional expression: %qT vs %qT",
>   arg2_type, arg3_type);
> }
> 
> What is the DECL_CONTEXT check doing there?

No I remember it is because of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524#c19

[Bug c++/60978] [4.9 Regression] -Wenum-compare warns too eagerly

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978

--- Comment #5 from Manuel López-Ibáñez  ---
I think it should not warn for anonymous enums. The point of the warning is
that using different enum types in a conditional expression is often some
programming mistake. But in the case of anonymous enums, they are probably just
used as named constants, so there is no much point in warning.

The reason it does not warn in C is that this particular warning message is not
implemented in C. Perhaps it should be.

The manual is a bit confusing. It would read better as:

Warn about a comparison between values of different enumerated types. In C this
warning is enabled by -Wall.  In C++ the warning is enabled by default and it
warns also about enumeral mismatches in conditional expressions.

[Bug tree-optimization/60979] New: [4.9/4.10 Regression] ICE: in gimple_redirect_edge_and_branch_force, at tree-cfg.c:5544, w/ -O -ftree-loop-linear or fgraphite-identity

[asolokha at gmx dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60979

Bug ID: 60979
   Summary: [4.9/4.10 Regression] ICE: in
gimple_redirect_edge_and_branch_force, at
tree-cfg.c:5544, w/ -O -ftree-loop-linear or
fgraphite-identity
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com

gcc 4.9.0 and newer fails when compiling the following reduced testcase w/ -O1
and above and either -ftree-loop-linear or -fgraphite-identity:

typedef long int __jmp_buf[8];

typedef struct
{
  unsigned long int __val[(1024 / (8 * sizeof(unsigned long int)))];
} __sigset_t;

struct __jmp_buf_tag
{
  __jmp_buf __jmpbuf;
  int __mask_was_saved;
  __sigset_t __saved_mask;
};

typedef struct __jmp_buf_tag jmp_buf[1];

extern int _setjmp(struct __jmp_buf_tag __env[1]);

struct x;

typedef struct x **(*a)(struct x *);

struct x {
  union {
struct {
  union {
a *i;
  } l;
  int s;
} y;
  } e;
};

jmp_buf c;

void
b(struct x *r)
{
  int f;
  static int w = 0;
  volatile jmp_buf m;
  f = (*(((struct x *)r)->e.y.l.i[2]((struct x *)r)))->e.y.s;
  if (w++ != 0)
memcpy((char *)m, (const char *)c, sizeof(jmp_buf));
  if (_setjmp(c) == 0) {
int z;
for (z = 0; z < 0; ++z)
  ;
  }
  d((const char *)m);
}

nl8dmqci.c:37:1: internal compiler error: in
gimple_redirect_edge_and_branch_force, at tree-cfg.c:5544
 b(struct x *r)
 ^

[Bug c++/60980] New: [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980

Bug ID: 60980
   Summary: [4.9/4.10 Regression] ICE in
build_special_member_call, at cp/call.c:7447
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Test case:

struct x0
{
x0 () = default;
};
struct x1
{
x0 x2[];
void x3 ()
{
x1 ();
}
};

Using trunk @r209848 (2014-04-27 17:18:40 -0700 (Sun, 27 Apr 2014)):

g++ -c -std=c++11 -c t.ii
t.ii: In member function ‘void x1::x3()’:
t.ii:10:13: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have array_type in build_special_member_call, at
cp/call.c:7447
 x1 ();
 ^
0xd6cad4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9180
0x55d587 tree_check3
../../gcc/tree.h:2761
0x55d587 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/cp/call.c:7447
0x6b5597 build_value_init(tree_node*, int)
../../gcc/cp/init.c:348
0x6b5179 build_value_init_noctor(tree_node*, int)
../../gcc/cp/init.c:419
0x6b560c build_value_init(tree_node*, int)
../../gcc/cp/init.c:367
0x5fd734 build_functional_cast(tree_node*, tree_node*, int)
../../gcc/cp/typeck2.c:1898
0x6656a0 cp_parser_functional_cast
../../gcc/cp/parser.c:23323
0x65ed42 cp_parser_postfix_expression
../../gcc/cp/parser.c:5900
0x662193 cp_parser_unary_expression
../../gcc/cp/parser.c:7188
0x662e7f cp_parser_binary_expression
../../gcc/cp/parser.c:7893
0x663361 cp_parser_assignment_expression
../../gcc/cp/parser.c:8131
0x6658c3 cp_parser_expression
../../gcc/cp/parser.c:8293
0x6660ec cp_parser_expression
../../gcc/cp/parser.c:8332
0x6660ec cp_parser_expression_statement
../../gcc/cp/parser.c:9651
0x65afc8 cp_parser_statement
../../gcc/cp/parser.c:9502
0x65bdf9 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:9774
0x65bf66 cp_parser_compound_statement
../../gcc/cp/parser.c:9728
0x66d14b cp_parser_function_body
../../gcc/cp/parser.c:18755
0x66d14b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:18791
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

[Bug c++/60980] [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447

[ppluzhnikov at google dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980

--- Comment #1 from Paul Pluzhnikov  ---
Google ref: b/14366603

[Bug lto/60981] New: lto-plugin configuration doesn't test for -static-libgcc (OSX gcc -> clang)

[tony.theodore at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981

Bug ID: 60981
   Summary: lto-plugin configuration doesn't test for
-static-libgcc (OSX gcc -> clang)
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tony.theodore at gmail dot com

Created attachment 32690
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32690&action=edit
lto-plugin -static-libgcc configure.ac test

Hi,

When building on OSX, gcc is a symlink to clang and doesn't accept the
-static-libgcc option.

The attached patch basically copies the "have_static_libs" test from the top
level configure.ac:1253 to the lto-plugin/configure.ac (removing the c++ parts)
- it hasn't been tested as I don't have the right version of autoconf, but
copying and modifying the corresponding section from configure works.

Cheers,

Tony

[Bug lto/60981] lto-plugin configuration doesn't test for -static-libgcc (OSX gcc -> clang)

[tony.theodore at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981

--- Comment #1 from Tony Theodore  ---
Created attachment 32691
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32691&action=edit
add -static-libgcc to lto-plugin/configure

This is the modified lto-plugin/configure that has been tested.

[Bug c++/60980] [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-28
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |4.9.1
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Started with r203985.

[Bug pch/60982] New: Very long compilation of precompiled headers

[georgthegreat at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60982

Bug ID: 60982
   Summary: Very long compilation of precompiled headers
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: georgthegreat at gmail dot com

I'm trying to compile gcc-4.8.2 on powerpc64 to run on powerpc32.
The problem is that I don't have sudo privileges on target machine, so
I'm installing everything locally. I've all prerequisites preinstalled
and gcc/g++-4.1.2.

I configure with the following command:
./configure --prefix=/gpfs/data/chernyshov/chroot
--enable-languages=c,c++ --enable-shared
--with-gmp=/gpfs/data/chernyshov/chroot
--with-mpc=/gpfs/data/chernyshov/chroot
--with-mpfr=/gpfs/data/chernyshov/chroot

During compilation (as far, as I understand, this is libstdc++
compilation), the following command hangs (I waited for 560 minutes
for it's completion):

/gpfs/data/chernyshov/contrib/gcc-4.8.2/host-powerpc64-unknown-linux-gnu/gcc/xgcc
-shared-libgcc
-B/gpfs/data/chernyshov/contrib/gcc-4.8.2/host-powerpc64-unknown-linux-gnu/gcc
-nostdinc++
-L/gpfs/data/chernyshov/contrib/gcc-4.8.2/powerpc64-unknown-linux-gnu/libstdc++-v3/src
-L/gpfs/data/chernyshov/contrib/gcc-4.8.2/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/gpfs/data/chernyshov/chroot/powerpc64-unknown-linux-gnu/bin/
-B/gpfs/data/chernyshov/chroot/powerpc64-unknown-linux-gnu/lib/
-isystem /gpfs/data/chernyshov/chroot/powerpc64-unknown-linux-gnu/include
-isystem /gpfs/data/chernyshov/chroot/powerpc64-unknown-linux-gnu/sys-include
   -x c++-header -nostdinc++ -I/gpfs/data/chernyshov/chroot/include
-D_GNU_SOURCE
-I/gpfs/data/chernyshov/contrib/gcc-4.8.2/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/gpfs/data/chernyshov/contrib/gcc-4.8.2/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/gpfs/data/chernyshov/contrib/gcc-4.8.2/libstdc++-v3/libsupc++ -O2
-g -std=gnu++0x
/gpfs/data/chernyshov/contrib/gcc-4.8.2/libstdc++-v3/include/precompiled/stdc++.h
\
-o powerpc64-unknown-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch

[Bug c++/60980] [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980

--- Comment #3 from Andrew Pinski  ---
Note I think this code is invalid due to the struct not having a size.