[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #26 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-29 06:47:41 UTC --- (In reply to comment #24) Your code in comment #14 is (I believe) invalid, and gfortran is issuing the correct error message. I get: Error: Variable 'length' cannot appear in the expression at (1) However, I believe that allocate(character(len=length)::string) is valid. One has (F2008): R626 allocate-stmt is ALLOCATE ( [ type-spec :: ] allocation-list [, alloc-opt-list ] ) with R402 type-spec is intrinsic-type-spec or derived-type-spec with R404 intrinsic-type-spec is [...] or CHARACTER [ char-selector ] with R420 char-selector is length-selector [or ...] with R421 length-selector is ( [ LEN = ] type-param-value ) [or ...] Thus, I do not see any syntax problems; I also couldn't find any constraint or other reason which renders the code in comment #14 invalid.
[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|WAITING |RESOLVED Resolution||FIXED --- Comment #5 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-29 07:01:38 UTC --- (In reply to comment #4) On Atom with -m32 -O2 -march=atom, 1. GCC 4.6.1: ./4.6 64.16s user 0.01s system 99% cpu 1:04.18 total 2. GCC 4.7.0 20110819: ./0819 69.73s user 0.01s system 99% cpu 1:09.76 total 3. GCC 4.7.0 20110826: ./0826 64.30s user 0.02s system 99% cpu 1:04.33 total Has this problem been fixed? Confirm. Problem has gone.
[Bug c/50219] Combine pass generated wrong code for unsigned char comparison on MIPS target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50219 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-29 07:19:51 UTC --- GCC 3.4.4 is no longer maintained, if 4.3 works (which is also no longer maintained) this bug is considered fixed.
[Bug tree-optimization/50204] [4.5/4.6/4.7 Regression] Missed fully redundant load found in crafty (SPEC 2k)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50204 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-29 07:29:57 UTC --- The loop over PHI args is a little hard to follow, but yeah, that's how it should work. Eventually we can put this in with a new --param telling the maximum number of PHI args to consider (and defaulting it to two). I'd probably keep the n == 1 handling in the main function separately instead of trying to handle it via the loop. Then I'd pre-seed the first arg which should make the loop a little easier to follow.
[Bug fortran/50221] Allocatable string length fails with array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221 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-08-29 07:32:18 UTC --- Unfortunately, there are still some issues with deferred-length character strings - including arrays; see also bug 45170 comment 9.
[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|RESOLVED|REOPENED Resolution|FIXED | --- Comment #6 from Ilya Enkovich enkovich.gnu at gmail dot com 2011-08-29 07:39:09 UTC --- It appeared problem was fixed in reproducer but was not fixed in original test case. I'll prepare fixed reproducer.
[Bug tree-optimization/50204] [4.5/4.6/4.7 Regression] Missed fully redundant load found in crafty (SPEC 2k)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50204 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-29 07:57:29 UTC --- On a 2nd thought the work should be still linear, even for N PHI args the way the merging is constructed (one arg has to dominate the other - the only exception is the diamond case which has a constant cost of two). So with some cleanup (essentially peel the first iteration of the loop) the patch should be ok as-is.
[Bug target/50116] [4.6 Regression] internal compiler error: in decode_addr_const, at varasm.c:2632
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50116 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-29 08:03:45 UTC --- Author: rguenth Date: Mon Aug 29 08:03:34 2011 New Revision: 178155 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178155 Log: 2011-08-29 Richard Guenther rguent...@suse.de PR middle-end/50116 * varasm.c (decode_addr_const): Handle MEM_REF[X, OFF]. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/varasm.c
[Bug target/50116] [4.6 Regression] internal compiler error: in decode_addr_const, at varasm.c:2632
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50116 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-29 08:04:08 UTC --- Should be fixed now.
[Bug tree-optimization/50222] ICE with -O{1,2} -funswitch-loops -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50222
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-08-29
CC||spop at gcc dot gnu.org
Component|c |tree-optimization
Ever Confirmed|0 |1
Known to fail||4.4.6, 4.5.3, 4.6.1, 4.7.0
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-29
08:20:48 UTC ---
Confirmed, reducing.
Program received signal SIGSEGV, Segmentation fault.
0x00c11969 in rename_use_op (op_p=0x75bc4230)
at /space/rguenther/src/svn/gcc-4_6-branch/gcc/tree-vect-loop-manip.c:55
55if (TREE_CODE (USE_FROM_PTR (op_p)) != SSA_NAME)
(gdb) p *op_p
$2 = {prev = 0x0, next = 0x0, loc = {stmt = 0x75bc4200,
ssa_name = 0x75bc4200}, use = 0x75bc4250}
(gdb) call debug_gimple_stmt (0x75bc4200)
key_frame_413 = PHI (90)
a broken PHI.
Broken since -ftree-loop-distribution is available.
[Bug tree-optimization/50222] ICE with -O{1,2} -funswitch-loops -ftree-loop-distribution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50222
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-29
08:39:42 UTC ---
Reduced testcase (only ICEs 4.6.1 and trunk):
typedef struct AVProgram {
void *priv_data;
unsigned int nb_streams;
} AVFormatContext;
typedef struct {
unsigned short flags;
unsigned char stream_id;
} FrameCode;
typedef struct {
FrameCode frame_code[256];
} NUTContext;
void build_frame_code(AVFormatContext *s, int stream_id,
int is_audio, int pred_count)
{
NUTContext *nut = s-priv_data;
int keyframe_0_esc = s-nb_streams 2;
int start2 = 1 + 253*stream_id / s-nb_streams;
int key_frame;
for(key_frame=0; key_frame2; key_frame++)
{
FrameCode *ft;
if (is_audio keyframe_0_esc key_frame==0)
continue;
ft= nut-frame_code[start2];
ft-flags|= 3;
ft-stream_id= stream_id;
}
}
[Bug debug/50215] [4.7 Regression] FAIL: gcc.dg/guality/pr45882.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50215 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 08:55:07 UTC --- Author: jakub Date: Mon Aug 29 08:55:02 2011 New Revision: 178167 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178167 Log: PR debug/50215 * var-tracking.c (create_entry_value): Call cselib_lookup_from_insn before adding ENTRY_VALUE to val-locs. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c
[Bug target/49987] [4.7 Regression] gcc.c-torture/compile/pr34856.c fails on powerpc-darwin9 from r176228
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49987 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||aldyh at redhat dot com, ||dje.gcc at gmail dot com, ||pthaugen at us dot ibm.com --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-29 08:58:26 UTC --- Note that while gcc.c-torture/compile/pr34856.c does not fail on powerpc64-unknown-linux-gnu, gcc.dg/pr34856.c does (see http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg03221.html ). Could a user of powerpc*-linux-* try the patch at http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01861.html ?
[Bug debug/50215] [4.7 Regression] FAIL: gcc.dg/guality/pr45882.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50215 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 09:04:12 UTC --- Fixed.
[Bug libfortran/50192] Wrong character comparision with wide strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50192 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-08-29 09:05:18 UTC --- Author: tkoenig Date: Mon Aug 29 09:05:11 2011 New Revision: 178173 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178173 Log: 2011-08-29 Thomas Koenig tkoe...@gcc.gnu.org PR libfortran/50192 * intrinsics/string_intrinsics.c (memcmp_char4): New function. * intrinsics/string_intrinsics_inc.c: New macro MEMCMP, either set to memcmp or memcmp_char4. (compare_string): Use MEMCMP, with correct size for it. * libgfortran.h: Add prototype for memcmp_char4. 2011-08-29 Thomas Koenig tkoe...@gcc.gnu.org PR libfortran/50192 * gfortran.dg/widechar_compare_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/widechar_compare_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/string_intrinsics.c trunk/libgfortran/intrinsics/string_intrinsics_inc.c trunk/libgfortran/libgfortran.h
[Bug debug/50203] ICE: in output_loc_list, at dwarf2out.c:8188 with --param max-vartrack-expr-depth=140
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50203 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 09:08:45 UTC --- DWARF has a fixed limit for the size of expression in .debug_loc - 64KB, so with insane high parameters you can trigger it.
[Bug c++/50207] [4.7 Regression] G++ segv's on reduced test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50207 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-29 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 10:04:09 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=177647
[Bug c++/50207] [4.7 Regression] G++ segv's on reduced test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50207 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 10:05:34 UTC --- Oops, sorry, that was for PR50208.
[Bug tree-optimization/50208] [4.7 Regression] ICE: in vinfo_for_stmt at tree-vectorizer.h:598 with -ftree-vectorize -fno-tree-fre -fno-tree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50208 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-29 CC||jakub at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 10:05:42 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=177647
[Bug debug/50203] ICE: in output_loc_list, at dwarf2out.c:8188 with --param max-vartrack-expr-depth=140
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50203 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-29 10:12:00 UTC --- Shouldn't we limit the max of the param then?
[Bug tree-optimization/50208] [4.7 Regression] ICE: in vinfo_for_stmt at tree-vectorizer.h:598 with -ftree-vectorize -fno-tree-fre -fno-tree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50208 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 10:44:42 UTC --- The problem is that def_stmt is a gimple stmt from before the loop and new_loop_vec_info only initializes gimple_uid of stmts in the loop being processed. So perhaps before testing for vinfo_for_stmt it should || !gimple_bb (def_stmt) || !flow_bb_inside_loop_p (loop, gimple_bb (def_stmt)) and perhaps give up in those cases too? Loop would need to be initialized, perhaps similarly to vect_recog_dot_prod_pattern? loop_vec_info loop_info = STMT_VINFO_LOOP_VINFO (vinfo_for_stmt (stmt)); struct loop *loop = LOOP_VINFO_LOOP (loop_info); ? I have no idea whether this can be invoked from slp vectorizer and what to do in that case.
[Bug debug/50203] ICE: in output_loc_list, at dwarf2out.c:8188 with --param max-vartrack-expr-depth=140
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50203 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 10:48:39 UTC --- But what would be a good limit for the parameter? On some targets some people have managed to trigger it even with the parameter 20 which has been the default for a while, but on other code/targets even a few hundred is fine. As I wrote on gcc-patches I think, what we could do is just drop the expression on the floor instead of asserting if it is = 64KB, or we could stick it into a DW_TAG_dwarf_procedure (though, I think = 64KB location expressions ought to be rarely useful).
[Bug debug/50203] ICE: in output_loc_list, at dwarf2out.c:8188 with --param max-vartrack-expr-depth=140
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50203 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-29 11:05:19 UTC --- (In reply to comment #3) But what would be a good limit for the parameter? On some targets some people have managed to trigger it even with the parameter 20 which has been the default for a while, but on other code/targets even a few hundred is fine. As I wrote on gcc-patches I think, what we could do is just drop the expression on the floor instead of asserting if it is = 64KB, or we could stick it into a DW_TAG_dwarf_procedure (though, I think = 64KB location expressions ought to be rarely useful). I suppose we can't know in advance and turn the max-vartrack-expr-depth param into a max-dwarf2-expr-size param? That we could limit to 64kb ...
[Bug c++/50207] [4.7 Regression] G++ segv's on reduced test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50207 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 11:18:10 UTC --- I'd say this is invalid, TYPE_TRANSPARENT_AGGR is an ugly hack and we should perhaps limit it just to scalar fields.
[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char-int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176 --- Comment #5 from Igor Zamyatin izamyatin at gmail dot com 2011-08-29 11:48:12 UTC --- Yes, looks like this revision is the reason
[Bug middle-end/48722] [4.7 Regression] ICE in df_refs_verify() with -mno-push-args
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48722 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 11:52:26 UTC --- Author: jakub Date: Mon Aug 29 11:52:22 2011 New Revision: 178208 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178208 Log: PR middle-end/48722 * emit-rtl.c (unshare_all_rtl_again): For CALL_INSNs, reset_used_flags also in CALL_INSN_FUNCTION_USAGE. (verify_rtl_sharing): Likewise and verify_rtx_sharing in there too. (unshare_all_rtl_in_chain): For CALL_INSNs copy_rtx_if_shared also CALL_INSN_FUNCTION_USAGE. * gcc.target/i386/pr48722.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr48722.c Modified: trunk/gcc/ChangeLog trunk/gcc/emit-rtl.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50224] New: [c++0x]g++ complains unused parameter but it is referenced in lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50224
Bug #: 50224
Summary: [c++0x]g++ complains unused parameter but it is
referenced in lambda
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: len...@gmail.com
#include vector
#include algorithm
#include memory
struct T;
struct S {
void m(T t);
};
struct C {
std::vectorstd::unique_ptrS _s;
void m(T t) // ERROR here
{
std::for_each(_s.begin()
, _s.end()
, [](std::unique_ptrS const s)
{
s-m(t); // ``t`` is referenced here
});
}
};
Compile that codes with
$ g++ test.cpp -c -Wunused-parameter -std=c++0x -Werror
and g++ will complain
test.cpp:14:10: error: unused parameter ‘t’ [-Werror=unused-parameter]
But if the parameter type changed to built in primitives, the error won't
occur, say, like
#include vector
#include algorithm
#include memory
struct S {
void m(int t); // changed to int
};
struct C {
std::vectorstd::unique_ptrS _s;
void m(int t) // changed to int
{
std::for_each(_s.begin()
, _s.end()
, [](std::unique_ptrS const s)
{
s-m(t);
});
}
};
My compiler and system info:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.6-20110819/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --enable-gnu-unique-object
--enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto
--enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--disable-multilib --disable-libssp --disable-libstdcxx-pch
--enable-checking=release
Thread model: posix
gcc version 4.6.1 20110819 (prerelease) (GCC)
There is a similar bug I've reported before
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49339
marked as duplicated of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49251
Hope that will help.
[Bug middle-end/48722] [4.7 Regression] ICE in df_refs_verify() with -mno-push-args
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48722 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 12:31:12 UTC --- Fixed.
[Bug c++/50224] [c++0x]g++ complains unused parameter but it is referenced in lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50224 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-29 12:39:36 UTC --- (In reply to comment #0) gcc version 4.6.1 20110819 (prerelease) (GCC) There is a similar bug I've reported before http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49339 marked as duplicated of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49251 Hope that will help. As that bug indicates, this is fixed in 4.6.1 Please use an FSF release and report a bug to ArchLinux that their GCC version string is misleading, it should show that it is a modified GCC. 4.6.1 20110819 (prerelease) is nonsensical because 4.6.1 was released in June, so whatever they're shipping should be described in the version string. *** This bug has been marked as a duplicate of bug 49251 ***
[Bug c++/49251] [C++0x][parameter pack expanding] unused parameter warning with unpacking empty tuples
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49251 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-29 12:39:36 UTC --- *** Bug 50224 has been marked as a duplicate of this bug. ***
[Bug c++/50207] [4.7 Regression] G++ segv's on reduced test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50207 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 12:48:10 UTC --- Created attachment 25125 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25125 gcc47-pr50207.patch Untested patch which adds that limitation. decimal/decimal still seems to work.
[Bug c++/50220] [C++0x] ICE when capturing a by-reference template function argument in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50220 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-29 CC||jason at gcc dot gnu.org Ever Confirmed|0 |1
[Bug c++/50224] [c++0x]g++ complains unused parameter but it is referenced in lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50224 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-29 13:14:01 UTC --- I've just tested with the official 4.6.1 release: gcc version 4.6.1 (GCC) and the 4.6-20110819 snapshot: gcc version 4.6.2 20110819 (prerelease) (GCC) and the tip of the 4.6 branch: gcc version 4.6.2 20110829 (prerelease) [gcc-4_6-branch revision 178215] (GCC) and there's no warning or error, so I don't know what the ArchLinux package is based on. It looks like the 20110819 snapshot with a misleading BASE-VER, but that shouldn't warn.
[Bug c++/50224] [c++0x]g++ complains unused parameter but it is referenced in lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50224 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|RESOLVED|NEW Last reconfirmed||2011-08-29 CC||jason at gcc dot gnu.org Resolution|DUPLICATE | Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-08-29 13:33:03 UTC --- Doh! sorry, I was testing the wrong file out of the two examples, for some reason I named the first one 2.cc and the second one 1.cc ... with embarrassing consequences ;) Confirmed, as you're right this isn't fixed (but the ArchLinux version string is still misleading!) Jason, PR 49251 still occurs for parameters of non-builtin types
[Bug libstdc++/50118] node-based containers cannot use allocators with explicit constructor template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50118 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-08-29 13:40:39 UTC --- Author: paolo Date: Mon Aug 29 13:40:33 2011 New Revision: 178230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178230 Log: 2011-08-29 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/50118 * include/bits/stl_list.h (_List_base:: _List_base(const allocator_type)): Remove. (_List_base::_List_base(const _Node_alloc_type)): Add. (list:list(const allocator_type), list(size_type, const value_type, const allocator_type), list(initializer_list, const allocator_type), list(_InputIterator, _InputIterator, const allocator_type), insert(iterator, size_type, const value_type), insert(iterator, _InputIterator, _InputIterator)): Adjust. * include/bits/stl_tree.h (_Rb_tree::_Rb_tree(const _Compare, const allocator_type)): Fix. * include/bits/stl_map.h (map::map(const _Compare, const allocator_type), map(initializer_list, const _Compare, const allocator_type), map(_InputIterator, _InputIterator, const _Compare, const allocator_type), get_allocator): Adjust. * include/bits/stl_set.h (set::set(const _Compare, const allocator_type), set(initializer_list, const _Compare, const allocator_type), set(_InputIterator, _InputIterator, const _Compare, const allocator_type), get_allocator): Likewise. * include/bits/stl_multimap.h (multimap::multimap(const _Compare, const allocator_type), multimap(initializer_list, const _Compare, const allocator_type), multimap(_InputIterator, _InputIterator, const _Compare, const allocator_type), get_allocator): Likewise. * include/bits/stl_multiset.h (multiset::multiset(const _Compare, const allocator_type), multiset(initializer_list, const _Compare, const allocator_type), multiset(_InputIterator, _InputIterator, const _Compare, const allocator_type), get_allocator): Likewise. * include/bits/forward_list.h (_Fwd_list_base:: _Fwd_list_base(const _Alloc), _Fwd_list_base(const _Fwd_list_base, const _Alloc), _Fwd_list_base(_Fwd_list_base, const _Alloc)): Remove. (_Fwd_list_base::_Fwd_list_base(const _Node_alloc_type), _Fwd_list_base(const _Fwd_list_base, const _Node_alloc_type), _Fwd_list_base(_Fwd_list_base, const _Node_alloc_type)): Add. (forward_list::forward_list(const _Alloc), forward_list(const forward_list, const _Alloc), forward_list(forward_list, const _Alloc), forward_list(size_type, const _Tp, const _Alloc), forward_list(_InputIterator, _InputIterator, const _Alloc), forward_list(std::initializer_list, const _Alloc), get_allocator): Adjust. * include/bits/forward_list.tcc * testsuite/util/testsuite_allocator.h (ExplicitConsAlloc): Add. * testsuite/23_containers/unordered_map/requirements/ explicit_instantiation/5.cc: New. * testsuite/23_containers/multimap/requirements/ explicit_instantiation/5.cc: Likewise. * testsuite/23_containers/multimap/requirements/ explicit_instantiation/5_c++0x.cc: Likewise. * testsuite/23_containers/set/requirements/explicit_instantiation/ 5.cc: Likewise. * testsuite/23_containers/set/requirements/explicit_instantiation/ 5_c++0x.cc: Likewise. * testsuite/23_containers/unordered_multimap/requirements/ explicit_instantiation/5.cc: Likewise. * testsuite/23_containers/forward_list/requirements/ explicit_instantiation/5.cc: Likewise. * testsuite/23_containers/unordered_set/requirements/ explicit_instantiation/5.cc: Likewise. testsuite/23_containers/multiset/requirements/explicit_instantiation/ 5.cc: Likewise. * testsuite/23_containers/multiset/requirements/ explicit_instantiation/5_c++0x.cc: Likewise. * testsuite/23_containers/list/requirements/explicit_instantiation/ 5_c++0x.cc: Likewise. * testsuite/23_containers/list/requirements/explicit_instantiation/ 5.cc: Likewise. * testsuite/23_containers/unordered_multiset/requirements/ explicit_instantiation/5.cc: Likewise. * testsuite/23_containers/map/requirements/explicit_instantiation/ 5.cc: Likewise. * testsuite/23_containers/map/requirements/explicit_instantiation/ 5_c++0x.cc: Likewise. * testsuite/23_containers/forward_list/requirements/dr438/ assign_neg.cc: Adjust dg-error line number. * testsuite/23_containers/forward_list/requirements/dr438/ insert_neg.cc: Likewise. * testsuite/23_containers/forward_list/requirements/dr438/ constructor_1_neg.cc: Likewise. * testsuite/23_containers/forward_list/requirements/dr438/ constructor_2_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/assign_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/insert_neg.cc: Likewise. * testsuite/23_containers/list/requirements/dr438/ constructor_1_neg.cc: Likewise. *
[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char-int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |NEW CC||rguenth at gcc dot gnu.org
[Bug libstdc++/50118] node-based containers cannot use allocators with explicit constructor template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50118 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-08-29 13:43:09 UTC --- Fixed for 4.7.
[Bug fortran/50225] New: The allocation status for polymorphic allocatable variables is not set properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50225 Bug #: 50225 Summary: The allocation status for polymorphic allocatable variables is not set properly Classification: Unclassified Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.markus...@gmail.com If you compile the program below with -fcheck=all, it fails, claiming that the result variable in the function add_vector() is already allocated. The error disappears when you change class(point2d) to type(point2d). (In a more elaborate version of the program, it also fails without this option and with this option there is a segmentation fault.) module points2d3d implicit none type point2d real :: x, y end type contains subroutine print( point ) class(point2d) :: point write(*,'(2f10.4)') point%x, point%y end subroutine subroutine random_vector( point ) class(point2d) :: point call random_number( point%x ) call random_number( point%y ) point%x = 2.0 * (point%x - 0.5) point%y = 2.0 * (point%y - 0.5) end subroutine function add_vector( point, vector ) class(point2d), intent(in) :: point, vector class(point2d), allocatable :: add_vector allocate( add_vector ) add_vector%x = point%x + vector%x add_vector%y = point%y + vector%y end function end module points2d3d program random_walk use points2d3d type(point2d), target :: point_2d, vector_2d class(point2d), pointer :: point, vector integer :: i point = point_2d vector = vector_2d write(*,*) 'Two-dimensional walk:' do i=1,10 call random_vector(point) call random_vector(vector) call print(add_vector(point, vector)) end do end program random_walk
[Bug rtl-optimization/50212] [4.7 Regression] ICE: in ei_container, at basic-block.h:610 with -fnon-call-exceptions -freorder-blocks-and-partition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50212 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-08-29 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 13:44:11 UTC --- Created attachment 25126 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25126 gcc47-pr50212.patch Untested patch, which handles this similarly to for_each_eh_label.
[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191 --- Comment #5 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-08-29 13:45:36 UTC --- Jakub, I don't see -fprofile-generate in your list of options. What Peter gave you was the link command that exposed the problem, but the error occurred when compiling chgpen.fppized.f with the options given. The original options from the build log were: /home/wschmidt/gcc/install/gcc-mainline-base/bin/gfortran -c -o chgpen.fppized.o -fprofile-generate -g -save-temps=obj -ffast-math -O3 -mveclibabi=mass -mcpu=power7 -mrecip=rsqrt -fpeel-loops -funroll-loops -ftree-vectorize -fvect-cost-model -O3 -mvsx -maltivec -mpopcntd -m64 -ftree-loop-linear chgpen.fppized.f which, after -v, I was able to whittle down to: /home/wschmidt/gcc/install/gcc-mainline-base/libexec/gcc/powerpc64-linux/4.7.0/f951 chgpen.fppized.f -g -O3 -fprofile-generate -ffast-math -funroll-loops -o chgpen.fppized.s I should have left -mcpu=power7 and -m64 on there for you; sorry about that. Try: /home/wschmidt/gcc/install/gcc-mainline-base/libexec/gcc/powerpc64-linux/4.7.0/f951 chgpen.fppized.f -g -O3 -fprofile-generate -ffast-math -funroll-loops -mcpu=power7 -m64 -o chgpen.fppized.s Thanks! Sorry for the late response, I was out ill on Friday/Saturday.
[Bug fortran/50225] The allocation status for polymorphic allocatable variables is not set properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50225 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-29 13:49:48 UTC --- On x86_64-apple-darwin10 I don't need the option -fcheck=all to get the run-timr error. However the error goes away with any optimization above -O1 (at least all those I have tried;-). This is also true for the original code posted at http://gcc.gnu.org/ml/fortran/2011-08/msg00239.html which gives Two-dimensional walk: 1.08830.1832 1.06180.1794 0.97650.0804 0.94590.0489 0.8895 -0.0245 0.9696 -0.0471 0.9587 -0.0147 0.86200.0154 0.8912 -0.0200 0.9624 -0.0397 Three-dimensional walk: -0.55170.92850.1628 -0.63160.97950.1839 -0.58781.05900.2156 -0.65761.08150.3113 -0.55781.03280.3215 -0.52601.04360.4170 -0.44561.07520.4628 -0.46511.16090.3924 -0.43021.21490.3602 -0.50701.23770.4244 if compiled with -O1 or above. Note also that the executable obtained with -O1 run under valgrind without error. Apparently the wrong part is removed by some optimization starting at -O1.
[Bug target/50176] [4.7 Regression] 4.7 generates spill-fill dealing with char-int conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50176 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-08-29 13:50:56 UTC --- It performs perfectly sensible optimizations: @@ -91,11 +83,9 @@ y_33 = (int) D.2055_32; D.2056_34 = inptr1_19 + col_5; D.2057_35 = *D.2056_34; - cb_36 = (int) D.2057_35; D.2058_37 = inptr2_24 + col_5; D.2059_38 = *D.2058_37; - cr_39 = (int) D.2059_38; - cr.0_40 = (unsigned int) cr_39; + cr.0_40 = (unsigned int) D.2059_38; ... @@ -104,12 +94,11 @@ D.2066_48 = range_limit_47(D) + D.2065_46; D.2067_49 = *D.2066_48; *outptr_4 = D.2067_49; - D.2068_50 = outptr_4 + 1; - cb.1_51 = (unsigned int) cb_36; + cb.1_51 = (unsigned int) D.2057_35; D.2070_52 = cb.1_51 * 4; D.2071_54 = Cbgtab_53(D) + D.2070_52; D.2072_55 = *D.2071_54; - cr.0_56 = (unsigned int) cr_39; + cr.0_56 = (unsigned int) D.2059_38; D.2061_57 = cr.0_56 * 4; D.2073_59 = Crgtab_58(D) + D.2061_57; D.2074_60 = *D.2073_59; This seems to be at most a register allocation or target issue. What it does is change (unsinged)(int)*load to (unsigned)*load, eventually enlarging life-ranges (didn't double-check that).
[Bug fortran/50225] [OOP] The allocation status for polymorphic allocatable variables is not set properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50225 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org, ||janus at gcc dot gnu.org Summary|The allocation status for |[OOP] The allocation status |polymorphic allocatable |for polymorphic allocatable |variables is not set|variables is not set |properly|properly --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-29 14:00:45 UTC --- For what it is worth: The 2D example here and the 2D and 3D examples at http://gcc.gnu.org/ml/fortran/2011-08/msg00239.html work with PGI 11.5, the 2D example also works with Cray 7.1.4.111 but the 3D example causes an ICE.
[Bug libfortran/50192] Wrong character comparision with wide strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50192 --- Comment #4 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-08-29 14:12:01 UTC --- Author: tkoenig Date: Mon Aug 29 14:11:54 2011 New Revision: 178238 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178238 Log: 2011-08-29 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR libfortran/50192 * intrinsics/string_intrinsics.c (memcmp_char4): New function. * intrinsics/string_intrinsics_inc.c: New macro MEMCMP, either set to memcmp or memcmp_char4. (compare_string): Use MEMCMP, with correct size for it. * libgfortran.h: Add prototype for memcmp_char4. 2011-08-29 Thomas Koenig tkoe...@gcc.gnu.org Backport from trunk PR libfortran/50192 * gfortran.dg/widechar_compare_1.f90: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/widechar_compare_1.f90 Modified: branches/gcc-4_6-branch/gcc/testsuite/ChangeLog branches/gcc-4_6-branch/libgfortran/ChangeLog branches/gcc-4_6-branch/libgfortran/intrinsics/string_intrinsics.c branches/gcc-4_6-branch/libgfortran/intrinsics/string_intrinsics_inc.c branches/gcc-4_6-branch/libgfortran/libgfortran.h
[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-08-29 14:26:57 UTC --- I still can't reproduce it (with the x86_64-linux - powerpc64-linux cross compiler, even when using the auto-host.h provided here): ./gfortran --version -B ./; ./f951 -g -O3 -fprofile-generate -ffast-math \ -funroll-loops -m64 -mcpu=power7 -mtune=power7 pr50191.f -fdump-rtl-vartrack \ -quiet -w; sed -n '/^(note/,/^$/p' pr50191.f.213r.vartrack | grep -i unspec GNU Fortran (GCC) 4.7.0 20110827 (experimental) Copyright (C) 2011 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING
[Bug target/49606] mips64: o64 Unrecognizable insn when one noreturn function calling another noreturn function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49606 --- Comment #4 from Martin Decky martin at decky dot cz 2011-08-29 14:33:07 UTC --- (In reply to comment #3) As well as making longs 64 bits wide, -mlong64 makes pointers 64 bits wide. But you're still using a 32-bit file format. If you want an LP64 ABI, then n64 seems like a better choice. Yes, this is indeed the most reasonable solution for me. So do you actually have a system that uses this ABI (o64+mlong64)? Actually, no. I was trying to cross-compile our own OS for mips64 and the o64+mlong64 combination was the first one I have tried. The 32-bit file format might or might not be eventually a problem if the compilation works (I can imagine that it might actually work fine at least for user space binaries). But the n64 ABI seems definitively to be a better choice. If so, could you give a few more details? TBH, my instinctive reaction is that this is a missing diagnostic bug, and that we should refuse to compile -mabi=o64 -mlong64. Well, I do not insist that this bug should be fixed only by making the compilation work. Your suggestion that this combination of options is not very reasonable and should be refused is sound. Either way, the compiler should not end with an internal error.
[Bug middle-end/50137] [4.7 Regression] ppc64/libstdc++-v3 is miscompiled on powerpc-apple-darwin9 since revision 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50137 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||paolo.carlini at oracle dot ||com --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-29 14:50:29 UTC --- Still there at revision 178145 (see http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg03312.html ).
[Bug c++/50207] [4.7 Regression] G++ segv's on reduced test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50207 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-08-29 14:59:43 UTC --- The problem here is not that the first field is aggregate, but that the first field is a fake field for the base class. I'll adjust the patch accordingly.
[Bug c++/50224] [c++0x]g++ complains unused parameter but it is referenced in lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50224 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/50226] New: Wrong code with -O -fno-implicit-templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50226 Bug #: 50226 Summary: Wrong code with -O -fno-implicit-templates Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Target: i686-pc-linux-gnu Created attachment 25127 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25127 testcase Compile with `g++-4.7.0 -O -fno-implicit-templates 1.cc 2.cc'. GOLD gives warnings: function main: warning: relocation refers to discarded section function vtable for Bethint: warning: relocation refers to discarded section BFD LD remains silent. Appeared between rev. 174012 and 176963.
[Bug fortran/50227] New: ICE on valid with allocatable class component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 Bug #: 50227 Summary: ICE on valid with allocatable class component Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: aben...@caltech.edu Created attachment 25128 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25128 Contains the files which constitute the test cases. The attached code causes an ICE with gfortran 4.7 r178129. Note that if I combine the code in the two files into a single file (as in the attached combined.F90), and compile that it works without any problem. $ gfortran -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.7/bin/gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7/libexec/gcc/i686-pc-linux- gnu/4.7.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.7/configure --prefix=/usr/local/gcc-4.7 --enable- languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.7.0 20110827 (experimental) (GCC) $ gfortran -c module.F90 -o module.o $ gfortran -c program.F90 -o program.o program.F90: In function ‘test’: program.F90:4:0: 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. $ gfortran -c combined.F90 -o combined.o
[Bug fortran/50227] ICE on valid with allocatable class component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #1 from Andrew Benson abenson at caltech dot edu 2011-08-29 16:08:59 UTC --- Created attachment 25129 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25129 Further reduced test case from Janus Weil This is a further reduced test case created by Janus Weil.
[Bug fortran/50227] ICE on valid with allocatable class component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #2 from Andrew Benson abenson at caltech dot edu 2011-08-29 16:11:25 UTC --- Original report on gfortran mailing list: http://gcc.gnu.org/ml/fortran/2011-08/msg00233.html
[Bug fortran/50227] [4.7 Regression] ICE on valid with allocatable class component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-08-29 Summary|ICE on valid with |[4.7 Regression] ICE on |allocatable class component |valid with allocatable ||class component Ever Confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-29 16:13:41 UTC --- Confirmed as a 4.7 regression introduced after r171100 and before (or at) r171957 (r171654?). Backtrace and analysis in http://gcc.gnu.org/ml/fortran/2011-08/msg00235.html .
[Bug rtl-optimization/49972] Invalid .gcc_except_table with -freorder-blocks-and-partition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49972 --- Comment #6 from Rainer Orth ro at gcc dot gnu.org 2011-08-29 16:15:02 UTC --- *** Bug 50127 has been marked as a duplicate of this bug. ***
[Bug gcov-profile/50127] [4.7 regression] g++.dg/tree-prof/partition2.C FAILs on several targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50127 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||rth at gcc dot gnu.org Resolution||DUPLICATE --- Comment #3 from Rainer Orth ro at gcc dot gnu.org 2011-08-29 16:15:02 UTC --- A reghunt has confirmed that the failure of 64-bit FAIL: gcc.dg/tree-prof/bb-reorg.c execution,-fprofile-use -D_PROFILE_USE was also caused by 2011-07-23 Richard Henderson r...@redhat.com * basic-block.h (EDGE_PRESERVE): New. (EDGE_ALL_FLAGS, EDGE_COMPLEX): Include it. * bb-reorder.c: Include except.h. [...] bb-reorg SEGVs here: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] main () at /vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gcc.dg/tree-prof/bb-reorg.c:23 23t2[t0] = s; (gdb) where #0 main () at /vol/gcc/src/hg/trunk/solaris/gcc/testsuite/gcc.dg/tree-prof/bb-reorg.c:23 #1 0x00400c4c in _start () which is caused by the following difference in assembler output: --- 21827/gcc/bb-reorg.s2011-08-20 10:48:12.562998495 +0200 +++ 21828/gcc/bb-reorg.s2011-08-20 10:48:23.486467546 +0200 @@ -83,13 +83,13 @@ .L16: movb$0, (%rax) movl$buf+4, %eax -movq$buf+3, t2+32(%rip) +movq$buf+3, (%rdx) cmpb$0, (%rax) movl$5, %esi je.L19 movb$0, (%rax) movl$buf+5, %eax -movq$buf+4, t2+40(%rip) +movq$buf+4, (%rcx) cmpb$0, (%rax) movl$6, %esi movl$7, %ecx Both %rcx/%rdx are uninitialized. *** This bug has been marked as a duplicate of bug 49972 ***
[Bug tree-optimization/50124] gfortran.dg/graphite/interchange-1.f XPASSes everywhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50124 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-08/msg01628.htm ||l Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2011-08-29 16:16:33 UTC --- Fixed for 4.7.0.
[Bug fortran/50227] [4.7 Regression] [OOP] ICE on valid with allocatable class component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |UNCONFIRMED CC||janus at gcc dot gnu.org Summary|[4.7 Regression] ICE on |[4.7 Regression] [OOP] ICE |valid with allocatable |on valid with allocatable |class component |class component Ever Confirmed|1 |0
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #27 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-08-29 16:22:16 UTC --- On Mon, Aug 29, 2011 at 06:47:41AM +, burnus at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #26 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-29 06:47:41 UTC --- (In reply to comment #24) Your code in comment #14 is (I believe) invalid, and gfortran is issuing the correct error message. I get: Error: Variable 'length' cannot appear in the expression at (1) However, I believe that allocate(character(len=length)::string) is valid. One has (F2008): R626 allocate-stmt is ALLOCATE ( [ type-spec :: ] allocation-list [, alloc-opt-list ] ) with R402 type-spec is intrinsic-type-spec or derived-type-spec with R404 intrinsic-type-spec is [...] or CHARACTER [ char-selector ] with R420 char-selector is length-selector [or ...] with R421 length-selector is ( [ LEN = ] type-param-value ) [or ...] From F2003: C402 (R402) The type-param-value for a kind type parameter shall be an initialization expression. 7.1.7 An initialization expression is an expression with limitations that make it suitable for use as a kind type parameter, initializer, or named constant. It is an expression in which each operation is intrinsic, and each primary is (1) A constant or subobject of a constant, character(:),allocatable::string integer::length length=5 allocate(character(len=length)::string) length is not a constant.
[Bug fortran/50227] [4.7 Regression] [OOP] ICE on valid with allocatable class component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #4 from janus at gcc dot gnu.org 2011-08-29 16:26:39 UTC --- (In reply to comment #3) (r171654?). Rather not. This one only concerns type-bound procedures (of which Andrew's test case has none): http://gcc.gnu.org/viewcvs?view=revisionrevision=171654
[Bug fortran/50225] [OOP] The allocation status for polymorphic allocatable variables is not set properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50225
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2011-08-29
Ever Confirmed|0 |1
--- Comment #3 from janus at gcc dot gnu.org 2011-08-29 16:31:29 UTC ---
Preliminary patch which seems to fix the test case:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 178183)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -5215,17 +5215,25 @@ gfc_generate_function_code (gfc_namespace * ns)
{
tree result = get_proc_result (sym);
- if (result != NULL_TREE
-sym-attr.function
-!sym-attr.pointer)
+ if (result != NULL_TREE sym-attr.function !sym-attr.pointer)
{
if (sym-attr.allocatable sym-attr.dimension == 0
sym-result == sym)
gfc_add_modify (init, result, fold_convert (TREE_TYPE (result),
null_pointer_node));
+ else if (sym-ts.type == BT_CLASS
+ CLASS_DATA (sym)-attr.allocatable
+ sym-attr.dimension == 0 sym-result == sym)
+ {
+ tmp = CLASS_DATA (sym)-backend_decl;
+ tmp = fold_build3_loc (input_location, COMPONENT_REF,
+TREE_TYPE (tmp), result, tmp, NULL_TREE);
+ gfc_add_modify (init, tmp, fold_convert (TREE_TYPE (tmp),
+ null_pointer_node));
+ }
else if (sym-ts.type == BT_DERIVED
- sym-ts.u.derived-attr.alloc_comp
- !sym-attr.allocatable)
+ sym-ts.u.derived-attr.alloc_comp
+ !sym-attr.allocatable)
{
rank = sym-as ? sym-as-rank : 0;
tmp = gfc_nullify_alloc_comp (sym-ts.u.derived, result, rank);
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #28 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-29 16:34:34 UTC --- (In reply to comment #27) R421 length-selector is ( [ LEN = ] type-param-value ) [or ...] From F2003: C402 (R402) The type-param-value for a kind type parameter shall be an initialization expression. [...] allocate(character(len=length)::string) length is not a constant. Nor is it a type-param-value for a *kind* type parameter (emphasis by me). It is a length type parameter: 1.3.147.12.4 length type parameter type parameter whose value is permitted to be assumed, deferred, or given by a specification expression In your case, it is deferred. Note that type-param-value is simply defined as: R401 type-param-value is scalar-int-expr or * or : and The values of the deferred type parameters of an object are determined by successful execution of an ALLOCATE statement (6.7.1), execution of an intrinsic assignment statement (7.2.1.3), execution of a pointer assignment statement (7.2.2), or by argument association (12.5.2).
[Bug fortran/50227] [4.7 Regression] [OOP] ICE on valid with allocatable class component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-29 17:07:55 UTC --- Confirmed;-)
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|NEW |UNCONFIRMED Summary|[4.7 Regression] [OOP] ICE |[4.7 Regression] [OOP] |on valid with allocatable |ICE-on-valid with |class component |allocatable class variable Ever Confirmed|1 |0
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-29 17:34:02 UTC --- Why setting this pr as unconfirmed?
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 --- Comment #7 from janus at gcc dot gnu.org 2011-08-29 17:36:29 UTC --- (In reply to comment #6) Why setting this pr as unconfirmed? Oops. Did I do this? Sorry, it was not intentional ...
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-29 17:39:01 UTC --- Oops. Did I do this? Sorry, it was not intentional ... Apparently this happens while changing the summary(?).
[Bug gcov-profile/50228] New: Incorrect line execution count.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50228
Bug #: 50228
Summary: Incorrect line execution count.
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc.h...@gmail.com
Source line 6625 is reported as having been executed more times than is
possible.
Secondly I saw that all the source lines in the function were executed at least
once, but it says blocks executed 92%
gcov 4.6.1, gcc 4.6.1 (-O0 -ggdb3 --coverage)
function Evaluate called 29903918 returned 100% blocks executed 92%
29903918: 6610:Evaluate( TOKEN * const expr, const int result_type )
-: 6611:{
29903918: 6612: parse( last_result, expr, END_EXP );
call0 returned 29903918
-: 6613:
29903918: 6614: if( last_result-fp )
branch 0 taken 1799 (fallthrough)
branch 1 taken 29902119
-: 6615: {
1799: 6616:if( result_type == INT )
branch 0 taken 1 (fallthrough)
branch 1 taken 1798
-: 6617:{
1: 6618: last_result-opval.e = iconv( last_result-opval.r,
expr-errp );
call0 returned 1
1: 6619: last_result-fp = NO;
-: 6620:}
-: 6621: }
-: 6622: else
-: 6623: {
29902119: 6624:if( result_type == INT )
branch 0 taken 17342570 (fallthrough)
branch 1 taken 12559549
34685140: 6625: last_result-opval.e = itrunc( last_result-opval.i,
expr-errp );
12559549: 6626:elif( result_type == REAL )
branch 0 taken 1 (fallthrough)
branch 1 taken 12559548
-: 6627:{
1: 6628: last_result-opval.r = last_result-opval.i;
1: 6629: last_result-fp = YES;
-: 6630:}
-: 6631: }
-: 6632:
29903918: 6633: return last_result;
-: 6634:}
GCC 2.95.3 for PS2 Multiplication Issue
Hi, I am seeing this issue when using the 2.95.3 compiler for EE processor. When compiling the following code: unsigned int a,b; a = ((unsigned int)4294967295 * b); the 2.95.3 compiler generates the following assembly: 8fc30014 lw $v1,20($s8) 0060102d move $v0,$v1 431823 subu $v1,$v0,$v1 afc30024 sw $v1,36($s8) Of course, the result is always 0. Is this a bug or done by design because the compiler knows that the result should be stored in a 64-bit data type? For the latter case I would expect an error message to be displayed instead. Note that if I declare a as an unsigned long (64-bit) the compiler generates the correct multiplication instruction. Is there a compiler option for 2.95.3 that can work around this issue? Thanks. Charlotte
[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50191 --- Comment #7 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-08-29 18:05:17 UTC --- Hm, mysterious. That's the correct auto-host.h and the correct options. I will get on one of the farm machines and see if I can reproduce with a cross-compiler.
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-08-29 18:17:50 UTC --- (r171654?). Rather not. This one only concerns type-bound procedures (of which Andrew's test case has none): Sorry to be such a nuisance, but it is: r171653 works, r171654 crashes.
[Bug bootstrap/50229] New: [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 Bug #: 50229 Summary: [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Created attachment 25130 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25130 toplevel config.log I am cross-compiling a HOST=i686-apple-darwin10 BUILD=x86_64-redhat-linux TARGET=i686-w64_mingw32 cross-compiler. GCC 4.6 (and most probably 4.5) work fine, GCC 4.7 misconfigures and results in a build failure. Attached is top-level toplevel config.log, more to follow.
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 Ruben Van Boxem vanboxem.ruben at gmail dot com changed: What|Removed |Added Attachment #25130|0 |1 is obsolete|| --- Comment #1 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2011-08-29 18:22:32 UTC --- Created attachment 25131 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25131 toplevel config.log Add proper toplevel config.log
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 --- Comment #2 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2011-08-29 18:23:12 UTC --- Created attachment 25132 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25132 gcc/config.log Attached gcc/config.log
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 --- Comment #3 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2011-08-29 18:26:10 UTC --- Created attachment 25133 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25133 Compressed build log detailing failure Attached build log. (make all-gcc output)
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227 --- Comment #10 from janus at gcc dot gnu.org 2011-08-29 18:29:16 UTC --- (In reply to comment #9) (r171654?). Rather not. This one only concerns type-bound procedures (of which Andrew's test case has none): Sorry to be such a nuisance, but it is: r171653 works, r171654 crashes. Well, ok. If you say so :) Empirics beats intuition, I guess. Also, you're not a nuisance at all. That's valuable information! Thanks for checking ...
[Bug bootstrap/50229] [4.7 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229 --- Comment #4 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2011-08-29 18:30:29 UTC --- For those wondering how on Earth I am cross-compiling for Mac, see http://build1.openftd.org/fedora-cross-darwinx/ This is a cross toolchain for Fedora, which works quite well. The version used in the build is: Using built-in specs. Target: i686-apple-darwin10 Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=i686-apple-darwin10 --enable-languages=c,objc,c++,obj-c++ --with-sysroot=/usr/darwinx/SDKs/MacOSX10.5.sdk --with-as=/usr/bin/darwinx-as --with-ld=/usr/bin/darwinx-ld --enable-static --enable-shared --disable-nls --enable-multilib --enable-libssp Thread model: posix gcc version 4.2.1 (Apple Inc. build 5664)
[Bug fortran/50227] [4.7 Regression] [OOP] ICE-on-valid with allocatable class variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50227
--- Comment #11 from janus at gcc dot gnu.org 2011-08-29 19:28:42 UTC ---
Well, the obvious patch (based on Tobias' debugging) would be:
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c (revision 178253)
+++ gcc/fortran/trans-types.c (working copy)
@@ -2109,7 +2109,8 @@ gfc_sym_type (gfc_symbol * sym)
{
/* We must use pointer types for potentially absent variables. The
optimizers assume a reference type argument is never NULL. */
- if (sym-attr.optional || sym-ns-proc_name-attr.entry_master)
+ if (sym-attr.optional
+ || (sym-ns-proc_name sym-ns-proc_name-attr.entry_master))
type = build_pointer_type (type);
else
{
And indeed it seems to fix the segfault. However, I still don't really see the
connection to r171654.
[Bug fortran/50231] New: Fatal Error: Wrong module version '5' (expected '4') for file 'sizes.mod'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50231 Bug #: 50231 Summary: Fatal Error: Wrong module version '5' (expected '4') for file 'sizes.mod' Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: pavel.belomest...@regeneron.com Hello Nonmem Users, Fortran460 have been genetating the following message: fsubs.f90:2.29: USE SIZES, ONLY: DPSIZE 1 Fatal Error: Wrong module version '5' (expected '4') for file 'sizes.mod' opened at (1) gfortran: Internal error: Aborted (program f951) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. Finished compiling fsubs gfortran: fsubs.o: No such file or directory Completed call to gfcompile.bat No nonmem execution. Do you have any insights? Thank you, Pavel
[Bug fortran/50231] Fatal Error: Wrong module version '5' (expected '4') for file 'sizes.mod'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50231 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||janus at gcc dot gnu.org Resolution||INVALID --- Comment #1 from janus at gcc dot gnu.org 2011-08-29 20:37:08 UTC --- (In reply to comment #0) fsubs.f90:2.29: USE SIZES, ONLY: DPSIZE 1 Fatal Error: Wrong module version '5' (expected '4') for file 'sizes.mod' [] Do you have any insights? This error message indicates that your module SIZES has been compiled with a different compiler version than the one you're using to compile fsubs.f90. Please use the same compiler version for both! This is not a compiler bug but a user error. I'm closing this PR as invalid.
[Bug fortran/50231] Fatal Error: Wrong module version '5' (expected '4') for file 'sizes.mod'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50231 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin mikael at gcc dot gnu.org 2011-08-29 21:14:07 UTC --- (In reply to comment #1) (In reply to comment #0) fsubs.f90:2.29: USE SIZES, ONLY: DPSIZE 1 Fatal Error: Wrong module version '5' (expected '4') for file 'sizes.mod' [] Do you have any insights? This error message indicates that your module SIZES has been compiled with a different compiler version than the one you're using to compile fsubs.f90. Please use the same compiler version for both! This is not a compiler bug but a user error. I'm closing this PR as invalid. I agree that the error you quoted is a user error. This, however, should not happen: gfortran: Internal error: Aborted (program f951) Please submit a full bug report. See http://gcc.gnu.org/bugs.html for instructions. Finished compiling fsubs gfortran: fsubs.o: No such file or directory Completed call to gfcompile.bat No nonmem execution. foo.f90: !!! foo.f90 !!! module bar end module bar !!! toto.f90: !!! toto.f90 !!! program toto use bar end program toto $ gfortran45 foo.f90 -c -o foo.o # hand-edit bar.mod and change module version $ gfortran45 toto.f90 toto.f90:3.13: use bar 1 Fatal Error: Wrong module version '3' (expected '4') for file 'bar.mod' opened at (1) $ In other words: no ICE. Just the plain error message.
[Bug fortran/50231] Fatal Error: Wrong module version '5' (expected '4') for file 'sizes.mod'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50231 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-08-29 21:26:37 UTC --- (In reply to comment #2) I agree that the error you quoted is a user error. This, however, should not happen: gfortran: Internal error: Aborted (program f951) I guess that the bug reporter uses Windows and runs into PR 47394 (fixed January 2011 on the 4.5 branch and - back then - on the 4.6 trunk). Pavel, is this correct? Namely, that you have a gfortran which is older than 21 January 2011 - and that you use Windows? If not, we would be interested in more details - in particular the output of gfortran -v - to trace why there is an internal error. The actual message Wrong module version '5' (expected '4') is unfortunately to be expected. Despite trying hard, we have been so far unable to keep the .mod file format compatible between different GCC minor versions. (At least the format is stable within releases/release branches.)
[Bug fortran/50231] Fatal Error: Wrong module version '5' (expected '4') for file 'sizes.mod'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50231 janus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2011-08-29 Resolution|INVALID | Ever Confirmed|0 |1 --- Comment #4 from janus at gcc dot gnu.org 2011-08-29 21:29:13 UTC --- (In reply to comment #2) I agree that the error you quoted is a user error. This, however, should not happen: gfortran: Internal error: Aborted (program f951) Ah, ok. I completely missed that part, sorry. So I will reopen this PR. However, I think what is missing is a small self-contained test case.
[Bug fortran/50225] [OOP] The allocation status for polymorphic allocatable function results is not set properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50225 --- Comment #4 from janus at gcc dot gnu.org 2011-08-29 21:55:16 UTC --- Author: janus Date: Mon Aug 29 21:55:10 2011 New Revision: 178262 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178262 Log: 2011-08-29 Janus Weil ja...@gcc.gnu.org PR fortran/50225 * trans-decl.c (gfc_generate_function_code): Nullify polymorphic allocatable function results. 2011-08-29 Janus Weil ja...@gcc.gnu.org PR fortran/50225 * gfortran.dg/class_result_1.f03: New. Added: trunk/gcc/testsuite/gfortran.dg/class_result_1.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50225] [OOP] The allocation status for polymorphic allocatable function results is not set properly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50225 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from janus at gcc dot gnu.org 2011-08-29 21:57:33 UTC --- Fixed with r178262. Closing. Thanks for the report, Arjen!
[Bug c++/2316] g++ fails to overload on language linkage
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #20 from Marc Glisse marc.glisse at normalesup dot org 2011-08-30 00:20:07 UTC --- Created attachment 25134 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25134 remember linkage of a function type This is an extremely basic patch, that probably misses many things (and we'd want to have conversions between externC and regular functions not to break too much code), but it can be useful to play with (it got at least 4 examples right :-) although it ICEs (assert) on some other code...). Obviously it has to be built with --disable-bootstrap since the gcc source code is far from externC-clean, but it can also be used to help clean it ;-) Oh, and it won't build libstdc++ either, first because of functions in gthread that take pthread_cancel and then because of the __stoa helper in ext/string_conversions.h (I didn't try to go further). Function type trees apparently leave at least 2 trees unused in tree_type_non_common so I reused one (minval), but since I only want one bit, there are probably better ways to store it.
[Bug target/49987] [4.7 Regression] gcc.c-torture/compile/pr34856.c fails on powerpc-darwin9 from r176228
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49987 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #11 from Pat Haugen pthaugen at gcc dot gnu.org 2011-08-30 01:11:37 UTC --- (In reply to comment #10) Note that while gcc.c-torture/compile/pr34856.c does not fail on powerpc64-unknown-linux-gnu, gcc.dg/pr34856.c does (see http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg03221.html ). Could a user of powerpc*-linux-* try the patch at http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01861.html ? Yes, the patch applied to trunk fixes the ICE on gcc.dg/pr34856.c. Note that -maltivec is required to produce the error, which gcc.c-torture/compile/pr34856.c doesn't specify so that is why it didn't fail the same way.
[Bug target/50194] wrong tail call optimization for mixed arm/thumb mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50194 --- Comment #3 from Carrot carrot at google dot com 2011-08-30 01:16:34 UTC --- Yes, it's a problem of the linker in my testing environment. I've tried to manually link it with a different linker, it can run successfully. And the correct stub is generated 2472 a9c8 gcov_init_from_thumb: 2473 a9c8: 4778bx pc 2474 a9ca: 46c0nop ; (mov r8, r8) 2475 a9cc: ea45b a6e8 __gcov_init
[Bug middle-end/50232] New: [4.7 Regression] reorg.c:3971: undefined reference to `make_return_insns'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50232 Bug #: 50232 Summary: [4.7 Regression] reorg.c:3971: undefined reference to `make_return_insns' Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definitio n -Wc++-compat -fno-common -DHAVE_CONFIG_H -o cc1plus \ cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/decl.o cp/expr.o cp /pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptre e.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangl e.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-gimplify.o tree-mudflap.o attribs.o incpath.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-f amily/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/ c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec. o default-c.o cc1plus-checksum.o main.o tree-browser.o libbackend.a libcommon-ta rget.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -rdynamic -ldl -L../zlib -lz libbackend.a(reorg.o): In function `dbr_schedule': /home/dave/gnu/gcc/objdir/gcc/../../gcc/gcc/reorg.c:3971: undefined reference to `make_return_insns'
[Bug c++/50233] New: Internal compiler error: in build_value_init_noctor, at cp/init.c:336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50233 Bug #: 50233 Summary: Internal compiler error: in build_value_init_noctor, at cp/init.c:336 Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: naddi...@gmail.com Created attachment 25135 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25135 Testcase I think shared pointers inside a union break when initialized in a constructor list. See attached test case. $ /usr/lib/gcc-snapshot/bin/g++ -std=c++0x -o test.bin test.cpp test.cpp: In constructor 'Test::Test()': test.cpp:15:16: internal compiler error: in build_value_init_noctor, at cp/init.c:336 $ /usr/lib/gcc-snapshot/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.6.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 20110308-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,fortran,objc,obj-c++,go --prefix=/usr/lib/gcc-snapshot --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.0 20110308 (experimental) [trunk revision 170786] (Ubuntu/Linaro 20110308-1)
[Bug c++/50209] [C++0x] Braced-init-lists are rejected as function default arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50209 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 04:30:38 UTC --- Author: jason Date: Tue Aug 30 04:30:27 2011 New Revision: 178275 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178275 Log: PR c++/50209 Core DR 994 * parser.c (cp_parser_default_argument): Use cp_parser_initializer_clause. (cp_parser_late_parsing_default_args): Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist58.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50207] [4.7 Regression] G++ segv's on reduced test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50207 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 04:30:56 UTC --- Author: jason Date: Tue Aug 30 04:30:42 2011 New Revision: 178276 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178276 Log: PR c++/50207 * class.c (finish_struct_1): Complain if the first field is artificial. Added: trunk/gcc/testsuite/g++.dg/dfp/base.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50224] [C++0x] bogus unused parameter warning (it is referenced in lambda)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50224 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 04:31:03 UTC --- Author: jason Date: Tue Aug 30 04:30:58 2011 New Revision: 178277 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178277 Log: PR c++/50224 * semantics.c (finish_id_expression): Mark captured variables used. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-use2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50234] New: internal compiler error: in cxx_eval_component_reference, at cp/semantics.c:6527
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50234 Bug #: 50234 Summary: internal compiler error: in cxx_eval_component_reference, at cp/semantics.c:6527 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: b...@gcc.gnu.org Created attachment 25136 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25136 pre-processed g++, v today, -std=gnu++0x while hacking constexpr
[Bug c++/50207] [4.7 Regression] G++ segv's on reduced test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50207 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 04:37:23 UTC --- Fixed.
[Bug c++/50209] [C++0x] Braced-init-lists are rejected as function default arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50209 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 04:38:08 UTC --- Implemented for 4.7.
[Bug c++/50224] [C++0x] bogus unused parameter warning (it is referenced in lambda)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50224 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 04:40:29 UTC --- Author: jason Date: Tue Aug 30 04:40:22 2011 New Revision: 178278 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=178278 Log: PR c++/50224 * semantics.c (finish_id_expression): Mark captured variables used. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-use2.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/semantics.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/50224] [C++0x] bogus unused parameter warning (it is referenced in lambda)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50224 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.6.2 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-08-30 04:50:33 UTC --- Fixed for 4.6.2.
[Bug target/50235] New: Wrong code with volatile bitfields and -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50235
Bug #: 50235
Summary: Wrong code with volatile bitfields and -Os
Classification: Unclassified
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com
Created attachment 25137
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25137
Output of ajo-gcc -w -Os test.c -v
This failure reproduces for me with svn revision 178264 (2011-08-29), but it
goes back at least as far as gcc-4.5. I'm on Ubuntu 10.10, x86-64.
cat test.c EOF
struct S1 {
unsigned f0, f1;
unsigned short f2, f3;
unsigned f4 : 16;
unsigned f5, f6;
volatile unsigned f7 : 28;
};
static struct S1 g_76;
static struct S1 g_245 = {0,0,0,0,0,0,0,1};
static signed char g_323 = 0x80;
static void func_1(void) {
g_245.f7 = 1;
for (g_323 = 0; g_323 = -1; g_323 -= 2) {
g_76 = g_76;
g_76.f4 ^= 11;
}
}
int main() {
func_1();
printf(%x %x\n, (unsigned)g_323, (unsigned)g_245.f7);
}
EOF
gcc -w -O3 test.c ; ./a.out
gcc -w -Os test.c ; ./a.out
With -O3, it correctly prints 0 1. With -Os, it incorrectly prints 7e 1.
In trunk, -fstrict-volatile-bitfields fixes the bug --- but I don't see
anything implementation-defined about this test case. It shouldn't need any
special options to compile correctly.
This test case is reduced from the output of Csmith 2.1.0 (git hash 01aa8b04,
https://github.com/Quuxplusone/csmith/), using the following command line:
csmith --no-paranoid --no-longlong --no-pointers --arrays --jumps --no-consts
--volatiles --checksum --no-divs --no-muls --bitfields --no-packed-struct -s
1163880864
[Bug c/50236] New: compiler throws internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50236
Bug #: 50236
Summary: compiler throws internal compiler error: Segmentation
fault
Classification: Unclassified
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bha...@nds.com
Hi,
I am doing compilation with gcc version
compiler/bin/mipsel-linux-uclibc-gcc -Os -fPIC -fno-strict-aliasing -Wall
-fno-builtin -DNeedFunctioPrototypes=1 -Wmissing-prototypes -Wshadow
-Wpointer-arith -c abc.c -o abc.o
abc.c: In function ‘func’:
abc.c:952: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
In the function abc.c, at line 952, I am calling a function abc1();
…
Abc1();
…
And the function definintion of abc1 is -
void abc1(void)
{
return;
}
I am using mipsel-uclibc-gcc-4.2.0, the crosstoolchain for mipsel.
Thanks,
Bhanu
