[Bug rtl-optimization/50764] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2243 with -O2 -fsched2-use-superblocks -ftree-tail-merge

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org 2011-10-30 07:39:36 UTC ---
Tentative patch at http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02767.html

[Bug c++/50917] New: [4.7 Regression] Mozilla build fails because of C++11 user-defined literals

[markus at trippelsdorf dot de]

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

 Bug #: 50917
   Summary: [4.7 Regression] Mozilla build fails because of C++11
user-defined literals
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de


Mozilla fails to build because of the recently merged C++11 user-defined
literals implementation:
c++ -o nsGlueLinkingDlopen.i_o -c -I../../../dist/system_wrappers -include
/var/tmp/mozilla-central/config/gcc_hidden.h -DOSTYPE=\"Linux3.1\"
-DOSARCH=Linux -DXPCOM_GLUE -DTARGET_XPCOM_ABI=\"x86_64-gcc3\"
-I/var/tmp/mozilla-central/xpcom/glue/standalone/../../build
-I/var/tmp/mozilla-central/xpcom/glue/standalone -I. -I../../../dist/include
-I../../../dist/include/nsprpub -I/usr/include/nspr -I/usr/include/nss -fPIC
-fno-rtti -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth
-Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof
-Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -march=native
-ffunction-sections -fdata-sections -fvisibility-inlines-hidden -fpermissive
-Wno-delete-non-virtual-dtor -fno-exceptions -fno-strict-aliasing -std=gnu++0x
-pthread -ffunction-sections -fdata-sections -pipe -DNDEBUG -DTRIMMED
-fprofile-generate -O3 -fomit-frame-pointer -DMOZILLA_CLIENT -include
../../../mozilla-config.h -MD -MF .deps/nsGlueLinkingDlopen.pp
/var/tmp/mozilla-central/xpcom/glue/standalone/nsGlueLinkingDlopen.cpp

/var/tmp/mozilla-central/xpcom/glue/standalone/nsGlueLinkingDlopen.cpp: In
function ‘nsresult XPCOMGlueLoad(const char*, nsresult (**)(XPCOMFunctions*,
const char*))’:
/var/tmp/mozilla-central/xpcom/glue/standalone/nsGlueLinkingDlopen.cpp:231:68:
error: unable to find user-defined string literal operator ‘operator""
MOZ_DLL_SUFFIX’

xpcom/glue/standalone/nsGlueLinkingDlopen.cpp:231:
snprintf(lastSlash, MAXPATHLEN - strlen(xpcomDir), "/" XUL_DLL);

./moz-build-dir/mozilla-config.h
#define MOZ_DLL_SUFFIX ".so"

./xpcom/build/nsXPCOMPrivate.h:
#define XUL_DLL   "libxul"MOZ_DLL_SUFFIX

Please note that they're using -std=gnu++0x

[Bug bootstrap/50878] [4.7 Regression] ARM bootstrap failure on insn-preds.c with error: dominator of 12 should be 6, not 5

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org 2011-10-30 08:21:52 UTC ---
Posted fix: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02782.html

[Bug tree-optimization/50918] New: Unoptimal code for vec-shift by scalar for integer (byte, short, long long) operands

[ubizjak at gmail dot com]

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

 Bug #: 50918
   Summary: Unoptimal code for vec-shift by scalar for integer
(byte, short, long long) operands
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ubiz...@gmail.com


Following testcase:

--cut here--
#define N 8

short a[N] = { 1,2,3,4,10,20,30,90 };
short r[N];

void
test_var (int n)
{
  int i;

  for (i = 0; i < N; i++)
r[i] = a[i] << n;
}

void
test_cst (void)
{
  int i;

  for (i = 0; i < N; i++)
r[i] = a[i] << 3;
}
--cut here--

compiles to (-march=corei7 -O2 -ftree-vectorize):

test_var:
movdqaa(%rip), %xmm0
movd%edi, %xmm2
pmovsxwd%xmm0, %xmm1
psrldq$8, %xmm0
pmovsxwd%xmm0, %xmm0
pslld%xmm2, %xmm1
pslld%xmm2, %xmm0
pshufb.LC0(%rip), %xmm1
pshufb.LC1(%rip), %xmm0
por%xmm1, %xmm0
movdqa%xmm0, r(%rip)
ret

test_cst:
movdqaa(%rip), %xmm0
pmovsxwd%xmm0, %xmm1
psrldq$8, %xmm0
pmovsxwd%xmm0, %xmm0
pslld$3, %xmm1
pshufb.LC0(%rip), %xmm1
pslld$3, %xmm0
pshufb.LC1(%rip), %xmm0
por%xmm1, %xmm0
movdqa%xmm0, r(%rip)
ret

Why not psllw ?

The .optimized dump already shows:

test_var (int n)
{
  vector(8) short int vect_var_.16;
  vector(4) int vect_var_.15;
  vector(4) int vect_var_.14;
  vector(8) short int vect_var_.13;

:
  vect_var_.13_23 = MEM[(short int[8] *)&a];
  vect_var_.14_24 = [vec_unpack_lo_expr] vect_var_.13_23;
  vect_var_.14_25 = [vec_unpack_hi_expr] vect_var_.13_23;
  vect_var_.15_26 = vect_var_.14_24 << n_5(D);
  vect_var_.15_27 = vect_var_.14_25 << n_5(D);
  vect_var_.16_28 = VEC_PACK_TRUNC_EXPR ;
  MEM[(short int[8] *)&r] = vect_var_.16_28;
  return;

}


test_cst ()
{
  vector(8) short int vect_var_.36;
  vector(4) int vect_var_.35;
  vector(4) int vect_var_.34;
  vector(8) short int vect_var_.33;

:
  vect_var_.33_22 = MEM[(short int[8] *)&a];
  vect_var_.34_23 = [vec_unpack_lo_expr] vect_var_.33_22;
  vect_var_.34_24 = [vec_unpack_hi_expr] vect_var_.33_22;
  vect_var_.35_25 = vect_var_.34_23 << 3;
  vect_var_.35_26 = vect_var_.34_24 << 3;
  vect_var_.36_27 = VEC_PACK_TRUNC_EXPR ;
  MEM[(short int[8] *)&r] = vect_var_.36_27;
  return;

}

The same unoptimal code is generated for long-long and byte (-mxop target)
signed and unsigned arguments, left and right shifts. OTOH, int arguments
produce optimal code for left and right shifts:

test_var:
movdqaa(%rip), %xmm0
movd%edi, %xmm1
pslld%xmm1, %xmm0
movdqa%xmm0, r(%rip)
ret

test_cst:
movdqaa(%rip), %xmm0
pslld$3, %xmm0
movdqa%xmm0, r(%rip)
ret

[Bug c++/50917] [4.7 Regression] Mozilla build fails because of C++11 user-defined literals

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |4.7.0

[Bug other/50916] -Os, -D_FORTIFY_SOURCE breaks strcpy & others if inlined

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Richard Guenther  2011-10-30 
09:12:28 UTC ---
extern __inline char *
 strcpy (char *__restrict __dest, const char *__restrict __src)

this should be marked with __attribute__((gnu_inline)), otherwise
it won't work with -std=c99.  GCC fix-includes glibc headers for this,
so this is a packaging bug on the debian side, please file it there.

[Bug libstdc++/50915] gcc fails at run time due to undefined libintl_textdomain

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID

--- Comment #2 from Richard Guenther  2011-10-30 
09:14:47 UTC ---
You used --with-included-gettext, that's probably breaking things for you
(together with -nodefaultlibs I guess).

Anyway, 3.4.3 is no longer supported.

[Bug tree-optimization/50912] [4.7 regression] gimple assertion failure at gimple.h:1940 with -msse2

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug target/50911] [4.7 regression] assertion failure in expand_vec_perm_interleave2 with -msse

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug tree-optimization/50908] [4.7 Regression] building emacs-23.3; gives msg: indent.c:1140:1: internal compiler error: in verify_dominators, at dominance.c:1041

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org
  Component|c   |tree-optimization
   Target Milestone|--- |4.7.0
Summary|building emacs-23.3; gives  |[4.7 Regression] building
   |msg: indent.c:1140:1:   |emacs-23.3; gives msg:
   |internal compiler error: in |indent.c:1140:1: internal
   |verify_dominators, at   |compiler error: in
   |dominance.c:1041|verify_dominators, at
   ||dominance.c:1041

[Bug c++/50917] [4.7 Regression] Mozilla build fails because of C++11 user-defined literals

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords|rejects-valid   |

--- Comment #1 from Markus Trippelsdorf  
2011-10-30 09:28:51 UTC ---
IOW:

 % cat test.cpp
#include 
#define MOZ_DLL_SUFFIX ".so"
int main () {
  char lastSlash[4096];
  snprintf(lastSlash, 4096 , "/" "libxul"MOZ_DLL_SUFFIX);
}

 % g++ test.cpp -std=gnu++0x
test.cpp: In function ‘int main()’:
test.cpp:5:34: error: unable to find user-defined string literal operator
‘operator"" MOZ_DLL_SUFFIX’

[Bug tree-optimization/50908] [4.7 Regression] building emacs-23.3; gives msg: indent.c:1140:1: internal compiler error: in verify_dominators, at dominance.c:1041

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |vries at gcc dot gnu.org
   |gnu.org |

--- Comment #2 from vries at gcc dot gnu.org 2011-10-30 09:39:19 UTC ---
Not fixed by patch for PR50878:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02783.html

[Bug rtl-optimization/50904] Induct benchmark of polyhedron slows down when -fno-protect-parens is enabled by -Ofast.

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther  2011-10-30 
09:40:38 UTC ---
I don't see why RTL invariant motion should move the one variant but not
the other.  Of course this also shows that we should, after loop unrolling
on the tree level, also perform loop invariant motion again ...

[Bug rtl-optimization/50904] Induct benchmark of polyhedron slows down when -fno-protect-parens is enabled by -Ofast.

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #3 from Richard Guenther  2011-10-30 
09:41:23 UTC ---
It would be nice if somebody could reduce this to a more managable testcase.

[Bug tree-optimization/50902] [4.7 Regression] intVar/dinternal.cc ICEs at -O2 -ftree-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Component|middle-end  |tree-optimization
   Target Milestone|--- |4.7.0
Summary|intVar/dinternal.cc ICEs at |[4.7 Regression]
   |-O2 -ftree-vectorize|intVar/dinternal.cc ICEs at
   ||-O2 -ftree-vectorize

[Bug fortran/50919] New: [OOP] Don't use vtable for NON_OVERRIDABLE TBP

[burnus at gcc dot gnu.org]

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

 Bug #: 50919
   Summary: [OOP] Don't use vtable for NON_OVERRIDABLE TBP
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org


Current, gfortran uses always a vtable for type-bound procedures. However, a
vtable only makes sense if the type-bound procedure can be overridden (C++: if
it is "virtual").

Expected:
a) gfortran call the procedure directly, which allows for inlining and avoids
the pointer dereference.

b) When the ABI is changed, the procedure is no longer added to the vtable.
Hence, it should be added as item to
http://gcc.gnu.org/wiki/LibgfortranAbiCleanup


Test case. The dump shows the following rather than a simple "test ()":

callit (struct __class_m_T & restrict x)
{
  x->_vptr->test ();



module m
type t
contains
  procedure, nopass, NON_OVERRIDABLE :: test
end type t
contains
  subroutine test()
print *, "t's test"
  end subroutine test

  subroutine callit(x)
class(t) :: x
call x%test()
  end subroutine
end module m
tob@archimedes:/dev/shm> less poly.f90.*
tob@archimedes:/dev/shm> cat poly.f90
module m
type t
contains
  procedure, nopass, NON_OVERRIDABLE :: test
end type t
contains
  subroutine test()
print *, "t's test"
  end subroutine test

  subroutine callit(x)
class(t) :: x
call x%test()
  end subroutine
end module m

[Bug c++/50881] ICE Segfault on compare this pointer with reference

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||rguenth at gcc dot gnu.org

--- Comment #5 from Paolo Carlini  2011-10-30 
10:12:35 UTC ---
Richard I just checked the preprocessed (on x86_64 -m32) and apparently
mainline is Ok, 4_6-branch Seg Faults at tree-cfg.c:1083, I'm not sure it's a
C++ issue.

[Bug c++/50881] ICE Segfault on compare this pointer with reference

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|rguenth at gcc dot gnu.org  |

--- Comment #6 from Paolo Carlini  2011-10-30 
10:14:40 UTC ---
Oops.

[Bug c++/50917] [4.7 Regression] Mozilla build fails because of C++11 user-defined literals

[markus at trippelsdorf dot de]

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

--- Comment #2 from Markus Trippelsdorf  
2011-10-30 10:20:42 UTC ---
Another example (happened later in Mozilla build, after putting
a space between "libxul"MOZ_DLL_SUFFIX):

struct  SECMODModule *nssMod = SECMOD_CreateModule(__null,
"NSS Internal PKCS #11 Module", __null,
"Flags=internal,critical"fips" slotparams=(""1""={"SECMOD_SLOT_FLAGS"})");

 % c++ -std=gnu++0x test.ii
test.ii:3:48: error: inconsistent user-defined literal suffixes ‘fips’ and
‘SECMOD_SLOT_FLAGS’ in string literal
test.ii:3:69: error: unable to find user-defined string literal operator
‘operator"" fips’
test.ii:3:73: error: ‘SECMOD_CreateModule’ was not declared in this scope

[Bug other/50916] -Os, -D_FORTIFY_SOURCE breaks strcpy & others if inlined

[aurelien at aurel32 dot net]

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

Aurelien Jarno  changed:

   What|Removed |Added

 CC||aurelien at aurel32 dot net

--- Comment #2 from Aurelien Jarno  2011-10-30 
10:21:29 UTC ---
Maybe GCC fixes the GLIBC headers, but how is it supposed to work if the GLIBC
is reinstalled after GCC? This solution doesn't really seem to scale very well
given the chicken and egg problem between GCC and GLIBC.

[Bug c++/50848] [4.7 Regression] ICE in derived template class missing using for member of template base class

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2011-10-30 
10:30:35 UTC ---
With -fpermissive ICEs for me, however:

50848.C: In member function ‘void B::f()’:
50848.C:2:53: warning: there are no arguments to ‘u’ that depend on a template
parameter, so a declaration of ‘u’ must be available [-fpermissive]
50848.C: In instantiation of ‘void B::f() [with T = int]’:
50848.C:3:16:   required from here
50848.C:2:50: warning: ‘u’ was not declared in this scope, and no declarations
were found by argument-dependent lookup at the point of instantiation
[-fpermissive]
50848.C:2:50: internal compiler error: tree check: expected tree that contains
‘decl minimal’ structure, have ‘indirect_ref’ in tsubst_copy_and_build, at
cp/pt.c:13529

[Bug target/50875] O3 and -mavx lead to internal compiler error: in find_reloads

[uros at gcc dot gnu.org]

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

--- Comment #9 from uros at gcc dot gnu.org 2011-10-30 10:30:11 UTC ---
Author: uros
Date: Sun Oct 30 10:30:06 2011
New Revision: 180676

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180676
Log:
PR target/50875
* config/i386/sse.md (*avx_unpcklpd256): Remove extra insn
constraints.  Change alternative 1 to "x,m,1".

testsuite/ChangeLog:

PR target/50875
* gfortran.dg/pr50875.f90: New test.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr50875.f90
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/config/i386/sse.md
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog

[Bug other/50916] -Os, -D_FORTIFY_SOURCE breaks strcpy & others if inlined

[ar...@pld-linux.org]

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

Arkadiusz Miskiewicz  changed:

   What|Removed |Added

 CC||ar...@pld-linux.org

--- Comment #3 from Arkadiusz Miskiewicz  2011-10-30 
10:33:49 UTC ---
$ pwd
/home/users/arekm/gcc-4.6.2/host-x86_64-unknown-linux-gnu/stage1-gcc/include-fixed
$ LC_ALL=C grep -r strcpy .
./nss/secport.h:#define PORT_Strcpy strcpy
grep: ./qt4/phonon: No such file or directory
./slang/slang.h:SL_EXTERN char *SLstrcpy(register char *, register char *);

Actually I don't see gcc fixincl fixing these glibc headers.

[Bug other/50916] -Os, -D_FORTIFY_SOURCE breaks strcpy & others if inlined

[pluto at agmk dot net]

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

Pawel Sikora  changed:

   What|Removed |Added

 CC||pluto at agmk dot net

--- Comment #4 from Pawel Sikora  2011-10-30 10:46:48 
UTC ---
(In reply to comment #3)
> $ pwd
> /home/users/arekm/gcc-4.6.2/host-x86_64-unknown-linux-gnu/stage1-gcc/include-fixed
> $ LC_ALL=C grep -r strcpy .
> ./nss/secport.h:#define PORT_Strcpy strcpy
> grep: ./qt4/phonon: No such file or directory
> ./slang/slang.h:SL_EXTERN char *SLstrcpy(register char *, register char *);
> 
> Actually I don't see gcc fixincl fixing these glibc headers.

gcc's fixincl doesn't touch  which redefines some str*
functions.

[Bug bootstrap/43328] multilib bootstrap broken.

[alexandre.nunes at gmail dot com]

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

Alexandre Pereira Nunes  changed:

   What|Removed |Added

 CC||alexandre.nunes at gmail
   ||dot com

--- Comment #21 from Alexandre Pereira Nunes  
2011-10-30 11:20:11 UTC ---
Building gcc 4.6.2 as a cross-compiler on ix86 targetting arm-elf fails for me
w/ --enable-multilib explicitly passed on, w/ zlib barking about trying to
compile a 64-bit version. gcc 4.6.1 used to work w/ same directives, so I
suspect I'm seeing a regression.

removing --enable-multilib from args passed to gcc seems to make the issue go
away.

[Bug rtl-optimization/50904] Induct benchmark of polyhedron slows down when -fno-protect-parens is enabled by -Ofast.

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2011-10-30 
11:24:57 UTC ---
> It would be nice if somebody could reduce this to a more managable testcase.

I have posted a reduced test in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265#c34 (pr34265).

[Bug rtl-optimization/50904] Induct benchmark of polyhedron slows down when -fno-protect-parens is enabled by -Ofast.

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  2011-10-30 
11:34:15 UTC ---
Created attachment 25666
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25666
Further reduced test for induct.f90

The reduced test contains a single et of nested loops in
mutual_ind_quad_cir_coil.  Using the main program in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265#c34 (induct_red.f90), the
execution time is 2.0s when induct_qc.f90 is compiled with -Ofast and 1.8s when
it is compiled with -fprotect-parens -Ofast.

[Bug target/50875] O3 and -mavx lead to internal compiler error: in find_reloads

[ubizjak at gmail dot com]

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

Uros Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-10/msg02477.htm
   ||l
 Resolution||FIXED
   Target Milestone|--- |4.5.4

--- Comment #10 from Uros Bizjak  2011-10-30 11:34:37 
UTC ---
Fixed.

[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-10-30
 Ever Confirmed|0   |1

--- Comment #3 from janus at gcc dot gnu.org 2011-10-30 11:38:28 UTC ---
Note that the segfault on the code in comment #0 is gone by now. With 4.6 and
trunk one currently gets:

  u = (u)*2.
  1
Error: Operands of binary numeric operator '*' at (1) are CLASS(field)/REAL(4)

(which is the same error as on comment #2.)

This error is due to the fact that the operator is not replaced by a TBP call
(which in turn is due to the parenthesis, which is not optimized away).


Also note that comment #0 is invalid (since it is missing a defined assignment
for type 'field'), as 4.5 reports:

  u = (u)*2.
  1
Error: Variable must not be polymorphic in assignment at (1)

[Bug c++/50917] [4.7 Regression] Mozilla build fails because of C++11 user-defined literals

[markus at trippelsdorf dot de]

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

--- Comment #3 from Markus Trippelsdorf  
2011-10-30 12:22:30 UTC ---
The problem in comment 2 is fixed by:

replacing:
#define SECMOD_MAKE_NSS_FLAGS(fips,slot) \
"Flags=internal,critical"fips" slotparams=("#slot"={"SECMOD_SLOT_FLAGS"})"
with:
#define SECMOD_MAKE_NSS_FLAGS(fips,slot) \  
"Flags=internal,critical" fips" slotparams=("#slot"={" SECMOD_SLOT_FLAGS"})"

in nss/secmodt.h

So I guess this bug is invalid, because the compiler is right to 
issue an error according to the new standard (2.14.8).

[Bug c++/50920] New: add a -std=c++11 option to the driver

[vanboxem.ruben at gmail dot com]

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

 Bug #: 50920
   Summary: add a -std=c++11 option to the driver
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vanboxem.ru...@gmail.com


Since the new Standard has been ratified and published, I think it's more than
time this gets added. In the next release, there could be a warning about the
deprecation of -std=c++0x in favor of the new one.

[Bug target/50749] SH Target: Post-increment addressing used only for first memory access

[oleg.e...@t-online.de]

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

--- Comment #5 from Oleg Endo  2011-10-30 12:36:51 UTC 
---
(In reply to comment #4)
> 
> I'm a bit curious to see what happens if they are changed
> to non-zero for SI/DImode.

..not much actually. I've tried defining both as TARGET_SH1 and compared 
before/after CSiBE results.  No code size changes at all.  Also the micro test
cases do not seem to be affected by that.  Of course I might have missed some
border case...

[Bug middle-end/50823] [4.7 Regression] ICE in inline_small_functions, at ipa-inline.c:1407

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres  2011-10-30 
12:41:34 UTC ---
I get the same ICE when compiling the polyhedron test aermod.f90:

[macbook] lin/test% gfc aermod.f90 -O3 --param max-inline-insns-auto=198
aermod.f90:39103:0: internal compiler error: in inline_small_functions, at
ipa-inline.c:1413
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[macbook] lin/test% gfc aermod.f90 -O3 --param max-inline-insns-auto=197
[macbook] lin/test%

[Bug target/50694] SH Target: SH2A little endian does not actually work

[oleg.e...@t-online.de]

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

--- Comment #9 from Oleg Endo  2011-10-30 12:45:30 UTC 
---
(In reply to comment #8)
> (In reply to comment #7)
> 
> This problem doesn't require the theoretical/mathematical
> completeness.  There are many inappropriate combinations
> of options which don't get any warning when running compiler
> and configurations.  The important thing is to warn very
> confusing ones from the user's point of view.  So your patch
> in #6 or even one liner in #2 would be OK and enough for
> this PR, I think.

OK.  I think the SH1 check should be left out completely in this case.
If it is included, the default configuration (-m1 -mb) will fail to build
e.g. newlib.  I'd propose catching the SH2A case only, considering the user's
default -mb / -ml configuration.  If somebody configures the default to be -m2a
-ml then it will fail to build, but I guess only very few people will try to do
that anyway.

[Bug c++/50921] New: GCC cannot find dependent conversion-function-id even if there's a using declaration for it

[schaub.johannes at googlemail dot com]

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

 Bug #: 50921
   Summary: GCC cannot find dependent conversion-function-id even
if there's a using declaration for it
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: schaub.johan...@googlemail.com


The following code should compile but doesn't.

--- snip
template
struct Type { int x; };

template
struct Base {
  operator Type();
};

template
struct Derived : Base {
  using Base::operator Type;
  void f() { 
int x = operator Type().x; 
(void) x;
  }
};

int main() {
  Derived d;
  d.f();
}
--- snap

Error:
--- snip
main1.cpp:13:30: error: there are no arguments to 'operator Type' that
depend on a template parameter, so a declaration of 'operator Type' must be
available
--- snap

The function call is dependent by the dependent function name itself, it
doesn't need dependent call arguments in this case in order to be dependent.

[Bug target/50749] SH Target: Post-increment addressing used only for first memory access

[oleg.e...@t-online.de]

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

--- Comment #6 from Oleg Endo  2011-10-30 13:53:51 UTC 
---
(In reply to comment #1)
> GCC makes usual mem accesses into those with post_inc/pre_dec at
> auto_inc_dec pass.  I guess that auto_inc_dec pass can't find
> post_inc insns well in that case because other tree/rtl optimizers
> tweak the code already.  If this is the case, the problem would be
> not target specific.

Looks like so.  For the simple test case...

int test (char* p, int c)
{
  int r = 0;
  r += *p++;
  r += *p++;
  r += *p++;
  return r;
}

...the load insns are initially expanded as:

(insn 2 5 3 2 (set (reg/v/f:SI 169 [ p ])
(reg:SI 4 r4 [ p ]))
 (nil))


(insn 7 6 8 3 (set (reg:SI 171)
(sign_extend:SI (mem:QI (reg/v/f:SI 169 [ p ]) [0 *p_2(D)+0 S1 A8]))) 
 (nil))


(insn 8 7 9 3 (set (reg:SI 172)
(reg/v/f:SI 169 [ p ]))
 (nil))


(insn 9 8 10 3 (set (reg/f:SI 173)
(plus:SI (reg/v/f:SI 169 [ p ])
(const_int 1 [0x1])))
 (nil))


(insn 10 9 11 3 (set (reg:SI 174)
(sign_extend:SI (mem:QI (reg/f:SI 173) [0 MEM[(char *)p_2(D) + 1B]+0 S1
A8])))
 (nil))

(insn 13 12 14 3 (set (reg/f:SI 177)
(plus:SI (reg/v/f:SI 169 [ p ])
(const_int 2 [0x2])))
 (nil))

(insn 14 13 15 3 (set (reg:SI 178)
(sign_extend:SI (mem:QI (reg/f:SI 177) [0 MEM[(char *)p_2(D) + 2B]+0 S1
A8])))
 (nil))


The auto_inc_dec pass then fails to realize that (reg:SI 177) = (reg:SI 169) +
2 = (reg:SI 173) + 1.

I wonder whether there might be something in the target code that suggests the
early optimizers to do that?  I've tried playing with the TARGET_ADDRESS_COST
hook but it didn't have any effect in this case.

[Bug c++/50921] GCC cannot find dependent conversion-function-id even if there's a using declaration for it

[schaub.johannes at googlemail dot com]

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

--- Comment #1 from Johannes Schaub  
2011-10-30 13:54:21 UTC ---
Someone notified me that you can substantially reduce this to the following

template
struct Base {
  operator int();
};

template
struct Derived : Base {
  using Base::operator int;
  void f() { 
int x = operator int(); 
(void) x;
  }
};

int main() {
  Derived d;
  d.f();
}

Same diagnostic is given.

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #8 from Steven Bosscher  2011-10-30 
14:23:24 UTC ---
Can you please see if the failure reproduces if you build (not bootstap!) a
compiler with --enable-checking=gcac.

[Bug middle-end/50913] ICE: compiling libgfortran for i686-w64-mingw32

[vanboxem.ruben at gmail dot com]

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

--- Comment #2 from Ruben Van Boxem  
2011-10-30 15:20:43 UTC ---
(In reply to comment #1)
> What was the ICE?

Sorry about that:
/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/generated/spread_i1.c: In
function 'spread_i1':
/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/generated/spread_i1.c:36:1:
internal compiler error: in scan_tree_for_params_right_scev, at
graphite-sese-to-poly.c:633

[Bug c/50922] New: infinite loop when optimized

[pfister at pci dot uzh.ch]

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

 Bug #: 50922
   Summary: infinite loop when optimized
Classification: Unclassified
   Product: gcc
   Version: 4.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pfis...@pci.uzh.ch


When a for loop should run 2^31 times, when optimized with -O2 becomes an
infinite loop.
Here the example programm:

#include 

void lcdSendData(unsigned long c)
{
 if((c&0xFF)==0)
  printf("%02lX ",(c>>24)&0xFF);
}

int main(void)
{
 long x=0;
 unsigned long c;
 for(c=0;c<2147483648UL;c++)
   {
  lcdSendData(x++);
}
 putc('\n',stdout);
 return 0;
}

and the outputs when compiling and running:

gcc -Wall -O1 loopbug2.c -o loopbug2
rolf@merkur:~/work/test/loopbug$ loopbug2
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19
1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33
34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D
4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67
68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F
rolf@merkur:~/work/test/loopbug$ gcc -Wall -O2 loopbug2.c -o loopbug2
rolf@merkur:~/work/test/loopbug$ loopbug2
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19
1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33
34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D
4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67
68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81
82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B
9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5
B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF
D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9
EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 F6 F7 F8 F9 FA FB FC FD FE FF 00 01 02 03
04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D
1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37
38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51
52 53 54 5^C
rolf@merkur:~/work/test/loopbug$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1

Same happens with gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1

Same problem in "avr-gcc (GCC) 4.3.3" with "char" and "uint8_t" instead of
"long" and "unsigned long". Then with 2^7 = 128 the bug occurs.

[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build

[andi-gcc at firstfloor dot org]

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

--- Comment #9 from Andi Kleen  2011-10-30 
15:53:10 UTC ---
Sorry made a mistake and i supplied the wrong command line

With this

gcc47 -O2 -m32-freg-struct-return io_apic.i -flto -c
gcc47 -O2 -flto io_apic.o

the test case ICEs hwith any path name.

I tested --enable-checking=gcac and expect for running extremly slowly it
didn't show any difference.

[Bug c/49934] gcc 4.6.1 messes up code

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot
   ||org

--- Comment #3 from Andi Kleen  2011-10-30 
16:06:12 UTC ---
My guess is that "FPGA_UART" is not declared volatile

[Bug lto/49677] GCC 4.6.0 LTO files not compatible with GCC 4.6.1

[andi-gcc at firstfloor dot org]

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot
   ||org

--- Comment #2 from Andi Kleen  2011-10-30 
16:14:06 UTC ---
This is a dup of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44965
Someone added a new option

I posted a patch to handle this specific case, but it wasn't accepted.
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00098.html

I believe there's an effort underway now to rewrite the lto option code which
will likely fix the problems.

Maybe the old patch is still a good idea for 4.6.x?

[Bug c/50922] infinite loop when optimized

[xunxun1982 at gmail dot com]

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

xunxun  changed:

   What|Removed |Added

 CC||xunxun1982 at gmail dot com

--- Comment #1 from xunxun  2011-10-30 16:26:26 
UTC ---
I found that when combining -O1, -fstrict-overflow and -ftree-vrp, the infinite
loop occured.
And -O2 contains -O1, -fstrict-overflow and -ftree-vrp .

[Bug c/50922] infinite loop when optimized

[mikpe at it dot uu.se]

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

--- Comment #2 from Mikael Pettersson  2011-10-30 
17:03:10 UTC ---
(In reply to comment #0)
> int main(void)
> {
>  long x=0;
>  unsigned long c;
>  for(c=0;c<2147483648UL;c++)
>{
>   lcdSendData(x++);
> }

You're causing a signed overflow in the "x++" expression.  Try making x
"unsigned long" instead.  Or pass "-fwrapv" to gcc.

[Bug middle-end/50598] [4.7 Regression] Undefined symbols: "___emutls_v.*", ... on *-apple-darwin*

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #6 from John David Anglin  2011-10-30 
17:17:57 UTC ---
Same failure on hppa*-*-hpux*.

[Bug fortran/50923] New: [4.4/4.5/4.6/4.7 Regression] No warning if function return value is not set

[burnus at gcc dot gnu.org]

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

 Bug #: 50923
   Summary: [4.4/4.5/4.6/4.7 Regression] No warning if function
return value is not set
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


The following program compiles without any warning (not even with -Wall
-Wextra).

Expected: A default-option warning like:

  integer pure function f()
  1
  Warning: Return value of function 'f' at (1) not set

Note: If one has a non-contained function, gfortran prints the warning shown
above - but for internal functions or module functions it does not. It also
works if one specifies a result(variable).

Note 2: In GCC 4.3 and earlier, the warning was printed by the middle end.


module m
contains
  integer pure function f()
  end function f
end module m

[Bug fortran/50924] New: Attempt to allocate negative amount of memory. Possible integer overflow

[fwi at inducks dot org]

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

 Bug #: 50924
   Summary: Attempt to allocate negative amount of memory.
Possible integer overflow
Classification: Unclassified
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: f...@inducks.org


When allocating a large array the progrem stops with:

Fortran runtime error: Attempt to allocate negative amount of memory. Possible
integer overflow

Test program:

  PROGRAM MAIN
  DOUBLE PRECISION, ALLOCATABLE :: E(:,:,:)
  INTEGER :: N
  N=645
  ALLOCATE(E(N,N,N))
  DEALLOCATE(E)
  END PROGRAM MAIN

With N=646:
$ gfortran -fbacktrace -g test.f90 && ./a.out 
Fortran runtime error: Attempt to allocate negative amount of memory. Possible
integer overflow

Backtrace for this error:
  + /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0xe2dbd6]

With N=645, the program works fine and takes 68.5% of the memory, so there
should be enough room for a 646^3 array (no other program is using a
significant amount of memory).

I believe the problem is that sizeof(double)=8 so the array size is:

8*(645^3) = 2 146 689 000 
8*(646^3) = 2 156 689 088

and: 2^31 = 2 147 483 648

So my guess is that the total amount of memory needed for the array is saved in
some integer, which overflows and become negative.

If that's of any use:

$ cat /proc/cpuinfo 
processor: 0
vendor_id: GenuineIntel
cpu family: 6
model: 23
model name: Intel(R) Celeron(R) CPUE3300  @ 2.50GHz
stepping: 10
cpu MHz: 2493.807
cache size: 1024 KB
physical id: 0
siblings: 2
core id: 0
cpu cores: 2
apicid: 0
initial apicid: 0
fdiv_bug: no
hlt_bug: no
f00f_bug: no
coma_bug: no
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips: 4987.61
clflush size: 64
cache_alignment: 64
address sizes: 36 bits physical, 48 bits virtual
power management:

processor: 1
vendor_id: GenuineIntel
cpu family: 6
model: 23
model name: Intel(R) Celeron(R) CPUE3300  @ 2.50GHz
stepping: 10
cpu MHz: 2493.807
cache size: 1024 KB
physical id: 0
siblings: 2
core id: 1
cpu cores: 2
apicid: 1
initial apicid: 1
fdiv_bug: no
hlt_bug: no
f00f_bug: no
coma_bug: no
fpu: yes
fpu_exception: yes
cpuid level: 13
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3
cx16 xtpr pdcm xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips: 4987.44
clflush size: 64
cache_alignment: 64
address sizes: 36 bits physical, 48 bits virtual
power management:

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04.3 LTS"

Thanks.

[Bug fortran/50924] Attempt to allocate negative amount of memory. Possible integer overflow

[fwi at inducks dot org]

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

fwi at inducks dot org changed:

   What|Removed |Added

 CC||fwi at inducks dot org

--- Comment #1 from fwi at inducks dot org 2011-10-30 18:52:10 UTC ---
NB: my system is 32-bit

[Bug fortran/50924] Attempt to allocate negative amount of memory. Possible integer overflow

[kargl at gcc dot gnu.org]

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

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 2011-10-30 18:55:09 UTC ---
(In reply to comment #1)
> NB: my system is 32-bit

What happens if you use 'INTEGER(8) N'?

You may simply be hitting an OS problem.  Your code
fails on i686-*-freebsd and runs fine on x86_64-*-freebsd.

The moral seems to be if you want to grab large chunks
of memory, get hardware that will it.

[Bug c/50925] New: avr ICE at spill_failure, at reload1.c:2118

[joel at gcc dot gnu.org]

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

 Bug #: 50925
   Summary: avr ICE at spill_failure, at reload1.c:2118
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


/home2/joel/build/b-avr-gcc/./gcc/xgcc -B/home2/joel/build/b-avr-gcc/./gcc/
-nostdinc -B/home2/joel/build/b-avr-gcc/avr-rtems4.11/avr25/newlib/ -isystem
/home2/joel/build/b-avr-gcc/avr-rtems4.11/avr25/newlib/targ-include -isystem
/users/joel/test-gcc/gcc-svn/newlib/libc/include
-B/users/joel/test-gcc/install-svn/avr-rtems4.11/bin/
-B/users/joel/test-gcc/install-svn/avr-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-svn/avr-rtems4.11/include -isystem
/users/joel/test-gcc/install-svn/avr-rtems4.11/sys-include  -mmcu=avr25
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.19.0\" -DPACKAGE_STRING=\"newlib\ 1.19.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I/users/joel/test-gcc/gcc-svn/newlib/libc/search -Os -DPREFER_SIZE_OVER_SPEED
-mcall-prologues -D_COMPILING_NEWLIB -DMALLOC_PROVIDED -DEXIT_PROVIDED
-DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE
-DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT
-D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -Wall -fno-builtin  -g
-O2  -mmcu=avr25 -c -o lib_a-twalk.o `test -f 'twalk.c' || echo
'/users/joel/test-gcc/gcc-svn/newlib/libc/search/'`twalk.c
/users/joel/test-gcc/gcc-svn/newlib/libc/search/hash.c: In function
'__expand_table':
/users/joel/test-gcc/gcc-svn/newlib/libc/search/hash.c:898:1: error: unable to
find a register to spill in class 'POINTER_REGS'
/users/joel/test-gcc/gcc-svn/newlib/libc/search/hash.c:898:1: error: this is
the insn:
(insn 172 96 173 10 (set (reg:QI 18 r18)
(mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 5 [0x5])) [16 S1 A8]))
/users/joel/test-gcc/gcc-svn/newlib/libc/search/hash.c:886 1 {movqi_insn}
 (nil))
/users/joel/test-gcc/gcc-svn/newlib/libc/search/hash.c:898:1: internal compiler
error: in spill_failure, at reload1.c:2118
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c/50922] infinite loop when optimized

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Andrew Pinski  2011-10-30 
19:14:49 UTC ---
Signed integer overflow is undefined so this is invalid.

[Bug c/50925] avr ICE at spill_failure, at reload1.c:2118

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  2011-10-30 19:42:50 
UTC ---
gcc (GCC) 4.7.0 20111029 (experimental)
Newlib up to date at same time


Cut and pasted from log with multiple jobs in parallel.  The actual command
line for hash.c was.

/home2/joel/build/b-avr-gcc/./gcc/xgcc -B/home2/joel/build/b-avr-gcc/./gcc/
-nostdinc -B/home2/joel/build/b-avr-gcc/avr-rtems4.11/avr25/newlib/ -isystem
/home2/joel/build/b-avr-gcc/avr-rtems4.11/avr25/newlib/targ-include -isystem
/users/joel/test-gcc/gcc-svn/newlib/libc/include
-B/users/joel/test-gcc/install-svn/avr-rtems4.11/bin/
-B/users/joel/test-gcc/install-svn/avr-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-svn/avr-rtems4.11/include -isystem
/users/joel/test-gcc/install-svn/avr-rtems4.11/sys-include  -mmcu=avr25
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.19.0\" -DPACKAGE_STRING=\"newlib\ 1.19.0\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
-I/users/joel/test-gcc/gcc-svn/newlib/libc/search -Os -DPREFER_SIZE_OVER_SPEED
-mcall-prologues -D_COMPILING_NEWLIB -DMALLOC_PROVIDED -DEXIT_PROVIDED
-DSIGNAL_PROVIDED -DREENTRANT_SYSCALLS_PROVIDED -DHAVE_NANOSLEEP -DHAVE_BLKSIZE
-DHAVE_FCNTL -DHAVE_ASSERT_FUNC -D_NO_GETLOGIN -D_NO_GETPWENT -D_NO_GETUT
-D_NO_GETPASS -D_NO_SIGSET -D_NO_WORDEXP -D_NO_POPEN -Wall -fno-builtin  -g
-O2 -c -o lib_a-hash.o `test -f 'hash.c' || echo
'/users/joel/test-gcc/gcc-svn/newlib/libc/search/'`hash.c

This shouldn't matter much except to have hash.c instead of twalk.c

[Bug c/50925] avr ICE at spill_failure, at reload1.c:2118

[joel at gcc dot gnu.org]

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

--- Comment #2 from Joel Sherrill  2011-10-30 19:43:24 
UTC ---
Created attachment 25667
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25667
Preprocessed output

Preprocessed code.

[Bug tree-optimization/50802] [4.7 Regression] FAIL: gcc.c-torture/execute/arith-rand-ll.c execution at -O2 and -Os

[danglin at gcc dot gnu.org]

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

--- Comment #5 from John David Anglin  2011-10-30 
19:59:27 UTC ---
Created attachment 25668
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25668
vrp dumps

[Bug fortran/50926] New: Output to 'fort.6" file instead of console

[dm.vl.ivanov at gmail dot com]

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

 Bug #: 50926
   Summary: Output to 'fort.6" file instead of console
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dm.vl.iva...@gmail.com


Console output suddenly stops to be console: at some point (usually when
write(*,*) and write(6,*) operators are being used for some times but non only
in that case, see the details below) the "fort.6" file is being created and
fill with the rest of program's output. Seems not a very big deal but it is
quite uncomfortable and eliminates the possibility to make a
console-interactive program. 

I also tried to avoid using "write" and mix my fortran code with C module
(compiled with g++) containing functions for console output. It helps just a
bit: some more strings go to the console and some less - to the "fort.6" file. 

This seems to be exactly the matter of compiler, not anything else: the same
code compiled with ifort runs just fine, no problems noticed. 

I imagine some more details would be good but my code is too big to upload
here. I can just tell some numbers: about 10 times write(*,*) and write(6,*)
functions produce their output to the console, all the rest - to the "fort.6"
file. When I use C functions instead of fortran's "write" this number becomes
slightly more, about 15 strings show up at the console. 

Environment: gcc version 4.6.1 (Debian 4.6.1-15), Debian testing/sid

[Bug middle-end/50708] Infinite loop between rshift_double and lshift_double if count is LONG_MIN

[mikpe at it dot uu.se]

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

--- Comment #5 from Mikael Pettersson  2011-10-30 
20:35:03 UTC ---
The regression started with r158372:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00478.html

Here's what seems to have happened:
1. Anatoly Sokolov suggested to add a bunch of double_int_ functions:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00482.html.

2. Eric Botcazou replied about the added double_int_rshift (a wrapper around
rshift_double) that the comment about the COUNT parameter was wrong, and that
rshift_double requires it to be positive (double_int_rshift stated that a
negative COUNT turned it into a left-shift):
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00557.html.

3. In the final version of Anatoly's patch committed in r158360:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00466.html, the comment above
rshift_double was changed to allow a negative COUNT as meaning a left-shift. 
However, the code in rshift_double was not changed, and still assumed that
COUNT would be positive.

4. Richard Guenther followed up with a cleanup patch to move rshift_double and
other related functions from fold-const.c to double-int.c in r158372:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00478.html.  However, rshift_double
was not copied verbatim, as a check for a negative COUNT was added at the
beginning followed by a conditional call to lshift_double with -COUNT.  This
made the code consistent with the comment, but also caused the loop on HWI32
platforms.

I suspect that r158360 shouldn't have allowed for a negative COUNT to
rshift_double or double_int_rshift.  Removing the check for negative COUNT from
the start of rshift_double does fix the test case on i686 with gcc-4.6.

However, I'm worried that parts of gcc now depend on the extended semantics of
rshift_double and double_int_rshift, so reverting that may be problematic. 
Instead we can robustify rshift_double a bit: if COUNT < 0, check if COUNT
equals INTTYPE_MINIMUM (HOST_WIDE_INT), and if so don't negate COUNT and call
lshift_double but instead set COUNT to 2 * HOST_BITS_PER_WIDE_INT.  The
following code will then handle this like other too-large shifts.  This fixes
the test case too with no testsuite regressions on i686 with gcc-4.6.

gcc-4.7 doesn't have the issue on i686 because i686 is now HWI64 (right?), but
other HWI32 platforms like m68k and arm-oabi still have the problem.  I'm
currently testing the 2nd patch with gcc-4.7 on i686 and x86_64.

[Bug c/26567] ICE in c_lex_with_flags, at c-lex.c:472 with cc1 -C (without -E)

[belyshev at depni dot sinp.msu.ru]

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

Serge Belyshev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2010-04/msg01592.htm
   ||l
  Known to work||4.6.0
 Resolution||FIXED
   Target Milestone|--- |4.6.0
  Known to fail||4.3.0, 4.4.0, 4.5.0

--- Comment #5 from Serge Belyshev  
2011-10-30 20:40:08 UTC ---
Was quietly fixed by r160100:

2010-06-01  Arnaud Charlet  
Matthew Gingell  

   * doc/invoke.texi: Mention -fdump-ada-spec.
   * tree-dump.c (dump_files): Add ada-spec.
   (FIRST_AUTO_NUMBERED_DUMP): Bump to 8.
   * tree-pass.h (tree_dump_index): Add TDI_ada.
   * gcc.c: Add support for -C without -E and for -fdump-ada-spec.
   (cpp_unique_options): Do not reject -C or -CC when -E isn't present.
   (default_compilers) <@c-header>: Allow -fdump-ada-spec on header files.
   * c-decl.c: Include c-ada-spec.h.
   (collect_source_ref_cb, collect_all_refs, for_each_global_decl): New
   functions.
   (c_write_global_declarations): Add handling of -fdump-ada-spec.
   * c-lex.c (c_lex_with_flags): Add handling of CPP_COMMENT.
   * Makefile.in (C_AND_OBJC_OBJS): Add c-ada-spec.o.
   * c-ada-spec.h, c-ada-spec.c: New files.

[Bug fortran/50926] Output to 'fort.6" file instead of console

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-10-30 20:55:52 UTC ---
(In reply to comment #0)

> I imagine some more details would be good but my code is too big to upload
> here. I can just tell some numbers: about 10 times write(*,*) and write(6,*)
> functions produce their output to the console, all the rest - to the "fort.6"
> file. When I use C functions instead of fortran's "write" this number becomes
> slightly more, about 15 strings show up at the console. 

This bug report is almost useless without the code.
Put the code someplace and post the URL.

Try compiling your code with -fcheck=all.

PS: If you're doing mix language programming, it is
advisable to use only Fortran IO or C IO.  Do not 
mix the two unless you know what happens under the
hood.

[Bug bootstrap/50927] New: lm32 ICE seg fauit compiling libgcc2

[joel at gcc dot gnu.org]

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

 Bug #: 50927
   Summary: lm32 ICE seg fauit compiling libgcc2
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


gcc (GCC) 4.7.0 20111029 (experimental)



/home2/joel/build/b-lm32-gcc/./gcc/xgcc -B/home2/joel/build/b-lm32-gcc/./gcc/
-nostdinc
-B/home2/joel/build/b-lm32-gcc/lm32-rtems4.11/mbarrel-shift-enabled/newlib/
-isystem
/home2/joel/build/b-lm32-gcc/lm32-rtems4.11/mbarrel-shift-enabled/newlib/targ-include
-isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include
-B/users/joel/test-gcc/install-svn/lm32-rtems4.11/bin/
-B/users/joel/test-gcc/install-svn/lm32-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-svn/lm32-rtems4.11/include -isystem
/users/joel/test-gcc/install-svn/lm32-rtems4.11/sys-include 
-mbarrel-shift-enabled -g -O2 -O2
-I/users/joel/test-gcc/gcc-svn/gcc/../newlib/libc/sys/rtems/include -I. -I.
-I/users/joel/test-gcc/gcc-svn/gcc -I/users/joel/test-gcc/gcc-svn/gcc/.
-I/users/joel/test-gcc/gcc-svn/gcc/../include
-I/users/joel/test-gcc/gcc-svn/gcc/../libdecnumber
-I/users/joel/test-gcc/gcc-svn/gcc/../libdecnumber/dpd -I../libdecnumber
-I/users/joel/test-gcc/gcc-svn/gcc/../libgcc -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc -G 0 -msign-extend-enabled -I. -I.
-I../../.././gcc -I/users/joel/test-gcc/gcc-svn/libgcc
-I/users/joel/test-gcc/gcc-svn/libgcc/.
-I/users/joel/test-gcc/gcc-svn/libgcc/../gcc
-I/users/joel/test-gcc/gcc-svn/libgcc/../include-o _ffssi2.o -MT _ffssi2.o
-MD -MP -MF _ffssi2.dep -DL_ffssi2 -c
/users/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcc2.c \

xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug bootstrap/50927] lm32 ICE seg fauit compiling libgcc2

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  2011-10-30 21:02:27 
UTC ---
Created attachment 25669
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25669
Preprocessed source code

[Bug c/50928] New: ICE building RTEMS

[joel at gcc dot gnu.org]

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

 Bug #: 50928
   Summary: ICE building RTEMS
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org


gcc (GCC) 4.7.0 20111029 (experimental)
Newlib cvs head as of same date

m32c-rtems4.11-gcc --pipe  -mcpu=m32cm --pipe -DHAVE_CONFIG_H   -I..
-I../../../lib/include -D__RTEMS_INSIDE__   -g -O2 -Wall
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs 
-mcpu=m32cm -MT src/libscore_a-heap.o -MD -MP -MF src/.deps/libscore_a-heap.Tpo
-c -o src/libscore_a-heap.o `test -f 'src/heap.c' || echo
'/users/joel/test-gcc/rtems/cpukit/score/'`src/heap.c
In file included from ../../../lib/include/rtems/score/basedefs.h:25:0,
 from ../../../lib/include/rtems/score/types.h:22,
 from ../../../lib/include/rtems/score/cpu.h:40,
 from ../../../lib/include/rtems/score/percpu.h:22,
 from ../../../lib/include/rtems/system.h:23,
 from /users/joel/test-gcc/rtems/cpukit/score/src/heap.c:28:
../../../lib/include/rtems/score/cpuopts.h:56:0: warning:
"__RTEMS_SIZEOF_VOID_P__" redefined [enabled by default]
In file included from /users/joel/test-gcc/rtems/cpukit/score/src/heap.c:23:0:
../config.h:465:0: note: this is the location of the previous definition
/users/joel/test-gcc/rtems/cpukit/score/src/heap.c: In function
'_Heap_Initialize':
/users/joel/test-gcc/rtems/cpukit/score/src/heap.c:300:1: error: unable to find
a register to spill in class 'A_REGS'
/users/joel/test-gcc/rtems/cpukit/score/src/heap.c:300:1: error: this is the
insn:
(insn 119 118 120 13 (set (mem/s:SI (subreg:PSI (reg/f:SI 30 [ first_block.3 ])
0) [3 first_block.3_22->prev_size+0 S4 A8])
(reg/v:SI 28 [ heap_area_end ]))
/users/joel/test-gcc/rtems/cpukit/score/src/heap.c:260 98 {movsi_24}
 (nil))
/users/joel/test-gcc/rtems/cpukit/score/src/heap.c:300:1: internal compiler
error: in spill_failure, at reload1.c:2118
Please submit a full bug report,

[Bug c/50928] ICE building RTEMS

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill  2011-10-30 21:09:56 
UTC ---
Created attachment 25670
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25670
Preprocessed source code

[Bug fortran/50924] Attempt to allocate negative amount of memory. Possible integer overflow

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Richard Guenther  2011-10-30 
21:55:06 UTC ---
The maximum object size that can be allocated is half of the virtual
address-space.  Your object is too large (this is a middle-end restriction,
documented
in the C implementation defined section of the manual - the same restriction
applies to fortran).

[Bug fortran/50923] [4.4/4.5/4.6/4.7 Regression] No warning if function return value is not set

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.4.7

[Bug other/50573] configure lists --with-gnu-ld twice

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org 2011-10-30 21:59:27 UTC ---
Author: kargl
Date: Sun Oct 30 21:59:24 2011
New Revision: 180686

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180686
Log:
2011-10-30  Steven G. Kargl  

PR fortran/50573
* check.c (gfc_check_dshift): Update argument checking for BOZ.
Update checking SHIFT against BITSIZE of I or J.
* intrinsic.texi: Update docs for DSHIFTL and DSHIFTR.

2011-10-30  Steven G. Kargl  

PR fortran/50573
* gfortran.dg/dshift_3.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dshift_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/testsuite/ChangeLog

[Bug fortran/50753] dshiftl/dshiftr: Rejects valid BOZ, accepts double BOZ

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #4 from kargl at gcc dot gnu.org 2011-10-30 22:03:30 UTC ---
Fixed on trunk.

[Bug other/50573] configure lists --with-gnu-ld twice

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #8 from kargl at gcc dot gnu.org 2011-10-30 22:08:36 UTC ---
(In reply to comment #7)
> Author: kargl
> Date: Sun Oct 30 21:59:24 2011
> New Revision: 180686
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180686
> Log:
> 2011-10-30  Steven G. Kargl  
> 
> PR fortran/50573

Damn. I transposed 50573 and 50753.  Sorry about the noise.

[Bug fortran/50753] dshiftl/dshiftr: Rejects valid BOZ, accepts double BOZ

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org 2011-10-30 22:09:50 UTC ---
Dang.  I transposed numbers in the PR in the ChangeLog.  Here's
the commit message with the correct PR number.

Author: kargl
Date: Sun Oct 30 21:59:24 2011
New Revision: 180686

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180686
Log:
2011-10-30  Steven G. Kargl  

PR fortran/50753
* check.c (gfc_check_dshift): Update argument checking for BOZ.
Update checking SHIFT against BITSIZE of I or J.
* intrinsic.texi: Update docs for DSHIFTL and DSHIFTR.

2011-10-30  Steven G. Kargl  

PR fortran/50753
* gfortran.dg/dshift_3.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/dshift_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/fortran/intrinsic.texi
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/39351] compute_init_costs uses unemitted insns

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #5 from Jorn Wolfgang Rennecke  
2011-10-30 22:44:10 UTC ---
rtl-factoring.c was deleted in r145374.

[Bug target/50749] SH Target: Post-increment addressing used only for first memory access

[kkojima at gcc dot gnu.org]

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

--- Comment #7 from Kazumoto Kojima  2011-10-30 
23:36:27 UTC ---
(In reply to comment #6)
> I wonder whether there might be something in the target code that suggests the
> early optimizers to do that?  I've tried playing with the TARGET_ADDRESS_COST
> hook but it didn't have any effect in this case.

-ftree-dump-all shows that forward propagation on ssa trees makes
those memory accesses into simple array accesses.  You can try
-fno-tree-forwprop and see the effect of that option.
It seems that there are no special knobs to control forwprop from
the target side.
The problem is that SH target can't do those simple array accesses
well at QI/HImode because of the lack of displacement addressing
for those modes.

[Bug bootstrap/50878] [4.7 Regression] ARM bootstrap failure on insn-preds.c with error: dominator of 12 should be 6, not 5

[joel at gcc dot gnu.org]

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

Joel Sherrill  changed:

   What|Removed |Added

 Target|arm-linux-gnueabi   |arm-linux-gnueabi
   ||arm-rtems4.11
 CC||joel at gcc dot gnu.org
   Host||x86_64-unknown-linux-gnu

--- Comment #10 from Joel Sherrill  2011-10-30 
23:52:21 UTC ---
FWIW I am using a native gcc on x86_64 to build cross *-rtems4.11 targets.  

gcc (GCC) 4.7.0 20111029 (experimental)

I think this is a native issue (x86_64-unknown-linux-gnu) that is showing up on
multiple odd situations.

I see this compiling arm-rtems4.11

And I think this is the same thing I saw with the native compiler of
yesterday's vintage compiling the head of binutils-cvs to target
sparc-rtems4.11

/users/joel/test-gcc/binutils-cvs/src/bfd/sunos.c: In function
‘sunos_check_dynamic_reloc’:
/users/joel/test-gcc/binutils-cvs/src/bfd/sunos.c:2328:1: error: dominator of
26 should be 20, not 19
/users/joel/test-gcc/binutils-cvs/src/bfd/sunos.c:2328:1: internal compiler
error: in verify_dominators, at dominance.c:1041

I can provide preprocessed source if someone needs it.

[Bug fortran/46328] [OOP] type-bound operator call with non-trivial polymorphic operand

[damian at rouson dot net]

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

--- Comment #4 from Damian Rouson  2011-10-31 
02:06:36 UTC ---
Thanks for the update.  The same error occurs when a defined assignment is
added:


$ cat abstract_field_expression.F90 
module field_module
  implicit none
  type ,abstract :: field
  contains
procedure(field_op_real) ,deferred :: multiply_real
procedure(field_eq_field) ,deferred :: assign
generic :: operator(*) => multiply_real
generic :: assignment(=) => assign
  end type
  abstract interface
function field_op_real(lhs,rhs)
  import :: field
  class(field) ,intent(in)  :: lhs
  real ,intent(in) :: rhs
  class(field) ,allocatable :: field_op_real
end function
subroutine field_eq_field(lhs,rhs)
  import :: field
  class(field) ,intent(inout)  :: lhs
  class(field) ,intent(in)  :: rhs
end subroutine
  end interface
end module

program main
  use field_module
  implicit none
  class(field) ,pointer :: u
  u = (u)*2.
end program

$ gfortran abstract_field_expression.F90 
abstract_field_expression.F90:29.6:

  u = (u)*2.
  1
Error: Operands of binary numeric operator '*' at (1) are CLASS(field)/REAL(4)

$ gfortran --version
GNU Fortran (GCC) 4.6.2 20111019 (prerelease)

[Bug rtl-optimization/49682] [alpha] gcc-4.6.1: ICE at -O2 and -O3

[mattst88 at gmail dot com]

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

Matt Turner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.6.2
 Resolution||FIXED

--- Comment #2 from Matt Turner  2011-10-31 03:48:14 
UTC ---
Indeed, this is fixed with 4.6.2.

[Bug bootstrap/50888] Bootstrap failure in libjava against latest git glibc

[christian.joensson at gmail dot com]

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

--- Comment #4 from Christian Joensson  
2011-10-31 05:29:38 UTC ---
Recent bootstrap/build on i686/linux

libtool: link: /usr/local/src/trunk/objdir/./gcc/gcj
-B/usr/local/src/trunk/objdir/i686-redhat-linux/libjava/
-B/usr/local/src/trunk/objdir/./gcc/ -B/usr/i686-redhat-linux/bin/
-B/usr/i686-redhat-linux/lib/ -isystem /usr/i686-redhat-linux/include -isystem
/usr/i686-redhat-linux/sys-include -ffloat-store -fomit-frame-pointer -Usun -g
-O2 -o .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc 
-L/usr/local/src/trunk/objdir/i686-redhat-linux/libjava/.libs
-L/usr/local/src/trunk/objdir/i686-redhat-linux/libjava ./.libs/libgcj.so
-lpthread -lrt -ldl -lz -Wl,-rpath -Wl,/usr/lib
./.libs/libgcj.so: undefined reference to `__cxa_call_unexpected'
collect2: error: ld returned 1 exit status
make[3]: *** [jv-convert] Error 1

[Bug c++/50929] New: [C++0x] Wrong function selected for overload with template and rvalue reference

[jarrydb at cse dot unsw.edu.au]

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

 Bug #: 50929
   Summary: [C++0x] Wrong function selected for overload with
template and rvalue reference
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jarr...@cse.unsw.edu.au


When choosing between a constructor

  A(const A& a)

and

  template 
  A(T&& t)

given an object of type A&, the compiler chooses the second function. For the
following code:

class A
{
  public:
  A() : value(0) {}

  A(const A& rhs) : value(1) { }

  A(A&& rhs) : value(2) { }

  template 
  A(T&& t) : value(3) { }

  int value;
};

int main()
{
  A a;
  A b = a;
  return b.value;
}

compiled with:
  g++ -std=gnu++0x rvalue_deduction.cpp

then running:
  ./a.out
  echo $?

the output is 
  3

I expect the output to be 1, not 3.


Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jarrydb/current/soft/install-latest/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/jarrydb/current/soft/src/gcc-git/configure
--prefix=/home/jarrydb/current/soft/install-latest --disable-multilib
--enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20111027 (experimental) (GCC)