[Bug c++/50893] New: [C++0x] explicitly defaulted virtual destructor throw specification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50893
Bug #: 50893
Summary: [C++0x] explicitly defaulted virtual destructor throw
specification
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jarr...@cse.unsw.edu.au
The following code fails to compile:
class Base
{
public:
virtual ~Base() = default;
};
class Derived : public Base
{
public:
virtual ~Derived() = default;
};
g++ -std=gnu++0x except.cpp
except.cpp:10:11: error: looser throw specifier for ‘virtual
Derived::~Derived()’
except.cpp:4:11: error: overriding ‘virtual Base::~Base() noexcept (true)’
I think, according to 15.4.14, that Derived should, by default, have the same
exception specification as Base, ie. noexcept(true). Therefore, this code
should compile.
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jarrydb/current/soft/install-latest/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/jarrydb/current/soft/src/gcc-git/configure
--prefix=/home/jarrydb/current/soft/install-latest --disable-multilib
--enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20111027 (experimental) (GCC)
[Bug rtl-optimization/49720] Infinite recursion compiling gold binary_test.cc testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49720 --- Comment #2 from Chung-Lin Tang cltang at gcc dot gnu.org 2011-10-28 06:35:37 UTC --- Author: cltang Date: Fri Oct 28 06:35:31 2011 New Revision: 180604 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180604 Log: 2011-10-28 Chung-Lin Tang clt...@codesourcery.com PR rtl-optimization/49720 * simplify-rtx.c (simplify_relational_operation_1): Detect infinite recursion condition in (eq/ne (plus x cst1) cst2) simplifies to (eq/ne x (cst2 - cst1)) case. testsuite/ * g++.dg/torture/pr49720.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr49720.C Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #5 from Richard B. Kreckel kreckel at ginac dot de 2011-10-28 07:06:57 UTC --- On 10/27/2011 11:24 AM, paolo.carlini at oracle dot com wrote: Thus, to understand and clarify why this has not been noticed so far, you are on a target which doesn't support in the underlying C library these complex functions, right? Because normally (eg, on Linux) these days we just forward to __builtin_cacosh*, the code you are touching is just a surrogate, a fallback, which doesn't get right all the special cases, NaNs, infinity. Well, I didn't notice it. Searching for bugs involving branch cut positions of inverse trig functions in a range of FOSS projects is a pet project of mine. ;-) BTW: I noticed that my patch tests if (__z.real() -0.0), which is correct, but the sign of zero looks eccentric and might potentially confuse future readers. I suggest removing it. It doesn't matter at all, anyhow.
[Bug libstdc++/50894] New: onlinedocs for libstdc++ missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50894 Bug #: 50894 Summary: onlinedocs for libstdc++ missing Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: libstdc++ AssignedTo: b...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: ger...@pfeifer.com http://gcc.gnu.org/ml/gcc/2011-10/msg00505.html This has been the case for several months now. The latest docs for trunk are 8 months out of date too.
[Bug ada/50842] [4.7 Regression] gnatmake fails to link in stage3 with undefined symbol _iconv_close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50842 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-10-28 07:13:49 UTC --- Author: ebotcazou Date: Fri Oct 28 07:13:44 2011 New Revision: 180605 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180605 Log: PR ada/50842 * gcc-interface/Makefile.in (SYMDEPS): Delete. (LIBICONV): New variable. (LIBICONV_DEP): Likewise. (LIBS): Add $(LIBICONV). (LIBDEPS): Add $(LIBICONV_DEP). (EXTRA_GNATTOOLS_OBJS): Merge into... (TOOLS_LIBS): ...this. Add $(LIBICONV). Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in
[Bug ada/50842] [4.7 Regression] gnatmake fails to link in stage3 with undefined symbol _iconv_close
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50842 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-10-28 07:18:15 UTC --- Patch applied.
[Bug libstdc++/50894] onlinedocs for libstdc++ missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50894 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.0 Known to fail||4.6.2 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-28 07:26:03 UTC --- The 4.6.0 docs are still there, so one way to fix it would be to simply change the links on the docs page http://gcc.gnu.org/onlinedocs/gcc-4.6.0/libstdc++/manual/spine.html
[Bug c/50521] -fstrict-volatile-bitfields is not strict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521 --- Comment #9 from Henrik Nordström henrik at henriknordstrom dot net 2011-10-28 07:32:48 UTC --- C standard does not define any of this It's all implementation and platform ABI dependent. The C standard does define not storage size of a bit-field other than that it's sufficiently large, or bit-fields of other types than _Bool and int (+qualifiers), or if bits outside the specific bit-field is accessed as side effect when operating on a bit-field. For example the ARM ABI defines volatile bitfield memory access in full detail as being equal to the base type of the bitfield, and I see now that it actually requires a double load in the mentioned test case. See http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf section 7.1.7.5.
[Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #54 from Sebastian Huber sebastian.hu...@embedded-brains.de
2011-10-28 07:31:19 UTC ---
I tested with GCC 4.6.2 and the patch provided by Mikael Pettersson. It works
for -march=armv4t and -march=armv5t, but not for -march=armv5te:
--- test-armv5te.s 2011-10-28 09:22:24.627388063 +0200
+++ test-armv5t.s 2011-10-28 09:22:19.923643155 +0200
@@ -1,4 +1,4 @@
- .arch armv5te
+ .arch armv5t
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
@@ -27,8 +27,8 @@
mov r1, r4
mov r2, #1
bl doStreamReadBlock
- add sp, sp, #8
ldrbr0, [r4]
+ add sp, sp, #8
@ sp needed for prologue
pop {r4, pc}
.size readStream, .-readStream
Command line:
arm-eabi-gcc -O2 -march=armv5t -mthumb -S test.c -o test-armv5t.s
arm-eabi-gcc -O2 -march=armv5te -mthumb -S test.c -o test-armv5te.s
[Bug c/50521] -fstrict-volatile-bitfields is not strict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521 --- Comment #10 from Tomohiro Kashiwada kikairoya at gmail dot com 2011-10-28 08:13:31 UTC --- (In reply to comment #9) http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf section 7.1.7.5. Thanks, I see. On ARM ABI, reading or writing to volatile-bitfields should not cause double access and regardless of volatileness, access should be aligned as container's type. I think that to avoid double access needs treatment of volatile object.
[Bug c/50521] -fstrict-volatile-bitfields is not strict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521 --- Comment #11 from Tomohiro Kashiwada kikairoya at gmail dot com 2011-10-28 08:15:39 UTC --- Created attachment 25642 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25642 patch to honor STRICT_ALIGNMENT honor STRICT_ALIGNMENT when accessing non-volatile-bitfields
[Bug libgcj/50895] New: Build failure in jni.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50895 Bug #: 50895 Summary: Build failure in jni.cc Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Building a x86_64-linux-gnu to i686-w64-mingw32 cross-compiler with --enable-libgcj, I get this build error: /bin/sh ./libtool --tag=CXX --mode=compile /home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc -shared-libgcc -B/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc -nostdinc++ -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/lib -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/include -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/bin/ -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/ -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -I./include -I./gcj -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -Iinclude -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/include -Iclasspath/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/native/fdlibm -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../boehm-gc/include -I../boehm-gc/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/libltdl -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/libltdl -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/.././libjava/../gcc -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../zlib -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -fno-omit-frame-pointer -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32\ -DTOOLEXECLIBDIR=\/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/../lib\ -DJAVA_HOME=\/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32\ -DBOOT_CLASS_PATH=\/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/libgcj-4.6.3.jar\ -DJAVA_EXT_DIRS=\/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/share/java/gcj-endorsed\ -DGCJ_VERSIONED_LIBDIR=\/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/lib/../lib/gcj-4.6.3-12\ -DPATH_SEPARATOR=\:\ -DECJ_JAR_FILE=\\ -DLIBGCJ_DEFAULT_DATABASE=\/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/lib/../lib/gcj-4.6.3-12/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.6.3-12/classmap.db\ -g -O2 -MT jni.lo -MD -MP -MF $depbase.Tpo -c -o jni.lo /home/ruben/mingw-w64/toolchain/src/gcc/libjava/jni.cc \ mv -f $depbase.Tpo $depbase.Plo libtool: compile: /home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc -shared-libgcc -B/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc -nostdinc++ -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src -L/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/i686-w64-mingw32/libstdc++-v3/src/.libs -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/lib -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/include -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/bin/ -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/ -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -I./include -I./gcj -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava -Iinclude -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/include -Iclasspath/include -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/classpath/native/fdlibm -I/home/ruben/mingw-w64/toolchain/src/gcc/libjava/../boehm-gc/include -I../boehm-gc/include
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-10-28 09:06:30 UTC --- sorry to ping again. Stage 1 is supposed to end Nov 7th. Will the new feature work out by Sri make for 4.7?
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-28 09:10:09 UTC --- Indeed you are right about the sign, in terms at least of consistency with the rest of the fallback implementations which already have got quite a number of comparisons with zero with no special attention to its signedness (like ' _Tp()' or ' _Tp()'). I had already noticed that. As soon as I find a bit of time, we can also *consistently over all those cases* use __builtin_signbit, as suggested by Gaby elsewhere. I have to double check with the middle-end people that it doesn't generate library calls for the patch to be neat.
[Bug c++/30066] option to make inline functions hidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30066 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-28 09:11:39 UTC --- I guess we can declare this fixed for 4.7.0, great!
[Bug driver/50876] [4.7 Regression] unrecognized command line option '-Zmultiply_defined suppress regressions for lto.exp on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50876
--- Comment #17 from Iain Sandoe iains at gcc dot gnu.org 2011-10-28 09:12:07
UTC ---
I notice that f{un}signed-char is marked for LTO in the .opts file - does that
make any difference to the logic?
funsigned-char
C ObjC C++ ObjC++ LTO Var(flag_signed_char, 0)
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #8 from rguenther at suse dot de rguenther at suse dot de 2011-10-28 09:14:29 UTC --- On Fri, 28 Oct 2011, vincenzo.innocente at cern dot ch wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-10-28 09:06:30 UTC --- sorry to ping again. Stage 1 is supposed to end Nov 7th. Will the new feature work out by Sri make for 4.7? No
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #10 from Marc Glisse marc.glisse at normalesup dot org 2011-10-28 09:31:30 UTC --- Just noticed this accidentally while looking for something else. And I am opposed to hiding the standard typedefs (particularly iterator_category), even in some debug mode. An iterator is either a pointer or a class with the typedefs. If you want to portably detect iterators (for sfinae purposes), that's exactly what you'll test, since iterator_traits is not guaranteed to be sfinae-friendly. On the other hand, I would not be opposed to a signature: iterator operator--(); for the decrement operator (notice the final '') when support appears in the compiler. Next time I read --v.end()... Note that IIRC Howard's libc++ uses pointers, which should make those issues more visible.
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-28 09:40:36 UTC --- Interesting, thanks. By the way, I would guess Sylvain' email doesn't work anymore, thus it's unlikely that he can give us his feedback ;) (or does he have a forward in place, as far as you know?)
[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-28 Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-28 09:42:57 UTC --- Confirmed. #1 0x009ab110 in gimplify_expr (expr_p=0x75b3d078, pre_p=0x7fffbdc8, post_p=0x7fff84f8, gimple_test_f= 0x93fdf9 is_gimple_val(tree_node*), fallback=1) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:7599 7599 gcc_assert (!VOID_TYPE_P (TREE_TYPE (*expr_p))); (gdb) call debug_generic_expr (*expr_p) *D.1735 #3 0x009840a8 in gimplify_call_expr (expr_p=0x75a2d7a8, pre_p=0x7fffbdc8, want_value=true) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:2438 2438EXPR_LOCATION (*expr_p)); (gdb) call debug_generic_expr (*expr_p) strlen_void (*D.1735) mem_ref 0x75a2d930 type void_type 0x75a31bd0 void VOID align 8 symtab 0 alias set -1 canonical type 0x75a31bd0 pointer_to_this pointer_type 0x75a31c78 arg 0 var_decl 0x75a2c640 D.1735 type pointer_type 0x75a31c78 type void_type 0x75a31bd0 void public unsigned DI size integer_cst 0x75a20ec0 constant 64 unit size integer_cst 0x75a20ee0 constant 8 align 64 symtab 0 alias set -1 canonical type 0x75a31c78 pointer_to_this pointer_type 0x75a44f18 used unsigned ignored DI file t.f90 line 18 col 0 size integer_cst 0x75a20ec0 64 unit size integer_cst 0x75a20ee0 8 align 64 context function_decl 0x75b38600 test arg 1 integer_cst 0x75a34580 type pointer_type 0x75a31c78 constant 0 t.f90:18:0
[Bug middle-end/50890] [4.7 Regression] ICE in fold_convert_loc, at fold-const.c:1894
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50890 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-10-28 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-28 09:45:36 UTC --- Confirmed. We should not have inlined the function. Possibly caused by my gimple_call_fntype changes, thus mine.
[Bug driver/50876] [4.7 Regression] unrecognized command line option '-Zmultiply_defined suppress regressions for lto.exp on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50876 --- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-28 09:46:32 UTC --- Author: rguenth Date: Fri Oct 28 09:46:26 2011 New Revision: 180608 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180608 Log: 2010-10-28 Richard Guenther rguent...@suse.de PR driver/50876 * lto-wrapper.c (get_options_from_collect_gcc_options): Properly count arguments. (run_gcc): Use an obstack to collect argv, properly separate switches and their arguments. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-wrapper.c
[Bug testsuite/50885] [4.7 Regression] FAIL: gcc.dg/strlenopt-22.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50885 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |testsuite Target Milestone|--- |4.7.0 Summary|FAIL: gcc.dg/strlenopt-22.c |[4.7 Regression] FAIL: |(test for excess errors)|gcc.dg/strlenopt-22.c (test ||for excess errors)
[Bug driver/50876] [4.7 Regression] unrecognized command line option '-Zmultiply_defined suppress regressions for lto.exp on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50876 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-28 09:49:31 UTC --- Fixed.
[Bug c++/50870] [C++0x] [4.6/4.7 Regression] ICE with decltype, operator-, and default template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50870 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-28 09:52:14 UTC --- HJ, any chance you can figure out when we regressed for testcase in Comment #3 ?
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2011-10-28 09:57:01 UTC --- (In reply to comment #10) An iterator is either a pointer or a class with the typedefs. Or a type for which iterator_traits has been specialized? I'm not really interested in the patch, I did it as a proof of concept and reverted it in my tree a long time ago
[Bug libstdc++/43813] [DR1234] vectorT*(3, NULL) fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43813 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #9 from Marc Glisse marc.glisse at normalesup dot org 2011-10-28 09:59:58 UTC --- (In reply to comment #8) Note: if the *only* way to change the behevior for the best requires using enable_if on the user-level member functions (as, if I remember correctly, pioneered by Howard at Metrowerks quite a few years ago), The resolution to 1234 has been adopted for C++11. The standard now says: the constructor shall not participate in overload resolution, not that the call should be dispatched to an appropriate function. If there is an observable difference, that makes the dispatch technique wrong. we have to make sure we do it consistently over all the dispatchings in the containers, and check what happens if a binary built with the headers using the old-style dispatching is linked to a new one. In case, restrict the mechanism to C++0x mode. But really, I'd rather wait for a resolution anyway, even as NAD but clearly stating this is a QoI issue. I don't think adding an extra template parameter or an extra argument to the function (and removing the unnecessary functions) creates any incompatibility, but you have more experience with that. In C++11 mode (where libstdc++ has sfinae-friendly iterator_traits), we could check something like is_convertibletypename iterator_traits_Iterator::iterator_category, input_iterator_tag.
[Bug driver/50876] [4.7 Regression] unrecognized command line option '-Zmultiply_defined suppress regressions for lto.exp on x86_64-apple-darwin11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50876
--- Comment #20 from rguenther at suse dot de rguenther at suse dot de
2011-10-28 10:01:45 UTC ---
On Fri, 28 Oct 2011, iains at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50876
--- Comment #17 from Iain Sandoe iains at gcc dot gnu.org 2011-10-28
09:12:07 UTC ---
I notice that f{un}signed-char is marked for LTO in the .opts file - does that
make any difference to the logic?
funsigned-char
C ObjC C++ ObjC++ LTO Var(flag_signed_char, 0)
Yes, I've fixed that in the patch I committed.
[Bug target/50164] [IRA, 4.7 Regression] Performance degradation due to increased memory instructions count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50164 Ilya Enkovich enkovich.gnu at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #11 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-10-28 10:10:42 UTC --- Initially problem was caused by movzbl cost value for Atom. Low cost of movzbl made IRA keep frequently used byte value on the stack and assign register for int value. Change cost model resolves the problem and it has been fixed in revision 17.
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247 --- Comment #13 from Marc Glisse marc.glisse at normalesup dot org 2011-10-28 10:18:43 UTC --- (In reply to comment #12) (In reply to comment #10) An iterator is either a pointer or a class with the typedefs. Or a type for which iterator_traits has been specialized? Yes. Sadly, that's not portably detectable. The 2 categories above are those that can be tested. And having a private iterator_category completely breaks sfinae in C++03.
[Bug rtl-optimization/47918] [4.6/4.7 Regression] noreturn discovery broke non local gotos on m68k and i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47918 --- Comment #11 from jules at gcc dot gnu.org 2011-10-28 10:48:36 UTC --- Author: jules Date: Fri Oct 28 10:48:32 2011 New Revision: 180611 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180611 Log: PR rtl-optimization/47918 * reload1.c (set_initial_label_offsets): Use initial offsets for labels on the nonlocal_goto_handler_labels chain. Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c
[Bug middle-end/50079] [4.7 Regression] FAIL: g++.dg/init/copy7.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50079 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-28 10:52:51 UTC --- Btw, for the truly anal folks with a memcpy implementation that breaks with src == dest we can add a target hook that specifies to use memmove for block move expansion instead of memcpy (or guard the latter with a if (src != dest) on those targets). Stupid targets/implementations should not pay the penalty of a test-and-branch.
[Bug target/45650] [4.4/4.5/4.6/4.7 regression] FreeBSD/ia64 builds fails: hidden symbol `_Unwind_FindTableEntry' isn't defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45650 --- Comment #5 from Anton Shterenlikht mexas at bristol dot ac.uk 2011-10-28 10:57:58 UTC --- gcc-4.7.0.20111022 now builds fine on ia64
[Bug middle-end/50079] [4.7 Regression] FAIL: g++.dg/init/copy7.C execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50079 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-10-28 11:07:10 UTC --- This fails on SPARC too.
[Bug c++/50896] New: FAIL: [4.7 Regression] g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50896 Bug #: 50896 Summary: FAIL: [4.7 Regression] g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2 (internal compiler error) Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: lto Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org CC: hubi...@gcc.gnu.org, ja...@gcc.gnu.org The weak alias changes probably caused FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2 (internal compiler error) which has Breakpoint 1, fancy_abort ( file=0x136a758 /space/rguenther/src/svn/trunk/gcc/varasm.c, line=1141, function=0x136d2c8 make_decl_rtl) at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:899 899 internal_error (in %s, at %s:%d, function, trim_filename (file), line); (gdb) up #1 0x00d7d415 in make_decl_rtl (decl=0x2ce9e140) at /space/rguenther/src/svn/trunk/gcc/varasm.c:1137 1137 gcc_assert (TREE_CODE (decl) != VAR_DECL (gdb) l 1132 /* Check that we are not being given an automatic variable. */ 1133 gcc_assert (TREE_CODE (decl) != PARM_DECL 1134 TREE_CODE (decl) != RESULT_DECL); 1135 1136 /* A weak alias has TREE_PUBLIC set but not the other bits. */ 1137 gcc_assert (TREE_CODE (decl) != VAR_DECL 1138 || TREE_STATIC (decl) 1139 || TREE_PUBLIC (decl) 1140 || DECL_EXTERNAL (decl) 1141 || DECL_REGISTER (decl)); (gdb) call debug_tree (decl) var_decl 0x2ce9e140 _ZN1AIDv4_fE1tE type vector_type 0x2cfc3348 mm128 type real_type 0x2cea3e70 float SF size integer_cst 0x2cea6240 constant 32 unit size integer_cst 0x2cea6260 constant 4 align 32 symtab 0 alias set -1 canonical type 0x2cea3e70 precision 32 pointer_to_this pointer_type 0x2ceb10a8 V4SF size integer_cst 0x2cea6400 constant 128 unit size integer_cst 0x2cea6420 constant 16 align 128 symtab 0 alias set -1 canonical type 0x2cfc33f0 nunits 4 pointer_to_this pointer_type 0x2cfc32a0 addressable used ignored V4SF file /space/rguenther/src/svn/trunk/gcc/testsuite/g++.dg/lto/20100302_0.C line 9 col 19 size integer_cst 0x2cea6400 128 unit size integer_cst 0x2cea6420 16 align 128 Possibly also a frontend issue(?)
[Bug c++/50896] FAIL: [4.7 Regression] g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2 (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50896 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 --- Comment #55 from Iain Sandoe iains at gcc dot gnu.org 2011-10-28 11:59:10 UTC --- Author: iains Date: Fri Oct 28 11:59:07 2011 New Revision: 180613 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180613 Log: ada: PR target/50678 * init.c (Darwin/__gnat_error_handler): Apply a work-around to the bug [filed as radar #10302855], which is inconsistent unwind data for sigtramp. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/init.c
[Bug target/50678] [4.7 Regression] FAIL: c52104y on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678 --- Comment #56 from Iain Sandoe iains at gcc dot gnu.org 2011-10-28 12:01:10 UTC --- please leave this bug open for now - it is not really fixed, the patch applied is a workaround. once we get a response to the radar, we'll know better how to proceed.
[Bug middle-end/50890] [4.7 Regression] ICE in fold_convert_loc, at fold-const.c:1894
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50890
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-28
12:45:28 UTC ---
Bah, probably triggered by that change but reveals some bigger issue with how
we keep the mismatched-function-flags (gimple_call_cannot_inline_p and
the corresponding edge flag e-call_stmt_cannot_inline_p) up-to-date.
In this case the inliner when inlining emit_pattern_after_noloc turns
the make_raw () call into a direct call but fails to set this flag,
so we inline it during the 2nd early inliner iteration.
Setting that flag at a convenient place with
+ /* Check whether propagating into the function address made the
+ call direct, and thus possibly non-inlineable.
+ ??? This asks for a more conservative setting of the non-inlinable
+ flag, namely true for all indirect calls. But that would require
+ that we can re-compute the flag conservatively, thus it isn't
+ ever initialized from something else than return/argument type
+ checks . */
+ callee = gimple_call_fndecl (stmt);
+ if (callee
+ !gimple_check_call_matching_types (stmt, callee))
+gimple_call_set_cannot_inline (stmt, true);
during statement folding (CCP can also cause such change when
turning an indirect into a direct call) causes us to hit
#1 0x012b80e7 in can_inline_edge_p (e=0x75b286e8, report=true)
at /space/rguenther/src/svn/trunk/gcc/ipa-inline.c:339
339 gcc_checking_assert (!e-call_stmt
because nobody updated the edge flag ... (and I don't think we should
do that from the statement folder). That's during the 2nd iteration
of the early inliner.
Honza, why do we get away not re-building cgraph edges while
iterating? What is supposed to keep the edges up-to-date?
I suppose we can adjust the flag when we do
/* Technically we ought to recompute inline parameters so the new
iteration of early inliner works as expected. We however have
values approximately right and thus we only need to update edge
info that might be cleared out for newly discovered edges. */
for (edge = node-callees; edge; edge = edge-next_callee)
{
struct inline_edge_summary *es = inline_edge_summary (edge);
es-call_stmt_size
= estimate_num_insns (edge-call_stmt, eni_size_weights);
es-call_stmt_time
= estimate_num_insns (edge-call_stmt, eni_time_weights);
}
Testing a patch.
[Bug target/45650] [4.4/4.5/4.6/4.7 regression] FreeBSD/ia64 builds fails: hidden symbol `_Unwind_FindTableEntry' isn't defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45650 --- Comment #6 from Gerald Pfeifer gerald at pfeifer dot com 2011-10-28 12:56:49 UTC --- (In reply to comment #5) gcc-4.7.0.20111022 now builds fine on ia64 Also if you remove files/patch-unwind-ia64.h from the lang/gcc47 port on FreeBSD which I assume you are using? In the context of upstream GCC -- that is here ;-) -- please always remove that one when reporting success or failure.
[Bug middle-end/50448] [4.5/4.6/4.7 Regression] Missed optimization accessing struct component with integer address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50448
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-10-28
12:59:28 UTC ---
The issue is still present for avr (4.7 trunk r180399).
There is a patch proposed by Paolo that fixes the issue:
Can someone of you integrate that patch? I have no access to compile farm and
cannot test for all languages/targets/hosts that might be affected.
Index: cprop.c
===
--- cprop.c(revision 177688)
+++ cprop.c(working copy)
@@ -764,6 +764,18 @@ try_replace_reg (rtx from, rtx to, rtx i
note = set_unique_reg_note (insn, REG_EQUAL, copy_rtx (src));
}
+ if (set MEM_P (SET_DEST (set)) reg_mentioned_p (from, SET_DEST (set)))
+{
+ /* If above failed and this is a single set, try to simplify the source
of
+ the set given our substitution. We could perhaps try this for multiple
+ SETs, but it probably won't buy us anything. */
+ rtx addr = simplify_replace_rtx (SET_DEST (set), from, to);
+
+ if (!rtx_equal_p (addr, SET_DEST (set))
+ validate_change (insn, SET_DEST (set), addr, 0))
+success = 1;
+}
+
/* REG_EQUAL may get simplified into register.
We don't allow that. Remove that note. This code ought
not to happen, because previous code ought to synthesize
[Bug rtl-optimization/50898] New: Register allocation depends on function return expression on x86 32-bits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50898 Bug #: 50898 Summary: Register allocation depends on function return expression on x86 32-bits Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: izamya...@gmail.com Created attachment 25643 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25643 Testcase This problem has been noticed during investigation for PR50164. For attached test case allocator's assignment of registers in some piece of code depends on how return expression looks like. And it seems that there are no reasons for this. For attached case we have following code snippet obtained by fresh compiler: .L13: movzbl (%esi), %ecx leal3(%esi), %ebp movb%cl, 48(%esp) notb48(%esp) movzbl 1(%esi), %ecx movzbl 2(%esi), %ebx notl%ecx notl%ebx cmpb%cl, 48(%esp) movl%ebp, %esi movb%bl, 32(%esp) jb .L18 cmpb%cl, 32(%esp) movzbl 32(%esp), %ebx cmova %ecx, %ebx movl%ebx, %edi jmp .L10 But if return expression turn to return 0 we will see following code which is actually more optimal: .L13: movzbl (%esi), %edx --- edx is used instead of ecx leal3(%esi), %ebp movzbl 1(%esi), %ecx notl%edx movzbl 2(%esi), %ebx notl%ecx notl%ebx cmpb%cl, %dl movl%ebp, %esi movb%dl, 48(%esp) movb%bl, 32(%esp) jb .L18 cmpb%cl, 32(%esp) movzbl 32(%esp), %ebx cmova %ecx, %ebx movl%ebx, %edi jmp .L10 So for some reasons in the first case edx is not used and code contains more memory instructions. gcc -v: Using built-in specs. COLLECT_GCC=/export/users/izamyati/compiler/build/bin/gcc COLLECT_LTO_WRAPPER=/export/users/izamyati/compiler/build/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --disable-bootstrap --enable-languages=c,c++ --prefix=/export/users/izamyati/compiler/build/ Thread model: posix gcc version 4.7.0 20111026 (experimental) (GCC) Options for slow code: -m32 -march=atom -O2 -c Options for fast code: -m32 -march=atom -O2 -DGOOD -c
[Bug bootstrap/50857] [4.7 Regression] The compiler is built with exceptions and RTTI enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50857 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-10-28 13:08:10 UTC --- Hm, well - I would rather unconditionally enable those options for stage2 and 3 (we know it'll be G++ at built) and leave them off for stage1. Any way to just influence stage2+? Or would that be even more complicated?
[Bug other/50899] New: need @direntry for gcov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50899 Bug #: 50899 Summary: need @direntry for gcov Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: tro...@gcc.gnu.org I think the gcov utility should have a @direntry in the manual. That way it would show up in the main menu in 'dir' along with all the other programs.
[Bug bootstrap/50857] [4.7 Regression] The compiler is built with exceptions and RTTI enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50857 --- Comment #3 from iant at google dot com iant at google dot com 2011-10-28 13:56:23 UTC --- I suppose you could drop something into POSTSTAGE1_FLAGS_TO_PASS. But it's not the right thing to do. We want to use -fno-exceptions -fno-rtti even when using --disable-bootstrap or when using --enable-build-with-cxx.
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #9 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-10-28 14:00:18 UTC --- That's a pity. It would be very useful though to have at least a patch to test so that we can have something to use in prototypes and eventually a working solution for 4.8
[Bug middle-end/50448] [4.5/4.6/4.7 Regression] Missed optimization accessing struct component with integer address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50448 --- Comment #4 from Paolo Bonzini bonzini at gnu dot org 2011-10-28 14:26:57 UTC --- Can't you just test on x86_64-linux?
[Bug other/50900] New: 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900
Bug #: 50900
Summary: 'gmake pdf' fails in libiberty
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ka...@gcc.gnu.org
Underfull \hbox (badness 1) in paragraph at lines 669--673
[]@textrm For ex-am-ple, if @textsl bin[]prefix @textrm is @texttt /alpha/beta
/gamma/gcc/delta[]@textrm , @textsl pre-fix @textrm is
[22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35])
Appendix A [36] (/home/sgk/gcc/gcc4x/libiberty/copying-lib.texi [37] [38]
[39] [40] [41] [42]
/home/sgk/gcc/gcc4x/libiberty/copying-lib.texi:480: This command can appear onl
y outside of any environment, not in environment @enumerate.
@badenverr ...temp , not @inenvironment @thisenv }
@checkenv ...@ifx @thisenv @temp @else @badenverr
@fi
@sectionheading #1#2#3#4-{@checkenv {}
@csname #2fonts@endcsname @rmisbold @...
@\heading ...tionheading {#1}{sec}{Yomitfromtoc}{}
@suppressfirstparagraphin...
l.480 @heading NO WARRANTY
? q
OK, entering @batchmode/usr/local/bin/texi2dvi: pdfetex exited with bad status,
quitting.
gmake[2]: *** [libiberty.pdf] Error 1
gmake[2]: Leaving directory `/usr/home/sgk/gcc/obj4x/libiberty'
gmake[1]: *** [pdf-libiberty] Error 1
gmake[1]: Leaving directory `/usr/home/sgk/gcc/obj4x'
gmake: *** [do-pdf] Error 2
[Bug c++/50901] New: [4.6/4.7 Regression] ICE: in build_new_op, at cp/call.c:5016
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50901
Bug #: 50901
Summary: [4.6/4.7 Regression] ICE: in build_new_op, at
cp/call.c:5016
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amona...@gcc.gnu.org
cat t.cc
templateclass T int foo(int a)
{
const unsigned b = a 0 ? -a : a;
return 0;
}
gcc/cc1plus -std=c++0x t.cc
int foo(int)
t2.cc:4:35: internal compiler error: in build_new_op, at cp/call.c:5016
4.5 and 4.6.1 work, 4.6.2 and trunk break. Seems like build_new_op is missing
a case for ABS_EXPR.
[Bug c++/50870] [C++0x] [4.6/4.7 Regression] ICE with decltype, operator-, and default template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50870 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-10-28 15:53:39 UTC --- (In reply to comment #4) HJ, any chance you can figure out when we regressed for testcase in Comment #3 ? I tried different versions of GCC, I got pr50870.cc:8: error: expected type-specifier before ‘decltype’ pr50870.cc:8: error: expected `' before ‘decltype’ pr50870.cc:12: error: template argument 4 is invalid pr50870.cc:12: error: invalid type in declaration before ‘;’ token
[Bug middle-end/50902] New: intVar/dinternal.cc ICEs at -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50902 Bug #: 50902 Summary: intVar/dinternal.cc ICEs at -O2 -ftree-vectorize Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: howa...@nitro.med.uc.edu Created attachment 25644 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25644 preprocessed source file for intVar/dinternal.cc The g++ compiler in current gcc trunk ICEs when compiling intVar/dinternal.cc from xplor-nih 2.27 with -O2 -ftree-vectorize or -O3. g++-fsf-4.7 -c dinternal.cc -O2 -ftree-vectorize -fpermissive -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG -I/Users/howarth/xplor-nih-2.27/intVar/ -I/Users/howarth/xplor-nih-2.27/arch/Darwin_11_x86_64/include -DCPLUSPLUS -DUSE_CDS_NAMESPACE -I/Users/howarth/xplor-nih-2.27/intVar/ -I/Users/howarth/xplor-nih-2.27/arch/Darwin_11_x86_64/include -I/Users/howarth/xplor-nih-2.27/CDSlib -I/Users/howarth/xplor-nih-2.27/common In file included from dinternal.cc:1251:0: /Users/howarth/xplor-nih-2.27/CDSlib/matrixTools.cc: In instantiation of 'MATRIX MatrixTools::callInverse(const MATRIX, MatrixTools::InverseResultsFullMatrixtypename MATRIX::ElementType ) [with MATRIX = InertiaTensor; typename MATRIX::ElementType = double]': /Users/howarth/xplor-nih-2.27/CDSlib/matrixTools.cc:237:35: required from 'MATRIX MatrixTools::inverse(const MATRIX, MatrixTools::InverseResultstypename MATRIX::MatrixType) [with MATRIX = InertiaTensor; typename MATRIX::MatrixType = FullMatrixdouble]' dinternal.cc:945:29: required from here /Users/howarth/xplor-nih-2.27/CDSlib/matrixTools.cc:170:2: warning: 'callTRF' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] /Users/howarth/xplor-nih-2.27/CDSlib/matrixTools.cc:293:1: note: 'templateclass Number void callTRF(const int, const int, Number*, const int, int*, int)' declared here, later in the translation unit /Users/howarth/xplor-nih-2.27/CDSlib/matrixTools.cc:180:2: warning: 'callTRI' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] /Users/howarth/xplor-nih-2.27/CDSlib/matrixTools.cc:274:1: note: 'templateclass Number void callTRI(const int, Number*, const int, const int*, Number*, const int, int)' declared here, later in the translation unit In file included from dinternal.cc:1238:0: /Users/howarth/xplor-nih-2.27/CDSlib/cdsVector.cc: In constructor 'CDSVectorBaseT, ALLOC::CDSVectorBase(int, const T, ALLOC) [with T = bool; ALLOC = CDS::DefaultAlloc]': /Users/howarth/xplor-nih-2.27/CDSlib/cdsVector.cc:25:1: internal compiler error: in build_vector_from_val, at tree.c:1382
[Bug middle-end/50902] intVar/dinternal.cc ICEs at -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50902 --- Comment #1 from Jack Howarth howarth at nitro dot med.uc.edu 2011-10-28 16:01:35 UTC --- Uploaded testcase which can reproduce the ICE with... g++-fsf-4.7 -c dinternal.ii -O2 -ftree-vectorize -fpermissive -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG -DCPLUSPLUS -DUSE_CDS_NAMESPACE for gcc trunk built with... Using built-in specs. COLLECT_GCC=g++-fsf-4.7 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.2.0/4.7.0/lto-wrapper Target: x86_64-apple-darwin11.2.0 Configured with: ../gcc-4.7-20111028/configure --prefix=/sw --prefix=/sw/lib/gcc4.7 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.7/info --with-build-config=bootstrap-lto --enable-stage1-languages=c,lto --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.7 --enable-checking=yes --enable-cloog-backend=isl Thread model: posix gcc version 4.7.0 20111028 (experimental) (GCC)
[Bug middle-end/50902] intVar/dinternal.cc ICEs at -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50902 --- Comment #2 from Jack Howarth howarth at nitro dot med.uc.edu 2011-10-28 16:11:38 UTC --- Created attachment 25645 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25645 gdb log for single stepping from last call to tree.c:1382 before crash
[Bug middle-end/50902] intVar/dinternal.cc ICEs at -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50902 --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu 2011-10-28 16:35:21 UTC --- Could this be an unresolved corner-case of PR48098?
[Bug c++/50870] [C++0x] [4.6/4.7 Regression] ICE with decltype, operator-, and default template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50870 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-28 16:40:15 UTC --- HJ, if you are willing to help you have to use -std=c++0x with this (see the [C++0x] in the Description]. 4_5-branch accepts the snippet, the regression is rather old.
[Bug bootstrap/50903] New: configure:14607: error: GNU Fortran is not working;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50903 Bug #: 50903 Summary: configure:14607: error: GNU Fortran is not working; Classification: Unclassified Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: chadjida...@gmail.com Hi, Trying to compile gcc 4.5.3 I go the following error: checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /opt/gcc/src/gcc-4.5.3/build/x86_64-apple-darwin11.2.0/libgfortran/config.log make[1]: *** [configure-target-libgfortran] Error 1 make: *** [bootstrap] Error 2 I'm using: gcc-4.5.3 gmp-5.0.2 mpc-0.9 mpfr-3.0.1 and configured gcc as: ../configure --prefix=/opt/gcc --disable-multilib --with-gmp=/opt/gcc --with-mpfr=/opt/gcc --with-mpc=/opt/gcc --enable-languages=c,c++,fortran See /opt/gcc/src/gcc-4.5.3/build/x86_64-apple-darwin11.2.0/libgfortran/config.log in attachment. Thanks for any help, Cynthia
[Bug bootstrap/50903] configure:14607: error: GNU Fortran is not working;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50903 --- Comment #1 from Hadjidakis chadjidakis at gmail dot com 2011-10-28 17:13:38 UTC --- Created attachment 25646 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25646 config.log for gfortran
[Bug tree-optimization/49316] ICE in in function_and_variable_visibility, at ipa.c:926 with g++.dg/tls/diag-1.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49316 --- Comment #7 from Graham Reed greed at pobox dot com 2011-10-28 17:17:54 UTC --- I've now gotten the trunk (SVN 180430) built on AIX 5.3 TL4; the problem is the same as 4.6.1 and is also solved with the same patch. So this is definitely not target-specific, it seems to be in the emulated TLS.
[Bug rtl-optimization/50904] New: Induct benchmark of polyhedron slows down when -fno-protect-parens is enabled by -Ofast.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904 Bug #: 50904 Summary: Induct benchmark of polyhedron slows down when -fno-protect-parens is enabled by -Ofast. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: venkataramanan.kumar@gmail.com Configurations: GCC 4.7 trunk revison: 180364 Machine: AMD64 Commandline: gfortran -Ofast induct2.f90 Description: We observed slowdown in induct benchmark for -Ofast after -fprotect-parens got disabled in -Ofast (in gcc trunk rev 173385 on 2011-05-04 for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48864). When ISA enabled is avx, we observed a slowdown of ~2% While analyzing the slowdown, we found that there is a difference in code generated in one of the induct's hot loop nest, between -Ofast (with protect-parens) and -Ofast (without protect-parens) irrespective of ISA (avx,fma4)and tuning. Observations revealed this is due to an interaction with the reassociation of expression happening in gimple and code hoisting in PRE and other loop optimizations for the RTL generated for that expression. Details: The following snippet shows the hot loop in subroutine mutual_ind_quad_cir_coil. (-Snip-) do i = 1, 2*m theta = pi*real(i,longreal)/real(m,longreal) c_vector(1) = r_coil * cos(theta) c_vector(2) = r_coil * sin(theta) ! ! compute current vector for the coil in the global coordinate system ! coil_tmp_vector(1) = -sin(theta) coil_tmp_vector(2) = cos(theta) coil_tmp_vector(3) = 0.0_longreal coil_current_vec(1) = dot_product(rotate_coil(1,:),coil_tmp_vector(:)) coil_current_vec(2) = dot_product(rotate_coil(2,:),coil_tmp_vector(:)) coil_current_vec(3) = dot_product(rotate_coil(3,:),coil_tmp_vector(:)) ! do j = 1, 9 c_vector(3) = 0.5 * h_coil * z1gauss(j) ! ! rotate coil vector into the global coordinate system and translate it ! rot_c_vector(1) = dot_product(rotate_coil(1,:),c_vector(:)) + dx rot_c_vector(2) = dot_product(rotate_coil(2,:),c_vector(:)) + dy rot_c_vector(3) = dot_product(rotate_coil(3,:),c_vector(:)) + dz ! do k = 1, 9 q_vector(1) = 0.5_longreal * a * (x2gauss(k) + 1.0_longreal) q_vector(2) = 0.5_longreal * b1 * (y2gauss(k) - 1.0_longreal) q_vector(3) = 0.0_longreal ! ! rotate quad vector into the global coordinate system ! rot_q_vector(1) = dot_product(rotate_quad(1,:),q_vector(:)) rot_q_vector(2) = dot_product(rotate_quad(2,:),q_vector(:)) rot_q_vector(3) = dot_product(rotate_quad(3,:),q_vector(:)) ! ! compute and add in quadrature term ! numerator = w1gauss(j) * w2gauss(k) * dot_product(coil_current_vec,current_vector) denominator = sqrt(dot_product(rot_c_vector-rot_q_vector, rot_c_vector-rot_q_vector)) l12_lower = l12_lower + numerator/denominator end do end do end do (-Snip-) At Ofast, the k loop is unrolled and vectorized. When -fprotect-parens is enabled at -Ofast, q_vector(2) = 0.5_longreal * b1 * (y2gauss(k) - 1.0_longreal) and part of the expression rot_q_vector(1) = dot_product(rotate_quad(1,:),q_vector(:)) are hoisted out of the j loop: But in case when -fprotect-parens is disabled, the expressions are not hoisted out of the loop. Observations: 1) In gimple, when -fprotect-parens is disabled, the expression (y2gauss(k) - 1.0_longreal) is reassociated as shown below. induct2.f90.080t.dse1 (-Snip-) D.8701_385 = y2gauss[D.8696_378]; D.8702_386 = D.8701_385 - 1.0e+0; D.8703_387 = b1_148 * D.8702_386; D.8704_388 = D.8703_387 * 5.0e-1; (-Snip-) induct2.f90.081.reassoc1 (-Snip-) D.8701_385 = y2gauss[D.8696_378]; D.8702_386 = D.8701_385 + -1.0e+0; D.8703_387 = b1_148 * 5.0e-1; D.8704_388 = D.8703_387 * D.8702_386; (-Snip-) However with -fprotect-parens is enabled, induct2.f90.081.reassoc1 (-Snip-) D.8814_395 = y2gauss[D.8808_387]; D.8815_396 = D.8814_395 - 1.0e+0; D.8816_397 = ((D.8815_396)); D.8817_398 = b1_154 * 5.0e-1; D.8818_399 = D.8817_398 * D.8816_397 (-Snip-) 2) Due to the reassociation that happens when -fprotect-parens is disabled, the RTL generated for the expression 0.5_longreal * b1 * (y2gauss(k) - 1.0_longreal) also changes. For example first 2 elements in y2guass array, the RTL is
[Bug middle-end/49363] [feature request] multiple target attribute (and runtime dispatching based on cpuid)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #10 from Sriraman Tallam tmsriram at google dot com 2011-10-28 17:28:23 UTC --- On Fri, Oct 28, 2011 at 7:00 AM, vincenzo.innocente at cern dot ch gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49363 --- Comment #9 from vincenzo Innocente vincenzo.innocente at cern dot ch 2011-10-28 14:00:18 UTC --- That's a pity. It would be very useful though to have at least a patch to test so that we can have something to use in prototypes and eventually a working solution for 4.8 Still working on it. Will keep you posted as soon as I have a patch to test. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2011-10-28 17:28:54 UTC --- What's the version of your texinfo.tex? I get no such error with version 2010-06-17.11.
[Bug middle-end/50902] intVar/dinternal.cc ICEs at -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50902 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2011-10-28 17:34:30 UTC --- Created attachment 25647 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25647 preprocessed source for marvin/MarvinNOEPotential.cc
[Bug middle-end/50902] intVar/dinternal.cc ICEs at -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50902 --- Comment #5 from Jack Howarth howarth at nitro dot med.uc.edu 2011-10-28 17:35:50 UTC --- The attached MarvinNOEPotential.ii preprocessed source is another instance of this bug in the xplor-nih 2.27 build... g++-fsf-4.7 -c MarvinNOEPotential.ii -O2 -ftree-vectorize -fpermissive -DX_MMAP_FLAGS=0 -DFORTRAN_INIT -fno-common -DDARWIN -D_REENTRANT -DNDEBUG -DCPLUSPLUS -DUSE_CDS_NAMESPACE -LANG:std In file included from MarvinNOEPotential.cc:2787:0: /Users/howarth/xplor-nih-2.27/CDSlib/cdsMatrix.cc: In constructor ‘CDSMatrixBaseT::CDSMatrixBase(int, int, const T) [with T = bool]’: /Users/howarth/xplor-nih-2.27/CDSlib/cdsMatrix.cc:24:1: internal compiler error: in build_vector_from_val, at tree.c:1382 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c/50521] -fstrict-volatile-bitfields is not strict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521 --- Comment #12 from Henrik Nordström henrik at henriknordstrom dot net 2011-10-28 17:46:15 UTC --- Regarding the double load. In a statement like a = b, both a be should be individually accessed even if they refer to the same storage. So bitfield.bits.a = bitfield.bits.c should load the bitfield variable twice, once for reading the rvalue and once for masking the lvalue assignment. See 7.1.7.5 second and third paragraph and the note just after. Regarding STRICT_ALIGNMENT, not strictly needed on ARM i think. Smaller accesses than the base type is acceptable, as long as it's aligned to the matching access size (8/16/32/64 bit) and on ARMv7 unaligned access is allowed, but at a performance penalty. And this change is technically unrelated to strict-volatile-bitfields even if there is overlap.
[Bug target/49313] Inefficient libgcc implementations for avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49313 --- Comment #11 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-10-28 17:48:04 UTC --- Author: gjl Date: Fri Oct 28 17:47:56 2011 New Revision: 180620 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180620 Log: PR target/49313 * config/avr/avr.md (parityhi2): Expand allowing pseudos. (*parityhi2): New pre-reload insn-and-split to map 16-bit parity to the libgcc insn. (*parityqihi2): Same for 8-bit parity. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 --- Comment #2 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-10-28 18:22:43 UTC --- On Fri, Oct 28, 2011 at 05:28:54PM +, sch...@linux-m68k.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2011-10-28 17:28:54 UTC --- What's the version of your texinfo.tex? I get no such error with version 2010-06-17.11. Unless another version is being used, I have troutmask:sgk[203] svn info gcc/doc/include/texinfo.tex Path: gcc/doc/include/texinfo.tex Name: texinfo.tex URL: svn+ssh://ka...@gcc.gnu.org/svn/gcc/trunk/gcc/doc/include/texinfo.tex Repository Root: svn+ssh://ka...@gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 180618 Node Kind: file Schedule: normal Last Changed Author: rwild Last Changed Rev: 133320 Last Changed Date: 2008-03-18 12:23:53 -0700 (Tue, 18 Mar 2008) Text Last Updated: 2009-05-17 13:16:39 -0700 (Sun, 17 May 2009)
[Bug bootstrap/50903] configure:14607: error: GNU Fortran is not working;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50903 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org 2011-10-28 18:30:20 UTC --- (In reply to comment #0) ../configure --prefix=/opt/gcc --disable-multilib --with-gmp=/opt/gcc --with-mpfr=/opt/gcc --with-mpc=/opt/gcc --enable-languages=c,c++,fortran Have you read the installation instructions at http://gcc.gnu.org/install/
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 --- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2011-10-28 18:33:57 UTC --- That's not the one being used.
[Bug c++/50864] [4.6/4.7 Regression] ICE with decltype and declval from another namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50864 --- Comment #12 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-10-28 18:40:29 UTC --- Author: paolo Date: Fri Oct 28 18:40:22 2011 New Revision: 180623 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180623 Log: /cp 2011-10-28 Paolo Carlini paolo.carl...@oracle.com PR c++/50864 * pt.c (tsubst_copy_and_build): Fix qualified_name_lookup_error call in case COMPONENT_REF. /testsuite 2011-10-28 Paolo Carlini paolo.carl...@oracle.com PR c++/50864 * g++.dg/template/crash109.C: New. Added: trunk/gcc/testsuite/g++.dg/template/crash109.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50864] [4.6 Regression] ICE with decltype and declval from another namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50864 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Summary|[4.6/4.7 Regression] ICE|[4.6 Regression] ICE with |with decltype and declval |decltype and declval from |from another namespace |another namespace --- Comment #13 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-28 18:41:49 UTC --- Fixed in mainline so far.
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900
--- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-10-28 19:02:20 UTC ---
On Fri, Oct 28, 2011 at 06:33:57PM +, sch...@linux-m68k.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900
--- Comment #3 from Andreas Schwab sch...@linux-m68k.org 2011-10-28
18:33:57 UTC ---
That's not the one being used.
Well, the only other version that I have, which could be the
problem, was installed with teTeX
troutmask:kargl[208] more /usr/local/share/texmf/tex/texinfo/texinfo.tex
% texinfo.tex -- TeX macros to handle Texinfo files.
%
% Load plain if necessary, i.e., if running under initex.
\expandafter\ifx\csname fmtname\endcsname\relax\input plain\fi
%
\def\texinfoversion{2011-05-23.16}
I'm in the middle of a new bootstrap. I'll see if I can find
out more information in an hour or so.
[Bug rtl-optimization/50904] Induct benchmark of polyhedron slows down when -fno-protect-parens is enabled by -Ofast.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-28 CC||bur...@net-b.de Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-10-28 19:14:18 UTC --- On a Core2Duo the run time when induct is compiled with -Ofast is 14.76s, when it is compiled with -fprotect-parens -Ofast, the run time is 14.29. Please provide your suggestions. As discussed with Tobias Burnus, I think the inclusion of -fno-protect-parens in -Ofast was a poor choice. I'ld like to see it reverted, not on the ground of speed, but because it violates one of the basic requirement of the Fortran standard (BTW it breaks two of my codes).
[Bug tree-optimization/50905] New: Gcc4.6.x's -ftree-parallelize-loops is effective only when using -O2/-O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50905 Bug #: 50905 Summary: Gcc4.6.x's -ftree-parallelize-loops is effective only when using -O2/-O3 -ffast-math Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: xunxun1...@gmail.com Created attachment 25648 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25648 the test I found that Gcc4.6.1 and Gcc4.6.2 -ftree-parallelize-loops is effective only when using -O2/-O3 -ffast-math on Windows or on Ubuntu. Is this right? Using my test, $gcc -ftree-parallelize-loops=2 -c main.c $nm main.o U clock T main U printf U puts U sin $gcc -O2 -ftree-parallelize-loops=2 -c main.c $nm main.o r .LC4 0008 r .LC6 U __printf_chk U clock T main U puts U sin $gcc -ffast-math -ftree-parallelize-loops=2 -c main.c $nm main.o U clock T main U printf U puts U sin $gcc -O2 -ftree-parallelize-loops=2 -ffast-math -c main.c $nm main.o r .LC5 U GOMP_parallel_end U GOMP_parallel_start U __printf_chk U clock T main t main._loopfn.0 U omp_get_num_threads U omp_get_thread_num U puts U sin Only -O2 -ftree-parallelize-loops=2 -ffast-math achieve my desired result. But I think it should generate the similar symbols below when using -ftree-parallelize-loops=2 alone: U GOMP_parallel_end U GOMP_parallel_start U omp_get_num_threads U omp_get_thread_num Am I right? Or the -ftree-parallelize-loops is such option that should be used with -O2/-O3 -ffast-math? Thanks.
[Bug c++/50870] [C++0x] [4.6/4.7 Regression] ICE with decltype, operator-, and default template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50870
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||dodji at gcc dot gnu.org
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2011-10-28 19:41:40
UTC ---
(In reply to comment #3)
Uhhm, let's reopen this: first it's a 4.6 Regression too, second we are still
not Ok for impl template, eg:
template class V
struct impl
{
template class T static T create();
};
template class T, class U, class V, class
= decltype(implV::template createT()
- implV::template createU())
struct tester { };
testerimplfloat*, int, float ti;
It is caused by revision 166179:
http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00065.html
[Bug tree-optimization/50905] Gcc4.6.x's -ftree-parallelize-loops is effective only when using -O2/-O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50905 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-10-28 19:45:18 UTC --- Am I right? Yes but the reason comes down to fp math is not associative which means it is impossible to do reductions with fp math unless you have -ffast-math (or really -fassociative-math) turned on.
[Bug tree-optimization/50905] Gcc4.6.x's -ftree-parallelize-loops is effective only when using -O2/-O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50905 xunxun xunxun1982 at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #2 from xunxun xunxun1982 at gmail dot com 2011-10-28 19:53:47 UTC --- (In reply to comment #1) Am I right? Yes but the reason comes down to fp math is not associative which means it is impossible to do reductions with fp math unless you have -ffast-math (or really -fassociative-math) turned on. But -ffast-math -ftree-parallelize-loops=2 is also no use. We must combine -ffast-math and -O2/-O3.
[Bug tree-optimization/50905] Gcc4.6.x's -ftree-parallelize-loops is effective only when using -O2/-O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50905 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-10-28 20:07:03 UTC --- Yes if you mean without -O1/-O2/-O3 -ftree-parallelize-loops does not work, this is expected as explained in the manual, -O1 enables more than the options that includes adding more optimizations.
[Bug bootstrap/50903] configure:14607: error: GNU Fortran is not working;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50903 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu 2011-10-28 20:12:12 UTC --- Probably PR49738. The llvm-gcc system compiler in Lion miscompiles gmp. If you run make check in your gmp build, you will see this. Rebuild gmp against clang. This issue is also fixed in gmp svn.
[Bug tree-optimization/50905] Gcc4.6.x's -ftree-parallelize-loops is effective only when using -O2/-O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50905 --- Comment #4 from xunxun xunxun1982 at gmail dot com 2011-10-28 20:14:38 UTC --- (In reply to comment #3) Yes if you mean without -O1/-O2/-O3 -ftree-parallelize-loops does not work, this is expected as explained in the manual, -O1 enables more than the options that includes adding more optimizations. Thanks for the information. --- I read the manual: -ftree-parallelize-loops=n Parallelize loops, i.e., split their iteration space to run in n threads. This is only possible for loops whose iterations are independent and can be arbitrarily reordered. The optimization is only profitable on multiprocessor machines, for loops that are CPU-intensive, rather than constrained e.g. by memory bandwidth. This option implies -pthread, and thus is only supported on targets that have support for -pthread. I don't notice any -O1/-O2/-O3 Optimization information here. --- If the information is true, we should only deal with the issue between -ftree-parallelize-loops=n and -ffast-math
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added CC||karl at gnu dot org --- Comment #5 from Andreas Schwab sch...@linux-m68k.org 2011-10-28 20:15:34 UTC --- 2011-02-14 Karl Berry k...@gnu.org * doc/texinfo.tex (\sectionheading): check that we are not in an environment such as @table. Report from Akim, https://savannah.gnu.org/bugs/?15514.
[Bug bootstrap/50903] configure:14607: error: GNU Fortran is not working;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50903 --- Comment #4 from Jack Howarth howarth at nitro dot med.uc.edu 2011-10-28 20:19:40 UTC --- Also be aware of http://llvm.org/bugs/show_bug.cgi?id=9571. The Xcode 4.x llvm-gcc still suffers from this bug (although it is fixed in llvm.org's llvm-gcc 2.9 release) and can't bootstrap FSF gcc. Use clang instead for the FSF gcc bootstrap as well.
[Bug target/50906] New: e500 exception unwinding under -Os causes SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906 Bug #: 50906 Summary: e500 exception unwinding under -Os causes SIGSEGV Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: kyle.d.moff...@boeing.com Created attachment 25649 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25649 Test case, part 1 The libffi test-suite is failing on an e500v2 build of GCC 4.6.1 with a segmentation fault in libgcc (called from throw() in the unwindtest.cc file). The target GCC configure options: --build/--host/--target=powerpc-linux-gnuspe --with-cpu=8548 --enable-e500_double --with-long-double-128 I have extracted it to the attached minimal test-case, compiled as follows: $ g++ -Wall -Wextra -Werror -ggdb3 -Os -c unwindtest.cc -o unwindtest.o $ g++ -Wall -Wextra -Werror -ggdb3 -Os -c unwindtestfunc.cc -o unwindtestfunc.o $ g++ -ggdb3 -Os -o unwindtest unwindtest.o unwindtestfunc.o The test fails if unwindtestfunc.cc is built with -Os, but not if it is built with -O2. The compile options for unwindtest.cc have no effect on the success or failure of the test. Cheers, Kyle Moffett -- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/
[Bug target/50906] e500 exception unwinding under -Os causes SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906 --- Comment #1 from Kyle Moffett Kyle.D.Moffett at boeing dot com 2011-10-28 20:29:53 UTC --- Created attachment 25650 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25650 Test case, part 2
[Bug target/50906] e500 exception unwinding under -Os causes SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906 --- Comment #2 from Kyle Moffett Kyle.D.Moffett at boeing dot com 2011-10-28 20:31:54 UTC --- Created attachment 25651 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25651 Assembled unwindtestfunc.cc (with -O2)
[Bug target/50906] e500 exception unwinding under -Os causes SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906 --- Comment #3 from Kyle Moffett Kyle.D.Moffett at boeing dot com 2011-10-28 20:32:18 UTC --- Created attachment 25652 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25652 Assembled unwindtestfunc.cc (with -Os)
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900
--- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-10-28 20:34:17 UTC ---
On Fri, Oct 28, 2011 at 08:15:34PM +, sch...@linux-m68k.org wrote:
2011-02-14 Karl Berry k...@gnu.org
* doc/texinfo.tex (\sectionheading): check that we are not in an
environment such as @table. Report from Akim,
https://savannah.gnu.org/bugs/?15514.
Andreas, good catch on the version difference for the texinfo.tex
file. For the record, the problematic texinfo.tex file is version
2011-05-23.16.
gmake[2]: Entering directory `/usr/home/sgk/gcc/obj4x/libiberty'
texi2pdf ../../gcc4x/libiberty/libiberty.texi
This is pdfeTeXk, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
file:line:error style messages enabled.
entering extended mode
(./../../gcc4x/libiberty/libiberty.texi
(/usr/local/share/texmf/tex/texinfo/texinfo.tex
Loading texinfo [version 2011-05-23.16]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc, environments,
defuns, macros, cross references, insertions,
(/usr/local/share/texmf/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.3 23 July 2005
) localization, formatting, and turning on texinfo input format.) [1{/usr/local
/share/texmf-var/fonts/map/pdftex/updmap/pdftex.map}] [2] [-1] Chapter 1
Chapter 2 [1] [2] (/home/sgk/gcc/gcc4x/libiberty/obstacks.texi Chapter 3
[3] [4] Cross reference values unknown; you must run TeX again. [5] [6]
[7] [8] [9] [10] [11] [12] [13]) Chapter 4 [14]
(/home/sgk/gcc/gcc4x/libiberty/functions.texi [15] [16] [17] [18] [19] [20]
[21]
Underfull \hbox (badness 1) in paragraph at lines 669--673
[]@textrm For ex-am-ple, if @textsl bin[]prefix @textrm is @texttt /alpha/beta
/gamma/gcc/delta[]@textrm , @textsl pre-fix @textrm is
[22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35])
Appendix A [36] (/home/sgk/gcc/gcc4x/libiberty/copying-lib.texi [37] [38]
[39] [40] [41] [42]
/home/sgk/gcc/gcc4x/libiberty/copying-lib.texi:480: This command can appear onl
y outside of any environment, not in environment @enumerate.
@badenverr ...temp , not @inenvironment @thisenv }
@checkenv ...@ifx @thisenv @temp @else @badenverr
[Bug rtl-optimization/50891] move2add_note_store fails to properly track register content
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50891 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-10-28 21:20:09 UTC --- We have (set (reg:DI 2) (mem)) ... (set (reg:HI 2) (const_int)) ... (set (reg:SI 2) (const_int)) Since we don't if know (set (reg:HI 2) (const_int)) will update the whole register, move2add_note_store should stop if the new mode is narrower than the previous mode.
[Bug debug/50816] [4.6.1] Discriminators are emitted in DWARF 2 format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50816 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-debug Known to work||4.6.2 Version|unknown |4.6.1 Target Milestone|--- |4.6.2
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #7 from Richard B. Kreckel kreckel at ginac dot de 2011-10-28 21:52:08 UTC --- As soon as I find a bit of time, we can also *consistently over all those cases* use __builtin_signbit, as suggested by Gaby elsewhere. I have to double check with the middle-end people that it doesn't generate library calls for the patch to be neat. We also better double check whether the results stay correct. Thinking of it... Big Ooops! It turns out the patch makes it much better but still not entirely correct. On systems that feature a signed zero, it gives incorrect results when either * __z.real() is -0.0 and signbit(__z.imag()) * __z.real() -1.0 and __z.imag() is -0.0 The first problem can be fixed by using signbit instead of -0.0, as you proposed, but the second needs more correction. The patch BC1 I'm attaching should fix these cases, too. But this is starting to look cumbersome. We are trying to construct a formula that is continuous except on the branch cut defined in C99. Why not just use the formula mentioned in CLTL2 [0] like in patch BC2 that I'm attaching? (The branch cuts of inverse trig functinos in C99 and Common Lisp are the same.) [0] http://www-prod-gif.supelec.fr/docs/cltl/clm/node129.html#SECTION001653000
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #8 from Richard B. Kreckel kreckel at ginac dot de 2011-10-28 21:53:30 UTC --- Created attachment 25653 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25653 BC1
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #9 from Richard B. Kreckel kreckel at ginac dot de 2011-10-28 21:54:07 UTC --- Created attachment 25654 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25654 BC2
[Bug libstdc++/50880] __complex_acosh() picks wrong complex branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50880 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-28 22:09:57 UTC --- Richard, I have no problems with BC2. This is code I wrote rather quickly a few years ago, adapting it from glibc, essentially, and then each year that went by, fewer and fewer systems used and tested it, because underlying C99 libc support is becoming often available (eg, for sure Linux and Darwin). Thus, please sleep on this, let's wait for comments from other people, and say, in a week or so we'll finalize the code for 4.7. Thanks again!
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 karl at freefriends dot org changed: What|Removed |Added CC||karl at freefriends dot org --- Comment #7 from karl at freefriends dot org 2011-10-28 22:19:02 UTC --- I believe that if you use the latest official version of the Texinfo for lgpl 2.1, the problem will go away. http://www.gnu.org/licenses/lgpl-2.1.texi ... It was a bug (among several others) in the lgpl-2.1.texi as originally released. (You'll also need to insert the @node and @appendixsubsec into the calling file; the current lgpl-2.1.texi doesn't have them. That is the way rms always intended those license .texi's to work, since different documents need different sectioning levels for the license.)
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 --- Comment #8 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-10-28 22:50:49 UTC --- On Fri, Oct 28, 2011 at 10:19:02PM +, karl at freefriends dot org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 karl at freefriends dot org changed: What|Removed |Added CC||karl at freefriends dot org --- Comment #7 from karl at freefriends dot org 2011-10-28 22:19:02 UTC --- I believe that if you use the latest official version of the Texinfo for lgpl 2.1, the problem will go away. http://www.gnu.org/licenses/lgpl-2.1.texi ... It was a bug (among several others) in the lgpl-2.1.texi as originally released. You'll need to be a little bit more specific in what you believe. I'm using texinfo from FreeBSD ports collection, and it is based on texinfo-4.13.tar.gz from http://ftp.gnu.org/gnu/texinfo/, which appears to be newer version.
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 --- Comment #9 from karl at freefriends dot org 2011-10-28 22:53:26 UTC --- I was completely specific. I am talking about fixing copying-lib.texi. I gave a url to the current canonical version for that document.
[Bug middle-end/50907] New: [4.7 Regression] EDGE_CROSSING incorrectly set across same section with -freorder-blocks-and-partition -fPIC -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50907 Bug #: 50907 Summary: [4.7 Regression] EDGE_CROSSING incorrectly set across same section with -freorder-blocks-and-partition -fPIC -fprofile-use Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: belys...@depni.sinp.msu.ru Target: x86_64-unknown-linux-gnu compilation of gcc.dg/tree-prof/pr45354.c with -O -freorder-blocks-and-partition -fPIC -fprofile-use fails: $ gcc pr45354.c -O -freorder-blocks-and-partition -fPIC -fprofile-generate $./a.out $ gcc pr45354.c -O -freorder-blocks-and-partition -fPIC -fprofile-use pr45354.c: In function 'test_ifelse2': pr45354.c:23:1: error: EDGE_CROSSING incorrectly set across same section pr45354.c:23:1: internal compiler error: verify_flow_info failed (testcase is attached also here: http://gcc.gnu.org/bugzilla/attachment.cgi?id=22560 )
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 --- Comment #10 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-10-28 23:18:46 UTC --- On Fri, Oct 28, 2011 at 10:53:26PM +, karl at freefriends dot org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 --- Comment #9 from karl at freefriends dot org 2011-10-28 22:53:26 UTC --- I was completely specific. You wrote I believe that if you use the latest official version of the Texinfo for lgpl 2.1, the problem will go away. AFAICT, texinfo-4.13.tar.gz is the latest official release of texinfo. I am talking about fixing copying-lib.texi. I gave a url to the current canonical version for that document. http://www.gnu.org/licenses/lgpl-2.1.texi is not in the texinfo cvs repository! So, I don't see how it is even a part of the latest official version. I'm guessing someone will understand what you meant and fix the problem.
[Bug c++/50870] [C++0x] [4.6/4.7 Regression] ICE with decltype, operator-, and default template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50870 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-28 23:23:43 UTC --- Thanks HJ. Dodji, I tried to help a bit with these issues and made some progress, thanks to Jason's help, of course. But this remaining issue is probably too hard to debug for me, given my still limited understanding of the front-end. If you could help it would be great. Note: now that PR50864 is fixed in mainline, we don't ICE anymore for the testcase in Comment #3, we reject it.
[Bug other/50900] 'gmake pdf' fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50900 --- Comment #11 from karl at freefriends dot org 2011-10-28 23:25:25 UTC --- By the Texinfo for lgpl 2.1 I mean the Texinfo source document for LGPLv2.1. To be even more specific, what's needed is to replace copying-lib.texi with the contents of http://www.gnu.org/licenses/lgpl-2.1.texi (and making the other adjustments as I wrote about). Then the libiberty document will process with any released texinfo.tex.
[Bug c++/50901] [4.6/4.7 Regression] ICE: in build_new_op, at cp/call.c:5016
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50901 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-10-28 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.6.3 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-28 23:43:48 UTC --- On it. Seems indeed trivial.
