[Bug c++/44175] [C++0x] decltype sometimes cannot recurse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44175
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-08
06:08:54 UTC ---
I wonder if for at least Linux host the driver shouldn't attempt to increase
stack size for its children, say to 32MB if possible:
{
struct rlimit rl;
if (getrlimit (RLIMIT_STACK, rl) == 0)
{
if (rl.rlim_cur != RLIM_INFINITY
rl.rlim_cur 32*1024*1024
(rl.rlim_max == RLIM_INFINITY
|| rl.rlim_max rl.rlim_cur))
{
if (rl.rlim_max == RLIM_INFINITY || rl.rlim_max = 32*1024*1024)
rl.rlim_cur = 32*1024*1024;
else
rl.rlim_cur = rl.rlim_max;
setrlimit (RLIMIT_STACK, rl);
}
}
}
then I guess maximum tinst depth could go back to 1024.
[Bug target/49257] -mfpmath=sse generates x87 instructions on 32 bits OS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49257 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-08 06:14:19 UTC --- It would need @plt for flag_pic, and somehow ensure that the %ebx is initialized, plus whatever else is needed for calls on e.g. darwin etc.
[Bug fortran/18918] Eventually support Fortran 2008's coarrays [co-arrays]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18918 --- Comment #57 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-08 06:28:44 UTC --- Author: burnus Date: Wed Jun 8 06:28:41 2011 New Revision: 174796 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174796 Log: 2011-06-08 Tobias Burnus bur...@net-b.de PR fortran/18918 * gfortran.h (gfc_statement): Add ST_LOCK and ST_UNLOCK. (gfc_exec_op): Add EXEC_LOCK and EXEC_UNLOCK. (gfc_code): Add expr4. * match.h (gfc_match_lock, gfc_match_unlock): New prototypes. * match.c (gfc_match_lock, gfc_match_unlock, lock_unlock_statement): New functions. (sync_statement): Bug fix, avoiding double freeing. (gfc_match_if): Handle LOCK/UNLOCK statement. * parse.c (decode_statement, next_statement, gfc_ascii_statement): Ditto. * st.c (gfc_free_statement): Handle LOCK and UNLOCK. * resolve.c (resolve_lock_unlock): New function. (resolve_code): Call it. * dump-parse-tree.c (show_code_node): Handle LOCK/UNLOCK. * frontend-passes.c (gfc_code_walker): Optimize gfc_code's expr4. 2011-06-08 Tobias Burnus bur...@net-b.de PR fortran/18918 * gfortran.dg/coarray_lock_1.f90: New. * gfortran.dg/coarray_lock_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/coarray_lock_1.f90 trunk/gcc/testsuite/gfortran.dg/coarray_lock_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/frontend-passes.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/match.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/st.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-06-08 07:16:06 UTC --- the testcase from http://gcc.gnu.org/bugzilla/attachment.cgi?id=20290 can be used more conveniently. It runs in 1.4s and still spends 50% of time in var-tracking emit. Using callgrind, most of the time is in emit_notes_for_changes, calling htab_traverse.
[Bug c++/49311] Missing static const symbol with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49311
--- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-08
08:02:19 UTC ---
(In reply to comment #4)
(In reply to comment #3)
This is a dup of
I think there are several hundred already. Not worth marking them as
duplicate,
it just further upsets people receiving notifications for a problem that has
no
solution.
Agreed, I provided them only for the reporter to get some additional background
to explain why this is definitely definitely not a bug.
(In reply to comment #5)
I think there are several hundred already.
Oh, this list was helpful, thanks!
Not worth marking them as duplicate,
it just further upsets people receiving notifications for a problem that
has no
solution.
Looking at http://www2.research.att.com/~bs/bs_faq2.html#in-class I found this
You can take the address of a static member if (and only if) it has an
out-of-class definition
Of course this is not a promise you don't need an out-of-class definition if
you don't take the address. Gcc uses the assumption it can take the address in
-O0 mode, but is this assumption justified? It's at least surprising.
class A
{
public:
static const unsigned first = 1;
enum { second = 2 };
};
should behave similar in all cases address of first isn't taken.
But your code requires an lvalue because the result of the conditional operator
is an lvalue if both arguments are lvalues, so it must have an address.
That's why casting the operands or adding zero makes it link, because it makes
the operand an rvalue, so the address is not needed.
This is explained in the duplicate PRs I linked to, please read them, there's
nothing more to discuss IMHO.
[Bug c++/49322] [4.7 Regression] Many libstdc++ testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49322 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug middle-end/49319] [4.7 regression] g++.dg/abi/thunk5.C FAILs on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49319 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/49320] gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c FAILs with random flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49320 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||irar at il dot ibm.com Resolution||DUPLICATE --- Comment #1 from Ira Rosen irar at il dot ibm.com 2011-06-08 09:48:39 UTC --- It's a duplicate of pr 49239. The preprocessed source doesn't have the initialization of res, that was added in r174469. Ira *** This bug has been marked as a duplicate of bug 49239 ***
[Bug testsuite/49239] Random gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49239 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #6 from Ira Rosen irar at il dot ibm.com 2011-06-08 09:48:39 UTC --- *** Bug 49320 has been marked as a duplicate of this bug. ***
[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310 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 #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-08 09:54:29 UTC --- Using -g -O2 -fbounds-check instead of -g -O1 -fbounds-check cures it, or e.g. -g -O1 -fbounds-check --param max-vartrack-expr-depth=5 speeds it up. The programming style is very weird, and combined with -fbounds-check which results in huge number of bbs doesn't help it, plus the expression chains for the debug vars really seem to be very long (and at the points where bounds checking failures are reported the relevant registers holding the expressions are reused for something else).
[Bug tree-optimization/49320] gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c FAILs with random flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49320 --- Comment #2 from Zdenek Sojka zsojka at seznam dot cz 2011-06-08 09:54:08 UTC --- Yes, sorry, I had testsuite results with preprocessed sources from an older revision, and when looking at the testcase sources, I was checking current trunk - where it is already fixed.
[Bug c++/49311] Missing static const symbol with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49311
--- Comment #7 from Hartmut Schirmer hartmut.schirmer at arcormail dot de
2011-06-08 09:57:58 UTC ---
class A
{
public:
static const unsigned first = 1;
enum { second = 2 };
};
should behave similar in all cases address of first isn't taken.
But your code requires an lvalue because the result of the conditional
operator
is an lvalue if both arguments are lvalues, so it must have an address.
That's why casting the operands or adding zero makes it link, because it makes
the operand an rvalue, so the address is not needed.
This is explained in the duplicate PRs I linked to, please read them, there's
nothing more to discuss IMHO.
Does the way I use an rvalue change it's definition?
So if A and B are rvalue's does
c = x ? A : B
to mutate to lvalues?
Looking at http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#454
the compiler should handle static const data members like rvalues wherever
possible. Currently gcc does so nearly all the time, the few exceptions cause
really unexpected troubles
[Bug rtl-optimization/49303] ICE: vinsn_detach, at sel-sched-ir.c:1277 w/ -O3 on ia64 in r174558
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49303 --- Comment #4 from Alexander Monakov amonakov at gcc dot gnu.org 2011-06-08 09:59:26 UTC --- Author: amonakov Date: Wed Jun 8 09:59:23 2011 New Revision: 174801 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174801 Log: PR rtl-optimization/49303 * sel-sched.c (move_op): Use correct type for 'res'. Verify that code_motion_path_driver returned 0 or 1. (sel_region_finish): Clear h_d_i_d. testsuite: * gcc.target/ia64/pr49303.c: New test. Added: trunk/gcc/testsuite/gcc.target/ia64/pr49303.c Modified: trunk/gcc/ChangeLog trunk/gcc/sel-sched.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/49303] ICE: vinsn_detach, at sel-sched-ir.c:1277 w/ -O3 on ia64 in r174558
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49303 Alexander Monakov amonakov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Alexander Monakov amonakov at gcc dot gnu.org 2011-06-08 10:00:46 UTC --- Fixed on the trunk. No backports needed.
[Bug c++/49311] Missing static const symbol with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49311
--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-08
10:27:28 UTC ---
(In reply to comment #7)
Does the way I use an rvalue change it's definition?
I don't understand the question, I don't know what you mean by the definition
of an rvalue.
So if A and B are rvalue's does
c = x ? A : B
to mutate to lvalues?
No of course not.
If A and B are both lvalues of the same type then (x ? A : B) is an lvalue.
Otherwise (x ? A : B) is an rvalue.
This is a simplification, check the rules for yourself in the C++ standard if
you want the gory details.
Looking at http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#454
the compiler should handle static const data members like rvalues wherever
possible. Currently gcc does so nearly all the time, the few exceptions cause
really unexpected troubles
The proposed resolution shown in DR 454 was not applied to the draft, it was
resolved differently.
G++ handles your code correctly, it is invalid C++. Consider if foo is
rewritten as:
unsigned foo(int direction)
{
const unsigned char result = direction==0 ? A::PEN : A::NEN;
return result;
}
This takes a reference to an lvalue, which requires it to have an address.
The solution is simple, just fix your code.
This is not a bug.
[Bug target/49257] -mfpmath=sse generates x87 instructions on 32 bits OS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49257 --- Comment #16 from Uros Bizjak ubizjak at gmail dot com 2011-06-08 10:31:13 UTC --- (In reply to comment #15) It would need @plt for flag_pic, and somehow ensure that the %ebx is initialized, plus whatever else is needed for calls on e.g. darwin etc. We can probably use (parts of) i386.c,ix86_expand_call here.
[Bug c++/46003] cond5.C fails for ARM EABI tests.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46003 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #6 from Dodji Seketeli dodji at gcc dot gnu.org 2011-06-08 10:42:09 UTC --- Shouldn't this be fixed by the commit of PR c++/49134 ?
[Bug testsuite/49323] New: FAIL: g++.dg/debug/dwarf2/integer-typedef.C scan-assembler-times *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49323 Summary: FAIL: g++.dg/debug/dwarf2/integer-typedef.C scan-assembler-times * Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ja...@gcc.gnu.org, dang...@gcc.gnu.org, r...@gcc.gnu.org, do...@gcc.gnu.org On x86_64-apple-darwin10 at revision 174779 g++.dg/debug/dwarf2/integer-typedef.C fails with FAIL: g++.dg/debug/dwarf2/integer-typedef.C scan-assembler-times [^\\n\\r]*DW_AT_name: S2048ul 1 FAIL: g++.dg/debug/dwarf2/integer-typedef.C scan-assembler-times [^\\n\\r]*DW_AT_MIPS_linkage_name: _ZN1SILm2048EE1fEm 1 for both -m32 and -m64. Grepping the assembler I see .ascii S2048ul\0# DW_AT_name and .ascii _ZN1SILm2048EE1fEm\0# DW_AT_MIPS_linkage_name .byte0x87,0x40# uleb128 0x2007; (DW_AT_MIPS_linkage_name) The test has been introduced by revision 174742 and the failures are along the line of pr49288.
[Bug middle-end/21953] [4.3/4.4/4.5/4.6/4.7 Regression] Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953 --- Comment #15 from Rainer Orth ro at gcc dot gnu.org 2011-06-08 11:39:16 UTC --- Author: ro Date: Wed Jun 8 11:39:14 2011 New Revision: 174804 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174804 Log: PR middle-end/21953 * gcc.dg/compat/struct-layout-1_generate.c (dg-options): Use -fno-common on alpha*-dec-osf*. * g++.dg/compat/struct-layout-1_generate.c (dg-options): Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/compat/struct-layout-1_generate.c trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
[Bug c++/49322] [4.7 Regression] Many libstdc++ testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49322 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-08 11:47:36 UTC --- On x86_64-apple-darwin10 at revision 174779 I only see FAIL: 20_util/is_move_assignable/value.cc (test for excess errors) WARNING: 20_util/is_move_assignable/value.cc compilation failed to produce executable The error is FAIL: 20_util/is_move_assignable/value.cc (test for excess errors) Excess errors: /opt/gcc/work/libstdc++-v3/testsuite/20_util/is_move_assignable/value.cc:60:1: internal compiler error: tree check: expected tree that contains 'common' structure, have '' in gt_ggc_mx_lang_tree_node, at ./gt-cp-tree.h:147
[Bug c/48825] libiberty psignal lacks const modifier, failing to compile when HAVE_PSIGNAL is undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48825 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-06-08 11:48:36 UTC --- It Would Be Nice if the eventual solution could be backported to open gcc branches. (My autotester, when trying to pick up newlib updates, fails for all branches so it seems anyone trying to build a toolchain with a recent newlib and *any* gcc will be hit.)
[Bug middle-end/21953] [4.3/4.4/4.5/4.6/4.7 Regression] Many tmpdir-gcc.dg-struct-layout-1 tests fail on Tru64 UNIX V5.1B
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|SUSPENDED |NEW URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-06/msg00638.htm ||l CC||ro at gcc dot gnu.org Target Milestone|4.3.6 |4.7.0 Severity|critical|normal --- Comment #16 from Rainer Orth ro at gcc dot gnu.org 2011-06-08 11:50:56 UTC --- Most parts fixed, adjusting target, initial analysis of the remaining ones in the patch submission above.
[Bug testsuite/49323] FAIL: g++.dg/debug/dwarf2/integer-typedef.C scan-assembler-times *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49323 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.08 11:52:22 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-06-08 11:52:22 UTC --- Created attachment 24466 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24466 gcc47-pr49323.patch Does this work for you?
[Bug c++/44175] [C++0x] decltype sometimes cannot recurse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44175
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-08
12:16:49 UTC ---
Additionally, if the only deep recursion problem is during GC, perhaps:
--- gcc/cp/cp-tree.h 2011-05-27 21:13:30.946483346 +0200
+++ gcc/cp/cp-tree.h 2011-06-08 14:15:06.743389464 +0200
@@ -4635,7 +4635,7 @@ struct cp_declarator {
};
/* A level of template instantiation. */
-struct GTY(()) tinst_level {
+struct GTY((chain_next (%h.next))) tinst_level {
/* The immediately deeper level in the chain. */
struct tinst_level *next;
could fix it and allow going back to 1024 from 900.
[Bug testsuite/49323] FAIL: g++.dg/debug/dwarf2/integer-typedef.C scan-assembler-times *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49323 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-08 12:19:17 UTC --- Created attachment 24466 [details] gcc47-pr49323.patch Does this work for you? On x86_64-apple-darwin10, yes it does (I cannot test powerpc-apple-darwin9 right now), thanks.
[Bug c++/49322] [4.7 Regression] Many libstdc++ testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49322 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-08 12:31:20 UTC --- I have forgotten to say that I see the failure with -m64 only.
[Bug c++/49322] [4.7 Regression] Many libstdc++ testsuite failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49322 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-08 12:45:07 UTC --- Indeed, this is caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=174772 deduction_tsubst_fntype is called, creates a TREE_LIST, pushes it using push_tinst_level, then during tsubst call (much deeper in the backtrace fact) add_pending_template is called, which sticks pointer to current_tinst_level (whose chain goes back to struct tinst_level that points to the TREE_LIST from deduction_tsubst_fntype), then some pop_tinst_level calls are called and finally tsubst returns to deduction_tsubst_fntype, which calls pop_tinst_level (but, all those pop_tinst_level calls just tweak current_tinst_level, they don't change what add_pending_template remembered) and then ggc_frees the TREE_LIST, which means that during GC pending_templates(-next)*-tinst(-next)*-decl suddenly points to freed memory and thus crashes. Either it shouldn't be freed, or before calling pop_tinst_level it should be reset to NULL or something similar (current_tinst_level-decl = NULL; pop_tinst_level (); ggc_free (tinst); ?), or it is wrong that add_pending_template has been called or remembered that.
[Bug target/47739] gcc 4.4.5 with target powerpc-wrs-vxworks fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47739 Jan Smets jan.sm...@alcatel-lucent.com changed: What|Removed |Added CC||jan.sm...@alcatel-lucent.co ||m --- Comment #1 from Jan Smets jan.sm...@alcatel-lucent.com 2011-06-08 12:49:26 UTC --- I have this issue as well. My source (4.6) has #ifdef TARGET_POSIX_IO in libgcov.c to pick the correct mkdir (when TARGET_POSIX_IO is undefined). My target is i686-wrs-vxworks (and --with-headers=..) and TARGET_POSIX_IO is defined somehow. I tried disabling gcov with --disable-coverage or --enable-coverage=no , but it did not prevent the compile problems.
[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #29 from Kris kristopher.kuhlman at gmail dot com 2011-06-08 13:12:59 UTC --- (In reply to comment #27) r174416 fixes all the test cases in this PR (except comment #11, which is invalid). I'm glad we finally nailed this one. Closing as fixed. Thanks for reporting, Rich! Will this fix be applied to 4.6 or 4.5?
[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-06-08 13:23:00 UTC --- (In reply to comment #3) Using -g -O2 -fbounds-check instead of -g -O1 -fbounds-check cures it, or e.g. -g -O1 -fbounds-check --param max-vartrack-expr-depth=5 speeds it up. The programming style is very weird, and combined with -fbounds-check which results in huge number of bbs doesn't help it, plus the expression chains for the debug vars really seem to be very long (and at the points where bounds checking failures are reported the relevant registers holding the expressions are reused for something else). Not so sure if I agree with your statement about my programming style ;-). sure timings explode with increasing max-vartrack-expr-depth, maybe the table below can help to pick a good default ? max-vartrack-expr-depth=2: var-tracking emit : 32.66 (33%) usr max-vartrack-expr-depth=3: var-tracking emit : 33.03 (34%) usr max-vartrack-expr-depth=4: var-tracking emit : 33.66 (34%) usr max-vartrack-expr-depth=5: var-tracking emit : 33.64 (34%) usr max-vartrack-expr-depth=6: var-tracking emit : 34.34 (35%) usr max-vartrack-expr-depth=7: var-tracking emit : 35.98 (35%) usr max-vartrack-expr-depth=8: var-tracking emit : 42.52 (37%) usr max-vartrack-expr-depth=9: var-tracking emit : 48.79 (39%) usr max-vartrack-expr-depth=10: var-tracking emit : 53.09 (42%) usr max-vartrack-expr-depth=12: var-tracking emit : 74.52 (46%) usr max-vartrack-expr-depth=14: var-tracking emit : 118.90 (63%) usr max-vartrack-expr-depth=16: var-tracking emit : 313.50 (81%) usr max-vartrack-expr-depth=18: var-tracking emit : 833.84 (91%) usr max-vartrack-expr-depth=20: var-tracking emit :2527.38 (97%) usr
[Bug c++/49321] Incorrect Optimization O2 and O3 on Shift Operation for 64 bit Integers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49321 Yu Simin silver24k at gmail dot com changed: What|Removed |Added CC||silver24k at gmail dot com --- Comment #3 from Yu Simin silver24k at gmail dot com 2011-06-08 13:26:40 UTC --- I've tried GCC 4.6 （r174793， i786-pc-mingw32） and it gives the 'corrent' result （-01 -02 or -03）： i[0]=0, i[1]=8
[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-08 13:34:42 UTC --- 10 was the minimal value to get reasonable debug info in some cases (e.g. gcc.dg/guality/), so perhaps 20 is too much and we should go down to the default of 12-15.
[Bug middle-end/49310] [4.7 Regression] Compile time hog in var-tracking emit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49310 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-08 13:38:51 UTC --- Or alternatively make it more dynamic, like if in one function the maximum level is reached or almost reached (so it could be checked only in vt_expand_loc_callback) more than some parameter times (like several millions or so), it would temporarily drop down the limit to a lower value. It would probably need to recheck all var locations at that spot though, because dummy and real expansion should match.
[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #30 from janus at gcc dot gnu.org 2011-06-08 13:39:42 UTC --- (In reply to comment #29) Will this fix be applied to 4.6 or 4.5? Usually we only backport regression fixes, and since this is technically not a regression, the default procedure would be to *not* backport it to earlier releases. However, if your life depends on it, we could maybe consider having an exception from that rule and doing a backport to the 4.6 branch (which is still young), given that the patch is relatively small and simple. Doing a backport to 4.5 is probably not worth it, though. 4.5 has only very rudimentary support for CLASSes and polymorphism, and I would not expect anyone to seriously use it for larger OOP codes ...
[Bug fortran/47601] [OOP] Internal Error: mio_component_ref(): Component not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #31 from Kris kristopher.kuhlman at gmail dot com 2011-06-08 13:49:21 UTC --- (In reply to comment #30) (In reply to comment #29) Will this fix be applied to 4.6 or 4.5? However, if your life depends on it, we could maybe consider having an exception from that rule and doing a backport to the 4.6 branch (which is still young), given that the patch is relatively small and simple. Although my *life* does not depend on it, I think backporting this fix to 4.6 would be beneficial, because it will be a while before 4.7 will be released and used widely. It seems to me that these sort of fixes are required before people will start using the more modern features of Fortran03/gfortran. Thanks for fixing this, regardless.
[Bug lto/49302] [4.7 Regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49302 --- Comment #9 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-06-08 13:51:34 UTC --- Hm, this isn't going to work for all cases. When I reproduce the problem on powerpc64-linux without forcing a hardware square root, I see: spawn /home/wschmidt/gcc/build/gcc-mainline-pr49302/gcc/xgcc -B/home/wschmidt/gcc/build/gcc-mainline-pr49302/gcc/ c_lto_20110201-1_0.o -O0 -flto -O2 -ffast-math -fuse-linker-plugin -m32 -o gcc-dg-lto-20110201-1-01 /tmp/cc1mUEPp.ltrans0.ltrans.o: In function `foo': cc1mUEPp.ltrans0.o:(.text+0x5c): undefined reference to `pow' cc1mUEPp.ltrans0.o:(.text+0x74): undefined reference to `sqrt' collect2: error: ld returned 1 exit status compiler exited with status 1 output is: /tmp/cc1mUEPp.ltrans0.ltrans.o: In function `foo': cc1mUEPp.ltrans0.o:(.text+0x5c): undefined reference to `pow' cc1mUEPp.ltrans0.o:(.text+0x74): undefined reference to `sqrt' collect2: error: ld returned 1 exit status Expanding cabs to sqrt(r*r + i*i) will still leave an unresolved reference to sqrt.
[Bug target/49305] SH Target: internal compiler error: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49305
--- Comment #3 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-06-08
14:03:02 UTC ---
It's my fault after all. The patch r174586 should check the mode
parameter too. Without checking mode, insn-recog routines are
confused and the combine pass makes insns with wrong insn_code.
Now I'm testing
--- ORIG/trunk/gcc/config/sh/predicates.md2011-06-04 10:16:51.0
+0900
+++ trunk/gcc/config/sh/predicates.md2011-06-08 18:55:09.0 +0900
@@ -395,6 +395,7 @@
}
if ((mode == QImode || mode == HImode)
+ mode == GET_MODE (op)
(MEM_P (op)
|| (GET_CODE (op) == SUBREG MEM_P (SUBREG_REG (op)
{
@@ -432,6 +433,7 @@
return 0;
if ((mode == QImode || mode == HImode)
+ mode == GET_MODE (op)
(MEM_P (op)
|| (GET_CODE (op) == SUBREG MEM_P (SUBREG_REG (op)
{
I'll apply it if it survives the tests on sh-elf and sh4-unknown-linux-gnu
and put the patch in #1 into my TODO list.
[Bug c++/43601] Enormous increase in DLL object files size in 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 --- Comment #64 from PcX xunxun1982 at gmail dot com 2011-06-08 14:26:05 UTC --- I found that the shared or static gcc edition made a great difference of the wx unicode release mono dll size. - At first, I build the gcc 4.6 with --enable-static --enable-shared, and then I use the gcc edition to compile wx2.8.12 unicode release mono dll, that is, mingw32-make -f makefile.gcc CXXFLAGS=-Os -fno-keep-inline-dllexport LDFLAGS=-static -Wl,-s this gcc edition can produce the wx dll size about 6-7M, and the dll depends no any gcc dll. Another day, I build the gcc4.6 with --enable-static --disable-shared, and then do the similar thing, that is, mingw32-make -f makefile.gcc CXXFLAGS=-Os -fno-keep-inline-dllexport LDFLAGS=-Wl,-s this gcc edition can produce the wx dll size very large, about 17M, and the dll depends no any gcc dll, too. That's why? Thanks.
[Bug fortran/49324] New: iso_varying_string and reshape fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324
Summary: iso_varying_string and reshape fail
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jjcogliati...@yahoo.com
Iso varying string seems to fail with reshape.
I am using the iso_varying_string module available from
http://www.fortran.com/iso_varying_string.f95
My test case is:
!--
program test_ivs
use iso_varying_string
implicit none
type(varying_string),dimension(:,:),allocatable :: array2d
type(varying_string) :: extra
integer :: i,j
allocate(array2d(2,3))
extra = four
array2d(:,:) = reshape((/ var_str(1),
var_str(2), var_str(3),
extra, var_str(5),
var_str(six) /), (/ 2, 3 /))
print *,array2d second ,ubound(array2d),(('//char(array2d(i,j))//'
,i=1,size(array2d,1)),j=1,size(array2d,2))
end program test_ivs
!-
With this test case, I get the output:
array2d second2 3 '' '0' 'P' 'P!' '0' '!'
If I modify it to:
!-
program test_ivs_no_reshape
use iso_varying_string
implicit none
type(varying_string),dimension(:,:),allocatable :: array2d
type(varying_string) :: extra
integer :: i,j
allocate(array2d(2,3))
extra = four
array2d(:,1) = (/ var_str(1), var_str(2) /)
array2d(:,2) = (/ var_str(3), extra /)
array2d(:,3) = (/ var_str(5), var_str(six) /)
print *,array2d first ,ubound(array2d),(('//char(array2d(i,j))//'
,i=1,size(array2d,1)),j=1,size(array2d,2))
end program test_ivs_no_reshape
!--
I get the following output:
array2d first2 3 '1' '2' '3' 'four' '5' 'six'
which is what I expected.
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/jjc/gcc/gcc_460_install/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.6.0/configure --prefix=/home/jjc/gcc/gcc_460_install/
Thread model: posix
gcc version 4.6.0 (GCC)
Compiling:
$ gfortran -Wall -c iso_varying_string.f95
$ gfortran -Wall -o test_ivs.f90 test_ivs.f90 iso_varying_string.o
$ ./test_ivs
array2d second2 3 '' '0' 'P' 'PQ�' '0' 'Q�'
[Bug c++/46003] cond5.C fails for ARM EABI tests.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46003 --- Comment #7 from Janis Johnson janis at gcc dot gnu.org 2011-06-08 15:49:02 UTC --- Test g++.dg/template/cond5.C starts passing for arm-none-linux-gnueabi with r174682, the fix for PR49134 mentioned in comment 6.
[Bug fortran/49324] iso_varying_string and reshape fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-08 16:22:37 UTC --- Not an analysis, just some observations ... I get different results with different compilers: gfortran 4.7: array2d second2 3 '' '@' '`' '`A�▒' '@' 'A�' ifort 11.1: array2d second2 3 '/' '/' '/' '/' '/' '/' NAG 5.1 and pgf90 10.1-0: array2d second 2 3 '' '' '' 'four' '' '' pathf95 and g95: array2d second 2 3 '1' '2' '3' 'four' '5' 'six' [Neither NAG with -C=all -C=undefined, nor ifort -check all, nor gfortran -fcheck=all show an error.] I tried also the other ISO Varying String implementations at ftp://ftp.nag.co.uk/sc22wg5/ISO_VARYING_STRING/Sample_Module/ , but I fail to get a consistent result with those. ifort with either iso_vst.f90 or iso_vsta.f90: array2d second2 3 '1' '1' '1' '1' '1' '1' gfortran, g95, NAG, pgf90 and pathf95 with iso_vst.f90 and with g95, pgf90 and pathf95 for iso_vsta.f90: array2d second2 3 '1' '2' '3' 'four' '5' 'six' gfortran with iso_vsta.f90: array2d second2 3 '' '�' '�' '�jb' '�' 'b' NAG with iso_vsta.f90: ALLOCATABLE array allocatable array component is not currently allocated Program terminated by fatal error In S_ASS_S, line 342 of iso_vsta.f90 Called by TEST_IVS, line 13 of hj4f.f90
[Bug fortran/49324] iso_varying_string and reshape fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324 --- Comment #2 from Joshua Cogliati jjcogliati-r1 at yahoo dot com 2011-06-08 16:30:16 UTC --- (In reply to comment #1) Not an analysis, just some observations ... I get different results with different compilers: gfortran 4.7: array2d second2 3 '' '@' '`' '`A�▒' '@' 'A�' [Neither NAG with -C=all -C=undefined, nor ifort -check all, nor gfortran -fcheck=all show an error.] I tried also the other ISO Varying String implementations at ftp://ftp.nag.co.uk/sc22wg5/ISO_VARYING_STRING/Sample_Module/ , but I fail to get a consistent result with those. gfortran, g95, NAG, pgf90 and pathf95 with iso_vst.f90 and with g95, pgf90 and pathf95 for iso_vsta.f90: array2d second2 3 '1' '2' '3' 'four' '5' 'six' gfortran with iso_vsta.f90: array2d second2 3 '' '�' '�' '�jb' '�' 'b' Hm. http://www.fortran.com/iso_varying_string.f95 and iso_vsta.f90 use: TYPE VARYING_STRING PRIVATE CHARACTER,DIMENSION(:),ALLOCATABLE :: chars ENDTYPE VARYING_STRING iso_vst.f90 uses: TYPE VARYING_STRING PRIVATE CHARACTER,DIMENSION(:),POINTER :: chars = NULL() ENDTYPE VARYING_STRING so for gfortran at least, it seems to happen when there is a allocatable character array, but not a pointer.
[Bug other/49325] New: Incorrect target HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49325 Summary: Incorrect target HAVE_INITFINI_ARRAY check Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com HAVE_INITFINI_ARRAY support was added by: http://gcc.gnu.org/ml/gcc-patches/2002-11/msg00387.html Unfortunately, it checks if host supports init_array/fini_array sections, not target. It will generate wrong result for cross compiler.
[Bug c++/49326] New: Lambda arguments should not have a default value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49326
Summary: Lambda arguments should not have a default value
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vanboxem.ru...@gmail.com
Currently, GCC 4.6.1 warns in pedantic mode when a lambda is written that
provides default value for an argument:
[](bool a, bool=true){ return !a;} }
Which, according to the FDIS n3290 section 5.1.2/5, should be illegal and thus
give an error.
As the detection code is already present/functional (in -pedantic mode),
changing that into an error shouldn't be hard.
[Bug c++/49326] Lambda arguments should not have a default value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49326 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-08 16:50:42 UTC --- If you get a warning with -pedantic that usually means it's a G++ extension. If you don't want the extension use -pedantic-errors so it is rejected
[Bug other/49325] Incorrect target HAVE_INITFINI_ARRAY check
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49325 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-06/msg00659.htm ||l --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-06-08 16:50:49 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00659.html
[Bug c++/49326] Lambda arguments should not have a default value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49326 --- Comment #2 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2011-06-08 16:54:34 UTC --- I compiled with -std=c++0x, so GCC extensions should be turned off.
[Bug c++/49326] Lambda arguments should not have a default value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49326 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-08 17:05:06 UTC --- No, that's not how it works, read the manual for -std and -pedantic.
[Bug lto/49302] [4.7 Regression] FAIL: gcc.dg/lto/20110201-1 c_lto_20110201-1_0.o-c_lto_20110201-1_0.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49302 --- Comment #10 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-06-08 17:07:42 UTC --- Proposed fix: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00661.html
[Bug c++/49327] New: Parse error involving templated method inside templated class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49327
Summary: Parse error involving templated method inside
templated class
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: robi...@gmail.com
Compiler invocation: g++ -ftemplate-depth-128 -O0 -fno-inline -Wall -g -c -o
buggy.o buggy.cpp
Platform: both win32 and linux
I have attached (and pasted) reduced code that exhibit the behavior, with
explanation.
CODE:
templatetypename Arg1 // REMOVE THIS LINE TO REMOVE PROBLEM
struct Delegate {
template class T
static void from_method(T *object_ptr) {}
};
templatetypename Arg1
struct Event {
typedef DelegateArg1 DelegateType; // REMOVE Arg1 TO REMOVE PROBLEM
template class T
void connect_method(T *object_ptr) {
// The following line fails with:
// buggy.cpp:16:36: error: expected primary-expression before '' token
DelegateType::from_methodT(object_ptr);
}
};
int main(int argc, char *argv[]) {
return 0;
}
[Bug c++/49327] Parse error involving templated method inside templated class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49327 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-08 17:25:34 UTC --- You want: DelegateType::template from_methodT(object_ptr);
[Bug c++/49327] Parse error involving templated method inside templated class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49327 --- Comment #2 from robinei at gmail dot com 2011-06-08 17:35:22 UTC --- (In reply to comment #1) You want: DelegateType::template from_methodT(object_ptr); Doh! thanks
[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191 Steve Ellcey sje at cup dot hp.com changed: What|Removed |Added CC||sje at cup dot hp.com --- Comment #6 from Steve Ellcey sje at cup dot hp.com 2011-06-08 17:35:43 UTC --- What would be the best way to implement 'dg-effective-target strict-align'? A target list would be the easiest but a program that can pass/fail based on STRICT_ALIGNMENT would probably be more robust. I am not sure what such a program would look like though. Like memcpy-3.c? I don't think we want the dg-effective-target routines using -fdump flags like memcpy-3.c does.
[Bug testsuite/49323] FAIL: g++.dg/debug/dwarf2/integer-typedef.C scan-assembler-times *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49323 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-08 17:36:15 UTC --- Author: jakub Date: Wed Jun 8 17:36:12 2011 New Revision: 174813 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174813 Log: PR testsuite/49323 * g++.dg/debug/dwarf2/integer-typedef.C: Add -fno-merge-debug-strings to dg-options, match also DW_AT_linkage_name. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/integer-typedef.C
[Bug c++/28220] Segfault with pch and trying to do IMA with C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28220 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-06-08 17:41:07 UTC --- Andrew, does it make sense to have this PR still open?
[Bug c++/49326] Lambda arguments should not have a default value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49326 Ruben Van Boxem vanboxem.ruben at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Ruben Van Boxem vanboxem.ruben at gmail dot com 2011-06-08 17:48:53 UTC --- Ok, my mistake, I compiled with -std=c++0x -pedantic, which (as I'm reading in the manual now) turns off GCC extensions and makes program adhere to strict standards... But emits warnings only. I should use -pedantic-errors then. OK. That works as it should in this case. Thanks.
[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-08 17:48:11 UTC --- I meant (*p)++; instead of *p++; sorry.
[Bug testsuite/49323] FAIL: g++.dg/debug/dwarf2/integer-typedef.C scan-assembler-times *
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49323 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-08 17:49:06 UTC --- Fixed.
[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2011-06-08
17:47:32 UTC ---
Perhaps something like:
union { int i; char c[8]; } u;
int
main ()
{
int *p;
asm volatile ( : =r (p) : 0 (u.c[1]));
*p++;
return 0;
}
compile+run and check for zero exit code? Perhaps __ia64__ should be
explicitly listed as strict alignment in addition to that, because I believe it
will
succeed there, just with annoying messages in dmesg.
[Bug middle-end/49308] [4.7 Regression] segfault in rest_of_handle_ud_dce () at gcc/gcc/dce.c:518
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49308
Arthur O'Dwyer arthur.j.odwyer at gmail dot com changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail
||dot com
--- Comment #10 from Arthur O'Dwyer arthur.j.odwyer at gmail dot com
2011-06-08 17:50:12 UTC ---
Here's another reduced test case, in C, for what looks like the same bug:
cat test.c EOF
extern unsigned g_63;
extern int g_169;
int F(unsigned left, unsigned int right) {
return right ? 0 : (unsigned short)left;
}
void func_73(unsigned p_75) {
for (unsigned l_120 = 0; l_120 3; ++l_120) {
if (p_75)
continue;
g_169 = (unsigned) F(g_63 ^ l_120, p_75);
}
g_169 = 1;
}
EOF
gcc -w -std=c99 -O2 -ggdb test.c
[segmentation fault]
This test case is reduced from the output of Csmith 2.1.0 (git hash 210eda7f,
https://github.com/Quuxplusone/csmith/), using the following command line:
csmith --paranoid --no-longlong --no-pointers --arrays --no-jumps --no-consts
--no-volatiles --no-checksum --no-divs --no-muls --no-bitfields
--no-packed-struct -s 575277166
[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191
--- Comment #9 from dave at hiauly1 dot hia.nrc.ca 2011-06-08 17:59:18 UTC ---
Perhaps something like:
union { int i; char c[8]; } u;
int
main ()
{
int *p;
asm volatile ( : =r (p) : 0 (u.c[1]));
*p++;
return 0;
}
compile+run and check for zero exit code? Perhaps __ia64__ should be
explicitly listed as strict alignment in addition to that, because I believe
it
will
succeed there, just with annoying messages in dmesg.
Same on hppa-linux. Kernel will fixup unaligned access.
Dave
[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191
--- Comment #10 from Steve Ellcey sje at cup dot hp.com 2011-06-08 18:12:40
UTC ---
How about compiling this with -Wcast-align and looking for a warning message:
char *y;
typedef char __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__))) c;
c *z;
void foo(void)
{
z = (c *) y;
}
I get a warning on IA64 but none on X86. The warning is coming from
c-typeck.c.
x.c: In function 'foo':
x.c:6:13: warning: cast increases required alignment of target type
[-Wcast-align]
[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.08 19:12:29 Ever Confirmed|0 |1 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-08 19:12:29 UTC --- I get a warning on IA64 but none on X86. The warning is coming from c-typeck.c. x.c: In function 'foo': x.c:6:13: warning: cast increases required alignment of target type [-Wcast-align] The warning is predicated on STRICT_ALIGNMENT being nonzero so this seems to be a good idea. You could add -Werror to get an error and test the exit code.
[Bug fortran/49328] New: Internal compiler error due to explicit array bounds in contained routine argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49328 Summary: Internal compiler error due to explicit array bounds in contained routine argument Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: david.sa...@gmail.com Consider the following program: !--- module test_mod contains subroutine twiss3_at_start () implicit none type t_struct real beta, alpha, gamma, phi end type type (t_struct) b real g(6,6), tune3 call mode1_calc (g(3:4, 3:4), tune3, b) contains subroutine mode1_calc (gg, tune, twiss) type (t_struct) twiss real gg(2,2), tune twiss%beta = gg(2,2)**2 end subroutine end subroutine end module !--- compiling gives: lnx4103:~/dcs/bmad_distribution/bmad_dist/test gfortran --version GNU Fortran (GCC) 4.5.1 Copyright (C) 2010 Free Software Foundation, Inc. lnx4103:~/dcs/bmad_distribution/bmad_dist/test gfortran -c -O2 test.f90 test.f90: In function 'twiss3_at_start': test.f90:14:0: internal compiler error: in build2_stat, at tree.c:3681 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Removing the -O2 compile option fixes things. Also changing real gg(2,2) to real gg(:,:) also fixes things.
[Bug middle-end/49191] gcc.dg/memcpy-3.c FAILs on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49191 --- Comment #12 from Steve Ellcey sje at cup dot hp.com 2011-06-08 20:07:04 UTC --- Checking for a warning using check_no_compiler_messages seems as easy or easier then checking the return code so I did that. I have submitted a patch to gcc-patches. http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00673.html
[Bug fortran/49328] Internal compiler error due to explicit array bounds in contained routine argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49328 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-08 20:11:38 UTC --- Confirmed on gcc4.5.2 and 4.5.3, but AFAICT this has been fixed on gcc4.6 and 4.7 (trunk) between revisions 17 and 170140.
[Bug c++/49329] New: Static method with std::string parameter gets messed up with non-static method with bool parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49329
Summary: Static method with std::string parameter gets messed
up with non-static method with bool parameter
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: swan...@web.de
I want a static and a non-static method with the same name in a class like
this:
//main.cpp
#include string
class cc {
public:
void xx (bool b) {return;}
static void xx (std::string str) {return;}
};
int main(int argc, char **argv) {
cc instance;
instance.xx(true);
cc::xx(test string); //error: cannot call member function
//'void cc::xx(bool)' without object
return 0;
}
When compiled with: g++ -o test main.cpp
I get the following error:
error: cannot call member function 'void cc::xx(bool)' without object
The error vanishes when I change the name of the non-static method, or
when I explicitly convert the char*-test string into a std::string, or when I
change the bool-parameter of the non-static method to an int-parameter;
But it's still a nasty, strange bug.
I'm using gcc 4.5.2 on ubuntu 11.04.
[Bug c/49330] New: Integer arithmetic on addresses optimised with pointer arithmetic rules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
Summary: Integer arithmetic on addresses optimised with pointer
arithmetic rules
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: har...@gigawatt.nl
#include stdint.h
int x, y;
int main(void) {
uintptr_t px = (uintptr_t) x;
uintptr_t py = (uintptr_t) y;
volatile uintptr_t d = px - py;
uintptr_t p = py + d;
x = 1;
*(int *) p = 2;
return x;
}
gcc 4.6(20110603) returns 1 at -O1 or higher. configure options:
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --prefix=/usr
--sysconfdir=/etc --program-suffix=-4.6 --enable-languages=c,c++
--enable-checking --enable-build-with-cxx
As far as I can see, this program is perfectly valid and is required to return
2. gcc seems to be optimising on the assumption that an addition to y will not
result in a pointer to a distinct object (and so stores 2 in y), but that
assumption is only correct for a pointer addition, which the above is not.
[Bug fortran/49328] Internal compiler error due to explicit array bounds in contained routine argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49328 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-08 20:22:40 UTC --- Confirmed on gcc4.5.2 and 4.5.3, but AFAICT this has been fixed on gcc4.6 and 4.7 (trunk) between revisions 17 and 170140. Sorry I did not read the tests correctly, the range is between r158253 and r159105.
[Bug c++/49329] Static method with std::string parameter gets messed up with non-static method with bool parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49329 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-06-08 20:25:50 UTC --- I think GCC is correct here. EDG gives a similar error.
[Bug c/49330] Integer arithmetic on addresses optimised with pointer arithmetic rules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
--- Comment #1 from Harald van Dijk harald at gigawatt dot nl 2011-06-08
20:42:04 UTC ---
A similar example, but one which does not convert the integer back to a
pointer:
#include stdio.h
#include stdlib.h
int a;
int main() {
unsigned long b = (unsigned long) a - 134518548;
volatile unsigned long c = b;
if (c == 0) {
if (b != 0) abort ();
}
printf(%lu\n, c);
return a;
}
This should never abort. It aborts on my system (with -m32).
[Bug fortran/49331] New: Accepts invalid specification expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49331 Summary: Accepts invalid specification expressions Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org gfortran currently compiles http://www.fortran.com/iso_varying_string.f95 with -std=f2003 without any error. Expected: gfortran rejects the program with an error messages. Crayftn correctly rejects the program with: character(LEN=len(string)) :: char_string ^ ftn-355 crayftn: ERROR CHAR_AUTO, File = iso_varying_string.f90, Line = 861, Column = 19 Generic interface LEN is referenced in a declarative expression in a [sub]module. Specific LEN_ must be completely specified prior to being referenced. The function being use is the innocently looking: pure function char_auto (string) result (char_string) type(varying_string), intent(in) :: string character(LEN=len(string)) :: char_string However, the specific function to which then LEN() resolves is not the intrinsic LEN, but the specific function LEN_, which is defined in the same module - but (crucially!) later than the function char_auto, which uses it. That's invalid! For a shorter example, see interpretation request J3/11-101, F08/0050, which passed already J3 and will be voted on soon by WG5. Cf. http://j3-fortran.org/doc/year/11/11-101r1.txt (Note: If the file is edited, the revision number is incremented, please remember to check whether there is, e.g., a 11-101r2.txt.)
[Bug c++/12255] exception-specification ignored on pointer to function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12255 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org Summary|exception-specifications|exception-specification |unchecked during assignment |ignored on pointer to |of pointer to function |function Severity|enhancement |normal --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-06-08 21:22:30 UTC --- The underlying issue is that G++ just ignores exception-specifications on non-function declarations. I think this choice originated in the uncertainty about whether or not the exeception-specification would become part of a function type rather than remain associated with the declaration. And as it happens, DR 92 (http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#92) is still open...
[Bug c++/49329] Static method with std::string parameter gets messed up with non-static method with bool parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49329 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-06-08 21:29:03 UTC --- (In reply to comment #0) I want a static and a non-static method with the same name you might want to rethink that cc::xx is a qualified name lookup, so can find both overloads of cc::xx The implicit pointer-to-bool conversion is a better conversion sequence than the user-defined conversion char*-to-std::string so it is selected, but calling a member function without an an object is obviously ill-formed
[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49107 --- Comment #19 from Jason Merrill jason at gcc dot gnu.org 2011-06-08 21:35:05 UTC --- Author: jason Date: Wed Jun 8 21:35:02 2011 New Revision: 174820 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174820 Log: PR c++/49107 * cp-tree.def (DEFERRED_NOEXCEPT): New. * cp-tree.h (struct tree_deferred_noexcept): New. (DEFERRED_NOEXCEPT_PATTERN, DEFERRED_NOEXCEPT_ARGS): New. (DEFERRED_NOEXCEPT_SPEC_P): New. (enum cp_tree_node_structure_enum): Add TS_CP_DEFERRED_NOEXCEPT. (union lang_tree_node): Add tree_deferred_noexcept. (maybe_instantiate_noexcept): Declare. * cp-objcp-common.c (cp_tree_size): Handle DEFERRED_NOEXCEPT. * error.c (dump_exception_spec): Likewise. * cxx-pretty-print.c (pp_cxx_exception_specification): Likewise. * ptree.c (cxx_print_xnode): Likewise. * tree.c (cp_tree_equal): Likewise. * decl.c (cp_tree_node_structure): Likewise. (duplicate_decls): Call maybe_instantiate_noexcept. * except.c (build_noexcept_spec): Handle DEFERRED_NOEXCEPT. (nothrow_spec_p, type_noexcept_p, type_throw_all_p): Check DEFERRED_NOEXCEPT_SPEC_P. * typeck2.c (merge_exception_specifiers): Likewise. * decl2.c (mark_used): Call maybe_instantiate_noexcept. * method.c (process_subob_fn, defaulted_late_check): Likewise. * pt.c (tsubst_exception_specification): Add defer_ok parm. Build DEFERRED_NOEXCEPT. (maybe_instantiate_noexcept): New. (tsubst, regenerate_decl_from_template, instantiate_decl): Adjust. * search.c (check_final_overrider): Call maybe_instantiate_noexcept. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept11.C trunk/gcc/testsuite/g++.dg/cpp0x/noexcept12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-objcp-common.c trunk/gcc/cp/cp-tree.def trunk/gcc/cp/cp-tree.h trunk/gcc/cp/cxx-pretty-print.c trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/error.c trunk/gcc/cp/except.c trunk/gcc/cp/method.c trunk/gcc/cp/pt.c trunk/gcc/cp/ptree.c trunk/gcc/cp/search.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/sfinae11.C
[Bug c++/48468] [C++0x][SFINAE] noexcept operator does not handle function templates well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48468 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-06-08 21:39:50 UTC --- Note that the fix I just checked in for 49107 delays substitution into noexcept-specifications, so they are no longer usable for SFINAE.
[Bug c++/49332] New: [C++0x] noexcept ignored on function pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49332
Summary: [C++0x] noexcept ignored on function pointer
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: accepts-invalid, rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
CC: ja...@gcc.gnu.org
Depends on: 12255
This testcase should give an error on the initialization and no error on the
static_assert.
// { dg-options -std=c++0x }
void f();
void (*p)() noexcept = f; // { dg-error }
#define SA(X) static_assert((X),#X)
SA(noexcept(p()));
The underlying issue is PR 12255, but while this behavior was not observable in
C++98, it is observable in C++0x.
[Bug c++/49332] [C++0x] noexcept ignored on function pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49332 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org 2011-06-08 21:47:04 UTC --- Or rather in C++98 it was observable through diagnostics, but couldn't change the behavior of a well-defined program.
[Bug c++/49332] [C++0x] noexcept ignored on function pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49332 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.08 21:47:18 Ever Confirmed|0 |1
[Bug c++/49259] template/incomplete6.C ICE in build_target_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49259 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.08 21:54:15 Ever Confirmed|0 |1 --- Comment #1 from Janis Johnson janis at gcc dot gnu.org 2011-06-08 21:54:15 UTC --- This was fixed by r174682, Jason's fix for c++/49134.
[Bug c++/49259] template/incomplete6.C ICE in build_target_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49259 Janis Johnson janis at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Janis Johnson janis at gcc dot gnu.org 2011-06-08 21:54:46 UTC --- Closing as FIXED.
[Bug c++/44175] [C++0x] decltype sometimes cannot recurse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44175 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2011-06-08 21:56:46 UTC --- The deep recursion issue is in the actual recursive template substitution, not the tinst_level stuff.
[Bug fortran/49324] iso_varying_string and reshape fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49324 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.08 22:12:30 CC||pault at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.3.4, 4.4.0, 4.5.1, 4.6.0, ||4.7.0 Severity|normal |major --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-06-08 22:12:30 UTC --- First: The module http://www.fortran.com/iso_varying_string.f95 is invalid, cf. PR 49331. (That shouldn't affect this PR.) Secondly, there seems to be a serious bug in gfortran - and several other compilers - in the handling of constructors of derived types with allocatable components. With gfortran, I see three bugs for the following program: - There is no reallocate on assignment - The memory is multiple times freed for a normal constructor - With reshape, the result is wrong (+ one has an invalid free) Expected: With and without the explicit allocate of z and z2, the program should print: 11 11 22 22 22 11 11 22 22 22 Actual result (w/ explicit allocate) 11 11 22 22 22 0 0 0 0 -202116348 (Plus segfault) implicit none type t integer, allocatable :: A(:) end type t type(t) :: x, y type(t), allocatable :: z(:), z2(:) allocate (x%A(2)) allocate (y%A(3)) x%A = 11 y%A = 22 ! BUG 1: Realloc LHS does not work, ! hence the following lines are required: allocate (z(2)) allocate (z2(2)) z = [ x, y ] print *, z(1)%a, z(2)%a ! OK, if allocated ! BUG 2: Crash with invalid FREE at the the program ! BUG 3: The following produces garbage z2 = reshape ([ x, y ], [ 2 ]) print *, z2(1)%a, z2(2)%a end
[Bug gcov-profile/49333] New: [cppcheck][PATCH] found a resource leak in gcc/gcc/gcov-io.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49333 Summary: [cppcheck][PATCH] found a resource leak in gcc/gcc/gcov-io.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile AssignedTo: unassig...@gcc.gnu.org ReportedBy: ettl.mar...@gmx.de Created attachment 24467 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24467 proposed patch to fix the resource leak During a check with the static code analysis tool cppcheck ( available on sourcforge), i discovered to resource leaks. A resource leak in this case means, it was forgotten to realease an open filepointer. Please refer the attached patch. Best regards from the cppcheck team. Ettl Martin
[Bug ada/49334] New: [cppcheck] possible index out of bounds in gcc/ada/adaint.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49334
Summary: [cppcheck] possible index out of bounds in
gcc/ada/adaint.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ettl.mar...@gmx.de
During a check with the static code analysis tool cppcheck, the tool discoverd
a possible buffer access out of bounds issue. The tool printed the following
output:
[gcc/ada/adaint.c][error] Array index -1 is out of bounds at line 3139
After further investiating, i reduced the code to following snipped and indeed
cppcheck is right. Please take a look at the reduced testcase:
#define MAXPATH 256
static char new_canonical_dirspec [MAXPATH];
char * f (char *dirspec)
{
int len;
strcpy (new_canonical_dirspec, );
len = strlen (new_canonical_dirspec);
if (new_canonical_dirspec [len-1] != '/') // -- if len == 0 -- Acces out
of bounds
strncat (new_canonical_dirspec, /, MAXPATH);
new_canonical_dirspec [MAXPATH - 1] = (char) 0;
return new_canonical_dirspec;
}
Best regards from the cppcheck team
Ettl Martin
[Bug gcov-profile/49333] [cppcheck][PATCH] found a resource leak in gcc/gcc/gcov-io.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49333 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-06-08 22:24:47 UTC --- Actually both of wrong, at the return point fd is associated with gcov_var.file (via fdopen) and fclose is called on the gcov_var.file.
[Bug target/49335] New: ARM: Invalid assembler generated while compiling C++ code from 'codeblocks'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49335 Summary: ARM: Invalid assembler generated while compiling C++ code from 'codeblocks' Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.h...@linaro.org Created attachment 24468 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24468 Reduced test case The attached testcase is derived from codeblocks 10.05 and fails to build on ARM due to generating invalid assembler. To reproduce: michaelh@ursa2:~/linaro/bugs$ ~/linaro/toolchains/gcc-4.7~svn174795-armv7l-maverick-cbuild127-ursa3-cortexa9r1/bin/g++ -c -O2 -save-temps lp791327.cpp lp791327.s: Assembler messages: lp791327.s:76: Error: r13 not allowed here -- `rsb r0,sp,r0,lsl#2' The fault occurs in 4.6.0 and current trunk. It does not occur in 4.5.3. Originally reported at https://bugs.launchpad.net/ubuntu/+source/codeblocks/+bug/791327
[Bug gcov-profile/49333] [cppcheck][PATCH] found a resource leak in gcc/gcc/gcov-io.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49333 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-06-08 22:25:35 UTC --- Oh the second hunk of the patch is very bad as it closes a file descriptor that has an associated FILE to it.
[Bug target/49335] ARM: Invalid assembler generated while compiling C++ code from 'codeblocks'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49335 --- Comment #1 from Michael Hope michael.hope at linaro dot org 2011-06-08 22:33:32 UTC --- Forgot the configuration: Configured with: '../../gcc-4.7~/configure' --prefix='/scratch/cbuild/slave/slaves/ursa3/gcc-4.7~svn174795/gcc/default/install' --enable-languages=c,c++,objc,obj-c++,fortran,lto --with-mode=thumb --with-arch=armv7-a --with-tune=cortex-a9 --with-float=softfp --with-fpu=neon Thread model: posix gcc version 4.7.0 20110608 (experimental) [trunk revision 174795] (GCC) michaelh@ursa2:~/linaro/bugs$ as -v GNU assembler version 2.20.51 (arm-linux-gnueabi) using BFD version (GNU Binutils for Ubuntu) 2.20.51-system.20100908 michaelh@ursa2:~/linaro/bugs$ uname -a Linux ursa2 2.6.35.3-cbuild2+ #8 SMP Mon Apr 4 12:46:46 NZST 2011 armv7l GNU/Linux michaelh@ursa2:~/linaro/bugs$ lsb_release -a No LSB modules are available. Distributor ID:Ubuntu Description:Ubuntu 10.10 Release:10.10 Codename:maverick The fault also occurs at -O1 and -O3 but not at -O0. The assembly in the region is: .L33: movsr1, #0 movsr2, #64 movr0, sp movr9, sp blmemset cmpr4, #4 beq.L11 addr0, r8, r4, lsl #2 rsbr6, r8, #4 lslsr6, r6, #2 rsbr1, r4, #4 rsbr0, sp, r0, lsl #2 movr4, sp movlr, #0 which matches the final lines of the function. It looks like the code should be using r9 instead of sp.
[Bug gcov-profile/49333] [cppcheck][PATCH] found a resource leak in gcc/gcc/gcov-io.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49333 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-06-08 22:47:16 UTC --- (In reply to comment #2) Oh the second hunk of the patch is very bad as it closes a file descriptor that has an associated FILE to it. I should say the FILE is still open and used after the function returns. I think you need to add another rule about fdopen causing the fd to become able to close via fclose.
[Bug target/49305] SH Target: internal compiler error: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49305 --- Comment #4 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-06-08 23:13:30 UTC --- Author: kkojima Date: Wed Jun 8 23:13:27 2011 New Revision: 174824 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174824 Log: PR target/49305 * config/sh/predicates.md (general_movsrc_operand): Check mode for memory with indexed address for QI and HImode. (general_movdst_operand): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/predicates.md
[Bug target/49305] SH Target: internal compiler error: in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49305 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-06-08 23:17:08 UTC --- Fixed.
[Bug libfortran/49336] New: ATAN2 values differ from those specified in documentation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49336 Summary: ATAN2 values differ from those specified in documentation Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ahn...@gmail.com The documentation for ATAN2(Y,X) says: If Y is zero, then the return value is zero if X is positive and pi if X is negative. However, the value returned by ATAN2(-0d0, -1d0) is -pi (not +pi). This is for gfortran 4.4.5. So either the documentation needs fixing (and signed zero explained), or the function ATAN2 should be redefined to return values in (-pi,pi]. ...I'm not sure which is more standard for Fortran.
[Bug ada/49337] New: Improve Gnatmake to work without static libraries.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49337 Summary: Improve Gnatmake to work without static libraries. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: bj...@xn--rombobjrn-67a.se Created attachment 24469 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24469 one possible way of making Gnatmake work with either shared or static libraries The maintainers of GCC in Fedora have split out libgnat.a and libgnarl.a to a separate subpackage which is by default not installed together with the Gnat tools. (Fedora has a policy to use only shared libraries as much as possible.) This causes Gnatmake to crash when it tries to find the directory that contains libgnat by looking for libgnat.a and the file isn't there. Could we have Gnatmake improved to also look for libgnat.so if it doesn't find libgnat.a, so that it can work with only shared libraries installed?
[Bug gcov-profile/49333] [cppcheck][PATCH] found a resource leak in gcc/gcc/gcov-io.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49333 --- Comment #4 from Martin Ettl ettl.martin at gmx dot de 2011-06-09 00:41:41 UTC --- Thanks, i already filed a bug at cppchecks bugtracker about this issue: http://sourceforge.net/apps/trac/cppcheck/ticket/2830 Many thanks for your help and best regards Martin 2011/6/9 pinskia at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49333 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2011-06-08 22:47:16 UTC --- (In reply to comment #2) Oh the second hunk of the patch is very bad as it closes a file descriptor that has an associated FILE to it. I should say the FILE is still open and used after the function returns. I think you need to add another rule about fdopen causing the fd to become able to close via fclose. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug rtl-optimization/49154] [4.7 Regression]: build fails on cris-elf in libgcc: ICE in setup_pressure_classes, at ira.c:902
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49154 --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-06-09 01:31:26 UTC --- Created attachment 24470 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24470 A patch to the CRIS port to go with the documentation update. Unfortunately when this patch by itself is applied, we run into a SEGV in IRA. Will post that patch momentarily.
[Bug target/49030] ICE in get_arm_condition_code, at config/arm/arm.c:17180
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49030 Michael Hope michael.hope at linaro dot org changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #5 from Michael Hope michael.hope at linaro dot org 2011-06-09 01:34:47 UTC --- The same assert is seen in https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/689887 in Thumb-2 mode on trunk r174795. Chung-Lin posted a patch at http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00790.html but there are bootstrap issues. Adding -fno-if-conversion works around the problem.
[Bug c/48062] `shadowed declaration is here' should be a note
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48062
momchil at xaxo dot eu changed:
What|Removed |Added
CC||momchil at xaxo dot eu
--- Comment #2 from momchil at xaxo dot eu 2011-06-09 01:46:43 UTC ---
Hi, there is an ambiguity here, consider the following examples:
$ cat 1.c
int
main(void)
{
int i;
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored -Wshadow
{ int i; }
#pragma GCC diagnostic pop
}
$ gcc46 -Wshadow 1.c
1.c: In function 'main':
1.c:4:6: warning: shadowed declaration is here [-Wshadow]
Here I would suppose to see no warning at all, because I have turned it off for
the case that shadows. But:
$ cat 2.c
int
main(void)
{
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored -Wshadow
int i;
#pragma GCC diagnostic pop
{int i;}
}
$ gcc46 -Wshadow 2.c
2.c: In function 'main':
2.c:9:7: warning: declaration of 'i' shadows a previous local [-Wshadow]
And it is something that I whould also not expect. And now:
$ cat 3.c
int
main(void)
{
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored -Wshadow
int i;
#pragma GCC diagnostic pop
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored -Wshadow
{ int i; }
#pragma GCC diagnostic pop
}
$ gcc46 -Wshadow 3.c
Produces no warning. So for me it is a bit confusing, since the warning setting
refers to pieces of code and not to variables.
[Bug rtl-optimization/49154] [4.7 Regression]: build fails on cris-elf in libgcc: ICE in setup_pressure_classes, at ira.c:902
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49154 --- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-06-09 01:54:41 UTC --- Created attachment 24471 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24471 Repeat mentioned SEGV at patched r174780 with cc1 -fpreprocessed -O2 libgcc2.i -march=v10
[Bug rtl-optimization/49154] [4.7 Regression]: build fails on cris-elf in libgcc: ICE in setup_pressure_classes, at ira.c:902
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49154 --- Comment #7 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-06-09 02:34:02 UTC --- (In reply to comment #5) Will post that patch momentarily. Done: http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00697.html
