[Bug other/38920] dw2 exceptions don't work.
--- Comment #9 from janus at gcc dot gnu dot org 2009-04-07 07:25 --- Subject: Bug 38920 Author: janus Date: Tue Apr 7 07:24:37 2009 New Revision: 145651 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145651 Log: 2009-04-07 Janus Weil ja...@gcc.gnu.org PR fortran/38920 * expr.c (gfc_check_pointer_assign): Enable interface check for procedure pointers. * gfortran.h: Add copy_formal_args_intr. * interface.c (gfc_compare_interfaces): Call gfc_compare_intr_interfaces if second argument is an intrinsic. (compare_intr_interfaces): Correctly set attr.function, attr.subroutine and ts. (compare_parameter): Call gfc_compare_interfaces also for intrinsics. * resolve.c (resolve_specific_f0,resolve_specific_s0): Don't resolve intrinsic interfaces here. Must happen earlier. (resolve_symbol): Resolution of intrinsic interfaces moved here from resolve_specific_..., and formal args are now copied from intrinsic interfaces. * symbol.c (copy_formal_args_intr): New function to copy the formal arguments from an intinsic procedure. 2009-04-07 Janus Weil ja...@gcc.gnu.org PR fortran/38920 * gfortran.dg/proc_decl_1.f90: Modified. * gfortran.dg/proc_ptr_11.f90: Extended. * gfortran.dg/proc_ptr_13.f90: Modified. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_decl_1.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_11.f90 trunk/gcc/testsuite/gfortran.dg/proc_ptr_13.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
[Bug fortran/38290] procedure pointer assignment checking
--- Comment #10 from janus at gcc dot gnu dot org 2009-04-07 07:32 --- Fixed with r145651 (I messed up the PR number in the ChangeLog entry, though). Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38290
[Bug other/38920] dw2 exceptions don't work.
--- Comment #10 from janus at gcc dot gnu dot org 2009-04-07 07:34 --- Oops. The commit in comment #9 was actually for PR38290, but I accidentally messed up the PR number in the ChangeLog. Sorry for the noise. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38920
[Bug c/39621] Delaying operation to end of function causes high stack usage
--- Comment #3 from wvangulik at xs4all dot nl 2009-04-07 07:55 --- (In reply to comment #2) It'd be nice to know if -fno-tree-reassoc helped here. Yes that solves the problem. I tried for -O[123s] (x86 and avr). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39621
[Bug fortran/39670] New: dollar sign in entities is not recognized when it is first symbol
With option -fdollar-ok the compiler does not recognize symbols that start with $ test case: program test a$a = 12 $a = 12! error end I currently have a lot of legacy code with identifiers starting with $. -- Summary: dollar sign in entities is not recognized when it is first symbol Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anickol at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39670
[Bug fortran/39670] dollar sign in entities is not recognized when it is first symbol
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-04-07 08:42 --- Confirmed. Checked 4.3.4 and 4.5.0, both complain about '$a'. Question is, if this is allowed at all. In comparison: digits are allowed in function names, but not as the first character; 'FUNCTION f3()' is valid, 'FUNCTION 3f()' is not. Does this apply to '$' as well? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Keywords||diagnostic Version|unknown |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39670
[Bug libstdc++/39310] T const assumed to be compatible with int (A::*) (void) const
--- Comment #14 from paolo dot carlini at oracle dot com 2009-04-07 08:51 --- Fixed for 4.4.0 too. Thanks Jason. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39310
[Bug fortran/39670] dollar sign in entities is not recognized when it is first symbol
--- Comment #2 from anickol at yahoo dot com 2009-04-07 08:59 --- As I already said, I have code, being compiled with MS Fortran, that has a lot of variable names starting with $. MS Fortran allows it. My personal opinion is that the Fortran compiler's primary use is support of the legacy code. That means that the implementation of any extension or even strange behaviour of existing compilers could be useful and will save hours of hard work. Forcing standards on existing code is illogical. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39670
[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion
--- Comment #11 from singler at gcc dot gnu dot org 2009-04-07 09:09 --- I found a shorter solution: Just parametrize equal_to with const T instead of T. Better? In general, passing the element to find as const ref is the safest we can do, isn't it? AFAIK the other option is to not pass it at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion
--- Comment #12 from singler at gcc dot gnu dot org 2009-04-07 09:10 --- Created an attachment (id=17598) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17598action=view) Patch differently parametrizing equal_to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39546
[Bug fortran/39670] dollar sign in entities is not recognized when it is first symbol
--- Comment #3 from dominiq at lps dot ens dot fr 2009-04-07 09:12 --- Question is, if this is allowed at all. In comparison: digits are allowed in function names, but not as the first character; 'FUNCTION f3()' is valid, 'FUNCTION 3f()' is not. My fortran book says: names must consist of between 1 and 31 alphanumeric characters (letters, underscores, and numerals) of which the first MUST BE A LETTER. Does this apply to '$' as well? Since '$' is an extension, you know the answer! It is outside the scope of the standard. BTW what should be the implict type of a variable starting with a $? Now I am not sure that, in the relics of past, names starting with a '$' had some side effects. I don't think it is likely to change this extension in gfortran. For the legacy code, the workaround depends on the kind of the variables starting with a '$'. If they are all of the same kind (say integer) then it is trivial with you favorite editor to replace all the '$name' by 'izzname' or 'i$name' (may be with some filters if you have $ elsewhere). My personal opinion is that the Fortran compiler's primary use is support of the legacy code. This is your personnal opinion, not mine and probably not of anyone coding in fortran. In addition I have always been very suspicious about the validity of the port of such legacy codes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39670
[Bug c/39635] [avr] integer wrong code bug
--- Comment #2 from wvangulik at xs4all dot nl 2009-04-07 09:51 ---
The problem is it uses R22 as loop counter and as the shift counter. I could
not (yet) reproduce the problem in a smaller example.
This could be the same problem as:
http://lists.gnu.org/archive/html/avr-gcc-list/2009-03/msg00203.html
or
http://lists.gnu.org/archive/html/avr-gcc-list/2009-03/msg00158.html
; (insn 16 15 17 main.c:24 (set (reg/v:HI 22 r22 [orig:42 _left ] [42])
; (ashift:HI (reg/v:HI 22 r22 [orig:42 _left ] [42])
; (reg:QI 22 r22 [orig:54 _right.2 ] [54]))) 54 {ashlhi3}
(expr_list:REG_DEAD (reg:QI 18 r18 [orig:54 _right.2 ] [54])
; (expr_list:REG_UNUSED (reg:QI 23 r23)
; (nil
rjmp 2f ; 16 ashlhi3/1 [length = 6]
1: lsl r22
rol r23
2: dec r22
brpl 1b
An other interresting point is the rtl stating reg 23 is unused. Unfortunatly
the avr backend can not remove the useless shift. But that is another issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39635
[Bug fortran/38152] [4.4 Regression] procedure pointers as module variables
--- Comment #15 from janus at gcc dot gnu dot org 2009-04-07 11:40 --- Reopening. proc_decl_13.f90 produces a segfault when compiled with -g. Backtrace: #0 0x00f4bee1 in htab_hash_string (p=0x0) at /home/jweil/gcc45/trunk/libiberty/hashtab.c:812 #1 0x005ff979 in lookup_filename (file_name=0x0) at /home/jweil/gcc45/trunk/gcc/dwarf2out.c:15710 #2 0x005f3efd in add_src_coords_attributes (die=0x7f26495edcc0, decl=0x7f26496adaa0) at /home/jweil/gcc45/trunk/gcc/dwarf2out.c:12551 #3 0x005f4089 in add_name_and_src_coords_attributes (die=0x7f26495edcc0, decl=0x7f26496adaa0) at /home/jweil/gcc45/trunk/gcc/dwarf2out.c:12568 #4 0x005f9405 in gen_variable_die (decl=0x7f26496adaa0, origin=0x0, context_die=0x7f26495ed3c0) at /home/jweil/gcc45/trunk/gcc/dwarf2out.c:14036 #5 0x005fe0ba in gen_decl_die (decl=0x7f26496adaa0, origin=0x0, context_die=0x7f26495ed3c0) at /home/jweil/gcc45/trunk/gcc/dwarf2out.c:15309 #6 0x005ff2a4 in dwarf2out_decl (decl=0x7f26496adaa0) at /home/jweil/gcc45/trunk/gcc/dwarf2out.c:15615 #7 0x005fe7c6 in dwarf2out_global_decl (decl=0x7f26496adaa0) at /home/jweil/gcc45/trunk/gcc/dwarf2out.c:15355 #8 0x00907815 in emit_debug_global_declarations (vec=0x2f7ba40, len=1342) at /home/jweil/gcc45/trunk/gcc/toplev.c:902 #9 0x007bffec in write_global_declarations () at /home/jweil/gcc45/trunk/gcc/langhooks.c:334 #10 0x00907dbc in compile_file () at /home/jweil/gcc45/trunk/gcc/toplev.c:987 #11 0x00909c7e in do_compile () at /home/jweil/gcc45/trunk/gcc/toplev.c:2241 #12 0x00909ce2 in toplev_main (argc=3, argv=0x7fff5172fb68) at /home/jweil/gcc45/trunk/gcc/toplev.c:2273 #13 0x005137db in main (argc=3, argv=0x7fff5172fb68) at /home/jweil/gcc45/trunk/gcc/main.c:35 -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/38152] [4.4 Regression] procedure pointers as module variables
--- Comment #17 from jakub at gcc dot gnu dot org 2009-04-07 12:11 --- All !DECL_IGNORED_P VAR_DECLs should have DECL_SOURCE_LOCATION set to something other than UNKNOWN_LOCATION. So, either the FE forgot to set it, or it didn't set DECL_IGNORED_P flag when it should. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug tree-optimization/39672] Local statics not promoted to const
--- Comment #2 from rguenther at suse dot de 2009-04-07 12:14 --- Subject: Re: Local statics not promoted to const On Tue, 7 Apr 2009, hubicka at ucw dot cz wrote: --- Comment #1 from hubicka at ucw dot cz 2009-04-07 11:44 --- Subject: Re: New: Local statics not promoted to const ipa-reference definitly is supposed to do this transform. I will debug why it does not in this testcase. I think it only adjusts global statics. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39672
[Bug c/39673] New: internal compiler error: in fold_binary, at fold-const.c:9642
Hi, i have problem when compiling vim-7.2 in LFS64 TIA == bash-4.0$ cc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap --disable-multilib Thread model: posix gcc version 4.5.0 20090407 (experimental) (GCC) bash-4.0$ pwd /home/user/d/vim7.2 bash-4.0$ make Starting make in the src directory. If there are problems, cd to the src directory and run make there cd src make first make[1]: Entering directory `/home/user/d/vim7.2/src' gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -D_FORTIFY_SOURCE=1 -o objects/spell.o spell.c spell.c: In function : spell.c:5720: warning: offset outside bounds of constant string spell.c:5733: warning: offset outside bounds of constant string spell.c:5733: warning: offset outside bounds of constant string spell.c:5772: warning: offset outside bounds of constant string spell.c:5783: warning: offset outside bounds of constant string spell.c:5785: warning: offset outside bounds of constant string spell.c:5806: warning: offset outside bounds of constant string spell.c:6046: warning: offset outside bounds of constant string spell.c: In function : spell.c:6557: warning: offset outside bounds of constant string spell.c: In function : spell.c:7059: internal compiler error: in fold_binary, at fold-const.c:9642 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [objects/spell.o] Error 1 make[1]: Leaving directory `/home/user/d/vim7.2/src' make: *** [first] Error 2 bash-4.0$ vi fold-const.c +9642 gcc_assert (IS_EXPR_CODE_CLASS (kind) TREE_CODE_LENGTH (code) == 2 op0 != NULL_TREE op1 != NULL_TREE); -- Summary: internal compiler error: in fold_binary, at fold- const.c:9642 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: happyarch at gmail dot com GCC build triplet: x86_64 GCC host triplet: x86_64 GCC target triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39673
[Bug fortran/38152] [4.4 Regression] procedure pointers as module variables
--- Comment #16 from janus at gcc dot gnu dot org 2009-04-07 11:43 --- (In reply to comment #15) proc_decl_13.f90 produces a segfault when compiled with -g. Sorry. Of course I'm talking about proc_ptr_13.f90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug c/39671] solaris 10 with gcc 3.4.3
--- Comment #2 from abhinav dot dubey at hcl dot in 2009-04-07 10:39 --- (In reply to comment #0) tring to compile batch libraries with make commang but geeting an error $ make -f retek.mk retek rms resa 21 | tee libretek.log cc -DNDEBUG -I. -I/data/rmsdb/rms/oracle/lib/src -I/data/u01/app/oracle/product/10.2.0/db_1/precomp/public -I/data/u01/app/oracle/product/10.2.0/db_1/rdbms/public -I/data/u01/app/oracle/product/10.2.0/db_1/plsql/public -I/data/u01/app/oracle/product/10.2.0/db_1/sqllib/public -I/data/u01/app/oracle/product/10.2.0/db_1/network/public -I/data/u01/app/oracle/product/10.2.0/db_1/rdbms/demo -g -Xa -xstrconst -dalign -xF -xildoff -errtags=yes -v -xarch=v9 -xchip=ultra3 -W2,-AKNR_S -Wd,-xsafe=unboundsym -Wc,-Qiselect-funcalign=32 -xcode=abs44 -Wc,-Qgsched-trace_late=1 -Wc,-Qgsched-T5 -D_REENTRANT -DSS_64BIT_SERVER -DBIT64 -DMACHINE64 -K PIC -DPRECOMP -I/data/u01/app/oracle/product/10.2.0/db_1/precomp/hdrs -I/data/u01/app/oracle/product/10.2.0/db_1/precomp/public -I/data/u01/app/oracle/product/10.2.0/db_1/precomp/include -I/data/u01/app/oracle/product/10.2.0/db_1/oracore/include -I/data/u01/app/oracle/product/10.2.0/db_1/oracore/public -I/data/u01/app/oracle/product/10.2.0/db_1/oracore/port/include -I/data/u01/app/oracle/product/10.2.0/db_1/xdk/include -I/data/u01/app/oracle/product/10.2.0/db_1/xdk/public -I/data/u01/app/oracle/product/10.2.0/db_1/nlsrtl/include -I/data/u01/app/oracle/product/10.2.0/db_1/slax/include -I. -DSLMXMX_ENABLE -DSLTS_ENABLE -D_SVID_GETTOD -D_REENTRANT-c saoranumadd.c -o `basename /data/rmsdb/rms/oracle/lib/src/saoranumadd.o` cc: PIC: No such file or directory Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs cc: unrecognized option `-Xa' cc: unrecognized option `-K' Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) cc: language code=abs44 not recognized cc: saoranumadd.c: linker input file unused because linking not done *** Error code 1 make: Fatal error: Command failed for target `saoranumadd.o' ... also try to compile by gcc comman ... the famous hello word program.. $ gcc -c -Wall -D_GNU_SOURCE abhi.c -o abhi.o $ gcc -c abhi.o abhi.c gcc: abhi.o: linker input file unused because linking not done .. have tried all possible fixes urgently need to up system .. any help will be highly appreciated. Thanks, (In reply to comment #1) also try to compile by gcc comman ... the famous hello word program.. $ gcc -c -Wall -D_GNU_SOURCE abhi.c -o abhi.o $ gcc -c abhi.o abhi.c gcc: abhi.o: linker input file unused because linking not done .. have tried all possible fixes gcc -o abhi abhi.o Thanks.. it getting compiled in this manner and showed that my gcc compiler working fine but for batch libraries using make command ,I am still getting the same error as $ make -f retek.mk retek rms resa 21 | tee libretek.log cc -DNDEBUG -I. -I/data/rmsdb/rms/oracle/lib/src -I/data/u01/app/oracle/product/10.2.0/db_1/precomp/public -I/data/u01/app/oracle/product/10.2.0/db_1/rdbms/public -I/data/u01/app/oracle/product/10.2.0/db_1/plsql/public -I/data/u01/app/oracle/product/10.2.0/db_1/sqllib/public -I/data/u01/app/oracle/product/10.2.0/db_1/network/public -I/data/u01/app/oracle/product/10.2.0/db_1/rdbms/demo -g -Xa -xstrconst -dalign -xF -xildoff -errtags=yes -v -xarch=v9 -xchip=ultra3 -W2,-AKNR_S -Wd,-xsafe=unboundsym -Wc,-Qiselect-funcalign=32 -xcode=abs44 -Wc,-Qgsched-trace_late=1 -Wc,-Qgsched-T5 -D_REENTRANT -DSS_64BIT_SERVER -DBIT64 -DMACHINE64 -K PIC -DPRECOMP -I/data/u01/app/oracle/product/10.2.0/db_1/precomp/hdrs -I/data/u01/app/oracle/product/10.2.0/db_1/precomp/public -I/data/u01/app/oracle/product/10.2.0/db_1/precomp/include -I/data/u01/app/oracle/product/10.2.0/db_1/oracore/include -I/data/u01/app/oracle/product/10.2.0/db_1/oracore/public -I/data/u01/app/oracle/product/10.2.0/db_1/oracore/port/include -I/data/u01/app/oracle/product/10.2.0/db_1/xdk/include -I/data/u01/app/oracle/product/10.2.0/db_1/xdk/public -I/data/u01/app/oracle/product/10.2.0/db_1/nlsrtl/include -I/data/u01/app/oracle/product/10.2.0/db_1/slax/include -I. -DSLMXMX_ENABLE -DSLTS_ENABLE -D_SVID_GETTOD -D_REENTRANT-c saoranumadd.c -o `basename /data/rmsdb/rms/oracle/lib/src/saoranumadd.o` cc: PIC: No such file or directory Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs cc: unrecognized option `-Xa' cc: unrecognized option `-K' Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3
[Bug c/39671] New: solaris 10 with gcc 3.4.3
tring to compile batch libraries with make commang but geeting an error $ make -f retek.mk retek rms resa 21 | tee libretek.log cc -DNDEBUG -I. -I/data/rmsdb/rms/oracle/lib/src -I/data/u01/app/oracle/product/10.2.0/db_1/precomp/public -I/data/u01/app/oracle/product/10.2.0/db_1/rdbms/public -I/data/u01/app/oracle/product/10.2.0/db_1/plsql/public -I/data/u01/app/oracle/product/10.2.0/db_1/sqllib/public -I/data/u01/app/oracle/product/10.2.0/db_1/network/public -I/data/u01/app/oracle/product/10.2.0/db_1/rdbms/demo -g -Xa -xstrconst -dalign -xF -xildoff -errtags=yes -v -xarch=v9 -xchip=ultra3 -W2,-AKNR_S -Wd,-xsafe=unboundsym -Wc,-Qiselect-funcalign=32 -xcode=abs44 -Wc,-Qgsched-trace_late=1 -Wc,-Qgsched-T5 -D_REENTRANT -DSS_64BIT_SERVER -DBIT64 -DMACHINE64 -K PIC -DPRECOMP -I/data/u01/app/oracle/product/10.2.0/db_1/precomp/hdrs -I/data/u01/app/oracle/product/10.2.0/db_1/precomp/public -I/data/u01/app/oracle/product/10.2.0/db_1/precomp/include -I/data/u01/app/oracle/product/10.2.0/db_1/oracore/include -I/data/u01/app/oracle/product/10.2.0/db_1/oracore/public -I/data/u01/app/oracle/product/10.2.0/db_1/oracore/port/include -I/data/u01/app/oracle/product/10.2.0/db_1/xdk/include -I/data/u01/app/oracle/product/10.2.0/db_1/xdk/public -I/data/u01/app/oracle/product/10.2.0/db_1/nlsrtl/include -I/data/u01/app/oracle/product/10.2.0/db_1/slax/include -I. -DSLMXMX_ENABLE -DSLTS_ENABLE -D_SVID_GETTOD -D_REENTRANT-c saoranumadd.c -o `basename /data/rmsdb/rms/oracle/lib/src/saoranumadd.o` cc: PIC: No such file or directory Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs cc: unrecognized option `-Xa' cc: unrecognized option `-K' Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) cc: language code=abs44 not recognized cc: saoranumadd.c: linker input file unused because linking not done *** Error code 1 make: Fatal error: Command failed for target `saoranumadd.o' ... also try to compile by gcc comman ... the famous hello word program.. $ gcc -c -Wall -D_GNU_SOURCE abhi.c -o abhi.o $ gcc -c abhi.o abhi.c gcc: abhi.o: linker input file unused because linking not done .. have tried all possible fixes urgently need to up system .. any help will be highly appreciated. Thanks, -- Summary: solaris 10 with gcc 3.4.3 Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: abhinav dot dubey at hcl dot in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39671
[Bug c/39671] solaris 10 with gcc 3.4.3
--- Comment #4 from abhinav dot dubey at hcl dot in 2009-04-07 11:46 --- (In reply to comment #3) Please help me in solving this issue also... Your Makefile expects Sun CC and you're using GCC. There should not be any difference as i directed cc to gcc $ cc -v Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Is it somthing with a Sun cc?.Do I need to install Sun cc compiler or some work around is possible. -- abhinav dot dubey at hcl dot in changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39671
[Bug tree-optimization/39672] Local statics not promoted to const
--- Comment #1 from hubicka at ucw dot cz 2009-04-07 11:44 --- Subject: Re: New: Local statics not promoted to const ipa-reference definitly is supposed to do this transform. I will debug why it does not in this testcase. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39672
[Bug fortran/38152] [4.4 Regression] procedure pointers as module variables
--- Comment #18 from janus at gcc dot gnu dot org 2009-04-07 12:41 ---
Patch:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(Revision 145652)
+++ gcc/fortran/trans-decl.c(Arbeitskopie)
@@ -1015,10 +1015,12 @@ gfc_get_symbol_decl (gfc_symbol * sym)
if (sym-backend_decl)
return sym-backend_decl;
- /* Catch function declarations. Only used for actual parameters. */
+ /* Catch function declarations. Only used for actual parameters and
+ procedure pointers. */
if (sym-attr.flavor == FL_PROCEDURE)
{
decl = gfc_get_extern_function_decl (sym);
+ gfc_set_decl_location (decl, sym-declared_at);
return decl;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug tree-optimization/39672] New: Local statics not promoted to const
For
int foo(void)
{
static int blah = 1;
return blah;
}
we should be able to promote blah to TREE_READONLY during ipa-reference (or
local analysis) if blah does not have its address taken and is not written
to in the function body.
This occurs for example in 189.lucas via
real(kind=r16), save :: mt,one=1,two=2,one_fourth,pi,theta,theta2
note the save attribute.
--
Summary: Local statics not promoted to const
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39672
[Bug c/39671] solaris 10 with gcc 3.4.3
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-04-07 10:42 --- Please help me in solving this issue also... Your Makefile expects Sun CC and you're using GCC. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39671
[Bug fortran/39576] gcc/fortran/error.c's error_print - missing break ?
--- Comment #1 from pault at gcc dot gnu dot org 2009-04-07 09:23 --- from error.c(error_print) 00470 case 'u': 00471 arg[pos].type = TYPE_UINTEGER; 00472 00473 case 'l': 00474 c = *format++; 00475 if (c == 'u') 00476 arg[pos].type = TYPE_ULONGINT; 00477 else if (c == 'i' || c == 'd') 00478 arg[pos].type = TYPE_LONGINT; 00479 else 00480 gcc_unreachable (); 00481 break; so, yes, without analysis I would say that the report is correct. Confirmed. I have given it the wrong-code keyword because it is likely to be true and to raise this out of the noise. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2009-04-07 09:23:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39576
[Bug fortran/39670] dollar sign in entities is not recognized when it is first symbol
--- Comment #4 from dominiq at lps dot ens dot fr 2009-04-07 10:18 --- Note that '$a' is also rejected by g77. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39670
[Bug c/39671] solaris 10 with gcc 3.4.3
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2009-04-07 10:08 --- also try to compile by gcc comman ... the famous hello word program.. $ gcc -c -Wall -D_GNU_SOURCE abhi.c -o abhi.o $ gcc -c abhi.o abhi.c gcc: abhi.o: linker input file unused because linking not done .. have tried all possible fixes gcc -o abhi abhi.o -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39671
[Bug c++/39674] New: Error compiling with SUN cc compiler
When trying to build on Sparc/Sun-Solaris 2.8 with cc command from SUN Forte 6.2, we have compilation error because of assignation between const and non const variables. I have patched the source code with problem (2 files) in order to compile it. The patch file is joined with this bug report to allow you to analyze it. -- Summary: Error compiling with SUN cc compiler Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Philippe dot Poilbarbe at cls dot fr GCC build triplet: sparc-sun-solaris2.8-gcc GCC host triplet: sparc-sun-solaris2.8-gcc GCC target triplet: sparc-sun-solaris2.8-gcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39674
[Bug c++/39674] Error compiling with SUN cc compiler
--- Comment #1 from Philippe dot Poilbarbe at cls dot fr 2009-04-07 13:03 --- Created an attachment (id=17599) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17599action=view) Modofed source files in order to compile on Sun/Solaris 2.8 with forte 6.2 C compiler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39674
[Bug tree-optimization/39675] New: [4.4 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-transform.c:1999
typedef struct {
float vertexAttrib[16][4];
float vertexAttribPre[16][4];
float rasterAttrib[16][4];
float rasterAttribPre[16][4];
} CRCurrentState;
void crStateCurrentInit(CRCurrentState *c)
{
unsigned int i;
for (i = 0; i 16; i++)
{
(c-vertexAttribPre[i])[0] = (c-vertexAttrib[i])[0];
(c-vertexAttribPre[i])[1] = (c-vertexAttrib[i])[1];
(c-vertexAttribPre[i])[2] = (c-vertexAttrib[i])[2];
(c-vertexAttribPre[i])[3] = (c-vertexAttrib[i])[3];
(c-rasterAttrib[i])[0] = (c-vertexAttrib[i])[0];
(c-rasterAttrib[i])[1] = (c-vertexAttrib[i])[1];
(c-rasterAttrib[i])[2] = (c-vertexAttrib[i])[2];
(c-rasterAttrib[i])[3] = (c-vertexAttrib[i])[3];
(c-rasterAttribPre[i])[0] = (c-vertexAttrib[i])[0];
(c-rasterAttribPre[i])[1] = (c-vertexAttrib[i])[1];
(c-rasterAttribPre[i])[2] = (c-vertexAttrib[i])[2];
(c-rasterAttribPre[i])[3] = (c-vertexAttrib[i])[3];
}
}
gcc-4.4 -S bug492696.3.i -o /dev/null -O3
bug492696.3.i: In function crStateCurrentInit:
bug492696.3.i:7: internal compiler error: in vect_get_vec_def_for_operand, at
tree-vect-transform.c:1999
Please submit a full bug report,
with preprocessed source if appropriate.
It looks like the vectorizer gets confused by predictive commoning
(-fno-predictive-commoning fixes this). On trunk FRE already optimizes
the redundant loads so no SSA_NAME copies rename (which appearantly
confuse the vectorizer):
# VUSE SMT.11_58
D.1603_6 = c_5(D)-vertexAttrib[i_57][0];
c___vertexAttribc__I_I_I_lsm0.28_56 = D.1603_6;
...
D.1603_18 = c___vertexAttribc__I_I_I_lsm0.28_56;
# SMT.11_47 = VDEF SMT.11_46
c_5(D)-rasterAttrib[i_57][0] = D.1603_18;
--
Summary: [4.4 Regression] ICE in vect_get_vec_def_for_operand, at
tree-vect-transform.c:1999
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39675
[Bug tree-optimization/39675] [4.4 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-transform.c:1999
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39675
[Bug c++/39674] Error compiling with SUN cc compiler
--- Comment #2 from paolo dot carlini at oracle dot com 2009-04-07 13:13 --- This Bugzilla is for *GCC*, which has nothing to do with the Sun compiler. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39674
[Bug libstdc++/39676] New: std::result_of doesn't work
--8--
#include functional
int fn(long, float) {
return 0;
}
int main(int argc, char *argv[]) {
typedef std::result_ofdecltype(fn)::type type;
return 0;
}
--8--
$ g++ -std=c++0x testcase.cpp
In file included from
/opt/gcc-4.4.0-trunk/lib/gcc/i686-pc-cygwin/4.4.0/include/
c++/functional:75,
from testcase.cpp:2:
/opt/gcc-4.4.0-trunk/lib/gcc/i686-pc-cygwin/4.4.0/include/c++/tr1_impl/functiona
l: In instantiation of 'std::_Result_of_implfalse, int ()(long int, float)':
/opt/gcc-4.4.0-trunk/lib/gcc/i686-pc-cygwin/4.4.0/include/c++/tr1_impl/functiona
l:154: instantiated from 'std::result_ofint ()(long int, float)'
testcase.cpp:13: instantiated from here
/opt/gcc-4.4.0-trunk/lib/gcc/i686-pc-cygwin/4.4.0/include/c++/tr1_impl/functiona
l:200: error: 'int' is not a class, struct, or union type
gcc used is:
$ gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../configure --prefix=/opt/gcc-4.4.0-trunk -v
--enable-bootstra
p --enable-version-specific-runtime-libs --enable-static --enable-shared
--enabl
e-shared-libgcc --with-gnu-ld --with-gnu-as --enable-sjlj-exceptions
--enable-la
nguages=c,c++ --disable-symvers --enable-libjava --disable-nls
--with-cpu-32=cor
e2 --with-cpu-64=core2 --enable-threads=posix
Thread model: posix
gcc version 4.4.0 20090309 (experimental) (GCC)
--
Summary: std::result_of doesn't work
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: WinXP/x86/Cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-07 13:19 --- Note that *most* of the facilities in functional are still following the TR1 specifications, thus, in general, do not expect conformance to the latest C++0x draft (or file a DR for each unimplemented behavior ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug c++/39674] Error compiling with SUN cc compiler
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-07 13:20 --- But the patch is against gcc and we support building with other host compilers. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39674
[Bug c/39673] internal compiler error: in fold_binary, at fold-const.c:9642
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-07 13:20 --- We need preprocessed source to reproduce the bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39673
[Bug c++/39674] Error compiling with SUN cc compiler
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-07 13:22 --- Ah, by *compile* they mean *building* GCC iself ;) Ok, then this PR should be tweaked quite a bit (C++?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39674
[Bug c++/39674] Error compiling with SUN cc compiler
--- Comment #5 from Philippe dot Poilbarbe at cls dot fr 2009-04-07 13:25 --- Yes, but building GCC (as said) with Sun compiler (or other) has to do with GCC. (In reply to comment #2) This Bugzilla is for *GCC*, which has nothing to do with the Sun compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39674
[Bug c/39635] [avr] integer wrong code bug
--- Comment #3 from wvangulik at xs4all dot nl 2009-04-07 13:26 ---
(In reply to comment #2)
The problem is it uses R22 as loop counter and as the shift counter. I could
not (yet) reproduce the problem in a smaller example.
This is my minimal test case:
static uint16_t
safe_lshift_func_uint16_t_u_u(uint16_t _left, unsigned int _right)
{
return _left _right;
}
char func_7 (uint8_t p_8)
{
if(safe_lshift_func_uint16_t_u_u (p_8, p_8))
{
return 0;
}
return 1;
}
Not using the function but shifting it directly solves the problem in this
case. It seems to me this problem is triggered when the function is inlined.
Note that this also fails for 4.1.2, 4.2.2, 4.3.0 and 4.3.2. (WinAvr20070525,
20071221, 20080610, 20081205)
This could be the same problem as:
http://lists.gnu.org/archive/html/avr-gcc-list/2009-03/msg00203.html
or
http://lists.gnu.org/archive/html/avr-gcc-list/2009-03/msg00158.html
; (insn 16 15 17 main.c:24 (set (reg/v:HI 22 r22 [orig:42 _left ] [42])
; (ashift:HI (reg/v:HI 22 r22 [orig:42 _left ] [42])
; (reg:QI 22 r22 [orig:54 _right.2 ] [54]))) 54 {ashlhi3}
(expr_list:REG_DEAD (reg:QI 18 r18 [orig:54 _right.2 ] [54])
; (expr_list:REG_UNUSED (reg:QI 23 r23)
; (nil
rjmp 2f ; 16 ashlhi3/1 [length = 6]
1: lsl r22
rol r23
2: dec r22
brpl 1b
An other interresting point is the rtl stating reg 23 is unused. Unfortunatly
the avr backend can not remove the useless shift. But that is another issue.
--
wvangulik at xs4all dot nl changed:
What|Removed |Added
CC||wvangulik at xs4all dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39635
[Bug c++/39674] Error compiling with SUN cc compiler
--- Comment #6 from paolo dot carlini at oracle dot com 2009-04-07 13:28 --- Yes, but please fix your report: the issue has nothing to do with c++, I guess. Also Host / Target / Build should likely be just sparc-sun-solaris2.8, no? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39674
[Bug c/39671] solaris 10 with gcc 3.4.3
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-04-07 13:29 --- There should not be any difference as i directed cc to gcc Your bug. The Makefile expects Sun CC since it uses Sun CC options. So you need to use Sun CC. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39671
[Bug middle-end/39677] AMD Opteron E needs workaround for lock erratum
--- Comment #1 from bonzini at gnu dot org 2009-04-07 13:42 --- More info from Solaris bug # 6323525: if (number_of_cores() 2) then don't have bug if (family == 0xf Model 0x40) then have bug if (rdmsr(MSR_BU_CFG/*0xC0011023*/) 2) then bug is masked See also http://bugzilla.kernel.org/show_bug.cgi?id=11305 -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-07 13:42:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39677
[Bug c++/39674] Error building with SUN cc (forte 6.2) compiler
--- Comment #7 from Philippe dot Poilbarbe at cls dot fr 2009-04-07 13:35 --- (In reply to comment #6) Yes, but please fix your report: the issue has nothing to do with c++, I guess. Also Host / Target / Build should likely be just sparc-sun-solaris2.8, no? I don't know if it is C++, I am not very aware of this; the files involved are: gcc/fixed-value.c and gcc/tree-ssa-loop-ivopts.c I saw compilation errors on this files and tried to fix it: it was only assignment errors (there is many other warnings about assignment error). I only said that it is gcc (built for c, c++ and fortran languages only) and I don't know which part of the gcc suite they belong to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39674
[Bug fortran/39670] dollar sign in entities is not recognized when it is first symbol
--- Comment #5 from burnus at gcc dot gnu dot org 2009-04-07 13:43 --- Many compilers support $ signs as extension (ISO standard Fortran does not). However, only a few support a leading $ sign. One of the questions which immediately come up, which data type is $foo (implicit typing). I think the issue had come up before and the PRs were closed as wont-fix. This can of cause be reconsidered, but implicit typing is a real issue here. (In reply to comment #2) As I already said, I have code, being compiled with MS Fortran, that has a lot of variable names starting with $. MS Fortran allows it. My personal opinion is that the Fortran compiler's primary use is support of the legacy code. That means that the implementation of any extension or even strange behaviour of existing compilers could be useful and will save hours of hard work. Forcing standards on existing code is illogical. I full-heartedly disagree. I think the primary point of a compiler is to be standard compliant. It does not help if I have to use extension A with compiler B and C, but extension E with compiler F while compiler G does not have a feature at all and H's syntax is like B's but it does something differently. - My impression is that nowadays all compiler vendors and most of the compiler customers think likewise. (Still, supporting some old vendor extension is seen as important by both.) There exists enough newly written software, updated and also old software which is standard compliant - and thus also requires that the compiler is compliant. Having said that I don't oppose to suppose vendor extensions, given that they (a) don't clash with the standard [though difficult to predict with regards to the future standards], (b) are reasonably widely used and (c) cannot easily be replaced by something standard conform. (The [long-term] implementation burden can be potentially large even for a seemingly simple addition.) For '$' as first (!) character I think (a) is fulfilled, (b) and (c) probably not. I think gfortran does fairly well in this regard compared with other compilers, except of DEC structures all major extensions should be there. One big issue with vendor extensions is that there is a huge number of them - and some even conflict with each other! Do you want to support the one of Microsoft, or of IBM, or of Intel, Digital, Sun, SGI, Cray, Pathscale, Portland Group, Absoft, Fujisu, g77, f2c, ...? And for vendor X - the of of version 4.0 or the one of 5.0 or ...? implementation of [...] even strange behaviour [...] will save hours of hard work. I sincerely doubt that. I think it will cause a lot of time for application developers and will lead to strange bugs. Relying on strange behaviour can also bite you if it was unintended and was then fixed in a new version of the same compiler. Nevertheless, one can re-consider the $ but the implicit typing issue has to be solved. It would help if you could make a survey (e.g. based on the documentation) and see how the few other compilers, which support it, are handling that. (I think IBM does, the xlf90 documentation could be a starting point.) By posting the result you show (a) how implicit typing is handled which is essential, (b) you proof that that is a feature supported by several vendors and (c) you show that you are really interested in that feature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39670
[Bug c/39671] solaris 10 with gcc 3.4.3
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2009-04-07 13:38 --- Thanks a lot , Is there any workaround for this problem,Becouse SunCC compiler is paid. You need to read the documentation of the software you're trying to build and see whether GCC is supported; if so, follow the instructions; if not, you need to install Sun CC. Please let me know from where I can easly get Sun CC compiler. http://www.sun.com -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39671
[Bug c++/39678] New: std::transform is incorrect with std::multiples and bind2nd for complexfloat
The code shown below works nicely when compiled with -O2 or -O2 -g.
However, it fails when compiled with -g, but only for std::complexfloat. For
the other types it works well. Valgrind gives piles of uninitialized value
errors.
The same results are obtained when building on other Linux platforms. Also hen
using bind1st the same problems arise.
It works well with g++-3.4.3 though.
Cheers,
Ger
#include iostream
#include vector
#include algorithm
#include complex
templatetypename TYPE
void testIt()
{
std::vectorTYPE vecc(2, TYPE(2.));
std::vectorTYPE result(2);
// Test vector * scalar.
std::transform (vecc.begin(), vecc.end(), result.begin(),
bind2nd(std::multipliesTYPE(), TYPE(5.)));
std::cout result[0] ' ' result[1] std::endl;
}
int main()
{
testItdouble();
testItfloat();
testItstd::complexfloat ();
testItstd::complexdouble ();
}
--
Summary: std::transform is incorrect with std::multiples and
bind2nd for complexfloat
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: diepen at astron dot nl
GCC build triplet: c++ -Wall -g tac.cc
GCC host triplet: Linux dop131 2.6.27.19-3.2-default #1 SMP 2009-02-25
15:40:44 +0
GCC target triplet: same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug c++/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-07 13:54 --- Explain what do you mean by fails. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug middle-end/39677] New: AMD Opteron E needs workaround for lock erratum
From
http://code.google.com/p/google-perftools/source/browse/trunk/src/base/atomicops-internals-x86.h
bool has_amd_lock_mb_bug; // Processor has AMD memory-barrier bug; do lfence
// after acquire compare-and-swap.
...
inline Atomic32 NoBarrier_CompareAndSwap(volatile Atomic32* ptr,
Atomic32 old_value,
Atomic32 new_value) {
Atomic32 prev;
__asm__ __volatile__(lock; cmpxchgl %1,%2
: =a (prev)
: q (new_value), m (*ptr), 0 (old_value)
: memory);
return prev;
}
inline Atomic32 Acquire_CompareAndSwap(volatile Atomic32* ptr,
Atomic32 old_value,
Atomic32 new_value) {
Atomic32 x = NoBarrier_CompareAndSwap(ptr, old_value, new_value);
if (AtomicOps_Internalx86CPUFeatures.has_amd_lock_mb_bug) {
__asm__ __volatile__(lfence : : : memory);
}
return x;
}
inline Atomic32 Release_CompareAndSwap(volatile Atomic32* ptr,
Atomic32 old_value,
Atomic32 new_value) {
return NoBarrier_CompareAndSwap(ptr, old_value, new_value);
}
This bug can also affect lock+xadd combinations.
--
Summary: AMD Opteron E needs workaround for lock erratum
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: i386-*-*, x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39677
[Bug c/39671] solaris 10 with gcc 3.4.3
--- Comment #6 from abhinav dot dubey at hcl dot in 2009-04-07 13:34 --- (In reply to comment #5) There should not be any difference as i directed cc to gcc Your bug. The Makefile expects Sun CC since it uses Sun CC options. So you need to use Sun CC. Thanks a lot , Is there any workaround for this problem,Becouse SunCC compiler is paid. Please let me know from where I can easly get Sun CC compiler. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39671
[Bug c++/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #2 from diepen at astron dot nl 2009-04-07 14:03 --- The output does not show the correct results. It looks as if the imaginary part of the complex number in the bind2nd object is incorrect. When debugging the bind2nd object was constructed correctly, but when used in std::transform its value was incorrect, in particular the imaginary part seems to be uninitialized (as also reported by valgrind). As I said, this only happens for complexfloat, not for complexdouble. Originally I used my own Multiplies functor to multiply a float vector with a complexfloat value and that failed similarly. But it appears to happen for the simpler case as shown in my test program too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #2 from piotr dot wyderski at gmail dot com 2009-04-07 14:05
---
(In reply to comment #1)
Note that *most* of the facilities in functional are still following the TR1
specifications, thus, in general, do not expect conformance to the latest
C++0x
draft (or file a DR for each unimplemented behavior ;)
The only C++0x functionality involved I am aware of is decltype,
which is outside of the template scope. BTW,
boost::function_traits...::result_type
works flawlessly. Here is a simplified testcase:
#include functional
int main(int argc, char *argv[]) {
typedef std::result_ofint (long, float)::type type;
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug c++/39679] New: Some absent attributes in the tree-dump should be added
Hi, I'am one of the lead developers from Linux Verification Center
(http://www.linuxtesting.org/) at ISPRAS in Russia. Last several years we make
instruments for linux testing along with the Linux Foundation
(http://linuxfoundation.org/) under the LSB-Infrastructure project. Some our
instruments use gcc as a parser through the command g++
-fdump-translation-unit. Dump that gcc creates by this command doesn't contain
some necessary things and we have to add some changes to the sources of gcc and
recompile it. We consider that some of these changes may be useful for other
users of gcc. Following patch for file dump.c from gcc sources contains a few
additional code that adds to the resulting dump useful function attributes:
inline, volatile, const.
--- dump.c 2007-08-02 14:36:13.0 +0400
+++ dump.c 2009-04-07 14:34:14.0 +0400
@@ -297,6 +297,15 @@
case FUNCTION_DECL:
if (!DECL_THUNK_P (t))
{
+ /* Dump whether function is const. */
+ if (DECL_CONST_MEMFUNC_P(t))
+ dump_string_field(di, qual, c);
+ /* Dump whether function is volatile. */
+ if (DECL_VOLATILE_MEMFUNC_P(t))
+ dump_string_field(di, qual, v);
+ /* Dump whether function is inline. */
+ if (DECL_DECLARED_INLINE_P(t))
+ dump_string_field (di, note, inline);
if (DECL_OVERLOADED_OPERATOR_P (t)) {
dump_string_field (di, note, operator);
dump_op (di, t);
--
Summary: Some absent attributes in the tree-dump should be added
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: susanin at ispras dot ru
GCC build triplet: independent
GCC host triplet: independent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39679
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #3 from paolo dot carlini at oracle dot com 2009-04-07 14:11 --- Are you *really* sure the simplified testcase was supposed to work per the TR1 specifications? The author of thar code is Doug Gregor, and it never did in GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug c++/39679] Some absent attributes in the tree-dump should be added
--- Comment #1 from susanin at ispras dot ru 2009-04-07 14:13 --- Created an attachment (id=17600) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17600action=view) This patch add some absent function attributes to the tree-dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39679
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-07 14:15 --- I'm looking at 3.4/3 in n1836, and my answer is *no*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug c++/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #3 from paolo dot carlini at oracle dot com 2009-04-07 14:17 --- Yes, you are right. Apparently some sort of miscompilation. The problem does not happen when using the C++ runtime + a different C++ compiler, by the way. Let's look further into it... The other possibility is that you are triggering somehow an undefined behavior... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug c++/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-07 14:23 --- Richard, can I have your opinion about this? Thanks in advance! -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug c++/39680] New: unary_function...::result_type cannot be void.
Hi everyone
The following code cannot pass compilation by g++ v4.3.2.
#include functional
#include algorithm
#include iostream
#include string
#include memory
#include vector
using namespace std;
class test
{
public:
void func(int i) { wcout i L: test\n; }
};
namespace
{
templateclass T
class destroyer : public unary_functionT, void
{
public:
using typename unary_functionT, void::result_type;
using typename unary_functionT, void::argument_type;
public:
typename unary_functionT, void::result_type operator()(typename
unary_functionT, void::argument_type pointer)
{
delete pointer;
}
};
}
int main()
{
vectortest * data;
for (int i = 0; i 5; ++i)
data.push_back(new test);
for_each(data.begin(), data.end(), bind2nd(mem_fun(test::func), 0));
for_each(data.begin(), data.end(), destroyervectortest *::value_type());
return 0;
}
The error message is quite vague:
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MFsrc/Test_Cplusplus.d
-MTsrc/Test_Cplusplus.d -osrc/Test_Cplusplus.o ../src/Test_Cplusplus.cpp
../src/Test_Cplusplus.cpp: In instantiation of ¡®unnamed::destroyertest*¡¯:
../src/Test_Cplusplus.cpp:49: instantiated from here
../src/Test_Cplusplus.cpp:25: internal compiler error: in
dwarf2out_imported_module_or_decl, at dwarf2out.c:14261
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.opensuse.org/ for instructions.
make: *** [src/Test_Cplusplus.o] error 1
However, if the result_type is not void, the code can be compiled
successfully. Does this behavior conform to the standard?
--
Summary: unary_function...::result_type cannot be void.
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jim_king_2000 at 163 dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39680
[Bug c++/39680] ICE with -g3
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-07 14:30:14 date|| Summary|unary_function...::result_|ICE with -g3 |type cannot be void.| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39680
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #5 from piotr dot wyderski at gmail dot com 2009-04-07 14:31 --- So it is a purely C++0x bug, as you indicated in your first reply. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug c++/39680] ICE with -g3
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-07 14:33 --- Current mainline is fine. I can reproduce on x86_64-linux with 4_3-branch and 4_4-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39680
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #6 from paolo dot carlini at oracle dot com 2009-04-07 14:34 --- Yes, a purely unimplemented C++0x feature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug libstdc++/39652] Trouble with new random bits
--- Comment #2 from paolo dot carlini at oracle dot com 2009-04-07 14:45 --- Is this still an issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39652
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #7 from jwakely dot gcc at gmail dot com 2009-04-07 14:45 --- I think you have the syntax wrong, if you want to know the return type of a function type (or function pointer, or function reference) you need to say: result_ofint (*(long, float))(long ,float)::type what you probably want is: typedef int (*func_ptr)(long, float); result_offunc_ptr(long, float):type -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug c++/39680] ICE with -g3
--- Comment #2 from axel-freyn at gmx dot de 2009-04-07 14:45 --- Created an attachment (id=17601) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17601action=view) shorter testcase testcase sufficient for ICE on gcc version 4.3.2 (Debian 4.3.2-1.1), Target: x86_64-linux-gnu -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39680
[Bug fortran/39670] dollar sign in entities is not recognized when it is first symbol
--- Comment #6 from kargl at gcc dot gnu dot org 2009-04-07 14:46 --- (In reply to comment #2) As I already said, I have code, being compiled with MS Fortran, that has a lot of variable names starting with $. MS Fortran allows it. My personal opinion is that the Fortran compiler's primary use is support of the legacy code. That means that the implementation of any extension or even strange behaviour of existing compilers could be useful and will save hours of hard work. Forcing standards on existing code is illogical. In other words, you want to shift the hard work of implementing all of these extensions on the compiler writer. Sorry, but is illogical particular when there is only 5 or so people writing the compiler when they can some up with some free time. Learn how to use sed and globally replace $ with whatever string you want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39670
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #8 from paolo dot carlini at oracle dot com 2009-04-07 14:47 --- Yes, that would work, we even have testcases for it. But what about C++0x, Jonathan? Seems strange that only that more convoluted syntax is right... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #9 from jwakely dot gcc at gmail dot com 2009-04-07 14:51 --- This is not a bug in C++0x either. The spec is: Given an rvalue fn of type Fn and values t1, t2, ..., tN of types T1, T2, ..., TN in ArgTypes, respectively, the type member is the result type of the expression fn(t1, t2, ...,tN). So the original testcase has Fn=int and tries to find the result of calling int as a function, which is invalid. The original testcase should be: typedef std::result_ofdecltype(fn) (long, float)::type type; which tells you the result of invoking something of type decltype(fn) with arguments of type long and float. Or, to see what happens if you pass it other types: typedef std::result_ofdecltype(fn) (int, double)::type type; This tells you the result of calling e.g. f(0, 0.0), which will result in the arguments being implicitly converted, and as it's a simple function not a function object or other callable type with multiple overloads, the result is always 'int' I believe this is not a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-07 14:51 ---
The expected output is
10 10
10 10
(10,0) (10,0)
(10,0) (10,0)
correct? With -O0 I get
10 10
10 10
(nan,nan) (nan,nan)
(10,0) (10,0)
while for -m32 it is ok. So it appears only the float variant is affected?
Thus, reduced testcase:
#include vector
#include algorithm
#include complex
extern C void abort(void);
int main()
{
std::vectorstd::complexfloat vecc(2, std::complexfloat(2.));
std::vectorstd::complexfloat result(2);
// Test vector * scalar.
std::transform (vecc.begin(), vecc.end(), result.begin(),
bind2nd(std::multipliesstd::complexfloat (),
std::complexfloat(4.)));
if (result[0].real() != 8.
|| result[0].imag() != 0.
|| result[1].real() != 8.
|| result[1].imag() != 0.)
abort ();
return 0;
}
fails for me at -O0 and -O1 in 64bits.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |target
Ever Confirmed|0 |1
Keywords||wrong-code
Known to fail||4.3.3 4.4.0
Last reconfirmed|-00-00 00:00:00 |2009-04-07 14:51:42
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug fortran/39670] dollar sign in entities is not recognized when it is first symbol
--- Comment #7 from kargl at gcc dot gnu dot org 2009-04-07 14:54 --- (In reply to comment #5) Many compilers support $ signs as extension (ISO standard Fortran does not). However, only a few support a leading $ sign. One of the questions which immediately come up, which data type is $foo (implicit typing). I think the issue had come up before and the PRs were closed as wont-fix. This can of cause be reconsidered, but implicit typing is a real issue here. Yes, that is the reason previous PRs were closed. I suppose Alexander will counter that we should do whatever MS Fortran did with implicit typing. This may have been a compelling argument except that MS Fortran hasn't been sold in the last 15 years or so. This sould be closed with WONTFIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39670
[Bug middle-end/39677] AMD Opteron E needs workaround for lock erratum
--- Comment #2 from bonzini at gnu dot org 2009-04-07 15:02 --- I cannot see any better alternative, but I'll point out that saying wrong-code is not exact. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39677
[Bug libstdc++/39652] Trouble with new random bits
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-07 15:08 --- Well, *cannot* be still an issue exactly in these terms, because there are no log2* functions any more in the code... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39652
[Bug tree-optimization/39672] Local statics not promoted to const
--- Comment #3 from hubicka at ucw dot cz 2009-04-07 15:14 --- Subject: Re: Local statics not promoted to const I think it only adjusts global statics. This is why I originally implemented varpool to have both local and global static alike, so it should not. Well, time to debug it ;) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39672
[Bug target/39386] [avr] different computation results for O1 and O0 executables
--- Comment #4 from eric dot weddington at atmel dot com 2009-04-07 15:18 --- *** Bug 39635 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39386
[Bug target/39635] [avr] integer wrong code bug
--- Comment #4 from eric dot weddington at atmel dot com 2009-04-07 15:18 --- This looks like a duplicate of bug #39386. *** This bug has been marked as a duplicate of 39386 *** -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39635
[Bug target/39386] [avr] different computation results for O1 and O0 executables
--- Comment #5 from eric dot weddington at atmel dot com 2009-04-07 15:23 --- Adding additional version numbers in the known-to-fail field from comment in duplicate bug #39635. Still waiting to hear if bug is present in 4.4. -- eric dot weddington at atmel dot com changed: What|Removed |Added CC||wvangulik at xs4all dot nl GCC host triplet|i686-pc-linux-gnu | Keywords||wrong-code Known to fail|4.3.3 4.3.2 |4.3.3 4.3.2 4.1.2 4.2.2 ||4.3.0 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39386
[Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-07 15:29 ---
Minor data point (-O1 -g):
movss 4(%rbx), %xmm3
movss (%rbx), %xmm2
movss (%rsp), %xmm1
movss 4(%rsp), %xmm0
call__mulsc3
Breakpoint 1, 0x77667990 in __mulsc3 () from /lib64/libgcc_s.so.1
(gdb) p $xmm0
$1 = {v4_float = {4, 0, 0, 0}, v2_double = {5.3464347077054713e-315, 0},
v16_int8 = {0, 0, -128, 64, 0 repeats 12 times}, v8_int16 = {0, 16512, 0,
0, 0, 0, 0, 0}, v4_int32 = {1082130432, 0, 0, 0}, v2_int64 = {1082130432,
0}, uint128 = 0x4080}
(gdb) p $xmm1
$2 = {v4_float = {2.24207754e-44, 0, 0, 0}, v2_double = {
7.9050503334599447e-323, 0}, v16_int8 = {16, 0 repeats 15 times},
v8_int16 = {16, 0, 0, 0, 0, 0, 0, 0}, v4_int32 = {16, 0, 0, 0}, v2_int64 = {
16, 0}, uint128 = 0x0010}
(gdb) p $xmm2
$3 = {v4_float = {2, 0, 0, 0}, v2_double = {5.3049894774131808e-315, 0},
v16_int8 = {0, 0, 0, 64, 0 repeats 12 times}, v8_int16 = {0, 16384, 0, 0,
0, 0, 0, 0}, v4_int32 = {1073741824, 0, 0, 0}, v2_int64 = {1073741824, 0},
uint128 = 0x4000}
(gdb) p $xmm3
$4 = {v4_float = {0, 0, 0, 0}, v2_double = {0, 0}, v16_int8 = {
0 repeats 16 times}, v8_int16 = {0, 0, 0, 0, 0, 0, 0, 0}, v4_int32 = {0,
0, 0, 0}, v2_int64 = {0, 0}, uint128 = 0x}
thus xmm1 is garbled.
marking the specific std::transform always_inline fixes the issue. The
arguments to that transform are already garbled:
__unary_op=
{std::unary_functionstd::complexfloat, std::complexfloat =
{No data fields}, op = {std::binary_functionstd::complexfloat,
std::complexfloat, std::complexfloat = {No data fields}, No data
fields}, value = {_M_value = 4 + -3.60319284e+33 * I}
Marking std::bind2nd noinline makes it fail at -O2 as well, its arguments
look good:
(gdb) p __x
$1 = (const std::complexfloat ) @0x7fffde10: {_M_value = 4 + 0 * I}
but its assembly looks weird:
_ZSt7bind2ndISt10multipliesISt7complexIfEES2_ESt9binder2ndIT_ERKS5_RKT0_:
.LFB1710:
.file 1 /usr/include/c++/4.4/backward/binders.h
.loc 1 164 0
.cfi_startproc
.LVL0:
.loc 1 167 0
movl(%rsi), %edx
movl4(%rsi), %eax
movl%edx, -20(%rsp)
movl%eax, -16(%rsp)
.loc 1 168 0
movq-24(%rsp), %xmm0
ret
so the error seems to be in the source or compilation of
std::bind2ndstd::multipliesstd::complexfloat , std::complexfloat
Paolo, can you provide an idea on how the result type of that looks like?
(I'm lost in the headers ... ;))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #8 from paolo dot carlini at oracle dot com 2009-04-07 15:32 --- Ok, give me a few minutes, I'm going to dig a bit further... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug c++/39681] New: Compile error is not descriptive
Note: This enhancement request (in my opinion) is related with the compiler
frontend (of C++ and probably also C) and can be applied to all platforms.
Given a .cpp file (3 lines below only, nothing else);
int main()
{
int* p = new foo;
}
When tried to compile gives the following error:
error: expected type-specifier before #8216;foo#8217;
error: expected #8216;,#8217; or #8216;;#8217; before #8216;foo#8217;
Which is not descriptive.
Something like;
error: #8216;foo#8217; was not declared in this scope
would be better, and consistent with the error report of the compilation of;
int main()
{
foo i;
}
--
Summary: Compile error is not descriptive
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: emreturkay at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39681
[Bug c++/39681] Compile error is not descriptive
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-07 15:37 --- FWIW, the EDG C++ front-end issues a very similar error message ;) 39681.C(3): error: expected a type specifier int* p = new foo; ^ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39681
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #12 from jwakely dot gcc at gmail dot com 2009-04-07 15:40 --- See what I wrote at http://gcc.gnu.org/ml/libstdc++/2008-09/msg00124.html under point 3) You want this: typename std::result_of decltype(traitsT::restore) (S*) ::type Paolo, let's close this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #13 from jwakely dot gcc at gmail dot com 2009-04-07 15:42 --- (In reply to comment #12) typename std::result_of decltype(traitsT::restore) (S*) ::type Oops, that should be S not S* It's not perfect, but for this case std::result_of works if you get the syntax right :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-04-07 15:44 ---
Wait - it's ok.
class binder2nd
: public unary_functiontypename _Operation::first_argument_type,
typename _Operation::result_type
{
protected:
_Operation op;
typename _Operation::second_argument_type value;
_Operation is probably empty, so there are 4 bytes padding and the struct
is returned in a xmm0
(gdb) p $xmm0
$5 = {v4_float = {-9.04046813e+33, 4, 0, 0}
but we access the result like
call
_ZSt7bind2ndISt10multipliesISt7complexIfEES2_ESt9binder2ndIT_ERKS5_RKT0_
movl72(%rsp), %edx
movq%xmm0, 8(%rsp)
movq8(%rsp), %rax
movl%edx, 88(%rsp)
movq%rax, 80(%rsp)
movss 88(%rsp), %xmm5
movq%rax, 64(%rsp)
movss 84(%rsp), %xmm4
movq%rax, 96(%rsp)
movl%edx, 104(%rsp)
.loc 5 1144 0
movaps %xmm4, %xmm0
movaps %xmm5, %xmm1
movss 4(%rbx), %xmm3
movss (%rbx), %xmm2
movss %xmm4, 32(%rsp)
movss %xmm5, 16(%rsp)
call__mulsc3
movq%xmm0, 56(%rsp)
movl56(%rsp), %eax
movl60(%rsp), %edx
so you can see we simply use the lower 8 bytes of %xmm0 only ...
(supposedly thinking that the other half got loaded to %edx).
It's already broken at expansion:
(call_insn 67 66 68 11 t.C:13 (set (parallel:BLK [
(expr_list:REG_DEP_TRUE (reg:DI 21 xmm0)
(const_int 0 [0x0]))
])
(call (mem:QI (symbol_ref/i:DI
(_ZSt7bind2ndISt10multipliesISt7complexIfEES2_ESt9binder2ndIT_ERKS5_RKT0_)
[flags 0x1] function_decl 0x74887d00 bind2nd) [0 S1 A8])
(const_int 0 [0x0]))) -1 (expr_list:REG_EH_REGION (const_int 0
[0x0])
(nil))
(expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
(expr_list:REG_DEP_TRUE (use (reg:DI 4 si))
(nil
(insn 68 67 69 11 t.C:13 (set (reg:DI 92)
(reg:DI 21 xmm0)) -1 (nil))
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet|same|x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #14 from paolo dot carlini at oracle dot com 2009-04-07 15:45 --- Agreed ;) -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-04-07 15:45 --- It seems to be an ABI mismatch in the backend somehow. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|c++ -Wall -g tac.cc| GCC host triplet|Linux dop131 2.6.27.19-3.2- | |default #1 SMP 2009-02-25 | |15:40:44 +0 | Keywords||ABI http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-04-07 15:46 --- Created an attachment (id=17603) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17603action=view) preprocessed testcase with bind2nd marked noinline Testcase, look at the compiled piece for the call to _ZSt7bind2ndISt10multipliesISt7complexIfEES2_ESt9binder2ndIT_ERKS5_RKT0_ (which is marked noinline here). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug libstdc++/39676] std::result_of doesn't work
--- Comment #15 from piotr dot wyderski at gmail dot com 2009-04-07 15:47 --- Subject: Re: std::result_of doesn't work jwakely dot gcc at gmail dot com gcc-bugzi...@gcc.gnu.org: You want this: typename std::result_of decltype(traitsT::restore) (S*) ::type Thank you! :-) Paolo, let's close this. Agreed. :-) Best regards, Piotr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39676
[Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #12 from paolo dot carlini at oracle dot com 2009-04-07 15:48 --- You are too fast ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-04-07 15:57 --- The intel compiler generates ..___tag_value__ZSt7bind2ndISt10multipliesISt7complexIfEES2_ESt9binder2ndIT_ERKS5_RKT0_.69: #165.5 movq (%rsi), %rax #167.53 movss 4(%rsi), %xmm1#167.53 movq %rax, -20(%rsp) #167.42 movsd -24(%rsp), %xmm0 #167.14 ..___tag_value__ZSt7bind2ndISt10multipliesISt7complexIfEES2_ESt9binder2ndIT_ERKS5_RKT0_.70: #167.14 ret and call _ZSt7bind2ndISt10multipliesISt7complexIfEES2_ESt9binder2ndIT_ERKS5_RKT0_ #13.68 # LOE rbx r12 r13 xmm0 xmm1 ..B1.35:# Preds ..B1.11 movlps%xmm0, 48(%rsp) #13.68 movss %xmm1, 56(%rsp) so it's at least consistent -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-04-07 16:04
---
With a small testcase it works:
struct Y {};
struct X {
Y y;
float real;
float imag;
};
struct X __attribute__((noinline))
foo (float *p)
{
struct X x;
x.real = p[0];
x.imag = p[1];
return x;
}
extern C void abort (void);
int main()
{
float a[2] = { 1., 2. };
struct X x = foo(a);
if (x.real != 1.
|| x.imag != 2.)
abort ();
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail|4.1.3 4.2.5 4.3.3 4.4.0 |4.3.3 4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-04-07 16:05 --- So maybe it's a C++ FE issue after all ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #16 from paolo dot carlini at oracle dot com 2009-04-07 16:24 --- Sorry for the noise, forgot that we don't care any more about 4_1 and 4_2 ;) Anyway, the issue is apparently *very* old... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug fortran/38152] [4.4 Regression] procedure pointers as module variables
--- Comment #19 from janus at gcc dot gnu dot org 2009-04-07 16:24 --- Subject: Bug 38152 Author: janus Date: Tue Apr 7 16:24:31 2009 New Revision: 145692 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145692 Log: 2009-04-07 Janus Weil ja...@gcc.gnu.org PR fortran/38152 * trans-decl.c (gfc_get_symbol_decl): Correctly set decl location for procedure pointer decls. 2009-04-07 Janus Weil ja...@gcc.gnu.org PR fortran/38152 * gfortran.dg/proc_ptr_13.f90: Add -g option. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/proc_ptr_13.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complexfloat
--- Comment #17 from paolo dot carlini at oracle dot com 2009-04-07 16:44 --- I guess I'm going to reduce the big one with 'delta', if you have special advice about that, just let me know... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug target/35466] Different assembly codes on 32bit and 64bit hosts
--- Comment #7 from info dot gnu at rt-labs dot com 2009-04-07 16:52 --- *** Bug 39663 has been marked as a duplicate of this bug. *** -- info dot gnu at rt-labs dot com changed: What|Removed |Added CC||info dot gnu at rt-labs dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35466
[Bug target/39663] mingw hosted arm-elf output differs from linux hosted arm-elf when compiling with -Os and -mthumb
--- Comment #4 from info dot gnu at rt-labs dot com 2009-04-07 16:52 --- You're right, I tried both examples you mentioned, i'll point this to #35466 that seems to point out the problem you described about. *** This bug has been marked as a duplicate of 35466 *** -- info dot gnu at rt-labs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39663
[Bug fortran/39682] New: compiler give bus error
/opt/gcc-4.3.3/bin/gfortran -ffixed-line-length-0 -g-c -I/Volumes/Users/bmayer/Desktop/download/netcdf-4.0/f90 driver.F90 driver.F90:170.25: call write_input(crm_input_test.nc, lchnk, 1, icol, plev2, ps, pmid, 1 Warning: Character length of actual argument shorter than of dummy argument 'filename' (17/80) at (1) driver.F90: In function driver: driver.F90:168: internal compiler error: Bus error Please submit a full bug report, -- Summary: compiler give bus error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bmayer at ucar dot edu GCC build triplet: ../gcc-4.3-20070810/configure --enable-threads=posix -- enable-la GCC target triplet: i386-apple-darwin8.10.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39682
[Bug c++/25185] deep typedef substitution in error message
--- Comment #25 from jason at gcc dot gnu dot org 2009-04-07 17:49 --- Subject: Bug 25185 Author: jason Date: Tue Apr 7 17:48:52 2009 New Revision: 145697 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145697 Log: PR c++/25185 * c-common.h, c-common.c: Add flag_pretty_templates. * c-opts.c (c_common_handle_option): Set it. * c.opt: Add -fno-pretty-templates. * doc/invoke.texi (C++ Dialect Options): Likewise. * error.c (dump_function_decl): Don't pretty-print templates if -fno-pretty-templates. (count_non_default_template_args): Print all args if -fno-pretty-templates. Added: trunk/gcc/testsuite/g++.dg/template/error40.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/c-opts.c trunk/gcc/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25185
[Bug fortran/39682] compiler give bus error
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-04-07 17:51 --- Could you please attach a (ideally) minimal testcase that reproduces the error? Thanks. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org GCC build triplet|../gcc-4.3- | |20070810/configure --enable-| |threads=posix --enable-la | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39682
[Bug c++/39679] Some absent attributes in the tree-dump should be added
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-07 18:28 --- this dump file is only supposed to be used to debug gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39679
