[Bug bootstrap/54447] New: gmp in source does not work on alphaev68-dec-osf5.1a

[htl10 at users dot sourceforge.net]

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

 Bug #: 54447
   Summary: gmp in source does not work on alphaev68-dec-osf5.1a
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ht...@users.sourceforge.net


In the course of looking at bug 44959, I tried building gcc 4.6.1 with an
in-source sub-directory of gmp/mpfr/mpc, and encountered strange errors:

In file included from fib_table.c:4:0:
/home/htl10/tmp-build/gcc-4.6.1-build/../gcc-4.6.1/gmp/gmp-impl.h:187:1: error:
unknown type name 'uint_least32_t'
make[5]: *** [fib_table.lo] Error 1
make[5]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build/gmp/mpn'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build/gmp'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build/gmp'
make[2]: *** [all-stage2-gmp] Error 2
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build'
make: *** [all] Error 2

/home/htl10/tmp-build/gcc-4.6.1-build/../gcc-4.6.1/gmp/printf/doprnt.c: In
function '__gmp_doprnt':
/home/htl10/tmp-build/gcc-4.6.1-build/../gcc-4.6.1/gmp/printf/doprnt.c:273:8:
error: unknown type name 'intmax_t'
/home/htl10/tmp-build/gcc-4.6.1-build/../gcc-4.6.1/gmp/printf/doprnt.c:273:8:
internal compiler error: tree check: expected class 'type', 
have 'exceptional' (error_mark) in build_c_cast, at c-typeck.c:4541
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[5]: *** [doprnt.lo] Error 1
make[5]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build/gmp/printf'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build/gmp'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build/gmp'
make[2]: *** [all-stage2-gmp] Error 2
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build'
make: *** [all] Error 2


I tried working around the above errors as follows:

--- gmp-impl.h~2012-08-30 05:51:36.0 +0100
+++ gmp-impl.h2012-08-30 06:07:00.0 +0100
@@ -184,6 +184,8 @@


 /* gmp_uint_least32_t is an unsigned integer type with at least 32 bits. */
+#undef HAVE_UINT_LEAST32_T
+#undef HAVE_INTMAX_T
 #if HAVE_UINT_LEAST32_T
 typedef uint_least32_t  gmp_uint_least32_t;
 #else

--- vasprintf.c~2010-06-10 12:00:14.0 +0100
+++ vasprintf.c2012-08-30 06:15:36.0 +0100
@@ -52,6 +52,10 @@
 #include  /* for ptrdiff_t */
 #endif

+#ifndef SIZE_MAX
+#define SIZE_MAX (18446744073709551615UL)
+#endif
+
 #if HAVE_INTTYPES_H
 # include  /* for intmax_t */
 #else


the result still does not compare (bug likely due to other problems detailed in
44959). Anyhow, I suspect that the reasons for the above errors is that stage 1
uses system headers which do not have those C99(?) defines, but stage2 have
gcc's own patched headers, which have those defines, and therefore have those
config's during configure, but when it comes to actually compiling, still uses
the system headers, and therefore fails. These are my guesses.

[Bug target/54445] TLS array lookup with negative constant is not combined into a single instruction

[adam at consulting dot net.nz]

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

--- Comment #1 from Adam Warner  2012-09-01 
03:00:39 UTC ---
Another example:
$ cat negative_constant_not_combined_into_a_single_instruction_example_2.c 
#include 

__thread uint8_t byte_array[100];

uint64_t lookup_with_positive_constant(int64_t offset1, int64_t offset2) {
  return *((uint64_t *) (byte_array + 8*offset1 + offset2 + 1));
}

uint64_t lookup_with_negative_constant(int64_t offset1, int64_t offset2) {
  return *((uint64_t *) (byte_array + 8*offset1 + offset2 - 1));
}

int main(void) {
  return 0;
}

$ gcc -O3 -std=gnu11 -pthread
negative_constant_not_combined_into_a_single_instruction_example_2.c && objdump
-d -m i386:x86-64:intel a.out |less

00400540 :
  400540:   64 48 8b 84 fe 9d ffmovrax,QWORD PTR
fs:[rsi+rdi*8-0x63]
  400547:   ff ff 
  400549:   c3  ret

00400550 :
  400550:   64 48 8b 14 25 00 00movrdx,QWORD PTR fs:0x0
  400557:   00 00 
  400559:   48 8d 04 fe learax,[rsi+rdi*8]
  40055d:   48 81 c2 9c ff ff ffaddrdx,0xff9c
  400564:   48 8b 44 02 ff  movrax,QWORD PTR [rdx+rax*1-0x1]
  400569:   c3  ret

The memory load expands into four instructions when subtracting 1 from the byte
offset instead of adding 1.

[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

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

--- Comment #29 from Hin-Tak Leung  
2012-09-01 02:53:00 UTC ---
Created attachment 28115
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28115
sets of failed-to-compare objs from 4.7.1

tgz'ed, failed-to-compared obj's from 4.7.1 .

stage2 always a lot smaller. I think it is from -gtoggle. Elsewhere there are a
few other bugs from this switch for other unusual architectures.

[Bug target/54446] Stack needlessly aligned with AVX

[cesarb at cesarb dot net]

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

--- Comment #1 from Cesar Eduardo Barros  2012-09-01 
01:23:48 UTC ---
Created attachment 28114
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28114
testcase

[Bug target/54436] [4.7/4.8 Regression] Compiling some regular C++ code gives assembler '700415 shortened to 255' warning

[mathias at gaunard dot com]

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

--- Comment #3 from Mathias Gaunard  2012-09-01 
01:23:04 UTC ---
While a warning is emitted, is the code in the end still valid or is that a
miscompilation?

[Bug target/54446] New: Stack needlessly aligned with AVX

[cesarb at cesarb dot net]

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

 Bug #: 54446
   Summary: Stack needlessly aligned with AVX
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ces...@cesarb.net


When compiling the following small function, gcc aligns the stack, even though
the function does not store any AVX values in the stack:

bool test(__m256i *p)
{
__m256i x = _mm256_load_si256(p);
return _mm256_testz_si256(x, x);
}

The generated assembly output is:

test:
pushq%rbp
movq%rsp, %rbp
andq$-32, %rsp
addq$16, %rsp
vmovdqa(%rdi), %ymm0
vptest%ymm0, %ymm0
leave
sete%al
vzeroupper
ret

The assembly output should instead be something like:

test:
vmovdqa(%rdi), %ymm0
vptest%ymm0, %ymm0
sete%al
vzeroupper
ret

The command line is "gcc -mavx -std=c99 -O3 -Wall -Wextra -Werror -save-temps".

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.3/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC)

[Bug target/54445] New: TLS array lookup with negative constant is not combined into a single instruction

[adam at consulting dot net.nz]

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

 Bug #: 54445
   Summary: TLS array lookup with negative constant is not
combined into a single instruction
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@consulting.net.nz


I have encountered a weird Thread Local Storage issue where negative constants
in an array lookup statement are not combined into a single memory load
instruction. Non-negative constant are handled OK.

$ cat
tls_array_lookup_with_negative_constant_not_combined_into_a_single_instruction.c
 
#include 

uint8_t array[64];
__thread uint8_t tls_array[64];

uint8_t array_lookup_with_positive_constant(int64_t position) {
  return array[position + 1];
}

uint8_t array_lookup_with_negative_constant(int64_t position) {
  return array[position - 1];
}

uint8_t tls_array_lookup_with_positive_constant(int64_t position) {
  return tls_array[position + 1];
}

uint8_t tls_array_lookup_with_negative_constant(int64_t position) {
  return tls_array[position - 1];
}

int main(void) {
  return 0;
}

$ gcc -O3 -std=gnu11 -pthread
tls_array_lookup_with_negative_constant_not_combined_into_a_single_instruction.c
&& objdump -d -m i386:x86-64:intel a.out |less

00400540 :
  400540:   0f b6 87 e1 09 60 00movzx  eax,BYTE PTR [rdi+0x6009e1]
  400547:   c3  ret
  400548:   0f 1f 84 00 00 00 00nopDWORD PTR [rax+rax*1+0x0]
  40054f:   00 

00400550 :
  400550:   0f b6 87 df 09 60 00movzx  eax,BYTE PTR [rdi+0x6009df]
  400557:   c3  ret
  400558:   0f 1f 84 00 00 00 00nopDWORD PTR [rax+rax*1+0x0]
  40055f:   00 

00400560 :
  400560:   64 0f b6 87 c1 ff ffmovzx  eax,BYTE PTR fs:[rdi-0x3f]
  400567:   ff 
  400568:   c3  ret
  400569:   0f 1f 80 00 00 00 00nopDWORD PTR [rax+0x0]

00400570 :
  400570:   48 c7 c0 c0 ff ff ffmovrax,0xffc0
  400577:   64 0f b6 44 07 ff   movzx  eax,BYTE PTR fs:[rdi+rax*1-0x1]
  40057d:   c3  ret
  40057e:   90  nop
  40057f:   90  nop

I believe tls_array_lookup_with_negative_constant should generate the
instruction movzx eax,BYTE PTR fs:[rdi-0x41]

Note: I initially observed the issue with the cmp instruction (e.g. mov
rax,0xfdc0; cmp BYTE PTR fs:[rax+rcx*1-0x80],r8b) so the issue is
likely to apply to all x86-64 instructions that perform a TLS memory load with
a negative constant.

[Bug fortran/54443] Segmentation Fault when Compiling for code using Fortran Polymorphic Entities

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2012-09-01 
00:30:05 UTC ---
Compiling the following reduced test

program class_test
  type hashnode
!character(12) :: name
character(4) :: htype
  end type hashnode
  class(hashnode), pointer :: hfirst,hcur,hp

select type(hp%htype)

end program class_test

gives an internal compiler error: Segmentation fault with trunk, but the error

pr54443_red.f90:8.25:

select type(hp%htype)
 1   
Error: Selector in SELECT TYPE at (1) is not a named variable; use
associate-name=>

if I uncomment the line character(12) :: name, while it still gives an ICE with
4.7.1.

The backtrace for trunk is

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x
gfc_match_select_type () at ../../work/gcc/fortran/match.c:5438
5438  && (strcmp (CLASS_DATA (expr1)->name, "_data") == 0)
(gdb) bt
#0  gfc_match_select_type () at ../../work/gcc/fortran/match.c:5438
#1  0x000100078fea in match_word (subr=, old_locus=0x100ea35e0) at ../../work/gcc/fortran/parse.c:67
#2  0x00014180f750 in ?? ()
Previous frame inner to this frame (gdb could not unwind past this frame)

[Bug fortran/54443] Segmentation Fault when Compiling for code using Fortran Polymorphic Entities

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  2012-09-01 
00:06:53 UTC ---
AFAICT the code is invalid:

pr54443.f90:43.25:

select type(hp%htype)
 1
Error: Selector in SELECT TYPE at (1) is not a named variable; use
associate-name=>
...

>From my archives, it seems to have been fixed on trunk between revisions
187200, 2012-05-05 (Segmentation fault) and 187291, 2012-05-08 (errors) and it
has been introduced between revisions 182107, 2011-12-08 (errors) and 183001,
2012-01-27 (Segmentation fault).

[Bug bootstrap/54444] New: 32-bit glibc development headers required on GNU/Linux x86_64, but not checked during configure

[gerald at pfeifer dot com]

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

 Bug #: 5
   Summary: 32-bit glibc development headers required on GNU/Linux
x86_64, but not checked during configure
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ger...@pfeifer.com


In the last week I twice ran into a variation of the following on two
different systems (operating systems):

In file included from /usr/include/features.h:382:0,
 from /usr/include/stdio.h:28,
 from /home/gp/svn/gcc-HEAD/libgcc/../gcc/tsystem.h:88,
 from /home/gp/svn/gcc-HEAD/libgcc/libgcc2.c:29:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or
directory
 # include 
   ^
compilation terminated.
gmake[5]: *** [_muldi3.o] Error 1
gmake[5]: Leaving directory
`/tmp/OBJ-0901-0046/x86_64-unknown-linux-gnu/32/libgcc'

The fix is simple -- install 32-bit glibc development headers.  On openSUSE
this is in the glibc-devel-32bit package, and there are similar packages on
other distributions.

Instead of failing during the build, can we test this at configure time?

[Bug fortran/54443] New: Segmentation Fault when Compiling for code using Fortran Polymorphic Entities

[mbeyer at cirrusaircraft dot com]

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

 Bug #: 54443
   Summary: Segmentation Fault when Compiling for code using
Fortran Polymorphic Entities
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mbe...@cirrusaircraft.com


Created attachment 28113
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28113
Sample Code

$gfortran --version

GNU Fortran (GCC) 4.7.2 20120818 (prerelease)
Copyright (C) 2012 Free Software Foundation, Inc.

$gfortran -C class.f03 -o class

f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

See attached code.

[Bug c++/18747] "template<> int i;" accepted

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  2012-08-31 
21:35:38 UTC ---
Author: jason
Date: Fri Aug 31 21:35:33 2012
New Revision: 190842

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190842
Log:
PR c++/18747
* pt.c (check_template_variable): New.
(num_template_headers_for_class): Split out...
* decl.c (grokdeclarator): ...from here.
(start_decl): Remove redundant diagnostic.
* cp-tree.h: Declare them
* parser.c (cp_parser_single_declaration): Call check_template_variable.
.

Added:
trunk/gcc/testsuite/g++.dg/parse/error50.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug target/54061] [4.8 Regression] gcc.c-torture/compile/mipscop-*.c ICEs with -g

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-31
 CC||sje at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Steve Ellcey  2012-08-31 21:27:26 
UTC ---
I sent a question to g...@gcc.gnu.org to see if I could get some idea of how to
fix this bug.

http://gcc.gnu.org/ml/gcc/2012-08/msg00359.html

[Bug c++/54442] Const overloads resolution failure

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||glisse at gcc dot gnu.org

--- Comment #2 from Marc Glisse  2012-08-31 20:40:55 
UTC ---
"using" and "extern"C"" are not guilty:

struct S
{
  void s (int) const throw ();
  void s (int) throw ();
};

typedef int index_t;

void (S::*f) (index_t)   = &S::s;
void (S::*g) (index_t) const = &S::s;

The bogus pretty printing with attribute((const)) is PR 48665.

[Bug c++/54442] Const overloads resolution failure

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #1 from Daniel Krügler  
2012-08-31 20:13:42 UTC ---
For gcc 4.8.0 20120819 (experimental) I'm getting an ICE instead:

"20|internal compiler error: canonical types differ for identical types
void(index_t)__attribute__((const)) {aka void(int)__attribute__((const)) throw
()} and void(int)__attribute__((const)) throw ()"

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

[fabien at gcc dot gnu.org]

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

fabien at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-08-31
 Ever Confirmed|0   |1
  Known to fail||4.6.3, 4.7.0, 4.8.0

--- Comment #3 from fabien at gcc dot gnu.org 2012-08-31 20:04:41 UTC ---
(In reply to comment #2)
> Fabien, you may be interested in this one.

Indeed! Thanks for notifying me.

[Bug c++/54442] New: Const overloads resolution failure

[nikkoara at hates dot ms]

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

 Bug #: 54442
   Summary: Const overloads resolution failure
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nikko...@hates.ms


gcc fails to take address of const overloads, possibly confused by the index_t
typedef:

$ gcc -v; cat t.cpp; gcc -c t.cpp
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/gcc/4_7_1/libexec/gcc/x86_64-slackware-linux/4.7.1/lto-wrapper
Target: x86_64-slackware-linux
Configured with: ../gcc-4.7.1/configure --prefix=/opt/gcc/4_7_1
--libdir=/opt/gcc/4_7_1/lib64 --enable-languages=c,c++ --enable-threads=posix
--enable-shared --enable-checking=release --with-system-zlib
--disable-libunwind-exceptions --enable-__cxa_atexit
--target=x86_64-slackware-linux --build=x86_64-slackware-linux
--host=x86_64-slackware-linux --enable-multilib
Thread model: posix
gcc version 4.7.1 (GCC) 
namespace X {

struct S
{
void s (int) const throw ();
void s (int) throw ();
};

}

extern "C" {
typedef int index_t;
}

namespace X {
using ::index_t;
} 

void (X::S::*f) (X::index_t) = &X::S::s;
void (X::S::*g) (X::index_t) const = &X::S::s;

t.cpp:20:45: error: no matches converting function 's' to type 'void (struct
X::S::*)(index_t)const {aka void (struct X::S::*)(int)const}'
t.cpp:6:10: error: candidates are: void X::S::s(int)
t.cpp:5:10: error: void X::S::s(int) const


Thanks.

Liviu

[Bug c++/54441] New: Infinite loop with brace initializer on zero-length array

[strikosn at gmail dot com]

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

 Bug #: 54441
   Summary: Infinite loop with brace initializer on zero-length
array
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: strik...@gmail.com


Consider this:

struct s { char c[]; };

int main()
{
struct s s = { .c = 0 };
return 0;
}

Compiling with 'g++ -Wall h.c' gives infinite warnings:

h.c: In function 'int main()':
h.c:5:24: warning: missing braces around initializer for 'char [0]'
[-Wmissing-braces]
h.c:5:24: warning: missing braces around initializer for 'char [0]'
[-Wmissing-braces]
h.c:5:24: warning: missing braces around initializer for 'char [0]'
[-Wmissing-braces]
h.c:5:24: warning: missing braces around initializer for 'char [0]'
[-Wmissing-braces]
...

Version: GNU C++ (GCC) version 4.7.0
Target: x86_64-unknown-linux-gnu

[Bug c/54428] [4.7/4.8 Regression] ICE in gimplify_expr, at gimplify.c:7591

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2012-08-31 
19:01:05 UTC ---
Author: jakub
Date: Fri Aug 31 19:00:59 2012
New Revision: 190840

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190840
Log:
PR c/54428
* c-convert.c (convert): Don't call fold_convert_loc if
TYPE_MAIN_VARIANT of a COMPLEX_TYPE is the same, unless e
is a COMPLEX_EXPR.  Remove TYPE_MAIN_VARIANT check from
COMPLEX_TYPE -> COMPLEX_TYPE conversion.

* gcc.c-torture/compile/pr54428.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr54428.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-convert.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/54369] Delayed-branch pass in reorg.c removes too many instructions

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #6 from Eric Botcazou  2012-08-31 
18:55:11 UTC ---
> Thanks for digging into this Eric.  I tested your patch here against the
> example and on the GCC testsuite and didn't see any problems.

You're welcome.  Thanks for the testing.

> Are you going to check this in on the mainline?

Not without Richard's approval, so I've CCed him now.

[Bug target/54338] internal compiler error: in find_costs_and_classes, at ira-costs.c:1711

[vmakarov at gcc dot gnu.org]

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

--- Comment #2 from Vladimir Makarov  2012-08-31 
18:35:17 UTC ---
IRA can not find super set of GENERAL_REGS and IWMMXT_GR_REGS.  It should not
happen as ALL_REGS exits as the last resort for this.

GCC documentation contains

@findex ALL_REGS
@findex NO_REGS
In general, each register will belong to several classes.  In fact, one
class must be named @code{ALL_REGS} and contain all the registers.  Another
class must be named @code{NO_REGS} and contain no registers.  Often the
union of two classes will be another class; however, this is not required.

Unfortunately, for some reasons ALL_REGS for ARM port does not contain
IWMMXT_GR_REGS, CC_REG, VFPCC_REG, SFP_REG, and AFP_REG.

I think ARM ALL_REGS should contain really all regs.  If this is not possible
for some reasons, we should fix the documentation and I should make a patch for
IRA fixing it in another way.  But I think the right solution would be fixing
ARM ALL_REGS definition (also probably the right cost should be returned by ARM
targets for different combinations of reg classes).

[Bug rtl-optimization/54369] Delayed-branch pass in reorg.c removes too many instructions

[sje at gcc dot gnu.org]

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

--- Comment #5 from Steve Ellcey  2012-08-31 18:16:08 
UTC ---
Thanks for digging into this Eric.  I tested your patch here against the
example and on the GCC testsuite and didn't see any problems.  Are you going to
check this in on the mainline?

[Bug target/53987] [SH] Unnecessary zero-extension before cmp/eq

[olegendo at gcc dot gnu.org]

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

--- Comment #1 from Oleg Endo  2012-08-31 18:14:28 
UTC ---
On a second thought, it might be not safe to omit zero/sign extensions if
values are compared after calculations, where the regs hold values < SImode.

[Bug c++/54440] New: [c++11] g++ prematurely applying rule that a template parameter pack cannot be followed by a template parameter

[eric.niebler at gmail dot com]

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

 Bug #: 54440
   Summary: [c++11] g++ prematurely applying rule that a template
parameter pack cannot be followed by a template
parameter
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eric.nieb...@gmail.com


The following code:

  template
  struct S
  {
template class...A, template class B>
struct T;
  };

yields:

  main.cpp:5:12: error: parameter pack ‘A’ must be at the end of the template
parameter list

I believe this is erroneous, as does clang developer Richard Smith. After S is
instantiated, A instantiates to a non-pack.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[drepper.fsp at gmail dot com]

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

--- Comment #9 from Ulrich Drepper  2012-08-31 
17:46:41 UTC ---
(In reply to comment #8)
> Is it clear which are the specific requirements for the various x86* targets?
> I'm wondering if after all it's just matter of updating:
> http://gcc.gnu.org/install/specific.html

Indeed.  You cannot use old binutils if any of the code generated by the
compiler requires something newer.  If these dependencies are not wanted then
make the compiler to emit .byte sequences when the new builtins are used.


> Since rdrand is only supported on Ivy Bridge processors, shouldn't
> src/c++11/random.cc have a fall through using rdtsc in case the processor
> doesn't support rdrand?

Read the code.  There is of course a fall-through for older processors.  This
is about the code generated by the compiler, not what is used at runtime.

[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended

[aaw at gcc dot gnu.org]

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

Ollie Wild  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Ollie Wild  2012-08-31 17:24:07 UTC 
---
Fixed for 4.7.2+.

[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended

[aaw at gcc dot gnu.org]

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

--- Comment #6 from Ollie Wild  2012-08-31 17:16:47 UTC 
---
Author: aaw
Date: Fri Aug 31 17:16:39 2012
New Revision: 190839

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190839
Log:
Backport from mainline
2012-08-31  Ollie Wild  

PR c++/54197
* gcc/cp/call.c (extend_ref_init_temps_1): Handle COMPOUND_EXPR trees.
* gcc/testsuite/g++.dg/init/lifetime3.C: New test.

Added:
branches/gcc-4_7-branch/gcc/testsuite/g++.dg/init/lifetime3.C
Modified:
branches/gcc-4_7-branch/gcc/cp/ChangeLog
branches/gcc-4_7-branch/gcc/cp/call.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[paolo.carlini at oracle dot com]

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

--- Comment #8 from Paolo Carlini  2012-08-31 
17:16:36 UTC ---
Is it clear which are the specific requirements for the various x86* targets?
I'm wondering if after all it's just matter of updating:
http://gcc.gnu.org/install/specific.html

[Bug middle-end/54409] [4.8 Regression] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710

[jamborm at gcc dot gnu.org]

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

--- Comment #11 from Martin Jambor  2012-08-31 
17:15:52 UTC ---
(In reply to comment #10)
> This commit or the previous one caused a lot of ICEs (see
> http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg02988.html):
> 
> /opt/gcc/work/gcc/testsuite/gfortran.dg/bound_7.f90: In function 'MAIN__':
> /opt/gcc/work/gcc/testsuite/gfortran.dg/bound_7.f90:168:0: internal compiler
> error: vector VEC(T,base) replace domain error, in predicate_for_phi_result at
> ipa-inline-analysis.c:2164
>call sub2
>  ^

It was the previous one, either calculate_dominance_info or
loop_optimizer_init grow SSANAMES of a function which I did not
expect.

I'm sorry, I do not know what went wring when I was testing the
patches.  I'm bootstrapping a simple fix:

2012-08-31  Martin Jambor  

* ipa-inline-analysis.c (estimate_function_body_sizes): Allocate
nonconstant_names after calculate_dominance_info and
loop_optimizer_init.

Index: src/gcc/ipa-inline-analysis.c
===
--- src.orig/gcc/ipa-inline-analysis.c
+++ src/gcc/ipa-inline-analysis.c
@@ -2185,13 +2185,6 @@ estimate_function_body_sizes (struct cgr
   struct ipa_node_params *parms_info = NULL;
   VEC (predicate_t, heap) *nonconstant_names = NULL;

-  if (ipa_node_params_vector && !early && optimize)
-{
-  parms_info = IPA_NODE_REF (node);
-  VEC_safe_grow_cleared (predicate_t, heap, nonconstant_names,
- VEC_length (tree, SSANAMES (my_function)));
-}
-
   info->conds = 0;
   info->entry = 0;

@@ -2199,6 +2192,13 @@ estimate_function_body_sizes (struct cgr
 {
   calculate_dominance_info (CDI_DOMINATORS);
   loop_optimizer_init (LOOPS_NORMAL | LOOPS_HAVE_RECORDED_EXITS);
+
+  if (ipa_node_params_vector)
+{
+  parms_info = IPA_NODE_REF (node);
+  VEC_safe_grow_cleared (predicate_t, heap, nonconstant_names,
+ VEC_length (tree, SSANAMES (my_function)));
+}
 }

   if (dump_file)

[Bug libgcj/54439] New: new BigDecimal (int n) dumps core under CYGWIN_NT-6.1-WOW64

[Bernhard.Fastenrath at gmail dot com]

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

 Bug #: 54439
   Summary: new BigDecimal (int n) dumps core under
CYGWIN_NT-6.1-WOW64
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libgcj
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bernhard.fastenr...@gmail.com


new BigDecimal () dumps core under CYGWIN_NT-6.1-WOW64:

COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.5.3/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with:
/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3/configure
--srcdir=/gnu/gcc/releases/respins/4.5.3-3/gcc4-4.5.3-3/src/gcc-4.5.3
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --datarootdir=/usr/share --docdir=/usr/share/doc/gcc4 -C
--datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man -v
--with-gmp=/usr --with-mpfr=/usr --enable-bootstrap
--enable-version-specific-runtime-libs --libexecdir=/usr/lib --enable-static
--enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld
--with-gnu-as --with-dwarf2 --disable-sjlj-exceptions
--enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite
--enable-lto --enable-java-awt=gtk --disable-symvers --enable-libjava
--program-suffix=-4 --enable-libgomp --enable-libssp --enable-libada
--enable-threads=posix --with-arch=i686 --with-tune=generic
--enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 CC_FOR_TARGET=gcc-4
CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake GNATBIND_FOR_TARGET=gnatbind
--with-ecj-jar=/usr/share/java/ecj.jar
Thread model: posix
gcc version 4.5.3 (GCC)

-- listing properties --
path.separator=:
java.vm.name=GNU libgcj
java.vm.specification.name=Java(tm) Virtual Machine Specification
java.runtime.version=1.5.0
java.home=/usr
java.vm.specification.version=1.0
line.separator=

java.vm.specification.vendor=Sun Microsystems Inc.
gnu.classpath.home.url=file:///usr/lib/gcc/i686-pc-cygwin/4.5.3
gnu.gcj.progname=./dumpProps
gnu.classpath.version=0.98
java.specification.version=1.5
gnu.java.util.zoneinfo.dir=/usr/share/zoneinfo
java.library.path=/usr/lib/gcj-4.5.3-11:/home/bernhard/...
gnu.classpath.vm.shortname=libgcj
java.class.version=49.0
java.specification.name=Java(tm) Platform API Specification
os.version=1.7.16(0.262/5/3)
gnu.classpath.home=/usr
user.home=/home/bernhard
file.encoding=ASCII
os.name=CYGWIN_NT-6.1-WOW64
user.name=bernhard
java.class.path=.;E:\Java\Extensions\QTJava.zip;E:\Ja...
java.io.tmpdir=/tmp
os.arch=i386
java.fullversion=GNU libgcj 4.5.3
user.language=en
java.specification.vendor=Sun Microsystems Inc.
user.dir=/workspace/Free Reservation System
java.vm.info=GNU libgcj 4.5.3
java.version=1.5.0
java.ext.dirs=/usr/share/java/ext
sun.boot.class.path=/usr/share/java/libgcj-4.5.3.jar
gnu.gcj.user.realname=U-indiana\bernhard,S-1-5-21-344129369...
java.vm.vendor=Free Software Foundation, Inc.
java.vendor.url=http://gcc.gnu.org/java/
java.vendor=Free Software Foundation, Inc.
file.separator=/
java.vm.version=4.5.3
http.agent=gnu-classpath/0.98 (libgcj/4.5.3)
gnu.gcj.precompiled.db.path=/usr/lib/gcj-4.5.3-11/classmap.db
gnu.cpu.endian=little
user.region=US
gnu.gcj.runtime.endorsed.dirs=/usr/share/java/gcj-endorsed

[Bug libstdc++/54392] [4.6/4.7/4.8 Regression] std::string::assign() fails to update length

[paolo.carlini at oracle dot com]

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

--- Comment #15 from Paolo Carlini  2012-08-31 
16:52:16 UTC ---
Yes it does. However considering that nobody noticed that for 10 years and that
the std::string implementation is near its end of life anyway (as I said, in
the new one the fix is straightforward and I'll take care of it in a few days)
I don't consider this issue very serious, frankly.

[Bug c++/54437] [4.8 Regression] Revision 190664 causes Firefox build failure

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Paolo Carlini  2012-08-31 
16:43:19 UTC ---
Adding Jason in CC, looks like this is related to the recent SFINAE work...

[Bug target/54436] [4.7/4.8 Regression] Compiling some regular C++ code gives assembler '700415 shortened to 255' warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  2012-08-31 
16:42:17 UTC ---
Created attachment 28112
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28112
gcc48-pr54436.patch

Untested fix.

[Bug middle-end/54409] [4.8 Regression] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  
2012-08-31 16:18:37 UTC ---
This commit or the previous one caused a lot of ICEs (see
http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg02988.html):

/opt/gcc/work/gcc/testsuite/gfortran.dg/bound_7.f90: In function 'MAIN__':
/opt/gcc/work/gcc/testsuite/gfortran.dg/bound_7.f90:168:0: internal compiler
error: vector VEC(T,base) replace domain error, in predicate_for_phi_result at
ipa-inline-analysis.c:2164
   call sub2
 ^

[Bug target/51244] SH Target: Inefficient conditional branch

[olegendo at gcc dot gnu.org]

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

--- Comment #51 from Oleg Endo  2012-08-31 
15:50:35 UTC ---
(In reply to comment #50)

Thanks!
Hmm .. difficult.  
There seem to be 17 improvements and 10 dis-improvements, but the
dis-improvements seem heavier.  The improvement avg is 1.1% and the
dis-improvements avg is -2.1%.  I don't know .. maybe this should wait a bit
more.

[Bug c++/54197] [4.7/4.8 regression] Lifetime of reference not properly extended

[aaw at gcc dot gnu.org]

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

--- Comment #5 from Ollie Wild  2012-08-31 15:47:37 UTC 
---
Author: aaw
Date: Fri Aug 31 15:47:29 2012
New Revision: 190834

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190834
Log:
2012-08-31  Ollie Wild  

PR c++/54197
* gcc/cp/call.c (extend_ref_init_temps_1): Handle COMPOUND_EXPR trees.
* gcc/testsuite/g++.dg/init/lifetime3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/init/lifetime3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

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

--- Comment #7 from Jack Howarth  2012-08-31 
15:40:25 UTC ---
Would the approach used in the proposed linux kernel patch be feasible?

+/* RDRAND sets carry bit on success, otherwise we should try
+ * again. */
+movl$0x10, %ecx
+2:
+/* rdrand %eax */
+.byte0x0f, 0xc7, 0xf0
+jc4f
+loop2b
+
+/* Fall through: if RDRAND is supported but fails, use RDTSC,
+ * which is guaranteed to be supported. */
+3:
+rdtsc
+shll$0xc, %eax
+4:
+/* Maximum offset at 64mb to be safe */

Since rdrand is only supported on Ivy Bridge processors, shouldn't
src/c++11/random.cc have a fall through using rdtsc in case the processor
doesn't support rdrand?

[Bug c++/50545] [C++0x][DR 1172] SFINAE does not handle an explicit type conversion (functional notation) with a braced-init-list well if target type is not dependent

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #3 from Jason Merrill  2012-08-31 
15:07:40 UTC ---
It was pointed out to me that 14.4 says,  "If an expression e involves a
template parameter, decltype(e) denotes a unique dependent type."

"involves a template parameter" is different from "is type-dependent", so G++
was clearly wrong.

Fixed by implementing instantiation-dependent in the way I think we should
resolve 1172.

[Bug c++/51222] [C++11][SFINAE] Unevaluated combined delete new expression completely broken

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jason Merrill  2012-08-31 
15:03:09 UTC ---
Fixed.

[Bug fortran/54435] [4.7/4.8 Regression] ICE with SELECT TYPE on a non-CLASS object

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-31
 Ever Confirmed|0   |1

--- Comment #6 from janus at gcc dot gnu.org 2012-08-31 14:58:28 UTC ---
(In reply to comment #3)
> Though, the error message of 4.6 is not really that helpful:
> 
>   end select type
>  1
> Error: Syntax error in END SELECT statement at (1)

Well, it's helpful in that it spots a syntax error in the test case: The
correct form is END SELECT.

If ones fixes the test case in this respect ...

subroutine foo(x)
  integer :: x
  select type (x)
  end select
end

... then it is rejected by the patch in comment 5 with the correct error
message:

  select type (x)
 1   
Error: Selector shall be polymorphic in SELECT TYPE statement at (1)


I'll start a regtest of the the patch now ...

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[howarth at nitro dot med.uc.edu]

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

--- Comment #6 from Jack Howarth  2012-08-31 
14:48:47 UTC ---
This same issue was discussed in the following thread...

http://thread.gmane.org/gmane.linux.kernel/1145078

specifically

Comments/Questions:

* Since RDRAND is relatively new, only the most recent version of
binutils supports assembling it.  To avoid breaking builds for people
who use older toolchains but want this feature, I hardcoded the opcodes.
If anyone has a better approach, please let me know.

It looks like that uncommitted patch hasn't been modified to address this issue
either.

[Bug middle-end/40119] ICE with --param hot-bb-frequency-fraction=0

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  2012-08-31 
14:48:54 UTC ---
Any plan to fix this PR?

[Bug target/45844] FAIL: gfortran.dg/vect/pr45714-b.f -O (internal compiler error)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Dominique d'Humieres  
2012-08-31 14:40:57 UTC ---
Backported to 4.6 at revision 188126, closing as fixed.

[Bug rtl-optimization/54369] Delayed-branch pass in reorg.c removes too many instructions

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  2012-08-31 
14:20:03 UTC ---
> I think I see where delete_related_insns is going wrong.  We call it
> with a JUMP instruction that we want to remove because we are just
> jumping to the next instruction (a label) which we would get to anyway
> without the jump, then after delete_related_insns removes the jump it
> checks the label it was jumping to, and if it finds no uses it calls
> delete_related_insns with that label.  When delete_related_insns
> is called with a label, it assumes it can remove all the code after
> that label as unreachable.

Only if there is a barrier just before the label though; now this barrier
should have been removed one level earlier.

The root cause of the problem is that MIPS runs its own version of the dbr pass
and doesn't make sure that barriers are correctly placed for it, unlike other
targets like SPARC.  So the fix is:

Index: config/mips/mips.c
===
--- config/mips/mips.c  (revision 184886)
+++ config/mips/mips.c  (working copy)
@@ -15083,7 +15083,10 @@ mips_reorg (void)
 }

   if (optimize > 0 && flag_delayed_branch)
-dbr_schedule (get_insns ());
+{
+  cleanup_barriers ();
+  dbr_schedule (get_insns ());
+}
   mips_reorg_process_insns ();
   if (!TARGET_MIPS16
   && TARGET_EXPLICIT_RELOCS

[Bug middle-end/54409] [4.8 Regression] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #9 from Martin Jambor  2012-08-31 
14:10:47 UTC ---
Fixed.

[Bug middle-end/54409] [4.8 Regression] internal compiler error: in remap_predicate, at ipa-inline-analysis.c:2710

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  2012-08-31 
14:05:50 UTC ---
Author: jamborm
Date: Fri Aug 31 14:05:45 2012
New Revision: 190833

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190833
Log:
2012-08-31  Martin Jambor  

PR middle-end/54409
* ipa-inline-analysis.c (remap_predicate): Fix the offset_map
checking condition.

* gcc/testsuite/gcc.dg/torture/pr54409.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr54409.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/54435] [4.7/4.8 Regression] ICE with SELECT TYPE on a non-CLASS object

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org 2012-08-31 14:03:21 UTC ---
This kills the ICE and gets us back at least to the 4.6 behavior (see comment
#3):


Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c(revision 190419)
+++ gcc/fortran/match.c(working copy)
@@ -5367,10 +5367,10 @@ gfc_match_select_type (void)
  array, which can have a reference, from other expressions that
  have references, such as derived type components, and are not
  allowed by the standard.
- TODO; see is it is sufficient to exclude component and substring
+ TODO: see if it is sufficient to exclude component and substring
  references.  */
   class_array = expr1->expr_type == EXPR_VARIABLE
-  && expr1->ts.type != BT_UNKNOWN
+  && expr1->ts.type == BT_CLASS
   && CLASS_DATA (expr1)
   && (strcmp (CLASS_DATA (expr1)->name, "_data") == 0)
   && (CLASS_DATA (expr1)->attr.dimension

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||howarth at nitro dot
   ||med.uc.edu

--- Comment #5 from Dominique d'Humieres  2012-08-31 
13:59:02 UTC ---
*** Bug 54438 has been marked as a duplicate of this bug. ***

[Bug bootstrap/54438] bootstrap broken on x86_64-apple-darwin12

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #1 from Dominique d'Humieres  2012-08-31 
13:59:02 UTC ---
Dup!

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

[Bug bootstrap/54438] New: bootstrap broken on x86_64-apple-darwin12

[howarth at nitro dot med.uc.edu]

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

 Bug #: 54438
   Summary: bootstrap broken on x86_64-apple-darwin12
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu


At r190831, the bootstrap of gcc trunk is broken on x86_64-apple-darwin12 in
all-stage1-target-libstdc++-v3 as follows...

Making all in c++11
/bin/sh ../../libtool --tag CXX --tag disable-shared   --mode=compile
/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/xgcc -shared-libgcc
-B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc -nostdinc++
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/src/.libs
-B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/bin/
-B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/lib/ -isystem
/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/include -isystem
/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/sys-include   
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120831/libstdc++-v3/../libgcc
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include/x86_64-apple-darwin12.2.0
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120831/libstdc++-v3/libsupc++
-I/sw/include -std=gnu++11 -prefer-pic -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once 
-fvisibility-inlines-hidden -ffunction-sections -fdata-sections 
-frandom-seed=random.lo -g -O2 -c -o random.lo
../../../../../gcc-4.8-20120831/libstdc++-v3/src/c++11/random.cc
libtool: compile:  /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/xgcc
-shared-libgcc -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc
-nostdinc++
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/src/.libs
-B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/bin/
-B/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/lib/ -isystem
/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/include -isystem
/sw/lib/gcc4.8/x86_64-apple-darwin12.2.0/sys-include
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120831/libstdc++-v3/../libgcc
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include/x86_64-apple-darwin12.2.0
-I/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/x86_64-apple-darwin12.2.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc48-4.8.0-1000/gcc-4.8-20120831/libstdc++-v3/libsupc++
-I/sw/include -std=gnu++11 -fno-implicit-templates -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once
-fvisibility-inlines-hidden -ffunction-sections -fdata-sections
-frandom-seed=random.lo -g -O2 -c
../../../../../gcc-4.8-20120831/libstdc++-v3/src/c++11/random.cc  -fno-common
-DPIC -o random.o
/var/tmp//ccirSv3U.s:28:no such instruction: `rdrand %eax'
make[6]: *** [random.lo] Error 1
make[6]: *** No rule to make target `../src/c++11/libc++11convenience.la',
needed by `libstdc++-symbols.explist'.  Stop.
make[5]: *** [all-recursive] Error 1
make[4]: *** [all-recursive] Error 1
make[3]: *** [all] Error 2
make[2]: *** [all-stage1-target-libstdc++-v3] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2

when bootstrapped as...

 $ ../gcc-4.8-20120831/configure --prefix=/sw --prefix=/sw/lib/gcc4.8
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --enable-checking=yes --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8

against Xcode 4.4.1.

[Bug middle-end/54394] [4.8 Regression] fatigue2 -flto run time regression

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Martin Jambor  2012-08-31 
13:27:08 UTC ---
Fixed.

[Bug fortran/54435] [4.7/4.8 Regression] ICE with SELECT TYPE on a non-CLASS object

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #4 from janus at gcc dot gnu.org 2012-08-31 13:15:24 UTC ---
(In reply to comment #1)
> As postscript: Non BT_CLASS should be directly rejected. From F2008:
> 
> C837 (R847)  The selector in a select-type-stmt shall be polymorphic.

We have such a check in resolve_select_type, which obviously comes too late for
gfc_match_select_type.

[Bug middle-end/54394] [4.8 Regression] fatigue2 -flto run time regression

[jamborm at gcc dot gnu.org]

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

--- Comment #5 from Martin Jambor  2012-08-31 
13:13:09 UTC ---
Author: jamborm
Date: Fri Aug 31 13:13:03 2012
New Revision: 190831

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190831
Log:
2012-08-31  Martin Jambor  

PR middle-end/54394
* ipa-inline-analysis.c (estimate_function_body_sizes): Compute
dominance info and loops whenever optimizing.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c

[Bug c++/54437] [4.8 Regression] Revision 190664 causes Firefox build failure

[markus at trippelsdorf dot de]

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

--- Comment #1 from Markus Trippelsdorf  
2012-08-31 13:07:54 UTC ---
This is what Creduce came up with:

typedef bool (*IsAcceptableThis)(const int& v);
typedef bool (*NativeImpl)(int *, int);
templatevoid CallNonGenericMethod();
typedef int (*JSNative)(int *, unsigned, int *);
struct A
{};
class B : A {
  static bool  is(const int& p1);
  templatestatic bool getterImpl(int *,
  int);
  templatestatic int  getter(int *,
  unsigned,
  int *);
  templatestatic bool defineGetter();
  static int   byteOffsetValue(B&);
  A  * initClass();
};
A *js_NewFunction(JSNative);
templateint
 B::getter(int *, unsigned, int *)
{
  CallNonGenericMethod >();
}

template
bool
 B::defineGetter()
{
  A *a = js_NewFunction(B::getter);
}

A *
B::initClass()
{
  defineGetter;
}

[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions

[markus at trippelsdorf dot de]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot
   ||de

--- Comment #14 from Markus Trippelsdorf  
2012-08-31 12:57:07 UTC ---
(In reply to comment #13)
> Author: jason
> Date: Sat Aug 25 03:30:11 2012
> New Revision: 190664
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190664
> Log:
> PR c++/51213 (again)

This revision causes Bug 54437.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2012-08-31 
12:55:40 UTC ---
Deleting the #if defined __i386__ || defined __x86_64__ blocks in
libstdc++-v3/src/c++11/random.cc allowed me to bootstrap revision 190830 on
x86_64-apple-darwin10 (regtesting scheduled for tonight).

[Bug c++/54437] New: [4.8 Regression] Revision 190664 causes Firefox build failure

[markus at trippelsdorf dot de]

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

 Bug #: 54437
   Summary: [4.8 Regression]  Revision 190664 causes Firefox build
failure
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de


Created attachment 28111
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28111
testcase

Starting with revision 190664 I get the following error when building Firefox:

 $ cc1plus -w -quiet jstypedarray.ii
/var/tmp/mozilla-central/js/src/jstypedarray.cpp: In instantiation of ‘static
JSBool js::DataViewObject::getter(JSContext*, unsigned int, JS::Value*) [with
JS::Value (* ValueGetter)(js::DataViewObject&) =
js::DataViewObject::bufferValue; JSBool = int; JSContext = JSContext]’:
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3215:108:   required from
‘static bool js::DataViewObject::defineGetter(JSContext*, js::PropertyName*,
JS::HandleObject) [with JS::Value (* ValueGetter)(js::DataViewObject&) =
js::DataViewObject::bufferValue; JSContext = JSContext; JS::HandleObject =
JS::Handle]’
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3241:80:   required from here
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3204:71: error: no matching
function for call to ‘CallNonGenericMethod(JSContext*&, JS::CallArgs&)’
 return CallNonGenericMethod >(cx, args);
   ^
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3204:71: note: candidate is:
In file included from /var/tmp/mozilla-central/js/src/jstypedarray.cpp:13:0:
/var/tmp/mozilla-central/js/src/jsapi.h:1556:1: note: template bool
JS::CallNonGenericMethod(JSContext*, JS::CallArgs)
 CallNonGenericMethod(JSContext *cx, CallArgs args)
 ^
/var/tmp/mozilla-central/js/src/jsapi.h:1556:1: note:   template argument
deduction/substitution failed:
/var/tmp/mozilla-central/js/src/jstypedarray.cpp: In substitution of
‘template bool JS::CallNonGenericMethod(JSContext*, JS::CallArgs) [with
bool (* Test)(const JS::Value&) = js::DataViewObject::is; bool (*
Impl)(JSContext*, JS::CallArgs) =
js::DataViewObject::getterImpl]’:
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3204:71:   required from
‘static JSBool js::DataViewObject::getter(JSContext*, unsigned int, JS::Value*)
[with JS::Value (* ValueGetter)(js::DataViewObject&) =
js::DataViewObject::bufferValue; JSBool = int; JSContext = JSContext]’
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3215:108:   required from
‘static bool js::DataViewObject::defineGetter(JSContext*, js::PropertyName*,
JS::HandleObject) [with JS::Value (* ValueGetter)(js::DataViewObject&) =
js::DataViewObject::bufferValue; JSContext = JSContext; JS::HandleObject =
JS::Handle]’
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3241:80:   required from here
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3191:1: error: ‘static bool
js::DataViewObject::getterImpl(JSContext*, JS::CallArgs) [with JS::Value (*
ValueGetter)(js::DataViewObject&) = js::DataViewObject::bufferValue; JSContext
= JSContext]’ is private
 DataViewObject::getterImpl(JSContext *cx, CallArgs args)
 ^
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3204:71: error: within this
context
 return CallNonGenericMethod >(cx, args);
   ^
/var/tmp/mozilla-central/js/src/jstypedarray.cpp: In instantiation of ‘static
JSBool js::DataViewObject::getter(JSContext*, unsigned int, JS::Value*) [with
JS::Value (* ValueGetter)(js::DataViewObject&) =
js::DataViewObject::byteLengthValue; JSBool = int; JSContext = JSContext]’:
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3215:108:   required from
‘static bool js::DataViewObject::defineGetter(JSContext*, js::PropertyName*,
JS::HandleObject) [with JS::Value (* ValueGetter)(js::DataViewObject&) =
js::DataViewObject::byteLengthValue; JSContext = JSContext; JS::HandleObject =
JS::Handle]’
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3244:88:   required from here
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3204:71: error: no matching
function for call to ‘CallNonGenericMethod(JSContext*&, JS::CallArgs&)’
/var/tmp/mozilla-central/js/src/jstypedarray.cpp:3204:71: note: candidate is:
In file included from /var/tmp/mozilla-central/js/src/jstypedarray.cpp:13:0:
/var/tmp/mozilla-central/js/src/jsapi.h:1556:1: note: template bool
JS::CallNonGenericMethod(JSContext*, JS::CallArgs)
 CallNonGenericMethod(JSContext *cx, CallArgs args)
 ^
/var/tmp/mozilla-central/js/src/jsapi.h:1556:1: note:   template argument
deduction/substitution failed:
/var/tmp/mozilla-central/js/src/jstypedarray.cpp: In substitution of
‘template bool JS::CallNonGenericMethod(JSContext*, JS::CallArgs) [with
bool (* Test)(const JS::Value&) = js::DataViewObject::is; bool (*
Impl)(JSContext*, JS::C

[Bug other/54436] [4.7/4.8 Regression] Compiling some regular C++ code gives assembler '700415 shortened to 255' warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-08-31
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |4.7.2
Summary|Compiling some regular C++  |[4.7/4.8 Regression]
   |code gives assembler|Compiling some regular C++
   |'700415 shortened to 255'   |code gives assembler
   |warning |'700415 shortened to 255'
   ||warning
 Ever Confirmed|0   |1

--- Comment #1 from Jakub Jelinek  2012-08-31 
12:42:37 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179556
Looking into it.

[Bug fortran/54426] [4.8 Regression] FAIL: gfortran.dg/common_6.f90 -O (internal compiler error) on powerpc-apple-darwin9

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus  2012-08-31 
12:30:53 UTC ---
(In reply to comment #2)
> Following Tobias' suggestion on IRC, the patch
> @@ -2890,6 +2890,7 @@ gfc_undo_symbols (void)
> +  p->common_block->refs--;
> fixes the PR on powerpc-apple-darwin9 without regression.

But it re-introduces the memory leak. The reason that it works is in
gfc_free_symbol:

  if (sym->common_block && sym->common_block->name[0] != '\0')
{
  sym->common_block->refs--;
  if (sym->common_block->refs == 0)
free (sym->common_block);

If "refs" is 1, doing twice "refs--" makes the latter -1, preventing the
deletion.


The proper fix is to avoid accessing common_root...->n.common after a common
block has been removed via undo_symbols. And the best way to do so is to delete
the common-block symtree in common_root - which is what the patch in comment 1
does.

[Bug fortran/54426] [4.8 Regression] FAIL: gfortran.dg/common_6.f90 -O (internal compiler error) on powerpc-apple-darwin9

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2012-08-31 
12:21:59 UTC ---
Following Tobias' suggestion on IRC, the patch

--- /opt/gcc/work/gcc/fortran/symbol.c2012-08-28 01:14:39.0 +0200
+++ /opt/gcc/rel_work/gcc/fortran/symbol.c2012-08-30 23:00:09.0
+0200
@@ -2890,6 +2890,7 @@ gfc_undo_symbols (void)
  needs to be removed to stop the resolver looking
  for a (possibly) dead symbol.  */

+  p->common_block->refs--;
   if (p->common_block->head == p)
 p->common_block->head = p->common_next;
   else

fixes the PR on powerpc-apple-darwin9 without regression.

[Bug other/54436] New: Compiling some regular C++ code gives assembler '700415 shortened to 255' warning

[mathias at gaunard dot com]

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

 Bug #: 54436
   Summary: Compiling some regular C++ code gives assembler
'700415 shortened to 255' warning
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: math...@gaunard.com


Created attachment 28110
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28110
automatically reduced testcase

When I compile the attached C++ code with GCC 4.7 and GNU as 2.22 with -O1, I
get the following message:
$ g++ -O1 -c reversebits.ii
/tmp/cchfvrG0.s: Assembler messages:
/tmp/cchfvrG0.s:40: Warning: 700415 shortened to 255

I do not think it is normal that GCC does not report any problem while the
assembler does.

The attached testcase was unfortunately automatically reduced from a large code
base, so it isn't very readable. Sorry about that.
I also do not know what is the right component, so putting in 'other' for now.

[Bug target/54429] [SH] SImode values get ferried through FPUL and FP regs for -O0

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  2012-08-31 11:54:27 
UTC ---
(In reply to comment #1)
> I don't know the history about it.  I guess that the original
> intention would be to use FP registers as fast memories for
> integers, though I'm wrong about it.  BTW, the last time I
> tried to disable integer mode for FP registers, some reload
> failures popped up in gcc testsuite.  Are there no new failures
> on your test with the above patch?

I haven't done proper testing.  I will check out what's happening there.

[Bug target/54429] [SH] SImode values get ferried through FPUL and FP regs for -O0

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima  2012-08-31 
10:59:44 UTC ---
(In reply to comment #0)

I don't know the history about it.  I guess that the original
intention would be to use FP registers as fast memories for
integers, though I'm wrong about it.  BTW, the last time I
tried to disable integer mode for FP registers, some reload
failures popped up in gcc testsuite.  Are there no new failures
on your test with the above patch?

[Bug target/51244] SH Target: Inefficient conditional branch

[kkojima at gcc dot gnu.org]

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

--- Comment #50 from Kazumoto Kojima  2012-08-31 
10:54:44 UTC ---
(In reply to comment #49)
> Kaz, if you have some time, could you please gather some CSiBE runtime numbers
> for '-mpretend-cmove' and without it?

Here is the runtime result with -O2:

test no cmoveratio(%)

bzip2-1.0.2 bzip2.d  10.976711.07-0.84312
bzip2-1.0.2 bzip2recover 4.703334.69333   0.213068
bzip2-1.0.2 bzip2.c  43.086743.73-1.47115
compiler vam.fib 2.026672.00667   0.996678
compiler vam.fact1.913331.89333   1.05634
compiler vam.test2   0.256667   0.27 -3.75
Here is the runtime result with -O2:

test no cmoveratio(%)

bzip2-1.0.2 bzip2.d  10.976711.07-0.84312
bzip2-1.0.2 bzip2recover 4.703334.69333   0.213068
bzip2-1.0.2 bzip2.c  43.086743.73-1.47115
compiler vam.fib 2.026672.00667   0.996678
compiler vam.fact1.913331.89333   1.05634
compiler vam.test2   0.256667   0.27 -3.75
flex-2.5.31 flex 13.18  13.02 1.22888
jikespg-1.3 jikespg  1.616671.6   1.04167
jpeg-6b jpegtran24.65   4.61  0.867679
jpeg-6b djpeg2   2.33   2.28667   1.89504
jpeg-6b djpeg1   2.293332.24667   2.07715
jpeg-6b cjpeg2   3.013332.99667   0.556174
jpeg-6b djpeg0   0.336667   0.35 -3.80952
jpeg-6b cjpeg0   0.476667   0.486667 -2.05479
jpeg-6b cjpeg1   3.063332.99667   2.22469
jpeg-6b jpegtran00.26   0.27 -2.46914
jpeg-6b jpegtran11.91.86667   1.78571
libpng-1.2.5 png2pnm00.986667   0.96  2.42215
libpng-1.2.5 pnm2png144.633345.6333  -2.19138
libpng-1.2.5 pnm2png07.936678.09333  -1.93575
libpng-1.2.5 png2pnm16.73   6.75 -0.296296
teem-1.6.0-src dehex01.67   1.66333   0.400802
teem-1.6.0-src dehex110.96  10.9367   0.21335
teem-1.6.0-src enhex141.176740.5733   1.48702
teem-1.6.0-src enhex06.183336.31 -2.0074
zlib-1.1.4 minigzip0 46.486746.2533   0.504468
zlib-1.1.4 minigzip  5.523335.50333   0.363416
flex-2.5.31 flex 13.18  13.02 1.22888
jikespg-1.3 jikespg  1.616671.6   1.04167
jpeg-6b jpegtran24.65   4.61  0.867679
jpeg-6b djpeg2   2.33   2.28667   1.89504
jpeg-6b djpeg1   2.293332.24667   2.07715
jpeg-6b cjpeg2   3.013332.99667   0.556174
jpeg-6b djpeg0   0.336667   0.35 -3.80952
jpeg-6b cjpeg0   0.476667   0.486667 -2.05479
jpeg-6b cjpeg1   3.063332.99667   2.22469
jpeg-6b jpegtran00.26   0.27 -2.46914
jpeg-6b jpegtran11.91.86667   1.78571
libpng-1.2.5 png2pnm00.986667   0.96  2.42215
libpng-1.2.5 pnm2png144.633345.6333  -2.19138
libpng-1.2.5 pnm2png07.936678.09333  -1.93575
libpng-1.2.5 png2pnm16.73   6.75 -0.296296
teem-1.6.0-src dehex01.67   1.66333   0.400802
teem-1.6.0-src dehex110.96  10.9367   0.21335
teem-1.6.0-src enhex141.176740.5733   1.48702
teem-1.6.0-src enhex06.183336.31 -2.0074
zlib-1.1.4 minigzip0 46.486746.2533   0.504468
zlib-1.1.4 minigzip  5.523335.50333   0.363416

[Bug target/54418] [4.8 Regression] [SH] Invalid operands for opcode

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  2012-08-31 
10:51:48 UTC ---
(In reply to comment #2)
> Unfortunately I was not able to reproduce this case without the -fopenmp
> option, and that option requires threads, which are not available on the 
> sh-sim
> config I've got here for testing.  Kaz, could you please try out the 
> following?

I've confirmed that libgomp failures go away with your patch.

[Bug fortran/54435] [4.7/4.8 Regression] ICE with SELECT TYPE on a non-CLASS object

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||pault at gcc dot gnu.org
   Target Milestone|--- |4.7.2
Summary|ICE with SELECT TYPE on a   |[4.7/4.8 Regression] ICE
   |non-CLASS object|with SELECT TYPE on a
   ||non-CLASS object

--- Comment #3 from Tobias Burnus  2012-08-31 
09:19:24 UTC ---
I marked it as regression as with 4.6 it doesn't ICE ("class_array =" is new in
4.7). Though, the error message of 4.6 is not really that helpful:

  end select type
 1
Error: Syntax error in END SELECT statement at (1)

[Bug fortran/54435] ICE with SELECT TYPE on a non-CLASS object

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||xarthisius.kk at gmail dot
   ||com

--- Comment #2 from Tobias Burnus  2012-08-31 
08:51:22 UTC ---
*** Bug 54434 has been marked as a duplicate of this bug. ***

[Bug fortran/54434] [4.8/ICE] on illegal use of TYPE(*) in SELECT TYPE construct

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #1 from Tobias Burnus  2012-08-31 
08:51:22 UTC ---
Thanks for the report -> mark as duplicate of PR 54435 which is exactly the
same, except for slightly more analysis.

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

[Bug fortran/54435] ICE with SELECT TYPE on a non-CLASS object

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  2012-08-31 
08:48:32 UTC ---
As postscript: Non BT_CLASS should be directly rejected. From F2008:

C837 (R847)  The selector in a select-type-stmt shall be polymorphic.

[Bug fortran/54435] New: ICE with SELECT TYPE on a non-CLASS object

[burnus at gcc dot gnu.org]

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

 Bug #: 54435
   Summary: ICE with SELECT TYPE on a non-CLASS object
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


It crashes in match.c's gfc_match_select_type:

  class_array = expr1->expr_type == EXPR_VARIABLE
  && expr1->ts.type != BT_UNKNOWN
  && CLASS_DATA (expr1)
  ...

as for obvious reasons, a non-BT_CLASS doesn't have CLASS_DATA.


Test case, reported by xarthisius on #gfortran:

subroutine foo(x)
!  type(*) :: x
  integer :: x
  select type (x)
  end select type
end

[Bug fortran/54434] New: [4.8/ICE] on illegal use of TYPE(*) in SELECT TYPE construct

[xarthisius.kk at gmail dot com]

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

 Bug #: 54434
   Summary: [4.8/ICE] on illegal use of TYPE(*) in SELECT TYPE
construct
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: xarthisius...@gmail.com


Following (invalid) code causes ICE:

type(*) :: dummy

select type(dummy)
end select
end

with:

Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0-pre/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.0_pre/work/gcc-4.8.0-/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0-pre
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check
--with-cloog-include=/usr/include/cloog-ppl --enable-lto --enable-nls
--without-included-gettext --with-system-zlib --enable-obsolete
--disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0-pre/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.8.0_pre'
Thread model: posix
gcc version 4.8.0-pre 20120827 (experimental) commit
362e3dd9651511fff63453eaf0b0d25f49e1f12e (Gentoo 4.8.0_pre)

[Bug c/54428] [4.7/4.8 Regression] ICE in gimplify_expr, at gimplify.c:7591

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  2012-08-31 
08:37:09 UTC ---
Created attachment 28109
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28109
gcc48-pr54428.patch

Untested fix.

[Bug c/42579] [PATCH] support for obtaining file basename

[asierllano at gmail dot com]

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

--- Comment #6 from Asier Llano  2012-08-31 
08:03:58 UTC ---
We tried it in 4.7 and it works perfectly. By now we will have to apply this
patch for our development with 4.7.1.

[Bug c/42579] [PATCH] support for obtaining file basename

[asierllano at gmail dot com]

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

Asier Llano  changed:

   What|Removed |Added

 CC||asierllano at gmail dot com

--- Comment #5 from Asier Llano  2012-08-31 
08:00:09 UTC ---
We have a similar issue for embedded devices with debugging. We even
implemented it with the same exact name __FILE_BASENAME__ and when I was going
to submit a it in bugzilla we realized that it was already reported.

[Bug c/54428] [4.7/4.8 Regression] ICE in gimplify_expr, at gimplify.c:7591

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC|jakub at gcc dot gnu.org|
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #4 from Jakub Jelinek  2012-08-31 
07:29:20 UTC ---
Started with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178209