[Bug middle-end/38533] [4.2/4.3 regression] tree-ssa-reassoc.c increases register pressure several times
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-18 07:56 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3/4.4 regression]|[4.2/4.3 regression] tree- |tree-ssa-reassoc.c increases|ssa-reassoc.c increases |register pressure several |register pressure several |times |times http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38533
[Bug tree-optimization/38564] [4.4 Regression] Revision 142662 caused ICE in insert_into_preds_of_block
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-18 08:13 ---
struct S
{
struct S *n, *p;
} *s;
void bar (void *);
int
foo (int x)
{
struct S p = { p, p };
int i;
for (i = 0; i x; i++)
bar (s);
return p.n == p;
}
I guess the reason is that unlike tcc_binary the result of tcc_comparison is
bool, not necessarily equal to the type of its operands. So it can't be
handled exactly like tcc_binary.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38564
[Bug fortran/38538] ICE with elemental character function
--- Comment #5 from pault at gcc dot gnu dot org 2008-12-18 09:13 --- I am most of the way onto a solution for this so I'll assign myself. The source of the problem is highlighted by two tests: s/call foo(func(_//bar()))/call foo(func(bar()))/ works fine as does a modified testcase with integers instead of characters and the concatenation replaced by another operation such as 1 + bar(). Thus the likely problem is the string length. This is confirmed by setting it to gfc_index_one_node in gfc_conv_expr_descriptor, whereupon the compilation completes because it is now possible to calculate a (wrong!) size for the temporary. An elemental function argument works because this is explicitly taken care of by get_elemental_fcn_charlen. When I wrote this function, I noted that this PR was a possibility but could not see an easy way to deal with it. The time has come to do the difficult thing! We'll have to scan the expression and sum the string lengths, calling get_elemental_fcn_charlen as necessary. It is a happy chance that there is only the concatenation operator:-) It is increasingly my opinion that interface mapping should be done in resolution, at the end of resolve_call and resolve_function, but that will have to wait for gcc-4.6. Paul Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-16 15:35:45 |2008-12-18 09:13:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug c++/35319] [4.3 regression] ICE throwing fixed-point types
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-12-18 09:17 --- Fixed on mainline. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 regression] ICE|[4.3 regression] ICE |throwing fixed-point types |throwing fixed-point types http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35319
[Bug c++/38517] Uninitialized reference variable is accepted after an extern declaration
--- Comment #6 from jakub at gcc dot gnu dot org 2008-12-18 09:39 ---
4297 if (init == NULL_TREE)
4298{
4299 if ((DECL_LANG_SPECIFIC (decl) == 0
4300 || DECL_IN_AGGR_P (decl) == 0)
4301 ! DECL_THIS_EXTERN (decl))
4302error (%qD declared as reference but not initialized, decl);
4303 return NULL_TREE;
4304}
DECL_THIS_EXTERN is sticky, if something has been ever declared with extern, it
is preserved through duplicate_decls. I wonder why this doesn't use
! DECL_EXTERNAL (decl) instead.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38517
[Bug fortran/31822] Missing run-time bound checks for character pointer = target
--- Comment #4 from domob at gcc dot gnu dot org 2008-12-18 10:07 --- Subject: Bug 31822 Author: domob Date: Thu Dec 18 10:05:54 2008 New Revision: 142808 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142808 Log: 2008-12-18 Daniel Kraft d...@domob.eu PR fortran/31822 * gfortran.h (gfc_check_same_strlen): Made public. * trans.h (gfc_trans_same_strlen_check): Made public. * check.c (gfc_check_same_strlen): Made public and adapted error message output to be useful not only for intrinsics. (gfc_check_merge): Adapt to gfc_check_same_strlen change. * expr.c (gfc_check_pointer_assign): Use gfc_check_same_strlen for string length compile-time check. * trans-expr.c (gfc_trans_pointer_assignment): Add runtime-check for equal string lengths using gfc_trans_same_strlen_check. * trans-intrinsic.c (gfc_trans_same_strlen_check): Renamed and made public from conv_same_strlen_check. (gfc_conv_intrinsic_merge): Adapted accordingly. 2008-12-18 Daniel Kraft d...@domob.eu PR fortran/31822 * gfortran.dg/char_pointer_assign_2.f90: Updated expected error message to be more detailed. * gfortran.dg/char_pointer_assign_4.f90: New test. * gfortran.dg/char_pointer_assign_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_4.f90 trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_pointer_assign_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31822
[Bug fortran/31822] Missing run-time bound checks for character pointer = target
--- Comment #5 from domob at gcc dot gnu dot org 2008-12-18 10:12 --- Fixed on trunk/4.4. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31822
[Bug target/38469] Wrong code for a function with long long argument returning int.
--- Comment #2 from niva at niisi dot msk dot ru 2008-12-18 10:47 --- Subject: Re: Wrong code for a function with long long argument returning int. Unfortunately it doesn't. I have added the necessary static functions (reg_truncated_to_mode, record_truncated_value, check_conversions) which are missing in combine.c in gcc-4.1.x and the invocation of check_conversions. But it didn't help. Gcc-4.1.3 generates proper code for this test if I just substitute the whole combine.c with the one from gcc-4.2.x (with minimal changes to conform the infrastructure of gcc-4.1.x). ÷ ðÎÄ, 15/12/2008 × 21:40 +, rsandifo at gcc dot gnu dot org ÐÉÛÅÔ: --- Comment #1 from rsandifo at gcc dot gnu dot org 2008-12-15 21:40 --- I think this was fixed by: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01996.html Could you check whether it works for you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38469
[Bug c++/38566] New: FAIL: g++.dg/cpp0x/auto12.C scan-assembler _ZN1AIiE1gIiEEDTplsTT_sRjES2_
We are now failing... FAIL: g++.dg/cpp0x/auto12.C scan-assembler _ZN1AIiE1gIiEEDTplsTT_sRjES2_ on i686-apple-darwin9 as of at least r142799. -- Summary: FAIL: g++.dg/cpp0x/auto12.C scan-assembler _ZN1AIiE1gIiEEDTplsTT_sRjES2_ Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38566
[Bug c++/38566] FAIL: g++.dg/cpp0x/auto12.C scan-assembler _ZN1AIiE1gIiEEDTplsTT_sRjES2_
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-12-18 12:02 --- Created an attachment (id=16927) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16927action=view) assembly file for g++.dg/cpp0x/auto12.C on i686-apple-darwin9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38566
[Bug c++/38566] FAIL: g++.dg/cpp0x/auto12.C scan-assembler _ZN1AIiE1gIiEEDTplsTT_sRjES2_
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-12-18 12:04 --- Attached auto12.s created with... /sw/src/fink.build/gcc44-4.3.999-20081217/darwin_objdir/gcc/testsuite/g++/../../g++ -B/sw/src/fink.build/gcc44-4.3.999-20081217/darwin_objdir/gcc/testsuite/g++/../../ /sw/src/fink.build/gcc44-4.3.999-20081217/gcc-4.4-20081217/gcc/testsuite/g++.dg/cpp0x/auto12.C -nostdinc++ -I/sw/src/fink.build/gcc44-4.3.999-20081217/darwin_objdir/i686-apple-darwin9/libstdc++-v3/include/i686-apple-darwin9 -I/sw/src/fink.build/gcc44-4.3.999-20081217/darwin_objdir/i686-apple-darwin9/libstdc++-v3/include -I/sw/src/fink.build/gcc44-4.3.999-20081217/gcc-4.4-20081217/libstdc++-v3/libsupc++ -I/sw/src/fink.build/gcc44-4.3.999-20081217/gcc-4.4-20081217/libstdc++-v3/include/backward -I/sw/src/fink.build/gcc44-4.3.999-20081217/gcc-4.4-20081217/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++0x -S -m32 -o auto12.s during the make check on i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38566
[Bug libstdc++/38567] New: FAIL: abi/demangle/regression/cw-16.cc execution test at -m32
As of at least r142799, we are now failing... FAIL: abi/demangle/regression/cw-16.cc execution test at -m32 on i686-apple-darwin9. This occurs with the errors... Setting LD_LIBRARY_PATH to :/sw/src/fink.build/gcc44-4.3.999-20081217/darwin_objdir/gcc:/sw/src/fink.build/gcc44-4.3.999-20081217/darwin_objdir/i686-apple-darwin9/./libstdc++-v3/src /.libs::/sw/src/fink.build/gcc44-4.3.999-20081217/darwin_objdir/gcc:/sw/src/fink.build/gcc44-4.3.999-20081217/darwin_objdir/i686-apple-darwin9/./libstdc++-v3/src/.libs:/usr/local/NM RPipe/xview/mac/lib:/usr/openwin/lib:/usr/local/NMRPipe/nmrbin.mac/lib:/usr/local/lib terminate called after throwing an instance of 'std::runtime_error' what(): error code = -2: invalid mangled name FAIL: abi/demangle/regression/cw-16.cc execution test extra_tool_flags are: -include bits/stdc++.h -- Summary: FAIL: abi/demangle/regression/cw-16.cc execution test at -m32 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38567
[Bug bootstrap/38300] [4.4 Regression] libstdc++ and libgcj contain a reference to _Unwind_GetIPInfo
--- Comment #9 from mrs at apple dot com 2008-12-18 12:21 --- Ok with the: + *-*-darwin[3-8]*) have_unwind_getipinfo=no ;; spelling. It matches the spelling in the rest of the compiler, which makes it easier to spot and modify. Technically, the: *-*-darwin[0-8]|*-*-darwin[0-8].*) ... is a bit more perfect, but, I'm not terribly worried about darwin1 or darwin2 systems. They won't work for other reasons. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38300
[Bug libstdc++/38567] FAIL: abi/demangle/regression/cw-16.cc execution test at -m32
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2008-12-18 12:49 --- This regression did not occur at r142777. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38567
[Bug libstdc++/38567] FAIL: abi/demangle/regression/cw-16.cc execution test at -m32
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2008-12-18 12:51 --- Suspect this regression is due to... r142799 | jason | 2008-12-17 14:08:14 -0500 (Wed, 17 Dec 2008) | 20 lines gcc/cp: * semantics.c (describable_type): New function. (finish_decltype_type): Use it for dependent exprs. * cp-tree.h: Declare it. * mangle.c (write_type) [DECLTYPE_TYPE]: Set skip_evaluation. (write_expression): If skip_evaluation, use type stubs. * tree.c (cp_tree_equal): Handle PARM_DECLs from different declarations of a function. * init.c (build_new): Do auto deduction if type is describable. * decl.c (cp_finish_decl): Likewise. * parser.c (cp_parser_omp_for_loop): Likewise. gcc/testsuite: * g++.dg/cpp0x/auto6.C: Test more stuff. * g++.dg/cpp0x/auto12.C: New test. libiberty: * cp-demangle.c (d_expression): Handle rvalue stubs too. [DEMANGLE_COMPONENT_CAST]: Update mangling. (d_print_comp): Avoid extra , with empty template argument packs. Remove handling for obsolete T() mangling. since we are also failing the new auto12.C testcase on i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38567
[Bug c++/38561] [4.4 Regression] Revision 142799 may cause C++ demangle failures
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-18 13:30 --- *** Bug 38567 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38561
[Bug c++/38561] [4.4 Regression] Revision 142799 may cause C++ demangle failures
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-18 13:30 --- *** Bug 38566 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||howarth at nitro dot med dot ||uc dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38561
[Bug c++/38566] FAIL: g++.dg/cpp0x/auto12.C scan-assembler _ZN1AIiE1gIiEEDTplsTT_sRjES2_
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-18 13:30 --- *** This bug has been marked as a duplicate of 38561 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38566
[Bug libstdc++/38567] FAIL: abi/demangle/regression/cw-16.cc execution test at -m32
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-18 13:30 --- *** This bug has been marked as a duplicate of 38561 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38567
[Bug c++/37922] [4.3/4.4 Regression] code generation error
--- Comment #19 from zadeck at gcc dot gnu dot org 2008-12-18 13:40 --- Subject: Bug 37922 Author: zadeck Date: Thu Dec 18 13:38:39 2008 New Revision: 142809 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142809 Log: 2008-12-18 Kenneth Zadeck zad...@naturalbridge.com PR rtl-optimization/37922 * dse.c (bb_info): Added regs_live field. (look_for_hardregs): New function. (replace_read): Added regs_live parameter and code to check that shift sequence does not clobber live hardregs. (check_mem_read_rtx): Added parameter to replace_read. (dse_step1): Added regs_live bitmap and initialize it. (rest_of_handle_dse): Added DF_NOTES problem and earlier call to df_analyze. * df-problems.c Renamed to df_simulate_initialize_backwards. (df_simulate_one_insn): Renamed to df_simulate_one_insn_backwards. (df_simulate_artificial_refs_at_top): Renamed to df_simulate_finalize_backwards. (df_simulate_initialized_forwards, df_simulate_one_insn_forwards, df_simulate_finalize_backwards): New functions. * df.h (df_simulate_artificial_refs_at_end): Renamed to df_simulate_initialize_backwards. (df_simulate_one_insn): Renamed to df_simulate_one_insn_backwards. (df_simulate_artificial_refs_at_top): Renamed to df_simulate_finalize_backwards. (df_simulate_initialized_forwards, df_simulate_one_insn_forwards, df_simulate_finalize_backwards): New functions. * ra-conflict.c (global_conflicts): Renamed df_simulate_artificial_refs_at_end to df_simulate_initialize_backwards. * sel-sched.c (propagate_lv_set): Renamed df_simulate_one_insn to df_simulate_one_insn_backwards. * ifcvt.c (dead_or_predicable): Renamed df_simulate_artificial_refs_at_end to df_simulate_initialize_backwards. Renamed df_simulate_one_insn to df_simulate_one_insn_backwards. * recog.c (peephole2_optimize): Ditto. * rtl-factoring (collect_pattern_seqs, clear_regs_live_in_seq): Ditto. 2008-12-18 Kenneth Zadeck zad...@naturalbridge.com PR rtl-optimization/37922 * g++.dg/torture/pr37922.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr37922.C Modified: trunk/gcc/ChangeLog trunk/gcc/dce.c trunk/gcc/df-problems.c trunk/gcc/df.h trunk/gcc/dse.c trunk/gcc/ifcvt.c trunk/gcc/ra-conflict.c trunk/gcc/recog.c trunk/gcc/rtl-factoring.c trunk/gcc/sel-sched.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug c++/37922] [4.3/4.4 Regression] code generation error
--- Comment #20 from zadeck at naturalbridge dot com 2008-12-18 14:23 --- committed patch to fix this. -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug c++/37922] [4.3/4.4 Regression] code generation error
--- Comment #21 from hjl dot tools at gmail dot com 2008-12-18 14:32 --- It is only fixed on trunk. 4.3 is still broken. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Known to fail||4.3.2 Known to work||4.4.0 Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
[Bug fortran/38568] New: ICE with invalid bounds for I/O FMT= array
The following program is invalid, however, there should be no ICE. Warning printed: Warning: Upper array reference at (1) is out of bounds (9 1) in dimension 1 hello.f90:2: internal compiler error: Segmentation fault valgrind: ==32039== Invalid read of size 4 ==32039==at 0x49C0DD: gfc_conv_scalarized_array_ref (trans-array.c:2414) ==32039==by 0x49D9A4: gfc_conv_array_ref (trans-array.c:2462) ==32039==by 0x4B7511: gfc_conv_variable (trans-expr.c:679) character(len=9) :: fmt(1) fmt = '(Hello)' WRITE(*, FMT(1:9) ) ! Invalid 1:9 is regarded as array bounds not at substring end Found at: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/250dfb55a30226da -- Summary: ICE with invalid bounds for I/O FMT= array Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38568
[Bug c++/38561] [4.4 Regression] Revision 142799 may cause C++ demangle failures
--- Comment #4 from jason at gcc dot gnu dot org 2008-12-18 14:53 --- Subject: Bug 38561 Author: jason Date: Thu Dec 18 14:51:56 2008 New Revision: 142814 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142814 Log: PR c++/38561 * cp-demangle.c (d_expression, d_print_comp): Revert cast changes. Modified: trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38561
[Bug c++/38561] [4.4 Regression] Revision 142799 may cause C++ demangle failures
--- Comment #5 from jason at gcc dot gnu dot org 2008-12-18 14:57 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38561
20 �ves l�ny keresi sexre v�gy� p�rj�t!
20 éves mult szöke leányzó keresi komoly párját! Bármilyen Sexuális formát felveszek! Telefonszámom: 06-30-769-75-92 hívjatok benne vagyok mindenben
[Bug libmudflap/28077] [4.2/4.3 regression] pass39-frag.c produces mudflap violation on alpha
--- Comment #5 from ubizjak at gmail dot com 2008-12-18 15:31 --- This does not fail on 4.4 [1] branch. [1] http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01564.html -- ubizjak at gmail dot com changed: What|Removed |Added Summary|[4.2/4.3/4.4 regression]|[4.2/4.3 regression] pass39- |pass39-frag.c produces |frag.c produces mudflap |mudflap violation on alpha |violation on alpha http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28077
[Bug target/34571] [4.3/4.4 Regression] Segfault in alpha_expand_mov at -O3
--- Comment #15 from ubizjak at gmail dot com 2008-12-18 15:36 --- (In reply to comment #14) Patch exists, tested and all, and just needs a re-test and then submit... I will re-bootstrap/re-test this patch. Will take some days to retest. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|rask at gcc dot gnu dot org |ubizjak at gmail dot com Status|ASSIGNED|UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34571
[Bug c++/38485] [4.4 Regression] GCC can't parse a parenthesized comma in a template-id within a default argument
--- Comment #6 from jason at gcc dot gnu dot org 2008-12-18 15:55 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38485
[Bug c++/38485] [4.4 Regression] GCC can't parse a parenthesized comma in a template-id within a default argument
--- Comment #7 from jason at gcc dot gnu dot org 2008-12-18 15:56 --- Subject: Bug 38485 Author: jason Date: Thu Dec 18 15:54:59 2008 New Revision: 142815 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142815 Log: PR c++/38485 * parser.c (cp_parser_token_starts_cast_expression): An EOF can't start a cast-expression. Added: trunk/gcc/testsuite/g++.dg/parse/defarg13.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38485
[Bug c++/38569] New: SLES11: SEGV with try/throw/catch/terminate() at -q64
The following cut-down code gets core-dump with g++ on SLES11, the problem does
not exist on CELL and AIX g++.
#include stdio.h
#include stdlib.h
#include exception
int f(int);
int g(int i);
void my_terminate();
typedef void(*Function_Pointer) ();
int xx_exceptions = 0;
class xx {
public:
xx(int i) { v = i;}
int v;
};
class aa {
public:
aa() {}
~aa() { throw xx(1); }
};
int main()
{
Function_Pointer set_terminate(Function_Pointer);
std::set_terminate(my_terminate);
f(1);
return 55;
}
void my_terminate()
{
fflush(0);
exit(55);
}
int f(int i)
{
aa x;
try {
return g(0);
}
catch ( xx xobj) {
xx_exceptions ++ ;
}
}
int g(int i)
{
if (i == 0) throw xx(1);
}
Part of core-dump details:
the coredump is from libgcc_s.so.1
warning: Can't read pathname for load map: Input/output error.
Reading symbols from
/nfs/adam/.../torolab.ibm.com/fs/proj/p0/vabld/run/vacpp/dev/sles10_ppc/daily/081216/opt.ibmcmp.lib64/libibmc++.so.1...done.
Loaded symbols for
/.../torolab.ibm.com/fs/projects/vabld/run/vacpp/dev/sles10_ppc/daily/081216//opt/ibmcmp/lib64/libibmc++.so.1
Reading symbols from /usr/lib64/libstdc++.so.6...done.
Loaded symbols for /usr/lib64/libstdc++.so.6
Reading symbols from /lib64/libm.so.6...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libgcc_s.so.1...done.
Loaded symbols for /lib64/libgcc_s.so.1
Reading symbols from /lib64/libc.so.6...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/ld64.so.1...done.
Loaded symbols for /lib64/ld64.so.1
Core was generated by `./abc '.
Program terminated with signal 11, Segmentation fault.
#0 0x042fd1ec in ?? () from /lib64/libgcc_s.so.1
--
Summary: SLES11: SEGV with try/throw/catch/terminate() at -q64
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aixing at ca dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38569
[Bug fortran/38538] ICE with elemental character function
--- Comment #6 from pault at gcc dot gnu dot org 2008-12-18 16:35 --- Created an attachment (id=16928) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16928action=view) Provisional patch for the PR Testcase follows in next attachement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug fortran/38538] ICE with elemental character function
--- Comment #7 from pault at gcc dot gnu dot org 2008-12-18 16:38 --- Created an attachment (id=16929) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16929action=view) testcase for the PR This might have departed somewhat from the original but it does at least work with the patch! Note that the patch is not regtested. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-18 16:55 --- Let me try, I'm kinda sorta responsible for this bug in a way, you know... -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-12-05 10:28:01 |2008-12-18 16:55:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug c/38570] New: 'GCC/THUMB generates sub-optimal prolog/epilog
When generating relatively trivial leaf-functions that contains local branch
instructions (not calling sub functions), the compiler generates unnecessary
PUSH/POP instructions to store the LR on the stack.
Richard Earnshaw [richard.earns...@arm.com] has confirmed that this is a bug
and requested that I raise it in bugzilla.
In the attached example (test.c), it can be seen in the generated assembly file
(test-prologue-thumb.s) that all of the wcstrlenN() functions have unnecessary
'push{lr}/pop{pc}' which could be replaced by just doing 'bx lr' in the epilog.
Command line was:
arm-none-eabi-gcc -mthumb -mno-thumb-interwork test.c -Os -S -o
test-prologue-thumb.s
--
Summary: 'GCC/THUMB generates sub-optimal prolog/epilog
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: daniel dot sherwood at sepura dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-mingw32
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug c/38570] 'GCC/THUMB generates sub-optimal prolog/epilog
--- Comment #1 from daniel dot sherwood at sepura dot com 2008-12-18 17:20 --- Created an attachment (id=16930) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16930action=view) Source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug c/38570] 'GCC/THUMB generates sub-optimal prolog/epilog
--- Comment #2 from daniel dot sherwood at sepura dot com 2008-12-18 17:20 --- Created an attachment (id=16931) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16931action=view) Generated assembly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug c/38570] 'GCC/THUMB generates sub-optimal prolog/epilog
--- Comment #3 from daniel dot sherwood at sepura dot com 2008-12-18 17:21 --- Created an attachment (id=16932) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16932action=view) gcc -v output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug c/38570] 'GCC/THUMB generates sub-optimal prolog/epilog
--- Comment #4 from daniel dot sherwood at sepura dot com 2008-12-18 17:22 --- Following comment received from richard.earns...@arm.com by e-mail. == Hmm, yes, I think this is happening because the body of the function contains branch instructions. The Thumb branch instructions have quite limited range, and in the worst case the compiler needs to use the BL instruction (which of course, will destroy the contents of r14). Unfortunately, it's nearly impossible to say exactly when it will be necessary to fall back to this method, so all branches are assumed to do so. It's relatively unusual to find leaf functions that have branches but do not need to stack any other registers (non-leaf functions have to save r14 anyway), but you've managed to find a couple. R. [I've just had a quick look at the sources. There appears to be code in there that is supposed to deal with this case, but it clearly contains broken assumptions (fortunately, the broken assumptions essentially mean that we always get correct, though at times sub-optimal, code).] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38570
[Bug c/38571] New: GCC/THUMB generates unnecessary padding between functions
WHen generating code, the compiler adds unnecessary '.align 2' assembeler directives (where '.align 2' means align on a four byte boundary). This results in extra padding being added between functions. This occurs even when -fno-align-functions -fno-align-labels are specified. Richard Earnshaw [richard.earns...@arm.com] has confirmed that this is an issue and requested that I raise it in bugzilla. In the attached example (test.c), it can be seen in the generated assembly file (test-align-thumb.s) that various .align 2 statements appear. Command line was: arm-none-eabi-gcc test.c -Os -S -mthumb -fno-align-functions -fno-align-labels -o test-align-thumb.s -- Summary: GCC/THUMB generates unnecessary padding between functions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: daniel dot sherwood at sepura dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-mingw32 GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
[Bug c/38571] GCC/THUMB generates unnecessary padding between functions
--- Comment #1 from daniel dot sherwood at sepura dot com 2008-12-18 17:41 --- Created an attachment (id=16933) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16933action=view) gcc -v output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
[Bug c/38571] GCC/THUMB generates unnecessary padding between functions
--- Comment #2 from daniel dot sherwood at sepura dot com 2008-12-18 17:42 --- Created an attachment (id=16934) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16934action=view) Source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
[Bug c/38571] GCC/THUMB generates unnecessary padding between functions
--- Comment #2 from daniel dot sherwood at sepura dot com 2008-12-18 17:42 --- Created an attachment (id=16934) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16934action=view) Source --- Comment #3 from daniel dot sherwood at sepura dot com 2008-12-18 17:42 --- Created an attachment (id=16935) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16935action=view) Source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
[Bug c/38571] GCC/THUMB generates unnecessary padding between functions
--- Comment #4 from daniel dot sherwood at sepura dot com 2008-12-18 17:42 --- Created an attachment (id=16936) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16936action=view) Generated assembly -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
[Bug c/38571] GCC/THUMB generates unnecessary padding between functions
--- Comment #5 from daniel dot sherwood at sepura dot com 2008-12-18 17:43 --- Following comment received from richard.earns...@arm.com by e-mail. == Often this is necessary (for example, if the function contains a literal pool); but it isn't always so. Again, if there is no existing case in bugzilla, perhaps you could file one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
[Bug c/38528] ICE while building libgfortran (gcc bootstrap)
--- Comment #4 from bernard at brenda-arkle dot me dot uk 2008-12-18 18:45 --- Is that official? Do you want to maintain a list of documented gcc options which unlikely ever to work, for the benefit of the rest of us? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38528
[Bug c/37865] gfortran build fails in stage 3 bootstrap with --enable-intermodule
--- Comment #7 from bernard at brenda-arkle dot me dot uk 2008-12-18 18:54 --- Sorry about the bug-number error. 38528 was what I meant. Andrew Pinski's reply there suggests that --enable-intermodule is simply doomed anyway. (a) Since submitting the original bug report I corrected -march=athlon64-sse3 to -march=athlon64. The abbreviated report of the late failure failed to show this, and I forgot to mention it. (b) It still doesn't work, even without trying to specify any particular target architecture with -march. But that belongs in 38528, if anywhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37865
[Bug middle-end/38572] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
While compiling xulrunner with yesterday's gcc 4.4 svn rev 142782: c++ -o jsparse.o -c -I./dist/include/system_wrappers -include ./config/gcc_hidden.h -DAVMPLUS_IA32 -DAVMPLUS_UNIX -DAVMPLUS_LINUX -DFEATURE_NANOJIT -DJS_TRACER -DOSTYPE=\Linux2.6.28-0.rc7\ -DOSARCH=Linux -DEXPORT_JS_API -DJS_USE_SAFE_ARENA -I. -I. -I./dist/include -I./dist/include/js -I/usr/include/nspr -I/sdk/include -I.-fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -m32 -O2 -march=i686 -fomit-frame-pointer -fweb -frename-registers -mmmx -Wl,-O2,-z,combreloc,-z,relro,--enable-new-dtags,--hash-style=gnu,--sort-common -msse -fvisibility-inlines-hidden -fno-strict-aliasing -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -m32 -O2 -march=i686 -fomit-frame-pointer -fweb -frename-registers -mmmx -Wl,-O2,-z,combreloc,-z,relro,--enable-new-dtags,--hash-style=gnu,--sort-common -msse -DMOZILLA_CLIENT -include ./mozilla-config.h -Wp,-MD,.deps/jsparse.pp jsparse.cpp jsparse.cpp: In function 'JSParseNode* Statement(JSContext*, JSTokenStream*, JSTreeContext*)': jsparse.cpp:2764: warning: suggest parentheses around '' within '||' jsopcode.cpp: In function 'jsbytecode* Decompile(SprintStack*, jsbytecode*, intN, JSOp)': jsopcode.cpp:1720: internal compiler error: in set_value_range, at tree-vrp.c:398 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.4 Regression] ICE in set_value_range, at tree- vrp.c:398 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #1 from bero at arklinux dot org 2008-12-18 19:26 --- Created an attachment (id=16937) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16937action=view) gzipped preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38492] [graphite] segfaulting code when compiled with -fgraphite -fgraphite-identity
--- Comment #6 from jsjodin at gcc dot gnu dot org 2008-12-18 19:39 ---
This still fails here:
gfortran -v -O2 -g -ffree-form -fgraphite -fgraphite-identity -cpp -D__FFTSG
PR38492.f90
I looked into this failure. It fails because the number of iterations cannot be
computed (chrec_unknown) when the loop domain is translated, and is ignored by
scan_tree_for_params. In general it can be dangerous to throw away
chrec_unknown, because it may code that we must generate.
The patch will prevent the scop from being transformed if the number of
iterations cannot be analyzed, and it will no longer ignore chrec_unknown. I
will run some more tests to make sure it does not break anything else. The
patch is below:
Index: graphite.c
===
--- graphite.c (revision 142764)
+++ graphite.c (working copy)
@@ -2356,6 +2356,7 @@ graphite_loop_normal_form (loop_p loop)
tree nit;
gimple_seq stmts;
edge exit = single_dom_exit (loop);
+ tree iv = NULL_TREE;
if (!number_of_iterations_exit (loop, exit, niter, false))
gcc_unreachable ();
@@ -2369,7 +2370,14 @@ graphite_loop_normal_form (loop_p loop)
if (nb_reductions_in_loop (loop) 0)
return NULL_TREE;
- return canonicalize_loop_ivs (loop, NULL, nit);
+ iv = canonicalize_loop_ivs (loop, NULL, nit);
+
+ nit = number_of_latch_executions (loop);
+ nit = analyze_scalar_evolution (loop, nit);
+ if (nit == chrec_dont_know)
+return NULL_TREE;
+
+ return iv;
}
/* Record LOOP as occuring in SCOP. Returns true when the operation
@@ -2602,7 +2610,7 @@ scan_tree_for_params (scop_p s, tree e,
int cst_col, param_col;
if (e == chrec_dont_know)
-return;
+gcc_unreachable ();
switch (TREE_CODE (e))
{
--
jsjodin at gcc dot gnu dot org changed:
What|Removed |Added
CC||jsjodin at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38492
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-18 19:45 --- Works for me as of revision 142793. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #3 from hjl dot tools at gmail dot com 2008-12-18 19:48 --- I don't see any changes between revision 142782 and revision 142793 which may impact this. How is your gcc configured? -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug target/34571] [4.3/4.4 Regression] Segfault in alpha_expand_mov at -O3
--- Comment #16 from ubizjak at gmail dot com 2008-12-18 19:53 --- (In reply to comment #15) I will re-bootstrap/re-test this patch. Will take some days to retest. It looks to me, that we need to fix this from the other side. According to the comment above symbolic_operand predicate, we should also accept label_ref with an offset, so: Index: varasm.c === --- varasm.c(revision 142326) +++ varasm.c(working copy) @@ -3710,7 +3710,7 @@ /* FALLTHRU */ case LABEL_REF: - tmp = XEXP (x, 0); + tmp = XEXP (tmp, 0); gcc_assert (!INSN_DELETED_P (tmp)); gcc_assert (!NOTE_P (tmp) || NOTE_KIND (tmp) != NOTE_INSN_DELETED); Index: config/alpha/predicates.md === --- config/alpha/predicates.md (revision 142326) +++ config/alpha/predicates.md (working copy) @@ -390,7 +390,8 @@ (ior (match_code symbol_ref,label_ref) (and (match_code const) (match_test GET_CODE (XEXP (op,0)) == PLUS - GET_CODE (XEXP (XEXP (op,0), 0)) == SYMBOL_REF + (GET_CODE (XEXP (XEXP (op,0), 0)) == SYMBOL_REF +|| GET_CODE (XEXP (XEXP (op,0), 0)) == LABEL_REF) GET_CODE (XEXP (XEXP (op,0), 1)) == CONST_INT ;; Return true if OP is valid for 16-bit DTP relative relocations. BTW: The fix to varasm.c is already in mainline, need to backport 2008-03-31 James E. Wilson wil...@tuliptree.org * varasm.c (output_constant_pool_1): In LABEL_REF check, use tmp consistently. BTW: The test doesn't fail anymore neither on 4.4 and neither on 4.3 branch. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-18 19:53:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34571
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #4 from bero at arklinux dot org 2008-12-18 20:08 --- Sorry, I misread the error message - I saw the warnings about jsparse.cpp, but the actual ice occurs in jsopcode.cpp -- bero at arklinux dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #5 from bero at arklinux dot org 2008-12-18 20:10 --- Created an attachment (id=16938) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16938action=view) gzipped preprocessed source of file actually causing the problem Attaching correct preprocessed source # g++ -o test.o -O2 -c jsopcode.ii jsopcode.cpp: In function 'jsbytecode* Decompile(SprintStack*, jsbytecode*, intN, JSOp)': jsopcode.cpp:1720: internal compiler error: in set_value_range, at tree-vrp.c:398 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- bero at arklinux dot org changed: What|Removed |Added Attachment #16937|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-12-18 20:18 --- Reducing ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #7 from hjl dot tools at gmail dot com 2008-12-18 20:20 --- (In reply to comment #5) Created an attachment (id=16938) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16938action=view) [edit] gzipped preprocessed source of file actually causing the problem Attaching correct preprocessed source # g++ -o test.o -O2 -c jsopcode.ii jsopcode.cpp: In function 'jsbytecode* Decompile(SprintStack*, jsbytecode*, intN, JSOp)': jsopcode.cpp:1720: internal compiler error: in set_value_range, at tree-vrp.c:398 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. It works for me: [...@gnu-9 gcc]$ ./xgcc -B./ /net/gnu-27//export/gnu/import/rrs/jsopcode.ii -O2 -S ./xgcc [...@gnu-9 gcc]$ ./xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc/gcc/configure --enable-clocale=gnu --with-system-zlib --enable-checking=assert --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --prefix=/usr/gcc-4.4 --with-local-prefix=/usr/local Thread model: posix gcc version 4.4.0 20081217 (experimental) [trunk revision 142793] (GCC) [...@gnu-9 gcc]$ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-12-18 20:23 --- (In reply to comment #7) gcc version 4.4.0 20081217 (experimental) [trunk revision 142793] (GCC) It ICEs for me with gcc version 4.4.0 20081216 (experimental) [trunk revision 142782] (GCC) on i386-darwin8.11. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-12-18 20:24 --- (In reply to comment #8) (In reply to comment #7) gcc version 4.4.0 20081217 (experimental) [trunk revision 142793] (GCC) It ICEs for me with gcc version 4.4.0 20081216 (experimental) [trunk revision 142782] (GCC) on i386-darwin8.11. Plus there is nothing which touched the tree optimizers in that time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug c++/38569] SLES11: SEGV with try/throw/catch/terminate() at -q64
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-18 20:47 --- Works for me on the trunk. If it fails for you on SUSE11, you might as well report it to them rather than to us. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38569
[Bug c++/38427] [4.4 Regression] crash for reference init code
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-18 20:52 --- Subject: Bug 38427 Author: jakub Date: Thu Dec 18 20:51:07 2008 New Revision: 142818 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142818 Log: PR c++/38427 * init.c (perform_member_init): For value-initialized references call permerror instead of warning and don't emit any INIT_EXPR. * g++.dg/init/ctor9.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/ctor9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38427
[Bug c++/38427] [4.4 Regression] crash for reference init code
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-18 20:57 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38427
[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes
--- Comment #13 from steven at gcc dot gnu dot org 2008-12-18 21:19 ---
Jakub's idea of comment #10 is nice conceptually, but it's a bit complicated in
practice for most cases where a libcall is emitted. Before subreg lowering we
have this:
(insn 8 7 9 2 t.c:19 (set (mem:DI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S8 A32])
(const_int 2123 [0x84b])) 63 {*movdi_2} (nil))
(insn 9 8 10 2 t.c:19 (set (mem:DI (reg/f:SI 7 sp) [0 S8 A32])
(reg:DI 60)) 63 {*movdi_2} (nil))
(call_insn/u 10 9 11 2 t.c:19 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:SI (__umoddi3) [flags 0x43]) [0 S1 A8])
(const_int 16 [0x10]))) 676 {*call_value_0}
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil))
(expr_list:REG_DEP_TRUE (use (mem:DI (reg/f:SI 7 sp) [0 S8 A8]))
(expr_list:REG_DEP_TRUE (use (mem:DI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S8 A8]))
(nil
But after subreg lowering (and some more, fwprop dump shown) we have split the
DImode store of g into two separate stores, without updating the REG_DEP notes
in the CALL_INSN:
(insn 8 33 34 2 t.c:19 (set (mem:DI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S8 A32])
(const_int 2123 [0x84b])) 63 {*movdi_2} (nil))
(insn 34 8 35 2 t.c:19 (set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
(reg:SI 61 [ g ])) 41 {*movsi_1} (nil))
(insn 35 34 10 2 t.c:19 (set (mem:SI (plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])) [0 S4 A32])
(const_int 0 [0x0])) 41 {*movsi_1} (nil))
(call_insn/u 10 35 36 2 t.c:19 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:SI (__umoddi3) [flags 0x43]) [0 S1 A8])
(const_int 16 [0x10]))) 676 {*call_value_0}
(expr_list:REG_EH_REGION (const_int -1 [0x])
(nil))
(expr_list:REG_DEP_TRUE (use (mem:DI (reg/f:SI 7 sp) [0 S8 A8]))
(expr_list:REG_DEP_TRUE (use (mem:DI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S8 A8]))
(nil
Most interesting libcalls for x86 -m32 probably are the DImode ones, and if
subreg lowering does this for all arguments, we would have to update the
REG_REP notes in the CALL_INSN, or do a lot of DSE-like work...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug fortran/38538] ICE with elemental character function
--- Comment #8 from dominiq at lps dot ens dot fr 2008-12-18 21:20 --- With the patch in comment #6, this pr is fixed but now the code character(len=1) :: string print *, transfer(((transfer(string,x,1))), x) end and friends (from pr31608) gives a bus error: pr31608_1.f90: In function 'MAIN__': pr31608_1.f90:1: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Note also that I have been unable to read the test in comment #7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug c++/38569] SLES11: SEGV with try/throw/catch/terminate() at -q64
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-18 21:26 --- It works for me with gcc 4.3.2 from Fedora 10/x86-64 at -O0. -O1 and -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38569
[Bug fortran/38538] ICE with elemental character function
--- Comment #9 from dominiq at lps dot ens dot fr 2008-12-18 21:36 ---
Another bus error with
! { dg-do run }
! Test fix of PR28118, in which a substring reference to an
! actual argument with an array reference would cause a segfault.
!
! Contributed by Paul Thomas pa...@gcc.gnu.org
!
program gfcbug33
character(12) :: a(2)
a(1) = abcdefghijkl
a(2) = mnopqrstuvwx
call foo ((a(2:1:-1)(6:)))
call bar ((a(:)(7:11)))
contains
subroutine foo (chr)
character(7) :: chr(:)
if (chr(1)//chr(2) .ne. rstuvwxfghijkl) call abort ()
end subroutine foo
subroutine bar (chr)
character(*) :: chr(:)
if (trim(chr(1))//trim(chr(2)) .ne. ghijkstuvw) call abort ()
end subroutine bar
end program gfcbug33
pr28118.f90: In function 'gfcbug33':
pr28118.f90:10: internal compiler error: Bus error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38538
[Bug middle-end/38565] [4.3 Regression] ICE with vector code
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-18 21:55 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38565
[Bug middle-end/38565] [4.3 Regression] ICE with vector code
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-18 21:56 --- Subject: Bug 38565 Author: pinskia Date: Thu Dec 18 21:55:31 2008 New Revision: 142820 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142820 Log: 2008-12-18 Andrew Pinski andrew_pin...@playstation.sony.com PR middle-end/38565 * gimplifier.c (gimplify_init_constructor): For constant vector CONSTRUCTORs use GENERIC_TREE_OPERAND instead of TREE_OPERAND. 2008-12-18 Andrew Pinski andrew_pin...@playstation.sony.com PR middle-end/38565 * testsuite/g++.dg/torture/pr38565.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/torture/pr38565.C Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/gimplify.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38565
[Bug middle-end/38565] [4.3 Regression] ICE with vector code
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-18 22:02 --- Subject: Bug 38565 Author: pinskia Date: Thu Dec 18 22:00:46 2008 New Revision: 142821 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142821 Log: 2008-12-18 Andrew Pinski andrew_pin...@playstation.sony.com PR middle-end/38565 * testsuite/g++.dg/torture/pr38565.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr38565.C - copied unchanged from r142820, branches/gcc-4_3-branch/gcc/testsuite/g++.dg/torture/pr38565.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38565
[Bug fortran/38573] New: Missing markers for translation
In the function gfc_check_intrinsic_standard in gcc/fortran/intrinsic.c there is a message written: gfc_warning (Intrinsic '%s' (is %s) is used at %L, isym-name, _(symstd_msg), where); The string pointed to by sysstd_msg is sent for translation. But the values this string can get are not marked for translation. It looks like this: symstd_msg = available since Fortran 77; Nothing tells xgettext to extract this to the po files so it can be translated. This needs to be changed to symstd_msg = N_(available since Fortran 77); Similarily for the other possible values of symstd_msg. -- Summary: Missing markers for translation Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: goeran at uddeborg dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573
[Bug middle-end/38574] New: -fvisibility=hidden not affecting thread variables while attribute hidden does.
Compile the following, with -O2 -fvisibility=hidden -S without/with -DH. Compare assembly code. For this target, you'll see the following diff, but the difference was noticed on the CRIS TLS w.i.p. using [gcc-4_3-branch revision 135713]: --- hh.s2008-12-18 23:14:54.0 +0100 +++ h.s 2008-12-18 23:15:05.0 +0100 @@ -13,5 +13,6 @@ foo: popl%ebp ret .size foo, .-foo + .hidden xyzzy .ident GCC: (GNU) 4.3.0 20080428 (Red Hat 4.3.0-8) .section.note.GNU-stack,,@progbits -- Summary: -fvisibility=hidden not affecting thread variables while attribute hidden does. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38574
[Bug middle-end/38574] -fvisibility=hidden not affecting thread variables while attribute hidden does.
--- Comment #1 from hp at gcc dot gnu dot org 2008-12-18 22:21 ---
Oops, forgot the code:
extern __thread char xyzzy[64] __attribute__ ((tls_model
(initial-exec)
#ifdef H
, visibility (hidden)
#endif
));
char *
foo (void)
{
return xyzzy+9;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38574
[Bug target/38574] -fvisibility=hidden not affecting thread variables while attribute hidden does.
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-18 22:24 --- Works on PPC-linux-gnu on the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38574
[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3
--- Comment #19 from pault at gcc dot gnu dot org 2008-12-18 22:29 --- I have noticed that the scalar TRANSFER does not respect the undefined condition for the rest of the result if the SOURCE size is less than the MOLD size. I have a patch for this, which is probably not complete but goes in the right direction. In particular, it assumes that array types are compelete, which was not the case when array TRANSFER was written. My inclination is to combine the two to ensure complete bomb-proofness. I will post my provisional patch tomorrow. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-03-24 18:43:13 |2008-12-18 22:29:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
[Bug middle-end/38574] -fvisibility=hidden not affecting thread variables while attribute hidden does.
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-12-18 22:25 --- Actually this is expected behavior of -fvisibility=hidden IIRC. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|target |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38574
[Bug middle-end/38574] -fvisibility=hidden not affecting thread variables while attribute hidden does.
--- Comment #4 from hp at gcc dot gnu dot org 2008-12-18 22:35 --- (In reply to comment #3) Actually this is expected behavior of -fvisibility=hidden IIRC. Oh right, it's at the end of the doc paragraph. Ok, I've done my share of the noise for today. :) -- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38574
[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes
--- Comment #14 from steven at gcc dot gnu dot org 2008-12-18 22:35 --- Created an attachment (id=16939) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16939action=view) make all functions with nonzero crtl-outgoing_args_size non-leaf The result of this patch is that DCE of dead const/pure calls still happens, but the argument pushes will stay around. Removing the pushes too is just hard and not really worth it. A nice-to-have would be some mechanism to detect this situation where we remove a call but not the pushes, because it probably will be the result of a missed optimization on GIMPLE... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug rtl-optimization/38245] [4.4 Regression] stack corruption when a call is removed but not the outgoing argument pushes
--- Comment #15 from steven at gcc dot gnu dot org 2008-12-18 22:58 --- Created an attachment (id=16940) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16940action=view) Make targets allocate outgoing args space if necessary Alternative approach is to let all targets check if crtl-outgoing_args_size is nonzero, instead of assuming so when the function is leaf. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38245
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #11 from pinskia at gcc dot gnu dot org 2008-12-18 23:20
---
Reduced testcase:
enum JSOp {
JSOP_GETELEM = 5,
JSOP_LIMIT
} ;
typedef struct JSFrameRegs {
unsigned char *pc;
} JSFrameRegs;
struct JSStackFrame {
JSFrameRegs *regs;
};
int
f( unsigned char *pc, enum JSOp nextop )
{
unsigned char *startpc, *endpc, *pc2, *done;
enum JSOp op, lastop, saveop;
while ( pc endpc)
{
JSStackFrame *fp;
unsigned format, mode, type;
if ( ( fp fp-regs pc == fp-regs-pc ) || pc == startpc )
{
if (mode == (2U5))
op = (JSOp) ((format (1U8)) ? 256 : 1);
else
if (mode == (3U5))
op = (JSOp) ((format (1U8)) ? 257 : 2);
else
op = JSOP_GETELEM;
}
if (op = JSOP_LIMIT) {
if (((format) 0x001f) != 8)
return 0;
}
}
}
-- CUT ---
This is related to enums as if I change the type of op to int, GCC does not
crash.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2008-12-18 23:20:57
date||
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #10 from hjl dot tools at gmail dot com 2008-12-18 23:20 --- It is caused by revision 140288: http://gcc.gnu.org/ml/gcc-cvs/2008-09/msg00447.html If gcc is configured with --enable-checking=assert, you won't see the bug. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-12-18 23:21 --- (In reply to comment #10) If gcc is configured with --enable-checking=assert, you won't see the bug. Well that is called real checking code :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-checking http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #13 from hjl dot tools at gmail dot com 2008-12-18 23:26 --- Testcase in comment 11 also fails on Linux/x86-64. -- hjl dot tools at gmail dot com changed: What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #14 from hjl dot tools at gmail dot com 2008-12-18 23:28 --- (In reply to comment #12) (In reply to comment #10) If gcc is configured with --enable-checking=assert, you won't see the bug. Well that is called real checking code :). There are 397 cmp = compare_values (min, max); 398 gcc_assert (cmp == 0 || cmp == -1 || cmp == -2); Doesn't --enable-checking=assert turn on gcc_assert? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug fortran/38573] Missing markers for translation
--- Comment #1 from schwab at suse dot de 2008-12-18 23:45 --- It needs to be rephrased anyway to be i18n friendly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573
[Bug middle-end/38492] [graphite] segfaulting code when compiled with -fgraphite -fgraphite-identity
--- Comment #7 from jv244 at cam dot ac dot uk 2008-12-19 00:43 --- (In reply to comment #6) I looked into this failure. It fails because the number of iterations cannot be computed (chrec_unknown) when the loop domain is translated, and is ignored by scan_tree_for_params. In general it can be dangerous to throw away chrec_unknown, because it may code that we must generate. tested the patch, and seems to do its job on the testcase here. That's great. The code in PR38431 also compiles with the patch, but is still segfaulting at runtime, however. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38492
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #15 from pinskia at gcc dot gnu dot org 2008-12-19 01:19 --- (In reply to comment #14) Doesn't --enable-checking=assert turn on gcc_assert? Yes but not when that code is wrapped with: #if defined ENABLE_CHECKING :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38492] [graphite] segfaulting code when compiled with -fgraphite -fgraphite-identity
--- Comment #8 from spop at gcc dot gnu dot org 2008-12-19 01:35 --- Subject: Re: [graphite] segfaulting code when compiled with -fgraphite -fgraphite-identity The patch will prevent the scop from being transformed if the number of iterations cannot be analyzed, and it will no longer ignore chrec_unknown. I will run some more tests to make sure it does not break anything else. The patch is below: [...] + if (nit == chrec_dont_know) +return NULL_TREE; Replace this test with if (chrec_contains_undetermined (nit)) With this change the patch looks good. Please apply to trunk and branch. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38492
[Bug libfortran/24685] real(16) formatted input is broken for huge values (gfortran.dg/default_format_2.f90)
--- Comment #35 from howarth at nitro dot med dot uc dot edu 2008-12-19 01:38 --- Revision 142724 causes... FAIL: gfortran.dg/default_format_denormal_2.f90 -O0 execution test FAIL: gfortran.dg/default_format_denormal_2.f90 -O1 execution test FAIL: gfortran.dg/default_format_denormal_2.f90 -O2 execution test FAIL: gfortran.dg/default_format_denormal_2.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/default_format_denormal_2.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/default_format_denormal_2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/default_format_denormal_2.f90 -O3 -g execution test FAIL: gfortran.dg/default_format_denormal_2.f90 -Os execution test on powerpc-apple-darwin8.5.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24685
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #16 from hjl dot tools at gmail dot com 2008-12-19 01:40 --- C compiler doesn't crash: (gdb) f 0 #0 set_value_range (vr=0x15e7bf40, t=VR_RANGE, min=0x2af40ef86fc0, max=0x2af40ef86fc0, equiv=0x0) at ../../src/gcc/tree-vrp.c:398 398 gcc_assert (cmp == 0 || cmp == -1 || cmp == -2); (gdb) call debug_tree (min) integer_cst 0x2af40ef86fc0 type enumeral_type 0x2af40ef776c0 JSOp constant 256 (gdb) call debug_tree (max) integer_cst 0x2af40ef86fc0 type enumeral_type 0x2af40ef776c0 JSOp constant 256 (gdb) p cmp $4 = 0 (gdb) C++ compiler crashes: (gdb) f 1 #1 0x00c9b2a5 in set_value_range (vr=0x2f069e0, t=VR_RANGE, min=0x2ac27d43b330, max=0x2ac27d429ab0, equiv=0x0) at ../../src/gcc/tree-vrp.c:398 398 gcc_assert (cmp == 0 || cmp == -1 || cmp == -2); (gdb) call debug_tree (min) integer_cst 0x2ac27d43b330 type enumeral_type 0x2ac27d433cc0 JSOp constant 256 (gdb) call debug_tree (max) integer_cst 0x2ac27d429ab0 type enumeral_type 0x2ac27d433cc0 JSOp constant 7 (gdb) p cmp $2 = 1 (gdb) Enum looks different in C++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #17 from pinskia at gcc dot gnu dot org 2008-12-19 01:49 --- (In reply to comment #16) Enum looks different in C++. Yes they are different because of the way C++ talks about out of range values and such. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
[Bug c/38575] New: free() accept argument that has the same name with standard/builtin function
Any variable that has the same name with standard/builtin function name will be
accepted by free parameter.
example of code,
#include stdlib.h
int main(int argc, char *argv[])
{
free(rand);
return 0;
}
This sample code will success on compile,
$ gcc -Wall -g -O0 free-bug.c
but error on run,
$ ./a.out
*** glibc detected *** ./a.out: free(): invalid pointer: 0x08048364 ***
=== Backtrace: =
/lib/libc.so.6[0xb7ee94b6]
/lib/libc.so.6(cfree+0x89)[0xb7eeb179]
./a.out[0x8048421]
/lib/libc.so.6(__libc_start_main+0xe0)[0xb7e98fe0]
./a.out[0x80483a1]
=== Memory map:
08048000-08049000 r-xp 08:03 7946378
/home/rv77ax/doc/sandbox/c/a.out
08049000-0804a000 r--p 08:03 7946378
/home/rv77ax/doc/sandbox/c/a.out
0804a000-0804b000 rw-p 1000 08:03 7946378
/home/rv77ax/doc/sandbox/c/a.out
0804b000-0806c000 rw-p 0804b000 00:00 0 [heap]
b7e76000-b7e8 r-xp 08:01 817696 /lib/libgcc_s.so.1
b7e8-b7e82000 rw-p 9000 08:01 817696 /lib/libgcc_s.so.1
b7e82000-b7e83000 rw-p b7e82000 00:00 0
b7e83000-b7fb r-xp 08:01 817612 /lib/libc-2.6.1.so
b7fb-b7fb1000 r--p 0012c000 08:01 817612 /lib/libc-2.6.1.so
b7fb1000-b7fb3000 rw-p 0012d000 08:01 817612 /lib/libc-2.6.1.so
b7fb3000-b7fb6000 rw-p b7fb3000 00:00 0
b7fcb000-b7fcc000 rw-p b7fcb000 00:00 0
b7fcc000-b7fe6000 r-xp 08:01 819693 /lib/ld-2.6.1.so
b7fe6000-b7fe8000 rw-p 0001a000 08:01 819693 /lib/ld-2.6.1.so
bfd0a000-bfd2 rw-p bfd0a000 00:00 0 [stack]
e000-f000 r-xp 00:00 0 [vdso]
Aborted
--
Summary: free() accept argument that has the same name with
standard/builtin function
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: m dot shulhan at gmail dot com
GCC build triplet: -Wall -g -O0
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38575
[Bug c/38575] free() accept argument that has the same name with standard/builtin function
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-19 03:16 --- Yes you are passing free a function pointer. a function decays to a function pointer and an implicit conversion to void* happens. If you use -pedantic you get an error message as a function pointer cannot be converted to void* in standard C: t.c:4: error: ISO C forbids passing argument 1 of 'free' between function pointer and 'void *' /usr/include/stdlib.h:159: note: expected 'void *' but argument is of type 'int (*)(void)' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38575
[Bug middle-end/38575] free() accept argument that has the same name with standard/builtin function
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-19 03:18 --- Now maybe maybe_emit_free_warning should be enhanced to warn about this. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|minor |enhancement Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38575
[Bug c++/38362] [4.4 regression] AltiVec context-sensitive keywords broke test for __vector bool
--- Comment #1 from bje at gcc dot gnu dot org 2008-12-19 04:15 --- Fixed; posting a patch to gcc-patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38362
[Bug middle-end/38510] Matrix.c from pymol 1.1r2 fails to compile with -O2 -fgraphite
--- Comment #3 from hjagasia at gcc dot gnu dot org 2008-12-19 05:31 --- Created an attachment (id=16942) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16942action=view) Proposed patch 2008-12-18 Harsha Jagasia harsha.jaga...@amd.com PR tree-optimization/38510 * gcc.dg/graphite/pr38510.c: New. * graphite.c (translate_clast): Call mark_irreducible_loops before graphite_verify. (gloog): Call mark_irreducible_loops before graphite_verify. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38510
[Bug middle-end/38572] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
--- Comment #18 from bonzini at gnu dot org 2008-12-19 06:05 --- mine. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-18 23:20:57 |2008-12-19 06:05:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38572
