[Bug tree-optimization/60930] [4.8/4.9/4.10 Regression] Wrong folding of - ((unsigned long long) a * (unsigned long long) (unsigned int)-1)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-23
 CC||jakub at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
   Target Milestone|--- |4.8.3
Summary|Wrong folding of -  |[4.8/4.9/4.10 Regression]
   |((unsigned long long) a *   |Wrong folding of -
   |(unsigned long long)|((unsigned long long) a *
   |(unsigned int)-1)   |(unsigned long long)
   ||(unsigned int)-1)
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Indeed, started with r188989.

int x = 1;

__attribute__((noinline, noclone)) void
foo (unsigned long long t)
{
  asm volatile ("" : : "r" (&t));
  if (x == 1)
__builtin_abort ();
}

int
main ()
{
  unsigned long long t = 0xULL * (0xUL * x);
  if (t != 0x0001ULL)
foo (t);;
  return 0;
}

[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||sebastian.huber@embedded-br
   ||ains.de

--- Comment #1 from Sebastian Huber  ---
I can confirm this problem on the GCC 4.9.0 release.  This is a bit unfortunate
since on 2014-04-17 everything was fine:

http://gcc.gnu.org/ml/gcc-testresults/2014-04/msg01349.html

[Bug target/60607] -march=native command line option handling breaks LTO option machinery

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

Version|4.9.0   |4.9.1
   Target Milestone|--- |4.9.1

[Bug tree-optimization/60902] [4.9/4.10 Regression] ffmpeg built with gcc 4.9 RC produces incorrect flac playback code

[law at redhat dot com]

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

--- Comment #26 from Jeffrey A. Law  ---
Testing is good.  Just trying to build a nice little testcase for the
regression suite.

[Bug c++/60924] __attribute__((no_sanitize_address)) and friends should (only?) be allowed at function definitions

[y.gribov at samsung dot com]

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

Yury Gribov  changed:

   What|Removed |Added

 CC||y.gribov at samsung dot com

--- Comment #4 from Yury Gribov  ---
(In reply to Jakub Jelinek from comment #2)
> I don't see why, all other attributes are allowed on both declarations and
> definitions, having some attributes that are only allowed on definitions
> would be extremely confusing to users, and not really useful.

It's not just attributes - type specifiers may also be written only at
declarations and propagated to definitions.

[Bug fortran/60898] model compile error with gfortran 4.7 and gcc 4.9 on Mac OS 10.9

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
After providing all the missing 'USE' items:

plib8b-1.f90: In function ‘master.1.mulyb’:
plib8b-1.f90:1992:0: internal compiler error: Segmentation fault
 END SUBROUTINE mulbd
 ^
0x9fa86f crash_signal
../../trunk/gcc/toplev.c:337
0x9f7178 get_identifier(char const*)
../../trunk/gcc/stringpool.c:111
0x619940 generate_namelist_decl
../../trunk/gcc/fortran/trans-decl.c:4179
0x61a066 generate_local_nml_decl
../../trunk/gcc/fortran/trans-decl.c:4967
0x5da673 do_traverse_symtree
../../trunk/gcc/fortran/symbol.c:3575
0x61a1f7 generate_local_vars
../../trunk/gcc/fortran/trans-decl.c:4977
0x61a1f7 gfc_generate_function_code(gfc_namespace*)
../../trunk/gcc/fortran/trans-decl.c:5552
0x5f25a1 gfc_generate_module_code(gfc_namespace*)
../../trunk/gcc/fortran/trans.c:1972
0x5aee59 translate_all_program_units
../../trunk/gcc/fortran/parse.c:4522
0x5aee59 gfc_parse_file()
../../trunk/gcc/fortran/parse.c:4732
0x5ec145 gfc_be_parse_file
../../trunk/gcc/fortran/f95-lang.c:188

[Bug tree-optimization/60930] Wrong folding of - ((unsigned long long) a * (unsigned long long) (unsigned int)-1)

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Wrong constant folding  |Wrong folding of -
   ||((unsigned long long) a *
   ||(unsigned long long)
   ||(unsigned int)-1)

--- Comment #1 from Andrew Pinski  ---
Confirmed, slsr is causing the problem.

[Bug tree-optimization/60930] New: Wrong constant folding

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 60930
   Summary: Wrong constant folding
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp

GCC 4.7 - 4.10 for i686 and x86_64 miscompiles the following code.

$ cat error.c

#include 
int x = 1;
main ()
{
unsigned long long t = 0xLLU * (0xLU * x);
if (t != 0x0001LLU) {
printf ("Error (t == %llu)\n", t);
}
return 0;
}

$ x86_64-unknown-linux-gnu-gcc-4.10.0 error.c -O1
$ ./a.out
Error 1

$ x86_64-unknown-linux-gnu-gcc-4.10.0 -v
Using built-in specs.
COLLECT_GCC=x86_64-unknown-linux-gnu-gcc-4.10.0
   
COLLECT_LTO_WRAPPER=/usr/local/x86_64-tools/gcc-4.10.0/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/hassy/gcc-master/configure
--prefix=/usr/local/x86_64-tools/gcc-4.10.0/
--with-gmp=/usr/local/gmp-5.1.1/ --with-mpfr=/usr/local/mpfr-3.1.2/
--with-mpc=/usr/local/mpc-1.0.2/ --disable-multilib
--disable-nls --enable-languages=c
Thread model: posix
gcc version 4.10.0 20140422 (experimental) (GCC)

The status of the other versions are as follows:

(x86_64)
GCC-4.7.3 OK
GCC-4.8.3 (prerelease) Error
GCC-4.9.1 (prerelease) Error
GCC-4.10.0 (experimental) Error

(i686)
GCC-4.7.3 Error
GCC-4.8.3 (prerelease) Error
GCC-4.9.1 (prerelease) Error
GCC-4.10.0 (experimental) Error

[Bug debug/60929] New: [4.8/4.9/4.10 regression] ICE in get_ref_die_offset, at dwarf2out.c

[ppluzhnikov at google dot com]

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

Bug ID: 60929
   Summary: [4.8/4.9/4.10 regression] ICE  in get_ref_die_offset,
at dwarf2out.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppluzhnikov at google dot com

Created attachment 32658
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32658&action=edit
test case

Using trunk @r209546:

g++ -fdebug-types-section -gdwarf-4 -fmax-errors=1 '-std=gnu++11' -S t.cc &&
echo OK
OK

g++ -fdebug-types-section -gdwarf-4 -fmax-errors=1 '-std=gnu++11' -S t.cc -O2
t.cc:84:1: internal compiler error: in get_ref_die_offset, at dwarf2out.c:3553
 }
 ^
0x892691 get_ref_die_offset
../../gcc/dwarf2out.c:3553
0x892691 output_loc_operands
../../gcc/dwarf2out.c:2081
0x892691 output_loc_sequence(dw_loc_descr_node*, int)
../../gcc/dwarf2out.c:2127
0x892eff output_die
../../gcc/dwarf2out.c:8558
0x892821 output_die
../../gcc/dwarf2out.c:8761
0x892821 output_die
../../gcc/dwarf2out.c:8761
0x892821 output_die
../../gcc/dwarf2out.c:8761
0x892821 output_die
../../gcc/dwarf2out.c:8761
0x892821 output_die
../../gcc/dwarf2out.c:8761
0x896841 output_comdat_type_unit
../../gcc/dwarf2out.c:9032
0x8b7b69 dwarf2out_finish
../../gcc/dwarf2out.c:24255
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

Google ref: b/14230806

[Bug fortran/60898] model compile error with gfortran 4.7 and gcc 4.9 on Mac OS 10.9

[shaojuncycle at gmail dot com]

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

--- Comment #2 from cycle  ---
Thank you for you reply.
The code file plib8b.f90 is in the attachment.


2014-04-21 21:02 GMT+08:00 dominiq at lps dot ens.fr <
gcc-bugzi...@gcc.gnu.org>:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898
>
> Dominique d'Humieres  changed:
>
>What|Removed |Added
>
> 
>  Status|UNCONFIRMED |WAITING
>Last reconfirmed||2014-04-21
>  Ever confirmed|0   |1
>
> --- Comment #1 from Dominique d'Humieres  ---
> Did you
> See  for instructions.
> ?
>
> Apparently not. You have to provide the code for plib8b.f90 (along with
> files
> for needed modules and includes). Note that it will help if you can reduce
> the
> code.
>
> --
> You are receiving this mail because:
> You reported the bug.
>

[Bug fortran/60928] New: gfortran issue with allocatable components and OpenMP

[quantheory at gmail dot com]

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

Bug ID: 60928
   Summary: gfortran issue with allocatable components and OpenMP
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: quantheory at gmail dot com

Just as a disclaimer up front, this is probably an OpenMP 4.0 issue. OpenMP 3.1
sort of glossed over this use case, but OpenMP 4.0 quietly added language about
it. Still, it would be nice to get right, and it doesn't involve any of the new
constructs.

The following test case works with nagfor, xlf, and newer versions of
pgfortran, but not gfortran or ifort:


use omp_lib, only: omp_get_thread_num
implicit none

type :: foo
   integer, allocatable :: a(:)
end type foo

type(foo) :: bar

integer :: i, sum_arr(5)

!$omp parallel private (i, bar)

allocate(bar%a(3))

!$omp do
do i = 1, 5
   bar%a = [1, 2, 3] + omp_get_thread_num()
   sum_arr(i) = sum(bar%a)
end do

!$omp barrier
print *, sum(bar%a)
!$omp barrier

!$omp single
print *, sum(sum_arr)
!$omp end single

deallocate(bar%a)

!$omp end parallel

end


This is the runtime's error message:

Fortran runtime error: Attempting to allocate already allocated variable 'bar'

I think this signifies that the private version of "bar" is not being set up
correctly, so the threads end up sharing the allocatable component.

[Bug target/60735] GCC targeting E500 with SPE has errors with the _Decimal64 type

[meissner at gcc dot gnu.org]

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

--- Comment #13 from Michael Meissner  ---
Author: meissner
Date: Tue Apr 22 23:33:14 2014
New Revision: 209664

URL: http://gcc.gnu.org/viewcvs?rev=209664&root=gcc&view=rev
Log:
[gcc]
2014-04-21  Michael Meissner  

PR target/60735
* config/rs6000/rs6000.md (mov_softfloat32, FMOVE64 case):
If mode is DDmode and TARGET_E500_DOUBLE allow move.

* config/rs6000/rs6000.c (rs6000_debug_reg_global): Print some
more debug information for E500 if -mdebug=reg.

[gcc/testsuite]
2014-04-21  Michael Meissner  

PR target/60735
* gcc.target/powerpc/pr60735.c: New test.  Insure _Decimal64 does
not cause errors if -mspe.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/pr60735.c
  - copied unchanged from r209549,
trunk/gcc/testsuite/gcc.target/powerpc/pr60735.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c++/60927] Ambiguity not caught when name introduced through using-directive conflicts with previously declared entity

[mbos at google dot com]

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

Maurice Bos  changed:

   What|Removed |Added

 CC||mbos at google dot com

--- Comment #1 from Maurice Bos  ---
Some interesting related test cases:

namespace N { struct A {}; }
namespace A {}
using namespace N;
A * x;
int main() {}

G++ correctly complains about ambiguity. When the two lines with 'N' are
removed, it complains that A is not a type. (As expected.)

Very similar test case:

#include 
namespace N { struct A {}; }
namespace A {}
using namespace N;
std::unique_ptr x; // Only this line is different.
int main() {}

G++ does not complain about ambiguity, but gives the same error as when the two
lines with 'N' are removed.

[Bug target/60926] Compiler doesn't properly align stack pointer

[gidici61 at gmail dot com]

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

--- Comment #5 from gidici61 at gmail dot com ---
Please see also: 
http://stackoverflow.com/questions/22941372/gcc-4-7-2-in-debian-wheezy-doesnt-always-properly-align-stack-pointer-is-this/23055211#23055211

[Bug libstdc++/56019] max_align_t should be in std namespace

[Jobst.Ziebell at mailbox dot tu-dresden.de]

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

--- Comment #5 from Jobst.Ziebell at mailbox dot tu-dresden.de ---
I would propose adding something like

#ifdef _GCC_MAX_ALIGN_T
...
#endif
around the 'using' declaration.

(Though I really have no idea whatsoever off gcc internals...)

[Bug target/60926] Compiler doesn't properly align stack pointer

[gidici61 at gmail dot com]

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

--- Comment #4 from gidici61 at gmail dot com ---
(In reply to Andrew Pinski from comment #3)
> (In reply to gidici61 from comment #2)
> > Register rsp is correctly aligned before "call g1"; let's assume rsp=0xB0.
> > "call g1" pushes rip (8 bytes) on the stack.  Now rsp=0xA8.
> > Then "pushq %rbp" subtracts 8.  Now rsp=0xA0.
> > "subq $8, %rsp" subtracts 8.  Now rsp=0x98
> > So before calling g2() rsp is not properly aligned.
> 
> call also pushes onto the stack.

If you add "putchar(p1)" in g2(), then rsp become 16-byte aligned before
calling g2():

   int g2(int p1) { putchar(p1); return p1; }
   int g1(int p1) { return g2(p1); }
   int main() { return g1(65); }

gives the following assembler code:

g1:
pushq%rbp
movq%rsp, %rbp
subq$16, %rsp   ; OK
movl%edi, -4(%rbp)
movl-4(%rbp), %eax
movl%eax, %edi
callg2
leave
ret

[Bug libstdc++/55817] [C++11] void return value in std::vector::insert() c++11 should be an iterator

[Jobst.Ziebell at mailbox dot tu-dresden.de]

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

Jobst.Ziebell at mailbox dot tu-dresden.de changed:

   What|Removed |Added

 Status|NEW |RESOLVED
Version|4.7.1   |4.9.0
 Resolution|--- |WORKSFORME

--- Comment #4 from Jobst.Ziebell at mailbox dot tu-dresden.de ---
This seems to be fixed in GCC 4.9.0

[Bug target/60926] Compiler doesn't properly align stack pointer

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to gidici61 from comment #2)
> Register rsp is correctly aligned before "call g1"; let's assume rsp=0xB0.
> "call g1" pushes rip (8 bytes) on the stack.  Now rsp=0xA8.
> Then "pushq %rbp" subtracts 8.  Now rsp=0xA0.
> "subq $8, %rsp" subtracts 8.  Now rsp=0x98
> So before calling g2() rsp is not properly aligned.

call also pushes onto the stack.

[Bug c++/60927] New: Ambiguity not caught when name introduced through using-directive conflicts with previously declared entity

[filip.roseen at gmail dot com]

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

Bug ID: 60927
   Summary: Ambiguity not caught when name introduced through
using-directive conflicts with previously declared
entity
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: filip.roseen at gmail dot com

Created attachment 32656
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32656&action=edit
testcase.cpp

namespace N {
  namespace A {
int x = 1;
  }
}

struct A {
  static int x;
};

int main () {
  using namespace N;

  A::x = 123;
}



`gcc` accepts the above even though there's an ambiguity between `N::A::x` and
`A::x` when referenced as `A::x` in `main`.

--

[ note: `gcc` treats the `A::x` as referring to `N::A::x`. ]

[ note: `clang` shows the correct behaviour and issues a diagnostic saying that
`A::x` is ambiguous. ]

[Bug target/60926] Compiler doesn't properly align stack pointer

[gidici61 at gmail dot com]

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

--- Comment #2 from gidici61 at gmail dot com ---
Register rsp is correctly aligned before "call g1"; let's assume rsp=0xB0.
"call g1" pushes rip (8 bytes) on the stack.  Now rsp=0xA8.
Then "pushq %rbp" subtracts 8.  Now rsp=0xA0.
"subq $8, %rsp" subtracts 8.  Now rsp=0x98
So before calling g2() rsp is not properly aligned.

[Bug libstdc++/56019] max_align_t should be in std namespace

[Jobst.Ziebell at mailbox dot tu-dresden.de]

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

Jobst.Ziebell at mailbox dot tu-dresden.de changed:

   What|Removed |Added

 CC||Jobst.Ziebell at mailbox dot 
tu-dr
   ||esden.de

--- Comment #4 from Jobst.Ziebell at mailbox dot tu-dresden.de ---
The fix introduces another problem. Whenever '__need_size_t' is defined prior
to the inclusion of , the type 'max_align_t' will not have been
defined.
This inevitably causes a compiler error:

#define __need_size_t
#include 

int main( void )
{
return 0;
}

This happens on Mac OS X 10.9. In my case it got triggered by including
.
Presumably this bug also occurs when #defining the other '__need_*' macros.

[Bug middle-end/59507] ICE: in mark_reachable_handlers, at tree-eh.c:3833 with -O -fnon-call-exceptions -fvtable-verify=preinit

[ctice at gcc dot gnu.org]

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

ctice at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ctice at gcc dot gnu.org

--- Comment #3 from ctice at gcc dot gnu.org ---

This is caused by the verification call being inserted after an exception
handler landing pad, in the same basic block as the landing pad, when GCC
expects the landing pad statement to be the last statement in the basic block.

The fix for this will be to split all the outgoing edges and insert new basic
blocks on each, with the verification call in there instead.  I will work on
this, but it may take me a little time to get right.

[Bug fortran/60495] [4.9/4.10 Regression] ICE: in fold_convert_loc, at fold-const.c:1994

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #11 from Tobias Burnus  ---
And now also FIXED on the 4.9 branch (for GCC 4.9.1).

Thanks for the report!

[Bug fortran/58880] [4.9/4.10 Regression] [OOP] ICE on valid with FINAL function and type extension

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #16 from Tobias Burnus  ---
And now also FIXED on the 4.9 branch (for GCC 4.9.1).

Thanks for the report!

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

[ctice at gcc dot gnu.org]

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

--- Comment #2 from ctice at gcc dot gnu.org ---
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?

[Bug fortran/58880] [4.9/4.10 Regression] [OOP] ICE on valid with FINAL function and type extension

[burnus at gcc dot gnu.org]

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

--- Comment #15 from Tobias Burnus  ---
Author: burnus
Date: Tue Apr 22 21:12:46 2014
New Revision: 209662

URL: http://gcc.gnu.org/viewcvs?rev=209662&root=gcc&view=rev
Log:
2014-04-22  Tobias Burnus  

Backport from mainline
2014-04-11  Tobias Burnus  

PR fortran/58880
PR fortran/60495
* resolve.c (gfc_resolve_finalizers): Ensure that vtables
and finalization wrappers are generated.

2014-04-22  Tobias Burnus  

Backport from mainline
2014-04-11  Tobias Burnus  

PR fortran/58880
PR fortran/60495
* gfortran.dg/finalize_25.f90: New.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/finalize_25.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/resolve.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/60495] [4.9/4.10 Regression] ICE: in fold_convert_loc, at fold-const.c:1994

[burnus at gcc dot gnu.org]

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

--- Comment #10 from Tobias Burnus  ---
Author: burnus
Date: Tue Apr 22 21:12:46 2014
New Revision: 209662

URL: http://gcc.gnu.org/viewcvs?rev=209662&root=gcc&view=rev
Log:
2014-04-22  Tobias Burnus  

Backport from mainline
2014-04-11  Tobias Burnus  

PR fortran/58880
PR fortran/60495
* resolve.c (gfc_resolve_finalizers): Ensure that vtables
and finalization wrappers are generated.

2014-04-22  Tobias Burnus  

Backport from mainline
2014-04-11  Tobias Burnus  

PR fortran/58880
PR fortran/60495
* gfortran.dg/finalize_25.f90: New.


Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/finalize_25.f90
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/resolve.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/60926] Compiler doesn't properly align stack pointer

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
>   pushq   %rbp
>   movq%rsp, %rbp
>   subq$8, %rsp ; why 8? 

Because the pushq increments rsp by 8 so adding another 8 will cause it to be
full addition of 16.

[Bug c/60926] New: Compiler doesn't properly align stack pointer

[gidici61 at gmail dot com]

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

Bug ID: 60926
   Summary: Compiler doesn't properly align stack pointer
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gidici61 at gmail dot com

Assembly code of the sample C code:

int g2(int p1) { return p1; }
int g1(int p1) { return g2(p1); }
int main() { return g1(65); }

when compiled [¹] on Debian wheezy using gcc v.4.7.2 shows that register rsp is
not 16 byte aligned before calling g2():

g1:
pushq%rbp
movq%rsp, %rbp
subq$8, %rsp ; why 8? 
movl%edi, -4(%rbp)
movl-4(%rbp), %eax
movl%eax, %edi
callg2
leave
ret

[¹] gcc -S filename.c

[Bug c++/60850] pedantic warning behavior when casting void* to ptr-to-func

[daniel.gutson at tallertechnologies dot com]

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

--- Comment #6 from Daniel Gutson  
---
Thanks Manuel.

1) I didn't see a warning regarding the old use of -pedantic rather than
-Wpedantic

2) I'll change that, after the C++ FE maintainer sees the patch in order to not
pollute the thread with more patches. I didn't know about the deprecation of
-pedantic, thanks!

And thanks for your encouraging words!

[Bug c++/60924] __attribute__((no_sanitize_address)) and friends should (only?) be allowed at function definitions

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
>I think we should disallow __attribute__((no_sanitize_address)) at 
>declarations because:
> 1) it's more consistent

More consistent with what, it would be very inconsistent with the rest of GCC's
attributes.

>2) it's much more readable, there's no "implicit attribute applied somewhere 
>else"
>   when looking at the code of a function/method.

This is just like where is the comment which describes what the arguments do. 
Is there is only one coding style in this world?

>4) applying/removing the attribute would usually result in fewer 
>recompilations (2000+ TUs in my case)

This is a C++ problem rather than a GCC issue :).  Modules for the win.

[Bug c++/60924] __attribute__((no_sanitize_address)) and friends should (only?) be allowed at function definitions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I don't see why, all other attributes are allowed on both declarations and
definitions, having some attributes that are only allowed on definitions would
be extremely confusing to users, and not really useful.

[Bug target/60925] [4.9 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'

[aaro.koskinen at iki dot fi]

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

--- Comment #2 from Aaro Koskinen  ---
GLIVC 2.19 compiles fine with GCC 4.8.2.

[Bug target/60925] [4.9 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'

[aaro.koskinen at iki dot fi]

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

--- Comment #1 from Aaro Koskinen  ---
Created attachment 32655
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32655&action=edit
Pre-processed source.

Steps to reproduce:

hppa-linux-gnu-gcc gethstbyad.i -c -std=gnu99 -fgnu89-inline  -O2 -Wall
-Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g
-Wstrict-prototypes -fPIC -fexceptions

[Bug fortran/60881] ICE on dummy argument that extends a type with scalar and scalar coarry components

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||burnus at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Tobias Burnus  ---
FIXED on the trunk (GCC 4.10).

Thanks for the report!

[Bug target/60925] New: [4.9 Regression] hppa: can't find a register in class 'R1_REGS' while reloading 'asm'

[aaro.koskinen at iki dot fi]

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

Bug ID: 60925
   Summary: [4.9 Regression] hppa: can't find a register in class
'R1_REGS' while reloading 'asm'
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aaro.koskinen at iki dot fi

Build failure when compiling GLIBC 2.19 with GCC 4.9.0 on PA-RISC:

hppa-linux-gnu-gcc gethstbyad.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall
-Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g
-Wstrict-prototypes   -fPIC -fexceptions  -I../include
-I/home/aaro/los/work/parisc/glibc-2.19-build/default/inet 
-I/home/aaro/los/work/parisc/glibc-2.19-build/default 
-I../ports/sysdeps/unix/sysv/linux/hppa/nptl 
-I../ports/sysdeps/unix/sysv/linux/hppa  -I../nptl/sysdeps/unix/sysv/linux 
-I../nptl/sysdeps/pthread  -I../sysdeps/pthread 
-I../ports/sysdeps/unix/sysv/linux  -I../sysdeps/unix/sysv/linux 
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../nptl/sysdeps/unix/sysv 
-I../ports/sysdeps/unix/sysv  -I../sysdeps/unix/sysv  -I../nptl/sysdeps/unix 
-I../ports/sysdeps/unix  -I../sysdeps/unix  -I../sysdeps/posix 
-I../ports/sysdeps/hppa/hppa1.1  -I../sysdeps/wordsize-32 
-I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754/dbl-64 
-I../ports/sysdeps/hppa/fpu  -I../ports/sysdeps/hppa/nptl 
-I../ports/sysdeps/hppa  -I../sysdeps/ieee754  -I../sysdeps/generic  -I../nptl 
-I../ports  -I.. -I../libio -I. -nostdinc -isystem
/home/aaro/los/work/parisc/toolchain/lib/gcc/hppa-linux-gnu/4.9.0/include
-isystem
/home/aaro/los/work/parisc/toolchain/lib/gcc/hppa-linux-gnu/4.9.0/include-fixed
-isystem /home/aaro/los/work/parisc/toolchain/glibc/hppa-linux-gnu/usr/include 
-D_LIBC_REENTRANT -include ../include/libc-symbols.h  -DPIC -DSHARED -o
/home/aaro/los/work/parisc/glibc-2.19-build/default/inet/gethstbyad.os -MD -MP
-MF /home/aaro/los/work/parisc/glibc-2.19-build/default/inet/gethstbyad.os.dt
-MT /home/aaro/los/work/parisc/glibc-2.19-build/default/inet/gethstbyad.os
In file included from ../include/atomic.h:50:0,
 from
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:25,
 from ../nptl/descr.h:30,
 from ../ports/sysdeps/hppa/nptl/tls.h:56,
 from ../include/link.h:44,
 from ../include/dlfcn.h:4,
 from ../nss/nsswitch.h:28,
 from ../include/nsswitch.h:1,
 from ../inet/netgroup.h:22,
 from ../include/netdb.h:193,
 from gethstbyad.c:19:
../nss/getXXbyYY.c: In function 'gethostbyaddr':
../ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:68:6: error: can't find a
register in class 'R1_REGS' while reloading 'asm'
  asm volatile(   \
  ^
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:219:13: note: in
expansion of macro 'atomic_compare_and_exchange_val_acq'
   int val = atomic_compare_and_exchange_val_acq (futex, 1, 0);
 ^
../ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:68:6: error: can't find a
register in class 'R1_REGS' while reloading 'asm'
  asm volatile(   \
  ^
../ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:97:12: note: in expansion
of macro 'atomic_compare_and_exchange_val_acq'
  ret = atomic_compare_and_exchange_val_acq(mem, newval, oldval); \
^
../include/atomic.h:189:7: note: in expansion of macro
'atomic_compare_and_exchange_bool_acq'
  (atomic_compare_and_exchange_bool_acq (__atg5_memp, __atg5_value, \
   ^
../include/atomic.h:196:45: note: in expansion of macro 'atomic_exchange_acq'
 # define atomic_exchange_rel(mem, newvalue) atomic_exchange_acq (mem,
newvalue)
 ^
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:293:16: note: in
expansion of macro 'atomic_exchange_rel'
   ({ int val = atomic_exchange_rel (futex, 0);  \
^
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:297:36: note: in
expansion of macro '__lll_unlock'
 #define lll_unlock(futex, private) __lll_unlock(&(futex), private)
^
../nptl/sysdeps/pthread/bits/libc-lockP.h:203:3: note: in expansion of macro
'lll_unlock'
   lll_unlock (NAME, LLL_PRIVATE)
   ^
../nss/getXXbyYY.c:144:3: note: in expansion of macro '__libc_lock_unlock'
   __libc_lock_unlock (lock);
   ^
../ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:68:6: error: 'asm' operand
has impossible constraints
  asm volatile(   \
  ^
../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:219:13: note: in
expansion of macro 'atomic_compare_and_exchange_val_acq'
   int val = atomic_compare_and_exchange_val_acq (futex, 1, 0);
 ^
../ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:68:6: error: 'asm' operand
has impossible constraints
  asm volatile(   \

[Bug fortran/60881] ICE on dummy argument that extends a type with scalar and scalar coarry components

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Author: burnus
Date: Tue Apr 22 19:28:43 2014
New Revision: 209657

URL: http://gcc.gnu.org/viewcvs?rev=209657&root=gcc&view=rev
Log:
2014-04-22  Tobias Burnus  

PR fortran/60881
* trans-expr.c (gfc_trans_subcomponent_assign): Fix handling
of scalar coarrays.

2014-04-22  Tobias Burnus  

PR fortran/60881
* coarray/alloc_comp_3.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/coarray/alloc_comp_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/60906] target attribute causes other attributes to be ignored

[harald at gigawatt dot nl]

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

--- Comment #8 from Harald van Dijk  ---
Oh, based on the existing error for

void f();
void f() __attribute__((regparm(3)));

which is accepted on x86-64, but fails on x86-32 with

test.cc:2:36: error: new declaration ‘void f()’
 void f() __attribute__((regparm(3)));
^
test.cc:1:6: error: ambiguates old declaration ‘void f()’
 void f();
  ^

even though things like

void f();
void f() __attribute__((noreturn));

and

void f();
void f() __attribute__((deprecated));

are accepted, I assumed that the existing logic to check attribute
compatibility (which I suggested to reuse) was a reliable way of determining
which attributes are and which aren't safe. If that's incorrect, then sure, my
suggestion is not suitable, I can completely see how huge of a maintenance
burden that would become.

[Bug target/60906] target attribute causes other attributes to be ignored

[tmsriram at google dot com]

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

--- Comment #7 from Sriraman Tallam  ---
(In reply to Jakub Jelinek from comment #6)
> GCC has like 60 or 70 target independent attributes plus sometimes various
> target dependent attributes.  Figuring out which are ABI changing and must
> be errored out on mismatch, which are safe to ignore, which are only
> affecting function generation and not callers is going to be hard even for
> the existing ones, and would be a maintainance burden for the future, as for
> each new attribute (every year a few of them are added) it would be another
> place to modify and think about what the behavior should be.  Keying
> something on default attribute would be weird, for multi-versioning you
> don't have to have target ("default") I think.  

Multi-versioning needs the target("default") version or error.

If you want to inherit the
> attributes, perhaps from the first decl only, and if the second/further
> multi-versioned declarations or definitions add attributes (other than the
> target attribute), it would be only allowed if the attribute wouldn't modify
> the attribute list (i.e. contain attribute that is already present).

[Bug target/60906] target attribute causes other attributes to be ignored

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
GCC has like 60 or 70 target independent attributes plus sometimes various
target dependent attributes.  Figuring out which are ABI changing and must be
errored out on mismatch, which are safe to ignore, which are only affecting
function generation and not callers is going to be hard even for the existing
ones, and would be a maintainance burden for the future, as for each new
attribute (every year a few of them are added) it would be another place to
modify and think about what the behavior should be.  Keying something on
default attribute would be weird, for multi-versioning you don't have to have
target ("default") I think.  If you want to inherit the attributes, perhaps
from the first decl only, and if the second/further multi-versioned
declarations or definitions add attributes (other than the target attribute),
it would be only allowed if the attribute wouldn't modify the attribute list
(i.e. contain attribute that is already present).

[Bug target/60906] target attribute causes other attributes to be ignored

[harald at gigawatt dot nl]

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

--- Comment #5 from Harald van Dijk  ---
(In reply to Sriraman Tallam from comment #4)
> I do not understand why the default function's attributes should be applied
> to all declarations?

The alternative is to not apply them to all declarations, but give an error if
any declarations are in conflict. Take example f3: if that means the default
function uses regparm(3), but the target function does not, then if the
dispatcher uses regparm(3), dispatching to the target function will fail. If
the dispatcher doesn't use regparm(3), dispatching to the default function will
fail. Making it an error would be just as safe and sensible, but IMO slightly
less user-friendly, and most of the work to check attribute compatibility would
need to be done either way.

[Bug target/60906] target attribute causes other attributes to be ignored

[tmsriram at google dot com]

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

Sriraman Tallam  changed:

   What|Removed |Added

 CC||tmsriram at google dot com

--- Comment #4 from Sriraman Tallam  ---
(In reply to Harald van Dijk from comment #3)
> Speaking only as a user, the behaviour I personally naïvely expected would
> be to push the default function's attributes into each target-specific
> function's attributes, and use the already existing rules for diagnosing
> conflicting attributes. The dispatcher (ifunc) would take the attributes of
> the default function.
> 
> Test cases:
> 
> void f1() __attribute__((target("default")));
> void f1() __attribute__((target("arch=corei7"), noreturn));
> // valid, but would apply noreturn attribute only to arch=corei7 declaration
> 

> void f2() __attribute__((target("default"), noreturn));
> void f2() __attribute__((target("arch=corei7")));
> // valid, would apply noreturn attribute to all three declarations

I do not understand why the default function's attributes should be applied to
all declarations?

> 
> void f3() __attribute__((target("default"), regparm(3)));
> void f3() __attribute__((target("arch=corei7")));
> // valid, would apply regparm(3) attribute to all three declarations
> 
> void f4() __attribute__((target("default")));
> void f4() __attribute__((target("arch=corei7"), regparm(3)));
> // invalid
> 
> The f4 testcase would be analogous to
> 
> int f(int x);
> int f(int x) __attribute__((regparm(3)));
> 
> which is already a compile-time error (in 32-bit mode).


Nice list of examples.  I think we can allow the various versions to have
distinct non-target attributes, I also think there is no need to apply the
default's functions attributes to all versions.  Also, we should check if the
non-common attributes pose a risk like regparm and issue an error
appropriately. Then, apply only the common attributes to ifunc.

[Bug libstdc++/43622] no C++ typeinfo for __float128

[glisse at gcc dot gnu.org]

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

--- Comment #19 from Marc Glisse  ---
Created attachment 32654
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32654&action=edit
potential export fix

I am currently testing the attached.

[Bug c++/60924] __attribute__((no_sanitize_address)) and friends should (only?) be allowed at function definitions

[timurrrr at google dot com]

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

Timur Iskhodzhanov  changed:

   What|Removed |Added

 CC||kcc at gcc dot gnu.org

--- Comment #1 from Timur Iskhodzhanov  ---
[+Kostya]

[Bug libstdc++/43622] no C++ typeinfo for __float128

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #18 from Marc Glisse  ---
The easiest would be to move CXXABI_LDBL_1.3 to gnu.ver and use that for the
new __float128 symbols on x86, but I'm sure that would be considered too hacky.

[Bug libstdc++/43622] no C++ typeinfo for __float128

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  ---
(In reply to Marc Glisse from comment #16)
> Should I revert right away?

If it doesn't break bootstrap for the ldbl targets (only causes test failures)
then I would say reverting it is not necessary if you will be able to work on a
fix fairly quickly.

> It looks like I need to create a file config/?/?/float128.ver and find the
> right incantation in configure to add it to port_specific_symbol_files for
> those 3 targets?

I honestly don't know, but that sounds reasonable.

[Bug target/60906] target attribute causes other attributes to be ignored

[harald at gigawatt dot nl]

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

--- Comment #3 from Harald van Dijk  ---
Speaking only as a user, the behaviour I personally naïvely expected would be
to push the default function's attributes into each target-specific function's
attributes, and use the already existing rules for diagnosing conflicting
attributes. The dispatcher (ifunc) would take the attributes of the default
function.

Test cases:

void f1() __attribute__((target("default")));
void f1() __attribute__((target("arch=corei7"), noreturn));
// valid, but would apply noreturn attribute only to arch=corei7 declaration

void f2() __attribute__((target("default"), noreturn));
void f2() __attribute__((target("arch=corei7")));
// valid, would apply noreturn attribute to all three declarations

void f3() __attribute__((target("default"), regparm(3)));
void f3() __attribute__((target("arch=corei7")));
// valid, would apply regparm(3) attribute to all three declarations

void f4() __attribute__((target("default")));
void f4() __attribute__((target("arch=corei7"), regparm(3)));
// invalid

The f4 testcase would be analogous to

int f(int x);
int f(int x) __attribute__((regparm(3)));

which is already a compile-time error (in 32-bit mode).

[Bug libstdc++/43622] no C++ typeinfo for __float128

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #16 from Marc Glisse  ---
(In reply to Jakub Jelinek from comment #6)
> I guess #c4 patch will break ppc/s390 etc.
> config/os/gnu-linux/ldbl-extra.ver already has:
> CXXABI_LDBL_1.3 {
>   _ZT[IS]g;
>   _ZT[IS]Pg;
>   _ZT[IS]PKg;
> };
> 
> So, IMNSHO you don't want to add something like that to gnu.ver, but have
> a special *.ver file for those 3 targets (i?86/x86_64/ia64) that have
> __float128.

Er, oups, I was going to close the bug, but apparently I overlooked this
comment when writing the patch, sorry :-(

Should I revert right away?

It looks like I need to create a file config/?/?/float128.ver and find the
right incantation in configure to add it to port_specific_symbol_files for
those 3 targets?

[Bug libstdc++/43622] no C++ typeinfo for __float128

[glisse at gcc dot gnu.org]

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

--- Comment #15 from Marc Glisse  ---
Author: glisse
Date: Tue Apr 22 16:44:46 2014
New Revision: 209652

URL: http://gcc.gnu.org/viewcvs?rev=209652&root=gcc&view=rev
Log:
2014-04-22  Marc Glisse  

PR libstdc++/43622
gcc/c-family/
* c-common.c (registered_builtin_types): Make non-static.
* c-common.h (registered_builtin_types): Declare.
gcc/cp/
* rtti.c (emit_support_tinfo_1): New function, extracted from
emit_support_tinfos.
(emit_support_tinfos): Call it and iterate on registered_builtin_types.
libstdc++-v3/
* config/abi/pre/gnu.ver (CXXABI_1.3.9): New version, new symbols.
* config/abi/pre/gnu-versioned-namespace.ver: New symbols.
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Likewise.



Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/c-family/c-common.h
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/rtti.c
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/post/x86_64-linux-gnu/baseline_symbols.txt
trunk/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver
trunk/libstdc++-v3/config/abi/pre/gnu.ver

[Bug target/60868] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -minline-all-stringops -minline-stringops-dynamically -march=core2

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #5 from H.J. Lu  ---
Fixed.

[Bug c/59073] [4.9/4.10 Regression] ICE with missing increment in OpenMP for-loop

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #8 from Jakub Jelinek  ---
Should be fixed now.

[Bug target/60868] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -minline-all-stringops -minline-stringops-dynamically -march=core2

[hjl at gcc dot gnu.org]

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

--- Comment #4 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Apr 22 16:34:54 2014
New Revision: 209651

URL: http://gcc.gnu.org/viewcvs?rev=209651&root=gcc&view=rev
Log:
Use counter_mode on count_exp to get mode

gcc/

Backport from mainline
PR target/60868
* config/i386/i386.c (ix86_expand_set_or_movmem): Call counter_mode 
on count_exp to get mode.

gcc/testsuite/

Backport from mainline
PR target/60868
* gcc.target/i386/pr60868.c: New testcase.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr60868.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/i386/i386.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/60868] [4.9/4.10 Regression] ICE: in int_mode_for_mode, at stor-layout.c:400 with -minline-all-stringops -minline-stringops-dynamically -march=core2

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Apr 22 16:31:41 2014
New Revision: 209648

URL: http://gcc.gnu.org/viewcvs?rev=209648&root=gcc&view=rev
Log:
Use counter_mode on count_exp to get mode

gcc/

PR target/60868
* config/i386/i386.c (ix86_expand_set_or_movmem): Call counter_mode 
on count_exp to get mode.

gcc/testsuite/

PR target/60868
* gcc.target/i386/pr60868.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr60868.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c/59073] [4.9/4.10 Regression] ICE with missing increment in OpenMP for-loop

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 22 16:25:59 2014
New Revision: 209647

URL: http://gcc.gnu.org/viewcvs?rev=209647&root=gcc&view=rev
Log:
PR c/59073
c/
* c-parser.c (c_parser_omp_parallel): If c_parser_omp_for
fails, don't set OM_PARALLEL_COMBINED and return NULL.
cp/
* parser.c (cp_parser_omp_parallel): If cp_parser_omp_for
fails, don't set OM_PARALLEL_COMBINED and return NULL.
testsuite/
* c-c++-common/gomp/pr59073.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/gomp/pr59073.c
Modified:
branches/gcc-4_9-branch/gcc/c/ChangeLog
branches/gcc-4_9-branch/gcc/c/c-parser.c
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/parser.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/59073] [4.9/4.10 Regression] ICE with missing increment in OpenMP for-loop

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 22 16:22:22 2014
New Revision: 209646

URL: http://gcc.gnu.org/viewcvs?rev=209646&root=gcc&view=rev
Log:
PR c/59073
c/
* c-parser.c (c_parser_omp_parallel): If c_parser_omp_for
fails, don't set OM_PARALLEL_COMBINED and return NULL.
cp/
* parser.c (cp_parser_omp_parallel): If cp_parser_omp_for
fails, don't set OM_PARALLEL_COMBINED and return NULL.
testsuite/
* c-c++-common/gomp/pr59073.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/pr59073.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/60923] New: Building of gcc fails on sparc solaris 9, In function '__muldi3' internal compiler error: Segmentation Fault

[mukul.gupta at aricent dot com]

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

Bug ID: 60923
   Summary: Building of gcc fails on sparc solaris 9, In function
'__muldi3' internal compiler error: Segmentation Fault
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mukul.gupta at aricent dot com

make[6]: Leaving directory
`/global/app/analysis/software/gccbuild/sparc-sun-solaris2.9/sparcv9/libgcc'
make[5]: Leaving directory
`/global/app/analysis/software/gccbuild/sparc-sun-solaris2.9/sparcv9/libgcc'
make[4]: Leaving directory
`/global/app/analysis/software/gccbuild/sparc-sun-solaris2.9/libgcc'
/global/app/analysis/software/gccbuild/./gcc/xgcc
-B/global/app/analysis/software/gccbuild/./gcc/
-B/VOBS/sol9tools/gcc64/sparc-sun-solaris2.9/bin/
-B/VOBS/sol9tools/gcc64/sparc-sun-solaris2.9/lib/ -isystem
/VOBS/sol9tools/gcc64/sparc-sun-solaris2.9/include -isystem
/VOBS/sol9tools/gcc64/sparc-sun-solaris2.9/sys-include-g -O2 -O2  -g -O2
-DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -fPIC -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -fPIC -I. -I.
-I../.././gcc -I../../../gcc-4.8.2/libgcc -I../../../gcc-4.8.2/libgcc/.
-I../../../gcc-4.8.2/libgcc/../gcc -I../../../gcc-4.8.2/libgcc/../include 
-DHAVE_CC_TLS  -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
../../../gcc-4.8.2/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../../gcc-4.8.2/libgcc/libgcc2.c: In function '__muldi3':
../../../gcc-4.8.2/libgcc/libgcc2.c:549:17: internal compiler error:
Segmentation Fault
   const DWunion uu = {.ll = u};
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_muldi3.o] Error 1
make[3]: Leaving directory
`/global/app/analysis/software/gccbuild/sparc-sun-solaris2.9/libgcc'
make[2]: *** [all-stage1-target-libgcc] Error 2
make[2]: Leaving directory `/global/app/analysis/software/gccbuild'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/global/app/analysis/software/gccbuild'
make: *** [all] Error 2


Configured with:
../gcc-4.8.2/configure --prefix=/VOBS/sol9tools/gcc64
--with-as=/VOBS/sol9tools/gcc64/bin/as --with-gnu-as
--with-ld=/VOBS/sol9tools/gcc64/bin/ld --with-gnu-ld --enable-languages=c,c++
--enable-shared --with-gmp=/global/app/analysis/software/tmplibs
--with-mpfr=/global/app/analysis/software/tmplibs
--with-mpc=/global/app/analysis/software/tmplibs

build = sparc-sun-solaris2.9

# uname -a
SunOS sunims103 5.9 Generic_118558-39 sun4u sparc SUNW,Sun-Fire-V240

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

[sfilippone at uniroma2 dot it]

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

Bug ID: 60922
   Summary: [4.9 regression]  Memory leak with INTENT(OUT) CLASS
argument w/ allocatable CLASS components
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sfilippone at uniroma2 dot it

Created attachment 32653
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32653&action=edit
test case

Attached code runs fine with 4.8.2, but generates a memory leak with current
trunk, unless I explicitly add FINAL subroutines, which should not be necessary
for this simple case. Possibly 4.9.0 is affected as well. 
Symptoms similar to PR 47637. 
 fails with trunk ---
[sfilippo@epsilon IMAGING]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/gnu/4.9/libexec/gcc/x86_64-unknown-linux-gnu/4.10.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/opt/gnu/4.9
--enable-languages=c,c++,fortran --with-gmp=/usr/local/travel/GNU/gmp
--with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc
--with-cloog=/usr/local/travel/GNU/cloog : (reconfigured) ../gcc/configure
--prefix=/opt/gnu/4.9 --with-gmp=/usr/local/travel/GNU/gmp
--with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc
--with-cloog=/usr/local/travel/GNU/cloog --enable-languages=c,c++,fortran,lto
--no-create --no-recursion
Thread model: posix
gcc version 4.10.0 20140422 (experimental) (GCC) 
[sfilippo@epsilon IMAGING]$ gfortran -o test_leak_410 -O3 test_leak.f90
[sfilippo@epsilon IMAGING]$ valgrind ./test_leak_410
==2140== Memcheck, a memory error detector
==2140== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==2140== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==2140== Command: ./test_leak_410
==2140== 
 Iteration1
 Iteration2
==2140== 
==2140== HEAP SUMMARY:
==2140== in use at exit: 6,291,552 bytes in 5 blocks
==2140==   total heap usage: 32 allocs, 27 frees, 10,497,741 bytes allocated
==2140== 
==2140== LEAK SUMMARY:
==2140==definitely lost: 48 bytes in 1 blocks
==2140==indirectly lost: 2,097,152 bytes in 1 blocks
==2140==  possibly lost: 0 bytes in 0 blocks
==2140==still reachable: 4,194,352 bytes in 3 blocks
==2140== suppressed: 0 bytes in 0 blocks
==2140== Rerun with --leak-check=full to see details of leaked memory
==2140== 
==2140== For counts of detected and suppressed errors, rerun with: -v
==2140== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)



Works with 4.8.2---
[sfilippo@epsilon IMAGING]$ gfortran -v 
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/gnu/4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.2/configure --prefix=/opt/gnu/4.8.2
--enable-languages=c,c++,fortran --with-gmp=/usr/local/travel/GNU/gmp
--with-mpfr=/usr/local/travel/GNU/mpfr --with-mpc=/usr/local/travel/GNU/mpc
--with-cloog=/usr/local/travel/GNU/cloog
Thread model: posix
gcc version 4.8.2 (GCC) 
[sfilippo@epsilon IMAGING]$ gfortran -o test_leak_482 -O3 test_leak.f90
[sfilippo@epsilon IMAGING]$ valgrind ./test_leak_482
==2122== Memcheck, a memory error detector
==2122== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==2122== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==2122== Command: ./test_leak_482
==2122== 
 Iteration1
 Iteration2
==2122== 
==2122== HEAP SUMMARY:
==2122== in use at exit: 4,194,352 bytes in 3 blocks
==2122==   total heap usage: 28 allocs, 25 frees, 10,497,699 bytes allocated
==2122== 
==2122== LEAK SUMMARY:
==2122==definitely lost: 0 bytes in 0 blocks
==2122==indirectly lost: 0 bytes in 0 blocks
==2122==  possibly lost: 0 bytes in 0 blocks
==2122==still reachable: 4,194,352 bytes in 3 blocks
==2122== suppressed: 0 bytes in 0 blocks
==2122== Rerun with --leak-check=full to see details of leaked memory
==2122== 
==2122== For counts of detected and suppressed errors, rerun with: -v
==2122== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 6)

[Bug libstdc++/60921] 'final' allocators are incompatible with the Empty Base-class Optimisation

[redi at gcc dot gnu.org]

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

Bug 51365 Summary: cannot use final empty class in std::tuple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365

   What|Removed |Added

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

[Bug libstdc++/51365] cannot use final empty class in std::tuple

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #19 from Jonathan Wakely  ---
I'm closing this as fixed, I've created Bug 60921 to deal with the remaining
final allocator issues.

[Bug libstdc++/60921] New: 'final' allocators are incompatible with the Empty Base-class Optimisation

[redi at gcc dot gnu.org]

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

Bug ID: 60921
   Summary: 'final' allocators are incompatible with the Empty
Base-class Optimisation
   Product: gcc
   Version: 4.10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Depends on: 51365

+++ This bug was initially created as a clone of Bug #51365 +++

Deriving from allocators to use the EBO doesn't work if they are final:

#include 
#include 

template
struct final_allocator final : std::allocator
{
  final_allocator() = default;

  template
final_allocator(const final_allocator&) { }

  template
struct rebind { typedef final_allocator other; };
};

final_allocator a;

std::promise p(std::allocator_arg, a);

This affects the containers and most types in . See Bug 51365 comment 6
for a partial fix.

[Bug rtl-optimization/49857] Put constant switch-tables into flash

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|4.9.1   |4.10.0

[Bug c++/60920] Crash on double template header due to default template parameter

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-04-22
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
The invalid partial specialization should be rejected

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

[g...@denis-excoffier.org]

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

--- Comment #45 from Denis Excoffier  ---
(In reply to Denis Excoffier from comment #44)
> shouldn't it be possible to make it available to 4.9.0, instead of 4.9.1?
No because 4.9.0 is out.

[Bug c/60156] GCC doesn't warn about variadic main

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |4.10.0

--- Comment #2 from Marek Polacek  ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00759.html

[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Biener  ---
Author: rguenth
Date: Tue Apr 22 13:33:37 2014
New Revision: 209633

URL: http://gcc.gnu.org/viewcvs?rev=209633&root=gcc&view=rev
Log:
2014-04-22  Richard Biener  

Backport from mainline
2014-04-14  Richard Biener  

PR middle-end/55022
* fold-const.c (negate_expr_p): Don't negate directional rounding
division.
(fold_negate_expr): Likewise.

* gcc.dg/graphite/pr55022.c: New testcase.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/graphite/pr55022.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/fold-const.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c/60846] Add 128-bit integer types for general use on 32-bit/64-bit CPUs

[jirik.svoboda at seznam dot cz]

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

Jiri Svoboda  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |---

--- Comment #4 from Jiri Svoboda  ---
As an example:

jirka@omelette:/tmp> echo "__int128 i;" > test.c
jirka@omelette:/tmp> gcc -o test -m64 test.c
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64/crt1.o: In function
`_start':
/home/abuild/rpmbuild/BUILD/glibc-2.18/csu/../sysdeps/x86_64/start.S:118:
undefined reference to `main'
collect2: error: ld returned 1 exit status
jirka@omelette:/tmp> gcc -c -m64 test.c
jirka@omelette:/tmp> echo "__int128 i;" > test.c
jirka@omelette:/tmp> gcc -c -m64 test.c
jirka@omelette:/tmp> gcc -c -m32 test.c
test.c:1:1: error: ‘__int128’ is not supported for this target
 __int128 i;
 ^
jirka@omelette:/tmp> gcc --version
gcc (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]
Copyright (C) 2013 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.

jirka@omelette:/tmp> gcc -dumpmachine
x86_64-suse-linux
jirka@omelette:/tmp> 

So it works for x86_64 64-bit target, but not for 32-bit target.
And I mean I would like to have this functionality in all 32-bit and 64-bit
targets, not just in some. Since I'm developping a cross-platform network stack
which runs on Intel (32-bit, 64-bit), PowerPC (32-bit), Itanium (64-bit), ARM
(32-bit), MIPS (32-bit), etc.

[Bug tree-optimization/60849] [4.7/4.8 Regression] bogus comparison result type

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Tue Apr 22 13:31:41 2014
New Revision: 209632

URL: http://gcc.gnu.org/viewcvs?rev=209632&root=gcc&view=rev
Log:
2014-04-22  Richard Biener  

Backport from mainline
2014-04-17  Richard Biener  

PR middle-end/60849
* tree-ssa-propagate.c (valid_gimple_rhs_p): Only allow effective
boolean results for comparisons.

* g++.dg/opt/pr60849.C: New testcase.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/opt/pr60849.C
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-propagate.c

[Bug tree-optimization/60841] [4.9 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener  ---
Author: rguenth
Date: Tue Apr 22 13:29:32 2014
New Revision: 209631

URL: http://gcc.gnu.org/viewcvs?rev=209631&root=gcc&view=rev
Log:
2014-04-22   Richard Biener  

Backport from mainline
2014-04-17   Richard Biener  

PR tree-optimization/60841
* tree-vect-data-refs.c (vect_analyze_data_refs): Count stmts.
* tree-vect-loop.c (vect_analyze_loop_2): Pass down number
of stmts to SLP build.
* tree-vect-slp.c (vect_slp_analyze_bb_1): Likewise.
(vect_analyze_slp): Likewise.
(vect_analyze_slp_instance): Likewise.
(vect_build_slp_tree): Limit overall SLP tree growth.
* tree-vectorizer.h (vect_analyze_data_refs,
vect_analyze_slp): Adjust prototypes.

* gcc.dg/vect/pr60841.c: New testcase.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr60841.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-vect-data-refs.c
branches/gcc-4_9-branch/gcc/tree-vect-loop.c
branches/gcc-4_9-branch/gcc/tree-vect-slp.c
branches/gcc-4_9-branch/gcc/tree-vectorizer.h

[Bug tree-optimization/60841] [4.9 Regression] gcc: internal compiler error: Killed (program cc1) out of memory

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #17 from Richard Biener  ---
Fixed.

[Bug c++/60836] [4.7/4.8 Regression] invalid PHI argument and ICE in verify_gimple

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Apr 22 13:27:33 2014
New Revision: 209630

URL: http://gcc.gnu.org/viewcvs?rev=209630&root=gcc&view=rev
Log:
2014-04-22  Richard Biener  

Backport from mainline
2014-04-17  Richard Biener  

PR tree-optimization/60836
* tree-vect-loop.c (vect_create_epilog_for_reduction): Force
initial PHI args to be gimple values.

* g++.dg/vect/pr60836.cc: New testcase.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/vect/pr60836.cc
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-vect-loop.c

[Bug c/60819] dse1 removing not-dead insn (aliasing issue?)

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
Author: rguenth
Date: Tue Apr 22 13:26:02 2014
New Revision: 209629

URL: http://gcc.gnu.org/viewcvs?rev=209629&root=gcc&view=rev
Log:
2014-04-22  Richard Biener  

Backport from mainline
2014-04-14  Richard Biener  
Marc Glisse  

PR c/60819
* c-common.c (convert_vector_to_pointer_for_subscript): Properly
apply may-alias the scalar pointer type when applicable.

* gcc.target/i386/vec-may_alias.c: New testcase.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/vec-may_alias.c
Modified:
branches/gcc-4_9-branch/gcc/c-family/ChangeLog
branches/gcc-4_9-branch/gcc/c-family/c-common.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/60453] ICE when building chromium with -O2 and graphite

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Apr 22 13:22:32 2014
New Revision: 209628

URL: http://gcc.gnu.org/viewcvs?rev=209628&root=gcc&view=rev
Log:
2014-04-22  Richard Biener  

Backport from mainline
2014-04-14  Richard Biener  

PR tree-optimization/59817
PR tree-optimization/60453
* graphite-scop-detection.c (graphite_can_represent_scev): Complete
recursion to catch all CHRECs in the scalar evolution and restrict
the predicate for the remains appropriately.

* gfortran.dg/graphite/pr59817.f: New testcase.
* gcc.dg/graphite/pr59817-1.c: Likewise.
* gcc.dg/graphite/pr59817-2.c: Likewise.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/graphite/pr59817-1.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/graphite/pr59817-2.c
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/graphite/pr59817.f
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/graphite-scop-detection.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/59817] [4.8 Regression] ICE in extract_affine_chrec with -O2 -ftree-loop-linear

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Tue Apr 22 13:22:32 2014
New Revision: 209628

URL: http://gcc.gnu.org/viewcvs?rev=209628&root=gcc&view=rev
Log:
2014-04-22  Richard Biener  

Backport from mainline
2014-04-14  Richard Biener  

PR tree-optimization/59817
PR tree-optimization/60453
* graphite-scop-detection.c (graphite_can_represent_scev): Complete
recursion to catch all CHRECs in the scalar evolution and restrict
the predicate for the remains appropriately.

* gfortran.dg/graphite/pr59817.f: New testcase.
* gcc.dg/graphite/pr59817-1.c: Likewise.
* gcc.dg/graphite/pr59817-2.c: Likewise.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/graphite/pr59817-1.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/graphite/pr59817-2.c
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/graphite/pr59817.f
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/graphite-scop-detection.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c++/60920] Crash on double template header due to default template parameter

[a71104 at gmail dot com]

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

--- Comment #2 from a71104 at gmail dot com ---
Additional: I'm using the `-Wall` and `--std=c++11` compiler options.

[Bug c++/60920] Crash on double template header due to default template parameter

[a71104 at gmail dot com]

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

--- Comment #1 from a71104 at gmail dot com ---
Sorry, I formatted the code like I was posting to GitHub in Markdown. :P

[Bug tree-optimization/60823] [4.9/4.10 Regression] ICE in gimple_expand_cfg, at cfgexpand.c:5644

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.10.0, 4.9.1
 Resolution|--- |FIXED

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

[Bug c++/60920] New: Crash on double template header due to default template parameter

[a71104 at gmail dot com]

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

Bug ID: 60920
   Summary: Crash on double template header due to default
template parameter
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a71104 at gmail dot com

```C++

template
struct x {};

template
template
struct x {};

int main() {
x<10, double> x1;
return 0;
}

```


It doesn't crash if I remove the default value `double` for the second template
argument, at the first line.

[Bug tree-optimization/60823] [4.9/4.10 Regression] ICE in gimple_expand_cfg, at cfgexpand.c:5644

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 22 13:16:31 2014
New Revision: 209626

URL: http://gcc.gnu.org/viewcvs?rev=209626&root=gcc&view=rev
Log:
PR tree-optimization/60823
* omp-low.c (ipa_simd_modify_function_body): Go through
all SSA_NAMEs and for those refering to vector arguments
which are going to be replaced adjust SSA_NAME_VAR and,
if it is a default definition, change it into a non-default
definition assigned at the beginning of function from new_decl.
(ipa_simd_modify_stmt_ops): Rewritten.
* tree-dfa.c (set_ssa_default_def): When removing default def,
check for NULL loc instead of NULL *loc.

* c-c++-common/gomp/pr60823-1.c: New test.
* c-c++-common/gomp/pr60823-2.c: New test.
* c-c++-common/gomp/pr60823-3.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/gomp/pr60823-1.c
branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/gomp/pr60823-2.c
branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/gomp/pr60823-3.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/omp-low.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-dfa.c

[Bug middle-end/60281] Address Sanitizer triggers alignment fault in ARM machines

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 22 13:15:24 2014
New Revision: 209625

URL: http://gcc.gnu.org/viewcvs?rev=209625&root=gcc&view=rev
Log:
PR middle-end/60281
* asan.c (asan_emit_stack_protection): Force the base to align to
appropriate bits if STRICT_ALIGNMENT.  Set shadow_mem align to
appropriate bits if STRICT_ALIGNMENT.
* cfgexpand.c (expand_stack_vars): Set base_align appropriately
when asan is on.
(expand_used_vars): Leave a space in the stack frame for alignment
if STRICT_ALIGNMENT.

Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/asan.c
branches/gcc-4_9-branch/gcc/cfgexpand.c

[Bug tree-optimization/60844] [4.9 Regression] ICE in reassoc_stmt_dominates_stmt_p

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.9.1
 Resolution|--- |FIXED

--- Comment #6 from Jakub Jelinek  ---
Fixed also for 4.9.1.

[Bug tree-optimization/60844] [4.9 Regression] ICE in reassoc_stmt_dominates_stmt_p

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 22 13:06:55 2014
New Revision: 209624

URL: http://gcc.gnu.org/viewcvs?rev=209624&root=gcc&view=rev
Log:
Backported from mainline
2014-04-16  Jakub Jelinek  

PR tree-optimization/60844
* tree-ssa-reassoc.c (reassoc_remove_stmt): New function.
(propagate_op_to_single_use, remove_visited_stmt_chain,
linearize_expr, repropagate_negates, reassociate_bb): Use it
instead of gsi_remove.

* gcc.dg/pr60844.c: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/pr60844.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/tree-ssa-reassoc.c

[Bug c++/51424] [C++11] G++ should diagnose self-delegating constructors

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|4.9.1   |4.9.0

--- Comment #6 from Jakub Jelinek  ---
Then it should have been closed months ago.

[Bug rtl-optimization/60901] [4.8/4.9/4.10 Regression] ICE: SIGSEGV in add_to_deps_list with -fsel-sched-pipelining-outer-loops

[abel at gcc dot gnu.org]

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

--- Comment #2 from Andrey Belevantsev  ---
I'm on Easter vacation this week, will take a look after that.

[Bug gcov-profile/60897] Mangled function name in warning during -fprofile-use phase of Firefox build

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Right.  IPA-SRA however uses ipa_modify_formal_parameters in ipa-prop
to manipulate parameters which des not reset DECL_LANG_SPECIFIC.  And
it probably should because this means it can currently probably
trigger some variant of PR 60002.

So, if it passes tests, would the following be OK for trunk and the
4.9 branch? 

--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -3650,6 +3650,7 @@ ipa_modify_formal_parameters (tree fndecl,
ipa_parm_adjustment_vec adjustments)

   TREE_TYPE (fndecl) = new_type;
   DECL_VIRTUAL_P (fndecl) = 0;
+  DECL_LANG_SPECIFIC (fndecl) = NULL;
   otypes.release ();
   oparms.release ();
 }

[Bug tree-optimization/60895] [4.8/4.9/4.10 Regression] error: address taken, but ADDRESSABLE bit not set

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
We copy TREE_ADDRESSABLE improperly in declare_return_variable with
return_slot not being a decl.  I have a patch.

[Bug c++/51424] [C++11] G++ should diagnose self-delegating constructors

[ville.voutilainen at gmail dot com]

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

--- Comment #5 from Ville Voutilainen  ---
(In reply to Jakub Jelinek from comment #4)
> GCC 4.9.0 has been released

Well, shouldn't this bug be closed, then? The patch Paolo wrote was applied and
shipped in 4.9.0, so this is already in, no need to change the milestone to
4.9.1.

[Bug c++/60894] [4.7/4.8/4.9/4.10 Regression] Use of redundant struct keyword in virtual function prototype combined with using statement causes compilation error

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Reduced (whether the function is virtual or not is irrelevant):

struct B
{
  struct S {};
};

struct D : B
{
  using B::S;
  void doIt(struct S&);
};

void D::doIt(struct S&)
{
}

[Bug c++/60894] [4.7/4.8/4.9/4.10 Regression] Use of redundant struct keyword in virtual function prototype combined with using statement causes compilation error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||fabien at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
The regression was caused by r181359

Fabien, could you take a look please? I think the code is valid.

[Bug tree-optimization/60891] [4.9/4.10 Regression] ICE: SIGSEGV (Invalid write/read) in pre_and_rev_post_order_compute_fn with -O -fno-tree-ch -fno-tree-cselim -fno-tree-dominator-opts

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
loop_optimizer_init (AVOID_CFG_MODIFICATIONS); ends up adding a basic-block. 
Oops.  I have a patch.

[Bug middle-end/60080] gcc.dg/vect/vect-nop-move.c FAILs

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger  ---
aehm...
actually this issue is already fixed,
but I can't set the status to FIXED.

[Bug c++/59823] [4.7/4.8 Regression] conversion operator to const X& causes copy-construction of temporary

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.9.0
   Target Milestone|4.9.1   |4.9.0
  Known to fail|4.9.0   |

--- Comment #5 from Jonathan Wakely  ---
Resetting target milestone, the fix is already in 4.9.0

[Bug testsuite/55440] Plugin tests is compiled with wrong CFLAGS

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.9.0   |4.9.1

--- Comment #3 from Jakub Jelinek  ---
GCC 4.9.0 has been released

[Bug rtl-optimization/57032] [4.9/4.10 Regression]: internal compiler error: Max. number of generated reload insns per insn is achieved (90)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.9.0   |4.9.1

--- Comment #4 from Jakub Jelinek  ---
GCC 4.9.0 has been released

[Bug bootstrap/60644] [4.9/4.10 Regression] Build of i686-pc-linux-android is broken

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.9.0   |4.9.1

--- Comment #11 from Jakub Jelinek  ---
GCC 4.9.0 has been released

[Bug tree-optimization/60577] [4.7/4.8 Regression] inefficient FDO instrumentation code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.9.0   |4.9.1

--- Comment #9 from Jakub Jelinek  ---
GCC 4.9.0 has been released

[Bug c++/59823] [4.7/4.8 Regression] conversion operator to const X& causes copy-construction of temporary

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.9.0   |4.9.1

--- Comment #4 from Jakub Jelinek  ---
GCC 4.9.0 has been released

[Bug libstdc++/57925] discrete_distribution can be improved to O(1) per sampling

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.9.0   |4.9.1

--- Comment #4 from Jakub Jelinek  ---
GCC 4.9.0 has been released

[Bug c/59984] OpenMP and Cilk Plus SIMD pragma makes loop incorrect

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.9.0   |4.9.1

--- Comment #9 from Jakub Jelinek  ---
GCC 4.9.0 has been released

[Bug sanitizer/59009] libsanitizer merge from upstream r191666 breaks bootstrap on powerpc64-linux

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.9.0   |4.9.1

--- Comment #41 from Jakub Jelinek  ---
GCC 4.9.0 has been released

[Bug go/59452] net FAILs on Solaris 9

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.9.0   |4.9.1

--- Comment #1 from Jakub Jelinek  ---
GCC 4.9.0 has been released