[Bug preprocessor/59935] [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault

[nheghathivhistha at gmail dot com]

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

--- Comment #3 from David Kredba  ---
Is this having the same cause please?

It is a seamonkey-2.23 configure stage.

configure:24169: checking size of int *
configure:24188: x86_64-pc-linux-gnu-gcc -o conftest -fPIC -ggdb -pipe
-march=native -mtune=native -mno-avx -mno-sse4.2 -mno-3dnow  -mno-avx
-std=gnu99 -fgnu89-inline -fno-strict-aliasing -fno-math-errno -pthread 
-lpthread -Wl,--as-needed -Wl,-O2 -ggdb -pipe -march=native -mtune=native
-mno-avx -mno-sse4.2 -mno-3dnow -fPIC -Wl,-z,noexecstack -Wl,-z,text -B
/var/tmp/portage/www-client/seamonkey-2.23/work/comm-release/seamonk/mozilla/build/unix/gold
conftest.c -ldl  1>&5
configure:24179:1: warning: return type defaults to 'int' [enabled by default]
x86_64-pc-linux-gnu-gcc: internal compiler error: Segmentation fault (program
cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure: failed program was:
#line 24177 "configure"
#include "confdefs.h"
#include 
main()
{
  FILE *f=fopen("conftestval", "w");
  if (!f) exit(1);
  fprintf(f, "%d\n", sizeof(int *));
  exit(0);
}
configure: error: Unexpected pointer size

trunk revision 207070

[Bug target/59691] cilk-plus run failures on non-sse processors

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger  ---
(In reply to Balaji V. Iyer from comment #6)
> Hi Jeff, Andrew and Bernd,
>Can you please try out the "possible fix" and
> see if that works for you?
>
> Thanks,
> 
> Balaji V. Iyer.

Hi the patch works,

but there is still one test case failing:

spawn /home/ed/gnu/gcc-build/gcc/testsuite/g++/../../xg++
-B/home/ed/gnu/gcc-build/gcc/testsuite/g++/../../
/home/ed/gnu/gcc-4.9-trunk/gcc/testsuite/g++.dg/cilk-plus/CK/catch_exc.cc
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/ed/gnu/gcc-build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
-I/home/ed/gnu/gcc-build/i686-pc-linux-gnu/libstdc++-v3/include
-I/home/ed/gnu/gcc-4.9-trunk/libstdc++-v3/libsupc++
-I/home/ed/gnu/gcc-4.9-trunk/libstdc++-v3/include/backward
-I/home/ed/gnu/gcc-4.9-trunk/libstdc++-v3/testsuite/util -fmessage-length=0 -O1
-fcilkplus -fcilkplus -lcilkrts
-L/home/ed/gnu/gcc-build/i686-pc-linux-gnu/./libstdc++-v3/src/.libs
-B/home/ed/gnu/gcc-build/i686-pc-linux-gnu/./libstdc++-v3/src/.libs
-L/home/ed/gnu/gcc-build/i686-pc-linux-gnu/./libstdc++-v3/src/.libs
-L/home/ed/gnu/gcc-build/i686-pc-linux-gnu/./libcilkrts/.libs -lm -o
./catch_exc.exe^M
PASS: g++.dg/cilk-plus/CK/catch_exc.cc  -O1 -fcilkplus (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/ed/gnu/gcc-build/i686-pc-linux-gnu/./libstdc++-v3/src/.libs:/home/ed/gnu/gcc-build/i686-pc-linux-gnu/./libstdc++-v3/src/.libs:/home/ed/gnu/gcc-build/gcc:/home/ed/gnu/gcc-build/i686-pc-linux-gnu/./libcilkrts/.libs:.:/home/ed/gnu/gcc-build/i686-pc-linux-gnu/./libstdc++-v3/src/.libs:/home/ed/gnu/gcc-build/i686-pc-linux-gnu/./libstdc++-v3/src/.libs:/home/ed/gnu/gcc-build/gcc:/home/ed/gnu/gcc-build/i686-pc-linux-gnu/./libcilkrts/.libs:/home/ed/gnu/gcc-build/./gmp/.libs:/home/ed/gnu/gcc-build/./prev-gmp/.libs:/home/ed/gnu/gcc-build/./mpfr/.libs:/home/ed/gnu/gcc-build/./prev-mpfr/.libs:/home/ed/gnu/gcc-build/./mpc/.libs:/home/ed/gnu/gcc-build/./prev-mpc/.libs
spawn [open ...]^M
terminate called after throwing an instance of 'int'
FAIL: g++.dg/cilk-plus/CK/catch_exc.cc  -O1 -fcilkplus execution test

[Bug c/59939] No warning on signedness changes caused by implicit conversion

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  ---
I think Andrew's point is that we might have:

#if T_IS_UNSIGNED
typedef unsigned T;
#else
typedef int T;
#endif

int f(T,T);

and thus the following:

  T_IS_UNSIGNED || f(a,b)

can be used as a short version for:

#if T_IS_UNSIGNED
  1
#else
  f(a,b)
#endif

where the warning is not wanted.

As with many things, it is a matter of taste whether you want to ignore
warnings in obviously dead code.

[Bug preprocessor/59935] [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to David Kredba from comment #3)
> Is this having the same cause please?

Yes. It's caused by the same revision.
Jabub's patch fixes both issues:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01589.html

[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
But it is 50 times inlined.  Anyway, supposedly the aborts would be all merged
then.  Looking at current gcc_assert definition, we actually use there
__builtin_unreachable (), at least when built with gcc 4.5+, and we only do
-Werror and care about warnings when built with recent gcc anyway, so
gcc_assert should be good enough.

[Bug fortran/59941] ICE with polymorphic types in [4.7.0|4.7.1|4.73|4.7.4]

[juergen.reuter at desy dot de]

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

--- Comment #1 from Jürgen Reuter  ---
Created attachment 31951
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31951&action=edit
Code triggering the ICE

[Bug fortran/59941] New: ICE with polymorphic types in [4.7.0|4.7.1|4.73|4.7.4]

[juergen.reuter at desy dot de]

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

Bug ID: 59941
   Summary: ICE with polymorphic types in [4.7.0|4.7.1|4.73|4.7.4]
   Product: gcc
   Version: 4.7.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de

This is the code that triggers the ICE:
$ gfortran -c ICE.f90
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Here is the code (also attached, 147 lines):


module tao_random_numbers
  integer, parameter, private :: tao_i32 = selected_int_kind (9)
  integer, parameter, private :: DEFAULT_BUFFER_SIZE = 1009
  integer(kind=tao_i32), dimension(DEFAULT_BUFFER_SIZE), save, private ::
s_buffer
  integer, save, private :: s_buffer_end = size (s_buffer)
end module tao_random_numbers



module interactions
  public :: interaction_t

  type :: external_link_t
 type(interaction_t), pointer :: int => null ()
  end type external_link_t

  type :: interaction_t
 type(external_link_t), dimension(:), allocatable :: source
  end type interaction_t

end module interactions

!

module polarizations
  public :: smatrix_t
  public :: pmatrix_t

  type :: smatrix_t
 integer :: dim = 0
 integer, dimension(:,:), allocatable :: index
  end type smatrix_t

  type, extends (smatrix_t) :: pmatrix_t
   contains
 procedure :: p_from_s => pmatrix_assign_from_smatrix
  end type pmatrix_t

contains

  subroutine pmatrix_assign_from_smatrix (pmatrix, smatrix)
class(pmatrix_t), intent(out) :: pmatrix
type(smatrix_t), intent(in) :: smatrix
pmatrix%smatrix_t = smatrix
  end subroutine pmatrix_assign_from_smatrix

end module polarizations

!

module beam_structures
  use polarizations
  public :: beam_structure_t

  type :: beam_structure_entry_t
 logical :: is_valid = .false.
  end type beam_structure_entry_t

  type :: beam_structure_record_t
 type(beam_structure_entry_t), dimension(:), allocatable :: entry
  end type beam_structure_record_t

  type :: beam_structure_t
 private
 integer :: n_beam = 0
 type(beam_structure_record_t), dimension(:), allocatable :: record
 type(smatrix_t), dimension(:), allocatable :: smatrix
   contains
 procedure :: get_smatrix => beam_structure_get_smatrix
  end type beam_structure_t

contains

  function beam_structure_get_smatrix (beam_structure) result (smatrix)
class(beam_structure_t), intent(in) :: beam_structure
type(smatrix_t), dimension (size (beam_structure%smatrix)) :: smatrix
smatrix = beam_structure%smatrix
  end function beam_structure_get_smatrix

end module beam_structures



module beams
  use polarizations
  use beam_structures
  public :: beam_data_t
  type :: beam_data_t
 type(pmatrix_t), dimension(:), allocatable :: pmatrix
  end type beam_data_t
end module beams

!

module sf_base
  use interactions
  use beams
  public :: sf_data_t
  public :: sf_int_t

  type, abstract :: sf_data_t
  end type sf_data_t

  type, abstract, extends (interaction_t) :: sf_int_t
   contains
 procedure (sf_int_init), deferred :: init
  end type sf_int_t

  abstract interface
 subroutine sf_int_init (sf_int, data)
   import
   class(sf_int_t), intent(out) :: sf_int
   class(sf_data_t), intent(in), target :: data
 end subroutine sf_int_init
  end interface
end module sf_base

!

module sf_circe1
  use tao_random_numbers !NODEP!
  use sf_base

  type, extends (sf_data_t) :: circe1_data_t 
 private 
   contains  
   procedure :: init => circe1_data_init 
  end type circe1_data_t 

  type, extends (sf_int_t) :: circe1_t
 type(circe1_data_t), pointer :: data => null ()
   contains
 procedure :: init => circe1_init
  end type circe1_t 

contains

  subroutine circe1_data_init (data)
class(circe1_data_t), intent(out) :: data 
  end subroutine circe1_data_init 

  subroutine circe1_init (sf_int, data) 
class(circe1_t), intent(out) :: sf_int 
class(sf_data_t), intent(in), target :: data
  end subroutine circe1_init

end module sf_circe1

[Bug fortran/59941] ICE with polymorphic types in [4.7.0|4.7.1|4.73|4.7.4]

[juergen.reuter at desy dot de]

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

--- Comment #2 from Jürgen Reuter  ---
The bug appears only with 4.7.x, with 4.8 and 4.9 it is working.

[Bug fortran/59941] [OOP] ICE with polymorphic types in 4.7.x

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-25
 CC||janus at gcc dot gnu.org
Summary|ICE with polymorphic types  |[OOP] ICE with polymorphic
   |in [4.7.0|4.7.1|4.73|4.7.4] |types in 4.7.x
 Ever confirmed|0   |1

--- Comment #3 from janus at gcc dot gnu.org ---
Confirmed. Also seems to work with 4.6.4 here.

[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[OOP] ICE with polymorphic  |[4.7 Regression] [OOP] ICE
   |types in 4.7.x  |with polymorphic types

--- Comment #4 from janus at gcc dot gnu.org ---
The current bug list shows three 4.7-only regressions, two of which are
OOP-related:

 * PR 53718
 * PR 56731

At first sight the problem here seems to be different, though.

[Bug c/59717] better warning when using functions without including appropriate header files

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-01-25
 CC||steven at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Steven Bosscher  ---
Can be implemented by adding header names in the builtins.def files.

[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Reduced test case:


module tao_random_numbers
  integer, dimension(10), private :: s_buffer
  integer, private :: s_buffer_end = size (s_buffer)
end module


module beam_structures

  type :: smatrix_t
  end type

  type :: beam_structure_t
 type(smatrix_t), dimension(:), allocatable :: smatrix
   contains
 procedure :: get_smatrix
  end type

contains

  function get_smatrix (beam_structure) result (smatrix)
class(beam_structure_t), intent(in) :: beam_structure
type(smatrix_t), dimension (size (beam_structure%smatrix)) :: smatrix
  end function

end module


module sf_circe1
  use tao_random_numbers
  use beam_structures
end module

[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #6 from janus at gcc dot gnu.org ---
Definitely some kind of module madness is at work here. Somewhat reminds me of
PR 58007.

[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
Another variant with the same behavior (ICEs only with 4.7):


module tao_random_numbers
  integer, dimension(10), private :: s_buffer
  integer, private :: s_buffer_end = size (s_buffer)
end module


module beam_structures

  private

  type :: beam_structure_t
 integer, dimension(:), allocatable :: smatrix
   contains
 procedure :: get_smatrix
  end type

contains

  function get_smatrix (beam_structure) result (matrix)
class(beam_structure_t), intent(in) :: beam_structure
integer, dimension (size (beam_structure%smatrix)) :: matrix
  end function

end module


program p
  use tao_random_numbers
  use beam_structures
end



Everything in the modules is private, so the USE statements should not have any
effect in principle.

Btw, maybe a warning for all-private modules would be appropriate? A module
without any public entities is not very useful, I guess ...

[Bug target/59691] cilk-plus run failures on non-sse processors

[hjl.tools at gmail dot com]

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

--- Comment #8 from H.J. Lu  ---
(In reply to Balaji V. Iyer from comment #5)
> Created attachment 31938 [details]
> Possible Fix.
> 
> Possible fix.

You can replace cpu_supports_sse with __builtin_cpu_supports
since __builtin_cpu_supports("sse") is compiled into:

movl__cpu_model+12(%rip), %eax

by GCC.

[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
Backtrace from gdb:


Program received signal SIGSEGV, Segmentation fault.
0x004d19d6 in replace_comp (expr=expr@entry=0x146cc10,
sym=sym@entry=0x146f7a0, i=i@entry=0x7fffdc6c)
at /home/jweil/gcc47/branch/gcc/fortran/expr.c:4199
4199   && !gfc_is_intrinsic (expr->symtree->n.sym, 0, expr->where)))
(gdb) bt
#0  0x004d19d6 in replace_comp (expr=expr@entry=0x146cc10,
sym=sym@entry=0x146f7a0, i=i@entry=0x7fffdc6c)
at /home/jweil/gcc47/branch/gcc/fortran/expr.c:4199
#1  0x004d46ba in gfc_traverse_expr (expr=0x146cc10,
sym=sym@entry=0x146f7a0, 
func=func@entry=0x4d19a0 , f=f@entry=0) at
/home/jweil/gcc47/branch/gcc/fortran/expr.c:3929
#2  0x004d6c9c in gfc_expr_replace_comp (expr=,
dest=dest@entry=0x146f7a0)
at /home/jweil/gcc47/branch/gcc/fortran/expr.c:4218
#3  0x00524615 in resolve_fl_derived0 (sym=sym@entry=0x146e590)
at /home/jweil/gcc47/branch/gcc/fortran/resolve.c:11724
#4  0x0052c80d in resolve_fl_derived (sym=sym@entry=0x146e590)
at /home/jweil/gcc47/branch/gcc/fortran/resolve.c:12046
#5  0x00522238 in resolve_symbol (sym=0x146e590) at
/home/jweil/gcc47/branch/gcc/fortran/resolve.c:12308
#6  0x00540a84 in do_traverse_symtree (st=0x146ca50,
st_func=st_func@entry=0x0, 
sym_func=sym_func@entry=0x521ac0 ) at
/home/jweil/gcc47/branch/gcc/fortran/symbol.c:3387
#7  0x0054440d in gfc_traverse_ns (ns=ns@entry=0x146bf80,
sym_func=sym_func@entry=0x521ac0 )
at /home/jweil/gcc47/branch/gcc/fortran/symbol.c:3412
#8  0x005209d1 in resolve_types (ns=ns@entry=0x146bf80) at
/home/jweil/gcc47/branch/gcc/fortran/resolve.c:13885
#9  0x005213c1 in gfc_resolve (ns=0x146bf80) at
/home/jweil/gcc47/branch/gcc/fortran/resolve.c:13985
#10 0x0052f7a5 in gfc_resolve (ns=) at
/home/jweil/gcc47/branch/gcc/fortran/resolve.c:13978
#11 0x00516153 in resolve_all_program_units
(gfc_global_ns_list=0x145ab60)
at /home/jweil/gcc47/branch/gcc/fortran/parse.c:4392

[Bug c/59942] New: pdp11-aout-gcc: PDP-11/10 code generation crashes when trying to do multiple shifts.

[mattis at mattisborgen dot se]

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

Bug ID: 59942
   Summary: pdp11-aout-gcc: PDP-11/10 code generation crashes when
trying to do multiple shifts.
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattis at mattisborgen dot se

This bug only occurs for PDP-11/10 not PDP-11/40. I presume that when using
PDP-11/40 the code generation will output a ASHC instruction which is not
present in the PDP-11/10.


mattis@mattis-VirtualBox:~$ pdp11-aout-gcc -m10  -S -msoft-float  -nostartfiles
 -nodefaultlibs  -nostdlib   pdp11-10-shiftbug.c 
pdp11-10-shiftbug.c: In function 'main':
pdp11-10-shiftbug.c:5:1: error: unrecognizable insn:
 }
 ^
(insn 8 7 9 2 (set (reg:HI 23)
(ashift:HI (reg:HI 24)
(const_int -9 [0xfff7]))) pdp11-10-shiftbug.c:4 -1
 (nil))
pdp11-10-shiftbug.c:5:1: internal compiler error: in extract_insn, at
recog.c:2154
0x837d527 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../src/gcc/rtl-error.c:109
0x837d571 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../src/gcc/rtl-error.c:117
0x8355394 extract_insn(rtx_def*)
../src/gcc/recog.c:2154
0x825d34e instantiate_virtual_regs_in_insn
../src/gcc/function.c:1561
0x825d34e instantiate_virtual_regs
../src/gcc/function.c:1928
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
mattis@mattis-VirtualBox:~$ cat pdp11-10-shiftbug.c
main ()
{
  short a=1, b;
  b = a >> 9;
}
mattis@mattis-VirtualBox:~$ pdp11-aout-gcc -v
Using built-in specs.
COLLECT_GCC=pdp11-aout-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/pdp11-aout/4.8.2/lto-wrapper
Target: pdp11-aout
Configured with: src/configure --target=pdp11-aout --disable-nls
--without-headers --enable-languages=c
Thread model: single
gcc version 4.8.2 (GCC) 
mattis@mattis-VirtualBox:~$ 

Linux mattis-VirtualBox 3.8.0-35-generic #50~precise1-Ubuntu SMP Wed Dec 4
17:28:45 UTC 2013 i686 i686 i386 GNU/Linux

[Bug target/59691] cilk-plus run failures on non-sse processors

[bviyer at gmail dot com]

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

--- Comment #9 from Balaji V. Iyer  ---
Hi Bernd and H. J.,
The catch_exc.cc bug is a different issue. It is failing in most 32 bit
machines and we are currently looking into it.

Thanks,

Balaji V. Iyer.

[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Created attachment 31952
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31952&action=edit
gcc49-pr59934.patch

So what about this way?  Then I'd expect for the missing partial/vector int
the compiler could easily find out that it shouldn't do a switch with 4
different cases, but just check class against MODE_INT and otherwise abort, or
for --disable-checking don't check the class at all.

[Bug bootstrap/59943] New: [4.9 Regression] ICE in read_line_num, at input.c:603 while building an x86_64-linux-gnu arm-linux-androideabi crosscompiler

[Bernhard.Rosenkranzer at linaro dot org]

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

Bug ID: 59943
   Summary: [4.9 Regression] ICE in read_line_num, at input.c:603
while building an x86_64-linux-gnu
arm-linux-androideabi crosscompiler
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Bernhard.Rosenkranzer at linaro dot org

This happens with current git when trying to build an x86_64-linux-gnu
arm-linux-androideabi crosscompiler (must have been caused by a very recent
commit, I have a successful build from last week):

make[4]: Entering directory
'/mnt/home2/bero/linaro-builds/toolchain/obj/gcc-bootstrap-gcc-4.9/arm-linux-androideabi/armv7-a/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
/mnt/home2/bero/linaro-builds/toolchain/obj/gcc-bootstrap-gcc-4.9/./gcc/xgcc
-B/mnt/home2/bero/linaro-builds/toolchain/obj/gcc-bootstrap-gcc-4.9/./gcc/
-B/tmp/android-toolchain-eabi/arm-linux-androideabi/bin/
-B/tmp/android-toolchain-eabi/arm-linux-androideabi/lib/ -isystem
/tmp/android-toolchain-eabi/arm-linux-androideabi/include -isystem
/tmp/android-toolchain-eabi/arm-linux-androideabi/sys-include-g -Os
-march=armv7-a -O2  -O2 -Os -g -DTARGET_POSIX_IO -fno-short-enums -isystem
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../android/bionic/libc/include
-isystem
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../android/bionic/libc/kernel/common
-isystem
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../android/bionic/libc/kernel/arch-arm
-isystem
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../android/bionic/libc/arch-arm/include
-isystem
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../android/bionic/libm/include
-isystem
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../android/bionic/libm/include/arm
-isystem
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../android/bionic/libm/arm
-include
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../android/bionic/libc/include/sys/limits.h
-DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fPIC -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc  -fPIC -fno-inline -I. -I. -I../../.././gcc
-I/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../gcc/gcc-4.9/libgcc
-I/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../gcc/gcc-4.9/libgcc/.
-I/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../gcc/gcc-4.9/libgcc/../gcc
-I/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../gcc/gcc-4.9/libgcc/../include
   -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../gcc/gcc-4.9/libgcc/libgcc2.c
 
In file included from ../../.././gcc/tm.h:24:0,
 from
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../gcc/gcc-4.9/libgcc/libgcc2.c:29:
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../gcc/gcc-4.9/libgcc/../gcc/config/gnu-user.h:113:0:
warning: "TARGET_POSIX_IO" redefined [enabled by default]
 #define TARGET_POSIX_IO
 ^
:0:0: note: this is the location of the previous definition
In file included from ../../.././gcc/tm.h:24:0,
 from
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../gcc/gcc-4.9/libgcc/libgcc2.c:29:
/mnt/home2/bero/linaro-builds/toolchain/obj/../build/../gcc/gcc-4.9/libgcc/../gcc/config/gnu-user.h:1:0:
internal compiler error: in read_line_num, at input.c:603
 /* Definitions for systems using, at least optionally, a GNU
 ^
0x4f3290 ???
../sysdeps/x86_64/start.S:122
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:478: recipe for target '_muldi3.o' failed

[Bug bootstrap/59943] [4.9 Regression] ICE in read_line_num, at input.c:603 while building an x86_64-linux-gnu arm-linux-androideabi crosscompiler

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Dup.

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

[Bug preprocessor/59935] [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||Bernhard.Rosenkranzer@linar
   ||o.org

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

[Bug c/59939] No warning on signedness changes caused by implicit conversion

[su at cs dot ucdavis.edu]

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

--- Comment #9 from Zhendong Su  ---
(In reply to Marc Glisse from comment #8)
> I think Andrew's point is that we might have:
> ... 

Thanks for your explanation Marc. I think I see the point now, although the
rational still feels a bit convoluted.  

> As with many things, it is a matter of taste whether you want to ignore
> warnings in obviously dead code.

Yes, I very much agree --- many times it's purely a design decision. 

But please allow me to argue the following point. Since "fn1(a,b)" is obviously
dead code in the originally reported test (because of which the two conversions
weren't warned), the dead code should then be warned, correct?

[Bug preprocessor/59935] [4.9 Regression] Firefox build fails with: : internal compiler error: Segmentation fault

[nheghathivhistha at gmail dot com]

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

--- Comment #6 from David Kredba  ---
The patch works as you said.
Thank you.

[Bug c/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together

[tom.rini at gmail dot com]

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

--- Comment #11 from Tom Rini  ---
(In reply to Andrew Pinski from comment #10)
> I noticed this also when I was helping out an uboot developer here at Cavium
> for Octeon.
> 
> Really I think someone should get LTO working for uboot.

Please note that for the record this is not a U-Boot bug but U-Boot showing a
compiler bug.  And given the nature of the bug, LTO would not help here I
suspect as the strings are merged together.

[Bug c++/59944] New: lambda in templated method body for method with default template value and lambda parameter causes error

[balint at posteo dot de]

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

Bug ID: 59944
   Summary: lambda in templated method body for method with
default template value and lambda parameter causes
error
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: balint at posteo dot de

Created attachment 31953
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31953&action=edit
compressed ii file

Take a class with a templated method, let the template parameter have a default
value and let the method have a std::function as only parameter with a lambda
as default value for the parameter. Now inside this function use another,
independent lambda, e.g. in the context of "remove_if". Then g++ in all tested
versions (4.8.1, 4.8.2, 4.9) throws several errors.

Please see for discussion, code sample and explanation:
http://stackoverflow.com/questions/21353349/c11-g-strangeness-using-defaulted-template-lambda-remove-if

Regarding the details you request for bug reports, here we go:

command line:
g++-4.9 -v -std=c++0x example3.cpp
(NOTE: example3.cpp contains the code shown in the stackoverflow link)

system info:
LinuxMint 16 (petra)
3.8.4 (Ubuntu 2013-12-05)
3.11.0-12-generic (#19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013)

gcc version:
GNU C++ (Ubuntu 20130917-1ubuntu1) version 4.9.0 20130917 (experimental) [trunk
revision 202647] (x86_64-linux-gnu)
compiled by GNU C version 4.9.0 20130917 (experimental) [trunk revision
202647], GMP version 5.1.2, MPFR version 3.1.1-p2, MPC version 1.0.1

gcc config options:
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
20130917-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-snap-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix

ii-file:
see attachment

gcc complete verbose compiler output:
Using built-in specs.
COLLECT_GCC=g++-4.9
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
20130917-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-snap-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.0 20130917 (experimental) [trunk revision 202647] (Ubuntu
20130917-1ubuntu1) 
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.9.0/cc1plus -quiet -v
-imultiarch x86_64-linux-gnu -D_GNU_SOURCE example3.cpp -quiet -dumpbase
example3.cpp -mtune=generic -march=x86-64 -auxbase example3 -std=c++11 -version
-o /tmp/ccYCvqsx.s
GNU C++ (Ubuntu 20130917-1ubuntu1) version 4.9.0 20130917 (experimental) [trunk
revision 202647] (x86_64-linux-gnu)
compiled by GNU C version 4.9.0 20130917 (experimental) [trunk revision
202647], GMP version 5.1.2, MPFR version 3.1.1-p2, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.9.0/../../../../x86_6

[Bug c++/59945] New: "uint" typedef is visible with "g++ -std=c++11 -pedantic"

[Keith.S.Thompson at gmail dot com]

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

Bug ID: 59945
   Summary: "uint" typedef is visible with "g++ -std=c++11
-pedantic"
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Keith.S.Thompson at gmail dot com

If a C++ program includes a standard header (I use  in my example), a
typedef

typedef unsigned int uint;

becomes visible. The identifier does not appear in the 2011 ISO C++ standard.

The problem occurs with "g++ -std=c++11 -pedantic". It does not occur with "g++
-std=c++03 -pedantic".

To demonstrate:

$ cat uint_bug.cpp
#include 
int uint;
int main() { }
$ g++ --version 
g++ (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ g++ -std=c++03 -pedantic -c uint_bug.cpp
$ g++ -std=c++11 -pedantic -c uint_bug.cpp
uint_bug.cpp:2:5: error: ‘int uint’ redeclared as different kind of symbol
In file included from /usr/include/stdlib.h:320:0,
 from /usr/include/c++/4.7/cstdlib:66,
 from /usr/include/c++/4.7/ext/string_conversions.h:37,
 from /usr/include/c++/4.7/bits/basic_string.h:2814,
 from /usr/include/c++/4.7/string:54,
 from uint_bug.cpp:1:
/usr/include/x86_64-linux-gnu/sys/types.h:153:22: error: previous
declaration of ‘typedef unsigned int uint’
$

Running "g++ -std=c++11 -E uint_bug.cpp" shows that the declaration "typedef
int uint;", along with similar declarations for "ushort" and "ulong", appears
in /usr/include/x86_64-linux-gnu/sys/types.h. Apparently the macro __USE_MISC
is defined. (The same macro appears to be defined with "-std=c++03", but the
problem doesn't occur with that option; I haven't figured out why.)

I'm not sure whether the bug is in the compiler or in the libc headers.

(The same problem occurs with clang++ version 3.4.)

[Bug c/59946] New: -mpcrel -O2 produces illegal asm code

[miro.kropacek at gmail dot com]

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

Bug ID: 59946
   Summary: -mpcrel -O2 produces illegal asm code
   Product: gcc
   Version: 4.6.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miro.kropacek at gmail dot com

int copyNextDtaToAtari(void);
char fsnextIsForUs;

int custom_fsnext( void *sp )
{
int res;

if(!fsnextIsForUs) {
return 0;
}

res = copyNextDtaToAtari();
return res;
}

If you compile this code with:

m68k-atari-mint-gcc -m68000 -mpcrel -O2 -c example.c

you'll get:

/tmp/ccqdKUHi.s:7: Error: syntax error -- statement `cmp.b
#0,(_fsnextIsForUs:w,%pc).l' ignored

For some reason, there's that ".l" suffix which is not understood by binutils
(2.23.2). Goes away with -O0.

[Bug c++/59945] "uint" typedef is visible with "g++ -std=c++11 -pedantic"

[Keith.S.Thompson at gmail dot com]

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

--- Comment #1 from Keith Thompson  ---
This came up in this question:
http://stackoverflow.com/q/21356275/827263
on Stack Overflow; the original version of the question used "uint" without
declaring it and compiled without error (at least without that error being
flagged).

[Bug libstdc++/51749] Including pollutes global namespace

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||Keith.S.Thompson at gmail dot 
com

--- Comment #27 from Jonathan Wakely  ---
*** Bug 59945 has been marked as a duplicate of this bug. ***

[Bug c++/59945] "uint" typedef is visible with "g++ -std=c++11 -pedantic"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
Glibc defines it:

#ifdef __USE_MISC
/* Old compatibility names for C types.  */
typedef unsigned long int ulong;
typedef unsigned short int ushort;
typedef unsigned int uint;
#endif

__USE_MISC is defined because G++ defines _GNU_SOURCE, which is well known to
cause problems, e.g. PR 11196 and PR 51749

This particular namespace pollution only occurs with C++11 because 
only needs to #include  in C++11 mode to define std::to_string,
std::stoi etc. but in general the problem affects C++98 too.

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

[Bug c++/59947] New: Segmentation fault with #pragma GCC optimize ("O2")

[timshen at gcc dot gnu.org]

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

Bug ID: 59947
   Summary: Segmentation fault with #pragma GCC optimize ("O2")
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: timshen at gcc dot gnu.org

The following piece of code causes a gcc segmentation fault:

// test.cc
#pragma GCC optimize ("O2")
#include 
template class std::basic_regex;


The backtrace info:

~ # /usr/local/bin/g++ -std=c++11 test.cc
In file included from /usr/local/include/c++/4.9.0/bits/basic_ios.h:37:0,
 from /usr/local/include/c++/4.9.0/ios:44,
 from /usr/local/include/c++/4.9.0/ostream:38,
 from /usr/local/include/c++/4.9.0/iterator:64,
 from /usr/local/include/c++/4.9.0/regex:44,
 from test.cc:2:
/usr/local/include/c++/4.9.0/bits/locale_facets.h: In member function ‘char
std::ctype::narrow(std::ctype::char_type, char) const’:
/usr/local/include/c++/4.9.0/bits/locale_facets.h:927:42: internal compiler
error: Segmentation fault
  const char __t = do_narrow(__c, __dfault);
  ^
0xb8afaf crash_signal
/home/root/src/gcc/gcc/toplev.c:337
0xa0c5a1 hash_table::find_slot_with_hash(tree_node
const*, unsigned int, insert_option)
/home/root/src/gcc/gcc/hash-table.h:774
0xa097bc get_odr_type(tree_node*, bool)
/home/root/src/gcc/gcc/ipa-devirt.c:413
0xa0b0a4 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**)
/home/root/src/gcc/gcc/ipa-devirt.c:1242
0x9c8774 possible_polymorphic_call_targets(tree_node*, bool*, void**)
/home/root/src/gcc/gcc/ipa-utils.h:135
0x9c5a83 gimple_fold_call
/home/root/src/gcc/gcc/gimple-fold.c:1193
0x9c5a83 fold_stmt_1
/home/root/src/gcc/gcc/gimple-fold.c:1306
0x9e643f gimplify_modify_expr
/home/root/src/gcc/gcc/gimplify.c:4582
0x9dab3b gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/home/root/src/gcc/gcc/gimplify.c:7441
0x9debf6 gimplify_stmt(tree_node**, gimple_statement_base**)
/home/root/src/gcc/gcc/gimplify.c:5334
0x9da393 gimplify_cleanup_point_expr
/home/root/src/gcc/gcc/gimplify.c:5110
0x9da393 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/home/root/src/gcc/gcc/gimplify.c:7804
0x9debf6 gimplify_stmt(tree_node**, gimple_statement_base**)
/home/root/src/gcc/gcc/gimplify.c:5334
0x9dad83 gimplify_statement_list
/home/root/src/gcc/gcc/gimplify.c:1405
0x9dad83 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/home/root/src/gcc/gcc/gimplify.c:7856
0x9debf6 gimplify_stmt(tree_node**, gimple_statement_base**)
/home/root/src/gcc/gcc/gimplify.c:5334
0x9df862 gimplify_bind_expr
/home/root/src/gcc/gcc/gimplify.c:1072
0x9da849 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
/home/root/src/gcc/gcc/gimplify.c:7638
0x9debf6 gimplify_stmt(tree_node**, gimple_statement_base**)
/home/root/src/gcc/gcc/gimplify.c:5334
0x9e03a9 gimplify_body(tree_node*, bool)
/home/root/src/gcc/gcc/gimplify.c:8548
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


My gcc is trunk@207098.

Thanks!

[Bug bootstrap/59934] Bootstrap fail since r206941: expmed.h:252:33: error: array subscript is above array bounds

[law at redhat dot com]

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

--- Comment #14 from Jeffrey A. Law  ---
Seems like a reasonable approach.  I'm bootstrapping it now on an s390x.