[Bug rtl-optimization/44194] struct returned by value generates useless stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194 --- Comment #36 from Eric Botcazou 2011-06-22 07:57:28 UTC --- > There is a comment in calls.c that says >/* Handle calls that return values in multiple non-contiguous > locations. > The Irix 6 ABI has examples of this. */ > > I don't know if avoiding the copy breaks that ABI in any way so I didn't try > that approach. In general, if the TARGET is non-NULL, I don't see how the copy > can be avoided (but then, the tree EXPR corresponding to the target hopefully > has the addressable flag set). In this particular case though TARGET is NULL. > Is it just a matter of setting VALREG and let expand_assignment deal with > it? It isn't a matter of avoiding the copy, it is matter of avoiding to spill the copy to memory if possible, i.e. to copy to pseudo registers instead. There may be prerequisites. See comment #22 for a possible approach. > Irrespective of how this case is handled, I think there may be other instances > where a store generated during expansion may be redundant, but we don't know > it > at the point of generation. In such cases, is this approach of associating a > tree expr with the temp rtx generated by the expanded reasonable? Probably, yes, albeit as a last resort solution.
[Bug regression/49500] [4.7 Regression]: gcc.dg/tls/alias-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49500 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/49496] [4.7 Regression] -fcompare-debug failure (length) with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49496 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug tree-optimization/49494] [4.7 Regression] ICE: in remap_predicate at ipa-inline-analysis.c:1876 with -findirect-inlining -finline-small-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49494 Richard Guenther changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.7.0
[Bug tree-optimization/49493] ICE: in insert_vi_for_tree, at tree-ssa-structalias.c:2637 with -O -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49493 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.22 09:17:55 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-06-22 09:17:55 UTC --- Mine.
[Bug bootstrap/49072] Error building the compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49072
--- Comment #7 from Franck Z 2011-06-22
09:21:41 UTC ---
In reply to comment #6)
> > Hope this piece of information is useful. :-)
> Not really, if you don't say which versions of GCC and GMP/MFPR/MPC you're
> using, and your exact configure command, then it's not reproducable or
> verifiable.
My Cygwin is recent (one week old).
I have the same source tree for gcc, gcc/gmp, gcc/mpc and gcc/mpfr as the one
advised here (4.6.0, 4.3.2, 0.9 and 3.0.1).
Along with Cygwin comes:
- libgmp, libgmp3, libgmpxx4 and libgmp-devel 4.3.1-3
- libmpc1 and libmpc-devel 0.8-1
- libmpfr1 and libmpfr-devel 2.4.1-4
I edited /usr/local/include/gmpxx.h to added "choke me" in order to verify if
it's used by gcc's "make" despite gmp's source being in my source tree.
gcc output is in an "objdir" directory separate from my gcc source directory.
Configure script (after a "make distclean" command in "objdir"), with "objdir"
as my present working directory :
/"path to my source"/configure --enable-cx
then:
make
That's the configuration I'm testing now ("make" isn't finished). The first
build failures I refer too were done with pretty much the same configuration,
but for a trunk version of gcc and a one-two months old Cygwin. As I've lost
track of this precise configuration, I'm trying again with the configuration
described above.
> It also seems to be completely unrelated to this bug report, which is about
> segfaults (almost certainly due to faulty hardware) not incorrectly-detected
> system properties during configuration.
I won't fight on this point, ;-).
If my bug shows up again, I'll submit a specific bug report, so as not to
pollute this one.
Thank you.
[Bug debug/49496] [4.7 Regression] -fcompare-debug failure (length) with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49496 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.22 09:24:57 CC||jakub at gcc dot gnu.org Component|tree-optimization |debug AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug debug/49496] [4.7 Regression] -fcompare-debug failure (length) with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49496 --- Comment #1 from Jakub Jelinek 2011-06-22 09:32:08 UTC --- Created attachment 24579 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24579 gcc47-pr49496.patch Untested fix.
[Bug regression/49500] [4.7 Regression]: gcc.dg/tls/alias-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49500 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan 2011-06-22 10:09:39 UTC --- Also on arm-eabi. Ramana
[Bug debug/47858] [4.5/4.6/4.7 Regression] IPA-SRA decreases quality of debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47858 --- Comment #7 from Jakub Jelinek 2011-06-22 10:42:02 UTC --- Author: jakub Date: Wed Jun 22 10:41:58 2011 New Revision: 175288 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175288 Log: PR debug/47858 * gimple.h (enum gimple_debug_subcode): Add GIMPLE_DEBUG_SOURCE_BIND. (gimple_build_debug_source_bind_stat): New prototype. (gimple_build_debug_source_bind): Define. (gimple_debug_source_bind_p, gimple_debug_source_bind_get_var, gimple_debug_source_bind_get_value, gimple_debug_source_bind_get_value_ptr, gimple_debug_source_bind_set_var, gimple_debug_source_bind_set_value): New inlines. * gimple.c (gimple_build_debug_source_bind_stat): New function. * gimple-pretty-print.c (dump_gimple_debug): Handle GIMPLE_DEBUG_SOURCE_BIND. * sese.c (rename_uses): Handle gimple_debug_source_bind_p. * tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Likewise. * tree-parloops.c (eliminate_local_variables, separate_decls_in_region): Likewise. (separate_decls_in_region_debug): Renamed from separate_decls_in_region_debug_bind. Handle gimple_debug_source_bind_p. * tree.h (decl_debug_args_lookup, decl_debug_args_insert): New prototypes. (DECL_HAS_DEBUG_ARGS_P): Define. (struct tree_function_decl): Add has_debug_args_flag field. * tree.c (debug_args_for_decl): New variable. (decl_debug_args_lookup, decl_debug_args_insert): New functions. * tree-into-ssa.c (mark_def_sites): Handle uses in debug stmts. (rewrite_debug_stmt_uses): New function. (rewrite_stmt): Use it to rewrite debug stmt uses. * rtl.def (DEBUG_PARAMETER_REF): New. * rtl.h (DEBUG_PARAMETER_REF_DECL): Define. * cselib.c (rtx_equal_for_cselib_1, cselib_hash_rtx): Handle DEBUG_PARAMETER_REF. * rtl.c (rtx_equal_p_cb, rtx_equal_p, iterative_hash_rtx): Likewise. * print-rtl.c (print_rtx): Likewise. * tree-sra.c (sra_ipa_reset_debug_stmts): Prefer replacing of SSA_NAMEs with DEBUG_EXPR_DECLs initialized in source bind debug stmts in the first bb. * tree-inline.c (remap_ssa_name): If remapping default def of a PARM_DECL fails, map to a DEBUG_EXPR_DECL set in a source bind debug stmt. (remap_gimple_stmt): Handle gimple_debug_source_bind_p. (maybe_move_debug_stmts_to_successors): Likewise. (copy_debug_stmt): Likewise. Avoid shadowing a variable. (tree_function_versioning): If DECL_HAS_DEBUG_ARGS_P, copy debug args vector from old_decl to new_decl. * ipa-prop.c (ipa_modify_call_arguments): For optimized away or modified parameters, add debug bind stmts before call setting DEBUG_EXPR_DECL which is remembered in debug args vector. * cfgexpand.c (expand_call_stmt): Call expand_debug_expr on DECL_DEBUG_EXPRs from debug args vector. (expand_debug_source_expr): New function. (expand_debug_locations): Use it for source bind insns. (expand_gimple_basic_block): Handle gimple_debug_source_bind_p. * var-tracking.c (prepare_call_arguments): Add debug args to call_arguments if any. * dwarf2out.c (dwarf_stack_op_name, size_of_loc_descr, output_loc_operands, output_loc_operands_raw, resolve_addr_in_expr, compare_loc_operands): Handle DW_OP_GNU_parameter_ref. (get_ref_die_offset, parameter_ref_descriptor): New functions. (mem_loc_descriptor): Handle DEBUG_PARAMETER_REF. (gen_subprogram_die): Handle parameters identified by DEBUG_PARAMETER_REF. * dwarf2.h (enum dwarf_location_atom): Add DW_OP_GNU_parameter_ref. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/cselib.c trunk/gcc/dwarf2out.c trunk/gcc/gimple-pretty-print.c trunk/gcc/gimple.c trunk/gcc/gimple.h trunk/gcc/ipa-prop.c trunk/gcc/print-rtl.c trunk/gcc/rtl.c trunk/gcc/rtl.def trunk/gcc/rtl.h trunk/gcc/sese.c trunk/gcc/tree-inline.c trunk/gcc/tree-into-ssa.c trunk/gcc/tree-parloops.c trunk/gcc/tree-sra.c trunk/gcc/tree-ssa-dce.c trunk/gcc/tree.c trunk/gcc/tree.h trunk/gcc/var-tracking.c trunk/include/ChangeLog trunk/include/dwarf2.h
[Bug bootstrap/49072] Error building the compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49072 --- Comment #8 from Franck Z 2011-06-22 11:07:52 UTC --- (In reply to comment #7) Failure. But with a tag passed to libtool. My Cygwin version of libtool is 2.4-1. Took place in objdir/gmp/mpn. With the command: /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I/cygdrive/c/gcc-4.6.0/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I/cygdrive/c/gcc-4.6.0/gmp -DOPERATION_`echo fib_table | sed 's/_$//'` -DNO_ASM -g -fkeep-inline-functions -c -o fib_table.lo fib_table.c messages sent: libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' backtraces from "make"s rewinding from /home/Défaut/objdir/gmp/mpn (make[5]) to /home/Défaut/objdir (make): [fib_table.lo] Error 1 (in mpn) [all-recursive] Error 1 (in gmp) [all] Error 2 (in gmp) [all-stage1-gmp] Error 2 (in objdir) [stage1-bubble] Error 2 (in objdir) [all] Error 2 Should I file in a new bug for this one with is different?
[Bug bootstrap/49072] Error building the compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49072 Jonathan Wakely changed: What|Removed |Added Severity|critical|normal --- Comment #9 from Jonathan Wakely 2011-06-22 11:19:32 UTC --- (In reply to comment #8) > Should I file in a new bug for this one with is different? Yes please, it's completely unrelated. Please provide all the information requested at http://gcc.gnu.org/bugs/
[Bug bootstrap/49502] New: Unable to build gcc with gmp/mpc/mpfr in its tree and flag "--enable-cxx"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49502 Summary: Unable to build gcc with gmp/mpc/mpfr in its tree and flag "--enable-cxx" Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: franck.z.bugzi...@orange.fr *** the exact version of GCC; configure:4184: gcc --version >&5 gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) *** the system type; uname -m = i686 uname -r = 1.7.9(0.237/5/3) uname -s = CYGWIN_NT-5.1 uname -v = 2011-03-29 10:10 My Cygwin is recent (one week old). My Cygwin version of libtool is 2.4-1. It was run on a Dual Core, Windows XP SP 3, with Cygwin environment. *** the options given when GCC was configured/built; $ /cygdrive/c/gcc-4.6.0/configure --enable-cxx *** the complete command line that triggers the bug; $ make more precisely: It's a failure with a tag passed to libtool. Took place in objdir/gmp/mpn. With the command: /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I/cygdrive/c/gcc-4.6.0/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I/cygdrive/c/gcc-4.6.0/gmp -DOPERATION_`echo fib_table | sed 's/_$//'` -DNO_ASM -g -fkeep-inline-functions -c -o fib_table.lo fib_table.c *** the compiler output (error messages, warnings, etc.); and messages sent: libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' backtraces from "make"s rewinding from /home/Défaut/objdir/gmp/mpn (make[5]) to /home/Défaut/objdir (make): [fib_table.lo] Error 1 (in mpn) [all-recursive] Error 1 (in gmp) [all] Error 2 (in gmp) [all-stage1-gmp] Error 2 (in objdir) [stage1-bubble] Error 2 (in objdir) [all] Error 2 *** the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command, or, in the case of a bug report for the GNAT front end, a complete set of source files (see below). not relevant (?) it's an issue with how the "libtool" utility was generated by gmp's "configure" script with the parameters it got from gcc's makefile. Namely, as found in gmp/config.log : $ /cygdrive/c/gcc-4.6.0/gmp/configure --cache-file=./config.cache --enable-cxx --enable-languages=c,c++,fortran,java,lto,objc --program-transform-name=s,y,y, --disable-option-checking --build=i686-pc-cygwin --host=none-pc-cygwin --target=none-pc-cygwin --srcdir=/cygdrive/c/gcc-4.6.0/gmp --disable-intermodule --enable-checking=yes,types --disable-coverage --enable-languages=c,lto --disable-shared *** Extra-precision about the source compiled. I have the same source tree for gcc, gcc/gmp, gcc/mpc and gcc/mpfr as the one advised in the pre-requisite web page at gcc.gnu.org (4.6.0, 4.3.2, 0.9 and 3.0.1). (see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49072 , for history, but all the information for reproduceability has been reproduced here.) gcc output is in an "objdir" directory separate from my gcc source directory. As far as I can remember from my various attempts, a configure command with --enable-cxx flag when I built gmp separately from gcc worked. I'll try it again if you wish so as to make sure it's not a gmp issue.
[Bug bootstrap/49502] Unable to build gcc with gmp/mpc/mpfr in its tree and flag "--enable-cxx"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49502 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.06.22 13:30:04 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-06-22 13:30:04 UTC --- Why do you use --enable-cxx and what do you think it does? Please do not use it.
[Bug target/49422] [arm] unable to find a register to spill in class 'VFP_LO_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49422 philb at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from philb at gnu dot org 2011-06-22 13:46:51 UTC --- I can't reproduce it now either. I think I must have been testing against a locally patched tree rather than the clean one by mistake. I'll close this bug until/unless I can reproduce the failure on a released version.
[Bug regression/49500] [4.7 Regression]: gcc.dg/tls/alias-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49500 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.22 14:04:32 CC||danglin at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from John David Anglin 2011-06-22 14:04:32 UTC --- Also on hppa*-*-hpux*.
[Bug tree-optimization/49365] 436.cactusADM performance regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49365 Richard Guenther changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #6 from Richard Guenther 2011-06-22 14:13:14 UTC --- I have posted a patch.
[Bug rtl-optimization/49429] [4.7 Regression] dse.c change (r175063) causes execution failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49429 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.22 14:19:56 CC||ebotcazou at gcc dot ||gnu.org Summary|[4.7 Regression] dse.c |[4.7 Regression] dse.c |changes to fix PR44194 |change (r175063) causes |(r175063) cause execution |execution failures |failures| Ever Confirmed|0 |1 --- Comment #15 from Eric Botcazou 2011-06-22 14:19:56 UTC --- > Unfortunately, this patch does not seem to fix PR 49454, the PA bootstrap > failure, which also broke at the same time. Perhaps there are some other > places where mark_addressable needs to be called? See http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01672.html for an analysis.
[Bug target/49454] [4.7 Regression] /usr/include/libio.h:336:3: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49454 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug libgomp/49490] suboptimal load balancing in loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49490 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.22 14:41:35 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek 2011-06-22 14:41:35 UTC --- Created attachment 24580 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24580 gcc47-pr49490.patch Untested fix.
[Bug middle-end/41378] -fipa-pta -O3 leads to ICE : in insert_vi_for_tree, at tree-ssa-structalias.c:2601
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41378 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #3 from Richard Guenther 2011-06-22 14:58:41 UTC --- I can't reproduce this anymore.
[Bug target/48308] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308 Michael K. Edwards changed: What|Removed |Added CC||m.k.edwards at gmail dot ||com --- Comment #7 from Michael K. Edwards 2011-06-22 15:14:06 UTC --- I hit this with Linaro GCC 4.6 (4.6.1-based) and the same pkeyparam.c from OpenSSL. I am also compiling with -Os and -fPIC, and implicitly with -mthumb (the default in my toolchain); so it's not specific to ARM mode. The situation appears to be that two pc-relative fetches (artifacts of -fPIC and string literals) get folded together, losing one of the labels (needed for calculation of the offset in the table of PIC indirections). Reverting http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163998 makes the problem go away, at least at compile time; I should be able to run a test suite soon.
[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0
[Bug testsuite/49503] New: Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503 Summary: Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: michael.v.zolotuk...@gmail.com CC: michael.v.zolotuk...@gmail.com Host: x64 Target: x64 Build: 4.7.0 20110619 The tests contain asm-listing like this: __asm ( testl %0, %0 jnz1f .subsection 1 .type _L_mutex_lock_%=, @function _L_mutex_lock_%=: 1:leaq %1, %%rdi 2:subq $128, %%rsp 3:call bar 4:addq $128, %%rsp 5:jmp21f ... As _L_mutex_lock is a function, GCC generates a prologue and epilogue for it - in prologue stack alignment is performed (according to ABI64, stack should be aligned to 128-bit). Before a call, SP is assumed to be a multiple of 16, at function entry, when return address is pushed to stack, (SP+8) becomes multiple of 16 - GCC uses these assumptions when generating prologue for stack alignment. But if JUMP is used instead of CALL, 8-byte displacement doesn't take place, and stack becomes unaligned - that's violation of ABI. To fix this error, JUMP should be replaced with CALL, or L_mutex_lock shouldn't be declared as a function.
[Bug target/49497] Incorrect lea peephole
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49497 --- Comment #3 from hjl at gcc dot gnu.org 2011-06-22 15:29:48 UTC --- Author: hjl Date: Wed Jun 22 15:29:43 2011 New Revision: 175295 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175295 Log: Check TARGET_PARTIAL_REG_STALL in imul to lea peepholes. 2011-06-22 H.J. Lu PR target/49497 * config/i386/i386.md (*lea_general_2): Always allow SImode. (*lea_general_2_zext): Likewise. (imul to lea peepholes): Use const359_operand and check TARGET_PARTIAL_REG_STALL. * config/i386/predicates.md (const359_operand): New. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/predicates.md
[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260 --- Comment #7 from Jason Merrill 2011-06-22 15:55:25 UTC --- Author: jason Date: Wed Jun 22 15:55:22 2011 New Revision: 175296 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175296 Log: PR c++/49260 * call.c (build_call_a): Set cp_function_chain->can_throw here. (build_cxx_call): Not here. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-eh2.C
[Bug c++/49260] cpp0x/lambda/lambda-eh2.C fails execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49260 --- Comment #8 from Jason Merrill 2011-06-22 15:55:59 UTC --- Should be fixed on trunk now.
[Bug c++/22596] Impossible to explicitly instantiate particular overloaded function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22596 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #8 from Jason Merrill 2011-06-22 16:07:24 UTC --- The example at the bottom of DR 214 seems related, but not quite the same: http://www.open-std.org/JTC1/SC22/WG21/docs/cwg_defects.html#214
[Bug target/48126] arm_output_sync_loop: misplaced memory barrier, missing clrex / dummy strex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126 Dr. David Alan Gilbert changed: What|Removed |Added CC||david.gilbert at linaro dot ||org --- Comment #5 from Dr. David Alan Gilbert 2011-06-22 16:40:07 UTC --- Michael: I think I agree with you on the need for the barrier in the branch out case; gcc's info page (section 6.49 'Built-in functions for atomic memory access') state: - In most cases, these builtins are considered a "full barrier". That is, no memory operand will be moved across the operation, either forward or backward. Further, instructions will be issued as necessary to prevent the processor from speculating loads across the operation and from queuing stores after the operation. -- so it does look like that last barrier would be needed to stop a subsequent load floating backwards before the ldrex. If I understand correctly however most cases wouldn't need it - I think most cases are use the compare&swap to take some form of lock, and then once you know you have the lock go and do your accesses - and in that case the ordering is guaranteed, where as if you couldn't take the lock you wouldn't use the subsequent access anyway. Dave
[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.06.22 16:48:48 Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu 2011-06-22 16:48:48 UTC --- (In reply to comment #0) > > As _L_mutex_lock is a function, GCC generates a prologue and epilogue for it - > in prologue stack alignment is performed (according to ABI64, stack should be > aligned to 128-bit). I didn't see any prologue and epilogue for _L_mutex_lock. Do you have a run-time testcase to show the problem?
[Bug middle-end/49504] New: Invalid optimization for Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49504
Summary: Invalid optimization for Pmode != ptr_mode
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
On x32 branch, I got
[hjl@gnu-33 tmp]$ cat x32.c
unsigned long long t(const void* p, unsigned long long q) {
unsigned long long a = (((unsigned long long) ((unsigned long) p)) + q) >>
32;
return a;
}
[hjl@gnu-33 tmp]$ /usr/gcc-4.7.0-x32/bin/gcc -O2 -mx32 -S x32.c
[hjl@gnu-33 tmp]$ cat x32.s
.file"x32.c"
.text
.p2align 4,,15
.globlt
.typet, @function
t:
.LFB0:
.cfi_startproc
xorl%eax, %eax
ret
.cfi_endproc
.LFE0:
.sizet, .-t
.ident"GCC: (GNU) 4.7.0 20110616 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-33 tmp]$
From
http://code.google.com/p/nativeclient/issues/detail?id=1601
What it does is that when pointers from memory (ptr_mode) are zero extended
when getting into registers (Pmode)(POINTERS_EXTEND_UNSIGNED > 0), and there is
a Pmode PLUS or MINUS of a register that holds a pointer value with some other
register, all bits above ptr_mode are considered zero.
Here is the test that demonstrates the bug clearly (compile with -O2):
unsigned long long t(const void* p, unsigned long long q) {
unsigned long long a = (((unsigned long long)p) + q) >> 32;
return a;
}
In our z86_64 compiler, p is 32-bit. It gets zero-extended to 64-bit long long
for addition with q, but the fact that it was originally a pointer is
preserved. Thus, nonzero_bits1 thinks the result of addition always has high
32-bits equal to zero, so the result of the right shift is always zero.
The test gets optimized to "return 0;".
[Bug regression/49498] [4.7 Regression]: gcc.dg/uninit-pred-8_b.c bogus warning line 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.06.22 17:27:37
CC||law at redhat dot com
Ever Confirmed|0 |1
--- Comment #2 from Jeffrey A. Law 2011-06-22 17:27:37
UTC ---
It looks like the uninit code is being confused by elimination of a test in one
path.
int foo (int n, int l, int m, int r)
{
int v;
if (n < 10 || m > 100 || r < 20 || l)
v = r;
if (m) g++;
else bar();
if ( n < 10 || m > 100 || r < 20 )
blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */
return 0;
}
We end up copying the n < 10 test from the 3rd conditional into the m == 0 path
of the second conditional and threading the false path from the copied
conditional to the r < 20 test (ie, we bypass the m > 100 test as it always
false on that path where m == 0.
This appears to confuse the predicate analysis in tree-ssa-uninit.c. I'm still
trying to wrap my head around its implementation to see if there's a reasonable
way to solve this.
[Bug c++/22596] Impossible to explicitly instantiate particular overloaded function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22596 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #9 from Jason Merrill 2011-06-22 17:35:09 UTC --- This is not a bug; under the partial ordering rules, the second foo is more specialized than the first, so if both are possible matches the second will be chosen. If you want the explicit instantiation to match the same function that's called with no explicit template arguments, then don't provide explicit template arguments in the explicit instantiation. If you just write template int foo(A_class a); or template int foo<>(A_class a); it will do what you want.
[Bug fortran/49501] support ATTRIBUTES ALIGN in gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49501 --- Comment #1 from stevenj at alum dot mit.edu 2011-06-22 17:38:25 UTC --- Actually, it looks like there is a way to allocate aligned memory, albeit a bit ugly, thanks to Fortran 2003's C interoperability. Declare a bind(C) interface to e.g. posix_memalign, and then use C_F_POINTER intrinsic to convert this into a pointer to a Fortran array.
[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503 --- Comment #2 from Michael Zolotukhin 2011-06-22 17:50:34 UTC --- (In reply to comment #1) > (In reply to comment #0) > > > > As _L_mutex_lock is a function, GCC generates a prologue and epilogue for > > it - > > in prologue stack alignment is performed (according to ABI64, stack should > > be > > aligned to 128-bit). > > I didn't see any prologue and epilogue for _L_mutex_lock. Do you have > a run-time testcase to show the problem? I don't have run-time test for this fail, but here is a way to see the problem: Firstly, you need to compile the test (it is in gcc/testsuite/gcc.target/i386): gcc cleanup-1.c -fexceptions -fnon-call-exceptions -fasynchronous-unwind-tables -O0 -lm -g -fno-inline Then, in debugger one can see that before each callq before foo (here 'before' means 'upper in call stack') RSP contains aligned value, after foo (deeper in call stack) - unaligned. Here is corresponding a assembler dump: -Dump of assembler code for function foo: 0x00400886 <+0>: push %rbp 0x00400887 <+1>: mov%rsp,%rbp 0x0040088a <+4>: push %r12 0x0040088c <+6>: push %rbx 0x0040088d <+7>: sub$0x98,%rsp # It is the prologue, 0x00400894 <+14>:mov%edi,-0x114(%rbp) # that I've spoken 0x0040089a <+20>:mov-0x114(%rbp),%ebx # about. 0x004008a0 <+26>:lea-0x110(%rbp),%r12 # 0x004008a7 <+33>:test %ebx,%ebx 0x004008a9 <+35>:jne0x400941 <_L_mutex_lock_216> 0x004008af <+41>:add$0x98,%rsp 0x004008b6 <+48>:pop%rbx 0x004008b7 <+49>:pop%r12 0x004008b9 <+51>:leaveq 0x004008ba <+52>:retq -End of assembler dump. RTL dumps showed that these instructions appear phase "197r.pro_and_epilogue". I'm not sure, if prologue generation is incorrect - in my opinion the problem is with such untrivial call of _L_mutex_lock.
[Bug libgcj/49451] FileHandleGcTest FAILS on IRIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49451 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-06/msg01687.htm ||l Last reconfirmed||2011.06.22 17:54:50 AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Rainer Orth 2011-06-22 17:54:50 UTC --- Mine, patch posted.
[Bug tree-optimization/49493] ICE: in insert_vi_for_tree, at tree-ssa-structalias.c:2637 with -O -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49493 --- Comment #2 from Richard Guenther 2011-06-22 18:02:09 UTC --- Author: rguenth Date: Wed Jun 22 18:02:06 2011 New Revision: 175300 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175300 Log: 2011-06-22 Richard Guenther PR tree-optimization/49493 * tree-ssa-structalias.c (get_constraint_for_ssa_var): Refer to the alias target of variables. (associate_varinfo_to_alias_1): Remove. (ipa_pta_execute): Do not associate aliases with anything. * cgraph.h (varpool_alias_aliased_node): Fix cut&paste errors. (cgraph_function_node): Likewise. (cgraph_function_or_thunk_node): Likewise. (varpool_variable_node): Likewise. * gcc.dg/ipa/ipa-pta-17.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/ipa/ipa-pta-17.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c
[Bug tree-optimization/49493] ICE: in insert_vi_for_tree, at tree-ssa-structalias.c:2637 with -O -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49493 Richard Guenther changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.7.0 Resolution||FIXED Target Milestone|--- |4.7.0 Known to fail|4.7.0 | --- Comment #3 from Richard Guenther 2011-06-22 18:03:38 UTC --- Fixed for trunk.
[Bug middle-end/49504] Invalid optimization for Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49504 H.J. Lu changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #1 from H.J. Lu 2011-06-22 18:11:33 UTC --- Another combine bug.
[Bug testsuite/49503] Incorrect stack alignment, produced by inline assembler in tests gcc.target/i386/cleanup-1.c and gcc.target/i386/cleanup-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49503 --- Comment #3 from H.J. Lu 2011-06-22 18:34:32 UTC --- (In reply to comment #2) > (In reply to comment #1) > > (In reply to comment #0) > > > > > > As _L_mutex_lock is a function, GCC generates a prologue and epilogue for > > > it - > > > in prologue stack alignment is performed (according to ABI64, stack > > > should be > > > aligned to 128-bit). > > > > I didn't see any prologue and epilogue for _L_mutex_lock. Do you have > > a run-time testcase to show the problem? > > I don't have run-time test for this fail, but here is a way to see the > problem: > It is very easy to check if stack alignment is correct at run-time. Please see how it is done in testcases under gcc.dg/torture/stackalign.
[Bug c++/36435] Partial ordering of explicit specialization should include return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36435 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.22 18:40:23 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug target/48126] arm_output_sync_loop: misplaced memory barrier, missing clrex / dummy strex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48126 --- Comment #6 from Michael K. Edwards 2011-06-22 19:00:54 UTC --- (In reply to comment #5) > If I understand correctly however most cases wouldn't need it - I think most > cases are use the compare&swap to take some form of lock, and then once you > know you have the lock go and do your accesses - and in that case the ordering > is guaranteed, where as if you couldn't take the lock you wouldn't use the > subsequent access anyway. Yes, that fits my understanding. It's only when you actually use the compare-and-swap as a compare-and-swap that you can get bit. I expect that it is quite hard to hit this in the 32-bit case, but with your 64-bit atomics and a dual-core system it should be a little easier to expose. I have an implementation of Michael-Scott lock-free queues (which rely on applying DCAS to a counter+pointer), in which I currently use the assembly cmpxchg64 equivalent we discussed; I'll adapt it to use the GCC intrinsic and re-test.
[Bug fortran/49416] wrong -fbounds-check with 2 dimensional arrays reshape
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49416 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Thomas Koenig 2011-06-22 19:43:01 UTC --- I don't think we will backport the fix (if we can find it easily) to 4.4; that is now essentially unmaintained. Advice would be to upgrade to 4.5 or 4.6.1 (about to be released). Closing.
[Bug rtl-optimization/49504] Invalid optimization for Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49504 H.J. Lu changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-06/msg01704.htm ||l Component|middle-end |rtl-optimization --- Comment #2 from H.J. Lu 2011-06-22 19:44:09 UTC --- The patch is posted at http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01704.html
[Bug rtl-optimization/49504] Invalid optimization for Pmode != ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49504 --- Comment #3 from hjl at gcc dot gnu.org 2011-06-22 19:59:59 UTC --- Author: hjl Date: Wed Jun 22 19:59:52 2011 New Revision: 175306 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175306 Log: Properly handle pointer addition/subtraction. gcc/ 2011-06-22 H.J. Lu PR rtl-optimization/49504 * rtlanal.c (nonzero_bits1): Properly handle addition or subtraction a pointer in Pmode if pointers extend unsigned. gcc/testsuite/ 2011-06-22 H.J. Lu PR rtl-optimization/49504 * gcc.target/i386/pr49504.c: New. Added: branches/x32/gcc/testsuite/gcc.target/i386/pr49504.c Modified: branches/x32/gcc/ChangeLog.x32 branches/x32/gcc/rtlanal.c branches/x32/gcc/testsuite/ChangeLog.x32
[Bug c++/35255] [DR 115] gcc does not do partial ordering on overloaded address resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35255 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Summary|gcc does not do partial |[DR 115] gcc does not do |ordering on overloaded |partial ordering on |address resolution |overloaded address ||resolution --- Comment #1 from Jason Merrill 2011-06-22 20:06:40 UTC --- This is DR 115. 14.8.1 says, In contexts where deduction is done and fails, or in contexts where deduction is not done, if a template argument list is specified and it, along with any default template arguments, identifies a single function template specialization, then the template-id is an lvalue for the function template specialization.
[Bug c++/49505] New: [DR 214] wrong partial ordering for explicit instantiation with unused template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49505
Summary: [DR 214] wrong partial ordering for explicit
instantiation with unused template parameter
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
template T f(int) { return T(); }
template T f(V);
template int f (int);
Here, the first f is more specialized than the second. G++ currently rejects
this testcase as ambiguous because of the unused template parameter U, but
since DR 214 14.8.2.4 says,
In most cases, all template parameters must have values in order for deduction
to succeed, but for partial ordering purposes a template parameter may remain
without a value provided it is not used in the types being used for partial
ordering.
clang and EDG get this right.
I noticed this issue while looking at bug 22596.
[Bug c++/49505] [DR 214] wrong partial ordering for explicit instantiation with unused template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49505 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.22 20:17:31 Ever Confirmed|0 |1
[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836 --- Comment #13 from Hans-Peter Nilsson 2011-06-22 20:17:55 UTC --- Author: hp Date: Wed Jun 22 20:17:47 2011 New Revision: 175307 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175307 Log: PR regression/47836 PR bootstrap/23656 PR other/47733 PR bootstrap/49247 * configure.ac (target_libraries): Remove target-libiberty. Remove case-statement setting skipdirs=target-libiberty for multiple targets. Remove checking target_configdirs and removing target-libiberty but keeping target-libgcc if otherwise empty. * Makefile.def (target_modules): Don't add libiberty. (dependencies): Remove all traces of target-libiberty. * configure, Makefile.in: Regenerate. (fixing PR annotations in the ChangeLog entry) Modified: trunk/ChangeLog
[Bug bootstrap/23656] Cross-compilation with newlib fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23656 --- Comment #2 from Hans-Peter Nilsson 2011-06-22 20:17:58 UTC --- Author: hp Date: Wed Jun 22 20:17:47 2011 New Revision: 175307 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175307 Log: PR regression/47836 PR bootstrap/23656 PR other/47733 PR bootstrap/49247 * configure.ac (target_libraries): Remove target-libiberty. Remove case-statement setting skipdirs=target-libiberty for multiple targets. Remove checking target_configdirs and removing target-libiberty but keeping target-libgcc if otherwise empty. * Makefile.def (target_modules): Don't add libiberty. (dependencies): Remove all traces of target-libiberty. * configure, Makefile.in: Regenerate. (fixing PR annotations in the ChangeLog entry) Modified: trunk/ChangeLog
[Bug bootstrap/49247] libiberty configure assumes newlib does not supply psignal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49247 --- Comment #1 from Hans-Peter Nilsson 2011-06-22 20:17:58 UTC --- Author: hp Date: Wed Jun 22 20:17:47 2011 New Revision: 175307 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175307 Log: PR regression/47836 PR bootstrap/23656 PR other/47733 PR bootstrap/49247 * configure.ac (target_libraries): Remove target-libiberty. Remove case-statement setting skipdirs=target-libiberty for multiple targets. Remove checking target_configdirs and removing target-libiberty but keeping target-libgcc if otherwise empty. * Makefile.def (target_modules): Don't add libiberty. (dependencies): Remove all traces of target-libiberty. * configure, Makefile.in: Regenerate. (fixing PR annotations in the ChangeLog entry) Modified: trunk/ChangeLog
[Bug other/47733] psignal (int, const? char*) in libiberty/strsignal.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47733 --- Comment #2 from Hans-Peter Nilsson 2011-06-22 20:18:00 UTC --- Author: hp Date: Wed Jun 22 20:17:47 2011 New Revision: 175307 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175307 Log: PR regression/47836 PR bootstrap/23656 PR other/47733 PR bootstrap/49247 * configure.ac (target_libraries): Remove target-libiberty. Remove case-statement setting skipdirs=target-libiberty for multiple targets. Remove checking target_configdirs and removing target-libiberty but keeping target-libgcc if otherwise empty. * Makefile.def (target_modules): Don't add libiberty. (dependencies): Remove all traces of target-libiberty. * configure, Makefile.in: Regenerate. (fixing PR annotations in the ChangeLog entry) Modified: trunk/ChangeLog
[Bug libstdc++/49506] New: reusing a file stream object will always get eof after openning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49506 Summary: reusing a file stream object will always get eof after openning Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: gz...@hotmail.com Created attachment 24581 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24581 test programe to reproduce the file stream open-eof bug It seems that if I reuse a std::ifstream object by "open(another_file)" it will always return EOF right away. See the attached file for details. I had confirmed this can be reproduced with gcc 3.3.3 but NOT in gcc 4.3.3. (Not sure which exact version fixed the problem -- I had searched the similar bug description but could not find one ). In a good case, the test program should return 0 silently. In a bad case, the test program print out "eof" and some of the bits of the stream state and return 1;
[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602 ak at gcc dot gnu.org changed: What|Removed |Added CC||ak at gcc dot gnu.org, ||mjambor at suse dot cz --- Comment #3 from ak at gcc dot gnu.org 2011-06-22 20:30:56 UTC --- I ran into a similar problem in my code. It would be nice if memset didn't break SRA.
[Bug target/46278] avr-gcc 4.5.1 doing suboptimal reloads using X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46278 --- Comment #3 from Georg-Johann Lay 2011-06-22 20:35:30 UTC --- Created attachment 24582 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24582 snake.c Yet another source file to test. Compile with, e.g. -Os -mmcu=atmega128 -std=gnu99 Compiled with avr-gcc 4.6.1 (prerelease SVN 175201) is shows size ca. 15% more compared to avr-gcc 3.4.6.
[Bug c++/49395] Non-class prvalues seem to have cv-qualification with GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49395 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.22 20:36:09 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jason Merrill 2011-06-22 20:36:09 UTC --- I think line 10 is definitely a bug, line 8 may be a standards issue; I notice that EDG also complains about that line. Since A().i is a subobject of a class prvalue, we might want to treat it differently from a normal int prvalue.
[Bug debug/49496] [4.7 Regression] -fcompare-debug failure (length) with -O -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49496 --- Comment #2 from Jakub Jelinek 2011-06-22 20:37:58 UTC --- Author: jakub Date: Wed Jun 22 20:37:54 2011 New Revision: 175314 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175314 Log: PR debug/49496 * tree-vect-patterns.c (vect_recog_widen_mult_pattern): Ignore debug uses. * gcc.dg/pr49496.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr49496.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug libgomp/49490] suboptimal load balancing in loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49490 --- Comment #2 from Jakub Jelinek 2011-06-22 20:39:27 UTC --- Author: jakub Date: Wed Jun 22 20:39:25 2011 New Revision: 175315 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175315 Log: PR libgomp/49490 * omp-low.c (expand_omp_for_static_nochunk): Only use n ceil/ nthreads size for the first n % nthreads threads in the team instead of all threads except for the last few ones which get less work or none at all. * iter.c (gomp_iter_static_next): For chunk size 0 only use n ceil/ nthreads size for the first n % nthreads threads in the team instead of all threads except for the last few ones which get less work or none at all. * iter_ull.c (gomp_iter_ull_static_next): Likewise. * env.c (parse_schedule): If OMP_SCHEDULE doesn't have chunk argument, set run_sched_modifier to 0 for static resp. 1 for other kinds. If chunk argument is 0 and not static, set value to 1. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/libgomp/ChangeLog trunk/libgomp/env.c trunk/libgomp/iter.c trunk/libgomp/iter_ull.c
[Bug libstdc++/49506] reusing a file stream object will always get eof after openning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49506 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.3 --- Comment #1 from Andrew Pinski 2011-06-22 20:42:02 UTC --- >I had confirmed this can be reproduced with gcc 3.3.3 but NOT in gcc 4.3.3. Well 3.3.3 is old and no longer supported. So this has been fixed already
[Bug c++/49470] optional diagnostic not given for invalid mem-initializer in uninstantiated template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49470 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.06.22 20:44:17 Summary|no matching constructor for |optional diagnostic not |initialization errors not |given for invalid |detected in g++ |mem-initializer in ||uninstantiated template Ever Confirmed|0 |1
[Bug c++/49440] [4.5/4.6/4.7 regression] Invalid dynamic_cast for unnamed namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49440 Jason Merrill changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.06.22 21:00:47 CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Summary|Invalid dynamic_cast for|[4.5/4.6/4.7 regression] |unnamed namespace |Invalid dynamic_cast for ||unnamed namespace Ever Confirmed|0 |1 --- Comment #3 from Jason Merrill 2011-06-22 21:00:47 UTC --- This is related to the change to use string comparison for matching type_infos. We have a special case for file-local symbols, but aren't using it here for some reason. http://gcc.gnu.org/ml/gcc/2009-08/msg00258.html
[Bug c++/49507] New: ICE because of defaulted template destructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49507
Summary: ICE because of defaulted template destructor
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@s-e-f-i.de
The following code makes rc1 of gcc-4.6.1 segfault:
template
struct ConcretePoolKey
{
virtual ~ConcretePoolKey();
};
template
ConcretePoolKey::~ConcretePoolKey() = default;
int main()
{
ConcretePoolKey foo;
}
/usr/bin/g++ -std=c++0x test.cpp
test.cpp: In destructor 'ConcretePoolKey::~ConcretePoolKey() [with T =
int]':
test.cpp:13:1: instantiated from here
test.cpp:2:8: internal compiler error: Segmentation fault
[Bug c++/49508] New: [4.7 Regression] Bogus "control reaches end of non-void function" warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49508
Summary: [4.7 Regression] Bogus "control reaches end of
non-void function" warning
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: paolo.carl...@oracle.com
In mainline, I see this, apparently bogus, warning which is not emitted by 4.6
(or ICC for that matter). Testcase distilled from 20_util/forward/1_neg.cc in
the v3 testsuite, compile with -Wreturn-type:
template
struct shared_ptr
{
};
template
shared_ptr
factory(const A1&, const A2&)
{
return shared_ptr(new T());
}
struct A
{
A(int&, int&);
};
void g()
{
factory(1, 2);
}
[Bug other/47733] psignal (int, const? char*) in libiberty/strsignal.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47733 --- Comment #3 from Hans-Peter Nilsson 2011-06-22 21:30:25 UTC --- Author: hp Date: Wed Jun 22 21:30:19 2011 New Revision: 175316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175316 Log: PR regression/47836 PR bootstrap/23656 PR other/47733 PR bootstrap/49247 PR c/48825 * configure.ac (target_libraries): Remove target-libiberty. Remove case-statement setting skipdirs=target-libiberty for multiple targets. Remove checking target_configdirs and removing target-libiberty but keeping target-libgcc if otherwise empty. * Makefile.def (target_modules): Don't add libiberty. (dependencies): Remove all traces of target-libiberty. * configure, Makefile.in: Regenerate. (add missing PR annotation in the ChangeLog entry) Modified: trunk/ChangeLog
[Bug c/48825] libiberty "psignal" lacks const modifier, failing to compile when HAVE_PSIGNAL is undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48825 --- Comment #7 from Hans-Peter Nilsson 2011-06-22 21:30:25 UTC --- Author: hp Date: Wed Jun 22 21:30:19 2011 New Revision: 175316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175316 Log: PR regression/47836 PR bootstrap/23656 PR other/47733 PR bootstrap/49247 PR c/48825 * configure.ac (target_libraries): Remove target-libiberty. Remove case-statement setting skipdirs=target-libiberty for multiple targets. Remove checking target_configdirs and removing target-libiberty but keeping target-libgcc if otherwise empty. * Makefile.def (target_modules): Don't add libiberty. (dependencies): Remove all traces of target-libiberty. * configure, Makefile.in: Regenerate. (add missing PR annotation in the ChangeLog entry) Modified: trunk/ChangeLog
[Bug regression/47836] Some Cross Compiler can't build target-libiberty or target-zlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836 --- Comment #14 from Hans-Peter Nilsson 2011-06-22 21:30:24 UTC --- Author: hp Date: Wed Jun 22 21:30:19 2011 New Revision: 175316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175316 Log: PR regression/47836 PR bootstrap/23656 PR other/47733 PR bootstrap/49247 PR c/48825 * configure.ac (target_libraries): Remove target-libiberty. Remove case-statement setting skipdirs=target-libiberty for multiple targets. Remove checking target_configdirs and removing target-libiberty but keeping target-libgcc if otherwise empty. * Makefile.def (target_modules): Don't add libiberty. (dependencies): Remove all traces of target-libiberty. * configure, Makefile.in: Regenerate. (add missing PR annotation in the ChangeLog entry) Modified: trunk/ChangeLog
[Bug bootstrap/23656] Cross-compilation with newlib fails in libiberty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23656 --- Comment #3 from Hans-Peter Nilsson 2011-06-22 21:30:24 UTC --- Author: hp Date: Wed Jun 22 21:30:19 2011 New Revision: 175316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175316 Log: PR regression/47836 PR bootstrap/23656 PR other/47733 PR bootstrap/49247 PR c/48825 * configure.ac (target_libraries): Remove target-libiberty. Remove case-statement setting skipdirs=target-libiberty for multiple targets. Remove checking target_configdirs and removing target-libiberty but keeping target-libgcc if otherwise empty. * Makefile.def (target_modules): Don't add libiberty. (dependencies): Remove all traces of target-libiberty. * configure, Makefile.in: Regenerate. (add missing PR annotation in the ChangeLog entry) Modified: trunk/ChangeLog
[Bug bootstrap/49247] libiberty configure assumes newlib does not supply psignal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49247 --- Comment #2 from Hans-Peter Nilsson 2011-06-22 21:30:25 UTC --- Author: hp Date: Wed Jun 22 21:30:19 2011 New Revision: 175316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175316 Log: PR regression/47836 PR bootstrap/23656 PR other/47733 PR bootstrap/49247 PR c/48825 * configure.ac (target_libraries): Remove target-libiberty. Remove case-statement setting skipdirs=target-libiberty for multiple targets. Remove checking target_configdirs and removing target-libiberty but keeping target-libgcc if otherwise empty. * Makefile.def (target_modules): Don't add libiberty. (dependencies): Remove all traces of target-libiberty. * configure, Makefile.in: Regenerate. (add missing PR annotation in the ChangeLog entry) Modified: trunk/ChangeLog
[Bug other/42980] GCC parallel "make install" failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980 --- Comment #15 from Ralf Wildenhues 2011-06-22 21:35:10 UTC --- (In reply to comment #14) > Seems fixed. If so, please close. If not, please summarize remaining issues. The patches in comments #8 and #10 are essentially unfixed, IIRC. #10 needs an update to Automake, that then needs propagated to GCC. This update changes multilib handling semantics slightly. I'm not sure if there are other problems with parallel install, but at that time I didn't see any others at least.
[Bug middle-end/49373] [4.7 Regression] Many testcase failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49373 --- Comment #10 from Hans-Peter Nilsson 2011-06-22 21:38:23 UTC --- Author: hp Date: Wed Jun 22 21:38:20 2011 New Revision: 175317 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175317 Log: PR middle-end/49373 * g++.dg/torture/pr43879-1_1.C: Xfail for -O1 and above, except -flto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/pr43879-1_1.C
[Bug target/28854] unwinder reports sentinel frame.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28854 Pawel Sikora changed: What|Removed |Added Known to fail|| --- Comment #3 from Pawel Sikora 2011-06-22 21:48:28 UTC --- please close this issue, my last alpha hardware died.
[Bug tree-optimization/24333] missed div optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24333 --- Comment #7 from Pawel Sikora 2011-06-22 21:56:27 UTC --- 4.6 still affected: f: movl%edi, %edx movl%edi, %eax sarl$31, %edx idivl %edi ret
[Bug tree-optimization/28850] missed call -> jmp transformation; redundant unwind stuff with empty finally
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28850 Pawel Sikora changed: What|Removed |Added Known to fail||4.6.1 --- Comment #5 from Pawel Sikora 2011-06-22 22:05:16 UTC --- call->jmp still not transformed for original testcase.
[Bug fortran/49509] New: cannot promote types for arguments passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 Summary: cannot promote types for arguments passed by value Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: stev...@alum.mit.edu Compile the following test program gfortran, which is a toy example of iso_c_binding that calls malloc(3). program bug use, intrinsic :: iso_c_binding implicit none interface type(C_PTR) function malloc(n) bind(C, name='malloc') import integer(C_SIZE_T), value :: n end function malloc end interface integer, parameter :: n = 3 integer(C_SIZE_T) sz type(C_PTR) p p = malloc(n) ! compiler error, cannot promote argument passed by value sz = n ! ... whereas assignment succeeds p = malloc(sz) end program bug I obtain the following error: promote.f03:15.13: p = malloc(n) ! compiler error, cannot promote argument type 1 Error: Type mismatch in argument 'n' at (1); passed INTEGER(4) to INTEGER(8) (Similarly with older versions of gcc.) Note that "n" is passed by value, so my understanding is that this should act much like the assignment sz = n (which succeeds): gfortran should automatically promote n to a size_t, like any other assignment of a narrower type to a wider type. Please consider applying the same type-promotion rules that are used for assignments to passing arguments by value. (I don't have the Fortran 2003 standard handy, but it is hard to believe that the two situations should be treated differently.)
[Bug middle-end/30506] not sibcalling a function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30506 Pawel Sikora changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #7 from Pawel Sikora 2011-06-22 22:14:00 UTC --- seems to be fixed: g: subq$131080, %rsp movl$131072, %edx xorl%esi, %esi movq%rsp, %rdi callmemset xorl%edi, %edi addq$131080, %rsp jmp f
[Bug target/28854] unwinder reports sentinel frame.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28854 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #4 from Uros Bizjak 2011-06-22 22:15:25 UTC --- (In reply to comment #3) > please close this issue, my last alpha hardware died. Wontfix.
[Bug web/46305] [Regression] Bugzilla: PR comment type of links: Comment links to the wrong bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46305 Frédéric Buclin changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |LpSolit at netscape dot net |gnu.org | --- Comment #4 from Frédéric Buclin 2011-06-22 22:17:42 UTC --- I finally managed to fix the problem without waiting for 4.2.
[Bug other/42980] GCC parallel "make install" failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42980 --- Comment #16 from Gary Funck 2011-06-22 22:19:07 UTC --- (In reply to comment #15) Ralf W. wrote (in part) > I'm not sure if there are other problems with parallel install, but at that > time I didn't see any others at least. Agreed. Off list, I wrote the following. On 03/01/10 07:48:09, Gary Funck wrote: > Ralf, > > I ran 1000 installs and they're all clean. > Typically, something would've failed in > that many installs.
[Bug target/49263] SH Target: underutilized "TST #imm, R0" instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263 --- Comment #4 from Kazumoto Kojima 2011-06-22 22:34:04 UTC --- Yes, that peephole doesn't catch all the patterns which could make tst #imm8,r0 use. Perhaps it would be a good idea to get numbers for the test like CSiBE test with the vanilla and new insns/peepholes patched compilers. Something covers 80% of the possible cases in the usual working set, it would be enough successful for such a micro-optimization, I guess. Cost patch looks fine to me. Could you propose it as a separate patch on gcc-patches list with an appropriate ChangeLog entry? When proposing it, please refer how you've tested it. Also the numbers got with the patch are highly welcome. BTW, do you have FSF copyright assignment for your GCC work? Although the cost patch itself is essentially several lines which doesn't require copyright assignment, the other changes you've proposed clearly require the paper work, I think.
[Bug target/49468] SH Target: inefficient integer abs code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468 Kazumoto Kojima changed: What|Removed |Added Severity|normal |enhancement --- Comment #3 from Kazumoto Kojima 2011-06-22 22:37:28 UTC --- On sh4-unknown-linux-gnu, this patch causes two new failures on libstdc++ testsuite FAIL: 27_io/basic_ostream/inserters_arithmetic/char/7.cc execution test FAIL: 27_io/basic_ostream/inserters_arithmetic/wchar_t/7.cc execution test I can't find any differences between generated codes for those test cases by compilers with/without your patch and the failures go away if the tests are running with libstdc++ library built with the unpatched compiler. So it seems that something in libstdc++ library is miscompiled. Weired and hard to see what is going on, ATM.
[Bug web/46305] [Regression] Bugzilla: PR comment type of links: Comment links to the wrong bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46305 --- Comment #5 from Jonathan Wakely 2011-06-22 22:39:31 UTC --- nice, thanks!
[Bug c++/49510] New: bitshift warnings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49510
Summary: bitshift warnings
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: claytongda...@gmail.com
This is a request to improve the warnings for bitshifts where the right operand
is negative or >= the size of the left operand. I am aware that this is
undefined behavior, but a warning would be nice in a case like the one included
below. GCC implements a cyclic bitshift instead.
$ more gcc_bitshift.C
#include
int main()
{
int shift = 32;
std::cout<<"0x>>32 = "<<(0x>>shift)<>(-1) = "<<(0x>>shift)<>32 = 4294967295
1<<32 = 1
0x>>(-1) = 1
1<<(-1) = -2147483648
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default
--with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
[Bug ada/49511] New: [4.6 Regression] acats test setup fails on HP-UX using posix shell
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49511 Summary: [4.6 Regression] acats test setup fails on HP-UX using posix shell Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org CC: r...@gcc.gnu.org Host: hppa1.1-hp-hpux10.20 Target: hppa1.1-hp-hpux10.20 Build: hppa1.1-hp-hpux10.20 make[3]: Leaving directory `/xxx/gnu/gcc/objdir/gcc' dirname: extra operand `is' Try `dirname --help' for more information. dirname: extra operand `is' Try `dirname --help' for more information. Test Run By dave on Wed Jun 22 20:01:45 EDT 2011 === acats configuration === target gcc is /xxx/gnu/gcc/objdir/gcc/xgcc -B/xxx/gnu/gcc/objdir/gcc/ Reading specs from /xxx/gnu/gcc/objdir/gcc/specs COLLECT_GCC=/xxx/gnu/gcc/objdir/gcc/xgcc COLLECT_LTO_WRAPPER=/xxx/gnu/gcc/objdir/gcc/lto-wrapper Target: hppa1.1-hp-hpux10.20 Configured with: ../gcc/configure --with-gnu-as --with-as=/usr/local/bin/as --enable-shared --prefix=/opt/gnu/gcc/gcc-4.6 --with-gmp=/opt/gnu/gcc/gmp --enable-debug=no --disable-nls --enable-languages=c,c++,objc,fortran,ada,obj-c++ Thread model: single gcc version 4.6.1 20110619 (prerelease) [gcc-4_6-branch revision 175188] (GCC) host=hppa1.1-hp-hpux10.20 target=hppa1.1-hp-hpux10.20 gnatmake is /xxx/gnu/gcc/objdir/gcc/gnatmake === acats support === Generating support files...fatal error, run-time library not installed correctly cannot locate file system.ads gnatmake: *** make failed. Failed to compile macrosub make[2]: *** [check-acats] Error 1 Problem was introduce in revision 158994. The problem is type invokes the sh-posix shell and it aliases type to 'whence -v'. 599 (hiauly1)dave> /bin/sh $ whence -v gnatmake gnatmake is /opt/gnu/gcc/gcc-4.5/bin/gnatmake $ whence gnatmake /opt/gnu/gcc/gcc-4.5/bin/gnatmake It appears the same would also occur on HP-UX 11.X but there I have always used bash as the CONFIG_SHELL. -bash-3.2$ type -p ls /usr/bin/ls -bash-3.2$ /usr/bin/sh $ type -p ls ls is /usr/bin/ls
[Bug fortran/49509] cannot promote types for arguments passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-06-23 02:10:32 UTC --- I believe your code is simply invalid on some targets. You need to change integer, parameter :: n = 3 to integer(c_size_t), parameter :: n = 3 The matching of type, kind, and rank of actual and dummy argument is a requirement of the Fortran standard. This requirement is placed on the programmer. What you want is explicitly prohibited by the standard. 12.4.1.2 Actual arguments associated with dummy data objects If a dummy argument is neither allocatable nor a pointer, it shall be type compatible (5.1.1.2) with the associated actual argument. The type parameter values of the actual argument shall agree with the corresponding ones of the dummy argument that are not assumed or deferred, except for the case of the character length parameter of an actual argument of type default character associated with a dummy argument that is not assumed shape. This should probably be closed as WONTFIX, but I'll let other gfortran maintainers weigh in on the subject.
[Bug bootstrap/49383] [4.7 regression] powerpc64-linux bootstrap failure due to ice in cgraph_only_called_directly_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org |
[Bug bootstrap/49383] [4.7 regression] powerpc64-linux bootstrap failure due to ice in cgraph_only_called_directly_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383 --- Comment #6 from Alan Modra 2011-06-23 02:21:03 UTC --- Author: amodra Date: Thu Jun 23 02:21:01 2011 New Revision: 175328 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175328 Log: PR bootstrap/49383 * config/rs6000/rs6000.c (call_ABI_of_interest): Adjust cgraph invocation for 2011-06-09 changes. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug bootstrap/49383] [4.7 regression] powerpc64-linux bootstrap failure due to ice in cgraph_only_called_directly_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49383 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-06/msg01735.htm ||l Resolution||FIXED --- Comment #7 from Alan Modra 2011-06-23 02:22:31 UTC --- Patch applied
[Bug fortran/49509] cannot promote types for arguments passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 --- Comment #3 from stevenj at alum dot mit.edu 2011-06-23 03:00:47 UTC --- > Hence, the familiar old requirements of the Fortran standard are irrelevant. > The question is, what does the Fortran 2003 standard require for passing by > value, which is I believe is NEW IN FORTRAN 2003, and is SPECIFIC TO BIND(C) > functions. Just checked, and the VALUE attribute it is indeed new in Fortran 2003, but it is not specific to bind(C). But the point remains that your usual understanding of Fortran semantics does not apply here.
[Bug fortran/49509] cannot promote types for arguments passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 --- Comment #2 from stevenj at alum dot mit.edu 2011-06-23 02:54:50 UTC --- You're missing the point. Traditionally in Fortran, all arguments were passed *by reference*, in which case it is clearly a requirement that actual parameter match the formal parameter's type exactly, because the formal parameter refers to the *same memory* as the actual parameter. However, in this case we are passing by value. This should act just like an assignment of the formal parameter to the actual parameter (as opposed to having them be the *same* object as in passing by reference). Hence, just like an assignment statement the compiler should be able to assign a narrower integer type to a wider one. Hence, the familiar old requirements of the Fortran standard are irrelevant. The question is, what does the Fortran 2003 standard require for passing by value, which is I believe is NEW IN FORTRAN 2003, and is SPECIFIC TO BIND(C) functions.
[Bug middle-end/35561] Promote written once local aggregates to static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35561
Steven Fuerst changed:
What|Removed |Added
CC||svfuerst at gmail dot com
--- Comment #6 from Steven Fuerst 2011-06-23
03:14:13 UTC ---
Still a problem in 4.6 at all optimization levels.
int foo1(int x)
{
int a[] = {1,4,7,9};
return a[x];
}
int foo2(int x)
{
static int a[] = {1,4,7,9};
return a[x];
}
foo1() creates the array on the stack using a series of mov instructions,
whereas the code generated for foo2() is much nicer.
[Bug middle-end/35561] Promote written once local aggregates to static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35561 --- Comment #7 from Andrew Pinski 2011-06-23 03:17:58 UTC --- At one point this was done but it was found it violated C rules. I can find the bug report but I am being lazy right now but it comes down to if it was promoted then you have issues if it escaped. Oh and technically a[i] does take the address of a.
[Bug fortran/49509] cannot promote types for arguments passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 --- Comment #4 from stevenj at alum dot mit.edu 2011-06-23 03:23:06 UTC --- Section 12.4.1.2 of Fortran 2003 standard: "If the dummy argument has the VALUE attribute it becomes associated with a definable anonymous data object whose initial value is that of the actual argument." Furthermore, NOTE 12.22 says: "If the VALUE attribute is specified, the effect is as if the actual argument is assigned to a temporary, and the temporary is then argument associated with the dummy argument. The actual mechanism by which this happens is determined by the processor." Thus, if you have a subroutine foo(x) with T, VALUE :: X, then the standard requires that call foo(y) have the same "effect as if" you did T :: temp temp = y call foo(temp) with pass by reference. But in that case, it would be valid to assign y to a wider type T. This implicitly contravenes the wording earlier in the section that the dummy and actual argument be "type compatible (5.1.1.2)". It is unfortunate that it is not explicit on this point, however -- one could argue that there is a bug in the standard here.
[Bug fortran/49509] cannot promote types for arguments passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 --- Comment #5 from Steve Kargl 2011-06-23 04:01:49 UTC --- On Thu, Jun 23, 2011 at 02:55:20AM +, stevenj at alum dot mit.edu wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 > > --- Comment #2 from stevenj at alum dot mit.edu 2011-06-23 02:54:50 UTC --- > You're missing the point. Ah, no. I believe I understand what you want. > Traditionally in Fortran, all arguments were passed *by reference*, > in which case it is clearly a requirement that actual parameter > match the formal parameter's type exactly, because the formal parameter refers > to the *same memory* as the actual parameter. Traditionally, the standard was silent on the passing mechanism. It could have been accomplished by chipmunks. > However, in this case we are passing by value. This should act > just like an assignment of the formal parameter to the actual > parameter (as opposed to having them be the *same* object as > in passing by reference). Hence, just like an assignment statement > the compiler should be able to assign a narrower > integer type to a wider one. That's not what the standard mandates.
[Bug fortran/49509] cannot promote types for arguments passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 --- Comment #6 from Steve Kargl 2011-06-23 04:02:38 UTC --- On Thu, Jun 23, 2011 at 03:01:04AM +, stevenj at alum dot mit.edu wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 > > --- Comment #3 from stevenj at alum dot mit.edu 2011-06-23 03:00:47 UTC --- > > Hence, the familiar old requirements of the Fortran standard are irrelevant. > > The question is, what does the Fortran 2003 standard require for passing by > > value, which is I believe is NEW IN FORTRAN 2003, and is SPECIFIC TO BIND(C) > > functions. > > Just checked, and the VALUE attribute it is indeed new in Fortran 2003, but it > is not specific to bind(C). > > But the point remains that your usual understanding of Fortran semantics does > not apply here. > Sorry, but I believe the semantics do apply. I already fixed your toy code.
[Bug fortran/49509] cannot promote types for arguments passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 --- Comment #7 from Steve Kargl 2011-06-23 04:13:49 UTC --- On Thu, Jun 23, 2011 at 03:23:26AM +, stevenj at alum dot mit.edu wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 > > --- Comment #4 from stevenj at alum dot mit.edu 2011-06-23 03:23:06 UTC --- > Section 12.4.1.2 of Fortran 2003 standard: > "If the dummy argument has the VALUE attribute it becomes associated with a > definable anonymous data object whose initial value is that of the actual > argument." I believe you are misintrepreting the meaning of "defineable anonymous data object". This does not mean that TKR does not apply. It means, well, the data object is definable and it is anonymous to the calling procedure. That is, the calling procedure has no means to getting at anything that might affect the value of the dummy argument. > Furthermore, NOTE 12.22 says: NOTEs in the standard are non-normative text. > "If the VALUE attribute is specified, the effect is as if the actual argument > is assigned to a temporary, and the temporary is then argument associated with > the dummy argument. The actual mechanism by which this happens is determined > by the processor." This note does not remove the requirement of TKR. > It is unfortunate that it is not explicit on this point, > however -- one could argue that there is a bug in the > standard here. Feel free to post to comp.lang.c about the issue. The technical editor of F2003 routinely answers questions about the standard as do others who are current members of J3 or former members of J3.
[Bug middle-end/49512] New: FAIL: gcc.dg/tree-ssa/asm-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49512 Summary: FAIL: gcc.dg/tree-ssa/asm-1.c Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/x86-64, revision 175284 gave FAIL: gcc.dg/tree-ssa/asm-1.c scan-tree-dump-times optimized "63" 1 Revision 175251 is OK.
[Bug fortran/49509] cannot promote types for arguments passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49509 --- Comment #8 from Steve Kargl 2011-06-23 04:22:51 UTC --- On Wed, Jun 22, 2011 at 09:13:19PM -0700, Steve Kargl wrote: > > Feel free to post to comp.lang.c about the issue. The > technical editor of F2003 routinely answers questions > about the standard as do others who are current members > of J3 or former members of J3. > Dang. That should have been comp.lang.fortran.
[Bug middle-end/49512] [4.7 Regression] FAIL: gcc.dg/tree-ssa/asm-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49512 H.J. Lu changed: What|Removed |Added Target Milestone|--- |4.7.0 Summary|FAIL: |[4.7 Regression] FAIL: |gcc.dg/tree-ssa/asm-1.c |gcc.dg/tree-ssa/asm-1.c --- Comment #1 from H.J. Lu 2011-06-23 05:06:17 UTC --- It failed with -march=core2.
[Bug middle-end/49512] [4.7 Regression] FAIL: gcc.dg/tree-ssa/asm-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49512 H.J. Lu changed: What|Removed |Added Target||x86_64 CC||bernds at gcc dot gnu.org --- Comment #2 from H.J. Lu 2011-06-23 05:38:10 UTC --- It is caused by revision 175261: http://gcc.gnu.org/ml/gcc-cvs/2011-06/msg00752.html Executing on host: /export/regression/rrs/175261/bld/gcc/xgcc -B/export/regression/rrs/175261/bld/gcc/ /export/regression/rrs/175261/src/gcc/testsuite/gcc.dg/tree-ssa/asm-1.c -O -fdump-tree-optimized -S -march=core2 -o asm-1.s(timeout = 300) spawn -ignore SIGHUP /export/regression/rrs/175261/bld/gcc/xgcc -B/export/regression/rrs/175261/bld/gcc/ /export/regression/rrs/175261/src/gcc/testsuite/gcc.dg/tree-ssa/asm-1.c -O -fdump-tree-optimized -S -march=core2 -o asm-1.s^M PASS: gcc.dg/tree-ssa/asm-1.c (test for excess errors) PASS: gcc.dg/tree-ssa/asm-1.c scan-tree-dump-times optimized "42" 1 FAIL: gcc.dg/tree-ssa/asm-1.c scan-tree-dump-times optimized "63" 1
