[Bug fortran/44489] Transfer with boz constant can confuse - add documentation
--- Comment #4 from kargl at gcc dot gnu dot org 2010-06-10 06:31 --- (In reply to comment #3) > The result of transfer is largest kind of decimal. Can be kind=8 or kind=16 > depending on the system. Maybe we should add some documentation in the manual > on this. Thanks Steve for pointing this out. > Well, to be more exact, the result of transfer() has the type of its 2nd argument. In transfer(ii8,z'1000'), the BOZ may have a kind type parameter of 8 or 16 depending on the target; while the INTEGER(4) ii8 can only supply 32 bits. Note, the documentation for transfer() already describes this situation without explicitly mentioning BOZ literal constants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44489
[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom
--- Comment #10 from ubizjak at gmail dot com 2010-06-10 06:18 ---
(In reply to comment #9)
> > Following patch is also needed to fix conditional splitting (it does not fix
> > original uncovered problem where BLOCK_FOR_INSN returns null):
>
> I am not sure this is correct. The code prior to revision 160394 was
> written in such a way to support X86_TUNE_OPT_AGU. We may have missed
> some cases. But it is mostly correct. I'd like to know what specific
> cases revision 160394 tried to fix. Thanks.
The patch fixes general problem, where we simply output lea from add{si,di}
instruction. This is not correct, since lea does not clobber flags, so we
should split add RTX to lea RTX to model this fact.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
[Bug objc/44488] objc test inconsistencies w/ / w/out --enable-build-with-cxx
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-10 05:41 --- I see the same problem now with revision 160389. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
[Bug target/44490] X86 memory mismatch stall
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-10 05:23 --- This patch --- iff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md index a33d3af..6f569cc 100644 --- a/gcc/config/i386/predicates.md +++ b/gcc/config/i386/predicates.md @@ -820,7 +820,10 @@ /* All patterns using aligned_operand on memory operands ends up in promoting memory operand to 64bit and thus causing memory mismatch. */ - if (TARGET_MEMORY_MISMATCH_STALL && !optimize_insn_for_size_p ()) + if (TARGET_MEMORY_MISMATCH_STALL + && !optimize_insn_for_size_p () + && (!MEM_EXPR (op) + || TREE_CODE (MEM_EXPR (op)) != PARM_DECL)) return 0; /* Don't even try to do any aligned optimizations with volatiles. */ helps. I got .file "call-1.c" .text .p2align 4,,15 .globl foo .type foo, @function foo: pushl %ebp movl%esp, %ebp movl12(%ebp), %eax addl8(%ebp), %eax addl16(%ebp), %eax popl%ebp ret .size foo, .-foo .p2align 4,,15 .globl bar .type bar, @function bar: pushl %ebp movl%esp, %ebp movswl 12(%ebp), %eax << still read 2 bytes. movswl 16(%ebp), %edx movswl 8(%ebp), %ecx movl%edx, 12(%ebp) movl%ecx, 16(%ebp) movl%eax, 8(%ebp) popl%ebp jmp foo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44490
[Bug fortran/44489] Transfer with boz constant can confuse - add documentation
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-06-10 05:21 --- The result of transfer is largest kind of decimal. Can be kind=8 or kind=16 depending on the system. Maybe we should add some documentation in the manual on this. Thanks Steve for pointing this out. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|Transfer with boz constant |Transfer with boz constant |gives wrong results |can confuse - add ||documentation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44489
[Bug target/44490] New: X86 memory mismatch stall
Since x86 zero extends when passing argument,
we get memory mismatch stall:
[...@gnu-6 899]$ cat call-1.c
short
__attribute__((noinline))
foo (short x, short y, short z)
{
return x + y + z;
}
short
bar (short z, short x, short y)
{
return foo (x, y, z);
}
[...@gnu-6 899]$ gcc -O2 -m32 call-1.c -S
[...@gnu-6 899]$ cat call-1.s
.file "call-1.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
pushl %ebp
movl%esp, %ebp
movzwl 12(%ebp), %eax << 2bytes
addw8(%ebp), %ax
addw16(%ebp), %ax
popl%ebp
ret
.size foo, .-foo
.p2align 4,,15
.globl bar
.type bar, @function
bar:
pushl %ebp
movl%esp, %ebp
movswl 12(%ebp), %eax
movswl 16(%ebp), %edx
movswl 8(%ebp), %ecx
movl%eax, 8(%ebp) << 4bytes
movl%edx, 12(%ebp)
movl%ecx, 16(%ebp)
popl%ebp
jmp foo
--
Summary: X86 memory mismatch stall
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44490
[Bug fortran/44489] Transfer with boz constant gives wrong results
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-06-10 04:37 --- Interesting! print *, "kind=", kind(transfer(ii4,z'1000')) On my system this gives kind = 8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44489
[Bug fortran/44489] Transfer with boz constant gives wrong results
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-10 04:24 --- This is probably a bogus PR. The BOZ literal constants are INTEGER(16) entities (at least of x86_64). ii8 is an INTEGER(4) item. The transfer() in the print statement is returning a INTEGER(16) entity where only INTEGER(4) worth of bits are set. I've removed the 'wrong-code' keyword, because I think you are getting processor dependent behavior. In fact, the program might be nonconforming, but I'd need to read up on transfer(). -- kargl at gcc dot gnu dot org changed: What|Removed |Added Keywords|wrong-code | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44489
[Bug libstdc++/44487] pair of references doesn't work in c++0x mode
--- Comment #4 from jason at gcc dot gnu dot org 2010-06-10 03:28 --- Created an attachment (id=20881) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20881&action=view) patch This patch fixes it for me. I'm not entirely sure this is a proper use of forward, but it seems appropriate. Want to raise this issue with the library WG? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44487
[Bug c++/44486] [4.3/4.4/4.5/4.6 regression] missing space in __PRETTY_FUNCTION__ expansion in anonymous namespace
--- Comment #2 from bangerth at gmail dot com 2010-06-10 03:27 ---
This is a regression:
2.95: struct S {anonymous}::f()
3.4: S ::f()
4.0: S::f()
W.
--
bangerth at gmail dot com changed:
What|Removed |Added
CC||bangerth at gmail dot com
Known to fail||4.0.4 4.5.0
Known to work||3.4.6
Summary|missing space in|[4.3/4.4/4.5/4.6 regression]
|__PRETTY_FUNCTION__ |missing space in
|expansion in anonymous |__PRETTY_FUNCTION__
|namespace |expansion in anonymous
||namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44486
[Bug fortran/44489] New: Transfer with boz constant gives wrong results
This one was posted at gfortran.org program f90_test implicit none integer :: ii8,ii4 ii4=0 ii8=522405223 print'(z4)',ii4 print'(z12)',ii8 print *, "z=", z'1000' print *, transfer(ii8,z'1000') print *, transfer(ii8,z'1000') ii4=30292 !=z'7654' print'(z4)',ii4 print'(z12)',ii8 end program f90_test Repeated execution gives changing results for line 9. I have not investigated further yet. $ ./a.out 0 1F234567 z=268435456 60197368789943655 522405223 7654 1F234567 $ ./a.out 0 1F234567 z=268435456 61446413999097191 522405223 7654 1F234567 $ ./a.out 0 1F234567 z=268435456 61358453068875111 522405223 7654 1F234567 Jerry -- Summary: Transfer with boz constant gives wrong results Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44489
[Bug fortran/44207] ICE with ALLOCATABLE components and SOURCE
-- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-05-20 09:36:07 |2010-06-10 01:23:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44207
[Bug libstdc++/44487] pair of references doesn't work in c++0x mode
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-10 01:07 --- The constructor at issue is trivially conforming to the most recent specs (n3092) (*), thus, in my opinion, either this is a compiler issue, or a defect in c++0x or a feature in c++0x itself, can't be a library implementation issue. I'm adding Jason in CC just in case, for the variant with const, in particular, which admittedly seems a bit weird. (*) To be picky, pair(pair&& p) has been lately removed because redundant with the templatized one template pair(pair&& p). I double checked that with or without nothing changes, the error is the same. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44487
[Bug objc/44488] objc test inconsistencies w/ / w/out --enable-build-with-cxx
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-10 01:06 --- On x86_64-linux-gnu it does the correct thing: Executing on host: /home/pinskia/src/local/gcc/objdir/gcc/xgcc -B/home/pinskia/src/local/gcc/objdir/gcc/ /home/pinskia/src/local/gcc/gcc/testsuite/objc/compile/trivial.m -fgnu-runtime -I/home/pinskia/src/local/gcc/gcc/testsuite/../../libobjc -B/home/pinskia/src/local/gcc/objdir/x86_64-unknown-linux-gnu/./libobjc/.libs -L/home/pinskia/src/local/gcc/objdir/x86_64-unknown-linux-gnu/./libobjc/.libs -S -o trivial.s(timeout = 300) set_ld_library_path_env_vars: ld_library_path=.::/home/pinskia/src/local/gcc/objdir/gcc:/home/pinskia/src/local/gcc/objdir/x86_64-unknown-linux-gnu/./libobjc/.libs Executing on host: /home/pinskia/src/local/gcc/objdir/gcc/xgcc -B/home/pinskia/src/local/gcc/objdir/gcc/ /home/pinskia/src/local/gcc/gcc/testsuite/objc/compile/trivial.m -fnext-runtime -B/home/pinskia/src/local/gcc/objdir/x86_64-unknown-linux-gnu/./libobjc/.libs -L/home/pinskia/src/local/gcc/objdir/x86_64-unknown-linux-gnu/./libobjc/.libs -S -o trivial.s(timeout = 300) In file included from /home/pinskia/src/local/gcc/gcc/testsuite/objc/compile/trivial.m:1:0:^M /home/pinskia/src/local/gcc/gcc/testsuite/objc/compile/../../objc-obj-c++-shared/Object1.h:39:30: fatal error: objc/objc-runtime.h: No such file or directory^M compilation terminated.^M compiler exited with status 1 output is: In file included from /home/pinskia/src/local/gcc/gcc/testsuite/objc/compile/trivial.m:1:0:^M /home/pinskia/src/local/gcc/gcc/testsuite/objc/compile/../../objc-obj-c++-shared/Object1.h:39:30: fatal error: objc/objc-runtime.h: No such file or directory^M compilation terminated.^M Using the following runtimes: -fgnu-runtime This is without --enable-build-with-cxx . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
[Bug objc/44488] objc test inconsistencies w/ / w/out --enable-build-with-cxx
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-10 01:04 --- -fnext-runtime should fail on x86-linux-gnu anyways. Why it is not failing is a good question. If this is failing without --enable-build-with-cxx there is a bug somewhere. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|44433 | nThis|| Component|testsuite |objc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
[Bug testsuite/44488] New: objc test inconsistencies w/ / w/out --enable-build-with-cxx
Sometime between revision 160389 and revision 160448, testsuite/objc/compile/compile.exp started to use a new set of options for overy test in testsuite/objc/compile/compile.exp, using -fnext-runtime instead of -fgnu-runtime, thus adding 5 tests * 6 option compinations, i.e. 30 new expected passes to the test results, for a default configuration bootstrap/regtest on i686-pc-linux-gnu. This is still the case at revision 160461. Running a bootstrap/regtest on i686-pc-linux-gnu with the configure option --enable-build-with-cxx, I do not see these new test variants, and thus 30 fewer expected passes. With the old trunk, or with the new trunk configured with --enable-build-with-cxx, I see there is a test of -fnext-runtime at the start of running compile.exp, which fails: Executing on host: /user/inria/fsf/bldxx-20100607/gcc/xgcc -B/user/inria/fsf/bldxx-20100607/gcc/ /user/inria/fsf/gcc/gcc/testsuite/objc/compile/trivial.m -fnext-runtime -B/user/inria/fsf/bldxx-20100607/i686-pc-linux-gnu/./libobjc/.libs -L/user/inria/fsf/bldxx-20100607/i686-pc-linux-gnu/./libobjc/.libs -S -o trivial.s(timeout = 300) In file included from /user/inria/fsf/gcc/gcc/testsuite/objc/compile/trivial.m:1:0: /user/inria/fsf/gcc/gcc/testsuite/objc/compile/../../objc-obj-c++-shared/Object1.h:21:31: fatal error: objc/Object.h: No such file or directory compilation terminated. compiler exited with status 1 output is: In file included from /user/inria/fsf/gcc/gcc/testsuite/objc/compile/trivial.m:1:0: /user/inria/fsf/gcc/gcc/testsuite/objc/compile/../../objc-obj-c++-shared/Object1.h:21:31: fatal error: objc/Object.h: No such file or directory compilation terminated. Using the following runtimes: -fgnu-runtime With the new trunk configured without --enable-build-with-cxx, this test appears to succeed: Executing on host: /user/inria/fsf/bld-20100609/gcc/xgcc -B/user/inria/fsf/bld-20100609/gcc/ /user/inria/fsf/gcc/gcc/testsuite/objc/compile/trivial.m -fnext-runtime -B/user/inria/fsf/bld-20100609/i686-pc-linux-gnu/./libobjc/.libs -L/user/inria/fsf/bld-20100609/i686-pc-linux-gnu/./libobjc/.libs -S -o trivial.s(timeout = 300) Using the following runtimes: -fgnu-runtime -fnext-runtime -- Summary: objc test inconsistencies w/ / w/out --enable-build- with-cxx Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu OtherBugsDependingO 44433 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44488
[Bug libstdc++/44487] pair of references doesn't work in c++0x mode
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-10 00:48 --- What I mean is that the C++ front-end is correct to reject the code that libstdc++ provides to it. If there is a bug it is a problem with libstdc++ (or maybe even the in flux C++0x STL :) ). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44487
[Bug libstdc++/44487] pair of references doesn't work in c++0x mode
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-10 00:43 --- I think this is because C++0x introduces rvalue references and those cannot bind to lvalues. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44487
[Bug c++/44487] New: pair of references doesn't work in c++0x mode
This program doesn't compile with g++-4.5 -std=c++0x -c test.cpp
I'm using:
g++-4.5 (Debian 4.5.0-5) 4.5.1 20100602 (prerelease)
I also verified the same behavior on:
g++ (Debian 20100530-1) 4.6.0 20100530 (experimental) [trunk revision 160047]
#include
int x, y;
std::pair foo() {
std::pair blah(x, y);
return blah;
}
It says:
In file included from /usr/include/c++/4.5/utility:71:0,
from /tmp/test.cpp:1:
/usr/include/c++/4.5/bits/stl_pair.h: In constructor std::pair<_T1,
_T2>::pair(std::pair<_T1, _T2>&&) [with _T1 = int&, _T2 = int&, std::pair<_T1,
_T2> = std::pair]:
/tmp/test.cpp:8:12: instantiated from here
/usr/include/c++/4.5/bits/stl_pair.h:113:30: error: invalid initialization of
non-const reference of type int& from an rvalue of type
std::remove_reference::type
/usr/include/c++/4.5/bits/stl_pair.h:113:30: error: invalid initialization of
non-const reference of type int& from an rvalue of type
std::remove_reference::type
It works without -std=c++0x, and it seems like that ought to work in c++0x too.
Furthermore, this slightly modified program, making "blah" const (which I think
shouldn't make a difference, as it's the outermost qualifier of a local
variable) causes it to successfully compile:
#include
int x, y;
std::pair foo() {
const std::pair blah(x, y);
return blah;
}
--
Summary: pair of references doesn't work in c++0x mode
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: foom at fuhm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44487
[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64
--- Comment #9 from paolo dot carlini at oracle dot com 2010-06-10 00:26 --- As far as we can see can't be substantively improved. See also the thread starting at: http://gcc.gnu.org/ml/libstdc++/2010-06/msg00073.html -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44413
[Bug tree-optimization/44483] [4.6 regression] gcc consumes all available memory when optimizing
--- Comment #4 from spop at gcc dot gnu dot org 2010-06-09 22:13 --- Mine. -- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|-00-00 00:00:00 |2010-06-09 22:13:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
[Bug fortran/38913] Fortran does not set TYPE_CANONICAL properly
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2010-06-09 22:11 --- (In reply to comment #16) > Re-confirmed with current trunk, testcase from (comment #8). I think it now passes. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38913
[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2010-06-09 22:10 --- Another one that fails: subroutine func (x) use demo integer :: x x = 999 end subroutine func subroutine foo interface subroutine func(x) integer :: x end subroutine func end interface integer :: x call func(x) if (x /= 999) call abort () end subroutine foo program test call foo end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40873
[Bug tree-optimization/44483] [4.6 regression] gcc consumes all available memory when optimizing
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-09 22:06 --- It is caused by revision 159886: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00942.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||spop at gcc dot gnu dot org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
[Bug c++/44486] missing space in __PRETTY_FUNCTION__ expansion in anonymous namespace
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-09 22:02 --- I'm VERY much in favour of using something that is not valid C++ syntax, rather than "" -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-09 22:02:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44486
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-09 22:02:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473
[Bug rtl-optimization/42461] [4.5/4.6 regression] missed optimization for pure functions
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-06-09 21:50 --- Subject: Bug 42461 Author: ebotcazou Date: Wed Jun 9 21:49:44 2010 New Revision: 160507 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160507 Log: PR rtl-optimization/42461 * dce.c (deletable_insn_p): Return true for const or pure calls again. * except.c (insn_could_throw_p): Return false if !flag_exceptions. Added: trunk/gcc/testsuite/gcc.dg/pr42461.c Modified: trunk/gcc/ChangeLog trunk/gcc/dce.c trunk/gcc/except.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42461
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-09 21:48 --- Oops, thanks Joseph. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|janis187 at us dot ibm dot | |com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473
[Bug c/44485] [4.6 Regression] ICE in get_expr_operands, at tree-ssa-operands.c:1020
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-09 21:40 --- It is caused by revision 160124: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00036.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-09 21:40:57 date|| Summary|ICE in get_expr_operands, at|[4.6 Regression] ICE in |tree-ssa-operands.c:1020|get_expr_operands, at tree- ||ssa-operands.c:1020 Target Milestone|--- |4.6.0 Version|unknown |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44485
[Bug fortran/44347] SELECT_REAL_KIND: Wrongly accepts non-scalar arguments
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-06-09 21:36 --- Subject: Bug 44347 Author: dfranke Date: Wed Jun 9 21:36:33 2010 New Revision: 160506 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160506 Log: gcc/fortran/: 2010-06-09 Daniel Franke PR fortran/44347 * check.c (gfc_check_selected_real_kind): Verify that the actual arguments are scalar. gcc/testsuite/: 2010-06-09 Daniel Franke PR fortran/44347 * gfortran.dg/selected_real_kind_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/selected_real_kind_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44347
[Bug c++/44486] New: missing space in __PRETTY_FUNCTION__ expansion in anonymous namespace
The "S::f()" text reads as though S were a template. I suspect the
text is simply missing a space between the S and but I wonder if
the bit could actually be replaced by something less ambiguous
in C++ (such as /* unnamed */ or perhaps better still, /* anonymous */).
Btw., since glibc uses __PRETTY_FUNCTION__ in its definition of the assert()
macro this shows up in quite a bit of output.
$ cat t.cpp && g++ -dumpversion && g++ t.cpp && ./a.out
#include
struct S { };
namespace { S f() { std::puts(__PRETTY_FUNCTION__); return S(); } }
int main() { f(); }
4.4.3
S::f()
--
Summary: missing space in __PRETTY_FUNCTION__ expansion in
anonymous namespace
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44486
[Bug fortran/44457] Missing ASYNCHRONOUS constraint check
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-06-09 21:19 ---
This should work (untested). However, ASYNCHRONOUS is F2003. Should one
introduce standard-specific checks? The whole function seems to be agnostic in
this respect?!
Index: interface.c
===
--- interface.c (revision 160504)
+++ interface.c (working copy)
@@ -2133,13 +2133,15 @@ compare_actual_formal (gfc_actual_arglis
if ((f->sym->attr.intent == INTENT_OUT
|| f->sym->attr.intent == INTENT_INOUT
- || f->sym->attr.volatile_)
+ || f->sym->attr.volatile_
+ || f->sym->attr.asynchronous)
&& has_vector_subscript (a->expr))
{
if (where)
- gfc_error ("Array-section actual argument with vector subscripts "
- "at %L is incompatible with INTENT(OUT), INTENT(INOUT) "
- "or VOLATILE attribute of the dummy argument '%s'",
+ gfc_error ("Array-section actual argument with vector "
+ "subscripts at %L is incompatible with INTENT(OUT), "
+ "INTENT(INOUT), VOLATILE or ASYNCHRONOUS attribute "
+ "of the dummy argument '%s'",
&a->expr->where, f->sym->name);
return 0;
}
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44457
[Bug fortran/44207] ICE with ALLOCATABLE components and SOURCE
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-09 21:17 ---
Here's a quick shot at fixing the ICE:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 160503)
+++ gcc/fortran/resolve.c (working copy)
@@ -6146,8 +6146,11 @@ gfc_expr_to_initialize (gfc_expr *e)
static gfc_try
conformable_arrays (gfc_expr *e1, gfc_expr *e2)
{
+ gfc_ref *tail;
+ for (tail = e2->ref; tail && tail->next; tail = tail->next);
+
/* First compare rank. */
- if (e2->ref && e1->rank != e2->ref->u.ar.as->rank)
+ if (tail && e1->rank != tail->u.ar.as->rank)
{
gfc_error ("Source-expr at %L must be scalar or have the "
"same rank as the allocate-object at %L",
It does work on the test case, but I haven't checked for regressions.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44207
[Bug c/44485] New: ICE in get_expr_operands, at tree-ssa-operands.c:1020
reg...@gamow tmp414]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r160490-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r160490-install
--program-prefix=r160490- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100609 (experimental) (GCC)
[reg...@gamow tmp414]$ current-gcc -c -O small.c
small.c: In function 'func_21':
small.c:42:22: warning: assignment makes integer from pointer without a cast
[enabled by default]
unhandled expression in get_expr_operands():
small.c: In function 'int324':
small.c:21:6: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:1020
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[reg...@gamow tmp414]$ cat small.c
static int
foo (int si1, int si2)
{
return si1 > 0 && si2 > 0 && si1 > -si2 || si1 < 0 && si2 < 0
&& si1 < -si2 ? : si1 + si2;
}
struct S0
{
unsigned short f1;
};
int g_4;
struct S0 g_54 = {
3428
};
int
func_21 (int * p_22, int * const int32p_24, unsigned p_25,
const int * p_26);
void int324 (unsigned p_15, int * p_16, int * p_17, int * p_18)
{
if (foo (g_4, func_21 (p_18, &g_4, 0, 0)))
{
for (g_54.f1; g_54.f1; g_54.f1 += 1)
{
}
}
}
int
func_21 (int * p_22, int * const int32p_24, unsigned p_25,
const int * p_26)
{
for (0; 1; p_25 += 1)
lbl_29:if (p_25)
goto lbl_28;
lbl_28:for (p_25 = 0; p_25 < 9; p_25 += 1)
if (p_25)
goto lbl_29;
unsigned short l_53;
for (0; l_53; l_53 = foo)
{
}
return 0;
}
--
Summary: ICE in get_expr_operands, at tree-ssa-operands.c:1020
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44485
[Bug fortran/44442] Useless temporary with RESHAPE
--- Comment #4 from dominiq at lps dot ens dot fr 2010-06-09 20:57 --- (In reply to comment #2) > This is a known limitation of array constructors handling by gfortran. I was about to ask if this pr is a duplicate. From comment #3, it is; so I am closing it as such. For the record the optimized dump (with 4.6) reads: ... atmp.6.dtype = 521; atmp.6.dim[0].stride = 1; atmp.6.dim[0].lbound = 0; atmp.6.dim[0].ubound = 1; atmp.6.data = &A.7; atmp.6.offset = 0; A.7[0] = 5; A.7[1] = 4; _gfortran_reshape_r4 (&parm.1, &parm.2, &atmp.6, 0B, 0B); ... So one temporary is removed with optimization. *** This bug has been marked as a duplicate of 33341 *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug fortran/33341] array temporaries for array constructors (unnecessary stores)
--- Comment #6 from dominiq at lps dot ens dot fr 2010-06-09 20:57 --- *** Bug 2 has been marked as a duplicate of this bug. *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33341
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #2 from joaquin at tid dot es 2010-06-09 20:34 --- Caching can also have undesired consequences: for additional context on the problem, see https://svn.boost.org/trac/boost/ticket/4264 Note that *two* problems are discussed there, one is LWG issue #579 and the other the one being addressed here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom
-- hjl dot tools at gmail dot com changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-09 20:30 --- (In reply to comment #6) > Following patch is also needed to fix conditional splitting (it does not fix > original uncovered problem where BLOCK_FOR_INSN returns null): > > I am not sure this is correct. The code prior to revision 160394 was written in such a way to support X86_TUNE_OPT_AGU. We may have missed some cases. But it is mostly correct. I'd like to know what specific cases revision 160394 tried to fix. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
[Bug rtl-optimization/44484] New: [4.6 regression] revision 160260 caused sparc64 testsuite failures
Between gcc-4.6-20100529 and gcc-4.6-20100605 a number of new testsuite FAILs appeared on sparc64-linux: === gfortran tests === FAIL: gfortran.fortran-torture/execute/forall_7.f90 execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops FAIL: gfortran.fortran-torture/execute/forall_7.f90 execution, -O3 -g === libgomp tests === FAIL: libgomp.c/nestedfn-3.c (test for excess errors) WARNING: libgomp.c/nestedfn-3.c compilation failed to produce executable FAIL: libgomp.c/nestedfn-4.c (test for excess errors) WARNING: libgomp.c/nestedfn-4.c compilation failed to produce executable FAIL: libgomp.c/task-2.c (test for excess errors) WARNING: libgomp.c/task-2.c compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -O1 (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -O1 compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -O2 (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -O2 compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer -funroll-loops compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -O3 -g (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -O3 -g compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -Os (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -Os compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -O1 (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -O1 compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -O2 (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -O2 compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer -funroll-loops compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -O3 -g (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -O3 -g compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -Os (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -Os compilation failed to produce executable I've traced this to r160260 (fix PR39871, PR40615, PR42500, PR42502). Some intermediate revisions cause bootstrap breakage making a bisection difficult, but reverting r160260 from gcc-4.6-20100605 eliminates the FAILs above. Although most FAILs are for Fortran, there are also three C-only libgomp tests that now FAIL. Compare also http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00316.html (r160217, libgomp) http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg02923.html (r160038, fortran and libgomp) with http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00454.html (r160287, libgomp) http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00590.html (r160330, fortran and libgomp) I'll check tomorrow if any of these are reproducible with a cross-compiler. -- Summary: [4.6 regression] revision 160260 caused sparc64 testsuite failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC build triplet: sparc64-unknown-linux-gnu GCC host triplet: sparc64-unknown-linux-gnu GCC target triplet: sparc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
[Bug target/44082] AVR watchdog resets the core during initialization
--- Comment #1 from eric dot weddington at atmel dot com 2010-06-09 20:21 --- This is not a bug. Please see the avr-libc documentation for here: http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html which gives the method to disable the watchdog. -- eric dot weddington at atmel dot com changed: What|Removed |Added CC||eric dot weddington at atmel ||dot com Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44082
[Bug target/43902] suboptimal MIPS widening multiply accumulate
--- Comment #9 from bernds at gcc dot gnu dot org 2010-06-09 20:20 --- Created an attachment (id=20880) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20880&action=view) A new version of Jim's patch Here's what I've done with it so far. I've changed the new tree code to be a proper gimple operation, which meant extending all sorts of gimple code to handle ternary operations. tree-ssa-math-opts runs late enough that I don't think we need to handle them in most passes, so I've turned some existing functions into wrappers that continue to present a two-operand interface. The other thing I've done is to restructure the pass a little to avoid the second loop over all the insns. I've changed the ARM backend to take advantage of it. Regression tests on ARM look fine (although I've had to change one of the testcases which didn't expect widen-macc to be generated). What do you think? Please let me know what your MIPS tests turned up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43902
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
--- Comment #5 from joseph at codesourcery dot com 2010-06-09 20:14 --- Subject: Re: iterators already defined for std::vector when using std::decimal On Wed, 9 Jun 2010, paolo dot carlini at oracle dot com wrote: > Janis, this doesn't make sense to me, and for sure happens only with decimal. > Can you have a look? > > > -- > > paolo dot carlini at oracle dot com changed: > >What|Removed |Added > > CC||janis187 at us dot ibm dot >||com Janis is no longer at IBM http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01516.html (her assignment has now come through, according to copyright.list) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473
[Bug fortran/44347] SELECT_REAL_KIND: Wrongly accepts non-scalar arguments
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-06-09 20:11 --- Confirmed. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 GCC host triplet|x86_64-unknown-linux-gnu| Last reconfirmed|-00-00 00:00:00 |2010-06-09 20:11:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44347
[Bug fortran/44442] Useless temporary with RESHAPE
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-09 19:45 --- I believe this is a dupe of PR33341. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug fortran/44359] -Wall / -Wconversion: Too verbose warning for DATA BOZ conversions
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-06-09 19:42 --- Fixed in trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44359
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-09 19:41 --- (In reply to comment #1) > As I read this, the test case is invalid since it does not have a rewind or > backspace before the write? Yes - I expect that gfortran should issue an EOR error instead of happily accepting an I/O transfer. > If we want to change this to be an intended extension, I suppose we should > issue a warning or error for -std= ? Well, I think we can do two things: a) Keep the current status and claim it is an extension b) Change it to match NAG f95 and Pathscale and print a run-time EoF error. (Or the equivalent for ERR=/IOSTAT=/IOMSG=.) I do not think that it makes sense to allow it for -std=(gnu/legacy) and not for -std=f(95/2003/2008). As Pathscale prints an error, there is hope that not too many programs rely on having no BACKSPACE/REWIND. Error: Pathscale 3.2.99, NAG f95 v5.1, Open64 4.2 No error: ifort 11.1, gfortran, g95, sunf95 8.3 (sunstudio12), Portland's pgf90 v6.2 and v10.3. (No idea what g77 did.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44359] -Wall / -Wconversion: Too verbose warning for DATA BOZ conversions
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-06-09 19:41 --- Subject: Bug 44359 Author: dfranke Date: Wed Jun 9 19:40:58 2010 New Revision: 160505 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160505 Log: gcc/fortran/: 2010-06-09 Daniel Franke PR fortran/44359 * intrinsic.c (gfc_convert_type_warn): Further improve -Wconversion. gcc/testsuite/: 2010-06-09 Daniel Franke PR fortran/44359 * gfortran.dg/warn_conversion.f90: Removed check for redundant warning. * gfortran.dg/warn_conversion_2.f90: Use non-constant expression to check for warning. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/warn_conversion.f90 trunk/gcc/testsuite/gfortran.dg/warn_conversion_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44359
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2010-06-09 19:24 --- As I read this, the test case is invalid since it does not have a rewind or backspace before the write? If we want to change this to be an intended extension, I suppose we should issue a warning or error for -std= ? I want to study this more before we do anything. Regression territory here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug libstdc++/44475] bunch of warnings of "second definition" on osf
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-09 19:19 --- Subject: Re: bunch of warnings of "second definition" on osf I've regularly seen those warnings, but ignored them since I've found no ill effect and the testsuite largely passes (which doesn't use the static libstdc++.a anyway). While I do have Tru64 UNIX sources, the compilation tools (including nm, ar, and ld) are missing, so I cannot use that source to shed some light on the warning, and binutils aren't an option yet since they don't allow a bootstrap to finish. Unless the reporter can provide evidence that this warning causes actual problems, I'd suggest to close this as INVALID. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44475
[Bug tree-optimization/44483] [4.6 regression] gcc consumes all available memory when optimizing
--- Comment #2 from falk at debian dot org 2010-06-09 19:11 ---
Confirmed, seems to be in if-conv. Here's a smaller test case:
int ffesum (void) {
int ch[4], ii, jj, kk;
char asc[32];
for (ii = 0; ii < 4; ii++)
{
for (jj = 0; jj < 4; jj++)
ch[jj] = ii;
for (kk = 0; kk < 13; kk++)
for (jj = 0; jj < 4; jj += 2)
if ((unsigned char) ch[jj] || (unsigned char) ch[jj + 1])
ch[jj]++;
for (jj = 0; jj < 4; jj++)
asc[4 * jj + ii] = ch[jj];
}
return asc[0];
}
--
falk at debian dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
[Bug rtl-optimization/44460] [4.6 Regression] r160380 breaks libjava bootstrap on *-apple-darwin*
--- Comment #8 from dominiq at lps dot ens dot fr 2010-06-09 18:39 --- > > The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html > > It definitly avoids the ICE, but it would be nice to know if libstdc++ > > testsuite passes. > > It does fix the bootstrap failure. I am currently regtesting (at gfortran > -m32) > and should have the results for libstdc++ in a couple of hours. On x86_64-apple-darwin10.3.0 I have bootstrapped successfully revision 160431 with revision 160380 reverted and revision 160454 with revision 160380 and the patch in http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html. For the later the regtest failures are those reported in http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00587.html . Note that the 2*16 failures for libstdc++ are due to revision 159362 (see also the regress logs for ppc). Martin Jambor knows about them and I'll fill a PR for yesterday later tonight or tomorrow (filling PR against darwin sucks!-). Obviously (as a duplicate) the patch fixes also pr44453. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44460
[Bug fortran/44430] [4.5/4.6 Regression] Infinite recursion with -fdump-parse-tree
--- Comment #8 from janus at gcc dot gnu dot org 2010-06-09 18:38 --- Subject: Bug 44430 Author: janus Date: Wed Jun 9 18:38:11 2010 New Revision: 160504 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160504 Log: 2010-06-09 Janus Weil PR fortran/44430 * dump-parse-tree.c (show_symbol): Avoid infinite loop. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44430
[Bug other/43838] [4.4/4.5/4.6 Regression] Incorrect output from abi::__cxa_demangle
--- Comment #12 from jakub at gcc dot gnu dot org 2010-06-09 18:09 --- I see the bug. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-06-08 17:57:00 |2010-06-09 18:09:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #30 from manu at gcc dot gnu dot org 2010-06-09 17:57 --- (In reply to comment #29) > Created an attachment (id=20878) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20878&action=view) [edit] > Refreshed version. Fully Bootstraps the C FE and passes regression tests. > > This fixes a annoying bug that were making the compiler emit wrong debug info, > leading to binaries that were not really debug-able. > > Next stop is to disable this feature by default, and enable it with a > -ftrack-macro-expansion flag, and update the regressions tests of the C FE. Great but... you should just prune the output in the general case (extending prune.exp) and only bother to handle the extra output in cases where it makes sense to specifically test it. This is what we do for the "inlined from" messages and it makes sense to do the same for this kind of message. I see now the sense in the column numbers, I think it is the order that confused me (and not seeing the code clearly). I would prefer a different output like: test.c:13:3: in expansion of macro MULT2 test.c:5:14: in expansion of macro SHIFTL test.c:8:3: in expansion of macro OPERATE test.c:2:8: error: invalid operands to binary << (have 'double' and 'int') But this is bike-shedding at this stage and it is more important to get the internals working. BTW, do we also keep the information about the macro arguments? If so, after your patch goes in we could even go as far as to print macro arguments: test.c:13:3: in expansion of macro MULT2 [with A=1.0] test.c:5:14: in expansion of macro SHIFTL [with A=1.0, B=1] test.c:8:3: in expansion of macro OPERATE [with OPRD1=1.0, OPTR=<<, OPTRD2=1] test.c:2:8: error: invalid operands to binary << (have 'double' and 'int') Ok, ok. let's get back to reality ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug rtl-optimization/44460] [4.6 Regression] r160380 breaks libjava bootstrap on *-apple-darwin*
--- Comment #7 from hp at gcc dot gnu dot org 2010-06-09 17:53 --- (In reply to comment #5) > The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html > It definitly avoids the ICE, but it would be nice to know if libstdc++ > testsuite passes. When applied to r160481, it solved the problems for cris-elf with no regressions compared to r160368. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44460
[Bug c/44483] [4.6 regression] gcc consumes all available memory when optimizing
--- Comment #1 from martin at mpa-garching dot mpg dot de 2010-06-09 17:42 --- Created an attachment (id=20879) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20879&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
[Bug c/44483] New: [4.6 regression] gcc consumes all available memory when optimizing
When compiling the attached testcase, current trunk gcc uses all available memory on my system (4GB) and then swaps until I interrupt the process. This only happens with -O3; using -O2 works as expected. gcc 4.5 comiles the file as expected with -O3. /scratch/tmp/devel2/build.linux_gcc/libcfitsio>gcc -c -O3 -v checksum.i Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/afs/mpa/data/martin/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /scratch/martin/gcc/configure --disable-bootstrap --enable-gold --enable-plugins --prefix=/afs/mpa/data/martin/ugcc --with-ppl=/afs/mpa/data/martin/numlibs64 --with-cloog=/afs/mpa/data/martin/numlibs64 --with-libelf=/afs/mpa/data/martin/numlibs64 --enable-languages=c++,fortran --enable-target=all --enable-checking=release Thread model: posix gcc version 4.6.0 20100609 (experimental) [trunk revision 160476] (GCC) COLLECT_GCC_OPTIONS='-c' '-O3' '-v' '-mtune=generic' '-march=x86-64' /afs/mpa/data/martin/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/cc1 -fpreprocessed checksum.i -quiet -dumpbase checksum.i -mtune=generic -march=x86-64 -auxbase checksum -O3 -version -o /tmp/ccibJbLw.s GNU C (GCC) version 4.6.0 20100609 (experimental) [trunk revision 160476] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.2, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 warning: GMP header version 4.3.2 differs from library version 4.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.6.0 20100609 (experimental) [trunk revision 160476] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.2, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1 warning: GMP header version 4.3.2 differs from library version 4.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: f4e23293da4cc17049a858a32373cf07 ^C /scratch/tmp/devel2/build.linux_gcc/libcfitsio> -- Summary: [4.6 regression] gcc consumes all available memory when optimizing Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44483
[Bug java/16858] Linking of jv-convert fails with redundant pthreads symbols
--- Comment #5 from jay dot krell at cornell dot edu 2010-06-09 17:39 --- Exact same errors building gc (not gcc) using gcc 4.3.5 on OSF/1 5.1. I haven't tried building java/libjava. Will probably do that. Please reopen. make[2]: Entering directory `/home/jayk/obj/gc' gcc -DPACKAGE_NAME=\"gc\" -DPACKAGE_TARNAME=\"gc\" -DPACKAGE_VERSION=\"6.8\" -DPACKAGE_STRING=\"gc\ 6.8\" -DPACKAGE_BUGREPORT=\"hans.bo...@hp.com\" -DGC_VERSION_MAJOR=6 -DGC_VERSION_MINOR=8 -DPACKAGE=\"gc\" -DVERSION=\"6.8\" -DGC_OSF1_THREADS=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DSILENT=1 -DNO_SIGNALS=1 -DNO_EXECUTE_PERMISSION=1 -DALL_INTERIOR_POINTERS=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 -DATOMIC_UNCOLLECTABLE=1 -I. -I/home/jayk/src/gc6.8 -I/home/jayk/src/gc6.8/include -pthread -fexceptions -g -O2 -c /home/jayk/src/gc6.8/tests/test.c /bin/ksh ./libtool --mode=link gcc -fexceptions -g -O2 -o gctest test.o ./libgc.la -lpthread -lrt gcc -fexceptions -g -O2 -o .libs/gctest test.o ./.libs/libgc.so -lpthread -lrt -Wl,-rpath -Wl,/home/jayk/lib /usr/bin/ld: /home/jayk/lib/gcc/alphaev67-dec-osf5.1/4.3.5/libgcc.a(gthr-posix.o): pthread_key_create: multiply defined /home/jayk/lib/gcc/alphaev67-dec-osf5.1/4.3.5/libgcc.a(gthr-posix.o): __pthread_getspecific: multiply defined /home/jayk/lib/gcc/alphaev67-dec-osf5.1/4.3.5/libgcc.a(gthr-posix.o): __pthread_setspecific: multiply defined /home/jayk/lib/gcc/alphaev67-dec-osf5.1/4.3.5/libgcc.a(gthr-posix.o): __pthread_mutex_lock: multiply defined /home/jayk/lib/gcc/alphaev67-dec-osf5.1/4.3.5/libgcc.a(gthr-posix.o): __pthread_mutex_unlock: multiply defined /home/jayk/lib/gcc/alphaev67-dec-osf5.1/4.3.5/libgcc.a(gthr-posix.o): pthread_attr_destroy: multiply defined /home/jayk/lib/gcc/alphaev67-dec-osf5.1/4.3.5/libgcc.a(gthr-posix.o): pthread_attr_init: multiply defined collect2: ld returned 1 exit status make[2]: *** [gctest] Error 1 make[2]: Leaving directory `/home/jayk/obj/gc' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/home/jayk/obj/gc' make: *** [check-recursive] Error 1 bash-4.1$ gcc -v Using built-in specs. Target: alphaev67-dec-osf5.1 Configured with: /home/jayk/src/gcc-4.3.5/configure -disable-nls -with-gmp=/home/jayk -prefix=/home/jayk Thread model: posix gcc version 4.3.5 (GCC) -- jay dot krell at cornell dot edu changed: What|Removed |Added CC||jay dot krell at cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16858
[Bug other/43838] [4.4/4.5/4.6 Regression] Incorrect output from abi::__cxa_demangle
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-09 17:24 --- Can be reproduced also with c++filt _ZN5boost6tuples5tupleIN23abcdefgxyzzzabb3AaaENS2_4klmn16BaaaENS0_9null_typeES6_S6_S6_S6_S6_S6_S6_EE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
[Bug java/43839] libjava incorrectly uses -liconv in testsuite, jni.exp when using --with-libiconv-prefix
--- Comment #11 from mrs at gcc dot gnu dot org 2010-06-09 17:21 --- Fixed. -- mrs at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43839
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #29 from dodji at gcc dot gnu dot org 2010-06-09 17:09 --- Created an attachment (id=20878) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20878&action=view) Refreshed version. Fully Bootstraps the C FE and passes regression tests. This fixes a annoying bug that were making the compiler emit wrong debug info, leading to binaries that were not really debug-able. Next stop is to disable this feature by default, and enable it with a -ftrack-macro-expansion flag, and update the regressions tests of the C FE. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #20769|0 |1 is obsolete|| Attachment #20770|0 |1 is obsolete|| Attachment #20846|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug other/43838] [4.4/4.5/4.6 Regression] Incorrect output from abi::__cxa_demangle
--- Comment #10 from paolo dot carlini at oracle dot com 2010-06-09 17:05 --- Thanks HJ. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
[Bug other/43838] [4.4/4.5/4.6 Regression] Incorrect output from abi::__cxa_demangle
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-09 16:56 --- It is caused by revision 142799: http://gcc.gnu.org/ml/gcc-cvs/2008-12/msg00498.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com Target Milestone|--- |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
[Bug fortran/44346] gfortran accepts illegal arguments to intrinsics
--- Comment #5 from kargl at gcc dot gnu dot org 2010-06-09 16:39 --- Patch has been committed to 4.4, 4.5, and trunk. Closing. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44346
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- Comment #11 from burnus at gcc dot gnu dot org 2010-06-09 16:36 --- cross-ref: http://sourceware.org/bugzilla/show_bug.cgi?id=5780 http://sourceware.org/bugzilla/show_bug.cgi?id=5784 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug c/44482] New: some warnings in libgcc amd64-darwin 4.5.0
note this is later bootstrap stages so shouldn't matter what the bootstrap
compiler was (assuming it compiled the compiler reasonably correctly)
For the missing prototypes, I suggest you just put them right there:
void Foo(void);
void Foo(void)
{
...
}
for the uninitialized I suggest just initializing them and not worrying about
it.
For the cast I already posted a patch adding const.
The shifts are buried in macros and I didn't look so not sure.
Personally if I want (a << 32) I'd just do ((a << 31) << 1)..or, uh, just 0,
but that may or may not be relevant here.
_darwin10_Unwind_FindEnclosingFunction I didn't look at.
I'll maybe come back to this myself, hopefully that's not an abuse of gcc
bugzilla (esp. given that this is not using -disable-bootstrap so not a
terrible bug report).
I'm surprised -Werror isn't used here.
I suggest -Wmissing-prototypes only apply to callers not implementers? I
realize it is a tradeoff, because you want to make sure there is a prototype
somewhere for callers (though not really for libgcc math helpers...) and
forcing the implementor to pull that in is a reasonable way to make that so.
/home/jayk/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c: In function
'uw_init_context_1':
/home/jayk/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c:1452:5: warning: missing
initializer
/home/jayk/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2.c:1452:5: warning: (near
initialization for 'once_regsizes.__reserved')
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2-fde-darwin.c: At top level:
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/unwind-dw2-fde-darwin.c:279:1: warning:
no previous prototype for '_darwin10_Unwind_FindEnclosingFunction'
/Users/jay/obj/gcc/./gcc/xgcc -B/Users/jay/obj/gcc/./gcc/
-B/Users/jay/amd64-darwin/bin/ -B/Users/jay/amd64-darwin/lib/ -isystem
/Users/jay/amd64-darwin/include -isystem /Users/jay/amd64-darwin/sys-include
-g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc
-I/Users/jay/src/gcc-4.5.0/libgcc -I/Users/jay/src/gcc-4.5.0/libgcc/.
-I/Users/jay/src/gcc-4.5.0/libgcc/../gcc
-I/Users/jay/src/gcc-4.5.0/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS
-Wno-missing-prototypes -Wno-type-limits -o fixunstfsi_s.o -MT fixunstfsi_s.o
-MD -MP -MF fixunstfsi_s.dep -DSHARED -fexceptions -c
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/soft-fp/fixunstfsi.c
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/soft-fp/fixunstfsi.c: In function
'__fixunstfsi':
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/soft-fp/fixunstfsi.c:42:3:
warning: left shift count >= width of type
/Users/jay/obj/gcc/./gcc/xgcc -B/Users/jay/obj/gcc/./gcc/
-B/Users/jay/amd64-darwin/bin/ -B/Users/jay/amd64-darwin/lib/ -isystem
/Users/jay/amd64-darwin/include -isystem /Users/jay/amd64-darwin/sys-include
-g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc
-I/Users/jay/src/gcc-4.5.0/libgcc -I/Users/jay/src/gcc-4.5.0/libgcc/.
-I/Users/jay/src/gcc-4.5.0/libgcc/../gcc
-I/Users/jay/src/gcc-4.5.0/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS
-Wno-missing-prototypes -Wno-type-limits -o multf3_s.o -MT multf3_s.o -MD -MP
-MF multf3_s.dep -DSHARED -fexceptions -c
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/soft-fp/multf3.c
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/soft-fp/multf3.c: In function
'__multf3':
/Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/soft-fp/multf3.c:38:1: warning:
'R_e' may be used uninitialized in this function
/Users/jay/obj/gcc/./gcc/xgcc -B/Users/jay/obj/gcc/./gcc/
-B/Users/jay/amd64-darwin/bin/ -B/Users/jay/amd64-darwin/lib/ -isystem
/Users/jay/amd64-darwin/include -isystem /Users/jay/amd64-darwin/sys-include
-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc
-I/Users/jay/src/gcc-4.5.0/libgcc -I/Users/jay/src/gcc-4.5.0/libgcc/.
-I/Users/jay/src/gcc-4.5.0/libgcc/../gcc
-I/Users/jay/src/gcc-4.5.0/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o
darwin-64_s.o -MT darwin-64_s.o -MD -MP -MF darwin-64_s.dep -DSHARED
-fexceptions -c /Users/jay/src/gcc-4.5.0/libgcc/../gcc/config/darwin-64.c
/Users/jay/obj/gcc/./gcc/xgcc -B/Users/jay/obj/gcc/./gcc/
-B/Users/jay/amd64-darwin/bin/ -B/Users/jay/amd64-darwin/lib/ -isystem
/Users/jay/amd64-darwin/include -isystem /Users/jay/amd64-darwin/sys-include
-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -fPIC -pipe -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FL
[Bug libstdc++/44461] __cxa_end_cleanup ends up in wrong section i.e. not in .text
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-09 15:52 --- In general, only if it's a regression. And nobody said that explicitly so far. If you want to argue for having it anyway in 4_5-branch, please speak on the mailing list and ask permission to the release managers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
[Bug libstdc++/44461] __cxa_end_cleanup ends up in wrong section i.e. not in .text
--- Comment #7 from raj dot khem at gmail dot com 2010-06-09 15:48 --- thanks Paolo, we would need this patch on 4.5 branch as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-09 15:46 --- I see. Looks like Matt essentially followed in the reference implementation the legacy HP / SGI, linear, way of computing begin(). I'm asking his opinion on this, whether we are also going to use caching or something else maybe... Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-09 15:46:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug libstdc++/44461] __cxa_end_cleanup ends up in wrong section i.e. not in .text
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-09 15:36 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
[Bug libstdc++/44461] __cxa_end_cleanup ends up in wrong section i.e. not in .text
--- Comment #5 from paolo at gcc dot gnu dot org 2010-06-09 15:35 --- Subject: Bug 44461 Author: paolo Date: Wed Jun 9 15:34:45 2010 New Revision: 160488 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160488 Log: 2010-06-09 Khem Raj PR libstdc++/44461 * libsupc++/eh_arm.cc (__cxa_end_cleanup): Use .pushsection/.popsection to emit inline assembly into .text section. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/eh_arm.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
[Bug objc++/27249] FAIL: obj-c++.dg/encode-8.mm execution test
-- mrs at gcc dot gnu dot org changed: What|Removed |Added CC|mikestump at comcast dot net| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27249
[Bug fortran/44465] [OOP] ICE with polymorphic object oriented example
--- Comment #6 from ian at rhymneyconsulting dot co dot uk 2010-06-09 15:20 --- Subject: RE: [OOP] ICE with polymorphic object oriented example Thanks very much for fixing it. Cheers Ian > -Original Message- > From: burnus at gcc dot gnu dot org [mailto:gcc-bugzi...@gcc.gnu.org] > Sent: 09 June 2010 16:07 > To: i...@rhymneyconsulting.co.uk > Subject: [Bug fortran/44465] [OOP] ICE with polymorphic object oriented > example > > > > --- Comment #5 from burnus at gcc dot gnu dot org 2010-06-09 15:07 > --- > With the patch for PR 44211 (just committed to the 4.6 trunk), the > program > compiles and the output is: > > shape > In generic_shape_assign > x = 10 > y = 20 > circle > In generic_shape_assign > x = 100 > y = 200 > radius = 300 > rectangle > In generic_shape_assign > x = 1000 > y = 2000 > width = 3000 > height = 4000 > > Thanks again for the bug report! > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44465 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44465
[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-09 15:13 --- I gave this more thought, and to be honest, focusing on 64-bit targets - I think that for 32-bit targets what we have is already good enough - I have no idea how to substantively improve the code, given that the length of a string is a 64-bit unsigned and the return type must be an int. Jon? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44413
[Bug c++/44366] [C++0x] g++ crashes when declaring a lambda expression using a typedef'd decltype.
--- Comment #9 from jason at gcc dot gnu dot org 2010-06-09 15:12 --- Subject: Bug 44366 Author: jason Date: Wed Jun 9 15:11:42 2010 New Revision: 160483 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160483 Log: PR c++/44366 * g++.dg/cpp0x/decltype23.C: Move to... * g++.dg/diagnostic/parm1.C: ...here, and remove decltype. Added: trunk/gcc/testsuite/g++.dg/diagnostic/ trunk/gcc/testsuite/g++.dg/diagnostic/parm1.C - copied, changed from r160478, trunk/gcc/testsuite/g++.dg/cpp0x/decltype23.C Removed: trunk/gcc/testsuite/g++.dg/cpp0x/decltype23.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44366
[Bug fortran/44465] [OOP] ICE with polymorphic object oriented example
--- Comment #5 from burnus at gcc dot gnu dot org 2010-06-09 15:07 --- With the patch for PR 44211 (just committed to the 4.6 trunk), the program compiles and the output is: shape In generic_shape_assign x = 10 y = 20 circle In generic_shape_assign x = 100 y = 200 radius = 300 rectangle In generic_shape_assign x = 1000 y = 2000 width = 3000 height = 4000 Thanks again for the bug report! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44465
[Bug tree-optimization/44258] [4.5/4.6 Regression] possible SRA wrong-code generation.
--- Comment #11 from jamborm at gcc dot gnu dot org 2010-06-09 14:43 --- OK, I have found the bug and I admit it is rather embarrassing. I'll submit a patch soon. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-05-30 17:04:29 |2010-06-09 14:43:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44258
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #28 from dodji at gcc dot gnu dot org 2010-06-09 14:32 --- Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL constants "manu at gcc dot gnu dot org" writes: >> >> $ ./cc1 -quiet test.c >> While expanding macro OPERATE at test.c:2:8 >> While expanding macro SHIFTL at test.c:5:14 >> While expanding macro MULT2 at test.c:8:3 >> test.c: In function 'g': >> test.c:13:3: error: invalid operands to binary << (have 'double' and 'int') > Also, what are the column numbers pointing to? They don't make sense > to me. About this line: >> While expanding macro OPERATE at test.c:2:8 which is about: #define OPERATE(OPRD1, OPRT, OPRD2) \ OPRD1 OPRT OPRD2; Column 8 is the starting column of the OPRT token. About this line: >> While expanding macro SHIFTL at test.c:5:14 which is about: #define SHIFTL(A,B) \ OPERATE (A,<<,B) Column 14 is the starting column of the '<<' token. About this line: >> While expanding macro MULT2 at test.c:8:3 which is about: #define MULT2(A) \ SHIFTL (A,1) Column 3 is the starting column of the 'SHIFT' token. > In any case, this is a huge step forward! Thanks for working on this. It would > be an important marketing point if you manage to complete it for GCC > 4.6. No problem ;) Not sure it'll get into 4.6, but I'll try. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
Re: [Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
"manu at gcc dot gnu dot org" writes: >> >> $ ./cc1 -quiet test.c >> While expanding macro OPERATE at test.c:2:8 >> While expanding macro SHIFTL at test.c:5:14 >> While expanding macro MULT2 at test.c:8:3 >> test.c: In function 'g': >> test.c:13:3: error: invalid operands to binary << (have 'double' and 'int') > Also, what are the column numbers pointing to? They don't make sense > to me. About this line: >> While expanding macro OPERATE at test.c:2:8 which is about: #define OPERATE(OPRD1, OPRT, OPRD2) \ OPRD1 OPRT OPRD2; Column 8 is the starting column of the OPRT token. About this line: >> While expanding macro SHIFTL at test.c:5:14 which is about: #define SHIFTL(A,B) \ OPERATE (A,<<,B) Column 14 is the starting column of the '<<' token. About this line: >> While expanding macro MULT2 at test.c:8:3 which is about: #define MULT2(A) \ SHIFTL (A,1) Column 3 is the starting column of the 'SHIFT' token. > In any case, this is a huge step forward! Thanks for working on this. It would > be an important marketing point if you manage to complete it for GCC > 4.6. No problem ;) Not sure it'll get into 4.6, but I'll try.
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #27 from dodji at gcc dot gnu dot org 2010-06-09 14:23 --- Subject: Re: __extension__ keyword doesn't suppress warning on LL or ULL constants "manu at gcc dot gnu dot org" writes: > I find this output a bit confusing. I find clang's output clearer > http://clang.llvm.org/diagnostics.html. I guess you are talking about the "automatic macro expansion" section of that link? > > In fact, clang's output actually follows more closely what GCC already does > with templates/inline functions. Well, this is obviously a first step in that direction. I'd be more interested in knowing what I can do at *this* step :-) But yes, once I can bootstrap all the FEs with the macro location tracking infrastructure in place with no regression, I guess I'll focus more on the user visible output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
Re: [Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
"manu at gcc dot gnu dot org" writes: > I find this output a bit confusing. I find clang's output clearer > http://clang.llvm.org/diagnostics.html. I guess you are talking about the "automatic macro expansion" section of that link? > > In fact, clang's output actually follows more closely what GCC already does > with templates/inline functions. Well, this is obviously a first step in that direction. I'd be more interested in knowing what I can do at *this* step :-) But yes, once I can bootstrap all the FEs with the macro location tracking infrastructure in place with no regression, I guess I'll focus more on the user visible output.
[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-09 14:16 --- Whatever we do, we need to preserve Atom add->lea optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
[Bug fortran/44211] [OOP] ICE with TBP of pointer component of derived type array
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-09 14:16 --- Fixed with r160478. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44211
[Bug target/44067] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713
--- Comment #12 from bergner at gcc dot gnu dot org 2010-06-09 14:15 --- Subject: Bug 44067 Author: bergner Date: Wed Jun 9 14:15:11 2010 New Revision: 160479 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160479 Log: Backport from mainline: 2010-06-09 Edmar Wienskoski PR target/44067 * config/rs6000/rs6000.md (DIFD): Do not split dpfp values for e500v2 target. Modified: branches/ibm/gcc-4_4-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_4-branch/gcc/config/rs6000/rs6000.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44067
[Bug fortran/44211] [OOP] ICE with TBP of pointer component of derived type array
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-09 14:15 --- Subject: Bug 44211 Author: janus Date: Wed Jun 9 14:14:08 2010 New Revision: 160478 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160478 Log: 2010-06-09 Janus Weil PR fortran/44211 * resolve.c (resolve_typebound_function,resolve_typebound_subroutine): Resolve references. 2010-06-09 Janus Weil PR fortran/44211 * gfortran.dg/typebound_call_14.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/typebound_call_14.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44211
[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom
--- Comment #7 from hjl dot tools at gmail dot com 2010-06-09 14:13 ---
(In reply to comment #4)
> (In reply to comment #1)
> > It may be broken by revision 160394:
> >
> > http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
>
> The add->lea transformation doesn't even trigger in this testcase... You still
> have normal add instruction with a flags clobber up to and including sched2
> pass.
>
> Later, compilation breaks in machine reorg pass with:
>
> Program received signal SIGSEGV, Segmentation fault.
> distance_non_agu_define (code=, insn=0x718c2750,
> operands=0x1298aa0) at ../../gcc-svn/trunk/gcc/config/i386/i386.c:13826
> 13826 if (insn != BB_HEAD (bb))
>
> (gdb) l
> 13821 basic_block bb = BLOCK_FOR_INSN (insn);
> 13822 int distance = 0;
> 13823 df_ref *def_rec;
> 13824 enum attr_type insn_type;
> 13825
> 13826 if (insn != BB_HEAD (bb))
> 13827 {
> 13828 rtx prev = PREV_INSN (insn);
> 13829 while (prev && distance < LEA_SEARCH_THRESHOLD)
> 13830 {
>
> It looks to me that bb is NULL, which isn't a good sign anyway.
ix86_lea_for_add_ok shouldn't be call during final scan when
we have already looked all add patterns and converted them
to lea if necessary.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|4.6.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #43 from mark dot workman at acm dot org 2010-06-09 14:07 --- (In reply to comment #39) > Hi, Kyle Moffett, > in testall.c, r9 is used by a register variable, however, in E500ABI > guide, > r9 should be used for parameter passing, this test case seems not reasonable. > > Harry He Please note that this testcase was removed by Kyle (see comment #12) and that neither the original testcase (tc-lossings-float.c) nor the trimmed testcase (tc-lossings-float-3.c) make such explicit use of particular registers. Thus, it does appear that it is the compiler that is making the register assignments in question. Cheers, Mark > -- mark dot workman at acm dot org changed: What|Removed |Added CC||mark dot workman at acm dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64
--- Comment #7 from paolo at gcc dot gnu dot org 2010-06-09 14:02 --- Subject: Bug 44413 Author: paolo Date: Wed Jun 9 14:02:03 2010 New Revision: 160476 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160476 Log: 2010-06-09 Paolo Carlini Revert: 2010-06-09 Paolo Carlini PR libstdc++/44413 * include/ext/vstring_util.h (__vstring_utility<>::_S_compare): Simplify, just return -1, 0, 1. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/vstring_util.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44413
[Bug rtl-optimization/44481] New: __builtin_parity() causes ICE in trunc_int_for_mode()
When compiling the following program with -O2, gcc gives an ICE "internal
compiler error: in trunc_int_for_mode, at explow.c:56".
Versions affected:
gcc (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
gcc (GCC) 4.5.1 20100521 (prerelease)
static inline unsigned parity(unsigned x)
{
return (unsigned) __builtin_parity(x);
}
unsigned f(unsigned rpoly)
{
return parity(rpoly & 1) ^ parity(rpoly & 6);
}
--
Summary: __builtin_parity() causes ICE in trunc_int_for_mode()
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rainy6144 at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44481
[Bug bootstrap/44469] [4.5/4.6 Regression] internal compiler error: in fixup_reorder_chain, at cfglayout.c:797
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-09 13:55 --- There are more issues: 1) cleanup_barriers seems to do weird things with these empty bbs from __builtin_unreachable (), I guess it shouldn't reorder anything if prev is a LABEL_P 2) the reason why this compiles fine on x86_64 seems to be in different bb reordering. On arm the empty bb is reordered after the condjump, which means its label is deleted by /* Remove code labels no longer used. */ in try_optimize_cfg and then the block is trivially empty. On x86_64 we don't ICE, but generate useless code: movl(%rdi), %eax testl %eax, %eax je .L2 cmpl$1, %eax jne .L3 movq%rdi, %rsi .L2: xorl%eax, %eax cmpb$0, (%rsi) sete%al ret .L3: .cfi_endproc I'd say we shouldn't try to delete just trivially_empty_bb_p's, but also ones that before the bb note also have labels and after it nothing or only DEBUG_INSNs, but we should delete only if we actually succeed adjusting the jump insn at the end of the earlier block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44469
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #15 from andi-gcc at firstfloor dot org 2010-06-09 13:55 --- Ok seems it does not do what I want: FIXME lto. Currently the scheme is limited in that only the options saved on the first object file (f1.o) are read back during the link step. This means that the options used to compile f1.o will be applied to ALL the object files in the final link step. More work needs to be done to implement a merging and validation mechanism, as this will not be enough for all cases. */ Anyways OT for this bug, maybe needs a new one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #42 from gcc at breakpoint dot cc 2010-06-09 13:52 --- (In reply to comment #41) > The ICE in #38 is due to a bug in caller-save.c Thank you for the very quick fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug rtl-optimization/44460] [4.6 Regression] r160380 breaks libjava bootstrap on *-apple-darwin*
--- Comment #6 from dominiq at lps dot ens dot fr 2010-06-09 13:50 --- > The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html > It definitly avoids the ICE, but it would be nice to know if libstdc++ > testsuite passes. It does fix the bootstrap failure. I am currently regtesting (at gfortran -m32) and should have the results for libstdc++ in a couple of hours. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44460
[Bug rtl-optimization/44460] [4.6 Regression] r160380 breaks libjava bootstrap on *-apple-darwin*
--- Comment #5 from hubicka at gcc dot gnu dot org 2010-06-09 13:43 --- The following http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html It definitly avoids the ICE, but it would be nice to know if libstdc++ testsuite passes. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44460
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #14 from andi-gcc at firstfloor dot org 2010-06-09 13:42 --- I found this code in lto.c which seems to disagree: /* Read the options saved from each file in the command line. Called from lang_hooks.post_options which is called by process_options right before all the options are used to initialize the compiler. This assumes that decode_options has already run, so the num_in_fnames and in_fnames are properly set. Note that this assumes that all the files had been compiled with the same options, which is not a good assumption. In general, options ought to be read from all the files in the set and merged. However, it is still unclear what the merge rules should be. */ void lto_read_all_file_options (void) Still remains to be seen if it DTRT though (e.g. for -pg vs no -pg) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug middle-end/44453] [4.6 Regression] Revision 160380 caused g++.dg/torture/pr32304.C
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-06-09 13:39 --- The following patch http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00692.html should fix the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44453
[Bug libstdc++/44480] New: Linear performance of begin() in unordered associative containers
The current implementation of begin() for unordered associative containers is linear (a search for the first non-empty bucket is executed each time begin() is called), yet the C++0x drafts specifiy that this should be constant (23.3.1, table 93). Boost.Unordered, for instance, caches the first non-empty bucket on insertion/deletion to meet the O(1) begin() requirement. -- Summary: Linear performance of begin() in unordered associative containers Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: joaquin at tid dot es http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44480
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #13 from andi-gcc at firstfloor dot org 2010-06-09 13:35 --- What happens then when some files need different options that other files? This sounds more and more like a showstopper if you're right. I was not prepared to redesign the Makefiles -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #41 from amodra at gmail dot com 2010-06-09 13:26 --- Created an attachment (id=20877) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877&action=view) e500.h and caller-save.c patch The ICE in #38 is due to a bug in caller-save.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
