[Bug java/41991] gcj segfaults on i686-apple-darwin9 and x86_64-apple-darwin9
--- Comment #43 from gcc at ryandesign dot com 2010-06-20 06:57 --- Is there a reason the 3 fixes Andreas committed in February were not backported to the 4.4 branch? I just ran into Internal error: Abort trap (program ecj1) with 4.4.4 on Snow Leopard 10.6.4 and applying those patches fixed it. -- gcc at ryandesign dot com changed: What|Removed |Added CC||gcc at ryandesign dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41991
[Bug c/44598] -Wunused-variable miss 'static const char x[] = ;'
--- Comment #2 from dimhen at gmail dot com 2010-06-20 07:32 --- (In reply to comment #1) Well... 1) so, gcc miss 'set-but-not-used' warning in testcase? 2) in testcase there are no more code to which 'x' may be inlined. Yes? 3) change test to static const char x[] = ; static const char const * b = ; changes nothing in diagnistics 4) add -O3 -Wextra changes nothing in diagnistics -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44598
[Bug target/44531] [4.5/4.6 Regression] [SH] Multilib configuration does not work as expected on darwin
--- Comment #3 from kkojima at gcc dot gnu dot org 2010-06-20 10:56 ---
I can reproduce it on an old ppc darwin. It looks that this
darwin's sed doesn't support the 'i' modifier for the 's' command
and drops all multilibs list specified.
Does the patch below work for you?
--- gcc/config.gcc~ 2010-04-07 19:34:00.0 +0900
+++ gcc/config.gcc 2010-06-20 18:08:46.0 +0900
@@ -2315,7 +2315,7 @@ sh-*-symbianelf* | sh[12346l]*-*-symbian
target_cpu_default=SELECT_`echo ${sh_cpu_default}|tr
abcdefghijklmnopqrstuvwxyz- ABCDEFGHIJKLMNOPQRSTUVWXYZ_`
tm_defines=${tm_defines}' SH_MULTILIB_CPU_DEFAULT=\'`echo
$sh_cpu_default|sed s/sh/m/`'\'
tm_defines=$tm_defines SUPPORT_`echo $sh_cpu_default | sed 's/^m/sh/'
| tr abcdefghijklmnopqrstuvwxyz- ABCDEFGHIJKLMNOPQRSTUVWXYZ_`=1
- sh_multilibs=`echo $sh_multilibs | sed -e 's/,/ /g' -e 's/^sh/m/i' -e
's/ sh/ m/gi' | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ_ abcdefghijklmnopqrstuvwxyz-`
+ sh_multilibs=`echo $sh_multilibs | sed -e 's/,/ /g' -e 's/^[Ss][Hh]/m/'
-e 's/ [Ss][Hh]/ m/g' | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ_
abcdefghijklmnopqrstuvwxyz-`
for sh_multilib in ${sh_multilibs}; do
case ${sh_multilib} in
m1 | m2 | m2e | m3 | m3e | \
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Known to fail||4.5.0 4.6.0
Known to work||4.4.4
Last reconfirmed|-00-00 00:00:00 |2010-06-20 10:56:53
date||
Summary|[SuperH] Multilib |[4.5/4.6 Regression] [SH]
|configuration does not work |Multilib configuration does
|as expected |not work as expected on
||darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44531
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #14 from eblot dot ml at gmail dot com 2010-06-20 13:53 --- (In reply to comment #10) I'd suggest generating all dumps, going through them and looking where and why the if statement disappears and how the switch statement evolved before being removed by switch conversion. Let me know how to proceed if you need more dumps. BTW, should not this bug be updated to a confirmed state? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug target/44531] [4.5/4.6 Regression] [SH] Multilib configuration does not work as expected on darwin
--- Comment #4 from ljsebald at gmail dot com 2010-06-20 14:01 --- The patch does indeed work, and everything builds as expected once patched. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44531
[Bug debug/44591] FAIL: gcc.dg/guality/pr41404-1.c *foo == 'f'
--- Comment #2 from danglin at gcc dot gnu dot org 2010-06-20 14:42 --- Goes away with gdb head as of 2010-06-19. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44591
[Bug debug/44593] FAIL: gcc.dg/guality/pr43479.c line 13 h == 9
--- Comment #1 from danglin at gcc dot gnu dot org 2010-06-20 14:43 --- Goes away with gdb head as of 2010-06-19. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44593
[Bug debug/44594] FAIL: gcc.dg/guality/vla-1.c
--- Comment #1 from danglin at gcc dot gnu dot org 2010-06-20 14:43 --- Goes away with gdb head as of 2010-06-19. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44594
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
--- Comment #6 from zlogic at gmail dot com 2010-06-20 14:55 --- Any news on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616
[Bug debug/44594] FAIL: gcc.dg/guality/vla-1.c
--- Comment #2 from danglin at gcc dot gnu dot org 2010-06-20 15:10 --- This gdb version is broken and test changed to UNSUPPORTED. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44594
[Bug debug/44593] FAIL: gcc.dg/guality/pr43479.c line 13 h == 9
--- Comment #2 from danglin at gcc dot gnu dot org 2010-06-20 15:10 --- This gdb version is broken and test changed to UNSUPPORTED. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED GCC build triplet|hppa-unknown-linu-gnu |hppa-unknown-linux-gnu GCC host triplet|hppa-unknown-linu-gnu |hppa-unknown-linux-gnu GCC target triplet|hppa-unknown-linu-gnu |hppa-unknown-linux-gnu Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44593
[Bug debug/44591] FAIL: gcc.dg/guality/pr41404-1.c *foo == 'f'
--- Comment #3 from danglin at gcc dot gnu dot org 2010-06-20 15:12 --- This gdb version is broken and test changed to UNSUPPORTED. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED GCC build triplet|hppa-unknown-linu-gnu |hppa-unknown-linux-gnu GCC host triplet|hppa-unknown-linu-gnu |hppa-unknown-linux-gnu GCC target triplet|hppa-unknown-linu-gnu |hppa-unknown-linux-gnu Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44591
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #7 from michael dot a dot richmond at nasa dot gov 2010-06-20 16:14 --- The following occurs in the snapshot of June 19, but not in earlier snapshots: mrich...@msc545ux:~$ cat test.f90 PROGRAM test END FILE 10 END FILE 10 END PROGRAM test mrich...@msc545ux:~$ gfortran test.f90 mrich...@msc545ux:~$ ./a.out At line 3 of file test.f90 (unit = 10, file = 'fort.10') Fortran runtime error: Cannot perform ENDFILE on a file already positioned after the EOF marker -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #8 from kargl at gcc dot gnu dot org 2010-06-20 16:41 --- (In reply to comment #7) The following occurs in the snapshot of June 19, but not in earlier snapshots: mrich...@msc545ux:~$ cat test.f90 PROGRAM test END FILE 10 END FILE 10 END PROGRAM test mrich...@msc545ux:~$ gfortran test.f90 mrich...@msc545ux:~$ ./a.out At line 3 of file test.f90 (unit = 10, file = 'fort.10') Fortran runtime error: Cannot perform ENDFILE on a file already positioned after the EOF marker Did you read the error message? The code is invalid. For the Fortran 95 standard: After execution of an ENDFILE statement, a BACKSPACE or REWIND statement shall be used to reposition the file prior to execution of any data transfer input/output statement or ENDFILE statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #15 from jamborm at gcc dot gnu dot org 2010-06-20 16:50 --- (In reply to comment #14) Let me know how to proceed if you need more dumps. Well, at this point I'd generate all tree dumps with -fdump-tree-all and start looking through them. You can tar-gzip them and attach them here too and then I can have a look too but this really seems it is not a bug in anything I wrote so my potential to help you is very much limited, especially since I cannot reproduce the problem. BTW, should not this bug be updated to a confirmed state? I have not seen the bug, I only trust you something wrong is happening under some circumstances (that I even cannot define). So I definitely cannot confirm it either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #16 from eblot dot ml at gmail dot com 2010-06-20 16:57 --- (In reply to comment #15) ... I cannot reproduce the problem. I can send you either the compiler binaries (hosts: cygwin/linux i386/linux x64/darwin x64) or the configuration options to build the binutils and the compiler for the arm-eabi target, if you want to. I'll attach the requested tree dumps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)
--- Comment #7 from ubizjak at gmail dot com 2010-06-20 16:59 --- Created an attachment (id=20946) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20946action=view) Proposed patch Patch in testing. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #17 from eblot dot ml at gmail dot com 2010-06-20 17:02 --- Created an attachment (id=20947) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20947action=view) File output with -fdump-tree-all option switch Here are the requested tree dumps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #19 from gerald at gcc dot gnu dot org 2010-06-20 17:12 --- Subject: Bug 32843 Author: gerald Date: Sun Jun 20 17:12:11 2010 New Revision: 161048 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161048 Log: Backport from mainline: 2009-09-17 Loren J. Rittle ljrit...@acm.org PR testsuite/32843 (strikes again) src/x86/ffi.c (ffi_prep_cif_machdep): Add X86_FREEBSD to enable proper extension on char and short. Modified: branches/gcc-4_4-branch/libffi/ChangeLog branches/gcc-4_4-branch/libffi/src/x86/ffi.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #10 from pault at gcc dot gnu dot org 2010-06-20 17:45 --- Created an attachment (id=20948) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20948action=view) A patch for the PR I think this correctly takes account of last night's discussion on #gfortran. Bootstraps and regtests OK on FC9/x86_64. Note that I forgot to add a call to abort in myabort. Clearly, I will do that. The present version allowed me to confirm that trunk fails on all the pertinent tests. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #18 from mikpe at it dot uu dot se 2010-06-20 18:26 --- (In reply to comment #5) Unfortunately I don't see this happening on the x86_64-linux - arm-linux-gnueabi cross compiler I built for myself. You need to build a cross to arm-eabi not arm-linux-gnueabi to see the bug. The two ABIs apparently have different data layout rules. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #11 from burnus at gcc dot gnu dot org 2010-06-20 18:31 --- + /* A temporary is not needed if the function is not contained and the + variable local. */ + if (!sym-attr.use_assoc +!sym-attr.in_common +!sym-attr.pointer +!sym-attr.target +expr2-value.function.esym +!expr2-value.function.esym-attr.contained) + return false; Does use_assoc also include host-associated variables - it should for this check. (I have not checked.) Additionally allowed without temporary: sym-attr.dummy sym-attr.intent == INTENT_OUT as If a dummy argument has INTENT (OUT), the actual argument becomes undefined at the time the association is established thus also any access via any method to that variable is undefined - and thus invalid. I think that the LHS is a dummy argument is a very common case and thus it makes sense to optimize for INTENT(OUT). +expr2-value.function.esym +!expr2-value.function.esym-attr.contained) Doesn't this not also unnecessarily prohibit contains subroutine a() dimension :: x(4) x = f() end subroutine function f() as f is contained (in the same namespace as a? Or is this not set for the sym as available in the namespace of a? Otherwise, the patch looks OK. + /* TODO a function that could correctly be declared PURE but is not + could do with returning false as well. */ (Well said, but not easily to be implemented. Actually, that could be a weaker check as pure routines may not do I/O (on file units) or use (ERROR) STOP and the argument INTENT(IN)/VALUE constraints do not matter either.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug fortran/44477] Sequential I/O with END FILE: File position should be at EoF
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-06-20 19:57 --- Michael, is this a legacy code issue? two ENDFILE in a row? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug fortran/44602] New: [F2008] EXIT: Jump to end of construct
Fortran 2003 only had: R844 exit-stmt is EXIT [ do-construct-name ] while Fortran 2008 (FDIS) has: R850 exit-stmt is EXIT [ construct-name ] While with EXIT one only exits the innermost construct, F2008 also allows to exit other constructs; looking at 8.1 one finds the following constructs: - ASSOCIATE - BLOCK - CRITICAL - DO - IF - SELECT CASE - SELECT TYPE of which in CRITICAL and DO CONCURRENT it is invalid to jump to their construct label (or outside the construct) cf. C845. This is already checked for CRITICAL. -- Summary: [F2008] EXIT: Jump to end of construct Product: gcc Version: 4.6.0 Status: UNCONFIRMED 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=44602
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #12 from dominiq at lps dot ens dot fr 2010-06-20 20:10 --- With the patch in comment #10, the modified test for pr31538 from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31538#c5 integer :: a(-4:1), b(0:4) b = 5 ! a(-4:1) = b(0:4) ! Error: different shape for Array ! ! assignment at (1) on dimension 1 (6/5) ! ! gfortran: Array bound mismatch for dimension 1 of array 'f' ! NAG f95: Rank 1 of array operand has extent 5 instead of 2 i = 0 a(i:1) = f(b) contains function f(x) integer :: x(:),f(size(x)) f = x end function end is no longer detected with -fckeck=bounds while the test program main integer, dimension (2) :: x x = (/ 1, 2 /) x = foo () if (sum (x) .ne. 103) call abort contains function foo() integer, dimension (2) :: foo foo (1) = 100 foo (2) = sum (x) end function end program main pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug fortran/44602] [F2008] EXIT: Jump to end of construct
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-20 20:52 ---
See below for a match.c patch. However, it will fail as the labels are not
available. In principle, one just needs to add:
tree exit_label;
/* The exit label. */
exit_label = gfc_build_label_decl (NULL_TREE);
code-block-backend_decl = tree_cons (NULL, exit_label, NULL);
stmt = build1_v (LABEL_EXPR, exit_label);
gfc_add_expr_to_block (if_se.pre, stmt);
to all constructs (in trans-stmt.c) as then trans_exit's
exit_label = TREE_VALUE (code-ext.whichloop-backend_decl);
would work. However, this fails for instance for the IF block as there
code-block is only available if an ELSE branch exists.
Index: match.c
===
--- match.c (Revision 161045)
+++ match.c
@@ -2034,6 +2034,13 @@ match_exit_cycle
gfc_ascii_statement (st));
return MATCH_ERROR;
}
+else if (sym == p-sym)
+ {
+ if (gfc_notify_std (GFC_STD_F2008, Fortran 2008: EXIT with no
+ do-construct-name at %C) == FAILURE)
+ return MATCH_ERROR;
+ break;
+ }
if (p == NULL)
{
@@ -2041,7 +2048,7 @@
gfc_error (%s statement at %C is not within a loop,
gfc_ascii_statement (st));
else
- gfc_error (%s statement at %C is not within loop '%s',
+ gfc_error (%s statement at %C is not within construct '%s',
gfc_ascii_statement (st), sym-name);
return MATCH_ERROR;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44602
[Bug other/32998] -frecord-gcc-switches issues
--- Comment #6 from jsm28 at gcc dot gnu dot org 2010-06-20 21:03 --- Subject: Bug 32998 Author: jsm28 Date: Sun Jun 20 21:02:46 2010 New Revision: 161053 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161053 Log: PR other/32998 * opth-gen.awk: Generate definitions of OPT_SPECIAL_unknown, OPT_SPECIAL_program_name and OPT_SPECIAL_input_file. * opts-common.c (find_opt): Return OPT_SPECIAL_unknown on failure. (decode_cmdline_option): Update for this return value. Set orig_option_with_args_text field. Set arg field for unknown options. Make static. (decode_cmdline_options_to_array): New. (prune_options): Update handling of find_opt return value. * opts.c (read_cmdline_option): Take decoded option. Return void. (read_cmdline_options): Take decoded options. (decode_options): Add parameters for decoded options. Use decode_cmdline_options_to_array. Use decoded options for -O scan. Use integral_argument for -O parameters. Update call to read_cmdline_options. (enable_warning_as_error): Update handling of find_opt return value. * opts.h: Update comment on unknown options. (struct cl_decoded_option): Update comments on opt_index and arg. Add orig_option_with_args_text. (decode_cmdline_option): Remove. (decode_cmdline_options_to_array): Declare. (decode_options): Update prototype. * toplev.c (save_argv): Remove. (save_decoded_options, save_decoded_options_count): New. (read_integral_parameter): Remove. (print_switch_values): Use decoded options. (toplev_main): Don't set save_argv. Update call to decode_options. * toplev.h (read_integral_parameter): Remove. * varasm.c (elf_record_gcc_switches): Don't handle holding back names. c-family: * c-common.c (parse_optimize_options): Update call to decode_options. fortran: * options.c (gfc_handle_option): Don't handle N_OPTS. testsuite: * gcc.dg/opts-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/opts-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/options.c trunk/gcc/opth-gen.awk trunk/gcc/opts-common.c trunk/gcc/opts.c trunk/gcc/opts.h trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c trunk/gcc/toplev.h trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
[Bug other/32998] -frecord-gcc-switches issues
--- Comment #7 from jsm28 at gcc dot gnu dot org 2010-06-20 21:05 --- The -D_GNU_SOURCE a.c issue is now fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
[Bug other/32998] -frecord-gcc-switches issues
--- Comment #8 from manu at gcc dot gnu dot org 2010-06-20 21:20 --- I think this is pretty much confirmed. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-20 21:20:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
--- Comment #7 from manu at gcc dot gnu dot org 2010-06-20 21:25 --- Patches should be sent to gcc-patches. You may CC the libgomp maintainer ja...@redhat.com. See also http://gcc.gnu.org/contribute.html -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616
[Bug c/44598] -Wunused-variable miss 'static const char x[] = ;'
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-20 21:30 --- I think we do not warn on purpose because unused global static const strings are used often for storing version, metadata and stuff that may only be conditionally compiled after preprocessing. I would argue we should not warn for either case then. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org, ||jakub at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-20 21:30:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44598
[Bug middle-end/44600] warnings about possibly uninitialized locals
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-20 21:35 --- I appreciate your effort reporting this but, why should we care about wrong warnings from very very old compilers? And initializing the variables has a cost, because optimizations cannot just assume any value. Otherwise, we could have fixed PR18501 a while ago. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44600
[Bug target/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)
--- Comment #8 from ubizjak at gmail dot com 2010-06-20 21:37 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01973.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||06/msg01973.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug c/44586] gcc does not warn about casting non-variadic types to variadic types
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-20 21:41 --- Joseph, what do you think? Any suggestions where this may be catched? wording? option? I have wished for some time to create a -Wundefined option anyway. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org, ||jsm28 at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44586
[Bug target/44546] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103 with -ffast-math -Os (compiling graphviz)
--- Comment #9 from uros at gcc dot gnu dot org 2010-06-20 21:42 --- Subject: Bug 44546 Author: uros Date: Sun Jun 20 21:42:10 2010 New Revision: 161055 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161055 Log: PR target/44546 * config/i386/predicates.md (ix86_swapped_fp_comparsion_operator): New predicate. * config/i386/i386.md (*fp_jcc_8mode_387): Use ix86_swapped_fp_comparsion_operator instead of ix86_fp_comparison_operator. (*fp_jcc_1_387): Rename from *fp_jcc_3_387. (*fp_jcc_1r_387): Rename from *fp_jcc_4_387. (*fp_jcc_2_387): Rename from *fp_jcc_5_387. (*fp_jcc_2r_387): Rename from *fp_jcc_6_387. (*fp_jcc_3_387): Rename from *fp_jcc_7_387. (*fp_jcc_4_mode_387): Rename from *fp_jcc_8mode_387. testsuite/ChangeLog: PR target/44546 * gcc.target/i386/pr44546.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr44546.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/predicates.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44546
[Bug target/44603] New: out of range branch generated in thumb code.
attached example fails to compile when no -On is used. $ arm-oe-linux-uclibceabi-gcc -mthumb -fPIC a.i -c /tmp/cc1iMNtS.s: Assembler messages: /tmp/cc1iMNtS.s:4814: Error: branch out of range If -O1 or any other -O optlevel is used then it works fine. -- Summary: out of range branch generated in thumb code. Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: x86_64-linux GCC host triplet: x86_64-linux GCC target triplet: arm-oe-linux-uclibceabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603
[Bug target/44603] out of range branch generated in thumb code.
--- Comment #1 from raj dot khem at gmail dot com 2010-06-20 22:01 --- Created an attachment (id=20949) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20949action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603
[Bug c/44586] gcc does not warn about casting non-variadic types to variadic types
--- Comment #2 from joseph at codesourcery dot com 2010-06-20 22:17 --- Subject: Re: gcc does not warn about casting non-variadic types to variadic types It's not the conversion that's undefined, but the call. You could have an option to warn for all function pointer conversions to incompatible function pointer types (but they have reasonable uses as there isn't a generic function pointer type like void *) - or you could have the optimizers detect calls to incompatibly cast types and warn then like the front ends does when the cast appears directly in the call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44586
[Bug target/44531] [4.5/4.6 Regression] [SH] Multilib configuration does not work as expected on darwin
--- Comment #5 from kkojima at gcc dot gnu dot org 2010-06-20 22:23 --- Thanks for the confirmation. I'll apply it when the usual bootstrapregression tests are done on 4.5/4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44531
[Bug c/44586] gcc does not warn about casting non-variadic types to variadic types
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-20 22:25 --- OK. So I would say confirmed, but still I am not sure how I would implement this. So patches welcome. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-20 22:25:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44586
[Bug lto/44248] -fcompare-debug failure with -flto/-fwhopr -g
--- Comment #4 from aoliva at gcc dot gnu dot org 2010-06-20 23:58 --- Subject: Bug 44248 Author: aoliva Date: Sun Jun 20 23:57:54 2010 New Revision: 161056 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161056 Log: PR debug/44248 * lto-streamer-in.c (input_bb): Leave debug stmts alone. (input_function): Drop them here, if VTA is disabled. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44248
[Bug lto/44248] -fcompare-debug failure with -flto/-fwhopr -g
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-06-21 02:58 --- Fixed -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44248
