[Bug tree-optimization/60116] New: wrong code at -Os on x86_64-linux-gnu in 32-bit mode

[su at cs dot ucdavis.edu]

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

Bug ID: 60116
   Summary: wrong code at -Os on x86_64-linux-gnu in 32-bit mode
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The current gcc trunk and 4.8.x mis-compile the following code on x86_64-linux
at -Os in 32-bit mode (but not 64-bit).

This is a regression from 4.7.x.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20140207 (experimental) [trunk revision 207610] (GCC) 
$ 
$ gcc-trunk -m32 -O1 small.c; a.out
1
$ gcc-trunk -m64 -Os small.c; a.out
1
$ gcc-4.7.3 -m32 -Os small.c; a.out
1
$ 
$ gcc-trunk -m32 -Os small.c; a.out
0
$ gcc-4.8.2 -m32 -Os small.c; a.out
0
$ 


-


int printf (const char *, ...);

int a, b, c, d = 1, e, f = 1, h, i, k;
char g, j;

int
fn1 ()
{
  int l;
  e = 0;
  c = 0;
  for (;;)
{
  k = a && b;
  j = k * 54;
  g = j * 147;
  l = ~g + (long long) e && 1;
  if (d)
c = l;
  else
h = i = l * 9UL;
  if (f)
return 0;
}
}

int
main ()
{
  fn1 ();
  printf ("%d\n", c);
  return 0;
}

[Bug c++/60113] Internal compiler error

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(In reply to lmat from comment #0)
> Attached is the output from command line along with the
> preprocessed code that I was trying to compile.

Looks like you forgot to attach it?

> Please let me know if I can provide any more information!

http://gcc.gnu.org/bugs/
We also want to know the command line, the target system, etc.

[Bug tree-optimization/60115] wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

--- Comment #1 from Zhendong Su  ---
The reported testcase seems to reveal an independent issue: GCC does warn the
out-of-bound array access at -Os and above, but not at -O0 and -O1, while clang
warns at all optimization levels. 

$ gcc-trunk -Warray-bounds -O0 small.c
$ gcc-trunk -Warray-bounds -O1 small.c 
$ 
$ gcc-trunk -Warray-bounds -Os small.c
small.c: In function ‘main’:
small.c:8:10: warning: array subscript is above array bounds [-Warray-bounds]
 if (b[613])
  ^
$
$ clang-trunk -Warray-bounds -O0 small.c
small.c:8:9: warning: array index 613 is past the end of the array (which
contains 1 element) [-Warray-bounds]
if (b[613])
^ ~~~
small.c:1:1: note: array 'b' declared here
int a, b[1];
^
1 warning generated.
$

[Bug tree-optimization/60115] New: wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 60115
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu

The current gcc trunk mis-compiles the following code on x86_64-linux-gnu at
-O3 in both 32-bit and 64-bit modes.

This is a regression from 4.8.x.

Although the code has an out-of-bound array access, it isn't executed, so the
code is valid. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20140207 (experimental) [trunk revision 207610] (GCC) 
$ 
$ gcc-trunk -O2 small.c; a.out
$ gcc-4.8 -O3 small.c; a.out
$ 
$ gcc-trunk -O3 small.c; a.out
Segmentation fault (core dumped)
$ 


---


int a, b[1];

int
main ()
{
 lbl:
  for (; a; a--)
if (b[613])
  goto lbl;

  return 0;
}

[Bug c/60114] New: Incorrect column number for -pedantic and -Wconversion

[chengniansun at gmail dot com]

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

Bug ID: 60114
   Summary: Incorrect column number for -pedantic and -Wconversion
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com

The column number in the warnings by -pedantic and -Wconversion is not precise. 


$: cat short.c 
int l[9] = {0xD051BC10L,0x976F2A4DL,0x976F2A4DL};
$: gcc-trunk -c -pedantic short.c
short.c:1:1: warning: overflow in implicit constant conversion [-Woverflow]
 int l[9] = {0xD051BC10L,0x976F2A4DL,0x976F2A4DL};
 ^
short.c:1:1: warning: overflow in implicit constant conversion [-Woverflow]
short.c:1:1: warning: overflow in implicit constant conversion [-Woverflow]
$: gcc-trunk -c -Wconversion short.c
short.c:1:1: warning: conversion to ‘int’ alters ‘long int’ constant value
[-Wconversion]
 int l[9] = {0xD051BC10L,0x976F2A4DL,0x976F2A4DL};
 ^
short.c:1:1: warning: conversion to ‘int’ alters ‘long int’ constant value
[-Wconversion]
short.c:1:1: warning: conversion to ‘int’ alters ‘long int’ constant value
[-Wconversion]

[Bug c++/60113] New: Internal compiler error

[dartmetrash at gmail dot com]

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

Bug ID: 60113
   Summary: Internal compiler error
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dartmetrash at gmail dot com

I would love to give more information, but the compiler gave me none that I can
tell. Attached is the output from command line along with the preprocessed code
that I was trying to compile.

Please let me know if I can provide any more information!

[Bug preprocessor/56824] [4.8 regression] pragma GCC diagnostic push/pop fail with GCC diagnostic ignored "-Waggregate-return"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||4.9.0
Summary|[4.8/4.9 regression] pragma |[4.8 regression] pragma GCC
   |GCC diagnostic push/pop |diagnostic push/pop fail
   |fail with GCC diagnostic|with GCC diagnostic ignored
   |ignored |"-Waggregate-return"
   |"-Waggregate-return"|
  Known to fail|4.9.0   |

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/60077] [4.9 regression] gcc.target/i386/pr35767-5.c FAILs

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb  7 23:55:24 2014
New Revision: 207622

URL: http://gcc.gnu.org/viewcvs?rev=207622&root=gcc&view=rev
Log:
PR target/60077
* gcc.target/i386/pr60077-1.c: New test.
* gcc.target/i386/pr60077-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr60077-1.c
trunk/gcc/testsuite/gcc.target/i386/pr60077-2.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ipa/60026] [4.8 Regression] ICE at -O3 on valid code (with the optimize pragma) on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb  7 23:54:17 2014
New Revision: 207621

URL: http://gcc.gnu.org/viewcvs?rev=207621&root=gcc&view=rev
Log:
PR ipa/60026
* ipa-cp.c (determine_versionability): Fail at -O0
or __attribute__((optimize (0))) or -fno-ipa-cp functions.
* tree-sra.c (ipa_sra_preliminary_function_checks): Similarly.

Revert:
2014-02-04  Jakub Jelinek  

PR ipa/60026
* tree-inline.c (copy_forbidden): Fail for
__attribute__((optimize (0))) functions.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-cp.c
trunk/gcc/tree-inline.c
trunk/gcc/tree-sra.c

[Bug fortran/59906] [4.7/4.8 Regression] error: size of variable '' is too large

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #13 from Paul Thomas  ---
Fixed on 4.7, 4.8 and 4.9

Thanks for the report

Paul

[Bug fortran/59906] [4.7/4.8 Regression] error: size of variable '' is too large

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  ---
Author: pault
Date: Fri Feb  7 23:29:44 2014
New Revision: 207617

URL: http://gcc.gnu.org/viewcvs?rev=207617&root=gcc&view=rev
Log:
2014-02-08  Paul Thomas  

PR fortran/59906
* trans-array.c (gfc_add_loop_ss_code): In the case of character
SS_REFERENCE, use gfc_conv_string_parameter to ensure that a
pointer to the string is stored.
* trans-expr.c (gfc_conv_expr_reference): Likewise, use
gfc_conv_string_parameter to ensure that a pointer to is passed
to the elemental function.

2014-02-08  Paul Thomas  

PR fortran/59906
* gfortran.dg/elemental_subroutine_9.f90 : New test

Added:
   
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_9.f90
Modified:
branches/gcc-4_7-branch/gcc/fortran/ChangeLog
branches/gcc-4_7-branch/gcc/fortran/trans-array.c
branches/gcc-4_7-branch/gcc/fortran/trans-expr.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com,
   ||richard.guenther at gmail dot 
com

--- Comment #24 from Jeffrey A. Law  ---
This is a mess.

As noted in the other comments, we're considering a cc0-setter as a potentially
trapping insn.  As a result the cc0-setter and cc0-consumer end up in different
blocks.

That's bad on so many levels and "fixing" it by hacking up fold_rtx like this
just papers over the fundamental problem (though I must admit from a pragmatic
standpoint, it's pretty effective).

One could argue that the CFG building code could be tweaked so that a
cc0-setter is never considered the end of a block.  The downside of that is
we're lying to the compiler about the true nature of the CFG.  But that little
white lie may be acceptable.  I haven't looked into how ugly that would be to
implement.

One could also argue that this is an inherent flaw in cc0 targets and that any
unconverted backend should be converted to deprecated.  There are certainly
better mechanisms for dealing with condition codes than the old cc0 nonsense. 
But I have neither the time nor the interest in converting the m68k backend. 
If we went this route it's a good bet the m68k backend would be deprecated.

In the end I'm at a loss about the best direction to take.  Adding Richi on cc
for his thoughts.

[Bug c++/60112] bogus error: array subscript is above array bounds

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
It works for me with 4.9.0 20140129.  Maybe you should update the version of
4.9.

[Bug target/40977] [4.7/4.8/4.9 regression] problem with code like this: res = ((uint64_t)resh << 32) | resl;

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
Fixed by trunk commit.

[Bug target/40977] [4.7/4.8/4.9 regression] problem with code like this: res = ((uint64_t)resh << 32) | resl;

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Fri Feb  7 22:35:49 2014
New Revision: 207615

URL: http://gcc.gnu.org/viewcvs?rev=207615&root=gcc&view=rev
Log:
PR target/40977
* config/m68k/m68k.md (ashldi_extsi): Turn into a
define_insn_and_split.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/m68k/m68k.md

[Bug fortran/60110] internal compiler error

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl  ---
On Fri, Feb 07, 2014 at 10:11:17PM +, dominiq at lps dot ens.fr wrote:
> It could be a duplicate of pr52332 (ICE at the same place).
> 

It might be.  I've recall other problems of this nature.  Anyway,
here's a further reduction in the testcase

module check_sem

  implicit  none

  type check_logical
logical  ok
  end type

  interface  assignment( = )
module procedure check_logical_to_logical
module procedure logical_to_check_logical
  end interface

  interface check
  module procedure check_character1_rank1
  end interface

  interface operator(**)
function character_power_sc(l, r)
  character(*), intent(in) :: l, r
  intrinsic  len
  character(len(l)) :: character_power_sc
end function  character_power_sc
  end interface

  contains

subroutine check_logical_to_logical(l, r)
  logical, intent(out) :: l
  type( check_logical ), intent(in) :: r
  l = r % ok
end subroutine check_logical_to_logical

subroutine logical_to_check_logical(l, r)
  type( check_logical ), intent(out) :: l
  logical, intent(in) :: r
  l % ok = r
end subroutine logical_to_check_logical

   function check_character1_rank1 (expected, computed)
  character(*,1), dimension(:), intent(in) ::  expected, computed
  type (check_logical) :: check_character1_rank1
  intrinsic all
  check_character1_rank1 = all(computed == expected)
   end function check_character1_rank1

end module check_sem

program foo
  use check_sem
  implicit none
  logical ok
  character :: y(3) = (/ 'a', 'b', 'c' /)
  ok = check(y, (/ y(1)**y(1), y(2)**y(2), y(3)**y(3) /))
end program foo

[Bug fortran/60110] internal compiler error

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
It could be a duplicate of pr52332 (ICE at the same place).

[Bug fortran/60110] internal compiler error

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-07
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Confirmed for 4.7.4, 4.8.3, and trunk.

[Bug target/59762] [4.9 Regression] func-vararg-mixed.c fails on PowerPC starting with revision 204079

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

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

--- Comment #1 from Pat Haugen  ---
Fixed with pr60032 fix.

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

[Bug target/60032] [4.9 regression] ICE in reload_cse_simplify_operands, at postreload.c:411

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #7 from Pat Haugen  ---
*** Bug 59762 has been marked as a duplicate of this bug. ***

[Bug fortran/60110] internal compiler error

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Walt Brainerd from comment #0)
> Created attachment 32079 [details]
> source file gfortran_bug.f90
> 
> Sorry, I am not sure where to begin to cut this down.
> I hope you can figure it out from the error msg.
> 
> This also fails the same way on the TDM build.
> 
> $ gfortran -c gfortran_bug.f90
> gfortran_bug.f90: In function 'r701t735_array':
> gfortran_bug.f90:2282:0: internal compiler error: in gfc_get_symbol_decl, at

The line number 2282 points to a problem with the character type.  Here's 
a reduced test case from your code:


module check_sem

  implicit  none

  type check_logical
logical  ok
  end type

  interface  operator( .and. )
module procedure  logical_and_check_logical
  end interface

  interface  operator( .not. )
module procedure  not_check_logical
  end interface

  interface  assignment( = )
module procedure  check_logical_to_logical, logical_to_check_logical
  end interface

  interface  check
  module procedure check_character1_rank1
  end interface

  contains

subroutine check_logical_to_logical( l, r )
  logical, intent(out) :: l
  type( check_logical ), intent(in) :: r
  l = r % ok
end subroutine check_logical_to_logical

subroutine  logical_to_check_logical( l, r )
  type( check_logical ), intent(out) :: l
  logical, intent(in) :: r
  l % ok = r
end subroutine logical_to_check_logical

logical function  logical_and_check_logical( l, r )
  logical, intent(in) :: l
  type( check_logical ), intent(in) :: r
  logical_and_check_logical = l .and. r % ok
end function logical_and_check_logical

logical function  not_check_logical( r )
  type( check_logical ), intent(in) :: r
  not_check_logical = .not. r % ok
end function not_check_logical

   function check_character1_rank1 (expected, computed, location)
  character(*), intent(in), optional :: location
  character(*,1), dimension(:), intent(in) ::  expected, computed
  type (check_logical) :: check_character1_rank1
  intrinsic all, present
  check_character1_rank1 = all(computed == expected)
   end function check_character1_rank1

end module check_sem

module  overloads

  interface  operator( ** )
function  character_power_sc(l, r)
  character(*), intent(in) :: l, r
  intrinsic  len
  character(len(l)) :: character_power_sc
end function  character_power_sc

function  character_power_array(l, r)
  character(*), intent(in), dimension(3) :: l, r
  intrinsic  len
  character(len(l)), dimension(3) :: character_power_array
end function  character_power_array
  end interface

end module overloads

program foo

  use check_sem
  use overloads

  implicit none
  logical  :: ok = .true.

  character, parameter, dimension(3) :: ch_c = (/ 'a', 'b', 'c' /)
  character  chv(3), cho1(3), cho2(3)

  cho1 = (ch_c)
  chv = cho1 ** ch_c
  ok = ok .and. check(chv, &
  (/ cho1(1)**ch_c(1), cho1(2)**ch_c(2), cho1(3)**ch_c(3) /), &
  'mult-operand-16')

end program foo

[Bug fortran/60066] Bad elemental invocation of non-scalar base object

[mikael.morin at sfr dot fr]

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

--- Comment #10 from mikael.morin at sfr dot fr ---
Le 07/02/2014 19:18, Paul Richard Thomas a écrit :
> Dear All,
> 
> I propose to add the attached to the testsuite.  It is the testcase
> from PR60066, which was fixed by the patch for PR59066.
> 
> OK for trunk, 4.8 and 4.7?
> 
Yes, sure.

Mikael.

[Bug c++/60112] New: bogus error: array subscript is above array bounds

[david.abdurachmanov at gmail dot com]

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

Bug ID: 60112
   Summary: bogus error: array subscript is above array bounds
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david.abdurachmanov at gmail dot com

GCC pre-4.9.0 (r206686), no issues on 4.6.2, 4.7.2, and 4.8.1. I found that if
I mark `get_size' as inline or constexpr errors are gone. If I keep `nFaces'
uninitialized it also complains, but if I set it explicitly to some number
(e.g., 0,..,) it's fine. Even commenting out such line (49) as

lp += VV(tanDistToFace[iFDest]);

removes the errors.

I tried removing more mass from the test case, but it also removes the errors.

Doesn't work with -O2, but works fine with -O0, -O1, -O3, -Os, and -Og.

### COMPILE ###

c++ -c -O2 -std=c++11 -Werror=array-bounds -fdiagnostics-show-option -fPIC
test2.cpp

### ERRORS ###

test2.cpp: In function 'void abc()':
test2.cpp:43:37: error: array subscript is above array bounds
[-Werror=array-bounds]
 iFDestSorted[nDestSorted - i - 1] = iFDestSorted[iMax];
 ^
test2.cpp:44:22: error: array subscript is above array bounds
[-Werror=array-bounds]
 iFDestSorted[iMax] = iTmp;
  ^
cc1plus: some warnings being treated as errors

### TEST CASE ###

struct GP {
  double mx, my, mz;
  GP (double x, double y, double z) : mx(x), my(y), mz(z) { };
};
typedef struct GP GP;

void do_something(const GP& n) { }

struct VV {
  double mx;
  VV (double x) : mx(x) { };
};
typedef struct VV VV;

struct PP {
  double mx;
  PP (double x) : mx(x) { };
  double x() { return mx; };
  PP& operator+=(const VV& rhs) { mx += rhs.mx; return *this; };
};
typedef struct PP PP;

int get_size() { return 0; };

void abc() {
  double tanDistToFace[6] = {0,0,0,0,0,0};
  unsigned int iFDestSorted[6] = {0,0,0,0,0,0};
  unsigned int nDestSorted = 0;

  unsigned int nFaces = get_size();
  for (unsigned int iFace = 0; iFace < nFaces; ++iFace) {
nDestSorted++;
  }

  for (unsigned int i = 0; i < nDestSorted; ++i) {
unsigned int iMax = nDestSorted - i - 1;
for (unsigned int j=0; j < nDestSorted-i; ++j) {
  if (tanDistToFace[iFDestSorted[j]] > tanDistToFace[iFDestSorted[iMax]]) {
iMax = j;
  }
}
unsigned int iTmp = iFDestSorted[nDestSorted - i - 1];
iFDestSorted[nDestSorted - i - 1] = iFDestSorted[iMax];
iFDestSorted[iMax] = iTmp;
  }

int iFDest = iFDestSorted[0];
PP lp(0);
lp += VV(tanDistToFace[iFDest]);
GP gp(lp.x(), lp.x(), lp.x());
do_something(gp);
}

[Bug target/60111] New: [SH] ICE compiling Newlib (4.8.2)

[lsebald1 at umbc dot edu]

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

Bug ID: 60111
   Summary: [SH] ICE compiling Newlib (4.8.2)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lsebald1 at umbc dot edu

Created attachment 32081
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32081&action=edit
Preprocessed source file exhibiting the ICE.

When building a cross-compiler from armv6l-unknown-linux-gnueabihf (A Raspberry
Pi running Raspbian) to sh-elf, I'm running into an internal compiler error
when compiling part of Newlib. Here is the backtrace that is generated:

sh-elf-gcc
-B/mnt/usbhdd1/toolchain/kos/utils/dc-chain/build-newlib-sh-elf-2.0.0/sh-elf/m4-nofpu/newlib/
-isystem
/mnt/usbhdd1/toolchain/kos/utils/dc-chain/build-newlib-sh-elf-2.0.0/sh-elf/m4-nofpu/newlib/targ-include
-isystem
/mnt/usbhdd1/toolchain/kos/utils/dc-chain/newlib-2.0.0/newlib/libc/include
-B/mnt/usbhdd1/toolchain/kos/utils/dc-chain/build-newlib-sh-elf-2.0.0/sh-elf/m4-nofpu/libgloss/sh
-L/mnt/usbhdd1/toolchain/kos/utils/dc-chain/build-newlib-sh-elf-2.0.0/sh-elf/m4-nofpu/libgloss/libnosys
-L/mnt/usbhdd1/toolchain/kos/utils/dc-chain/newlib-2.0.0/libgloss/sh  -m4-nofpu
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"2.0.0\" -DPACKAGE_STRING=\"newlib\ 2.0.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I../../../../../../newlib-2.0.0/newlib/libc/stdlib
-DREENTRANT_SYSCALLS_PROVIDED -DMALLOC_PROVIDED -DABORT_PROVIDED -DHAVE_FCNTL
-ffunction-sections -fdata-sections -fno-builtin  -g -O2  -m4-nofpu -c -o
lib_a-lrand48.o `test -f 'lrand48.c' || echo
'../../../../../../newlib-2.0.0/newlib/libc/stdlib/'`lrand48.c
../../../../../../newlib-2.0.0/newlib/libc/stdlib/lrand48.c: In function
‘_lrand48_r’:
../../../../../../newlib-2.0.0/newlib/libc/stdlib/lrand48.c:24:1: internal
compiler error: in gen_ashift, at config/sh/sh.c:3746
 }
 ^
0x5a33db gen_ashift
../../gcc-4.8.2/gcc/config/sh/sh.c:3746
0x5a358f gen_shifty_hi_op(int, rtx_def**)
../../gcc-4.8.2/gcc/config/sh/sh.c:3874
0x5a87ff gen_shl_and(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
../../gcc-4.8.2/gcc/config/sh/sh.c:4185
0x5f105f gen_split_912(rtx_def*, rtx_def**)
../../gcc-4.8.2/gcc/config/sh/sh.md:5173
0x222a6f try_split(rtx_def*, rtx_def*, int)
../../gcc-4.8.2/gcc/emit-rtl.c:3562
0x382b47 split_insn
../../gcc-4.8.2/gcc/recog.c:2836
0x38709f split_all_insns()
../../gcc-4.8.2/gcc/recog.c:2926
0x38715b rest_of_handle_split_after_reload
../../gcc-4.8.2/gcc/recog.c:3832
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

I have tried with both GCC versions available on the host OS' package manager
(Debian 4.6.3-14+rpi1, and Debian 4.7.2-5+rpi1) and have the same ICE with both
of them. This may actually be a host-related bug, rather than a target-related
bug, as the ICE does not occur when building a cross-compiler on Darwin on
x86-64.

Preprocessed source code of the file exhibiting the ICE is attached.

[Bug c/60083] Duplicate conversion warnings from negative integer to unsigned type (gcc-4.3 emits only one warning)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-07
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Marek Polacek  ---
Yeah, I bet we'll have tons of those ;/.

[Bug c/60083] Duplicate conversion warnings from negative integer to unsigned type (gcc-4.3 emits only one warning)

[chengniansun at gmail dot com]

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

--- Comment #1 from Chengnian Sun  ---
I think the following case is similar to the reported case. The only difference
is the message content. The following case also triggers "gcc -O0" to emit two
duplicate warnings. But "gcc -O1" emits only one warning.

$: cat s.c
extern short fn2(short, short);
unsigned long g;
void fn1() {
  int const l = 0;
  fn2(((g = l != 0) < 10LL) | 91608LL, 0);
}
$: gcc-trunk -c -Wconversion -std=c99 s.c
s.c: In function ‘fn1’:
s.c:5:7: warning: conversion to ‘short int’ alters ‘long long int’ constant
value [-Wconversion]
   fn2(((g = l != 0) < 10LL) | 91608LL, 0);
   ^
s.c:5:7: warning: conversion to ‘short int’ alters ‘long long int’ constant
value [-Wconversion]
$: gcc-trunk -c -Wconversion -std=c99 s.c -O1
s.c: In function ‘fn1’:
s.c:5:7: warning: conversion to ‘short int’ from ‘long long int’ may alter its
value [-Wconversion]
   fn2(((g = l != 0) < 10LL) | 91608LL, 0);
   ^
$:

[Bug fortran/59906] [4.7/4.8 Regression] error: size of variable '' is too large

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas  ---
Author: pault
Date: Fri Feb  7 21:15:37 2014
New Revision: 207613

URL: http://gcc.gnu.org/viewcvs?rev=207613&root=gcc&view=rev
Log:
2014-02-07  Paul Thomas  

PR fortran/59906
* trans-stmt.c (gfc_add_loop_ss_code): In the case of character
SS_REFERENCE, use gfc_conv_string_parameter to ensure that a
pointer to the string is stored.
* trans-expr.c (gfc_conv_expr_reference): Likewise, use
gfc_conv_string_parameter to ensure that a pointer to is passed
to the elemental function.

2014-02-07  Paul Thomas  

PR fortran/59906
* gfortran.dg/elemental_subroutine_9.f90 : New test

Added:
   
branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/elemental_subroutine_9.f90
Modified:
branches/gcc-4_8-branch/gcc/fortran/ChangeLog
branches/gcc-4_8-branch/gcc/fortran/trans-array.c
branches/gcc-4_8-branch/gcc/fortran/trans-expr.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug libgcc/58710] HAVE_GETIPINFO is incorrectly set on Mac OS X 10.4

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Feb  7 21:10:47 2014
New Revision: 207611

URL: http://gcc.gnu.org/viewcvs?rev=207611&root=gcc&view=rev
Log:
PR target/58710
* configure.ac: Use AC_LINK_IFELSE in check for
_Unwind_GetIPInfo.
* configure: Regenerate.

Modified:
branches/gcc-4_8-branch/libbacktrace/ChangeLog
branches/gcc-4_8-branch/libbacktrace/Makefile.in
branches/gcc-4_8-branch/libbacktrace/configure
branches/gcc-4_8-branch/libbacktrace/configure.ac

[Bug libgcc/58710] HAVE_GETIPINFO is incorrectly set on Mac OS X 10.4

[ian at gcc dot gnu.org]

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

--- Comment #4 from ian at gcc dot gnu.org  ---
Author: ian
Date: Fri Feb  7 21:10:55 2014
New Revision: 207612

URL: http://gcc.gnu.org/viewcvs?rev=207612&root=gcc&view=rev
Log:
PR target/58710
* configure.ac: Use AC_LINK_IFELSE in check for
_Unwind_GetIPInfo.
* configure: Regenerate.

Modified:
trunk/libbacktrace/ChangeLog
trunk/libbacktrace/Makefile.in
trunk/libbacktrace/configure
trunk/libbacktrace/configure.ac

[Bug target/59927] [4.9 Regression] ICE sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or subtarget optimization implying it

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rth at gcc dot gnu.org

--- Comment #6 from Richard Henderson  ---
Created attachment 32080
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32080&action=edit
testing patch

Here's a patch that seems altogether too straightforward.

It suppresses the incorrect first adjustment mentioned in the previous
comment while retaining the reg_parm_stack_space adjust.

I also tested the obvious 5 argument call and see

subq$8, %rsp
pushq$4
subq$32, %rsp
movl$3, %r9d
movl$2, %r8d
movl$1, %edx
movl$0, %ecx
callbaz

which seems inefficient, but is also correct.

I'll attempt to test this at some point this weekend, but I'm not
currently in a position to build on x86_64 windows.  Kai, can you
fire something off?

[Bug target/59927] [4.9 Regression] ICE sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or subtarget optimization implying it

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #5 from Richard Henderson  ---
There's definitely a calls.c bug.

We allocate 24 bytes of stack at line 2973, to make up the 32-byte preferred
alignment from the 8 bytes that we "pushed".  Except that we shouldn't pushing
any bytes at all.

Then we allocate 32 bytes of stack at line 3111 to allocate all the space for
the arguments passed in registers.

Then we ICE because (24+32) % 32 != 0.

[Bug fortran/60110] internal compiler error

[walt.brainerd at gmail dot com]

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

Walt Brainerd  changed:

   What|Removed |Added

 CC||walt.brainerd at gmail dot com

--- Comment #1 from Walt Brainerd  ---
OK, now I see the attachment. Sorry.

[Bug fortran/60110] New: internal compiler error

[walt.brainerd at gmail dot com]

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

Bug ID: 60110
   Summary: internal compiler error
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walt.brainerd at gmail dot com

Created attachment 32079
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32079&action=edit
source file gfortran_bug.f90

Sorry, I am not sure where to begin to cut this down.
I hope you can figure it out from the error msg.

This also fails the same way on the TDM build.

$ gfortran -c gfortran_bug.f90
gfortran_bug.f90: In function 'r701t735_array':
gfortran_bug.f90:2282:0: internal compiler error: in gfc_get_symbol_decl, at
for
tran/trans-decl.c:1265
   'mult-operand-16')
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Walt@HP_Laptop /cygdrive/c/walt/Testing/U_F90_TS_15/TESTS/SYNTAX/RULES
$ gfortran --version
GNU Fortran (rev5, Built by MinGW-W64 project) 4.8.1
Copyright (C) 2013 Free Software Foundation, Inc.

I can't tell if the attachment is there or not ???

[Bug middle-end/59776] [4.8/4.9 Regression] gcc -g -O1 ICE in expand_debug_locations, at cfgexpand.c:3865

[rth at gcc dot gnu.org]

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

--- Comment #7 from Richard Henderson  ---
Definitely SRA's fault.  See

  http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00489.html

for analysis, and the hackiest of patches.

[Bug fortran/60066] Bad elemental invocation of non-scalar base object

[paul.richard.thomas at gmail dot com]

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

--- Comment #9 from paul.richard.thomas at gmail dot com  ---
Dear All,

I propose to add the attached to the testsuite.  It is the testcase
from PR60066, which was fixed by the patch for PR59066.

OK for trunk, 4.8 and 4.7?

On 5 February 2014 12:38, pault at gcc dot gnu.org
 wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066
>
> Paul Thomas  changed:
>
>What|Removed |Added
> 
>  Resolution|DUPLICATE   |FIXED
>
> --- Comment #8 from Paul Thomas  ---
> (In reply to Dominique d'Humieres from comment #5)
>> > I have applied the patch at 
>> > http://gcc.gnu.org/ml/fortran/2014-02/txtX3eVILZEGw.txt
>> > on top of 4.8.3 r206497 and the test runs successfully ...
>>
>> Marking as duplicate of pr49906.
>>
>> Paul,
>>
>> For the record, no regression when testing with
>>
>> make -k -j8 check-gfortran RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
>>
>> *** This bug has been marked as a duplicate of bug 49906 ***
>
> I will, however, add this testcase to that of PR59906 - it is different yet
> again from the verification tests although it is fixed by the patch.
>
> Cheers
>
> Pau
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug c++/60105] [C++11] g++-4.8.2 segfaults on enable_if explicit cast operator

[Andrey.E.Antipov at gmail dot com]

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

--- Comment #1 from Andrey Antipov  ---
Tested - crashes on 4.7.3 and 4.7.2 on linux as well.

[Bug translation/52289] translatable string typo: "must not be have"

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #2 from Jeffrey A. Law  ---
Fixed on trunk.

[Bug translation/52289] translatable string typo: "must not be have"

[law at gcc dot gnu.org]

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

--- Comment #1 from Jeffrey A. Law  ---
Author: law
Date: Fri Feb  7 17:52:59 2014
New Revision: 207609

URL: http://gcc.gnu.org/viewcvs?rev=207609&root=gcc&view=rev
Log:
PR translation/52289
* fortran/resolve.c (resolve_ordinary_assign): Fix typoed word
in an error message.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c

[Bug target/60109] __builtin_frame_address does not work as documented on ARM

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #2 from Ramana Radhakrishnan  ---
Agreed, this is effectively requesting for a frame pointer mandatorily in the
ABI.


regards
Ramana

[Bug libgcc/58710] HAVE_GETIPINFO is incorrectly set on Mac OS X 10.4

[misty at brew dot sh]

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

--- Comment #2 from Misty De Meo  ---
Patch submitted: http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00477.html

[Bug target/60109] __builtin_frame_address does not work as documented on ARM

[rearnsha at gcc dot gnu.org]

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

--- Comment #1 from Richard Earnshaw  ---
This is an unresolvable problem.

If we made __builtin_frame_address(N > 0) always return 0, then some useful use
cases for debugging would be excluded.

On the other hand, it is impossible to know whether it will return a useful
value in other cases, since it is dependent on all code being:
a) built with the same instruction set (arm or thumb)
b) Having a consistent use of the frame pointer.

My inclination is to resolve this as "won't fix".

[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)

[amonakov at gcc dot gnu.org]

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

--- Comment #9 from Alexander Monakov  ---
By "good code" I was referring to the fact that your 4.7 asm does not contain
stack (%rbp) references in the vectorized loop.

Historically, first scheduling (-fschedule-insns) was problematic for 32-bit
x86 due to increase of register pressure to the point that register allocator
couldn't handle.  The situation got much better with the introduction of
-fsched-pressure, and was tuned a bit further recently.  I don't know the
latest status; I think compile time cost is the reason it's not enabled at -O2.

For regrename, the manpage notes there are debug info issues on some targets; I
don't know if there's anything else beside that.

[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)

[marcin.krotkiewski at gmail dot com]

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

--- Comment #8 from Marcin Krotkiewski  ---
(In reply to Andrey Belevantsev from comment #5)
> At this point insn 461 is dead but we do not notice, and it doesn't look
> easy.  I think there was some suggestion in the original research for
> killing dead insn copies left after renaming but I don't remember offhand.

Following Alexanders suggestion, I compiled the test code with -mavx -O3
-fselective-scheduling2 -frename-registers. This seems to get rid of the dead
instructions and yields the desired scheduling:

.L5:
vmovapd(%rbx,%rdi), %ymm0
 addq$1, %rsi
vmovapd(%r12,%rdi), %ymm3
 vaddpd0(%r13,%rdi), %ymm0, %ymm2
vaddpd(%r14,%rdi), %ymm3, %ymm4
 vmovapd%ymm2, (%rbx,%rdi)
 vmovapd%ymm4, (%r12,%rdi)
 addq$32, %rdi
cmpq%rsi, %rdx
ja.L5

Alexander, I should maybe clarify that the 'good' code was prepared by hand,
modifying the 'bad' asm I got from gcc 4.7. Asm generated by gcc 4.4 was the
same. If that is what you were refering to.

I am a bit confused now. It seems that all fine and the desired asm can be
generated, so there is no real bug. But why is the original code compiled with
-O3 -mavx bad then? Is -fschedule-insns not enabled at -O2?

[Bug preprocessor/56824] [4.8/4.9 regression] pragma GCC diagnostic push/pop fail with GCC diagnostic ignored "-Waggregate-return"

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb  7 16:42:24 2014
New Revision: 207606

URL: http://gcc.gnu.org/viewcvs?rev=207606&root=gcc&view=rev
Log:
PR preprocessor/56824
* line-map.c (get_combined_adhoc_loc, linemap_get_expansion_line,
linemap_get_expansion_filename, linemap_location_in_system_header_p,
linemap_location_from_macro_expansion_p,
linemap_macro_loc_to_spelling_point, linemap_macro_loc_to_def_point,
linemap_macro_loc_to_exp_point, linemap_expand_location): Fix
formatting.
(linemap_compare_locations): Look through adhoc locations for both
l0 and l1.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr56824.c
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/line-map.c

[Bug target/60109] New: __builtin_frame_address does not work as documented on ARM

[doko at gcc dot gnu.org]

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

Bug ID: 60109
   Summary: __builtin_frame_address does not work as documented on
ARM
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

__builtin_frame_address does not work as documented on ARM. For a value
greater or equal to 1 it returns a non null value but the returned
pointer does not seem to match a frame. See the attached testcase. With
tcc and clang it displays "__builtin_frame_address" while with gcc it
first displays "bfa1: %s" and then segfaults if the #if is removed.


amd64:
$ gcc builtin_frame_address.c && ./a.out
str: __builtin_frame_address
bfa1: __builtin_frame_address

armhf:
str: __builtin_frame_address
bfa1:  %s

$ cat builtin_frame_address.c 
#include 
#include 

void bfa3(ptrdiff_t str_offset)
{
printf("bfa3: %s\n", (char *)__builtin_frame_address(3) + str_offset);
}
void bfa2(ptrdiff_t str_offset)
{
printf("bfa2: %s\n", (char *)__builtin_frame_address(2) + str_offset);
bfa3(str_offset);
}
void bfa1(ptrdiff_t str_offset)
{
printf("bfa1: %s\n", (char *)__builtin_frame_address(1) + str_offset);
#if defined(__arm__) && !defined(__GNUC__)
bfa2(str_offset);
#endif
}

void builtin_frame_address_test(void)
{
char str[] = "__builtin_frame_address";
char *fp0 = __builtin_frame_address(0);

printf("str: %s\n", str);
bfa1(str-fp0);
}

int main(void)
{
builtin_frame_address_test();
return 0;
}

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[thatcadguy at gmail dot com]

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

--- Comment #23 from Jacob Abel  ---
If it helps at all, the following produces the same problem under gcc:

#include 
#include 

int main(void)
{
__float128 *ptr = NULL;
int i;
if (ptr = malloc(100 * sizeof(__float128)))
for (i = 0; i < 100; i++)
ptr[i] = 0;
return 0;
}

segfault with -march=native, fine without.

[Bug c++/60108] New: ICE in use_thunk, at cp/method.c:340

[doko at gcc dot gnu.org]

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

Bug ID: 60108
   Summary: ICE in use_thunk, at cp/method.c:340
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org

seen with trunk and current 4.7 and 4.8 branches.

$ g++ -std=c++0x -c sample.cpp
sample.cpp:5:3: internal compiler error: in use_thunk, at cp/method.c:340
   ~B() = default;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.


template  struct A {
  virtual ~A();
};
template  struct B : A... {
  ~B() = default;
};
struct C : B {
  C() {}
};

[Bug target/59595] [4.9 Regression] Segmentation fault: build/genpreds -c ../../gcc/gcc/config/arm/arm.md > tmp-constrs.h

[dave.anglin at bell dot net]

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

--- Comment #3 from dave.anglin at bell dot net ---
I have been trying to narrow down the change that caused the 
regression.  r205921 is
OK and r205955 is bad. Most recent build that I have noted as bad is 
r206196.

Last test results from box are here:
http://gcc.gnu.org/ml/gcc-testresults/2014-01/msg02299.html

 From the above, it looks like the failure points for 59913 and 59595 
are different.

Dave

[Bug libgomp/60107] New: libgomp.c/pr58392.c etc. FAIL

[ro at gcc dot gnu.org]

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

Bug ID: 60107
   Summary: libgomp.c/pr58392.c etc. FAIL
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Host: i386-pc-solaris2.9
Target: i386-pc-solaris2.9
 Build: i386-pc-solaris2.9

3 libgomp tests FAIL on Solaris 9/x86 since they were introduced:

FAIL: libgomp.c/pr58392.c execution test
FAIL: libgomp.c/simd-6.c execution test
FAIL: libgomp.c++/simd-8.C execution test

For the first, I find

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2 (LWP 2)]
0x080509f1 in foo._omp_fn ()
at /vol/gcc/src/hg/trunk/local/libgomp/testsuite/libgomp.c/pr58392.c:20
20  c += d[j + l];
(gdb) x/i $pc
=> 0x80509f1 :   paddd  0x10(%esp),%xmm0
(gdb) p $esp
$1 = (void *) 0xb5aedf64

truss shows
/2: Incurred fault #6, FLTBOUNDS  %pc = 0x080509F1
/2:   siginfo: SIGSEGV SEGV_MAPERR addr=0x080509F1
/2: Received signal #11, SIGSEGV [default]
/2:   siginfo: SIGSEGV SEGV_MAPERR addr=0x080509F1

and  has

#define FLTBOUNDS   6   /* Memory bounds (invalid address) */

pmap reveals the following mappings:

08062000  12K rwx--[ heap ]
B5AED000   4K rwx-R[ anon ]
B5AF 108K rw---[ anon ]

  Rainer

[Bug rtl-optimization/60030] [4.9 regression] ICE in simplify_subreg, at simplify-rtx.c:5903

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libstdc++/60037] SIGFPE in std::generate_canonical

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-07
 CC||ro at gcc dot gnu.org
Version|unknown |4.9.0
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #2 from Rainer Orth  ---
I'm seeing the same on Solaris 10 and 11/x86.

  Rainer

[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

--- Comment #6 from Jakub Jelinek  ---
Created attachment 32077
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32077&action=edit
Untested fix

Untested fix.  Likely I'll need to do something more, so that we don't emit
extra decls for the debug info outside of the #pragma omp simd (flag on the
private clause?) and add a testcase.

And, the reason why with this patch (or the adjusted testcase with explicit
private clause) isn't vectorized is that we'd need to teach vectorizer how to
vectorize SSA_NAME = &array[SSA_NAME]; where the second SSA_NAME is
GOMP_SIMD_LANE () result and array is an "omp simd array" array, as a vector
of addresses (initialized before the loop), containing { &array[0], &array[1],
..., &array[vf-1] }.

[Bug libgcj/55637] FAIL: sourcelocation output - source compiled test

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
> What should we do about this test?  Having it fail everywhere a current 
> binutils
> version is used causes lots of noise in testsuite results.

Since nobody cared to fix the tests since more than one year, IMO the answer is
obvious: remove it.

[Bug ipa/59918] [4.9 Regression] ICE in record_target_from_binfo, at ipa-devirt.c:693

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #10 from Markus Trippelsdorf  ---
Fixed by r207592. Closing.

[Bug libgcj/55637] FAIL: sourcelocation output - source compiled test

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

--- Comment #12 from Rainer Orth  ---
What should we do about this test?  Having it fail everywhere a current
binutils
version is used causes lots of noise in testsuite results.

  Rainer

[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

--- Comment #5 from Jakub Jelinek  ---
I guess during gimplification when gimplifying #pragma omp simd body we should
add all the local variables (declared in the body) that aren't static and are
address taken to private clause on the #pragma omp simd, so that they will be
handled like if you in your testcase do instead:
int v1, v2;
#pragma omp simd private (v1, v2)
for(i = 0; i < 1000; i++)
{
  foo(a[i], &v1, &v2);
  a[i] = v1 * v2;
}

We don't vectorize that right now, but that is something that is likely
fixable.

[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #7 from Alexander Monakov  ---
(In reply to Jakub Jelinek from comment #1)
> alignment, but still the scheduler doesn't reorder the loads vs. the store,
> unless -O3 -mavx -fschedule-insns.  The reason why the second scheduler
> doesn't reorder those is that RA allocates the same register

I think you usually want -fschedule-insns (pre-regalloc scheduling) or
-frename-registers rather than -fselective-scheduling2 when the goal is to
workaround RA conservativeness.  Unfortunately, stack accesses in the loop
prevent sched2 from using the additional freedom supplied by regrename for AVX
code in this case (when tuning is enabled).  The stack accesses seem to be a
trunk regression judging by good code supplied in the opening comment. 

(-O3 -mavx -fschedule-insns or -frename-registers, same modulo ymm* names,
%rpb-based accesses in the loop are pretty bad, but otherwise it's scheduled as
desired)
.L9:
movq-136(%rbp), %rdx
vmovapd (%r9,%rax), %ymm1
addq$1, %rdi
vmovapd (%r10,%rax), %ymm0
vaddpd  (%rdx,%rax), %ymm1, %ymm1
movq-144(%rbp), %rdx
vaddpd  (%rdx,%rax), %ymm0, %ymm0
vmovapd %ymm1, (%r9,%rax)
vmovapd %ymm0, (%r10,%rax)
addq$32, %rax
cmpq%rdi, -152(%rbp)
ja  .L9

(-O3 -fschedule-insns or -frename-registers, same modulo xmm* names, scheduled
as desired)
.L7:
movapd  (%r9,%rax), %xmm0
addq$1, %rdi
movapd  (%r10,%rax), %xmm2
addpd   (%r11,%rax), %xmm0
addpd   (%rcx,%rax), %xmm2
movaps  %xmm0, (%r9,%rax)
movaps  %xmm2, (%r10,%rax)
addq$16, %rax
cmpq%rdi, %r8
ja  .L7

(-mavx -O3 -mtune=corei7-avx -frename-registers, stack-based references prevent
good scheduling)
.L9:
movq-136(%rbp), %rdx
addq$1, %rdi
vmovapd (%r9,%rax), %ymm0
vmovapd (%r10,%rax), %ymm3
vaddpd  (%rdx,%rax), %ymm0, %ymm2
movq-144(%rbp), %rdx
vmovapd %ymm2, (%r9,%rax)
vaddpd  (%rdx,%rax), %ymm3, %ymm4
vmovapd %ymm4, (%r10,%rax)
addq$32, %rax
cmpq%rdi, -152(%rbp)
ja  .L9

(-mavx -O3 -mtune=corei7-avx -fschedule-insns -fno-ivopts, no spilling in the
loop, scheduled as desired)
.L9:
addq$32, %rcx
addq$32, %r10
vmovapd (%rdx), %ymm1
addq$32, %rsi
vmovapd (%rdi), %ymm0
addq$32, %r11
addq$1, %rax
addq$32, %rdx
vaddpd  -32(%rcx), %ymm1, %ymm1
addq$32, %rdi
vaddpd  -32(%r10), %ymm0, %ymm0
vmovapd %ymm1, -32(%rsi)
vmovapd %ymm0, -32(%r11)
cmpq%rax, -184(%rbp)
ja  .L9

[Bug target/60039] sh3 optimisation bug with -O2

[skrll at netbsd dot org]

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

--- Comment #4 from Nick Hudson  ---
Created attachment 32076
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32076&action=edit
Full assembler output

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
Author: rguenth
Date: Fri Feb  7 13:41:10 2014
New Revision: 207598

URL: http://gcc.gnu.org/viewcvs?rev=207598&root=gcc&view=rev
Log:
2014-02-07  Richard Biener  

PR middle-end/60092
* gimple-low.c (lower_builtin_posix_memalign): New function.
(lower_stmt): Call it to lower posix_memalign in a way
to make alignment info accessible.

* gcc.dg/vect/pr60092-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr60092-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-low.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/60082] Certain Cilk keywords executable Hanging for -O1

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
catch_exc.cc FAILs (other than timeout) seem to be a Cilk+ bug, if it ever
worked, it seems to have worked by accident.
The problem is that __cilkrts_rethrow conditionally throws an exception, but is
marked TREE_NOTHROW, thus there are no EH edges out of it.

2014-02-07  Jakub Jelinek  

* cilk-common.c (cilk_init_builtins): Clear TREE_NOTHROW
flag on __cilkrts_rethrow builtin.

--- gcc/cilk-common.c.jj2014-02-06 23:06:47.0 +0100
+++ gcc/cilk-common.c2014-02-07 11:11:15.253128977 +0100
@@ -285,6 +285,7 @@ cilk_init_builtins (void)
   /* __cilkrts_rethrow (struct stack_frame *);  */
   cilk_rethrow_fndecl = install_builtin ("__cilkrts_rethrow", fptr_fun, 
  BUILT_IN_CILK_RETHROW, false);
+  TREE_NOTHROW (cilk_rethrow_fndecl) = 0;

   /* __cilkrts_save_fp_ctrl_state (__cilkrts_stack_frame *);  */
   cilk_save_fp_fndecl = install_builtin ("__cilkrts_save_fp_ctrl_state",

[Bug other/60099] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Richard Biener  ---
Thus fixed.

[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||4.4.7
   Keywords||compile-time-hog,
   ||diagnostic
   Last reconfirmed||2014-02-07
 Ever confirmed|0   |1
Summary|Long compile times when |[4.7/4.8/4.9 Regression]
   |mixed complex floating  |Long compile times when
   |point datatypes are used in |mixed complex floating
   |lengthy expressions |point datatypes are used in
   ||lengthy expressions
   Target Milestone|--- |4.7.4
  Known to fail||4.5.4, 4.6.4, 4.7.2, 4.8.2,
   ||4.9.0

--- Comment #1 from Richard Biener  ---
Looks like we spend all time in c-common.c:verify_sequence_points ().  Not sure
why double.c compiles instantly.  Using the C++ frontend also makes float.c
compile instantly.

Regression from at 4.4.

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de  ---
On Fri, 7 Feb 2014, pa...@matos-sorge.com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
> 
> --- Comment #20 from Paulo J. Matos  ---
> OK, I was trying to make sense of all this and there are two things that stick
> out.
> 
> One is when you say that due to C integer promotion rules make i = 
> (short)((int)i + 1). However GCC is doing i = (short) ((unsigned short) 
> i + 1). Am I missing something that allows this or makes the addition in 
> int equivalent to the addition in unsigned short?

This is a valid shortening optimization GCC performs.

> Secondly we still have a dangling sign_extend later on that we could 
> possibly optimize. I find it hard to understand if this can be done 
> properly in expand or if a small pass like ree but before zero overhead 
> loop generation is better. What do you think?

That entirely depends on where the extension is generated and what
information is present there ... if it can be avoided at expand
time then that's surely the best thing to do.  Maybe it can even
be avoided on the GIMPLE level.

[Bug target/59222] [4.9 Regression] gcc.c-torture/compile/20050622-1.c ICEs at -O1 and above for aarch64-elf ILP32

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-07
 CC||ramana at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org,
   ||yvan.roux at linaro dot org
 Ever confirmed|0   |1

--- Comment #4 from Ramana Radhakrishnan  ---
Adding Vlad and Yvan to the cc list as they've been looking at LRA for AArch64.

[Bug c++/60082] Certain Cilk keywords executable Hanging for -O1

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb  7 10:49:08 2014
New Revision: 207597

URL: http://gcc.gnu.org/viewcvs?rev=207597&root=gcc&view=rev
Log:
PR c++/60082
* tree.c (build_common_builtin_nodes): Set ECF_LEAF for
__builtin_setjmp_receiver.

Revert
2014-02-05  Balaji V. Iyer  

* g++.dg/cilk-plus/CK/catch_exc.cc: Disable test for -O1.
* c-c++-common/cilk-plus/CK/spawner_inline.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/spawner_inline.c
trunk/gcc/testsuite/g++.dg/cilk-plus/CK/catch_exc.cc
trunk/gcc/tree.c

[Bug target/60034] "invalid expression as operand" in aarch64 inline asm

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-07
 Ever confirmed|0   |1

[Bug target/60034] "invalid expression as operand" in aarch64 inline asm

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #4 from Ramana Radhakrishnan  ---
(In reply to Kugan from comment #1)
> Created attachment 32018 [details]
> Proposed patch

Please submit patches on gcc-patc...@gcc.gnu.org

[Bug target/59695] bad code generation on aarch64 in aarch64_output_mi_thunk

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
Version|4.9.0   |4.8.0
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.3

--- Comment #4 from Ramana Radhakrishnan  ---
Fixed now presumably.

[Bug target/59595] [4.9 Regression] Segmentation fault: build/genpreds -c ../../gcc/gcc/config/arm/arm.md > tmp-constrs.h

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed|2014-01-20 00:00:00 |2014-02-07
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59913 was something similar. Can
you see if it still fails for you ? 

I see a few testresults for v5te bootstraps

http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00255.html

[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

[nheghathivhistha at gmail dot com]

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

--- Comment #15 from David Kredba  ---
It is still present in rev. 207565 and pykde4-4.12.2:

CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart5.cpp.o: In
function `~Notifier':
/usr/include/phonon/backendcapabilities.h:57: undefined reference to `vtable
for Phonon::BackendCapabilities::Notifier'
/usr/include/phonon/backendcapabilities.h:57: undefined reference to `vtable
for Phonon::BackendCapabilities::Notifier'
CMakeFiles/python_module_PyKDE4_phonon.dir/sip/phonon/sipphononpart5.cpp.o: In
function `Phonon::BackendCapabilities::Notifier::~Notifier()':
/usr/include/phonon/backendcapabilities.h:57: undefined reference to `vtable
for Phonon::BackendCapabilities::Notifier'
collect2: error: ld returned 1 exit status

[Bug c/57490] ICE on c-c++-common/cilk-plus/AN/an-if.c

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #3 from Rainer Orth  ---
Fixed since ca. 20131217.

[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop

[pa...@matos-sorge.com]

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

--- Comment #20 from Paulo J. Matos  ---
OK, I was trying to make sense of all this and there are two things that stick
out.

One is when you say that due to C integer promotion rules make i =
(short)((int)i + 1). However GCC is doing i = (short) ((unsigned short) i + 1).
Am I missing something that allows this or makes the addition in int equivalent
to the addition in unsigned short?

Secondly we still have a dangling sign_extend later on that we could possibly
optimize. I find it hard to understand if this can be done properly in expand
or if a small pass like ree but before zero overhead loop generation is better.
What do you think?

[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Author: rguenth
Date: Fri Feb  7 09:33:23 2014
New Revision: 207595

URL: http://gcc.gnu.org/viewcvs?rev=207595&root=gcc&view=rev
Log:
2014-02-07  Richard Biener  

PR middle-end/60092
* builtin-types.def (BT_FN_INT_PTRPTR_SIZE_SIZE): Add.
* builtins.def (BUILT_IN_POSIX_MEMALIGN): Likewise.
* tree-ssa-structalias.c (find_func_aliases_for_builtin_call):
Handle BUILT_IN_POSIX_MEMALIGN.
(find_func_clobbers): Likewise.
* tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Likewise.
(call_may_clobber_ref_p_1): Likewise.

* gcc.dg/tree-ssa/alias-30.c: New testcase.
* gcc.dg/tree-ssa/alias-31.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-30.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-31.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtin-types.def
trunk/gcc/builtins.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-structalias.c

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-07
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
Confirmed.

[Bug rtl-optimization/60030] [4.9 regression] ICE in simplify_subreg, at simplify-rtx.c:5903

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||bernd.edlinger at hotmail dot 
de

--- Comment #3 from Ramana Radhakrishnan  ---
*** Bug 60093 has been marked as a duplicate of this bug. ***

[Bug target/59904] [ARM] tls-reload-1.c fails

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #1 from Ramana Radhakrishnan  ---
So, this is failing for TLS with Thumb1, PIE and armv5t. 

Needs further investigation.

[Bug middle-end/60093] ICE on testsuite/c-c++-common/ubsan/overflow-*.c

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #2 from Ramana Radhakrishnan  ---
looks like a dup of 60030

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

[Bug target/60094] gcc.target/arm/ftest-armv7em-thumb.c fails

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #4 from Ramana Radhakrishnan  ---
Fixed. I don't see these in any of my recent test results.

[Bug target/55666] Use scratch register to avoid save/restore of callee saved register

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-02-07
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Ramana Radhakrishnan  ---
This looks like a case due to a different REG_ALLOC_ORDER for Thumb2 being set
up. HONOR_IRA_REGALLOC_ORDER and some of the changes which came there would be
where I would dig further.

[Bug regression/55676] ICE in int_mode_for_mode, at stor-layout.c:423

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |WORKSFORME
   Target Milestone|--- |4.8.3

--- Comment #1 from Ramana Radhakrishnan  ---
Works for me on trunk and the 4.8 branch with the options under question. 

Not sure what fixed it though.

[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)

[abel at gcc dot gnu.org]

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

--- Comment #6 from Andrey Belevantsev  ---
Forgot to mention that we end up scheduling this block in 21 cycles while the
regular scheduling needs 24.  Not that it's so important though.

[Bug rtl-optimization/60086] suboptimal asm generated for a loop (store/load false aliasing)

[abel at gcc dot gnu.org]

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

--- Comment #5 from Andrey Belevantsev  ---
(In reply to Jakub Jelinek from comment #1)
> ...
> doesn't reorder those is that RA allocates the same register.  With -O3
> -mavx -fselective-scheduling2 the stores are also changed, but we end up
> with a weird:
> .L9:
> movq-136(%rbp), %rdx
> vmovapd (%r9,%rax), %ymm0
> addq$1, %rdi
> vmovapd (%r10,%rax), %ymm8
> vaddpd  (%rdx,%rax), %ymm0, %ymm0
> movq-144(%rbp), %rdx
> vaddpd  (%rdx,%rax), %ymm8, %ymm9
> vmovapd %ymm0, (%r9,%rax)
> vmovapd %ymm8, %ymm0
> vmovapd %ymm9, %ymm0
> vmovapd %ymm0, (%r10,%rax)
> addq$32, %rax
> cmpq%rdi, -152(%rbp)
> ja  .L9
> Why there is the vmovapd %ymm8, %ymm0 is a mystery, and vmovapd %ymm9, %ymm0
> could be very well merged with the store into vmovapd %ymm9, (%r10,%rax).

That's because we do a renaming and a substitution.  We have (in the middle of
scheduling, just scheduled insn 78):

  262: dx:DI=[bp:DI-0x88]
   72: xmm0:V4DF=[r9:DI+ax:DI]
   78: {di:DI=di:DI+0x1;clobber flags:CC;}   <--- we are here
   73: xmm0:V4DF=xmm0:V4DF+[dx:DI+ax:DI]
   74: [r9:DI+ax:DI]=xmm0:V4DF
   75: xmm0:V4DF=[r10:DI+ax:DI]
  263: dx:DI=[bp:DI-0x90]
   76: xmm0:V4DF=xmm0:V4DF+[dx:DI+ax:DI]
   77: [r10:DI+ax:DI]=xmm0:V4DF

Now we want to schedule insn 75 but xmm0 is busy in 74 and 73, so we rename it
to xmm8 and have:

  262: dx:DI=[bp:DI-0x88]
   72: xmm0:V4DF=[r9:DI+ax:DI]
   78: {di:DI=di:DI+0x1;clobber flags:CC;}
  459: xmm8:V4DF=[r10:DI+ax:DI]  <--- we are here
   73: xmm0:V4DF=xmm0:V4DF+[dx:DI+ax:DI]
   74: [r9:DI+ax:DI]=xmm0:V4DF
  461: xmm0:V4DF=xmm8:V4DF   <--- copy after renaming 
  263: dx:DI=[bp:DI-0x90]
   76: xmm0:V4DF=xmm0:V4DF+[dx:DI+ax:DI]
   77: [r10:DI+ax:DI]=xmm0:V4DF

Then after scheduling insns 73 and 263 we have

  262: dx:DI=[bp:DI-0x88]
   72: xmm0:V4DF=[r9:DI+ax:DI]
   78: {di:DI=di:DI+0x1;clobber flags:CC;}
  459: xmm8:V4DF=[r10:DI+ax:DI]
   73: xmm0:V4DF=xmm0:V4DF+[dx:DI+ax:DI]
  263: dx:DI=[bp:DI-0x90]   <--- we are here
   74: [r9:DI+ax:DI]=xmm0:V4DF
  461: xmm0:V4DF=xmm8:V4DF
   76: xmm0:V4DF=xmm0:V4DF+[dx:DI+ax:DI]
   77: [r10:DI+ax:DI]=xmm0:V4DF

and now we want to schedule insn 76.  We substitute its rhs through a copy 461
but then xmm0 is again busy so we rename the target register to xmm9 and get

  262: dx:DI=[bp:DI-0x88]
   72: xmm0:V4DF=[r9:DI+ax:DI]
   78: {di:DI=di:DI+0x1;clobber flags:CC;}
  459: xmm8:V4DF=[r10:DI+ax:DI]
   73: xmm0:V4DF=xmm0:V4DF+[dx:DI+ax:DI]
  263: dx:DI=[bp:DI-0x90]
  464: xmm9:V4DF=xmm8:V4DF+[dx:DI+ax:DI]<--- new renamed insn
   74: [r9:DI+ax:DI]=xmm0:V4DF
  461: xmm0:V4DF=xmm8:V4DF
  466: xmm0:V4DF=xmm9:V4DF  <--- copy after renaming
   77: [r10:DI+ax:DI]=xmm0:V4DF


At this point insn 461 is dead but we do not notice, and it doesn't look easy. 
I think there was some suggestion in the original research for killing dead
insn copies left after renaming but I don't remember offhand.

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

[izamyatin at gmail dot com]

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

--- Comment #4 from Igor Zamyatin  ---
vect details show that v1.0_14 = v1 and v2.1_15 = v2 are treated as invariants:

test.c:24:14: note: -->vectorizing statement: v1.0_14 = v1;

test.c:24:14: note: transform statement.
test.c:24:14: note: transform load. ncopies = 1
test.c:24:14: note: create vector_type-pointer variable to type: vector(4) int 
vectorizing a pointer ref: v1
test.c:24:14: note: created vectp_v1.11_40
test.c:24:14: note: add new stmt: vect_v1.12_37 = MEM[(int *)vectp_v1.10_39];

test.c:24:14: note: hoisting out of the vectorized loop: v1.0_14 = v1;

test.c:24:14: note: created new init_stmt: vect_cst_.13_7 = {v1.0_8, v1.0_8,
v1.0_8, v1.0_8};

test.c:24:14: note: -->vectorizing statement: v2.1_15 = v2;

test.c:24:14: note: transform statement.
test.c:24:14: note: transform load. ncopies = 1
test.c:24:14: note: create vector_type-pointer variable to type: vector(4) int 
vectorizing a pointer ref: v2
test.c:24:14: note: created vectp_v2.15_1
test.c:24:14: note: add new stmt: vect_v2.16_60 = MEM[(int *)vectp_v2.14_58];

test.c:24:14: note: hoisting out of the vectorized loop: v2.1_15 = v2;

test.c:24:14: note: created new init_stmt: vect_cst_.17_62 = {v2.1_61, v2.1_61,
v2.1_61, v2.1_61};


Step for both loads determined as 0. Seems support for such case should be
explicitly added

[Bug target/60088] Segfault when using quad precision and -march=native on gfortran

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #22 from Uroš Bizjak  ---


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

[Bug fortran/55916] Alignment issues with real(16) on i686

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||thatcadguy at gmail dot com

--- Comment #7 from Uroš Bizjak  ---
*** Bug 60088 has been marked as a duplicate of this bug. ***