[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282
--- Comment #7 from ubizjak at gmail dot com 2009-09-29 06:29 --- (In reply to comment #6) Problem still happens with 4.5.0 20090928 (experimental) [lto revision 152240] (lto merged with rev 150842). Without the langhooks.c patch -flto is currently unusable/untestable (ICEs on pretty well everything) for arm-unknown-linux-gnu and sh-unknown-linux-gnu. Also on alpha-linux-gnu: Target: alphaev68-unknown-linux-gnu Configured with: /home/uros/gcc-svn/branches/lto/configure --enable-lto Thread model: posix gcc version 4.5.0 20090928 (experimental) (lto merged with rev 152236) lto1: internal compiler error: in lto_end_uncompression, at lto-compress.c:281 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /space/uros/gcc-build-lto/gcc/xgcc returned 1 exit status collect2: lto-wrapper returned 1 exit status -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392
[Bug tree-optimization/41498] New: ICE with graphite flags
When running trunk -r 152114 on powerpc64 with these flags (which enable the Graphite identity transformation) I get the following ICE on most of SPEC2006 benchmarks: (the following is take from 429.mcf) /home/eres/mainline_45/build/bin/gcc -c -o pbeampp.o -DSPEC_CPU -DNDEBUG -DWANT_STDC_PROTO -m64 -O3 -mcpu=power6 -ffast-math -maltivec -fno-loop-parallelize-all -fgraphite -fno-loop-block -fno-loop-interchange -fno-loop-strip-mine -fgraphite-identity -ftree-vectorize pbeampp.c pbeampp.c: In function 'primal_bea_mpp': pbeampp.c:119:8: internal compiler error: in sese_adjust_vphi, at sese.c:405 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. specmake: *** [pbeampp.o] Error 1 -- Summary: ICE with graphite flags Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eres at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41498
[Bug c/41497] apparent integer wrong code bug
--- Comment #1 from jakub at gcc dot gnu dot org 2009-09-29 07:23 ---
Fails on x86_64-linux too, the bug first appears in sccp.
extern void abort (void);
static unsigned short
bar (unsigned short x, unsigned short y)
{
return x + y;
}
unsigned int a;
unsigned char b, c;
void
foo (void)
{
for (b = 0; b = 0; b = 1)
for (a = -13; a == 0; a = bar (a, 0))
c = 1;
}
int
main ()
{
foo ();
if (a != -13)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41497
[Bug fortran/39626] Fortran 2008: Implement BLOCK construct
--- Comment #5 from domob at gcc dot gnu dot org 2009-09-29 07:43 --- Subject: Bug 39626 Author: domob Date: Tue Sep 29 07:42:42 2009 New Revision: 152266 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152266 Log: 2009-09-29 Daniel Kraft d...@domob.eu PR fortran/39626 * gfortran.h (enum gfc_statement): Add ST_BLOCK and ST_END_BLOCK. (struct gfc_namespace): Convert flags to bit-fields and add flag `construct_entities' for use with BLOCK constructs. (enum gfc_exec_code): Add EXEC_BLOCK. (struct gfc_code): Add namespace field to union for EXEC_BLOCK. * match.h (gfc_match_block): New prototype. * parse.h (enum gfc_compile_state): Add COMP_BLOCK. * trans.h (gfc_process_block_locals): New prototype. (gfc_trans_deferred_vars): Made public, new prototype. * trans-stmt.h (gfc_trans_block_construct): New prototype. * decl.c (gfc_match_end): Handle END BLOCK correctly. (gfc_match_intent): Error if inside of BLOCK. (gfc_match_optional), (gfc_match_value): Ditto. * match.c (gfc_match_block): New routine. * parse.c (decode_statement): Handle BLOCK statement. (case_exec_markers): Add ST_BLOCK. (case_end): Add ST_END_BLOCK. (gfc_ascii_statement): Handle ST_BLOCK and ST_END_BLOCK. (parse_spec): Check for statements not allowed inside of BLOCK. (parse_block_construct): New routine. (parse_executable): Parse BLOCKs. (parse_progunit): Disallow CONTAINS in BLOCK constructs. * resolve.c (is_illegal_recursion): Find real container procedure and don't get confused by BLOCK constructs. (resolve_block_construct): New routine. (gfc_resolve_blocks), (resolve_code): Handle EXEC_BLOCK. * st.c (gfc_free_statement): Handle EXEC_BLOCK statements. * trans-decl.c (saved_local_decls): New static variable. (add_decl_as_local): New routine. (gfc_finish_var_decl): Add variable as local if inside BLOCK. (gfc_trans_deferred_vars): Make public. (gfc_process_block_locals): New routine. * trans-stmt.c (gfc_trans_block_construct): New routine. * trans.c (gfc_trans_code): Handle EXEC_BLOCK statements. 2009-09-29 Daniel Kraft d...@domob.eu PR fortran/39626 * gfortran.dg/block_1.f08: New test. * gfortran.dg/block_2.f08: New test. * gfortran.dg/block_3.f90: New test. * gfortran.dg/block_4.f08: New test. * gfortran.dg/block_5.f08: New test. * gfortran.dg/block_6.f08: New test. * gfortran.dg/block_7.f08: New test. * gfortran.dg/block_8.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/block_1.f08 trunk/gcc/testsuite/gfortran.dg/block_2.f08 trunk/gcc/testsuite/gfortran.dg/block_3.f90 trunk/gcc/testsuite/gfortran.dg/block_4.f08 trunk/gcc/testsuite/gfortran.dg/block_5.f08 trunk/gcc/testsuite/gfortran.dg/block_6.f08 trunk/gcc/testsuite/gfortran.dg/block_7.f08 trunk/gcc/testsuite/gfortran.dg/block_8.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/match.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/parse.h trunk/gcc/fortran/resolve.c trunk/gcc/fortran/st.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-stmt.h trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39626
[Bug fortran/39626] Correctly implement details of Fortran 2008 BLOCK construct
--- Comment #6 from domob at gcc dot gnu dot org 2009-09-29 07:48 --- Committed my patch linked above. This implements basic BLOCK support (what I as a user would reasonably expect it to behave) but misses a lot of finer details; I'll keep the PR open for those. See my mailing list message for more information, but what I've got in mind for still missing stuff: * handle VOLATILE and ASYNCHRONOUS as the draft standard mentions * implement the clause requiring SAVE to not reference a common-name * do more stuff with regards to 'construct entities' rather than ordinary variables, for instance the IMPLICIT handling Richard Maine mentioned in his c.l.f post which is also the XFAIL'ed test-case block_7.f08 -- domob at gcc dot gnu dot org changed: What|Removed |Added Summary|Fortran 2008: Implement |Correctly implement details |BLOCK construct |of Fortran 2008 BLOCK ||construct http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39626
[Bug fortran/39626] Correctly implement details of Fortran 2008 BLOCK construct
--- Comment #7 from domob at gcc dot gnu dot org 2009-09-29 07:49 --- Also, Tobias mentioned (in the linked thread): The patch looks good to me. It sometimes makes the diagnostics less useful, e.g. for recursive function func(i) integer :: i, func func = 1 entry func2(i) block func2 = func(1) end block end function func But the same Unclassifiable statement one gets if one not only removes (end )block but also recursive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39626
[Bug target/33637] [4.3/4.4/4.5 Regression] checking for nm: test: too many arguments causes Undefined symbol: __gxx_personality_v0
--- Comment #9 from michael dot haubenwallner at salomon dot at 2009-09-29
08:09 ---
(In reply to comment #6)
Can you try GCC 4.3.2 and see if that fails for you?
Still failing with gcc-4.3.3 and gcc-4.4.1: The stage1 xgcc starts doing ICE
once its libgcc_s.a is built, because libgcc_s.a(shr.o) does not export any
symbols due to broken nm, and preinstalled libgmp.a and libmpfr.a find the
local libgcc_s.a when they were built with another gcc.
The configure{,.ac} part of the patch still applies unmodified.
stamp-nm: $(ORIGINAL_NM_FOR_TARGET)
This is no longer there.
Yep, the Makefile now doesn't have this problem any more.
Though we have:
exec $original ${1+$@}
This is problematic, as $original is /path/to/nm -B -X32_64.
It works when the quotes are dropped:
- exec $original ${1+$@}
+ exec $original ${1+$@}
Patch working for both 4.3.3 and 4.4.1 now is:
http://overlays.gentoo.org/proj/alt/export/51702/trunk/prefix-overlay/sys-devel/gcc/files/4.3.0/targettools-checks.patch
--
michael dot haubenwallner at salomon dot at changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33637
[Bug tree-optimization/41498] ICE with graphite flags on trunk
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 09:49 --- Can you provide preprocessed source? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41498
[Bug tree-optimization/41497] [4.5 Regression] apparent integer wrong code bug
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-29 09:51 --- Thus, confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |tree-optimization Ever Confirmed|0 |1 Keywords||wrong-code Known to work||4.3.4 4.4.1 Last reconfirmed|-00-00 00:00:00 |2009-09-29 09:51:50 date|| Summary|apparent integer wrong code |[4.5 Regression] apparent |bug |integer wrong code bug Target Milestone|--- |4.5.0 Version|unknown |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41497
[Bug middle-end/41496] [4.5 regression] Many regressions on trunk
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41496
[Bug lto/41390] [LTO] ICE in lto_output_tree_pointers, at lto-streamer-out.c:1285
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-29 09:53 --- I'll add a testcase after the merge. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-29 09:53:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41390
[Bug fortran/41494] temp and memcpy used when zeroing array
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-29 10:01 ---
I wonder why it uses the extra temporary - that shouldn't be necessary.
Ah, it's because of
else if (ts.type == BT_DERIVED)
{
gfc_add_block_to_block (block, lse-pre);
gfc_add_block_to_block (block, rse-pre);
tmp = gfc_evaluate_now (rse-expr, block);
tmp = fold_build1 (VIEW_CONVERT_EXPR, TREE_TYPE (lse-expr), tmp);
gfc_add_modify (block, lse-expr, tmp);
changing that to something that doesn't call gfc_evaluate_now in the
correct cases should fix this. What do we expect there? My first
bet would be to use EXPR_P as a check. Or maybe we can drop the
gfc_evaluate_now call completely here?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-09-29 10:01:31
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41494
[Bug fortran/41494] [4.5 Regression] temp and memcpy used when zeroing array
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||missed-optimization Summary|temp and memcpy used when |[4.5 Regression] temp and |zeroing array |memcpy used when zeroing ||array Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41494
[Bug lto/41173] [LTO] internal error: builtin function to __builtin_spe_mtspefscr already processed
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-29 10:02 --- Let's add a testcase after the merge. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41173
[Bug bootstrap/41491] [4.5 regression] ICE in set_value_range, at tree-vrp.c:386
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-29 10:03 --- Please attach preprocessed source. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41491
[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-09-29 10:04 --- And s390(x). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392
[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-09-29 10:08 --- Diego, can't we simply drop the assemble_align call from lhd_begin_section? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392
[Bug libstdc++/41448] std::sort on std::vectorfloat with certain values leads to segfault in the vector destructor
--- Comment #8 from chris at bubblescope dot net 2009-09-29 11:04 --- Just to clarify, it is not a memory leak which is occurring, it is memory corruption. Basically when std::sort is given a type which is not totally ordered as required, it tends to corrupt the memory immediately before and after the given array. There are a few ways in which this could be detected, but if it was detected it's not obvious what the behaviour should then be, and obviously it would (slightly) slow down std::sort when given 'correct' types. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41448
[Bug libstdc++/41448] std::sort on std::vectorfloat with certain values leads to segfault in the vector destructor
--- Comment #9 from paolo dot carlini at oracle dot com 2009-09-29 11:55 --- In C++03 this is not a bug. However, I seem to vaguely remember a recent discussion in the committee (basing on either a paper or a DR) about comparisons of floats, if somebody can find a reference I would appreciate it... -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41448
[Bug tree-optimization/41499] New: missed optimization: Scalar evolution analysis prevents vectorization
The hot loop in SPEC2000/179.art scanner.c (line 615) does not get vectorized
due to data ref analysis failure:
(The original loop contains invariant store which I manually extracted out of
the loop. Will try to generate a testcase.)
Taken from the vectorizer dump:
(instantiate_scev
(instantiate_below = 252)
(evolution_loop = 56)
(chrec = {(double *) pretmp.1559_2569 + (long unsigned int) pretmp.1564_2574,
+, (long unsigned int) pretmp.1561_2571}_56)
(res = {(double *) pretmp.1559_2569 + (long unsigned int) pretmp.1564_2574,
+, (long unsigned int) pretmp.1561_2571}_56))
base_address:
offset from base address:
constant offset from base address:
step:
aligned to:
base_object: *((double *) pretmp.1559_2569 + (long unsigned int)
(D.8586_1080 * 8))
(compute_affine_dependence
(stmt_a =
D.8555_1089 = D.8600_1088-P;
)
(stmt_b =
D.8548_1100 = *D.8549_1099;
)
)
scanner.c:615: note: get vectype with 2 units of type double
scanner.c:615: note: vectype: vector double
scanner.c:615: note: not vectorized: data ref analysis failed D.8548_1100 =
*D.8549_1099;
scanner.c:615: note: bad data references.(get_loop_exit_condition
Here are the flags that I used:
/data1/eres/mainline45/bbuild/bin/gcc-m64 -DSPEC_CPU2000_LP64
-mrecip -m64 -fpeel-loops -funroll-loops -ftree-loop-linear -ffast-math -O3
-maltivec -mvsx -Wa,-mpower7 -Wa,-mvsx -mcpu=power7 -fwhole-program
--combine -fipa-matrix-reorg -fdump-tree-vect-details scanner.c -lm -o
art
--
Summary: missed optimization: Scalar evolution analysis prevents
vectorization
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eres at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41499
[Bug lto/40754] lto1 dies with SIGBUS/SIGSEGV on Solaris 11/SPARC
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-29 12:09 ---
Hm. Even lto_read_file_options causes unaligned accesses in some cases. It
looks
like the ELF sections in the wpa files are no aligned:
Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL
0 0 0
[ 1] .gnu.lto_main PROGBITS 0040
02c8 0 0 1
[ 2] .gnu.lto_myprintf PROGBITS 0308
0322 0 0 1
[ 3] .gnu.lto_.cgraph PROGBITS 062a
00c6 0 0 1
...
properly aligning the data in lto_elf_append_data is needed, but only
for the first data block in a section.
I have a hack^Wpatch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-09-29 12:09:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40754
[Bug tree-optimization/41499] Scalar evolution analysis prevents vectorization
--- Comment #1 from eres at il dot ibm dot com 2009-09-29 12:14 --- I was using trunk -r152153 and run on powerpc64. -- eres at il dot ibm dot com changed: What|Removed |Added Keywords||missed-optimization Summary|missed optimization: Scalar |Scalar evolution analysis |evolution analysis prevents |prevents vectorization |vectorization | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41499
[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-09-29 12:56 --- Subject: Bug 40392 Author: rguenth Date: Tue Sep 29 12:56:29 2009 New Revision: 152274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152274 Log: 2009-09-29 Richard Guenther rguent...@suse.de PR lto/41467 * lto-symtab.c (lto_symtab_compatible): Fix typos. PR lto/40392 * langhooks.c (lhd_begin_section): Do not align the section. * config/rs6000/rs6000.c (rs6000_output_function_epilogue): Handle LTO. PR lto/40754 * lto-elf.c (init_shdr##BITS): Properly specify alignment in bytes. (first_data_block): New static variable. (lto_elf_append_data): Align the first data block in each section. * lib/torture-options.exp: Do not append an empty option. Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/config/rs6000/rs6000.c branches/lto/gcc/langhooks.c branches/lto/gcc/lto-symtab.c branches/lto/gcc/lto/ChangeLog branches/lto/gcc/lto/lto-elf.c branches/lto/gcc/testsuite/ChangeLog.lto branches/lto/gcc/testsuite/lib/torture-options.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392
[Bug lto/40754] lto1 dies with SIGBUS/SIGSEGV on Solaris 11/SPARC
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-29 12:56 --- Subject: Bug 40754 Author: rguenth Date: Tue Sep 29 12:56:29 2009 New Revision: 152274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152274 Log: 2009-09-29 Richard Guenther rguent...@suse.de PR lto/41467 * lto-symtab.c (lto_symtab_compatible): Fix typos. PR lto/40392 * langhooks.c (lhd_begin_section): Do not align the section. * config/rs6000/rs6000.c (rs6000_output_function_epilogue): Handle LTO. PR lto/40754 * lto-elf.c (init_shdr##BITS): Properly specify alignment in bytes. (first_data_block): New static variable. (lto_elf_append_data): Align the first data block in each section. * lib/torture-options.exp: Do not append an empty option. Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/config/rs6000/rs6000.c branches/lto/gcc/langhooks.c branches/lto/gcc/lto-symtab.c branches/lto/gcc/lto/ChangeLog branches/lto/gcc/lto/lto-elf.c branches/lto/gcc/testsuite/ChangeLog.lto branches/lto/gcc/testsuite/lib/torture-options.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40754
[Bug lto/41467] ICE in lto_symtab_prevailing_decl, at lto-symtab.c:727 for 483.xalancbmk
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 12:56 --- Subject: Bug 41467 Author: rguenth Date: Tue Sep 29 12:56:29 2009 New Revision: 152274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152274 Log: 2009-09-29 Richard Guenther rguent...@suse.de PR lto/41467 * lto-symtab.c (lto_symtab_compatible): Fix typos. PR lto/40392 * langhooks.c (lhd_begin_section): Do not align the section. * config/rs6000/rs6000.c (rs6000_output_function_epilogue): Handle LTO. PR lto/40754 * lto-elf.c (init_shdr##BITS): Properly specify alignment in bytes. (first_data_block): New static variable. (lto_elf_append_data): Align the first data block in each section. * lib/torture-options.exp: Do not append an empty option. Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/config/rs6000/rs6000.c branches/lto/gcc/langhooks.c branches/lto/gcc/lto-symtab.c branches/lto/gcc/lto/ChangeLog branches/lto/gcc/lto/lto-elf.c branches/lto/gcc/testsuite/ChangeLog.lto branches/lto/gcc/testsuite/lib/torture-options.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41467
[Bug testsuite/41444] Typo in gcc/testsuite/gcc.dg/guality/guality.h
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-29 12:57 --- Subject: Bug 41444 Author: jakub Date: Tue Sep 29 12:56:46 2009 New Revision: 152275 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152275 Log: PR testsuite/41444 * gcc.dg/guality/guality.h (GUALITY_GDB_REDIRECT): Fix a typo in macro name definition for non-unix/win32/msdos. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/guality/guality.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41444
[Bug lto/40392] ICE in lto_end_uncompression, at lto-compress.c:282
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-09-29 12:58 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40392
[Bug testsuite/41444] Typo in gcc/testsuite/gcc.dg/guality/guality.h
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-29 12:58 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41444
[Bug lto/40754] lto1 dies with SIGBUS/SIGSEGV on Solaris 11/SPARC
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-09-29 12:58 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40754
[Bug lto/41467] ICE in lto_symtab_prevailing_decl, at lto-symtab.c:727 for 483.xalancbmk
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-29 12:58 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41467
[Bug bootstrap/41500] New: [4.4 Regression] ARM: 4.4 compiler segfault when compiling gcc
Since 4.4 i'm unable to rebuild gcc, check downstream bug: http://bugs.gentoo.org/286251 Steps to reproduce: - extract gcc-4.4.1 tarball -./configure -make LDFLAGS=-Wl,-O1 STAGE1_CFLAGS=-O LIBPATH=/usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.4.1 'BOOT_CFLAGS= -march=armv5te -pipe -O2' bootstrap-lean -segfaults The failing part is as follows: hecking for armv5tel-softfloat-linux-gnueabi-ar... /usr/armv5tel-softfloat-linux-gnueabi/bin/ar checking for armv5tel-softfloat-linux-gnueabi-lipo... lipo checking for armv5tel-softfloat-linux-gnueabi-nm... /var/tmp/portage/sys-devel/gcc-4.4.1/work/build/./gcc/nm checking for armv5tel-softfloat-linux-gnueabi-ranlib... /usr/armv5tel-softfloat-linux-gnueabi/bin/ranlib checking for armv5tel-softfloat-linux-gnueabi-strip... /usr/armv5tel-softfloat-linux-gnueabi/bin/strip checking whether ln -s works... yes checking for armv5tel-softfloat-linux-gnueabi-gcc... /var/tmp/portage/sys-devel/gcc-4.4.1/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.4.1/work/build/./gcc/ -B/usr/armv5tel-softfloat-linux-gnueabi/bin/ -B/usr/armv5tel-softfloat-linux-gnueabi/lib/ -isystem /usr/armv5tel-softfloat-linux-gnueabi/include -isystem /usr/armv5tel-softfloat-linux-gnueabi/sys-include checking for suffix of object files... configure: error: in `/var/tmp/portage/sys-devel/gcc-4.4.1/work/build/armv5tel-softfloat-linux-gnueabi/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.4.1/work/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.4.1/work/build' config.log contains: configure:2415: /var/tmp/portage/sys-devel/gcc-4.4.1/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.4.1/work/build/./gcc/ -B/usr/armv5tel-softfloat-linux-gnueabi/bin/ -B/usr/armv5tel-softfloat-linux-gnueabi/lib/ -isystem /usr/armv5tel-softfloat-linux-gnueabi/include -isystem /usr/armv5tel-softfloat-linux-gnueabi/sys-include -o conftest -g -march=armv5te -pipe -O2 conftest.c 5 conftest.c: In function 'main': conftest.c:15: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions. configure:2418: $? = 1 configure:2590: checking for suffix of object files configure:2611: /var/tmp/portage/sys-devel/gcc-4.4.1/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.4.1/work/build/./gcc/ -B/usr/armv5tel-softfloat-linux-gnueabi/bin/ -B/usr/armv5tel-softfloat-linux-gnueabi/lib/ -isystem /usr/armv5tel-softfloat-linux-gnueabi/include -isystem /usr/armv5tel-softfloat-linux-gnueabi/sys-include -c -g -march=armv5te -pipe -O2conftest.c 5 conftest.c: In function 'main': conftest.c:15: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions. configure:2614: $? = 1 It works when using -O2 in STAGE1_CFLAGS instead of -O. This doesn't occur on 4.3, 4.3 is able to compile 4.4, but 4.4 is unable to compile itself or gcc-4.3. Not sure if its related, but i filed bug 40105 for SH some time ago, and using -O2 in STAGE1_CFLAGS made it work. Thanks, let me know if you need more info. -- Summary: [4.4 Regression] ARM: 4.4 compiler segfault when compiling gcc Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: armin76 at gentoo dot org GCC host triplet: armv5tel-softfloat-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41500
[Bug tree-optimization/41501] New: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE - `-fprofile-use' fails with '-02'
gcc-4.4.2 testsuite failures:
FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE
using binutils 2.20.51.20090927
Copying sources to a temporary directory and repeating commands used by
testsuite produces this log:
$ ${GCC_BUILD}/gcc/xgcc bb-reorg.c -B${GCC_BUILD}/gcc/ -O2
-freorder-blocks-and-partition -fprofile-generate -D_PROFILE_GENERATE -lm -o
bb-reorg.x01
$ ./bb-reorg.x01
$ ${GCC_BUILD}/gcc/xgcc bb-reorg.c -B${GCC_BUILD}/gcc/ -O2
-freorder-blocks-and-partition -fprofile-use -D_PROFILE_USE -lm -o bb-reorg.x02
/tmp/ccFSvybE.s: Assembler messages:
/tmp/ccFSvybE.s:98: Error: .cfi_endproc without corresponding .cfi_startproc
/tmp/ccFSvybE.s:116: Error: open CFI at the end of file; missing .cfi_endproc
directive
Omitting '-O2' fixes :
$ ${GCC_BUILD}/gcc/xgcc bb-reorg.c -B${GCC_BUILD}/gcc/
-freorder-blocks-and-partition -fprofile-generate -D_PROFILE_GENERATE -lm -o
bb-reorg.x01
$ ./bb-reorg.x01
$ ${GCC_BUILD}/gcc/xgcc bb-reorg.c -B${GCC_BUILD}/gcc/
-freorder-blocks-and-partition -fprofile-use -D_PROFILE_USE -lm -o bb-reorg.x02
$ ./bb-reorg.x02
The same problem occurs with
gcc/testsuite/gcc.dg/tree-prof/pr34999.c .
--
Summary: FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -
fprofile-use -D_PROFILE_USE - `-fprofile-use' fails
with '-02'
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason dot vas dot dias at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41501
[Bug ada/41493] [4.5 regression] ACATS c34006g fails on arm-linux and sparc-rtems
--- Comment #1 from laurent at guerby dot net 2009-09-29 13:32 --- This happens also on arm-linux at rev 152122 http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02662.html .,. C34006G ACATS 2.5 09-09-28 14:27:54^M C34006G CHECK THAT THE REQUIRED PREDEFINED OPERATIONS ARE DECLARED ^M (IMPLICITLY) FOR DERIVED RECORD TYPES WITHOUT^M DISCRIMINANTS AND WITH A LIMITED COMPONENT TYPE.^M * C34006G INCORRECT SELECTION (ASSIGNMENT).^M C34006G FAILED .^M -- laurent at guerby dot net changed: What|Removed |Added CC|guerby at gcc dot gnu dot |laurent at guerby dot net |org | Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|sparc-rtems4.10 | Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2009-09-29 13:32:14 date|| Summary|ACATS c34006g fails |[4.5 regression] ACATS ||c34006g fails on arm-linux ||and sparc-rtems http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41493
[Bug ada/41493] [4.5 regression] ACATS c34006g fails on arm-linux and sparc-rtems
--- Comment #2 from joel at gcc dot gnu dot org 2009-09-29 13:35 --- Add powerpc-rtems4.10 to the list of targets that fail. -- joel at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41493
[Bug ada/41325] ACATS c37105a wrong code on armv5tel
--- Comment #3 from laurent at guerby dot net 2009-09-29 13:38 --- Together with PR41493 these are the only two ACATS fail on arm-linux as of rev 152122: http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02662.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41325
[Bug middle-end/41502] New: ICE in expand_call_inline
gcc.dg/attr-warn-unused-result.c ICEs in Program received signal SIGSEGV, Segmentation fault. 0x00c790bc in expand_call_inline (bb=0x771a0a10, stmt=0x77198000, id=0x7fffd810) at /space/rguenther/src/svn/lto/gcc/tree-inline.c:3661 3661 gcc_assert (!id-src_cfun-after_inlining); (gdb) p cfun $1 = (struct function *) 0x77128140 (gdb) p id-src_cfun $1 = (struct function *) 0x0 -- Summary: ICE in expand_call_inline Product: gcc Version: lto Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41502
[Bug middle-end/41502] ICE in expand_call_inline
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 13:46 ---
Reduced testcase, fails at -O1:
typedef void (*fnt) (void);
extern inline void check3 (void)
{
bar ();
}
void test (void)
{
const fnt pcheck3 = check3;
pcheck3 ();
}
all details important: extern, the call to bar() and the indirect call in test.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-09-29 13:46:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41502
[Bug tree-optimization/41089] [4.5 Regression] r147980 (New SRA) breaks stdargs
--- Comment #31 from jamborm at gcc dot gnu dot org 2009-09-29 13:49 --- (In reply to comment #12) Thus I believe SRA has nothing to do with these remaining failures. If you want to confirm this independently, compile them with -fno-tree-sra. ...and so I un-assign this bug from myself. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jamborm at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41089
[Bug c++/41503] New: function_parameter_expanded_from_pack_p segfaults when passed a PARM_DECL created by IPA-SRA
function_parameter_expanded_from_pack_p() segfaults when compiling 20_util/reference_wrapper/24803.cc and IPA-SRA turned on. The reason is that it is presented a PARM_DECL that was created by IPA-SRA and which does not have language specific data. The backtrace is: #0 0x004b872f in function_parameter_expanded_from_pack_p (param_decl=0x76a123f0, pack=0x76e59cf0) at /home/jamborm/gcc/mine/gcc/cp/pt.c:2679 #1 0x00604090 in gen_subprogram_die (decl=0x76b2ca00, context_die=value optimized out) at /home/jamborm/gcc/mine/gcc/dwarf2out.c:15459 #2 0x00605c01 in gen_decl_die (decl=0x76b2ca00, origin=0x0, context_die=0x7734a2a0) at /home/jamborm/gcc/mine/gcc/dwarf2out.c:17538 #3 0x00605268 in dwarf2out_abstract_function (decl=0x76b2ca00) at /home/jamborm/gcc/mine/gcc/dwarf2out.c:15624 #4 0x0090b11b in optimize_inline_calls (fn=0x76c3e900) at /home/jamborm/gcc/mine/gcc/tree-inline.c:3820 #5 0x008e90af in cgraph_early_inlining () at /home/jamborm/gcc/mine/gcc/ipa-inline.c:1593 #6 0x006ecd04 in execute_one_pass (pass=0x10fe430) at /home/jamborm/gcc/mine/gcc/passes.c:1295 #7 0x006ecf45 in execute_pass_list (pass=0x10fe430) at /home/jamborm/gcc/mine/gcc/passes.c:1344 #8 0x006ecf57 in execute_pass_list (pass=0x10444a0) at /home/jamborm/gcc/mine/gcc/passes.c:1345 #9 0x006ed29e in execute_ipa_pass_list (pass=0x100) at /home/jamborm/gcc/mine/gcc/passes.c:906 #10 0x008e3c6c in cgraph_finalize_compilation_unit () at /home/jamborm/gcc/mine/gcc/cgraphunit.c:1358 #11 0x004e68c6 in cp_write_global_declarations () at /home/jamborm/gcc/mine/gcc/cp/decl2.c:3754 #12 0x0077f0c0 in toplev_main (argc=39, argv=0x7fffd978) at /home/jamborm/gcc/mine/gcc/toplev.c:1050 #13 0x773f3586 in __libc_start_main () from /lib64/libc.so.6 #14 0x00493bc9 in _start () at ../sysdeps/x86_64/elf/start.S:113 I am about to test a patch that will make the function return false if DECL_ARTIFICIAL (param_decl) is true. -- Summary: function_parameter_expanded_from_pack_p segfaults when passed a PARM_DECL created by IPA-SRA Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: jamborm at gcc dot gnu dot org ReportedBy: jamborm at gcc dot gnu dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41503
[Bug middle-end/41502] ICE in expand_call_inline
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-09-29 14:04 ---
static void
ipa_passes (void)
{
...
/* Remove the bodies of extern inline functions that we never
inlined. */
cgraph_remove_unreachable_nodes (false, dump_file);
that's bogus and too early.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2009-09-29 13:46:24 |2009-09-29 14:04:01
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41502
[Bug middle-end/41502] ICE in expand_call_inline
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-09-29 14:20 --- Papered over. ./xgcc -B. -o t.o -shared attr-warn-unused-result.3.i -O -fPIC -flto still ICEs the old way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41502
[Bug middle-end/41502] ICE in expand_call_inline
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-09-29 14:21 --- Subject: Bug 41502 Author: rguenth Date: Tue Sep 29 14:20:37 2009 New Revision: 152277 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152277 Log: 2009-09-29 Richard Guenther rguent...@suse.de * gcc.dg/visibility-7.c: Revert changes. PR middle-end/41502 * cgraphunit.c (ipa_passes): Do not remove bodies of extern inline functions if not generating lto output. Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/cgraphunit.c branches/lto/gcc/testsuite/ChangeLog.lto branches/lto/gcc/testsuite/gcc.dg/visibility-7.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41502
[Bug libfortran/41504] New: Incorrect __gthread_active_p version with weak symbols (pthread_cancel does not bring in pthread_mutex_trylock)
Hello,
Compile the following file with gcc:
void s () {
pthread_cancel();
/*pthread_mutex_trylock (); */
}
and the following file with gfortran:
program test
print*, Bug
end program test
Link both files using gfortran -static -pthread. Note that the program dies
with SEGV in pthread_mutex_trylock (weak symbol equal to 0x0).
It is due to the fact that __gthread_active_p checks only for pthread_cancel
and pthread_mutex_trylock is not automatically taken from libpthread.a.
Un-commenting pthread_mutex_trylock in s() fixes the problem.
Regards,
Dima
--
Summary: Incorrect __gthread_active_p version with weak symbols
(pthread_cancel does not bring in pthread_mutex_trylock)
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: DumaShkurko at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41504
[Bug libfortran/41504] Incorrect __gthread_active_p version with weak symbols (pthread_cancel does not bring in pthread_mutex_trylock)
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 14:31 --- You need to link libpthread.a with -Wl,--whole-archive In general static linking is not recommended with glibc and threads. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41504
[Bug debug/41438] [4.5 Regression] VTA: libgomp build fails due to inconsistent debug info
--- Comment #1 from jakub at gcc dot gnu dot org 2009-09-29 14:40 --- My http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02070.html patch fixes this too. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|aoliva at gcc dot gnu dot |jakub at gcc dot gnu dot org |org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||09/msg02070.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-09-29 14:40:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41438
[Bug tree-optimization/41501] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE - `-fprofile-use' fails with '-02'
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-29 14:58 --- This was fixed on the trunk, I don't have the changelog entry handy though, but it was done by Jakub IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41501
[Bug libfortran/41504] Incorrect __gthread_active_p version with weak symbols (pthread_cancel does not bring in pthread_mutex_trylock)
--- Comment #2 from DumaShkurko at gmail dot com 2009-09-29 15:09 --- Is it possible to adjust specs file for -static and/or -pthread? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41504
[Bug fortran/41479] [4.3/4.4/4.5 Regression] intent(out) for types with default initialization
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41479
[Bug target/41505] New: GCC choosing poor code sequence for certain stores (x86)
Consider:
foo(int *x)
{
*x = 0;
}
Compile with -Os -fomit-frame-pointer and you'll get something like this:
movl4(%esp), %eax
movl$0, (%eax)
It would be 2 bytes shorter to instead load the constant 0 via an xor
instruction into a scratch register, then store the scratch register into the
memory location. Something like this:
movl4(%esp), %eax
xor %edx, %edx
movl%edx, (%eax)
ISTM this could easily be implemented with a peep2.
I'm not well versed enough in x86 instruction timings to know if the xor
sequence is going to generally be faster.
--
Summary: GCC choosing poor code sequence for certain stores (x86)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: law at redhat dot com
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=41505
[Bug gcov-profile/41506] New: all gcov tests fail because gcov.c's use of '#define __USE_GNU' has no effect
Every gcov test in the gcov testsuite
( gcc/testsuite/gcc.misc-tests/gcov.exp )
fails because gcov gets a SIGSEGV
on its first invocation of 'fgets()' -
'char *fgets_unlocked( char *buf, size_t size, FILE *stream )
'
is NOT declared, because '__USE_GNU' is NOT defined ;
__USE_GNU is explicitly '#undef'd in /usr/include/features.h,
and hence any prexisting user definition of it is discarded,
so stdio.h's :
#ifdef __USE_GNU
extern char *fgets_unlocked (char *__restrict __s, int __n,
FILE *__restrict __stream) __wur;
#endif
produces no output, so 'fgets_unlocked' is implicitly declared to return an
int,
producing these warnings when gcov.o is built by 'make bootstrap' :
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I.
-I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/bid -I../libdecnumber
../../gcc/gcov.c -o gcov.o
../../gcc/gcov.c: In function 'output_lines':
../../gcc/gcov.c:1931: warning: implicit declaration of function
'fgets_unlocked'
../../gcc/gcov.c:1931: warning: assignment makes pointer from integer without a
cast
../../gcc/gcov.c:1934: warning: implicit declaration of function
'fputs_unlocked'
../../gcc/gcov.c:1974: warning: assignment makes pointer from integer without a
cast
../../gcc/gcov.c:1980: warning: assignment makes pointer from integer without a
cast
so gcov gets a SIGSEGV the first time it dereferences the return value of
fgets(), which is a 64-bit pointer value converted to a 32-bit integer
and then back to a 64-bit pointer, on my x86_64 ,
as shown by gdb running gcov with the testsuite 'gcov-1.c' as input:
...
Reading symbols from /usr/build2/gcc/gcc-4_4-branch/x86_64/gcc/gcov...done.
(gdb) start gcov-1.c
Temporary breakpoint 1 at 0x403090: file ../../gcc/gcov.c, line 360.
Starting program: /usr/build2/gcc/gcc-4_4-branch/x86_64/gcc/gcov gcov-1.c
Temporary breakpoint 1, main (argc=2, argv=0x7fffeb58) at
../../gcc/gcov.c:360
360 {
(gdb) c
Continuing.
File 'gcov-1.c'
Lines executed:100.00% of 6
gcov-1.c:creating 'gcov-1.c.gcov'
Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:31
31 pcmpeqb (%rdi), %xmm2
Current language: auto
The current source language is auto; currently asm.
(gdb) where
#0 strlen () at ../sysdeps/x86_64/strlen.S:31
#1 0x7781419e in *__GI_fputs_unlocked (str=0xe940 Address
0xe940 out of bounds, fp=0x6082a0) at iofputs_u.c:37
#2 0x0040428e in output_lines (argc=2, argv=0x7fffeb58) at
../../gcc/gcov.c:1934
#3 generate_results (argc=2, argv=0x7fffeb58) at ../../gcc/gcov.c:581
#4 main (argc=2, argv=0x7fffeb58) at ../../gcc/gcov.c:381
(gdb) up
#1 0x7781419e in *__GI_fputs_unlocked (str=0xe940 Address
0xe940 out of bounds, fp=0x6082a0) at iofputs_u.c:37
37_IO_size_t len = strlen (str);
Current language: auto
The current source language is auto; currently c.
(gdb) up
#2 0x0040428e in output_lines (argc=2, argv=0x7fffeb58) at
../../gcc/gcov.c:1934
1934 fputs (retval, gcov_file);
(gdb) print retval
$1 = 0xe940 Address 0xe940 out of bounds
It appears that the autoconf macro that sets HAVE_DECL_FGETS_UNLOCKED
( gcc/acinclude.m4's gcc_AC_CHECK_DECL ) sets
'#define _GNU_SOURCE 1' ,
so it sees the declaration of fgets_unlocked(), while gcov.c's
'#define __USE_GNU'
has no effect ( __USE_GNU is #undef'd by features.h ).
Suggested patch:
$ diff -u gcov.c~ gcov.c
--- gcov.c~ 2009-04-10 16:48:28.0 +0100
+++ gcov.c 2009-09-29 16:53:52.0 +0100
@@ -31,8 +31,8 @@
/* Need an option to show individual block counts, and show
probabilities of fall through arcs. */
-#define __USE_XOPEN
-#define __USE_GNU
+#define _XOPEN_SOURCE 1
+#define _GNU_SOURCE 1
#include sys/types.h
#include unistd.h
#include stdio.h
--
Summary: all gcov tests fail because gcov.c's use of '#define
__USE_GNU' has no effect
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason dot vas dot dias at gmail dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41506
[Bug gcov-profile/41506] all gcov tests fail because gcov.c's use of '#define __USE_GNU' has no effect
--- Comment #1 from jason dot vas dot dias at gmail dot com 2009-09-29 15:59 --- Created an attachment (id=18666) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18666action=view) Patch to fix gcov -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41506
[Bug gcov-profile/41506] all gcov tests fail because gcov.c's use of '#define __USE_GNU' has no effect
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-29 16:06 --- It would be helpful to know what you are patching, because neither 4.4 branch nor trunk gcov.c has anything like that, see e.g. http://sources.redhat.com/viewcvs/gcc/branches/gcc-4_4-branch/gcc/gcov.c?revision=145122view=markup -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41506
[Bug target/41505] GCC choosing poor code sequence for certain stores (x86)
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-09-29 16:07 --- difficult -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41505
[Bug target/41327] [4.4 regression] ICE (segmentation fault) with -O3
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-29 16:09 --- Can't reproduce with x86_64-linux - s390x-linux cross (-O3 -m31). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41327
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #37 from jamborm at gcc dot gnu dot org 2009-09-29 16:16 --- (In reply to comment #34) It is tree.o object of stage2 gcc that gets miscompiled when -fipa-sra is added to BOOT_CFLAGS. If tree.o is substituted with the one from the build without BOOT_CFLAGS, gcc is again able to compile hello.c without crashing. Can you please attach pre-processed source of it so that I can try running it through a cross-compiler? Additionally, -fdump-tree-cddce-slim and -fdump-tree-eipa_sra-details dumps would also be appreciated. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug fortran/41507] New: Documentation misleading on MAXLOC/MINLOC array type requirement
The gfortran manual's documentation about MAXLOC/MINLOC is misleading. It claims that the 'array' argument may be of CHARACTER type, which is true for Fortran 2003. However, the manual claims the intrinsic is Fortran 90/95 without further notice about CHARACTER type being allowed only since F2003. Additionally, MAXLOC/MINLOC is not even implemented for CHARACTER type in gfortran yet. I think the manual should at very least reflect what's actually implemented, rather than just copy the description from the standard. I've not checked, but the same problem may exist with other intrinsics as well. -- Summary: Documentation misleading on MAXLOC/MINLOC array type requirement Product: gcc Version: unknown Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41507
[Bug c++/41503] function_parameter_expanded_from_pack_p segfaults when passed a PARM_DECL created by IPA-SRA
--- Comment #1 from jamborm at gcc dot gnu dot org 2009-09-29 16:42 ---
The following patch fixes the problem, I will send it to the mailing
list soon:
2009-09-29 Martin Jambor mjam...@suse.cz
PR c++/41503
* cp/pt.c (function_parameter_expanded_from_pack_p): Return false if
DECL_ARTIFICIAL (param_decl) is true.
Index: mine/gcc/cp/pt.c
===
--- mine.orig/gcc/cp/pt.c
+++ mine/gcc/cp/pt.c
@@ -2669,7 +2669,8 @@ get_function_template_decl (const_tree p
bool
function_parameter_expanded_from_pack_p (tree param_decl, tree pack)
{
-if (! function_parameter_pack_p (pack))
+if (DECL_ARTIFICIAL (param_decl)
+ || !function_parameter_pack_p (pack))
return false;
gcc_assert (DECL_NAME (param_decl) DECL_NAME (pack));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41503
[Bug c++/41503] function_parameter_expanded_from_pack_p segfaults when passed a PARM_DECL created by IPA-SRA
--- Comment #2 from jamborm at gcc dot gnu dot org 2009-09-29 16:52 --- (In reply to comment #1) The following patch fixes the problem, I will send it to the mailing list soon: http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02105.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41503
[Bug target/41505] GCC choosing poor code sequence for certain stores (x86)
--- Comment #2 from law at redhat dot com 2009-09-29 17:12 --- I don't understand your comment Richard. Isn't it just something like this? (define_peephole2 [(match_scratch:SI 2 r) (set (match_operand:SI 0 memory_operand ) (match_operand:SI 1 const_0_operand ))] [(set (match_dup 2) (match_dup 1)) (set (match_dup 0) (match_dup 2))] ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41505
[Bug debug/41438] [4.5 Regression] VTA: libgomp build fails due to inconsistent debug info
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-29 17:34 --- Subject: Bug 41438 Author: jakub Date: Tue Sep 29 17:33:58 2009 New Revision: 152282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152282 Log: PR debug/41438 * dwarf2out.c (const_ok_for_output_1, const_ok_for_output): New functions. (mem_loc_descriptor, loc_descriptor, add_const_value_attribute): Bail out if !const_ok_for_output. PR debug/41474 * dwarf2out.c (mem_loc_descriptor) case CONCAT, case CONCATN, case VAR_LOCATION: Remove gcc_unreachable (). * gcc.dg/debug/dwarf2/const-1.c: Add dg-require-visibility, make x hidden. * g++.dg/debug/dwarf2/const-1.C: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/const1.C trunk/gcc/testsuite/gcc.dg/debug/dwarf2/const-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41438
[Bug debug/41438] [4.5 Regression] VTA: libgomp build fails due to inconsistent debug info
--- Comment #3 from jakub at gcc dot gnu dot org 2009-09-29 17:39 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41438
[Bug debug/41474] [4.5 Regression] 951116-1.c ICEs in mem_loc_descriptor, at dwarf2out.c:11279
--- Comment #4 from jakub at gcc dot gnu dot org 2009-09-29 17:40 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41474
[Bug testsuite/41496] [4.5 regression] Many regressions on trunk
--- Comment #1 from hjl dot tools at gmail dot com 2009-09-29 17:36 ---
Hi Janis, I think one of your patches causes this. It removed
-ansi -pedantic-errors -Wno-long-long in the second run for
--target_board 'unix{-m32,}'.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||janis187 at us dot ibm dot
||com
Component|middle-end |testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41496
[Bug testsuite/41496] [4.5 regression] Many regressions on trunk
--- Comment #2 from hjl dot tools at gmail dot com 2009-09-29 18:02 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02117.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||09/msg02117.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41496
[Bug libstdc++/41495] libstdc++ --enable-clocale=ieee_1003.1-2001 fails
--- Comment #1 from ro at gcc dot gnu dot org 2009-09-29 18:09 --- Testing the trivial fix on Solaris 10/x86 to see how far this gets me. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41495
[Bug testsuite/41496] [4.5 regression] Many regressions on trunk
--- Comment #3 from hjl at gcc dot gnu dot org 2009-09-29 18:29 --- Subject: Bug 41496 Author: hjl Date: Tue Sep 29 18:29:24 2009 New Revision: 152287 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152287 Log: 2009-09-29 H.J. Lu hongjiu...@intel.com PR testsuite/41496 * g++.dg/dfp/dfp.exp: Unset DEFAULT_CXXFLAGS if it didn't exist before. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/dfp/dfp.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41496
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #38 from ubizjak at gmail dot com 2009-09-29 18:36 --- (In reply to comment #37) Can you please attach pre-processed source of it so that I can try running it through a cross-compiler? Additionally, -fdump-tree-cddce-slim and -fdump-tree-eipa_sra-details dumps would also be appreciated. Thanks. I belive that this failure is due to PR41089 and manifest itself in FAIL: gcc.c-torture/execute/stdarg-1.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/stdarg-1.c execution, -O3 -g Jakub has promised to look into stdarg issue, so perhaps we should wait a bit... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug tree-optimization/41501] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE - `-fprofile-use' fails with '-02'
--- Comment #2 from ubizjak at gmail dot com 2009-09-29 18:47 --- (In reply to comment #1) This was fixed on the trunk, I don't have the changelog entry handy though, but it was done by Jakub IIRC. 2009-08-07 Jakub Jelinek ja...@redhat.com * dwarf2out.c (output_fde): When doing hot/cold partitioning, use fde-dw_fde_begin as begin label instead of hot/cold label. Use LLSDAC label instead of LLSDA for second section lsda. (dwarf2out_do_cfi_startproc): Add SECOND argument. Use LLSDAC label instead of LLSDA if it is true. (dwarf2out_begin_prologue, dwarf2out_switch_text_section): Adjust callers. * except.c (add_call_site, dw2_size_of_call_site_table): Add SECTION argument. Use it as index into crtl-eh.call_site_record array. (dw2_output_call_site_table): Likewise. Add CS_FORMAT argument, use it to determine how to print table entries instead of using #ifdef HAVE_AS_LEB128. For SECTION 0 use hot resp. cold label instead of normal begin label as base. (sjlj_assign_call_site_values): Adjust add_call_site caller. (convert_to_eh_region_ranges): When doing hot/cold partitioning, ensure no EH range spans between sections and that landing pads are always in the corresponding section. (sjlj_size_of_call_site_table, sjlj_output_call_site_table): Adjust for crtl-eh.call_site_record being an array rather than scalar. (output_one_function_exception_table): New function, copied from output_function_exception_table. Adjust dw2_size_of_call_site_table, dw2_output_call_site_table callers. For SECOND section use *C suffixed labels. (output_function_exception_table): Call output_one_function_exception_table and, when doing hot/cold partitioning, also another time for the second section. * opts.c: Include except.h. (decode_options): Allow -freorder-blocks-and-partition with exceptions, unless SJLJ or TARGET_UNWIND_INFO. * Makefile.in (opts.o): Depend on $(EXCEPT_H). * function.h (struct rtl_eh): Change call_site_record from scalar into array of 2 elements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41501
[Bug c++/41508] New: error: no matching function for call to ...
I am currently porting an app from Sun Solaris where we use the Solaris cc compiler (version 5.8). Have a 12 year old legacy app that compiles fine in the current environment :-) While trying to migrate to RedHat Linux and the GNU g++ compiler (version 4.1.2) I am repeatedly running into error: no matching function for call to ... errors with code that sends and/or receives reference parameters. Here's an example of the compiler error: EJPeriod.C:102: error: no matching function for call to âEJPeriod::EJPeriod(Date, Date, String)â EJPeriod.h:83: note: candidates are: EJPeriod::EJPeriod(EJPeriod) EJPeriod.h:76: note: EJPeriod::EJPeriod() EJPeriod.h:72: note: EJPeriod::EJPeriod(Date, Date, String) I don't understand why the compiler doesn't recognize the 3rd constructor referenced by line 72. When I try to overload the constructor to satisfy the compiler complaint the compiler correctly tells me the two constructors create an ambiguous situation. Can you advise as to whether this is a compiler bug or a potentially old coding standard that isn't acceptable with the version of the GNU compiler we are using? Also, this only seems to occur with our home grown classes. The compiler has no issue with basic scalar types and the passing and receiving of reference and non-reference parameters. Lastly and admittedly, when I create a simple test.C program to duplicate the issue the simple example compiles. There must be something else in the 1000s of lines of code that I am overlooking. Thanks in advance for any help or direction you can provide. Regards, Marc -- Summary: error: no matching function for call to ... Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mwarshofsk at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41508
[Bug tree-optimization/14741] missing transformations lead to poorly optimized code
--- Comment #16 from jv244 at cam dot ac dot uk 2009-09-29 18:59 --- since graphite should be able to fix this PR, I tried it without luck: gfortran -ffast-math -O3 -march=native -fgraphite -floop-interchange -floop-block test.f90 test.f90: In function MAIN__: test.f90:1:0: sorry, unimplemented: loop blocking not implemented test.f90:1:0: internal compiler error: in apply_poly_transforms, at graphite-poly.c:253 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
[Bug c++/41508] error: no matching function for call to ...
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-09-29 19:15 --- Can you show the line where the call to EJPeriod::EJPeriod is done? It might be because String that you are passing is a rvalue which cannot be bound to String as that would mean it needs to be bound to a lvalue. rvalues can be bound to const references (or in C++0x rvalue references too). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41508
[Bug c++/41508] error: no matching function for call to ...
--- Comment #2 from mwarshofsk at aol dot com 2009-09-29 19:24 ---
This is the method where I am receiving the compiler error:
enum err_stat EJPeriod::rollup( ListEmplJob src, ListEJPeriod dst,
Date startDt, Date endDt )
{
// then theres a bunch of code
// and then the offending line is the one below starting w/EJPeriod
if( srcSize == 1 ) {
EJPeriod ejptmp( startDt, endDt, src(0)-get_job_title_mgmt_ind() );
dst.add( new EJPeriod( ejptmp ) );
return( Success );
}
The object named src is a home grown template linked list class.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41508
[Bug c++/41508] error: no matching function for call to ...
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-09-29 19:25 --- What type does get_job_title_mgmt_ind return? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41508
[Bug c++/41508] error: no matching function for call to ...
--- Comment #4 from mwarshofsk at aol dot com 2009-09-29 19:32 ---
Here's the definition for that call ... I think you're on to something
String get_job_title_mgmt_ind() const { return _jobTitleMgmtInd; };
When I change the constructor to non reference paramters it seems to compile
fine. I've got dozens of these to go through. I suspect they're probably all
similar. Is there a better fix than removing the reference parameter? I'm not
really sure why the old code has it as a reference anyway. The constructor is
not looking to change that value anyway ... its just using it to initialize a
data member.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41508
[Bug c++/41508] error: no matching function for call to ...
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-09-29 19:41 --- Yes GCC is correct as in C++ rvalues don't bind to references as only lvalues bind to references. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41508
[Bug debug/39708] add a debug_privnames section
--- Comment #2 from tromey at gcc dot gnu dot org 2009-09-29 20:03 --- This is obsoleted by the newer idea in PR 41130. *** This bug has been marked as a duplicate of 41130 *** -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39708
[Bug debug/41130] GCC should emit an index of publicly named entities
--- Comment #6 from tromey at gcc dot gnu dot org 2009-09-29 20:03 --- *** Bug 39708 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41130
[Bug c++/41508] error: no matching function for call to ...
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-29 20:08 --- If the ctor isn't going to change it, you could as well change the argument type to const String instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41508
[Bug c++/41508] error: no matching function for call to ...
--- Comment #7 from mwarshofsk at aol dot com 2009-09-29 20:34 --- Comment 6 is perfect! That makes total sense. Thanks so much! Actually, I bet the Solaris compiler is implicitly treating this same code as a const String behind the scenes. We'll just explicitly make that promise/fix for this migration. Thanks so much for the speedy and excellent responses!!! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41508
[Bug tree-optimization/19778] Unnecessary jumps for comparisons
--- Comment #3 from ubizjak at gmail dot com 2009-09-29 20:45 --- This is not alpha specific, but generic tree issue. The _.optimized dump: bb 2: if (x_2(D) == 0) goto bb 4; else goto bb 3; bb 3: D.2022_3 = x_2(D) + -1; D.2023_4 = D.2022_3 x_2(D); D.2016_9 = D.2023_4 == 0; bb 4: # D.2016_1 = PHI D.2016_9(3), 1(2) return D.2016_1; However, by changing boolean or to integer or: bb 2: D.2017_2 = x_1(D) == 0; D.2018_3 = x_1(D) + -1; D.2019_4 = D.2018_3 x_1(D); D.2020_5 = D.2019_4 == 0; D.2021_6 = D.2020_5 | D.2017_2; D.2016_7 = (int) D.2021_6; return D.2016_7; -- ubizjak at gmail dot com changed: What|Removed |Added GCC target triplet|alphaev68-*-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19778
[Bug tree-optimization/19778] Unnecessary jumps for comparisons
--- Comment #4 from ubizjak at gmail dot com 2009-09-29 20:53 --- In fact, this implements short-cut of boolean OR. Function returns early for x == 0 and should not execute right part of OR expression in this case. Something like: if (x == 0 || (x (x - 1)) == 0) return 1; else return 0; -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19778
[Bug bootstrap/41395] [4.5 regression] Revision 151800 failed bootstrap
--- Comment #39 from rth at gcc dot gnu dot org 2009-09-29 20:54 --- (In reply to comment #35) static tree build_function_type_list_1 (bool vaargs, tree return_type, va_list argp) Passing va_list by value is non-portable. One fix here is to pass argp by reference. Dunno if that fixes this problem though, since the main problem for Alpha seems to be the stdarg thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
[Bug tree-optimization/19778] Unnecessary jumps for comparisons
--- Comment #5 from falk at debian dot org 2009-09-29 21:02 --- Of course the optimization would be wrong if the second clause had side effects, but it doesn't and this will frequently be the case. So this is definitely a valid and in my opinion worthwhile optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19778
[Bug target/41505] GCC choosing poor code sequence for certain stores (x86)
--- Comment #3 from rth at gcc dot gnu dot org 2009-09-29 21:18 --- There are already peepholes for this, though the condition appears to be slightly wrong for -Os. See i386.md:21121 : (define_peephole2 [(match_scratch:SI 1 r) (set (match_operand:SI 0 memory_operand ) (const_int 0))] optimize_insn_for_speed_p () ! TARGET_USE_MOV0 TARGET_SPLIT_LONG_MOVES get_attr_length (insn) = ix86_cur_cost ()-large_insn peep2_regno_dead_p (0, FLAGS_REG) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41505
[Bug rtl-optimization/22031] Poor code from unrolled simple loop
--- Comment #6 from ubizjak at gmail dot com 2009-09-29 21:18 --- Not alpha specific, happens on current mainline, where on x86_64 we produce the code as shown in comment #5. I think that Richi will be interested in the fact that the usage of __restrict does not change generated code in any way. -- ubizjak at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|WAITING |NEW Ever Confirmed|0 |1 GCC build triplet|alphaev68-unknown-linux-gnu | GCC host triplet|alphaev68-unknown-linux-gnu | Last reconfirmed|2009-02-09 08:28:40 |2009-09-29 21:18:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22031
[Bug libmudflap/28077] [4.3 regression] pass39-frag.c produces mudflap violation on alpha
--- Comment #9 from ubizjak at gmail dot com 2009-09-29 21:41 --- (In reply to comment #6) Can someone check if this still fails on latest 4.3 branch? It doesn't. See [1]. [1] http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg01497.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28077
[Bug target/41279] [4.5 Regression] 252.eon performance regression
--- Comment #6 from jakub at gcc dot gnu dot org 2009-09-29 21:42 ---
I've looked at what code generation changes the jump from r151310 to r151312
(aka VTA merge) and on eon.cc at -O3 -funroll-loops -fpeel-loops on ia64-linux
the difference is that r151310 unroll something that r151312 does not.
The change that caused this is in num_loop_insns:
@@ -176,8 +176,8 @@ num_loop_insns (const struct loop *loop)
{
bb = bbs[i];
ninsns++;
- for (insn = BB_HEAD (bb); insn != BB_END (bb); insn = NEXT_INSN (insn))
- if (INSN_P (insn))
+ FOR_BB_INSNS (bb, insn)
+ if (NONDEBUG_INSN_P (insn))
ninsns++;
}
free(bbs);
Note that before we didn't count BB_END (bb) insn (well, it is probably counted
in that ninsns++ before the loop), but now we do. Similar change to
average_num_loop_insns changed binsns = 1; before the loop to binsns = 0;, so I
think that:
--- cfgloopanal.c.xx2009-09-29 17:19:59.0 +0200
+++ cfgloopanal.c 2009-09-29 23:30:26.0 +0200
@@ -175,12 +175,11 @@ num_loop_insns (const struct loop *loop)
for (i = 0; i loop-num_nodes; i++)
{
bb = bbs[i];
- ninsns++;
FOR_BB_INSNS (bb, insn)
if (NONDEBUG_INSN_P (insn))
ninsns++;
}
- free(bbs);
+ free (bbs);
return ninsns;
}
is a correct change. No idea whether 252.eon's hot loop is in eon.cc or
elsewhere though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug testsuite/29737] make check fixinclude test FAILURES
--- Comment #6 from ubizjak at gmail dot com 2009-09-29 21:52 --- This is fixed in 4.3+: All fixinclude tests pass make[2]: Leaving directory `/space/uros/gcc-build-43/fixincludes' -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29737
[Bug bootstrap/29889] jc1 segfaults while bootstrap
--- Comment #2 from ubizjak at gmail dot com 2009-09-29 21:55 --- (In reply to comment #1) Also the date here is from before the big gcj-eclipse merge. So, maybe things are different now. Sure, they are fixed [1]. [1]: http://gcc.gnu.org/ml/gcc-testresults/2009-08/msg01386.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29889
[Bug target/41505] GCC choosing poor code sequence for certain stores (x86)
--- Comment #4 from law at redhat dot com 2009-09-29 21:55 --- Subject: Re: GCC choosing poor code sequence for certain stores (x86) On 09/29/09 15:18, rth at gcc dot gnu dot org wrote: --- Comment #3 from rth at gcc dot gnu dot org 2009-09-29 21:18 --- There are already peepholes for this, though the condition appears to be slightly wrong for -Os. See i386.md:21121 : (define_peephole2 [(match_scratch:SI 1 r) (set (match_operand:SI 0 memory_operand ) (const_int 0))] optimize_insn_for_speed_p () ! TARGET_USE_MOV0 TARGET_SPLIT_LONG_MOVES get_attr_length (insn)= ix86_cur_cost ()-large_insn peep2_regno_dead_p (0, FLAGS_REG) Ah, yes, the flags register needs to be available. As for the condition, after reading optimization guides for the various x86 chips that mov $0, mem is generally going to be faster than xor temp, temp mov temp, mem So I was thinking we'd want something like this for the condition. ((optimize_insn_for_size_p () || (!TARGET_USE_MOV0 TARGET_SPLIT_LONG_MOVES get_attr_length (insn) = ix86_cur_cost()-large_insn)) peep2_regno_dead_p (0, FLAGS_REG) Which I think should always give us the xor sequence when optimizing for size or when optimizing for the odd x86 implementation where the xor sequence is faster. I can easily bundle that up as a patch if it looks right to you... Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41505
[Bug c++/29918] FAIL: 23_containers/vector/cons/4.cc
--- Comment #1 from ubizjak at gmail dot com 2009-09-29 21:58 --- (In reply to comment #0) libstdc++ test 23_containers/vector/cons/4.cc fails: No more [1]. [1] http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00242.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29918
[Bug target/32866] gcc-4.2.1 ICE in stage2 during make bootstrap
--- Comment #1 from ubizjak at gmail dot com 2009-09-29 22:02 --- Please try with newer gcc, 4.2.x is not supported anymore. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32866
[Bug testsuite/33263] [4.3/4.4/4.5 regression] libjava testsuite failures on alpha-linux
--- Comment #10 from ubizjak at gmail dot com 2009-09-29 22:06 --- Libjava has zero failures with gcc 4.3.5, 4.4.2 and 4.5.0 for me on latest Gentoo. Please reopen if it still fails for you. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33263
[Bug target/38581] Tru64 outputs non-virtual thunks as non-weak symbols
--- Comment #3 from ubizjak at gmail dot com 2009-09-29 22:12 --- 4.2.4 is not supported anymore. Please try with newer gcc. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38581
[Bug target/41365] [4.5 Regression] gcc.dg/vect/vect-cond-[123].c abort due to bad code generation at -O1 and above
--- Comment #3 from sje at gcc dot gnu dot org 2009-09-29 22:21 --- Subject: Bug 41365 Author: sje Date: Tue Sep 29 22:21:27 2009 New Revision: 152306 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152306 Log: 2009-09-29 Steve Ellcey s...@cup.hp.com Alexander Monakov amona...@ispras.ru PR target/41365 * config/ia64/predicates.md (not_postinc_destination_operand): New. (not_postinc_memory_operand): New. (not_postinc_move_operand): New. * config/ia64/ia64.md (*cmovdi_internal): Disallow autoincrement. (*cmovsi_internal): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.md trunk/gcc/config/ia64/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41365
[Bug target/41365] [4.5 Regression] gcc.dg/vect/vect-cond-[123].c abort due to bad code generation at -O1 and above
--- Comment #4 from sje at cup dot hp dot com 2009-09-29 22:36 --- Fixed. -- sje at cup dot hp dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41365
[Bug target/41327] [4.4 regression] ICE (segmentation fault) with -O3
--- Comment #3 from debian-gcc at lists dot debian dot org 2009-09-29 22:44 --- confirmed: https://buildd.debian.org/fetch.cgi?pkg=gcc-snapshotver=20090923-1arch=alphastamp=1253933048file=log https://buildd.debian.org/fetch.cgi?pkg=gcj-4.4ver=4.4.1-4arch=alphastamp=1252769258file=log thanks! although I see regression in the libffi testsuite on trunk Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41327
[Bug testsuite/33263] [4.3/4.4/4.5 regression] libjava testsuite failures on alpha-linux
--- Comment #11 from debian-gcc at lists dot debian dot org 2009-09-29 22:45 --- confirmed: https://buildd.debian.org/fetch.cgi?pkg=gcc-snapshotver=20090923-1arch=alphastamp=1253933048file=log https://buildd.debian.org/fetch.cgi?pkg=gcj-4.4ver=4.4.1-4arch=alphastamp=1252769258file=log thanks! although I see regression in the libffi testsuite on trunk Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33263
[Bug target/41327] [4.4 regression] ICE (segmentation fault) with -O3
--- Comment #4 from debian-gcc at lists dot debian dot org 2009-09-29 22:47 --- sorry, the last comment should have gone to PR33263, I'll need to find the time to recheck this issue. Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41327
[Bug target/41327] [4.4 regression] ICE (segmentation fault) with -O3
--- Comment #5 from debian-gcc at lists dot debian dot org 2009-09-29 22:48 --- fixed -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work|4.3.4 4.5.0 |4.3.4 4.5.0 4.4.2 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41327
