[Bug java/49556] The import A cannot be resolved，But the A is placed at the current dir.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49556 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|blocker |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-06-28 06:09:20 UTC --- I think this is correct as classes in the same packages don't cannot be imported.
[Bug libmudflap/38738] libmudflap could be enabled for Solaris when using GNU ld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38738 --- Comment #8 from Rob rob1weld at aol dot com 2011-06-28 06:18:04 UTC --- Thanks for FIXing, every little bit helps. Rob
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #15 from Joerg Wunsch j at uriah dot heep.sax.de 2011-06-28 06:27:17 UTC --- (In reply to comment #14) . Regardless of whether someone votes to remove an option, a segfault should always be analyzed. Except that this is a segfault on a compiler switch that is unmaintained, Did you analyze it to make sure there is no chance for this to happen also without -mint8? OK, I did, and it's indeed the case. unmaintained — by the original maintainers. The people contributing (patches!) to this bug report demonstrate there actually *is* some effort to still maintain it — by the users. Why ignore this effort, and do it away as we don't want to maintain that anymore? The only drawback I could see with that patch is that it introduces a couple of #ifdefs outside of the AVR code path in the compiler, to give the AVR backend an override option for the type sizes. and there are little to no user complaints about it. That's simply because all the compiler versions that are out in the field (4.3.x, 4.4.x) still have a working (within their known limitations, of course) -mint8 option. Be assured, we will get complaints about it if you release another WinAVR with a non-working -mint8 option, or with the option dropped. Actually it does. The attiny10 series (attiny10/4/5/9/20/40) is still what I would call experimental, in that they are only in distros and not upstream, and you know as well as I do that there is a serious wrong-code bug with them anyway. That doesn't matter much. The wrong-code bug can (probably) be fixed, but the integer promotion issues won't be affected by that fix. If you don't like the reference to ATtiny10 (Co.), just keep the ATtiny13 (and probably also ATtiny2313, ATtiny25, ATtiny45) in your mind by now. As to the other small device users, those devices still use avr-libc They *can* use it. We've always told them however, that using -mint8 and avr-libc doesn't mix. Nevertheless, it appears to be useful enough to some users to decide pro -mint8 (and thus against using the library). (It isn't even entirely true that both don't mix: a lot of the library stuff just comes as inline functions and macros within the header files, and this part is likely working to a large degree even with -mint8.) We all know that the ideal solution is to fix the avr backend regarding optimizing (removing) unnecessary promotion. We can start by biting the bullet and removing -mint8. I'd do it the other way around: fix the optimization issues, until the users don't benefit from the -mint8 hack anymore. By that time, it can be removed without anyone complaining. You cannot impose any pressure to the *developers* (to fix the optimization issues) by removing the option now, but you'll cause some impact for users of that option — users who can't do anything about it other than voicing their complaints in public that more recent versions of GCC get worse and worse in their usability. I'd like to avoid this situation.
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #16 from Joerg Wunsch j at uriah dot heep.sax.de 2011-06-28 06:30:42 UTC --- Created attachment 24611 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24611 Fixed the filenames in the patch header. Fixed the filenames in the patch header (there have been two .orig too many). I can confirm the patch fixes the issue in question on GCC trunk.
[Bug middle-end/49545] [4.7 Regression] New C++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49545 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-06-28 06:31:11 UTC --- constexpr-ptrmem.C is now failing because the C++ ABI uses the low bit of the function pointer field in a pointer-to-member function to indicate whether that field is actually a function pointer or a vtable index, and constexpr-ptrmem.C relies on being able to fold (fn) 1 to 0. I assume that the ARM C++ ABI variant uses a different representation.
[Bug ada/49557] New: Building the GCC compiler suite fails on a Makefile concerning Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49557 Summary: Building the GCC compiler suite fails on a Makefile concerning Ada Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.markus...@gmail.com I can not build the GCC compiler suite (as contained in the sources from 2011-06-20, release candidate for GCC 4.6.1). It fails with the following message: make[4]: Entering directory `/d/gcc4.6.1.src/gcc-4.6.1-RC-20110620/host-i686-pc-mingw32/prev-gcc' ../.././gcc/ada/gcc-interface/Make-lang.in:615: *** multiple target patterns. Stop. make[4]: Leaving directory `/d/gcc4.6.1.src/gcc-4.6.1-RC-20110620/host-i686-pc-mingw32/prev-gcc' make[3]: *** [stmp-fixinc] Error 2 make[3]: Leaving directory `/d/gcc4.6.1.src/gcc-4.6.1-RC-20110620/host-i686-pc-mingw32/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/d/gcc4.6.1.src/gcc-4.6.1-RC-20110620' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/d/gcc4.6.1.src/gcc-4.6.1-RC-20110620' make: *** [all] Error 2 Even when I attempt to reduce the set of languages to C and Fortran, the error message keeps appearing. The full configure command that I use is (the build directory is parallel to the source directory): ../gcc-4.6.1-RC-20110620/configure --with-gmp-include=d:/gcc4.6.1.src/gmp-5.0.2 --with-gmp-lib=d:/gcc4.6.1.src/gmp-5.0.2/.libs --with-mpfr-include=d:/gcc4.6.1.src/mpfr-3.0.1 --with-mpfr-lib=d:/gcc4.6.1.src/mpfr-3.0.1/.libs --with-mpc-include=d:/gcc4.6.1.src/mpc-0.9/src --with-mpc-lib=d:/gcc4.6.1.src/mpc-0.9/src/.libs --prefix=d:/gcc4.6.1 --enable-languages=c,fortran The compiler that is used (within the MSYS environment) is: Using built-in specs. COLLECT_GCC=d:\MinGW2010\bin\gfortran.exe COLLECT_LTO_WRAPPER=d:/mingw2010/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.5.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.5.0 (GCC) For completeness, here is the screen output from configure: checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking target system type... i686-pc-mingw32 checking for a BSD-compatible install... /bin/install -c checking whether ln works... yes checking whether ln -s works... no, using cp -p checking for a sed that does not truncate output... /bin/sed checking for gawk... gawk checking for gcc... gcc checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for gnatbind... gnatbind checking for gnatmake... gnatmake checking whether compiler driver understands Ada... yes checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for objdir... .libs checking for the correct version of gmp.h... yes checking for the correct version of mpfr.h... yes checking for the correct version of mpc.h... yes checking for the correct version of the gmp/mpfr/mpc libraries... yes checking for PWL_handle_timeout in -lpwl... no checking for version 0.11 (revision 0 or later) of PPL... no *** This configuration is not supported in the following subdirectories: target-libmudflap target-libgomp target-libffi target-zlib target-libjava gnattools target-libada target-libstdc++-v3 target-libgo target-libobjc target-boehm-gc (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug checking for bison... bison -y checking for bison... bison checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for expect... no checking for runtest... no checking for ar... ar checking for as... as checking for dlltool... dlltool checking for ld... (cached) d:/mingw2010/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe checking for lipo... no checking for nm... nm checking for ranlib... ranlib checking for strip... strip checking for windres... windres checking for windmc... windmc checking for objcopy... objcopy checking for objdump... objdump checking for cc... no checking for gcc... gcc checking for c++... c++ checking for gcc... gcc checking for gcj...
[Bug c++/49558] New: Compiling gcc-3.4.5 source code on MAC OS X 10.6.3 gives an error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49558 Summary: Compiling gcc-3.4.5 source code on MAC OS X 10.6.3 gives an error. Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: birender.c...@gmail.com While compiling gcc-3.4.5 source code on MAC OS X 10.6.3[which has gcc and cc with version i686-apple-darwin10-gcc-4.2.1] gives an error mentioned below. . . . . rm -f include/limits.h cp xlimits.h include/limits.h chmod a+r include/limits.h rm -f include/README cp ./README-fixinc include/README chmod a+r include/README echo timestamp stmp-int-hdrs /els/install/Rohit/gcc-3.4.5/gcc/xgcc -B/els/install/Rohit/gcc-3.4.5/gcc/ -B/usr/local/i686-apple-darwin10.3.0/bin/ -B/usr/local/i686-apple-darwin10.3.0/lib/ -isystem /usr/local/i686-apple-darwin10.3.0/include -isystem /usr/local/i686-apple-darwin10.3.0/sys-include -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I. -I./. -I./../include -I../intl \ -c ./config/darwin-crt2.c -o crt2.o ./config/darwin-crt2.c: In function `__darwin_gcc3_preregister_frame_info': ./config/darwin-crt2.c:151: error: unrecognizable insn: (insn 11 9 12 0 (set (reg/f:SI 58) (plus:SI (reg:SI 3 bx) (const:SI (minus:SI (symbol_ref:SI (L___keymgr_global$non_lazy_ptr)) (symbol_ref:SI (pic base)) -1 (nil) (nil)) ./config/darwin-crt2.c:151: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [crt2.o] Error 1 make: *** [install-gcc] Error 2 ssdarwinb1:gcc-3.4.5 root#
[Bug libstdc++/49559] New: stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559
Summary: stable_sort calls self-move-assignment operator
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ cat t.cc
#include cassert
#include algorithm
#include iostream
struct MyMoveClass
{
int val_;
explicit MyMoveClass( int val = 0 )
: val_( val )
{
std::cout ctr this= this std::endl;
}
MyMoveClass( MyMoveClass const rhs )
: val_( rhs.val_ )
{
std::cout ctr copy this= this rhs= rhs std::endl;
}
MyMoveClass( MyMoveClass rhs )
: val_( rhs.val_ )
{
std::cout ctr move this= this rhs= rhs std::endl;
rhs.val_ = 0;
}
MyMoveClass operator=( MyMoveClass rhs )
{
std::cout assign move this= this rhs= rhs std::endl;
assert( this != rhs );
val_ = rhs.val_;
rhs.val_ = 0;
return *this;
}
MyMoveClass operator=( MyMoveClass const rhs )
{
std::cout assign copy this= this rhs= rhs std::endl;
val_ = rhs.val_;
return *this;
}
~MyMoveClass()
{
std::cout dtr this= this std::endl;
}
bool operator( MyMoveClass const rhs ) const
{
return val_ rhs.val_;
}
};
int main()
{
MyMoveClass v(5);
std::stable_sort( v, v+1 );
return 0;
}
$ g++ -std=gnu++0x -o t t.cc
$ ./t
ctr this=0xbfe1730c
ctr move this=0x8afd008 rhs=0xbfe1730c
assign move this=0xbfe1730c rhs=0x8afd008
assign move this=0xbfe1730c rhs=0xbfe1730c
template: template.cc:31: MyMoveClass MyMoveClass::operator=(MyMoveClass):
Assertion `this != rhs' failed.
From DR 1204: Additionally this clarifies that move assignment operators need
not perform the traditional if (this != rhs) test commonly found (and needed)
in copy assignment operators.
Note that std::sort() calls no copy constructor or assignment operator at all.
Seems sensible when there is only one element.
[Bug c++/49260] [C++0x] lambda-eh2.C fails execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260 --- Comment #9 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-28 07:13:30 UTC --- Should be fixed on trunk now. Yes, it is, thanks. Do you plan to backport the fix to the 4.6 branch?
[Bug ada/49557] Building the GCC compiler suite fails on a Makefile concerning Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49557 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.06.28 07:27:30 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-28 07:27:30 UTC --- What happens if you use an absolute path to the configure script instead?
[Bug c++/49558] Compiling gcc-3.4.5 source code on MAC OS X 10.6.3 gives an error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49558 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-06-28 07:41:57 UTC --- GCC 3.4.5 is no longer supported and really did not have support for x86-darwin. Please use a newer version of GCC.
[Bug c/49560] New: -fexec-charset=IBM-1047 makes -Wformat report incorrect warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49560 Summary: -fexec-charset=IBM-1047 makes -Wformat report incorrect warnings Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: jphartm...@gmail.com Created attachment 24612 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24612 Preprocessor output from printf It looks as if the translated form of the format string is used. Removing the substitution parameter clears the warning. ASCII % (0x37) is not likely to be in any string that is converted to EBCDIC. [/home/john/src/cmsh/390] CFLAGS=-Wall make hlo cc -Wallhlo.c -o hlo [/home/john/src/cmsh/390] rm hlo [/home/john/src/cmsh/390] CFLAGS=-fexec-charset=IBM-1047 -Wall make hlo cc -fexec-charset=IBM-1047 -Wallhlo.c -o hlo hlo.c: In function 'main': hlo.c:17: warning: spurious trailing '%' in format hlo.c:17: warning: too many arguments for format [/home/john/src/cmsh/390] gcc --version gcc (GCC) 4.4.5 20101112 (Red Hat 4.4.5-2) Don't know how RedHat configured the compiler. And also with a 4.6.0 I compiled from unmodified source. --with-gnu-as --with-gnu-ld --prefix=/home/john/pool/360/root/usr --with-sysroot=/home/john/pool/360/root --target=s390x-ibm-linux --enable-languages=c --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr --disable-libgomp --disable-threads --disable-tls --disable-libada --disable-libssp --disable-shared --without-headers --disable-lto --disable-nls [/home/john/src/cmsh/390] uname -a Linux bigserv 2.6.34.8-68.fc13.x86_64 #1 SMP Thu Feb 17 15:03:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
[Bug libstdc++/49561] New: gcc does not meet the standard for std::list container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 Summary: gcc does not meet the standard for std::list container Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: yoch.me...@gmail.com I realized that the complexity of std::list::size() is O(n), not O(1). This does not conform to standard. The standard states that size() function is in constant time for alls containers. So, the behavior of gcc is not as expected. This also affects parts of std::list::splice() function, as mentioned in the last drat (n3242 - 23.3.5.5): [quote] 1 Since lists allow fast insertion and erasing from the middle of a list, certain operations are provided specifically for them. 2 list provides three splice operations that destructively move elements from one list to another.[...] void splice(const_iterator position, listT,Allocator x) noexcept; void splice(const_iterator position, listT,Allocator x) noexcept; [...] 4 Effects: Inserts the contents of x before position and x becomes empty. Pointers and references to the moved elements of x now refer to those same elements but as members of *this. Iterators referring to the moved elements will continue to refer to their elements, but they now behave as iterators into *this, not into x. 5 Complexity: Constant time. void splice(const_iterator position, listT,Allocator x, const_iterator i) noexcept; void splice(const_iterator position, listT,Allocator x, const_iterator i) noexcept; 6 Effects: Inserts an element pointed to by i from list x before position and removes the element from x. The result is unchanged if position == i or position == ++i. Pointers and references to *i continue to refer to this same element but as a member of *this. Iterators to *i (including i itself) continue to refer to the same element, but now behave as iterators into *this, not into x. [...] 8 Complexity: Constant time. void splice(const_iterator position, listT,Allocator x, const_iterator first, const_iterator last) noexcept; void splice(const_iterator position, listT,Allocator x, const_iterator first, const_iterator last) noexcept; 9 Effects: Inserts elements in the range [first,last) before position and removes the elements from x. [...] 11 Complexity: Constant time if x == this; otherwise, linear time. [/quote]
[Bug c/49560] -fexec-charset=IBM-1047 makes -Wformat report incorrect warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49560 --- Comment #1 from jphartmann at gmail dot com jphartmann at gmail dot com 2011-06-28 08:25:24 UTC --- This is how the string shows up in the .s: [/home/john/src/cmsh/390] more hlo.s .file hlo.c .section.rodata .LC0: .string \310\226\246\204\250K@@\346\205\210\201\245\205@l\204@\201\231\207\244\224\205\225\243\242% The % sign now represents the newline in the ascii string. The circumvention is to do a dry run with -Wall but without -fexec-charset, so this is not a priority as far as I am concerned.
[Bug fortran/49562] New: [OOP] ICE at invalid code: assigning value to function of polymorphic object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562 Summary: [OOP] ICE at invalid code: assigning value to function of polymorphic object Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: boschm...@tp1.physik.uni-siegen.de CC: ja...@gcc.gnu.org The code: module ice type::ice_type contains procedure::ice_func end type ice_type contains pure integer function ice_func(this) class(ice_type),intent(in)::this ice_func=1 end function ice_func subroutine ice_sub(a) class(ice_type)::a a%ice_func()=1 ! This is the invalid line end subroutine ice_sub end module ice The marked line is obviously not allowed. When I replace class(ice_type)::a by type(ice_type)::a then get a proper error message, but the class statement results in an internal compiler error. My gfortran version is 4.7.0 20110620
[Bug libstdc++/49559] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.06.28 08:41:06
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-28
08:41:06 UTC ---
confirmed, __copy_move_b in stl_algobase.h performs the redundant self-move
this untested change fixes the testcase but I haven't checked if it's correct
or passes the testsuite:
Index: include/bits/stl_algobase.h
===
--- include/bits/stl_algobase.h (revision 175389)
+++ include/bits/stl_algobase.h (working copy)
@@ -541,8 +541,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
static _BI2
__copy_move_b(_BI1 __first, _BI1 __last, _BI2 __result)
{
- typename iterator_traits_BI1::difference_type __n;
- for (__n = __last - __first; __n 0; --__n)
+ typename iterator_traits_BI1::difference_type __n
+ = __last - __first;
+ if (__n = 1)
+ return __first;
+ for (; __n 0; --__n)
*--__result = std::move(*--__last);
return __result;
}
[Bug libstdc++/49561] gcc does not meet the standard for std::list container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-28 08:47:47 UTC --- (In reply to comment #0) I realized that the complexity of std::list::size() is O(n), not O(1). This does not conform to standard. The standard states that size() function is in constant time for alls containers. No, the current standard does not. The C++0x draft does, but it's not yet a standard, and parts of it are not yet implemented.
[Bug c++/49558] Compiling gcc-3.4.5 source code on MAC OS X 10.6.3 gives an error.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49558 Adriaan van Os gcc at microbizz dot nl changed: What|Removed |Added CC||gcc at microbizz dot nl --- Comment #2 from Adriaan van Os gcc at microbizz dot nl 2011-06-28 08:52:47 UTC --- (In reply to comment #0) While compiling gcc-3.4.5 source code on MAC OS X 10.6.3[which has gcc and cc with version i686-apple-darwin10-gcc-4.2.1] gives an error mentioned below. You will find a patched gcc-3.4.6 gcc/gpc compiler at http://www.microbizz.nl/gpc.html that still compiles on Mac OS X 10.6
[Bug libstdc++/49559] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-28 08:56:39 UTC --- bah, that's testing the wrong thing the test should be: if (__result == __last) return __first;
[Bug fortran/49540] [4.6/4.7 Regression] Memory-hog with large DATA stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49540
Adrian Sevcenco adrian.sevcenco at cern dot ch changed:
What|Removed |Added
CC||adrian.sevcenco at cern dot
||ch
--- Comment #8 from Adrian Sevcenco adrian.sevcenco at cern dot ch 2011-06-28
08:59:38 UTC ---
(In reply to comment #7)
(In reply to comment #6)
(In reply to comment #2)
Thus, in some way, the repeat count must come back. One possibility is to
handle the special case /array_size*value/, which is equivalent to
a scalar initialization. I think that should cover the most common case.
IIRC, as implemented the array constructor is completely unrolled, for each
element an entry in the splay tree is generated.
Yes - at least since dropping the repeat count, which your patch did.
One could apply the -fmax-array-constructor=value restrictions used e.g.
for
PARAMETER arrays and do not unroll arrays of size larger than value but
do it
on runtime.
As written, I think it should be sufficient to support the initialization via
a
scalar. In terms of the trans*.c files that already works:
real :: a(3) = 0
thus, there is no reason why one should be able to set sym-value also for
real a(3)
data a/3*0/
That is: If - and only if - one has repeat count == size(array), i.e. a
whole-array initialization, one changes the initialization from:
sym-value = [ ( value, i = 1, repeat count) ]
to
sym-value = value
That should require some reshoveling in the code, but sounds much cleaner as
-fmax-array-constructor= tweaking. Additionally, it will generate much faster
code for data a/1000*0.0/ as it gets translated into static real a =
{}.
so with regard to the initial submission from
https://bugzilla.redhat.com/show_bug.cgi?id=716721
(and code from
http://alisoft.cern.ch/viewvc/trunk/TAmpt/AMPT/hijing1.383_ampt.f?view=markuproot=AliRoot)
do you have some specific (and certain) recommendations in order to make this
scientific code to be compiled (alongside with a lot other fortran scientific
code)?
Thanks
[Bug middle-end/49563] New: Expansion forgets to set MEM_VOLATILE_P for TARGET_MEM_REF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49563 Summary: Expansion forgets to set MEM_VOLATILE_P for TARGET_MEM_REF Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: baldr...@gcc.gnu.org In expr.c, this code if (TREE_THIS_VOLATILE (exp)) MEM_VOLATILE_P (temp) = 1; sets MEM_VOLATILE_P for a volatile MEM_REF. But this is not done for a volatile TARGET_MEM_REF. This doesn't matter right now because tree-ssa-loop-ivopts.c bails out if it sees a volatile memory reference, so volatile TARGET_MEM_REFs don't (yet) occur in the wild.
[Bug ada/49557] Building the GCC compiler suite fails on a Makefile concerning Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49557 --- Comment #2 from Arjen Markus arjen.markus895 at gmail dot com 2011-06-28 09:12:00 UTC --- Hi Eric, thanks for looking into this. If I use an absolute path, then the make command chokes on the lack of a target for configure as required to update config.status. Regards, Arjen 2011/6/28 ebotcazou at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49557 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What |Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed| |2011.06.28 07:27:30 CC| |ebotcazou at gcc dot | |gnu.org Ever Confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-28 07:27:30 UTC --- What happens if you use an absolute path to the configure script instead? -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug target/47997] gcc on macosx: ld: warning: -fwritable-strings not compatible with literal CF/NSString
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997 --- Comment #13 from Iain Sandoe iains at gcc dot gnu.org 2011-06-28 09:16:08 UTC --- Author: iains Date: Tue Jun 28 09:16:04 2011 New Revision: 175578 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175578 Log: PR target/47997 * config/darwin.c (darwin_mergeable_string_section): Place string constants in '.cstring' rather than '.const' when CF/NSStrings are active. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/darwin.c
[Bug target/47997] gcc on macosx: ld: warning: -fwritable-strings not compatible with literal CF/NSString
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Iain Sandoe iains at gcc dot gnu.org 2011-06-28 09:17:47 UTC --- fixed on trunk and 4.6 branch (sorry it took a while to commit the fix).
[Bug middle-end/49563] Expansion forgets to set MEM_VOLATILE_P for TARGET_MEM_REF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49563 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-28 09:18:30 UTC --- It looks like set_mem_attributes () will set it via a similar check.
[Bug tree-optimization/49552] missed optimization: test for zero remainder after division by a constant.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49552 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.28 09:20:40 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-28 09:20:40 UTC --- Confirmed. Is this possible for all constant moduli?
[Bug middle-end/49543] Cast move causes incorrect code and numerical results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49543 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-06-28 09:31:35 UTC --- There is undefined behavior if the overflow occurs, so the upcast is valid.
[Bug ada/49557] Building the GCC compiler suite fails on a Makefile concerning Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49557 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-28 09:32:10 UTC --- thanks for looking into this. If I use an absolute path, then the make command chokes on the lack of a target for configure as required to update config.status. Huh? OK, I presume this is the usual mess with paths on Windows. What version of make do you use? Do you use the -j option?
[Bug ada/49557] Building the GCC compiler suite fails on a Makefile concerning Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49557 --- Comment #4 from Arjen Markus arjen.markus895 at gmail dot com 2011-06-28 09:40:56 UTC --- Hi Eric, I used the path d://configure, perhaps I should have used /d//configure I am using the make utility that comes with MinGW/MSYS: GNU Make 3.81, from 2006. Hm, could that explain it? A rather old version of make? Regards, Arjen 2011/6/28 ebotcazou at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49557 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-28 09:32:10 UTC --- thanks for looking into this. If I use an absolute path, then the make command chokes on the lack of a target for configure as required to update config.status. Huh? OK, I presume this is the usual mess with paths on Windows. What version of make do you use? Do you use the -j option?
[Bug middle-end/49545] [4.7 Regression] New C++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49545 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org | --- Comment #4 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-06-28 09:42:34 UTC --- Sorry for the breakage. I should obviously have tested on x86_64-linux-gnu as well.
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] ICE at invalid code: assigning value to function of polymorphic object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.28 09:43:24 Summary|[OOP] ICE at invalid code: |[4.6/4.7 Regression] [OOP] |assigning value to function |ICE at invalid code: |of polymorphic object |assigning value to function ||of polymorphic object Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2011-06-28 09:43:24 UTC --- In fact this is a regression: With 4.5 one gets the correct error message.
[Bug libstdc++/49559] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jwakely.gcc at gmail dot ||com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28 09:45:22 UTC --- Irrespective of what happens in other functions, I think we want to check at the beginning of stable_sort whether __last - __first 1 and thus avoid the _Temporary_buffer dance otherwise. Then, Jon, I'm not sure to understand what you propose to do, note that __last and __result have different types. Also note that the FDIS is *very* explicit about what move_backward does (+ I see now that we have a typo in the documentation comment: Result may not be in the range (first,last] *not* Result may not be in the range [first,last)
[Bug libstdc++/49559] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.6.2
[Bug libstdc++/49561] [C++0x] std::list::size complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.28 10:08:36 Summary|gcc does not meet the |[C++0x] std::list::size |standard for std::list |complexity |container | Ever Confirmed|0 |1 Severity|major |normal
[Bug bootstrap/49555] libjava fails to configure if --enable-symvers=gnu or --enable-symvers=sun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49555 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC|ro at CeBiTec dot |ro at gcc dot gnu.org |Uni-Bielefeld.DE, ro at | |techfak dot | |uni-bielefeld.de| Target Milestone|--- |4.7.0 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2011-06-28 10:20:50 UTC --- Please provide a bit mor information: * what platform are you on? * what are your configure options? * why do you insist on specifying the symvers flavor manually?
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||chris at bubblescope dot
||net
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28
10:41:20 UTC ---
So, I added a:
Index: util/testsuite_rvalref.h
===
--- util/testsuite_rvalref.h(revision 175578)
+++ util/testsuite_rvalref.h(working copy)
@@ -68,6 +68,7 @@
operator=(rvalstruct in)
{
bool test __attribute__((unused)) = true;
+ VERIFY( this != in );
VERIFY( in.valid == true );
val = in.val;
in.valid = false;
and got fails for the 25_algorithms/inplace_merge/moveable.cc tests.
Chris, are you willing to have a look? I seem to remember that you did a lot of
work in this area...
I'm not seeing other fails, luckily.
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-28 10:45:11 UTC --- (In reply to comment #3) note that the FDIS is *very* explicit about what move_backward does Ah ok - but if move_backward has to do that then we should avoid calling it at all when nothing needs to move, maybe in __move_merge_backward
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28 10:56:50 UTC --- Maybe, yes. I'm going to attaching as a draft patch what I have so far, if you could coordinate with Chris and complete it, would be great...
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28 10:58:09 UTC --- Created attachment 24613 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24613 Draft patch. inplace_merge still needs work.
[Bug c/49560] -fexec-charset=IBM-1047 makes -Wformat report incorrect warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49560 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-06-28 11:03:03 UTC --- Duplicate. *** This bug has been marked as a duplicate of bug 20110 ***
[Bug c/20110] format checking and non-ASCII character sets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20110 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added CC||jphartmann at gmail dot com --- Comment #2 from Joseph S. Myers jsm28 at gcc dot gnu.org 2011-06-28 11:03:03 UTC --- *** Bug 49560 has been marked as a duplicate of this bug. ***
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] ICE at invalid code: assigning value to function of polymorphic object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562
--- Comment #2 from janus at gcc dot gnu.org 2011-06-28 11:05:08 UTC ---
The fix is pretty trivial:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 175562)
+++ gcc/fortran/expr.c(working copy)
@@ -4395,7 +4395,7 @@ gfc_check_vardef_context (gfc_expr* e, bool pointe
}
if (!pointer e-expr_type == EXPR_FUNCTION
- sym-result-attr.pointer)
+ sym-result sym-result-attr.pointer)
{
if (!(gfc_option.allow_std GFC_STD_F2008))
{
With this one gets:
a%ice_func()=1 ! This is the invalid line
1
Error: Non-variable expression in variable definition context (assignment) at
(1)
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] ICE at invalid code: assigning value to function of polymorphic object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #3 from janus at gcc dot gnu.org 2011-06-28 11:06:29 UTC --- Also: Mine. [Will commit as obvious after regtesting.]
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] ICE at invalid code: assigning value to function of polymorphic object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562 --- Comment #4 from janus at gcc dot gnu.org 2011-06-28 11:18:47 UTC --- For the record: The regression is probably due to r165749: http://gcc.gnu.org/viewcvs?view=revisionrevision=165749
[Bug middle-end/29274] [4.4/4.5 Regression] not using mulsidi3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29274 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.4.7 |4.6.0
[Bug ada/49557] Building the GCC compiler suite fails on a Makefile concerning Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49557 --- Comment #5 from Arjen Markus arjen.markus895 at gmail dot com 2011-06-28 11:45:17 UTC --- When I remove the directories libada and gcc/ada to prevent make from attempting to build Ada, the build process fails on a missing % for a pattern in gcc/cp/Make-lang.in.
[Bug pch/49435] get_z.c:46: MPFR assertion failed: exp 0 || exp = ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49435 --- Comment #6 from Valery longvalery at gmail dot com 2011-06-28 11:59:52 UTC --- Created attachment 24614 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24614 Please. But In ZIP only
[Bug pch/49435] get_z.c:46: MPFR assertion failed: exp 0 || exp = ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49435 --- Comment #7 from Valery longvalery at gmail dot com 2011-06-28 12:03:29 UTC --- Created attachment 24615 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24615 I thing that my problem is here If I comment body of two functions float_16_to_32() and float_24_to_32 compiler work without any error
[Bug pch/49435] get_z.c:46: MPFR assertion failed: exp 0 || exp = ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)1))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49435 --- Comment #8 from Valery longvalery at gmail dot com 2011-06-28 12:04:36 UTC --- Created attachment 24616 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24616 I thing that my problem is here (2) If I comment body of function float_32_to_16 compiler work without any error
[Bug target/48273] [4.6 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273 --- Comment #10 from Alexander Monakov amonakov at gcc dot gnu.org 2011-06-28 12:19:23 UTC --- Author: amonakov Date: Tue Jun 28 12:19:18 2011 New Revision: 175581 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175581 Log: Backport from mainline 2011-04-08 Alexander Monakov amona...@ispras.ru PR target/48273 * cfgloop.h (loop_has_exit_edges): New helper. * sel-sched-ir.c (init_global_and_expr_for_insn): Make CALLs non-clonable. * sel-sched.c (sel_setup_region_sched_flags): Don't pipeline loops that have no exit edges. * g++.dg/opt/pr48273.C: New. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/opt/pr48273.C Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/cfgloop.h branches/gcc-4_6-branch/gcc/sel-sched-ir.c branches/gcc-4_6-branch/gcc/sel-sched.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/49540] [4.6/4.7 Regression] Memory-hog with large DATA stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49540 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-28 12:20:41 UTC --- (In reply to comment #8) do you have some specific (and certain) recommendations in order to make this scientific code to be compiled (alongside with a lot other fortran scientific code)? As short term solution: Use an older version of gfortran (before 4.6.0-2010-05-05) - or remove the 0 initialization. While the Fortran standard does not guarantee it, in practice, static memory should nevertheless be zero initialized (.bss). The proper fix will take a bit longer: A couple of days for the fix and then it will likely also take a while until a Red Hat/Fedora build will be available. (Though, non-Fedora nightly builds will have it earlier.) * * * (In reply to comment #7) As written, I think it should be sufficient to support the initialization via a scalar. For what it is worth: Intel's compiler seem to do the same. Hence, DATA B/repeat*value/ is is very fast while using DATA B(:)/repeat*value/ is very slow - even though, both lines are effectively the same.
[Bug target/48273] [4.6 Regression] ICE: in create_copy_of_insn_rtx, at sel-sched-ir.c:5604 with -fsel-sched-pipelining -fselective-scheduling2 -march=core2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48273 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from Alexander Monakov amonakov at gcc dot gnu.org 2011-06-28 12:21:27 UTC --- Fixed.
[Bug tree-optimization/49552] missed optimization: test for zero remainder after division by a constant.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49552 --- Comment #2 from Wouter Vermaelen wouter.vermaelen at scarlet dot be 2011-06-28 12:22:11 UTC --- Confirmed. Is this possible for all constant moduli? It is. I recommend you get a copy of the book I mentioned before. The theory behind the transformation is much better explained there than I could ever do here. But I'll try to give a recipe to construct the routine for a specific constant: (all examples are for 32-bit, but it should be easy enough to generalize) There are 3 different cases: (x % C) == 0 * 'x' is unsigned, 'C' is odd: return (x * Cinv) = (0x / C); Where Cinv is the multiplicative inverse of C (C * Cinv = 1 (modulo pow(2, 32))). Cinv is the same 'magic number' as is used to optimize exact-division (division where it's known that the remainder will be zero). * 'x' is unsigned, 'C' is even: Split 'C' in an odd factor and a power of two. C = Codd * Ceven where Ceven = pow(2, k) Now we test that 'x' is both divisible by 'Codd' and 'Ceven'. return !(x (Ceven - 1)) ((x * Codd_inv) = (0x / Codd)) When a rotate-right instruction is available, the expression above can be rewritten so that it only requires one test: return rotateRight(x * Codd_inv, k) = (0x / C); // unsigned comparison * 'x' is signed, (C can be odd or even) (I admit, I don't fully understand the theory behind this transformation, so I'll only give the final result). constexpr unsigned A = (0x7fff / Codd) -(1 k); constexpr unsigned B = k ? (A (k - 1)) : (A 1); return rotateRight((x * Codd_inv) + A, k) = B; // unsigned comparison
[Bug rtl-optimization/49014] [4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7132 with even more insane set of flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49014 --- Comment #6 from Andrey Belevantsev abel at gcc dot gnu.org 2011-06-28 12:46:37 UTC --- Author: abel Date: Tue Jun 28 12:46:34 2011 New Revision: 175582 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175582 Log: Backport from mainline 2011-05-25 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/49014 * config/i386/athlon.md (athlon_ssecomi): Change type to ssecomi. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/i386/athlon.md
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] assigning value to type-bound function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562 janus at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Summary|[4.6/4.7 Regression] [OOP] |[4.6/4.7 Regression] [OOP] |ICE-on-invalid: assigning |assigning value to |value to type-bound |type-bound function |function| --- Comment #5 from janus at gcc dot gnu.org 2011-06-28 12:52:58 UTC --- Note: You can get the same ICE on *valid* code, if you give the return value of 'ice_func' the POINTER attribute (allowed by F08): module ice type::ice_type contains procedure::ice_func end type ice_type contains pure function ice_func(this) integer, pointer :: ice_func class(ice_type),intent(in)::this ice_func=1 end function ice_func subroutine ice_sub(a) class(ice_type)::a a%ice_func()=1 ! This is valid now end subroutine ice_sub end module ice Unfortunately this test case is rejected with the patch in comment #2.
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] assigning value to type-bound function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562
--- Comment #6 from janus at gcc dot gnu.org 2011-06-28 12:59:20 UTC ---
(In reply to comment #5)
Unfortunately this test case is rejected with the patch in comment #2.
However, it is accepted with this improved patch:
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c(revision 175580)
+++ gcc/fortran/expr.c(working copy)
@@ -4394,8 +4394,8 @@ gfc_check_vardef_context (gfc_expr* e, bool pointe
sym = e-value.function.esym ? e-value.function.esym :
e-symtree-n.sym;
}
- if (!pointer e-expr_type == EXPR_FUNCTION
- sym-result-attr.pointer)
+ attr = gfc_expr_attr (e);
+ if (!pointer e-expr_type == EXPR_FUNCTION attr.pointer)
{
if (!(gfc_option.allow_std GFC_STD_F2008))
{
@@ -4432,7 +4432,6 @@ gfc_check_vardef_context (gfc_expr* e, bool pointe
/* Find out whether the expr is a pointer; this also means following
component references to the last one. */
- attr = gfc_expr_attr (e);
is_pointer = (attr.pointer || attr.proc_pointer);
if (pointer !is_pointer)
{
[Bug middle-end/49545] [4.7 Regression] New C++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49545 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-06-28 13:07:34 UTC --- yup, cris-elf (non-strict-alignment) too...
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28 13:38:06 UTC --- For inplace_merge the problem happens with the _GLIBCXX_MOVE3 calls in __move_merge, at some point __first == __result != __last.
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28 14:11:32 UTC --- Given the specific instantiations we have of __move_merge, something like the new draft I'm attaching seems correct and avoids the regressions for inplace_merge. But actually it seems __first2 always == __result after the first move, thus I think we really want to rework and possibly simplify these __move_merge helpers.
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28 14:12:36 UTC --- Created attachment 24617 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24617 New draft
[Bug c/19541] need another option to support what -I- did just besides -iquote
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19541 David Rosa jdrosa at yahoo dot com changed: What|Removed |Added CC||jdrosa at yahoo dot com --- Comment #21 from David Rosa jdrosa at yahoo dot com 2011-06-28 14:14:37 UTC --- I want to add my voice to others who have asked that the priority of this bug be elevated to P2. Eliminating the secondary function of -I- as quoted from the GNU preprocessor documentation is unacceptable. Second, the directory containing the current file is not searched for anything, unless it happens to be one of the directories named by an -I switch. Even if a different switch is used, like the -ignore-source-dir I've heard some rumblings about, can this issue please be elevated in priority and addressed soon? For our code base, we utilize gcc along with commercial cross-compilers. All of the cross-compilers we use support an option that implements the original -I- behavior and in order to maintain our existing code base, we either -I- to no longer be deprecated or replaced with a different option that implements the same behavior.
[Bug c++/49538] Revision 175341 causes segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49538 --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-06-28 14:49:18 UTC --- Created attachment 24618 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24618 fix logical thinko This patch fixes the issue. It was a simple logical thinko. It also fixes Bug 49533.
[Bug other/49533] Firefox profiled build issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533 --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-06-28 14:51:15 UTC --- The patch attached to Bug 49538 fixes this problem.
[Bug target/49564] New: [cppcheck][patch] fixed resource and memory leaks in /gcc/gcc/config/alpha/host-osf.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49564 Summary: [cppcheck][patch] fixed resource and memory leaks in /gcc/gcc/config/alpha/host-osf.c Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ettl.mar...@gmx.de Created attachment 24619 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24619 proposed patch to fix the issues cppcheck revealed two resource leaks and a memory leak in /gcc/gcc/config/alpha/host-osf.c. Please refer the attached patch that fixed the issues. Best regards from the cppcheck team Martin
[Bug fortran/40054] [F08] Pointer functions as lvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40054 --- Comment #4 from janus at gcc dot gnu.org 2011-06-28 15:49:54 UTC --- cf. also PR 49562
[Bug fortran/49565] New: character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49565 Summary: character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tro...@gcc.gnu.org I compiled this program with svn trunk gfortran. I used -gdwarf-4 -g. character(kind=4) :: c character(kind=4,len=5) :: str c = 4_'\u00AE' str = 4_'\u00AE\u01DD' open(6,encoding='utf-8') print *, c print *, str end Then I examined the DWARF. 'c' is ultimately of type: 1cf: Abbrev Number: 7 (DW_TAG_base_type) d0 DW_AT_byte_size : 4 d1 DW_AT_encoding: 7(unsigned) d2 DW_AT_name: (indirect string, offset: 0x67): character(kind=4) I think the encoding should be DW_ATE_unsigned_char instead.
[Bug fortran/49565] character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49565
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-28
16:07:33 UTC ---
From gcc/dwarf2out.c's base_type_die:
if (TYPE_STRING_FLAG (type))
{
if (TYPE_UNSIGNED (type))
encoding = DW_ATE_unsigned_char;
which should set it. However, there is also in gen_array_type_die the following
code:
/* Emit DW_TAG_string_type for Fortran character types (with kind 1 only, as
DW_TAG_string_type doesn't have DW_AT_type attribute). */
if (TYPE_STRING_FLAG (type)
TREE_CODE (type) == ARRAY_TYPE
is_fortran ()
TYPE_MODE (TREE_TYPE (type)) == TYPE_MODE (char_type_node))
That has been added by Jakub's commit Rev. 139778:
http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=cdba1d8f465a94f6f654bcc33a7663913df2181e;hp=98923a8420e5399f31613d93ebee61e63f2d36e1
Sumitted patch was http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01680.html
[Bug fortran/49566] New: [DWARF/DEBUG] Add coarray shapes (codimensions) to the debug output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49566 Summary: [DWARF/DEBUG] Add coarray shapes (codimensions) to the debug output Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Blocks: 24546 There is an open extension request for the DWARF to handle Coshape of Coarrays in Fortran 2008. This is a tracking bug for gfortran http://www.dwarfstd.org/ShowIssue.php?issue=090824.1type=open (gfortran already supports coarrays.)
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Attachment #24617|0 |1 is obsolete|| --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28 16:22:05 UTC --- Comment on attachment 24617 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24617 New draft Never mind the last patch, isn't ok for stable_sort etc.
[Bug java/49556] The import A cannot be resolved，But the A is placed at the current dir.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49556 --- Comment #2 from licheng.1212 at gmail dot com licheng.1212 at gmail dot com 2011-06-28 16:25:21 UTC --- (In reply to comment #1) I think this is correct as classes in the same packages don't cannot be imported. yes,you are right!Please close this bug
[Bug fortran/49565] character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49565
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-28
16:45:35 UTC ---
There are two issues:
a) The one mentioned by Jakub for the committal cited in comment 1
That seems to be a DWARF bug - and Tromey has now filled an issue; it
should
show up in a while at http://www.dwarfstd.org/Issues.php
The problem is that DW_TAG_string_type does not support DW_AT_type,
which makes it not suitable for character(kind=4) [as it already has to
handle character(kind=1)].
b) Independent of that issue, GCC should emit DW_ATE_unsigned_char and not
DW_ATE_unsigned
The latter issue seems to come due to the following code in gen_array_type_die:
if (TYPE_STRING_FLAG (type)
/* Case handling kind=1 characters. */
{
...
return;
}
...
/* For Fortran multidimensional arrays use DW_ORD_col_major ordering. */
if (is_fortran ()
TREE_CODE (type) == ARRAY_TYPE
TREE_CODE (TREE_TYPE (type)) == ARRAY_TYPE
!TYPE_STRING_FLAG (TREE_TYPE (type)))
add_AT_unsigned (array_die, DW_AT_ordering, DW_ORD_col_major);
This test is true as:
(gdb) p type-type_common.string_flag
$6 = 1
(gdb) p type-typed.type-type_common.string_flag
$7 = 0
I wonder whether the
!TYPE_STRING_FLAG (TREE_TYPE (type)))
shouldn't be instead a
!TYPE_STRING_FLAG (type))
Or alternatively, whether fortran/trans-type.c's
gfc_get_character_type_len_for_eltype should not only set
TYPE_STRING_FLAG (type) = 1;
but also
TYPE_STRING_FLAG (TREE_TYPE (type)) = 1;
[Bug fortran/49565] character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49565 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-28 16:55:16 UTC --- (In reply to comment #2) /* For Fortran multidimensional arrays use DW_ORD_col_major ordering. */ if (is_fortran () TREE_CODE (type) == ARRAY_TYPE TREE_CODE (TREE_TYPE (type)) == ARRAY_TYPE !TYPE_STRING_FLAG (TREE_TYPE (type))) add_AT_unsigned (array_die, DW_AT_ordering, DW_ORD_col_major); It's too warm to think poperly: TREE_CODE (type) is ARRAY_TYPE but TREE_CODE(TREE_TYPE(type)) is INTEGER_TYPE - not an ARRAY_TYPE; hence the code is never executed. Nevertheless, the issue is presumably related to type having TYPE_STRING_FLAG set, but TREE_TYPE(type) having it not.
[Bug debug/49567] New: [4.7 Regression] ICE in mem_loc_descriptor due to typed DWARF stack changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49567
Summary: [4.7 Regression] ICE in mem_loc_descriptor due to
typed DWARF stack changes
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: debug
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
/* { dg-do compile } */
/* { dg-options -g -O2 -msse4 } */
#include x86intrin.h
__m128
foo (__m128i x)
{
__m128i y;
y = _mm_cvtepi16_epi32 (x);
return _mm_cvtepi32_ps (y);
}
ICEs in mem_loc_descriptor, as we are asserting SIGN_EXTEND/ZERO_EXTEND will
have integral mode, while it has vector mode here.
[Bug debug/49567] [4.7 Regression] ICE in mem_loc_descriptor due to typed DWARF stack changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49567 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.28 17:01:27 Known to work||4.6.1 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 Known to fail||4.7.0
[Bug debug/49567] [4.7 Regression] ICE in mem_loc_descriptor due to typed DWARF stack changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49567 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-28 17:05:55 UTC --- Created attachment 24620 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24620 gcc47-pr49567.patch Untested fix.
[Bug c++/49568] New: [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49568 Summary: [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: link-failure Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Host: alpha-dec-osf5.1b Target: alpha-dec-osf5.1b Build: alpha-dec-osf5.1b Between 20110502 and 20110518, g++.dg/torture/pr41257-2.C started to FAIL on Tru64 UNIX: A::~A() typeinfo for A collect2: error: ld returned 1 exit status which is a link error (undefined symbols). This is a regression from the 4.6 branch. While the input file is identical, the generated code is far longer on mainline, and contains a call to an undefined function _ZN1AD2Ev (A::~A()). This may be related to the fact that Tru64 UNIX doesn't support weak definitions, but the code is plain wrong. I'm attaching assembler output from 4.6 and 4.7.
[Bug c++/49568] [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49568 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2011-06-28 17:39:00 UTC --- Created attachment 24622 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24622 gcc 4.7 assembler output at -O0
[Bug c++/49568] [4.7 regression] g++.dg/torture/pr41257-2.C FAILs to link on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49568 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-06-28 17:38:31 UTC --- Created attachment 24621 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24621 gcc 4.6 assembler output at -O0
[Bug bootstrap/49557] make chokes on various Makefile constructs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49557 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Component|ada |bootstrap Host||i686-pc-mingw32 Summary|Building the GCC compiler |make chokes on various |suite fails on a Makefile |Makefile constructs |concerning Ada | --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-28 17:42:18 UTC --- When I remove the directories libada and gcc/ada to prevent make from attempting to build Ada, the build process fails on a missing % for a pattern in gcc/cp/Make-lang.in. Needless to say that you aren't expected to run into this kind of problems on a decent host. The GNU make version is OK. You'd probably better reach out to the MinGW folks and see what they have to say about this.
[Bug ada/49511] [4.6 Regression] acats test setup fails on HP-UX using posix shell
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49511
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-06-28 17:58:01 UTC ---
505 (hiauly1)dave /bin/sh
$ type -p gnatmake 2/dev/null
gnatmake is /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake
$ echo $?
0
Drats, sh silently ignores -p. The following (untested) patch should
cope with this:
diff --git a/gcc/testsuite/ada/acats/run_acats
b/gcc/testsuite/ada/acats/run_acats
--- a/gcc/testsuite/ada/acats/run_acats
+++ b/gcc/testsuite/ada/acats/run_acats
@@ -10,11 +10,11 @@ fi
# type -p is missing from Solaris 2 /bin/sh and /bin/ksh (ksh88), but both
# ksh93 and bash have it.
# type output format differs between ksh88 and ksh93, so avoid it if
-# type -p is present.
+# type -p is present. Unfortunately, HP-UX 10 /bin/sh ignores -p with type.
# Fall back to whence which ksh88 and ksh93 provide, but bash does not.
which () {
-path=`type -p $* 2/dev/null` { echo $path; return 0; }
+path=`type -p $* 2/dev/null | awk '{print $NF}` { echo $path; return
0; }
path=`type $* 2/dev/null | awk '{print $NF}'` { echo $path; return 0;
}
path=`whence $* 2/dev/null` { echo $path; return 0; }
return 1
Could you give it a try?
Thanks.
Rainer
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559
--- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28
18:06:54 UTC ---
I'm looking at __merge_adaptive and it seems to me that self move assignment
can happen very generically. Consider:
if (__len1 = __len2 __len1 = __buffer_size)
{
_Pointer __buffer_end = _GLIBCXX_MOVE3(__first, __middle, __buffer);
std::__move_merge(__buffer, __buffer_end, __middle, __last, __first);
}
here __first comes in memory before __middle and when __move_merge has filled
all the positions before __middle then any element can be move assigned from
itself. Of course we could always move to the buffer the entire range __first,
__last. Still looking for Chris' opinion on this, he updated this code to move
instead of copy...
[Bug bootstrap/49555] libjava fails to configure if --enable-symvers=gnu or --enable-symvers=sun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49555 Bryan Hundven bryanhundven at gmail dot com changed: What|Removed |Added Target||x86_64-unknown-linux-gnu Host||i686-unknown-linux-gnu Build||i686-unknown-linux-gnu --- Comment #3 from Bryan Hundven bryanhundven at gmail dot com 2011-06-28 18:18:33 UTC --- (In reply to comment #2) Please provide a bit mor information: * what platform are you on? It happens on every platform I configure, but if you want something specific: --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu --target=x86_64-unknown-linux-gnu I also have the same problems on: --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu --target=mips64-unknown-linux-gnu and: --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-unknown-linux-gnuspe This is a build from crosstool-ng. --enable-symvers=gnu is set staticly in: http://crosstool-ng.org/hg/crosstool-ng/file/tip/scripts/build/cc/gcc.sh * what are your configure options? --enable-languages=c,c++,fortran,objc,obj-c++ --disable-multilib --with-tune=core2 --with-pkgversion=crosstool-NG hg_unknown@20110627.135200 --disable-sjlj-exceptions --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-mpfr=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-mpc=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-ppl=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-cloog=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-libelf=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++ -lm -L/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static/lib -lpwl --enable-threads=posix --enable-target-optspace --disable-libstdcxx-pch --with-long-double-128 --enable-gold * why do you insist on specifying the symvers flavor manually? I didn't insist on specifying it manually. crosstool-ng did. While you might say that is a problem with crosstool-ng, but the older crosstool and other cross tool scripts use this as well. If every other component besides libjava specifically check for yes|no|gnu*|sun, why doesn't libjava? Or... If I shouldn't use --enable-symvers=gnu, shouldn't all other components fail to support it?
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #17 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-28 18:26:26 UTC --- Instead of defining CHAR16_TYPE, I think it's preferred to define UINT_LEAST16_TYPE appropriately and use logic in defaults.h so that defaults.h need not to be changed. CHAR16_TYPE is not used in many places, and it appears that defaults.h is included after tm.h. UINT_LEAST16_TYPE comes from config/newlib-stdint.h which is merged into avr headers in config.gcc. So a fix inside AVR sandbox could be: A) Include a new file, say avr/stdint.h, instead of newlib-stdint.h. or B) Include newlib-stdint.h prior to avr.h and override as needed. IMO A) is best because almost anything will have to be overwritten to render -min8 functional again. Moreover, note independant of this PR, that newlib-stdint.h makes some definitions that are not correct for AVR like #define SIG_ATOMIC_TYPE int // should be char for AVR So it's desired to have AVR-specific stdint.h, anyway. The major drawback of -mint8 is that it's not covered by the testsuite at all -- like most other AVR gadgets (ISR, progmem, ...) If maintainers are willing to support this, I am sure someone will supply according patch. Johann
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #18 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-28 18:34:54 UTC --- (In reply to comment #17) A) Include a new file, say avr/stdint.h, instead of newlib-stdint.h. or B) Include newlib-stdint.h prior to avr.h and override as needed. or C) Omit newlib-stdint.h altogether and to the defines in avr.h. C) and A) are better than B) Johann
[Bug ada/49511] [4.6 Regression] acats test setup fails on HP-UX using posix shell
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49511
--- Comment #4 from dave at hiauly1 dot hia.nrc.ca 2011-06-28 18:46:19 UTC ---
On Tue, 28 Jun 2011, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49511
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-06-28 17:58:01 UTC ---
505 (hiauly1)dave /bin/sh
$ type -p gnatmake 2/dev/null
gnatmake is /opt/gnu/gcc/gcc-3.3.4/bin/gnatmake
$ echo $?
0
Drats, sh silently ignores -p. The following (untested) patch should
cope with this:
Could you give it a try?
The following revised patch works. There was a missing quote and
the problem also affects HP-UX 11. I just never hit it since I always
build with bash.
Index: ada/acats/run_acats
===
--- ada/acats/run_acats(revision 175188)
+++ ada/acats/run_acats(working copy)
@@ -10,11 +10,11 @@
# type -p is missing from Solaris 2 /bin/sh and /bin/ksh (ksh88), but both
# ksh93 and bash have it.
# type output format differs between ksh88 and ksh93, so avoid it if
-# type -p is present.
+# type -p is present. Unfortunately, HP-UX /bin/sh ignores -p with type.
# Fall back to whence which ksh88 and ksh93 provide, but bash does not.
which () {
-path=`type -p $* 2/dev/null` { echo $path; return 0; }
+path=`type -p $* 2/dev/null | awk '{print $NF}'` { echo $path; return
0; }
path=`type $* 2/dev/null | awk '{print $NF}'` { echo $path; return 0;
}
path=`whence $* 2/dev/null` { echo $path; return 0; }
return 1
Thanks,
Dave
[Bug fortran/49479] [4.6/4.7 Regression] reshape / optionals / zero sized arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49479 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-06-28 18:59:06 UTC --- Author: tkoenig Date: Tue Jun 28 18:59:04 2011 New Revision: 175594 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175594 Log: 2011-06-28 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/49479 * m4/reshape.m4: If source allocation is smaller than one, set it to one. * intrinsics/reshape_generic.c: Likewise. * generated/reshape_r16.c: Regenerated. * generated/reshape_c4.c: Regenerated. * generated/reshape_c16.c: Regenerated. * generated/reshape_c8.c: Regenerated. * generated/reshape_r4.c: Regenerated. * generated/reshape_i4.c: Regenerated. * generated/reshape_r10.c: Regenerated. * generated/reshape_r8.c: Regenerated. * generated/reshape_c10.c: Regenerated. * generated/reshape_i8.c: Regenerated. * generated/reshape_i16.c: Regenerated. 2011-06-28 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/49479 * gfortran.dg/reshape_zerosize_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/reshape_zerosize_3.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/generated/reshape_c10.c trunk/libgfortran/generated/reshape_c16.c trunk/libgfortran/generated/reshape_c4.c trunk/libgfortran/generated/reshape_c8.c trunk/libgfortran/generated/reshape_i16.c trunk/libgfortran/generated/reshape_i4.c trunk/libgfortran/generated/reshape_i8.c trunk/libgfortran/generated/reshape_r10.c trunk/libgfortran/generated/reshape_r16.c trunk/libgfortran/generated/reshape_r4.c trunk/libgfortran/generated/reshape_r8.c trunk/libgfortran/intrinsics/reshape_generic.c trunk/libgfortran/m4/reshape.m4
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #19 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-06-28 19:05:00 UTC --- On Tue, 28 Jun 2011, gjl at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #18 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-06-28 18:34:54 UTC --- (In reply to comment #17) A) Include a new file, say avr/stdint.h, instead of newlib-stdint.h. or B) Include newlib-stdint.h prior to avr.h and override as needed. or C) Omit newlib-stdint.h altogether and to the defines in avr.h. C) and A) are better than B) Indeed, I simply made all bare-metal targets use newlib-stdint.h as a default, but since AVR has its own libc it seems more appropriate to put the defines in avr-stdint.h or avr.h and not use newlib-stdint.h. (And the point of having separate headers such as newlib-stdint.h is that there may not otherwise be a header shared between all relevant targets. If all AVR targets use avr-libc, putting the defines in avr.h makes sense, but if avr-rtems is using newlib like other RTEMS targets then you probably want a separate header only for AVR targets using avr-libc.)
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #13 from Chris Jefferson chris at bubblescope dot net 2011-06-28 19:16:00 UTC --- I am on holiday until tomorrow night, and away from a computer. Once I get back, I promise to give this my full attention. This code got messy in the first place because I was trying to make minimal changes to already confusing code. I still see if this can be easily cleaned, our if we should use a different method.
[Bug c++/49569] New: -std=gnu++0x causes segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49569 Summary: -std=gnu++0x causes segmentation fault Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 24623 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24623 gzipped C++ source code I just tried to compile the pokerth-0.8.3-6.fc16 package with the latest trunk snapshot 20110625 on an AMD x86_64 box. The compiler said ./include/c++/4.7.0/bits/stl_pair.h:137:45: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gdb says Program received signal SIGSEGV, Segmentation fault. iterative_hash (k_in=optimized out, length=optimized out, initval=optimized out) at ../../src/gcc-4.7-20110625/libiberty/hashtab.c:981 981 case 4 : a+=((hashval_t)k[3]24); Missing separate debuginfos, use: debuginfo-install glibc-2.13.90-13.x86_64 gmp-4.3.2-3.fc15.x86_64 mpfr-3.0.0-4.fc15.x86_64 (gdb) p k $1 = (const unsigned char *) 0x8 Address 0x8 out of bounds Preprocessed source code attached. Flag -std=gnu++0x required.
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28 19:38:47 UTC --- Thanks Chris, I appreciate that, I know I can always count on you. Actually, I will be on vacation for a few days starting tomorrow, but I will bring the laptop will be and will be able to provide feedback and all due attention to your work. I'm thinking, we could also prepare two different fixes: one minimally invasive for 4.6.2 and another more invasive for 4.7. At the moment, I'm under the impression that a proper fix involves massaging __merge_adaptive quite a bit...
[Bug c++/49570] New: /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49570 Summary: /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ansa...@babcock.com I upgraded v. 4.6.0 from sources on a RHEL 5.5 system. Previously I had v. 4.1.2. I get the following error when using the icc compiler which I did not have before: icc -g -O0 -DERR_DEBUG -Wall -wd177,1572 -I. -I/opt/hpmpi/include -DDOMAIN_DECOMP_SUPPORTED -DNO_TIMEDATA -DMP_MPI -c ../../src/adapt/tregstr.cpp /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed const bool __simple = (__is_trivial(_ValueTypeI) ^ detected during: instantiation of _OI std::__copy_move_a2_IsMove,_II,_OI(_II, _II, _OI) [with _IsMove=false, _II=__gnu_cxx::__normal_iteratorBv **, std::vectorBv *, std::allocatorBv *, _OI=__gnu_cxx::__normal_iteratorBv **, std::vectorBv *, std::allocatorBv *] at line 454 instantiation of _OI std::copy(_II, _II, _OI) [with _II=__gnu_cxx::__normal_iteratorBv **, std::vectorBv *, std::allocatorBv *, _OI=__gnu_cxx::__normal_iteratorBv **, std::vectorBv *, std::allocatorBv *] at line 139 of /usr/include/c++/4.6.0/bits/vector.tcc instantiation of __gnu_cxx::__normal_iteratorstd::_Vector_base_Tp, _Alloc::_Tp_alloc_type::pointer, std::vector_Tp, _Alloc std::vector_Tp, _Alloc::erase(__gnu_cxx::__normal_iteratorstd::_Vector_base_Tp, _Alloc::_Tp_alloc_type::pointer, std::vector_Tp, _Alloc) [with _Tp=Bv *, _Alloc=std::allocatorBv *] at line 462 of ./bvlist.h /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: identifier __is_trivial is undefined const bool __simple = (__is_trivial(_ValueTypeI) ^ detected during: instantiation of _OI std::__copy_move_a2_IsMove,_II,_OI(_II, _II, _OI) [with _IsMove=false, _II=__gnu_cxx::__normal_iteratorBv **, std::vectorBv *, std::allocatorBv *, _OI=__gnu_cxx::__normal_iteratorBv **, std::vectorBv *, std::allocatorBv *] at line 454 instantiation of _OI std::copy(_II, _II, _OI) [with _II=__gnu_cxx::__normal_iteratorBv **, std::vectorBv *, std::allocatorBv *, _OI=__gnu_cxx::__normal_iteratorBv **, std::vectorBv *, std::allocatorBv *] at line 139 of /usr/include/c++/4.6.0/bits/vector.tcc instantiation of __gnu_cxx::__normal_iteratorstd::_Vector_base_Tp, _Alloc::_Tp_alloc_type::pointer, std::vector_Tp, _Alloc std::vector_Tp, _Alloc::erase(__gnu_cxx::__normal_iteratorstd::_Vector_base_Tp, _Alloc::_Tp_alloc_type::pointer, std::vector_Tp, _Alloc) [with _Tp=Bv *, _Alloc=std::allocatorBv *] at line 462 of ./bvlist.h compilation aborted for ../../src/adapt/tregstr.cpp (code 2) line 462 of bvlist.h is erasing telements from a vector continer list : this-list.erase(this-list.begin()+i);
[Bug c++/49570] /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49570 --- Comment #1 from Alan N. Sayre ansayre at babcock dot com 2011-06-28 20:28:52 UTC --- [ansayre@blgwap02 trunk]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --prefix=/usr --with-mpc=/usr --with-mpfr=/usr --wi th-gmp=/usr --with-ppl=/usr --with-cloog=/usr Thread model: posix gcc version 4.6.0 (GCC) [ansayre@blgwap02 trunk]$
[Bug c++/49570] /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49570 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28 20:29:23 UTC --- Report the problem to Intel.
[Bug c++/49538] Revision 175341 causes segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49538
--- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-06-28 20:32:14 UTC ---
Haha, that patch doesn't work. It's identical to:
#if 0
if (!in_charge_parm_used
fns[0]
idx == 1
!flag_use_repository
DECL_INTERFACE_KNOWN (fns[0])
(SUPPORTS_ONE_ONLY || !DECL_WEAK (fns[0]))
(!DECL_ONE_ONLY (fns[0])
|| (HAVE_COMDAT_GROUP
DECL_WEAK (fns[0])))
(flag_syntax_only
/* Set linkage flags appropriately before
cgraph_create_function_alias looks at them. */
(expand_or_defer_fn_1 (clone)
|| cgraph_same_body_alias (cgraph_get_node (fns[0]),
clone, fns[0]
{
alias = true;
if (DECL_ONE_ONLY (fns[0]))
{
/* For comdat base and complete cdtors put them
into the same, *[CD]5* comdat group instead of
*[CD][12]*. */
comdat_group = cdtor_comdat_group (fns[1], fns[0]);
DECL_COMDAT_GROUP (fns[0]) = comdat_group;
}
}
#endif
So back to square one. But everything points to commit c70f46b057cd12973:
Author: hubicka
Date: Sat Jun 11 13:01:53 2011 +
* lto-symtab.c (lto_cgraph_replace_node): Kill same body alias code.
(lto_symtab_resolve_can_prevail_p): Likewise.
...
[Bug c++/49570] /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49570 --- Comment #3 from Alan N. Sayre ansayre at babcock dot com 2011-06-28 20:35:13 UTC --- I disagree with your assessment. The C++ header files should not depend on internal compiler flags. Why is this Intel's problem. -Original Message- From: paolo.carlini at oracle dot com [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Tuesday, June 28, 2011 4:30 PM To: Sayre, Alan N Subject: [Bug c++/49570] /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49570 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28 20:29:23 UTC --- Report the problem to Intel.
[Bug tree-optimization/49539] [4.7 regression] ICE building gnattools
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49539 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Component|ada |tree-optimization --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-28 20:47:10 UTC --- Recategorizing.
[Bug c++/49570] /usr/include/c++/4.6.0/bits/stl_algobase.h(378): error: type name is not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49570 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-28 20:50:17 UTC --- The GNU C++ header files depend already on *tons* of non-standard facilities provided by the GNU C++ front-end, and many more such dependencies are being added these days. In some cases, eg, std::underlying_type in C++0x, that it's provably absolutely unavoidable (even not considering quality of implementation issues). Anyway, normally Intel is pretty good at its GNU compatibility modes, probably you should only update your Intel compiler too.
[Bug bootstrap/49555] libjava fails to configure if --enable-symvers=gnu or --enable-symvers=sun
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49555 Bryan Hundven bryanhundven at gmail dot com changed: What|Removed |Added CC||yann.morin.1998 at free dot ||fr --- Comment #4 from Bryan Hundven bryanhundven at gmail dot com 2011-06-28 21:01:43 UTC --- (In reply to comment #3) (In reply to comment #2) Please provide a bit mor information: Sure. Re-reading comment #3, maybe I sounded a bit brass. Let me try again. Yann requested to be CC'd. * what platform are you on? It happens on every platform I configure, but if you want something specific: --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu --target=x86_64-unknown-linux-gnu I also have the same problems on: --build=i686-unknown-linux-gnu --host=i686-unknown-linux-gnu --target=mips64-unknown-linux-gnu and: --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=powerpc-unknown-linux-gnuspe same response. This is a build from crosstool-ng. --enable-symvers=gnu is set staticly in: http://crosstool-ng.org/hg/crosstool-ng/file/tip/scripts/build/cc/gcc.sh * what are your configure options? --enable-languages=c,c++,fortran,objc,obj-c++ --disable-multilib --with-tune=core2 --with-pkgversion=crosstool-NG hg_unknown@20110627.135200 --disable-sjlj-exceptions --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-mpfr=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-mpc=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-ppl=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-cloog=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-libelf=/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static --with-host-libstdcxx=-static-libgcc -Wl,-Bstatic,-lstdc++ -lm -L/home/bryan/builds/x86_64-unknown-linux-gnu/.build/x86_64-unknown-linux-gnu/build/static/lib -lpwl --enable-threads=posix --enable-target-optspace --disable-libstdcxx-pch --with-long-double-128 --enable-gold Same response. * why do you insist on specifying the symvers flavor manually? I had a discussion with Yann E. Morin, and it sounds like this option was ported forward from the legacy options in Dan Kegel's crosstool. The questions I am asking should be: * Should this ever (for any platform) be set manually? Or should this always be an 'automatic' setting? * Isn't it inconsistent that every component checks for 'gnu*' and 'sun', except for libjava? Yann is currently retesting the sh4 build without --enable-symvers=gnu set to see if it still needs it. If it does not, then he will remove it completely, otherwise it should be target specific in crosstool-ng and not for all targets. I didn't insist on specifying it manually. crosstool-ng did. While you might say that is a problem with crosstool-ng, but the older crosstool and other cross tool scripts use this as well. If every other component besides libjava specifically check for yes|no|gnu*|sun, why doesn't libjava? Or... If I shouldn't use --enable-symvers=gnu, shouldn't all other components fail to support it?
[Bug lto/49571] New: -flto -Wl,--as-needed drops needed libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49571 Summary: -flto -Wl,--as-needed drops needed libraries Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: b.r.longb...@gmail.com Created attachment 24624 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24624 Minimal testcase demonstrating the error Description: -flto does something funny that makes --as-needed drop more libraries than it should. See the attached file Context: I originally encountered this bug in a big C++ project with -m32, but quickly reduced it to the attached minimal testcase. Only in the original project, I got this misleading error: /usr/bin/ld: /tmp/ccPEhCnW.ltrans4.ltrans.o: undefined reference to symbol 'sqrt@@GLIBC_2.0' /usr/bin/ld: note: 'sqrt@@GLIBC_2.0' is defined in DSO /usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/../../../../../lib32/libm.so so try adding it to the linker command line despite -lm *being* explicitly on the command line (which is normally not needed in C++? Is that standard behavior or is it relying on the indirect linking thing that *usually* generates that error?) but this was replaced in the minimal case by the more typical ccp7SO9X.ltrans0.o:(.text+0x29): undefined reference to `sqrt' Workaround: Identify which libraries are *actually* needed and pass them after -Wl,--no-as-needed. This works for my particular case (I am building multiple binaries, only one of which requires -lm) since libm would be loaded indirectly by libstdc++ anyway, but could be problematic in the general case System information 1: Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.6.0/work/gcc-4.6.0/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --disable-nls --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.0 p1.2, pie-0.4.5' Thread model: posix gcc version 4.6.0 (Gentoo 4.6.0 p1.2, pie-0.4.5) System information 2: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-13' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 20110611 (prerelease) (Debian 4.6.0-13)
[Bug lto/49571] -flto -Wl,--as-needed drops needed libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49571 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-06-28 23:37:39 UTC --- I think this only fails when the LTO plugin is enabled.
