[Bug tree-optimization/50052] [4.6/4.7 Regression] FAIL: gcc.dg/ipa/ipa-sra-2.c scan-tree-dump eipa_sra

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-12
   Target Milestone|--- |4.6.2
Summary|[4.6 Regression] FAIL:  |[4.6/4.7 Regression] FAIL:
   |gcc.dg/ipa/ipa-sra-2.c  |gcc.dg/ipa/ipa-sra-2.c
   |scan-tree-dump eipa_sra |scan-tree-dump eipa_sra
 Ever Confirmed|0   |1

[Bug libgcj/50053] New: [4.7 regression] SIGSEGV in natClass.cc:651

[jojelino at gmail dot com]

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

 Bug #: 50053
   Summary: [4.7 regression] SIGSEGV in natClass.cc:651
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jojel...@gmail.com


Created attachment 24989
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24989
testcase,class file using -target 1.1

Reading symbols from /usr/i686-pc-mingw32/java/bin/i686-pc-mingw32-gij...done.
(gdb) r
Starting program: /usr/i686-pc-mingw32/java/bin/i686-pc-mingw32-gij -cp .
foobar -v
[New Thread 11168.0x2234]
[New Thread 11168.0x3824]

Program received signal SIGSEGV, Segmentation fault.
java::lang::Class::newInstance (this=0x1)
at ../.././libjava/java/lang/natClass.cc:651
651   if (isPrimitive ()
(gdb) disass
Dump of assembler code for function java::lang::Class::newInstance():
   0x696c5cb0 <+0>: push   %ebp
   0x696c5cb1 <+1>: mov%esp,%ebp
   0x696c5cb3 <+3>: push   %esi
   0x696c5cb4 <+4>: push   %ebx
   0x696c5cb5 <+5>: mov%ecx,%ebx
   0x696c5cb7 <+7>: sub$0x10,%esp
   0x696c5cba <+10>:movl   $0x0,(%esp)
   0x696c5cc1 <+17>:call   0x696d64a0

   0x696c5cc6 <+22>:sub$0x4,%esp
=> 0x696c5cc9 <+25>:cmpl   $0x,0x34(%ebx)

(gdb) bt
#0  java::lang::Class::newInstance (this=0x1)
at ../.././libjava/java/lang/natClass.cc:651
#1  0x69d0b567 in ffi_call_win32 () at ../.././libffi/src/x86/win32.S:424
#2  0x69d0b525 in ffi_raw_call (cif=0xbf0a0c,
fn=0x696c5cb0 , rvalue=0x22f8ac,
fake_avalue=0x22f6d0) at ../.././libffi/src/x86/ffi.c:647
#3  0x6969d056 in _Jv_InterpMethod::run (retp=0x22fa14, args=0x22fa34,
meth=0xe12f60) at ../.././libjava/interpret-run.cc:611
#4  0x69d0b715 in ffi_closure_raw_SYSV () at ../.././libffi/src/x86/win32.S:695
#5  0x69d0b567 in ffi_call_win32 () at ../.././libffi/src/x86/win32.S:424
#6  0x69d0b525 in ffi_raw_call (cif=0xbf0b24, fn=0xe30098, rvalue=0x22fc98,
fake_avalue=0x22fab0) at ../.././libffi/src/x86/ffi.c:647
#7  0x6969d056 in _Jv_InterpMethod::run (retp=0x22fe00, args=0x22fe20,
meth=0xab8e60) at ../.././libjava/interpret-run.cc:611
#8  0x69d0b715 in ffi_closure_raw_SYSV () at ../.././libffi/src/x86/win32.S:695
#9  0x696bdd22 in gnu::java::lang::MainThread::call_main (this=0xbfcf60)
at ../.././libjava/gnu/java/lang/natMainThread.cc:54
#10 0x696fb636 in gnu.java.lang.MainThread.run()void (this=@bfcf60)
at /tmp/gcc/libjava/gnu/java/lang/MainThread.java:106
#11 0x696cc6a2 in _Jv_ThreadRun (thread=0xbfcf60)
at ../.././libjava/java/lang/natThread.cc:335
#12 0x69684040 in _Jv_RunMain (vm_args=0x22ff30, klass=0x0,
name=0x3d8925 "foobar", argc=0x2, argv=0x3d89f4, is_jar=0x0)
---Type  to continue, or q  to quit---
at ../.././libjava/prims.cc:1789
#13 0x66bc6d2a in main (argc=0x5, argv=0x3d89e8) at ../.././libjava/gij.cc:333
#14 0x004010fd in __mingw_CRTStartup () at ../../.././winsup/mingw/crt1.c:244
#15 0x0408 in ?? ()
#16 0x7ffde000 in ?? ()
#17 0x in ?? ()
(gdb) i r
eax0x0  0x0
ecx0x69e8d040   0x69e8d040
edx0x0  0x0
ebx0x1  0x1
esp0x22f628 0x22f628
ebp0x22f640 0x22f640
esi0x696c5cb0   0x696c5cb0
edi0x22f6d0 0x22f6d0
eip0x696c5cc9   0x696c5cc9

eflags 0x10206  [ PF IF RF ]
cs 0x1b 0x1b
ss 0x23 0x23
ds 0x23 0x23
es 0x23 0x23
fs 0x3b 0x3b
gs 0x0  0x0
(gdb)


it is class member function, so %ecx is considered as `this`, 
but caller doesn't seem to assign `this` to %ecx.

[Bug tree-optimization/49911] SRA + DOM + VRP + -fstrict-enums incorrectly remove predicate

[ebotcazou at gcc dot gnu.org]

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

--- Comment #16 from Eric Botcazou  2011-08-12 
08:01:36 UTC ---
> No, they still mean "nothing", but VRP assumes they are the canonical
> value according to precision/signedness.  Which C and C++ do not follow.
> Unfortunately the C and C++ maintainers do not care (and probably have
> a harder job "fixing" this because they lack the nice separation of
> the "real" frontend and the interface to GENERIC).

They certainly used to mean something, so it would be interesting to know when
they stopped doing so.  The existence of -fstrict-enums is an evidence.

> As they mean "nothing" I would like to make VRP not assume anything about
> them (and VRP is really the only one caring for TYPE_MIN/MAX_VALUE apart from
> array domain uses).

The folder cares (or used to care), in particular the range code.

In any case, this particular problem is more of a SRA bug in my opinion.

[Bug c++/50054] New: Fails to recover from type error in function signature

[stiffy2 at gmx dot de]

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

 Bug #: 50054
   Summary: Fails to recover from type error in function signature
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: stif...@gmx.de


GCC fails to recover from the type error in the function signature of g and
crashes:

void g( const int& (a)[1] ) {}

int main () {
g( { 1, 2 } );
}

It doesn't crash when g( { 1, 2 } ); is deleted.

 Using 4.7

Call to GCC with error message:

% LANG=C make CXXFLAGS="-std=c++0x" listinit
g++ -std=c++0xlistinit.cpp   -o listinit
listinit.cpp:1:25: error: declaration of `a' as array of references
listinit.cpp: In function `int main()':
listinit.cpp:4:17: internal compiler error: in cxx_incomplete_type_diagnostic,
at cp/typeck2.c:453
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

GCC Version:

% LANG=C g++ -v
Using built-in specs.
COLLECT_GCC=/home/evnu/bin/g++
COLLECT_LTO_WRAPPER=/home/evnu/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --enable-plugin --enable-cloog-backend=isl
--with-ppl --enable-__cxa_atexit --with-system-zlib --enable-shared
--enable-threads=posix --enable-languages=c,c++ --disable-multilib
--prefix=/home/evnu
Thread model: posix
gcc version 4.7.0 20110808 (experimental) (GCC)

=== Using GCC 4.6

Call to GCC with error message:

% LANG=C make CXXFLAGS="-std=c++0x" listinit CXX=/usr/bin/g++
/usr/bin/g++ -std=c++0xlistinit.cpp   -o listinit
listinit.cpp:1:25: error: declaration of 'a' as array of references
listinit.cpp:4: confused by earlier errors, bailing out

GCC Version:
% LANG=C /usr/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.6.1/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --enable-gnu-unique-object
--enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto
--enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--enable-multilib --disable-libstdcxx-pch --enable-checking=release
Thread model: posix
gcc version 4.6.1 (GCC)

[Bug libgcj/50053] [4.7 regression] SIGSEGV in natClass.cc:651

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther  2011-08-12 
08:27:30 UTC ---
Try to build everything with -fno-ipa-sra -fno-ipa-cp.

[Bug libgcj/50053] [4.7 regression] SIGSEGV in natClass.cc:651

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug target/49992] lto-bootstrap reveals duplicate symbols on x86_64-apple-darwin11

[iains at gcc dot gnu.org]

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

--- Comment #49 from Iain Sandoe  2011-08-12 08:51:32 
UTC ---
(In reply to comment #47)
> (In reply to comment #43)
> 
> > Changing the topic to target - although there's a latent issue with the two
> > diagnostic implemenations, (and I will post comment 6, when the reg-tests 
> > are
> > done on linux) the actual bug is a target one.


> Note that error posted in Comment 41. There are additional duplicated
> symbols in errors.c that conflict with those in diagnostic.c (in that case
> fancy_abort). So if you intend to proceed with the patch in comment 6, it
> should be expanded to address all the duplicated symbols which can potentially
> conflict. 

comment 6 does not rename the duplicated symbols.  In fact  what it does is to
rename "fatal" = > "fatal_error" in the gen* and errors.c, so that it is not
necessary to link errors.o when libcommon.a is available. 

Looking at comment 41, it doesn't look as if you had applied comment 6 when the
test was carried out - since the link line includes both errors.o and
libcommon.a.

>Alternative, we can simply drop the use of '-c' with ranlib and be
> done with it.

let's complete the testing on darwin 8 - and, if that is OK, I'll produce a
patch to remove the special casing of ranlib on darwin entirely (as suggested
by Mike).

[Bug c++/50054] Fails to recover from type error in function signature

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-12
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2011-08-12 
08:57:07 UTC ---
confirmed, 4.5 gave:
:4:17: error: insufficient contextual information to determine type

[Bug libgcj/50053] [4.7 regression] SIGSEGV in natClass.cc:651

[jojelino at gmail dot com]

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

--- Comment #2 from gee  2011-08-12 08:59:41 UTC ---
(In reply to comment #1)
> Try to build everything with -fno-ipa-sra -fno-ipa-cp.
I understand what you meant is "append -fno-ipa-sra -fno-ipa-cp to
{C,CXX,GCJ}FLAGS when building libgcj"

[Bug target/34790] [avr] no sibling call optimisation

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org
 Resolution|WORKSFORME  |FIXED
   Target Milestone|--- |4.7.0

--- Comment #5 from Georg-Johann Lay  2011-08-12 
11:35:29 UTC ---
Sibcalls are supported in avr-gcc 4.7+
  http://gcc.gnu.org/viewcvs?view=revision&revision=171300

[Bug fortran/50050] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-12
 CC||mikael at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Mikael Morin  2011-08-12 
11:41:38 UTC ---
Confirmed on recent (patched, but I don't think it matters) trunk on freeBSD:
GNU Fortran (GCC) 4.7.0 20110806 (experimental)

$ valgrind ~/gcc4x/build/gcc/f951 comment_0.f90
==5119== Memcheck, a memory error detector
==5119== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==5119== Using Valgrind-3.6.0 and LibVEX; rerun with -h for copyright info
==5119== Command: /home/mik/gcc4x/build/gcc/f951 comment_0.f90
==5119== 
 bug main==5119== Invalid read of size 4
==5119==at 0x1E3AB90: __gmpz_clear (in /usr/local/lib/libgmp.so.10)
==5119==by 0x4DBA0E: free_expr0(gfc_expr*) (expr.c:479)
==5119==by 0x4DBB6D: gfc_free_expr(gfc_expr*) (expr.c:497)
==5119==by 0x543421: gfc_free_statement(gfc_code*) (st.c:84)
==5119==by 0x54358C: gfc_free_statements(gfc_code*) (st.c:233)
==5119==by 0x5482B1: gfc_free_namespace(gfc_namespace*) (symbol.c:3246)
==5119==by 0x548BFF: gfc_symbol_done_2() (symbol.c:3291)
==5119==by 0x50A008: gfc_done_2() (misc.c:266)
==5119==by 0x51BD03: gfc_parse_file() (parse.c:4334)
==5119==by 0x554085: gfc_be_parse_file() (f95-lang.c:250)
==5119==by 0x8E64D7: toplev_main(int, char**) (toplev.c:548)
==5119==by 0x4B5F1B: (below main) (in /usr/home/mik/gcc4x/build/gcc/f951)
==5119==  Address 0x247b4d0 is 0 bytes after a block of size 16 alloc'd
==5119==at 0x25990A: calloc (in
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5119==by 0xDF4348: xcalloc (xmalloc.c:162)
==5119==by 0x4DBD53: gfc_copy_shape(__mpz_struct (*) [1], int) (expr.c:689)
==5119==by 0x4DBDE5: gfc_copy_expr(gfc_expr*) (expr.c:391)
==5119==by 0x525908: gfc_expr_to_initialize(gfc_expr*) (resolve.c:6549)
==5119==by 0x53021A: resolve_allocate_deallocate(gfc_code*, char const*)
(resolve.c:6864)
==5119==by 0x532796: resolve_code(gfc_code*, gfc_namespace*)
(resolve.c:9302)
==5119==by 0x53429E: resolve_codes(gfc_namespace*) (resolve.c:13757)
==5119==by 0x525D07: gfc_resolve(gfc_namespace*) (resolve.c:13784)
==5119==by 0x51BBAF: gfc_parse_file() (parse.c:4247)
==5119==by 0x554085: gfc_be_parse_file() (f95-lang.c:250)
==5119==by 0x8E64D7: toplev_main(int, char**) (toplev.c:548)

[Bug libgcj/50053] [4.7 regression] SIGSEGV in natClass.cc:651

[jojelino at gmail dot com]

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

--- Comment #3 from gee  2011-08-12 11:44:58 UTC ---
using only '-fno-ipa-sra -fno-ipa-cp' didn't work too.

Reading symbols from /usr/i686-pc-mingw32/java/bin/i686-pc-mingw32-gij...done.
(gdb) r
Starting program: /usr/i686-pc-mingw32/java/bin/i686-pc-mingw32-gij -cp .
foobar --verbose
[New Thread 9260.0x2b18]
[New Thread 9260.0x3634]

Program received signal SIGSEGV, Segmentation fault.
0x6a45d594 in java::lang::Class::isPrimitive (this=0x1)
at ../.././libjava/java/lang/Class.h:428
428   return vtable == JV_PRIMITIVE_VTABLE;
(gdb) bt
#0  0x6a45d594 in java::lang::Class::isPrimitive (this=0x1)
at ../.././libjava/java/lang/Class.h:428
#1  0x696ca56f in java::lang::Class::newInstance (this=0x1)
at ../.././libjava/java/lang/natClass.cc:651
#2  0x6a432d37 in ffi_call_win32 () at ../.././libffi/src/x86/win32.S:424
#3  0x6a432d13 in ffi_raw_call (cif=0xbf0a0c,
fn=0x696ca546 , rvalue=0x22e8c4,
fake_avalue=0x22e5a0) at ../.././libffi/src/x86/ffi.c:647
#4  0x696a351f in _Jv_InterpMethod::run (retp=0x22f104, args=0x22f124,
meth=0xe12f60) at ../.././libjava/interpret-run.cc:611
#5  0x696a2251 in _Jv_InterpMethod::run_normal (ret=0x22f104, args=0x22f124,
__this=0xe12f60) at ../.././libjava/interpret.cc:358
#6  0x6a432ee5 in ffi_closure_raw_SYSV () at ../.././libffi/src/x86/win32.S:695
#7  0x6a432d37 in ffi_call_win32 () at ../.././libffi/src/x86/win32.S:424
#8  0x6a432d13 in ffi_raw_call (cif=0xbf0b24, fn=0xe30098, rvalue=0x22f4e0,
fake_avalue=0x22f1c0) at ../.././libffi/src/x86/ffi.c:647
#9  0x696a351f in _Jv_InterpMethod::run (retp=0x22fd20, args=0x22fd40,
meth=0xab8e60) at ../.././libjava/interpret-run.cc:611
#10 0x696a237a in _Jv_InterpMethod::run_class (ret=0x22fd20, args=0x22fd40,
__this=0xab8e60) at ../.././libjava/interpret.cc:407
#11 0x6a432ee5 in ffi_closure_raw_SYSV () at ../.././libffi/src/x86/win32.S:695
#12 0x696c282c in gnu::java::lang::MainThread::call_main (this=0xbfdf60)
at ../.././libjava/gnu/java/lang/natMainThread.cc:54
---Type  to continue, or q  to quit---
#13 0x6973c37d in gnu.java.lang.MainThread.run()void (this=@bfdf60)
at /tmp/gcc/libjava/gnu/java/lang/MainThread.java:106
#14 0x696d4d4d in _Jv_ThreadRun (thread=0xbfdf60)
at ../.././libjava/java/lang/natThread.cc:335
#15 0x69684e9b in _Jv_RunMain (vm_args=0x22fef4, klass=0x0,
name=0x3d8925 "foobar", argc=0x2, argv=0x3d89fc, is_jar=0x0)
at ../.././libjava/prims.cc:1789
#16 0x66bc24b0 in _fu0___ZN3gcj13verifyClassesE ()
at ../.././libjava/gij.cc:333
#17 0x004010fd in __mingw_CRTStartup () at ../../.././winsup/mingw/crt1.c:244
#18 0x0408 in ?? ()
#19 0x7ffda000 in ?? ()
#20 0x in ?? ()
(gdb) Quit
(gdb) down
Bottom (innermost) frame selected; you cannot go down.
(gdb)
Bottom (innermost) frame selected; you cannot go down.
(gdb)
Bottom (innermost) frame selected; you cannot go down.
(gdb)
Bottom (innermost) frame selected; you cannot go down.
(gdb)
Bottom (innermost) frame selected; you cannot go down.
(gdb)
Bottom (innermost) frame selected; you cannot go down.
(gdb)
Bottom (innermost) frame selected; you cannot go down.
(gdb)
Bottom (innermost) frame selected; you cannot go down.
(gdb)
Bottom (innermost) frame selected; you cannot go down.
(gdb) print vtable
Cannot access memory at address 0x35
(gdb) print this
$1 = (java::lang::Class * const) 0x1
(gdb) i r
eax0x1  0x1
ecx0x1  0x1
edx0x0  0x0
ebx0x696ca546   0x696ca546
esp0x22e4a8 0x22e4a8
ebp0x22e4c0 0x22e4c0
esi0xe300bc 0xe300bc
edi0x22e5a4 0x22e5a4
eip0x6a45d594   0x6a45d594

eflags 0x10212  [ AF IF RF ]
cs 0x1b 0x1b
ss 0x23 0x23
ds 0x23 0x23
es 0x23 0x23
fs 0x3b 0x3b
gs 0x0  0x0
(gdb) disass
Dump of assembler code for function java::lang::Class::isPrimitive():
   0x6a45d588 <+0>: push   %ebp
   0x6a45d589 <+1>: mov%esp,%ebp
   0x6a45d58b <+3>: sub$0x18,%esp
   0x6a45d58e <+6>: mov%ecx,-0xc(%ebp)
   0x6a45d591 <+9>: mov-0xc(%ebp),%eax
=> 0x6a45d594 <+12>:mov0x34(%eax),%eax
   0x6a45d597 <+15>:cmp$0x,%eax
   0x6a45d59a <+18>:sete   %al
   0x6a45d59d <+21>:leave
   0x6a45d59e <+22>:ret
End of assembler dump.
(gdb) up
#1  0x696ca56f in java::lang::Class::newInstance (this=0x1)
at ../.././libjava/java/lang/natClass.cc:651
651   if (isPrimitive ()
(gdb) disass
Dump of assembler code for function java::lang::Class::newInstance():
   0x696ca546 <+0>: push   %ebp
   0x696ca547 <+1>: mov%esp,%ebp
   0x696ca549 <+3>: push   %esi
   0x696ca54a <+4>: push   %ebx
   0x696ca54b <+5>: sub$0x30,%esp
   0x696ca54e <+8>: mov%ecx,-0x1c(%ebp)
   0x696ca551 <+11>:mov-0x1c(%ebp),%eax
   0x696ca554 <+14>:movl   $0x0,(%esp)
   0x6

[Bug c++/50055] New: [PATCH] Location information for the throw() specification in a function may be incorrect

[siddhesh.poyarekar at gmail dot com]

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

 Bug #: 50055
   Summary: [PATCH] Location information for the throw()
specification in a function may be incorrect
Classification: Unclassified
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: siddhesh.poyare...@gmail.com


Created attachment 24990
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24990
Write EH_SPEC_BLOCK to the same line as its function

Problem Description:

The line number information for throw() exception specifier should be the same
as the function it is written against. For the following program:

struct mtcClass {
  mtcClass() throw(int)
  {
throw(1);
  }
};

int main()
{
  try
  {
mtcClass mtc;
  }
  catch(...)
  {
return 42;
  }
}

gcov returns the following output after execution:

-:0:Source:mtc_bad.cpp
-:0:Graph:mtc_bad.gcno
-:0:Data:mtc_bad.gcda
-:0:Runs:1
-:0:Programs:1
-:1:struct mtcClass {
1:2:mtcClass() throw(int) 
#:3:{
1:4:throw(1);
-:5:}
-:6:};
-:7:
1:8:int main()
-:9:{
-:   10:try {
1:   11:mtcClass mtc;
-:   12:}
2:   13:catch( ...) {
1:   14:return 42;
-:   15:}
#:   16:}


This happens during parsing where the EH_SPEC_BLOCK is written out with line
number as the one after the function decl. Attached patch modifies code to
write out the code for the throw() specification with the same line number as
the function.

[Bug fortran/50050] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2

[mikael at gcc dot gnu.org]

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

--- Comment #2 from Mikael Morin  2011-08-12 
11:54:27 UTC ---
In gfc_expr_to_initialize, we copy an expression, 

  result = gfc_copy_expr (e);


and then change it to something else:

  /* Change the last array reference from AR_ELEMENT to AR_FULL.  */
  for (ref = result->ref; ref; ref = ref->next)
if (ref->type == REF_ARRAY && ref->next == NULL)
  {
ref->u.ar.type = AR_FULL;

for (i = 0; i < ref->u.ar.dimen; i++)
  ref->u.ar.start[i] = ref->u.ar.end[i] = ref->u.ar.stride[i] = NULL;

result->rank = ref->u.ar.dimen;
break;
  }


Not very surprising that it fails.

[Bug c++/50055] [PATCH] Location information for the throw() specification in a function may be incorrect

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2011-08-12 
12:18:37 UTC ---
Patches go to the gcc-patches mailing list. Also, always clearly state how you
tested it, etc, according to the guidelines http://gcc.gnu.org/contribute.html

[Bug c++/50056] New: Binding a temporary object to a reference

[wolfgang.roe...@gi-de.com]

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

 Bug #: 50056
   Summary: Binding a temporary object to a reference
Classification: Unclassified
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wolfgang.roe...@gi-de.com


Hi all,

I would like to post a bug report for the GNU C/C++ compiler
version 4.5.2 (powerpc-rtems4.11).

We use the compiler to generate code for a PowerPC processor.

The compiler is invoked with the following options:

ccppc -c -x c++ -ansi -Wall -Werror -g -mcpu=8540 -fverbose-asm -mbig
  -mfloat-gprs=double -mspe -mabi=spe -meabi -msdata -fno-common
  -mmultiple -mno-string -misel -mstrict-align -fgcse-sm
  -fno-rename-registers -fno-section-anchors -G 8 -Os
  -fno-exceptions -fno-rtti
  -I
  -D
  X.CPP -oX.O

// file X.CPP

struct S
{
S();
~S();
void func () const;
};

void test (void)
{
const S& s = static_cast(S());

s.func ();
}


The code compiles fine but function test() is translated to the following
pseudo code:
  call S::S()
  call S::~S()--> now we have a dangling reference s without an object
  call S::func()  --> calling an element function without an object


Kind regards
W. Roehrl

[Bug fortran/50050] Internal compiler error free_expr0 at expr.c:3709 via gfc_done_2

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #3 from Mikael Morin  2011-08-12 
12:38:45 UTC ---
Created attachment 24991
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24991
Tentative patch

This should fix the issue.

[Bug c++/50056] Binding a temporary object to a reference

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2011-08-12 
12:46:42 UTC ---
Are you sure G++ isn't correct?
The cast creates a temporary reference, which binds to the temporary object,
then initalizes 's' with the temporary reference. That means the temporary
object's lifetime is extended to the same lifetime as the reference, but the
reference is temporary so is destroyed at the end of the full expression.

call S::S()
bind to temporary reference
initialize s from temporary reference
temporary reference goes out of scope
call S::~S()
call S::func()
s goes out of scope

if you do this:

const S& s = S();

then you get the behaviour I assume you are expecting:

call S::S()
initialize s temporary object
call S::func()
s goes out of scope
call S::~S()

[Bug libgcj/50057] New: [4.7 regression] SIGSEGV in natObject.cc:58

[jojelino at gmail dot com]

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

 Bug #: 50057
   Summary: [4.7 regression] SIGSEGV in natObject.cc:58
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jojel...@gmail.com
  Host: i686-pc-cygwin
Target: i686-pc-mingw32
 Build: i686-pc-cygwin


Created attachment 24992
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24992
try to resolve 'o1' class on runtime, and got sigsegv

when referenced class(oo1) is not found in classpath, it throwed
classnotfoundexception.
but it sigsegved 

Starting program: /usr/i686-pc-mingw32/java/bin/i686-pc-mingw32-gij -cp .
foobar --verbose
[New Thread 7704.0x1af8]
[New Thread 7704.0x2b60]

Program received signal SIGSEGV, Segmentation fault.
0x696cfc4a in java::lang::Object::getClass (this=0x0)
at ../.././libjava/java/lang/natObject.cc:58
58return (*dt)->clas;
(gdb) bt
#0  0x696cfc4a in java::lang::Object::getClass (this=0x0)
at ../.././libjava/java/lang/natObject.cc:58
#1  0x696b8bbf in _Jv_InterpMethod::check_handler (this=0xe12f60, pc=0x22e8d8,
meth=0xe12f60, ex=0x0) at ../.././libjava/interpret.cc:1463
#2  0x696a99f5 in _Jv_InterpMethod::run (retp=0x22f104, args=0x22f124,
meth=0xe12f60) at ../.././libjava/interpret-run.cc:2676
#3  0x696a2251 in _Jv_InterpMethod::run_normal (ret=0x22f104, args=0x22f124,
__this=0xe12f60) at ../.././libjava/interpret.cc:358
#4  0x6a432ee5 in ffi_closure_raw_SYSV () at ../.././libffi/src/x86/win32.S:695
#5  0x6a432d37 in ffi_call_win32 () at ../.././libffi/src/x86/win32.S:424
#6  0x6a432d13 in ffi_raw_call (cif=0xbf0b24, fn=0xe30098, rvalue=0x22f4e0,
fake_avalue=0x22f1c0) at ../.././libffi/src/x86/ffi.c:647
#7  0x696a351f in _Jv_InterpMethod::run (retp=0x22fd20, args=0x22fd40,
meth=0xab8e60) at ../.././libjava/interpret-run.cc:611
#8  0x696a237a in _Jv_InterpMethod::run_class (ret=0x22fd20, args=0x22fd40,
__this=0xab8e60) at ../.././libjava/interpret.cc:407
#9  0x6a432ee5 in ffi_closure_raw_SYSV () at ../.././libffi/src/x86/win32.S:695
#10 0x696c282c in gnu::java::lang::MainThread::call_main (this=0xbfdf60)
at ../.././libjava/gnu/java/lang/natMainThread.cc:54
#11 0x6973c37d in gnu.java.lang.MainThread.run()void (this=@bfdf60)
at /tmp/gcc/libjava/gnu/java/lang/MainThread.java:106
#12 0x696d4d4d in _Jv_ThreadRun (thread=0xbfdf60)
at ../.././libjava/java/lang/natThread.cc:335
---Type  to continue, or q  to quit---
#13 0x69684e9b in _Jv_RunMain (vm_args=0x22fef4, klass=0x0,
name=0x3d8925 "foobar", argc=0x2, argv=0x3d89fc, is_jar=0x0)
at ../.././libjava/prims.cc:1789
#14 0x66bc24b0 in _fu0___ZN3gcj13verifyClassesE ()
at ../.././libjava/gij.cc:333
#15 0x004010fd in __mingw_CRTStartup () at ../../.././winsup/mingw/crt1.c:244
#16 0x0408 in ?? ()
#17 0x7ffd4000 in ?? ()
#18 0x in ?? ()
(gdb)

and _Jv_Throw doesn't seem to pass throwable as argument of
unwind_raiseexception, as a consequence, catch(Throwable e){someoperaton(e);}
leads SIGSEGV.

[Bug c++/50058] New: [4.7 Regression] FAIL: g++.dg/tree-ssa/pr41186.C

[hjl.tools at gmail dot com]

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

 Bug #: 50058
   Summary: [4.7 Regression] FAIL: g++.dg/tree-ssa/pr41186.C
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: rgue...@gcc.gnu.org


On Linux/x86, revision 177691:

http://gcc.gnu.org/ml/gcc-cvs/2011-08/msg00705.html

caused:

FAIL: g++.dg/tree-ssa/pr41186.C scan-tree-dump fre1 "Replaced b1.D.[0-9]*.f
with 1"
FAIL: g++.dg/tree-ssa/pr41186.C scan-tree-dump fre1 "Replaced b1.D.[0-9]*.i
with 0"

[Bug c++/50059] New: [C++0x] Broken error message with __builtin_remquo & constexpr

[paolo.carlini at oracle dot com]

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

 Bug #: 50059
   Summary: [C++0x] Broken error message with __builtin_remquo &
constexpr
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com


Consider this:

int r = 0;
constexpr double d = __builtin_remquo(1, 1, &r);

The error message is:

a.cc:2:49: error: expression ‘(r  1)’ is not a
constant-expression

[Bug c++/50059] [C++0x] Broken error message with __builtin_remquo & constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2011-08-12 
14:49:27 UTC ---
__builtin_modf has similar problems

[Bug c++/50056] Binding a temporary object to a reference

[wolfgang.roe...@gi-de.com]

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

--- Comment #2 from Wolfgang Roehrl  2011-08-12 
14:51:25 UTC ---
Hi Jonathan,

I would analyze the crucial line of the code as follows:

The cast creates a temporary reference, which binds to the temporary 
object,
and then initalizes 's' with the temporary reference. The latter means:

A) 's' is initialized with a temporary S-object which appears as an 
lvalue:
   Cf. 5/6: "If an expression initially has the type "reference to T" 
(8.3.2,
   8.5.3), the type is adjusted to "T" prior to any further analysis, the
   expression designates the object or function denoted by the reference,
   and the expression is an lvalue."

B) 's' is directly bound to the temporary S-object:
   Cf. 8.5.3/5, Bullet 1: "If the initializer expression
   - is an lvalue (but is not a bit-field), and "cv1 T1" is reference-
 compatible with "cv2 T2," ... then the reference is bound directly
 to the initializer expression lvalue."

C) 12.2/5 says that the lifetime of a temporary which is bound to a 
reference
   is extended to the lifetime fo the reference.

I'm not sure if this analysis is really correct but it seems reasonable to 
me.
Otherwise we would have a reference without an object.

Best regards,
W. Roehrl







"redi at gcc dot gnu.org"  
12.08.2011 14:47

An
wolfgang.roe...@gi-de.com
Kopie

Thema
[Bug c++/50056] Binding a temporary object to a reference






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

--- Comment #1 from Jonathan Wakely  2011-08-12 
12:46:42 UTC ---
Are you sure G++ isn't correct?
The cast creates a temporary reference, which binds to the temporary 
object,
then initalizes 's' with the temporary reference. That means the temporary
object's lifetime is extended to the same lifetime as the reference, but 
the
reference is temporary so is destroyed at the end of the full expression.

call S::S()
bind to temporary reference
initialize s from temporary reference
temporary reference goes out of scope
call S::~S()
call S::func()
s goes out of scope

if you do this:

const S& s = S();

then you get the behaviour I assume you are expecting:

call S::S()
initialize s temporary object
call S::func()
s goes out of scope
call S::~S()

[Bug c++/50059] [C++0x] Broken error message with __builtin_remquo & constexpr

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-12
 CC||jason at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Paolo Carlini  2011-08-12 
15:06:49 UTC ---
Happens also with  and std::remquo, std::modf, CC-ing Jason.

[Bug c/50032] Bad optimization with sin/cos

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  2011-08-12 
15:10:51 UTC ---
> if your math library implementation has a slower cosf than cos it's
> definitely broken ;)

So it is at least for fedora (see
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5997
http://sourceware.org/bugzilla/show_bug.cgi?id=5781
https://bugzilla.redhat.com/show_bug.cgi?id=521190 and pr34128).

I suspect it is for most (all?) linux libraries (I am not in position to check
it, but the above pointer will allow anyone interested to see by
her/himself;-).

[Bug bootstrap/49681] 4.6.1 cross-build fails in libquadmath/libiberty

[manuel.lauss at googlemail dot com]

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

Manuel Lauss  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #4 from Manuel Lauss  
2011-08-12 15:11:09 UTC ---
Seems to have been a Gentoo-problem after all: Just built 4.6.1
for mipsel-softfloat-linux-gnu without a hitch.

# mipsel-softfloat-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/mipsel-softfloat-linux-gnu/gcc-bin/4.6.1/mipsel-softfloat-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/mipsel-softfloat-linux-gnu/4.6.1/lto-wrapper
Target: mipsel-softfloat-linux-gnu
Configured with:
/tmp-ram/portage/cross-mipsel-softfloat-linux-gnu/gcc-4.6.1/work/gcc-4.6.1/configure
--prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/mipsel-softfloat-linux-gnu/gcc-bin/4.6.1
--includedir=/usr/lib/gcc/mipsel-softfloat-linux-gnu/4.6.1/include
--datadir=/usr/share/gcc-data/mipsel-softfloat-linux-gnu/4.6.1
--mandir=/usr/share/gcc-data/mipsel-softfloat-linux-gnu/4.6.1/man
--infodir=/usr/share/gcc-data/mipsel-softfloat-linux-gnu/4.6.1/info
--with-gxx-include-dir=/usr/lib/gcc/mipsel-softfloat-linux-gnu/4.6.1/include/g++-v4
--host=x86_64-pc-linux-gnu --target=mipsel-softfloat-linux-gnu
--build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point
--without-ppl --without-cloog --enable-lto --with-float=soft --disable-nls
--with-system-zlib --disable-werror --enable-secureplt --disable-multilib
--disable-libmudflap --disable-libssp --disable-libgomp --enable-cld
--with-python-dir=/share/gcc-data/mipsel-softfloat-linux-gnu/4.6.1/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++
--with-sysroot=/usr/mipsel-softfloat-linux-gnu --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.1 p1.0'
--with-mips-plt --with-arch=mips32 --with-tune=mips32 --with-float=soft
--with-llsc
Thread model: posix
gcc version 4.6.1 (Gentoo 4.6.1 p1.0)

[Bug middle-end/50060] New: intrinsics not folded by the middle-end

[paolo.carlini at oracle dot com]

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

 Bug #: 50060
   Summary: intrinsics not folded by the middle-end
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com


Following up to 49813, this is a list of intrinsics, corresponding to C89 and
C99  (and C++11 ) facilities, not yet folded by the middle-end.

C89:
- fmod
- frexp

C99:
- lgamma
- llrint
- lrint
- nearbyint
- nextafter
- nexttoward
- remquo
- rint

Note: in the audit trail of PR49813, Comment #51, Jakub explains that nextafter
and nexttoward should be doable rather easily.

[Bug middle-end/50060] intrinsics not folded by the middle-end

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2011-08-12 
16:12:56 UTC ---
Uhm, remquo is strange. I see a do_mpfr_remquo but the following C++11 snippet
is rejected, I don't know why:

int r = 0;
constexpr double d = __builtin_remquo(1.0, 1.0, &r);

[Bug libfortran/50016] The fortran program 's io is very slow

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle  2011-08-12 
16:17:21 UTC ---
I would like to see if Kai has any thought on this.  Unfortunately I am not
very familiar with the windows OS.

[Bug c++/50059] [C++0x] Broken error message with __builtin_remquo & constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2011-08-12 
16:21:08 UTC ---
... and __builtin_frexp (std::frexp)

[Bug middle-end/50060] intrinsics not folded by the middle-end

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  2011-08-12 
16:26:00 UTC ---
... frexp also don't understand at the moment. I see a fold_builtin_frexp but
the following doesn't compile:

int r = 0;
constexpr double d = __builtin_frexp(1.0, &r);

[Bug target/48328] GCC failed to generate 16bit relative jump table

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  2011-08-12 
16:58:13 UTC ---
Author: ramana
Date: Fri Aug 12 16:58:09 2011
New Revision: 177705

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177705
Log:

Fix PR target/48328 part 1

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.h

[Bug middle-end/50060] intrinsics not folded by the middle-end

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Paolo Carlini  2011-08-12 
17:00:10 UTC ---
I think we can safely scratch frexp & remquo from the list: I double checked
that the middle-end functions correctly compute the constants.

(It seems more a problem with my C++ test snippets in Comments #1 / #2: I
suppose any definition of such functions isn't viable for constexpr, because
the body has to assign the pointed integer additionally to returning a value...
If Jason could confirm it would be great)

Updated list:
C89:
- fmod

C99:
- lgamma
- llrint
- lrint
- nearbyint
- nextafter
- nexttoward
- rint

[Bug c/50032] Bad optimization with sin/cos

[fbafelipe at gmail dot com]

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

--- Comment #3 from Felipe  2011-08-12 17:07:47 UTC 
---
(In reply to comment #2)
> > if your math library implementation has a slower cosf than cos it's
> > definitely broken ;)
> 
> So it is at least for fedora (see
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=5997
> http://sourceware.org/bugzilla/show_bug.cgi?id=5781
> https://bugzilla.redhat.com/show_bug.cgi?id=521190 and pr34128).
> 
> I suspect it is for most (all?) linux libraries (I am not in position to check
> it, but the above pointer will allow anyone interested to see by
> her/himself;-).

Tested in Arch Linux and it has the same problem.

(In reply to comment #1)
> You can disable the optimization via -fno-builtin-sincos

This flag didn't solve the problem (compiling with O1/O2/O3 is still slower
than O0).

> Btw,
> 
> float ang = i*j*2*M_PI/N;
> 
> is performed in double arithmetic as well, as M_PI is a double constant.
> You'll likely get faster code with using
> 
> float ang = i*j*2*((float)M_PI)/N;
> 


I am aware of that, but the code was just a minimalist working example.

> btw, you didn't specify if you are using 32bit or 64bit code.

It is 64bits.

Some bug reports for this performance issue date from 2008, so it seems we
won't see that fixed any time soon.

[Bug bootstrap/50047] [4.7 Regression] Revision 177670 failed to bootstrap

[bonzini at gnu dot org]

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

--- Comment #1 from Paolo Bonzini  2011-08-12 17:13:10 
UTC ---
Author: bonzini
Date: Fri Aug 12 17:13:04 2011
New Revision: 177706

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177706
Log:
2011-08-12  Paolo Bonzini  

PR bootstrap/50047
* Makefile.in (install-unwind_h): Create
$(gcc_objdir)/include/unwind.h atomically.


Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/Makefile.in

[Bug middle-end/50061] New: [4.7 regression] emit_library_call_value_1 change broke SF->TI conversion on MIPS

[ro at gcc dot gnu.org]

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

 Bug #: 50061
   Summary: [4.7 regression] emit_library_call_value_1 change
broke SF->TI conversion on MIPS
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: rdsandif...@googlemail.com
  Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
 Build: mips-sgi-irix6.5


Julian,

your patch

2011-08-01  Julian Brown  

* calls.c (emit_library_call_value_1): Support padding for libcall
arguments and return values.
* config/arm/arm.c (arm_pad_arg_upward): Pad half-float values
downwards in big-endian mode.

introduced several testsuite regressions on IRIX 6.5.  Initially, I suspected
that my fp-bit move to toplevel gcc had been the culprit, but a reghunt
identified
your patch.  I've used the following testcase, derived from
gcc.dg/torture/fp-int-convert-timode.c.  It aborts with your patch:

extern void abort (void);
extern void exit (int);

typedef int TItype __attribute__ ((mode (TI)));

int
main (void)
{
  static volatile TItype ivin, ivout;
  static volatile float  fv1, fv2;

  ivin = (TItype)1;
  fv1 = (TItype)1;
  fv2 = ivin;
  ivout = fv2;

  if (ivin != ((TItype)1)
  || ivout != ivin
  || ivout != (TItype)1
  || fv1 != (TItype)1
  || fv2 != (TItype)1
  || fv1 != fv2)
abort ();

  exit (0);
}

Comparing gcc -O3 -save-temps output before and after the patch, I find that
it introduced a wrong shift of one __fixsfti arg:

ld  $25,%call16(__fixsfti)($28)
+   dmfc1   $2,$f12
+   nop
+   dsll$2,$2,32
+   dmtc1   $2,$f12
jalr$25

Please fix.

  Rainer

[Bug c++/50059] [C++0x] Broken error message with __builtin_remquo & constexpr

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2011-08-12 
18:01:43 UTC ---
And I suspect that this diagnostic issue may be not unrelated to what I was
noticing today together with PR50060: these badly printed intrinsics (remquo,
modf, frexp) can be optimized by the middle-end but aren't really viable as
constexpr functions because of the pointer parameter. Thus, by the time error.c
is involved the middle-end has computed the constants and erased any info about
the name of the intrinsics. Can be?

[Bug fortran/50062] New: GNU Fortran is not working

[hsong6 at ucsc dot edu]

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

 Bug #: 50062
   Summary: GNU Fortran is not working
Classification: Unclassified
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hso...@ucsc.edu


Dear expert, 

While I was trying to install gcc-4.3.4, I got an error.
Currently, my machine has gcc-4.2 and gcc-4.5.
But I would like to install gcc-4.3.4 because other program supports this
version.

During the compilation, I set gcc-4.2 to be avaible.

I would really appreciate any comments.
Thank you.

HJ

[Bug fortran/50062] GNU Fortran is not working

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Paolo Carlini  2011-08-12 
18:14:13 UTC ---
This isn't a valid PR. You may try sending a *detailed* message to the gcc-help
mailing list.

[Bug c/50032] Bad optimization with sin/cos

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  2011-08-12 
18:28:56 UTC ---
> Some bug reports for this performance issue date from 2008, so it seems we
> won't see that fixed any time soon.

IIRC the excuses were:
(1) nobody use float (fortran does not exist indeed!-),
(2) the results are "correctly rounded",
(3) why don't you write the library yourself?

If the linux users don't put some pressure on their favorite "vendor", the
problem will never be fixed. I cannot say I really care since darwin provide a
sensible library for float intrinsics (it seems that AMD is also providing one)
also I have been bitten by the problem while helping a colleague to debug his
code on our linux boxes.

[Bug c++/50055] [PATCH] Location information for the throw() specification in a function may be incorrect

[siddhesh.poyarekar at gmail dot com]

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

--- Comment #2 from Siddhesh Poyarekar  
2011-08-12 19:21:15 UTC ---
Thanks, done, with a test case this time:

http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01158.html

As mentioned in the submission, I ran the existing c++ tests to make sure I did
not cause any regressions.

[Bug fortran/49693] Spurious "unused-variable" warnings for COMMON block module variables.

[longb at cray dot com]

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

Bill Long  changed:

   What|Removed |Added

 CC||longb at cray dot com

--- Comment #1 from Bill Long  2011-08-12 19:22:50 UTC 
---
Had a user support with similar issues when using the MPI module.  Test case:

module dmi_mpi_global
   use mpi
   implicit none
   private

   logical,save, public :: debug_print
   integer(4), save, public :: iu06
   integer(4), save, public :: mpi_io_rank = 0
   character(LEN=256), save, public :: mpi_decomp_file = 'mpi_decompo.txt'
   public :: dmpi_close

contains

  subroutine dmpi_close ( flag )
 implicit none
 logical, intent(in) :: flag
 integer(4) :: ierr

 if (flag) then
   write(*,'(a19)') 'Time to die for MPI'
 else
   write(iu06,'(a19)') 'Time to die for MPI'
 endif

 if (.not.flag) close (iu06)

 call mpi_finalize(ierr)

   end subroutine dmpi_close
end module dmi_mpi_global


> ftn -c -Wall test.f90
test.f90:2:0: warning: 'mpi_bottom' defined but not used [-Wunused-variable]
test.f90:2:0: warning: 'mpi_in_place' defined but not used [-Wunused-variable]
test.f90:2:0: warning: 'mpi_status_ignore' defined but not used
[-Wunused-variable]
test.f90:2:0: warning: 'mpi_statuses_ignore' defined but not used
[-Wunused-variable]
test.f90:2:0: warning: 'mpi_errcodes_ignore' defined but not used
[-Wunused-variable]
test.f90:2:0: warning: 'mpi_unweighted' defined but not used
[-Wunused-variable]
test.f90:2:0: warning: 'mpi_argvs_null' defined but not used
[-Wunused-variable]
test.f90:2:0: warning: 'mpi_argv_null' defined but not used [-Wunused-variable]

[Bug fortran/50062] GNU Fortran is not working

[hsong6 at ucsc dot edu]

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

--- Comment #2 from hsong6 at ucsc dot edu 2011-08-12 19:38:46 UTC ---
Thank you for pointing out.

Here is an error message
--

checking whether the GNU Fortran compiler is working... no
configure: error: GNU Fortran is not working; please report a bug in
http://gcc.gnu.org/bugzilla, attaching
/home/hsong/objdir/x86_64-unknown-linux-gnu/libgfortran/config.log
make[1]: *** [configure-target-libgfortran] Error 1
make[1]: Leaving directory `/auto/home/hsong/objdir'
make: *** [all] Error 2

---

Thank you.
HJ

[Bug target/50063] New: [avr]: wrong code for gcc.dg/torture/pta-ptrarith-3.c

[gjl at gcc dot gnu.org]

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

 Bug #: 50063
   Summary: [avr]: wrong code for gcc.dg/torture/pta-ptrarith-3.c
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Target: avr


Testcase gcc.dg/torture/pta-ptrarith-3.c
  
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.dg/torture/pta-ptrarith-3.c?revision=145490&view=markup
produces wrong code for current trunk and avr-gcc 4.6.1

struct X 
{
  int *p;
  int *q;
  int *r;
};

int __attribute__((noinline))
foo (int i, int j, int k, int off)
{
  struct X x;
  int **p, *q;
  x.p = &i;
  x.q = &j;
  x.r = &k;
  p = &x.q;
  p += off;
  /* *p points to { i, j, k } */
  q = *p;
  return *q;
}

With -Os -mmcu=atmega88 4.6.1 output is (wrong):

foo:
push r28 ;  42*pushqi/1[length = 1]
push r29 ;  43*pushqi/1[length = 1]
in r28,__SP_L__ ;  44*movhi_sp/2[length = 2]
in r29,__SP_H__
sbiw r28,12 ;  45*addhi3/3[length = 1]
in __tmp_reg__,__SREG__ ;  46*movhi_sp/1[length = 5]
cli
out __SP_H__,r29
out __SREG__,__tmp_reg__
out __SP_L__,r28
/* prologue: function */
/* frame size = 12 */
/* stack size = 14 */
.L__stack_usage = 14
std Y+8,r25 ;  2*movhi/3[length = 2]
std Y+7,r24
std Y+10,r23 ;  3*movhi/3[length = 2]
std Y+9,r22
std Y+12,r21 ;  4*movhi/3[length = 2]
std Y+11,r20
lsl r18 ;  55*ashlhi3_const/2[length = 2]
rol r19
add r18,r28 ;  16*addhi3/1[length = 2]
adc r19,r29
movw r26,r18 ;  41*movhi/1[length = 1]
adiw r26,3 ;  18*movhi/2[length = 4]
ld r30,X+
ld r31,X
sbiw r26,3+1
ld r24,Z ;  35*movqi/4[length = 1]
ldd r25,Z+1 ;  36*movqi/4[length = 1]
/* epilogue start */
adiw r28,12 ;  49*addhi3/2[length = 1]
in __tmp_reg__,__SREG__ ;  50*movhi_sp/1[length = 5]
cli
out __SP_H__,r29
out __SREG__,__tmp_reg__
out __SP_L__,r28
pop r29 ;  51popqi[length = 1]
pop r28 ;  52popqi[length = 1]
ret ;  53return_from_epilogue[length = 1]



With 4.5.2 and same options, the test case runs on exit:


foo:
push r29 ;  42*pushhi/1[length = 2]
push r28
in r28,__SP_L__ ;  43*movhi_sp/2[length = 2]
in r29,__SP_H__
sbiw r28,12 ;  44*addhi3/3[length = 1]
in __tmp_reg__,__SREG__ ;  45*movhi_sp/1[length = 5]
cli
out __SP_H__,r29
out __SREG__,__tmp_reg__
out __SP_L__,r28
/* prologue: function */
/* frame size = 12 */
/* stack size = 14 */
.L__stack_usage = 14
std Y+8,r25 ;  2*movhi/3[length = 2]
std Y+7,r24
std Y+10,r23 ;  3*movhi/3[length = 2]
std Y+9,r22
std Y+12,r21 ;  4*movhi/3[length = 2]
std Y+11,r20
movw r24,r28 ;  38*movhi/1[length = 1]
adiw r24,7 ;  9*addhi3/2[length = 1]
std Y+2,r25 ;  10*movhi/3[length = 2]
std Y+1,r24
movw r24,r28 ;  39*movhi/1[length = 1]
adiw r24,9 ;  11*addhi3/2[length = 1]
std Y+4,r25 ;  12*movhi/3[length = 2]
std Y+3,r24
movw r24,r28 ;  40*movhi/1[length = 1]
adiw r24,11 ;  13*addhi3/2[length = 1]
std Y+6,r25 ;  14*movhi/3[length = 2]
std Y+5,r24
lsl r18 ;  53*ashlhi3_const/2[length = 2]
rol r19
add r18,r28 ;  16*addhi3/1[length = 2]
adc r19,r29
movw r26,r18 ;  41*movhi/1[length = 1]
adiw r26,3 ;  18*movhi/2[length = 4]
ld r30,X+
ld r31,X
sbiw r26,3+1
ld r24,Z ;  35*movqi/4[length = 1]
ldd r25,Z+1 ;  36*movqi/4[length = 1]
/* epilogue start */
adiw r28,12 ;  48*addhi3/2[length = 1]
in __tmp_reg__,__SREG__ ;  49*movhi_sp/1[length = 5]
cli
out __SP_H__,r29
out __SREG__,__tmp_reg__
out __SP_L__,r28
pop r28 ;  50pophi[length = 2]
pop r29
ret ;  51return_from_epilogue[length = 1]

[Bug middle-end/50061] [4.7 regression] emit_library_call_value_1 change broke SF->TI conversion on MIPS

[rsandifo at gcc dot gnu.org]

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

rsand...@gcc.gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-08/msg00735.htm
   ||l
   Last reconfirmed||2011-08-12
 CC|rdsandiford at googlemail   |rsandifo at gcc dot gnu.org
   |dot com |
 AssignedTo|unassigned at gcc dot   |rsandifo at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from rsandifo at gcc dot gnu.org  
2011-08-12 20:26:35 UTC ---
Note that I posted a patch for this last weekend:

http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00735.html

However, Julian's on holiday at the moment, and I'm not set up
to test big-endian ARM myself.  Probably best to apply the patch
to your local tree (or revert Julian's in your local tree)
until he gets back.

[Bug target/50063] [avr]: wrong code for gcc.dg/torture/pta-ptrarith-3.c

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011-08-12
   Target Milestone|--- |4.6.2
 Ever Confirmed|0   |1

--- Comment #1 from Georg-Johann Lay  2011-08-12 
20:33:32 UTC ---
Setting status to NEW, see gcc-testresults:

4.7.0 20110810 (experimental)
   http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg01258.html

4.6.2 20110805 (prerelease)
   http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00698.html

[Bug bootstrap/50064] New: Failure in stage 2 (lazy binding) on openbsd

[julien at trigofacile dot com]

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

 Bug #: 50064
   Summary: Failure in stage 2 (lazy binding) on openbsd
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jul...@trigofacile.com


Hi,

I am trying to bootstrap GCC 4.6.1 on OpenBSD 4.6 GENERIC#43 sparc64 (it is in
fact gcc64 in the GCC Compile Farm ).
/usr/bin/uname -p = SUNW,UltraSPARC-IIIi (rev 2.4) @ 1002 MHz

Build is initially done with GCC 3.3.5.

Configure flags:
./configure --prefix=/home/iulius/autobuild/bin/gcc-core-4.6.1
--with-gmp=/home/iulius/autobuild/bin/gmp-4.3.2
--with-mpfr=/home/iulius/autobuild/bin/mpfr-2.4.2
--with-mpc=/home/iulius/autobuild/bin/mpc-0.8.1






Checking multilib configuration for libgcc...
Configuring stage 2 in sparc64-unknown-openbsd4.6/libgcc
configure: loading cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... nawk
checking build system type... sparc64-unknown-openbsd4.6
checking host system type... sparc64-unknown-openbsd4.6
checking for sparc64-unknown-openbsd4.6-ar... ar
checking for sparc64-unknown-openbsd4.6-lipo... lipo
checking for sparc64-unknown-openbsd4.6-nm...
/home/iulius/autobuild/src/gcc-core-4.6.1/host-sparc64-unknown-openbsd4.6/gcc/nm
checking for sparc64-unknown-openbsd4.6-ranlib... ranlib
checking for sparc64-unknown-openbsd4.6-strip... strip
checking whether ln -s works... yes
checking for sparc64-unknown-openbsd4.6-gcc...
/home/iulius/autobuild/src/gcc-core-4.6.1/host-sparc64-unknown-openbsd4.6/gcc/xgcc
-B/home/iulius/autobuild/src/gcc-core-4.6.1/host-sparc64-unknown-openbsd4.6/gcc/
-B/home/iulius/autobuild/bin/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/bin/
-B/home/iulius/autobuild/bin/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/lib/
-isystem
/home/iulius/autobuild/bin/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/include
-isystem
/home/iulius/autobuild/bin/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/sys-include
 
checking for suffix of object files... configure: error: in
`/home/iulius/autobuild/src/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
gmake[2]: *** [configure-stage2-target-libgcc] Error 1


config.log ->

/home/iulius/autobuild/src/gcc-core-4.6.1/libgcc/configure
--cache-file=./config.cache --enable-multilib
--prefix=/home/iulius/autobuild/bin/gcc-core-4.6.1
--with-gmp=/home/iulius/autobuild/bin/gmp-4.3.2
--with-mpfr=/home/iulius/autobuild/bin/mpfr-2.4.2
--with-mpc=/home/iulius/autobuild/bin/mpc-0.8.1 --enable-languages=c,lto
--program-transform-name=s,y,y, --disable-option-checking
--with-target-subdir=sparc64-unknown-openbsd4.6
--build=sparc64-unknown-openbsd4.6 --host=sparc64-unknown-openbsd4.6
--target=sparc64-unknown-openbsd4.6 --srcdir=../.././libgcc
--with-build-libsubdir=host-sparc64-unknown-openbsd4.6



configure:3055:
/home/iulius/autobuild/src/gcc-core-4.6.1/host-sparc64-unknown-openbsd4.6/gcc/xgcc
-B/home/iulius/autobuild/src/gcc-core-4.6.1/host-sparc64-unknown-openbsd4.6/gcc/
-B/home/iulius/autobuild/bin/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/bin/
-B/home/iulius/autobuild/bin/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/lib/
-isystem
/home/iulius/autobuild/bin/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/include
-isystem
/home/iulius/autobuild/bin/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/sys-include
   -o conftest -g -O2   conftest.c  >&5
/home/iulius/autobuild/src/gcc-core-4.6.1/host-sparc64-unknown-openbsd4.6/gcc/cc1:/home/iulius/autobuild/src/gcc-core-4.6
.1/host-sparc64-unknown-openbsd4.6/gcc/cc1: undefined symbol ''
lazy binding failed!
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:3058: $? = 1
configure:3246: checking for suffix of object files
configure:3268:
/home/iulius/autobuild/src/gcc-core-4.6.1/host-sparc64-unknown-openbsd4.6/gcc/xgcc
-B/home/iulius/autobuild/src/gcc-core-4.6.1/host-sparc64-unknown-openbsd4.6/gcc/
-B/home/iulius/autobuild/bin/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/bin/
-B/home/iulius/autobuild/bin/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/lib/
-isystem
/home/iulius/autobuild/bin/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/include
-isystem
/home/iulius/autobuild/bin/gcc-core-4.6.1/sparc64-unknown-openbsd4.6/sys-include
   -c -g -O2  conftest.c >&5
/home/iulius/autobuild/src/gcc-core-4.6.1/host-sparc64-unknown-openbsd4.6/gcc/cc1:/home/iulius/autobuild/src/gcc-core-4.6
.1/host-sparc64-unknown-openbsd4.6/gcc/cc1: undefined symbol ''
lazy binding failed!
cc1: internal compiler error: Segmentation fault
Please submit a full bu

[Bug rtl-optimization/49994] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2234 with -fsched2-use-superblocks

[rth at gcc dot gnu.org]

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

--- Comment #6 from Richard Henderson  2011-08-12 
21:00:17 UTC ---
Author: rth
Date: Fri Aug 12 21:00:00 2011
New Revision: 177721

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177721
Log:
PR rtl-opt/49994
* sched-init.h (struct deps_desc): Add sched_before_next_jump.
* sched-deps.c (init_deps): Clear it.
(deps_analyze_insn): Consume it.
(sched_analyze_insn): Fill it.

Added:
trunk/gcc/testsuite/gcc.dg/pr49994-1.c
trunk/gcc/testsuite/gcc.dg/pr49994-2.c
trunk/gcc/testsuite/gcc.dg/pr49994-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-deps.c
trunk/gcc/sched-int.h

[Bug rtl-optimization/49994] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2234 with -fsched2-use-superblocks

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Richard Henderson  2011-08-12 
21:04:32 UTC ---
Fixed.

[Bug middle-end/50060] intrinsics not folded by the middle-end

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  2011-08-12 
21:17:05 UTC ---
(In reply to comment #3)
> (It seems more a problem with my C++ test snippets in Comments #1 / #2: I
> suppose any definition of such functions isn't viable for constexpr, because
> the body has to assign the pointed integer additionally to returning a 
> value...
> If Jason could confirm it would be great)

Correct, the assignment makes it non-constant.

[Bug middle-end/50060] intrinsics not folded by the middle-end

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC|jason at gcc dot gnu.org|

--- Comment #5 from Paolo Carlini  2011-08-12 
21:19:23 UTC ---
Thanks Jason.

[Bug debug/50006] [4.7 Regression] ICE in in connect_traces, at dwarf2cfi.c:2677

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED

--- Comment #6 from Richard Henderson  2011-08-12 
21:21:54 UTC ---
Reproduced via cross-compiler...

[Bug c++/50034] [4.7 regression] Overload selection failure within class template

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  2011-08-12 
21:28:01 UTC ---
Author: jason
Date: Fri Aug 12 21:27:52 2011
New Revision: 177722

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177722
Log:
PR c++/50034
* call.c (convert_arg_to_ellipsis): force_rvalue only in
potentially evaluated context.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp0x/defaulted28.C

[Bug c/50065] New: -Os, -O2, -O3 optimization breaks LD/ST ordering on 32-bit SPARC

[tanzhangxi at gmail dot com]

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

 Bug #: 50065
   Summary: -Os, -O2, -O3 optimization breaks LD/ST ordering on
32-bit SPARC
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tanzhan...@gmail.com


Considering the following C code.

static inline int spinlock_trylock(char* lock)
{
int reg;
__asm__ __volatile__ ("ldstub [%1],%0" : "=r"(reg) : "r"(lock) : "memory",
"cc");
return reg;
}

static inline int spinlock_is_locked(char* lock)
{
int reg;
__asm__ __volatile__ ("ldub [%1],%0" : "=r"(reg) : "r"(lock) : "memory");
return reg;
}


static inline void spinlock_lock(char* lock)
{
while(spinlock_trylock(lock))
  while(spinlock_is_locked(lock));
}

static inline void spinlock_unlock(char* lock)
{
*(volatile unsigned char*)lock = 0;
}

char remap_lock;
int remap_barrier;

void inc_remap_barrier()
{

  spinlock_lock(&remap_lock);
  remap_barrier++;
  spinlock_unlock(&remap_lock);
}

A simple ++ counter is protected by a spinlock implemented with the ldstub
atomic instruction on SPARC.

If I use -Os/-O2/-O3 to optimize the code, e.g.
sparc-ramp-gcc -c -Os test.c -o test.o

gcc will generate the following code
 :
   0:   03 00 00 00 sethi  %hi(0), %g1
   4:   10 80 00 06 b  1c 
   8:   82 10 60 00 mov  %g1, %g1   ! 0 
   c:   c4 08 40 00 ldub  [ %g1 ], %g2
  10:   80 a0 a0 00 cmp  %g2, 0
  14:   12 bf ff fe bne  c 
  18:   01 00 00 00 nop 
  1c:   c4 68 40 00 ldstub  [ %g1 ], %g2
  20:   80 a0 a0 00 cmp  %g2, 0
  24:   12 bf ff fa bne  c 
  28:   05 00 00 00 sethi  %hi(0), %g2
  2c:   c0 28 40 00 clrb  [ %g1 ]
  30:   c6 00 a0 00 ld  [ %g2 ], %g3
  34:   86 00 e0 01 inc  %g3
  38:   81 c3 e0 08 retl 
  3c:   c6 20 a0 00 st  %g3, [ %g2 ]


instruction 2C, clrb [%g1] corresponds to inline function 'spinlock_unlock'
*(volatile unsigned char*)lock = 0;

This happens before the lock protected content 'remap_barrier++', i.e.

  30:   c6 00 a0 00 ld  [ %g2 ], %g3
  34:   86 00 e0 01 inc  %g3
  38:   81 c3 e0 08 retl 
  3c:   c6 20 a0 00 st  %g3, [ %g2 ] ---> use the branch delay slot

This is wrong and will cause serious lock issues under a multithreading
environment.

However, the same code works fine with -O1 and -O0

This problem happens with couple of cross GCC builds (4.3.2 / 4.6.1) at our
side with various configurations (with glibc or a bare metal setting).
It breaks with the following configurations:

1. 
COLLECT_GCC=sparc-ramp-gcc
COLLECT_LTO_WRAPPER=/home/charming/toolchain/sparc-ramp/libexec/gcc/sparc-ramp-elf/4.6.1/lto-wrapper
Target: sparc-ramp-elf
Configured with: /home/charming/toolchain/.build/src/gcc-4.6.1/configure
--build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu
--target=sparc-ramp-elf --prefix=/home/charming/toolchain/sparc-ramp
--with-local-prefix=/home/charming/toolchain/sparc-ramp/sparc-ramp-elf/sysroot
--disable-multilib --disable-libmudflap
--with-sysroot=/home/charming/toolchain/sparc-ramp/sparc-ramp-elf/sysroot
--with-newlib --enable-threads=no --disable-shared
--with-pkgversion='crosstool-NG 1.12.0' --disable-__cxa_atexit
--with-gmp=/home/charming/toolchain/.build/sparc-ramp-elf/build/static
--with-mpfr=/home/charming/toolchain/.build/sparc-ramp-elf/build/static
--with-mpc=/home/charming/toolchain/.build/sparc-ramp-elf/build/static
--with-ppl=/home/charming/toolchain/.build/sparc-ramp-elf/build/static
--with-cloog=/home/charming/toolchain/.build/sparc-ramp-elf/build/static
--with-libelf=/home/charming/toolchain/.build/sparc-ramp-elf/build/static
--enable-lto
--with-host-libstdcxx='-L/home/charming/toolchain/.build/sparc-ramp-elf/build/static/lib
-lpwl' --enable-target-optspace --disable-libgomp --disable-libmudflap
--disable-nls --enable-languages=c --with-cpu=v8
Thread model: single
gcc version 4.6.1 (crosstool-NG 1.12.0) 

2.
Using built-in specs.
COLLECT_GCC=sparc-ramp-gcc
COLLECT_LTO_WRAPPER=/home/xtan/toolchain/sparc-ramp/libexec/gcc/sparc-ramp-linux-gnu/4.6.1/lto-wrapper
Target: sparc-ramp-linux-gnu
Configured with: /home/xtan/toolchain/.build/src/gcc-4.6.1/configure
--build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu
--target=sparc-ramp-linux-gnu --prefix=/home/xtan/toolchain/sparc-ramp
--with-sysroot=/home/xtan/toolchain/sparc-ramp/sparc-ramp-linux-gnu/sysroot
--enable-languages=c,c++ --disable-multilib
--with-pkgversion=crosstool-NG-1.11.3 --enable-__cxa_atexit
--disable-libmudflap --disable-libgomp --disable-libssp
--with-gmp=/home/xtan/toolchain/.build/sparc-ramp-linux-gnu/build/static
--with-mpfr=/home/xtan/toolchain/.build/sparc-ramp-linux-gnu/build/static
--with-mpc=/home/xtan/toolchain/.build/sparc-ramp-linux-gnu/build/static
--with-ppl=/home/xtan/toolchain/.b

[Bug debug/50006] [4.7 Regression] ICE in in connect_traces, at dwarf2cfi.c:2677

[rth at gcc dot gnu.org]

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

--- Comment #7 from Richard Henderson  2011-08-12 
21:49:19 UTC ---
Created attachment 24993
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24993
proposed patch

This seems to fix the bug.  Doing an Ada sanity check on x86_64...

[Bug bootstrap/50010] i386-unknown-freebsd bootstrap comparison failure

[nenad at intrepid dot com]

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

--- Comment #3 from Nenad Vukicevic  2011-08-12 
22:03:03 UTC ---
I tried "/configure i586-linux" on my 32-bit machine and got the
following:

Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
libiberty/pic/simple-object-coff.o differs
libiberty/pic/cp-demangle.o differs
libiberty/pic/alloca.o differs
libiberty/pic/pex-common.o differs
libiberty/pic/argv.o differs
libiberty/pic/regex.o differs
libiberty/pic/crc32.o differs
libiberty/pic/hashtab.o differs
libiberty/pic/fdmatch.o differs
libiberty/pic/floatformat.o differs
libiberty/pic/cplus-dem.o differs
lto-plugin/.libs/lto-plugin.o differs

[Bug target/49903] [avr] Redundant comparisons in binary-search switch/case expansion

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #5 from Hans-Peter Nilsson  2011-08-12 
22:54:27 UTC ---
I'd guess you're just looking at a NOTICE_UPDATE_CC bug in the AVR port.

[Bug middle-end/50066] New: [4.7 Regression] Bad signed long to unsigned long long conversion

[hjl.tools at gmail dot com]

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

 Bug #: 50066
   Summary: [4.7 Regression] Bad signed long to unsigned long long
conversion
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/ia32, I got

[hjl@gnu-6 gmp-1]$ cat x.c
#include 
#include 
#include 

extern unsigned long long foo (long);

int
main ()
{
  unsigned long long val = foo (LONG_MIN);
  printf ("0x%llx\n", val);
  if (val != 0x8000)
abort ();
  return 0;
}
[hjl@gnu-6 gmp-1]$ cat foo.c
unsigned long long
foo (signed long int val)
{
  return (unsigned long long) (unsigned long int) (val >= 0 ? val : -val);
}
[hjl@gnu-6 gmp-1]$ make 
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -m32 -O2   -c -o foo.o foo.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -m32 -O2   -c -o x.o x.c
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -m32 -O2 -o x foo.o x.o
./x
0x8000
make: *** [all] Aborted (core dumped)
[hjl@gnu-6 gmp-1]$

[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
Summary|[4.7 Regression] Bad signed |[4.7 Regression] Bad signed
   |long to unsigned long long  |int to unsigned long long
   |conversion  |conversion

--- Comment #1 from H.J. Lu  2011-08-12 23:45:55 
UTC ---
It may be caused by revision 176154:

http://gcc.gnu.org/ml/gcc-cvs/2011-07/msg00419.html

When replacing long with int, LONG_MIN with INT_MIN,
the testcase also fails on Linux/x86-64.

[Bug tree-optimization/50067] New: Wrong code with -fpredictive-commoning

[arthur.j.odwyer at gmail dot com]

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

 Bug #: 50067
   Summary: Wrong code with -fpredictive-commoning
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com


Created attachment 24994
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24994
Output of "ajo-gcc -std=c99 -O -fpredictive-commoning test.c -v"

This failure reproduces for me with svn revision 177688 (2011-08-11). I'm on
Ubuntu 10.10, x86-64.


cat >test.c <
int a[6] = {0, 0, 0, 0, 7, 0};
static int *p = &a[4];
int main (int argc, char* argv[]) {
for (int i=0; i < 4; ++i) {
a[i+1] = (a[i+2] > i);
*p &= ~1;
}
printf("%d\n", a[4]);
}
EOF
gcc -std=c99 -O test.c ; ./a.out
gcc -std=c99 -O -fpredictive-commoning test.c ; ./a.out


The first command line above correctly produces "0".
The second command line, with -fpredictive-commoning, produces "6".
Note that -fpredictive-commoning is enabled as part of -O3.


This test case is reduced from the output of Csmith 2.1.0 (git hash 01aa8b04,
https://github.com/Quuxplusone/csmith/), using the following command line:
csmith --paranoid --no-longlong --pointers --arrays --jumps --no-consts
--volatiles --checksum --no-divs --muls --no-bitfields --no-packed-struct -s
278348999

[Bug c++/50034] [4.7 regression] Overload selection failure within class template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Depends on||49102
 Resolution||FIXED

--- Comment #3 from Jason Merrill  2011-08-13 
00:00:39 UTC ---
Fixed.

[Bug rtl-optimization/50068] New: Invalid memory access in incr_ticks_for_insn

[uwe at netbsd dot org]

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

 Bug #: 50068
   Summary: Invalid memory access in incr_ticks_for_insn
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: u...@netbsd.org


I'm not sure about a good short description for this, so please bear with me.

NetBSD is currently in a process of switching to gcc-4.5.3 as its system
compiler.  I have built a NetBSD release with the new gcc and, as a test, I
decided to build NetBSD/landisk (SuperH) on a landisk machine itself (with the
newly compiled system) to verify bootstrap/self-hosting.  While it takes
several days, it's an interesting exercise and last time I did it I actually
found a sequence point bug in out lint...  But I digressed.

The build failed with:

#   compile  libstdc++-v3/fstream-inst.o
/usr/nb/tools/bin/shle--netbsdelf-c++ -frandom-seed=4cd80fc7 -Os
-freorder-blocks -Werror -fno-implicit-templates
-fdiagnostics-show-location=once  --sysroot=/usr/nb/distrib/landisk
-I/usr/src/external/gpl3/gcc/dist/gcc -I/usr/src/external/gpl3/gcc/dist/include
-I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/libsupc++
-I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/../libstdc++-v3_4/arch/sh3el -I.
-DHAVE_STDLIB_H -DHAVE_STRING_H
-I/usr/src/external/gpl3/gcc/dist/libstdc++-v3/include
-I/usr/src/external/gpl3/gcc/lib/libstdc++-v3/arch/sh3el  -c
-Wno-stack-protector  -std=gnu++0x
/usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/fstream-inst.cc -o
fstream-inst.o
/usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/fstream-inst.cc: In member
function 'void
std::basic_fstream::_ZTv0_n12_NSt13basic_fstreamIcSt11char_traitsIcEED1Ev()':
/usr/src/external/gpl3/gcc/dist/libstdc++-v3/src/fstream-inst.cc:46:1: internal
compiler error: Bus error

That SIGBUS happens in incr_ticks_for_insn at resource.c:1275 doing

  bb_ticks[b]++;

and bb_ticks is an address aligned as x*4+2.  Since it's not properly aligned
for int*, there's SIGBUS triggered.

bb_ticks is allocated at resource.c:1201 as:

  bb_ticks = XCNEWVEC (int, last_basic_block);

and for the faulty allocation the last_basic_block is 0.  Now, xcalloc in
libiberty checks that

  if (nelem == 0 || elsize == 0)
nelem = elsize = 1;

and so it ends up with calloc(1, 1).  NetBSD's jemalloc rounds allocation
size=1 up to 2 and allocates memory at x*4+2 that IS properly aligned for
size=2, but IS NOT properly aligned for int *bb_ticks.   Since SuperH is strict
about alignment, eventual invalid access in incr_ticks_for_insn causes SIGBUS
and exposes the bug.

The compiler under investigation in the above was build on SuperH to run on
SuperH targeting SuperH.

To verify this bug I did a cross-build of NetBSD/landisk on an amd64 RedHat
machine.  Then I manually ran the command that failed in my landisk build using
valgrind.  So in this verification I used compiler built on amd64, running on
amd64 targeting SuperH.  Valgrind complained about:

==12675== Invalid read of size 4
==12675==at 0x743398: incr_ticks_for_insn (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x741636: fill_simple_delay_slots (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x741FA9: dbr_schedule (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x8D9BC7: sh_output_mi_thunk (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x8DF98E: cgraph_expand_function (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x8E11A4: cgraph_optimize (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x8E1A54: cgraph_finalize_compilation_unit (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x4D2BF4: cp_write_global_declarations (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x78D905: do_compile (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x78E04D: toplev_main (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x35C801D973: (below main) (in /lib64/libc-2.5.so)
==12675==  Address 0x4f22524 is 3 bytes after a block of size 1 alloc'd
==12675==at 0x4A0516B: calloc (vg_replace_malloc.c:418)
==12675==by 0xA2C628: xcalloc (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x74412B: init_resource_info (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x741F62: dbr_schedule (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x8D9BC7: sh_output_mi_thunk (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3/cc1plus)
==12675==by 0x8DF98E: cgraph_expand_function (in
netbsd/tools/libexec/gcc/shle--netbsdelf/4.5.3a/cc1plus)
==12675==by 0x8E11A4: cgraph_optimize (in
netbsd/tools/libexec/gcc/shle-

[Bug rtl-optimization/50068] Invalid memory access in incr_ticks_for_insn

[uwe at netbsd dot org]

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

--- Comment #1 from Valeriy E. Ushakov  2011-08-13 
01:18:00 UTC ---
Created attachment 24995
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24995
Preprocessed source that triggers the bug

[Bug debug/50006] [4.7 Regression] ICE in in connect_traces, at dwarf2cfi.c:2677

[dave.anglin at bell dot net]

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

--- Comment #8 from dave.anglin at bell dot net 2011-08-13 01:19:35 UTC ---
On 12-Aug-11, at 5:49 PM, rth at gcc dot gnu.org wrote:
>  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24993
> proposed patch


Testing on hppa2.0w-hp-hpux11.00.  Will test on hppa2.0w-hp-hpux11.11  
tomorrow
after current build completes.

Thanks,
Dave
--
John David Anglindave.ang...@bell.net

[Bug rtl-optimization/50068] Invalid memory access in incr_ticks_for_insn

[uwe at netbsd dot org]

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

--- Comment #2 from Valeriy E. Ushakov  2011-08-13 
01:27:57 UTC ---
The command that fails:

.../libexec/gcc/shle--netbsdelf/4.5.3/cc1plus -fpreprocessed fstream-inst.i
-quiet -dumpbase fstream-inst.i -auxbase-strip fstream-inst.o -Os -Werror
-Wno-stack-protector -std=gnu++0x -frandom-seed=4cd80fc7 -freorder-blocks
-fno-implicit-templates -fdiagnostics-show-location=once -o /tmp/cc83k8TV.s

[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)

[jimis at gmx dot net]

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

--- Comment #2 from jimis  2011-08-13 01:37:14 UTC ---
Created attachment 24996
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24996
Make cse.c:preferable() more readable, slightly faster, without affecting its
logic.

2011-08-13  Dimitrios Apostolou  

* cse.c (preferable): Make it more readable and slightly faster,
without affecting its logic.

[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)

[jimis at gmx dot net]

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

jimis  changed:

   What|Removed |Added

 CC||jimis at gmx dot net

--- Comment #3 from jimis  2011-08-13 01:39:23 UTC ---
I think that the logic in this function is expressed in complicated manner. It
took me some time to figure out what happens in various corner cases. The
attached patch I think makes the code more readable/maintainable, hopefully it
doesn't affect the function's logic at all. Runtime measured unaffected, if not
a couple milliseconds faster. Bootstrapped and tested on x86_64.

Thanks to Cristophe for pointing me here.

[Bug rtl-optimization/50065] -Os, -O2, -O3 optimization breaks LD/ST ordering on 32-bit SPARC

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  2011-08-13 
02:21:05 UTC ---
I fixed a volatile bug dealing with inlining and ipa-sra.  Maybe this was fixed
by that too.

[Bug middle-end/50066] [4.7 Regression] Bad signed int to unsigned long long conversion

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2011-08-13 
04:32:16 UTC ---
- LONG_MIN is undefined.