[Bug lto/46798] [4.6 Regression] invalid conversion in gimple call; verify_stmts failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46798 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.04 15:13:47 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-04 15:13:47 UTC --- Confirmed. We can't do much about this now. I have plans for 4.7.
[Bug driver/46760] LTO bootstrap doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760 --- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2010-12-04 17:04:34 UTC --- (In reply to comment #9) Created attachment 22604 [details] Patch I am testing to allow profile merging This patch should allow merging of LTO units with different number of executions. I am testing how far I can get with lto bootstrap with this one and the pass-through I got lto1: internal compiler error: Floating point exception Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Do we have a divide by zero bug?
[Bug libfortran/46800] New: Handle CTRL-D correctly with STDIN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46800 Summary: Handle CTRL-D correctly with STDIN Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: jvdeli...@gcc.gnu.org With the given test case, on READ from STDIN, if an empty entry with LF is given first, two CTRL-D are required to terminate the read. G77 requires only one CTRL-D. number=999 30 write(6,*) 'Enter number1?' read(5,*,iostat=ios) number write(6,*) 'ios= ',ios call bs5(ios) if(ios) 20,20,10 10 write(6,*) 'Input Error' go to 30 20 write(6,*) number 60 write(6,*) 'Enter number2?' read(5,*,iostat=ios) number write(6,*) 'ios= ',ios call bs5(ios) if(ios) 50,50,40 40 write(6,*) 'Input Error' go to 60 50 write(6,*) number end subroutine bs5(ios) character *20 name if(ios.ge.0) go to 20 name=TtyNam(5) close (unit=5) open(unit=5,file=name,status='old') 20 return end
[Bug debug/46799] [4.6 Regression] -fcompare-debug failure (length) with -ftree-parallelize-loops=2 -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46799 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.12.04 17:08:54 CC||matz at suse dot de Target Milestone|--- |4.6.0 Summary|-fcompare-debug failure |[4.6 Regression] |(length) with |-fcompare-debug failure |-ftree-parallelize-loops=2 |(length) with |-fno-tree-dce |-ftree-parallelize-loops=2 ||-fno-tree-dce Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-12-04 17:08:54 UTC --- It is caused by revision 167184: http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg01074.html
[Bug driver/46760] LTO bootstrap doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2010-12-04 17:13:57 UTC --- Program received signal SIGFPE, Arithmetic exception. 0x00f6e670 in merge_profile_summaries () at /export/gnu/import/git/gcc/gcc/lto-cgraph.c:1513 1513/ node-local.lto_file_data-profile_info.run_max);
[Bug driver/46760] LTO bootstrap doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760
--- Comment #12 from H.J. Lu hjl.tools at gmail dot com 2010-12-04 17:24:28
UTC ---
(gdb) p cgraph_nodes-local.lto_file_data-profile_info
$4 = {num = 0, runs = 9409, sum_all = 0, run_max = 0, sum_max = 1302797449}
(gdb)
[Bug c/46788] unsigned int possible treated as signed in a union/struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46788 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2010-12-04 17:31:11 UTC --- I can reproduce this with FSF gcc-4.5/4.6 and binutils-2.20.1 on armv5tel-linux-gnueabi: gcc/xgcc -Bgcc -mcpu=cortex-m3 -mthumb -O2 -c MyFile.c /tmp/ccCisNkW.s: Assembler messages: /tmp/ccCisNkW.s:27: Error: immediate value out of range -- `movt r3,-32768' With gcc-4.4 the error does not occur.
[Bug driver/46760] LTO bootstrap doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #13 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-04 17:33:02 UTC --- I fixed that division bug (it is wrong way) and I can bootstrap C only, C++ still fails, this time on profile mismatches. I will commit the fixed patch. Honza
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690 --- Comment #33 from H.J. Lu hjl.tools at gmail dot com 2010-12-04 17:37:39 UTC --- This bug should be fixed with the 2 stage BFD linker patch: http://sourceware.org/ml/binutils/2010-12/msg00182.html No changes to GCC are needed.
[Bug tree-optimization/46801] New: [4.6 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized gnat_rcheck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46801 Summary: [4.6 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized gnat_rcheck Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir/gcc/gnatmake --GCC=/test/gnu/gcc/objdir/ gcc/xgcc --GNATBIND=/test/gnu/gcc/objdir/gcc/gnatbind --GNATLINK=/test/gnu/gcc/o bjdir/gcc/gnatlink -cargs -B/test/gnu/gcc/objdir/gcc -largs --GCC=/test/gnu/gcc/ objdir/gcc/xgcc\ -B/test/gnu/gcc/objdir/gcc\ -margs --RTS=/test/gnu/gcc/objdir/ hppa2.0w-hp-hpux11.11/./libada -q -f /test/gnu/gcc/gcc/gcc/testsuite/gnat.dg/pac k9.adb -O2 -gnatp -fdump-tree-optimized -c -S -o pack9.s(timeout = 300) PASS: gnat.dg/pack9.adb (test for excess errors) FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized gnat_rcheck -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.6 --with-gmp=/opt/gnu/gcc/gcc-4.6.0 --enable-threads=posix --enable-debug=no --disable-nls --without-cloog --without-ppl --enable-languages=c,c++,objc,fortran,java,ada,obj-c++ Thread model: posix gcc version 4.6.0 20101203 (experimental) [trunk revision 167444] (GCC)
[Bug tree-optimization/46801] [4.6 Regression] FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized gnat_rcheck
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46801 --- Comment #1 from dave at hiauly1 dot hia.nrc.ca 2010-12-04 18:01:04 UTC --- Attached tree dump.
[Bug target/43814] gcc failed to inline memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #9 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2010-12-04
18:09:15 UTC ---
(In reply to comment #8)
In the end we _should_ be able to use alignment information of the
types used at the access (that's also more reliable as compared to
use alignment information from pointer argument types).
But we already do that in MEM_REF expansion:
align = MAX (TYPE_ALIGN (TREE_TYPE (exp)),
get_object_alignment (exp, BIGGEST_ALIGNMENT));
Indeed. SRC will be considered 4-byte aligned in
==
unsigned long long get_ull(const unsigned int *src)
{
unsigned long long tmp;
tmp = src[0];
return tmp;
}
==
, but only 1-byte aligned in
==
unsigned long long get_ull(const unsigned int *src)
{
unsigned long long tmp;
__builtin_memcpy(tmp, src[0], 8);
return tmp;
}
==
It seems we should really use for MEM_REFs
==
align = get_pointer_alignment (exp, BIGGEST_ALIGNMENT);
==
without relying on type alignment. Unfortunately, that will worsen code
generation even more.
[Bug driver/46802] New: GCC option handling change breaks dejagnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46802 Summary: GCC option handling change breaks dejagnu Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: js...@gcc.gnu.org GCC 4.6 failed binutils tests: g++: warning: switch '-fvtable-gc' is no longer supported g++: warning: switch '-fvtable-gc' is no longer supported ERROR: /export/gnu/import/git/binutils/ld/testsuite/ld-selective/3.cc: compilation failed UNRESOLVED: selective4 prune_warnings in dejagnu has regsub -all (^|\n)(cc1: warning: -g is only supported when using GAS on this processor\[^\n\]*\ncc1: warning:\[^\n\]*\n?)+ $text \\1 text regsub -all (^|\n)(cc1plus: warning: -g is only supported when using GAS on this processor\[^\n\]*\ncc1plus: warning:\[^\n\]*\n?)+ $text \\1 text Before GCC 4.6, we have [...@gnu-6 tmp]$ g++ -fvtable-gc -S x.i cc1plus: warning: switch \u2018-fvtable-gc\u2019 is no longer supported GCC 4.6 has [...@gnu-6 tmp]$ /usr/gcc-4.6/bin/g++ -fvtable-gc -S x.i g++: warning: switch \u2018-fvtable-gc\u2019 is no longer supported This change breaks prune_warnings.
[Bug libstdc++/46803] New: libstdc++ build errors on unknown attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46803 Summary: libstdc++ build errors on unknown attributes Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@openbsd.org With OpenBSD/i386 -current and gcc svn it is possible to bootstrap with --enable-languages=c but trying to enable c++ breaks as shown below due to treating unknown attributes as fatal. System compiler used is GCC 4.2.1 gmake[4]: Entering directory `/home/jsg/src/obj/i386-unknown-openbsd4.8/libstdc++-v3' Making all in include gmake[5]: Entering directory `/home/jsg/src/obj/i386-unknown-openbsd4.8/libstdc++-v3/include' mkdir -p ./i386-unknown-openbsd4.8/bits/stdc++.h.gch /home/jsg/src/obj/./gcc/xgcc -shared-libgcc -B/home/jsg/src/obj/./gcc -nostdinc++ -L/home/jsg/src/obj/i386-unknown-openbsd4.8/libstdc++-v3/src -L/home/jsg/src/obj/i386-unknown-openbsd4.8/libstdc++-v3/src/.libs -B/usr/gcc/i386-unknown-openbsd4.8/bin/ -B/usr/gcc/i386-unknown-openbsd4.8/l ib/ -isystem /usr/gcc/i386-unknown-openbsd4.8/include -isystem /usr/gcc/i386-unknown-openbsd4.8/sys-include-x c++-header -nostdinc++ -g -O2 -I/home/jsg/src/obj/i386-unknown-openbsd4.8/libstdc++-v3/include/i386-unknown-openbsd4.8 -I/home/jsg/src/obj/i386-unknown-openbsd4.8/libstdc++ -v3/include -I/home/jsg/src/gcc/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /home/jsg/src/gcc/libstdc++-v3/include/precompiled/stdc++.h \ -o i386-unknown-openbsd4.8/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /usr/include/sys/time.h:346:0, from /usr/include/sys/siginfo.h:130, from /usr/include/sys/signal.h:105, from /usr/include/signal.h:39, from /home/jsg/src/obj/i386-unknown-openbsd4.8/libstdc++-v3/include/csignal:44, from /home/jsg/src/gcc/libstdc++-v3/include/precompiled/stdc++.h:44: /home/jsg/src/obj/./gcc/include-fixed/time.h:125:31: error: '__string__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/time.h:129:31: error: '__minbytes__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/time.h:131:31: error: '__minbytes__' was not declared in this scope In file included from /home/jsg/src/obj/i386-unknown-openbsd4.8/libstdc++-v3/include/cstdio:44:0, from /home/jsg/src/gcc/libstdc++-v3/include/precompiled/stdc++.h:47: /home/jsg/src/obj/./gcc/include-fixed/stdio.h:238:31: error: '__string__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/stdio.h:244:31: error: '__size__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/stdio.h:253:31: error: '__size__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/stdio.h:287:31: error: '__string__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/stdio.h:297:30: error: '__string__' was not declared in this scope In file included from /home/jsg/src/obj/i386-unknown-openbsd4.8/libstdc++-v3/include/cstdlib:67:0, from /home/jsg/src/gcc/libstdc++-v3/include/precompiled/stdc++.h:48: /home/jsg/src/obj/./gcc/include-fixed/stdlib.h:193:31: error: '__string__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/stdlib.h:290:30: error: '__string__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/stdlib.h:293:30: error: '__string__' was not declared in this scope In file included from /home/jsg/src/obj/i386-unknown-openbsd4.8/libstdc++-v3/include/cstring:44:0, from /home/jsg/src/gcc/libstdc++-v3/include/precompiled/stdc++.h:49: /home/jsg/src/obj/./gcc/include-fixed/string.h:72:31: error: '__buffer__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/string.h:73:31: error: '__buffer__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/string.h:75:31: error: '__buffer__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/string.h:76:31: error: '__buffer__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/string.h:78:31: error: '__buffer__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/string.h:88:31: error: '__string__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/string.h:91:31: error: '__string__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/string.h:99:31: error: '__string__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/string.h:103:31: error: '__buffer__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/string.h:109:31: error: '__buffer__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/string.h:110:31: error: '__buffer__' was not declared in this scope /home/jsg/src/obj/./gcc/include-fixed/string.h:112:31: error: '__buffer__' was not declared in this scope
[Bug driver/46802] GCC option handling change breaks dejagnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46802 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-12-04 18:44:51 UTC --- On Sat, 4 Dec 2010, hjl.tools at gmail dot com wrote: g++: warning: switch '-fvtable-gc' is no longer supported g++: warning: switch '-fvtable-gc' is no longer supported This is unrelated to the DejaGnu code you quote. prune_warnings in dejagnu has regsub -all (^|\n)(cc1: warning: -g is only supported when using GAS on this processor\[^\n\]*\ncc1: warning:\[^\n\]*\n?)+ $text \\1 text regsub -all (^|\n)(cc1plus: warning: -g is only supported when using GAS on this processor\[^\n\]*\ncc1plus: warning:\[^\n\]*\n?)+ $text \\1 text None of this DejaGnu code appears to do anything with -fvtable-gc diagnostics, unless there was a previous warning about -g that you didn't quote. The ld testsuite tries to skip these tests case on the compiler version number - is that broken? In any case, it's clearly better for warnings to start g++: instead of cc1plus:. The cc1plus binary is an internal implementation detail; diagnostics should refer to the user-visible binary, which is g++ here.
[Bug driver/46802] GCC option handling change breaks dejagnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46802 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-12-04 18:49:29 UTC --- You can use GCC 4.6 to run make check in ld to see the failures for yourselves. I checked this patch into binutils: http://sourceware.org/ml/binutils/2010-12/msg00189.html to work around it.
[Bug target/43814] gcc failed to inline memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #10 from rguenther at suse dot de rguenther at suse dot de
2010-12-04 18:49:34 UTC ---
On Sat, 4 Dec 2010, mkuvyrkov at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #9 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2010-12-04
18:09:15 UTC ---
(In reply to comment #8)
In the end we _should_ be able to use alignment information of the
types used at the access (that's also more reliable as compared to
use alignment information from pointer argument types).
But we already do that in MEM_REF expansion:
align = MAX (TYPE_ALIGN (TREE_TYPE (exp)),
get_object_alignment (exp, BIGGEST_ALIGNMENT));
Indeed. SRC will be considered 4-byte aligned in
==
unsigned long long get_ull(const unsigned int *src)
{
unsigned long long tmp;
tmp = src[0];
Because here the C language specifies that *src has to be properly
aligned.
return tmp;
}
==
, but only 1-byte aligned in
==
unsigned long long get_ull(const unsigned int *src)
{
unsigned long long tmp;
__builtin_memcpy(tmp, src[0], 8);
And memcpy has to deal with unaligned memory.
return tmp;
}
==
It seems we should really use for MEM_REFs
==
align = get_pointer_alignment (exp, BIGGEST_ALIGNMENT);
==
without relying on type alignment. Unfortunately, that will worsen code
generation even more.
That was what I did originally ...
[Bug driver/46802] GCC option handling change breaks dejagnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46802 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-12-04 18:56:17 UTC --- This is not a GCC bug. It is correct that the message says g++. (You have not given a convincing analysis of why it breaks anything, but the bug is still not in CGC.)
[Bug target/43814] gcc failed to inline memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814 --- Comment #11 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2010-12-04 19:04:29 UTC --- I looked into CCP a bit and it seems like no alignment analysis whatsoever is done for either tmp nor src[0] in == __builtin_memcpy (tmp, src[0], 8); == That is because 1. ccp_initialize() sees __builtin_memcpy, 2. infers that its return value varies, 3. exits without processing the arguments. If the code was structured like so == D1 = tmp; D2 = src[0]; __builtin_memcpy (D1, D2, 8); == CCP would have a better chance inferring alignment for D1 and D2. I'm mostly walking in the dark trying improve CCP, so any pointers would be appreciated.
[Bug driver/46802] GCC option handling change breaks dejagnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46802 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2010-12-04 19:06:01 UTC --- (In reply to comment #3) This is not a GCC bug. It is correct that the message says g++. (You have not given a convincing analysis of why it breaks anything, but the bug is still not in CGC.) I am not saying g++ is incorrect. It is just that some packages don't expect such changes in GCC warning messages. I have changed binutils to work around it. I don't know if it will cause troubles for other programs.
[Bug driver/46760] LTO bootstrap doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760 --- Comment #14 from Jan Hubicka hubicka at gcc dot gnu.org 2010-12-04 19:35:27 UTC --- Author: hubicka Date: Sat Dec 4 19:35:23 2010 New Revision: 167458 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167458 Log: PR tree-optimization/46760 * cgraph.c (cgraph_create_node): Initialize count_materialization_scale. * cgraph.h (struct cgraph_node): Add count_materialization_scale. * lto-cgraph.c (lto_output_edge): Fix assert. (lto_output_node): Output count_materialization_scale. (output_profile_summary): Output only runs and sum_max. (input_node): Input count_materialization_scale. (input_profile_summary): Read data into file specific gcov summary. (merge_profile_summaries): New function. (input_cgraph): Update call of input_profile_summary; call merge_profile_summaries. * lto-streamer-in.c (input_cfg): Add count_materialization_scale arg; rescale counts at read in. (intput_bb): Likewise. (input_function): Update call of input_bb. (lto_read_body): Update call of input_cfg. * lto-streamer.h: Inlclude gcov-io.h (lto_file_decl_data): Add gcov_ctr_summary. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/cgraph.h trunk/gcc/lto-cgraph.c trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer.h
[Bug driver/46802] GCC option handling change breaks dejagnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46802 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||steven at gcc dot gnu.org Resolution||INVALID --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2010-12-04 19:36:27 UTC --- This is not a real bug, and not even a GCC problem (I agree with Joseph that this is actually an improvement). But perhaps something can be said about this in the gcc-4.6 release notes.
[Bug rtl-optimization/46804] New: [4.5/4.6 Regression] gfortran.dg/char_cshift_2.f90 FAILs with -fregmove
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46804
Summary: [4.5/4.6 Regression] gfortran.dg/char_cshift_2.f90
FAILs with -fregmove
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 22632
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22632
auto-reduced testcase
Output:
$ /mnt/svn/gcc-trunk/binary-167453-lto-fortran-checking-yes-rtl-df/bin/gfortran
-O -fPIC -fexpensive-optimizations -fgcse -foptimize-register-move -fpeel-loops
-fno-tree-loop-optimize pr46804.f90
$ ./a.out
Aborted
In the assembly, the problem is apparent (intel syntax):
...
movr12d, DWORD PTR A.4.1573[rip+3]# tmp310, A.4
movDWORD PTR 16[rsp+r8*4], r12d# shift3, tmp310
...
32bit (unaligned) value is loaded instead of sign-extend byte as is done
without -fregmove:
...
movsxr11d, BYTE PTR A.4.1573[rip+3]# tmp310, A.4
movDWORD PTR 16[rsp+r8*4], r11d# shift3, tmp310
...
so shift3 contains invalid data
The problem seems to first appear in the 182r.regmove dump:
$ diff pr46804.f90.180r.ce2 pr46804.f90.182r.regmove
...
2009,2010c1409,1410
(sign_extend:SI (reg:QI 236))) pr46804.f90:17 132 {extendqisi2}
(expr_list:REG_DEAD (reg:QI 236)
---
(reg:SI 236)) pr46804.f90:17 64 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 236)
...
Output:
r167453 - fail
r158095 - fail
4.5 r166509 - fail
4.4 r166509 - OK
[Bug libstdc++/46803] libstdc++ build errors on unknown attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46803 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.04 21:08:59 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-04 21:08:59 UTC --- Please specify exactly how you configured GCC. The C++ language and library is built with the C++ compiler that has been bootstrapped, not the host compiler.
[Bug target/43814] gcc failed to inline memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #12 from rguenther at suse dot de rguenther at suse dot de
2010-12-04 21:12:35 UTC ---
On Sat, 4 Dec 2010, mkuvyrkov at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #11 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2010-12-04
19:04:29 UTC ---
I looked into CCP a bit and it seems like no alignment analysis whatsoever is
done for either tmp nor src[0] in
==
__builtin_memcpy (tmp, src[0], 8);
==
That is because
1. ccp_initialize() sees __builtin_memcpy,
2. infers that its return value varies,
3. exits without processing the arguments.
If the code was structured like so
==
D1 = tmp;
D2 = src[0];
__builtin_memcpy (D1, D2, 8);
==
CCP would have a better chance inferring alignment for D1 and D2.
I'm mostly walking in the dark trying improve CCP, so any pointers would be
appreciated.
tmp and src[0] are irrelevant for CCP. get_{pointer,object}_alignment
does a proper job on them already.
You can only improve CCP by handling SSA name default defs according
to their type (thus, give them initial alignment). But that's
dangerous in my opinion.
If CCP wants to seed alignment from dereferences like
d.134_2 = *p_4;
then it needs to insert stuff like assert-exprs like VRP does
to have SSA name defs at the point of the dereference. Of course
it also needs to retain the so introduced copies.
But I haven't wrapped my brain about this enough to say if this
approach would make sense or would be beneficial.
[Bug libstdc++/46803] libstdc++ build errors on unknown attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46803 --- Comment #2 from Jonathan Gray jsg at openbsd dot org 2010-12-04 21:15:38 UTC --- like so: ../gcc/configure --prefix=/usr/gcc \ --program-transform-name=s,^,e, \ --disable-nls \ --enable-checking \ --with-system-zlib \ --disable-libmudflap \ --disable-libgomp \ --disable-tls \ --with-as=/usr/bin/as \ --with-ld=/usr/bin/ld \ --with-gnu-ld \ --with-gnu-as \ --enable-threads=posix \ --enable-wchar_t \ --disable-lto \ --enable-languages=c,c++,go \ --with-gmp=/usr/local \ --with-mpfr=/usr/local \ --with-mpc=/usr/local
[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751
--- Comment #12 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-04
22:00:39 UTC ---
The problem dsymutil issues are fixed for darwin10 when using Xcode 3.2.4 and
the patch...
Index: gcc/config/darwin10.h
===
--- gcc/config/darwin10.h(revision 167446)
+++ gcc/config/darwin10.h(working copy)
@@ -28,3 +28,12 @@
#undef TARGET_ASM_EMIT_UNWIND_LABEL
#define TARGET_ASM_EMIT_UNWIND_LABEL default_emit_unwind_label
+
+/* Since DWARF2 is default, conditions for running dsymutil are different. */
+/* Xcode 3.2.3 and later have radar 7851516 fixed. */
+#undef DSYMUTIL_SPEC
+#define DSYMUTIL_SPEC \
+ %{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
+
%{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm|.s|.f|.f90|.f95|.f03|.f77|.for|.F|.F90|.F95|.F03:
\
+%{g*:%{!gstabs*:%{!g0: DSYMUTIL %{o*:%*}%{!o:a.out
+
http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg00289.html
Using the same approach in gcc/config/darwin9.h reveals that Xcode 3.1.4 still
produces three types of warnings from dsymutil. These are of the form...
warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item
TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4^M
warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item
TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4
arning: {0x026d} TAG_variable: AT_location( 0x ) didn't have valid
function low pc, the location list will be incorrect.
[Bug target/43751] dsymutil is not called for fortran and, under some circumstances not for other FEs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43751 --- Comment #13 from Jack Howarth howarth at nitro dot med.uc.edu 2010-12-04 22:02:00 UTC --- The second form of the error should have been... warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_lower_bound form = FORM_ref4
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690 --- Comment #34 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2010-12-04 22:29:59 UTC --- Created attachment 22633 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22633 Testcase for ld.bfd with Hongjiu Lu's patch (In reply to comment #33) Received SIGSEGV on this testcase.
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690 --- Comment #35 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2010-12-04 22:31:01 UTC --- Created attachment 22634 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22634 Backtrace from ld.bfd with Hongjiu Lu's patch
[Bug tree-optimization/46805] New: ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O -fno-tree-scev-cprop -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46805 Summary: ICE: SIGSEGV in optab_for_tree_code (optabs.c:407) with -O -fno-tree-scev-cprop -ftree-vectorize Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 22635 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22635 reduced testcase valgrind output: $ gcc -O -fno-tree-scev-cprop -ftree-vectorize pr46805.go ==28234== Conditional jump or move depends on uninitialised value(s) ==28234==at 0x595C61: Lex::require_line() (lex.cc:501) ==28234==by 0x597E1A: Lex::next_token() (lex.cc:544) ==28234==by 0x598532: Parse::peek_token() (parse.cc:64) ==28234==by 0x59A08A: Parse::package_clause() (parse.cc:4544) ==28234==by 0x5A6F7D: Parse::program() (parse.cc:4624) ==28234==by 0x5717AC: go_parse_input_files (go.cc:82) ==28234==by 0x91B4F7: toplev_main (toplev.c:579) ==28234==by 0x65EABBC: (below main) (in /lib64/libc-2.11.2.so) ==28234== Uninitialised value was created by a stack allocation ==28234==at 0x56E720: go_langhook_parse_file (go-lang.c:222) ==28234== ==28234== Invalid read of size 2 ==28234==at 0x8153C0: optab_for_tree_code (optabs.c:407) ==28234==by 0xA56359: supportable_widening_operation (tree-vect-stmts.c:5521) ==28234==by 0xA56B45: vectorizable_type_promotion (tree-vect-stmts.c:3177) ==28234==by 0xA596E3: vect_analyze_stmt (tree-vect-stmts.c:4697) ==28234==by 0xA6522E: vect_analyze_loop (tree-vect-loop.c:1249) ==28234==by 0xA71968: vectorize_loops (tree-vectorizer.c:199) ==28234==by 0x8316FE: execute_one_pass (passes.c:1553) ==28234==by 0x8319C4: execute_pass_list (passes.c:1608) ==28234==by 0x8319D6: execute_pass_list (passes.c:1609) ==28234==by 0x8319D6: execute_pass_list (passes.c:1609) ==28234==by 0x971B45: tree_rest_of_compilation (tree-optimize.c:422) ==28234==by 0xB374E1: cgraph_expand_function (cgraphunit.c:1508) ==28234==by 0xB39AB9: cgraph_optimize (cgraphunit.c:1567) ==28234==by 0xB3A039: cgraph_finalize_compilation_unit (cgraphunit.c:1031) ==28234==by 0x57B97B: Gogo::write_globals() (gogo-tree.cc:825) ==28234==by 0x91B535: toplev_main (toplev.c:591) ==28234==by 0x65EABBC: (below main) (in /lib64/libc-2.11.2.so) ==28234== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==28234== pr46805.go: In function 'main.main': pr46805.go:3:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. The first failure is most likely unrelated, similiar problems can be seen for other frontends as well. Tested revisions: r167453 - crash
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690 --- Comment #36 from H.J. Lu hjl.tools at gmail dot com 2010-12-05 00:44:37 UTC --- (In reply to comment #34) Created attachment 22633 [details] Testcase for ld.bfd with Hongjiu Lu's patch (In reply to comment #33) Received SIGSEGV on this testcase. Please try: http://sourceware.org/ml/binutils/2010-12/msg00191.html
[Bug driver/46760] LTO bootstrap doesn't work with FDO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46760 --- Comment #15 from H.J. Lu hjl.tools at gmail dot com 2010-12-05 00:51:39 UTC --- With revision 167460, I got [...@gnu-18 gcc]$ /export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/xgcc -B/export/build/gnu/gcc-lto/build-x86_64-linux/./prev-gcc/ -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.6.0/x86_64-unknown-linux-gnu/lib/ -isystem /usr/gcc-4.6.0/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.6.0/x86_64-unknown-linux-gnu/sys-include -g -O2 -flto=jobserver -fuse-linker-plugin -frandom-seed=1 -fprofile-use -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc -o build/genchecksum build/genchecksum.o .././libiberty/libiberty.a In function \u2018md5_process_block\u2019: lto1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make: *** [/tmp/cc1Nc0QJ.ltrans0.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status lto-wrapper failedcollect2: ld returned 1 exit status [...@gnu-18 gcc]$
[Bug libstdc++/46803] libstdc++ build errors on unknown attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46803 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-05 01:17:33 UTC --- I don't think this is a library issue.
[Bug c++/46806] New: -O3 implies 0 = 8 = 7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46806 Summary: -O3 implies 0 = 8 = 7 Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: cstankev...@toyon.com Host: Linux seymour.toyon.corp 2.6.35.6-48.fc14.x86_64 #1 SMP Fri Oct 22 15:36:08 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Build: g++ (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) Created attachment 22636 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22636 sample program Linux seymour.toyon.corp 2.6.35.6-48.fc14.x86_64 #1 SMP Fri Oct 22 15:36:08 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux g++ (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) Compile the attached source with g++ test.cpp -O3 and the executable will report 0=8=7. To make the strange result go away: - comment out the do-nothing line gValue = EdgeType (or make a number of other minor changes) - compile with -O1
[Bug c++/46806] -O3 implies 0 = 8 = 7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46806 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-05 02:26:07 UTC --- the enum is unsigned and 8 is out of range of the enum.
[Bug c++/46806] -O3 implies 0 = 8 = 7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46806 --- Comment #2 from Chris Stankevitz cstankevitz at toyon dot com 2010-12-05 02:47:51 UTC --- 8 is out of range of the enum. I agree. Unfortunately, with -O3, 8 is reported as in the range.
[Bug c++/46806] -O3 implies 0 = 8 = 7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46806 Chris Stankevitz cstankevitz at toyon dot com changed: What|Removed |Added Attachment #22636|0 |1 is obsolete|| --- Comment #3 from Chris Stankevitz cstankevitz at toyon dot com 2010-12-05 02:53:17 UTC --- Created attachment 22637 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22637 sample program Updated sample to use a cast to explicitly compare signed ints.
[Bug c++/46806] -O3 implies 0 = 8 = 7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46806 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-05 04:16:26 UTC --- dup of PR 43680 - the default behaviour has changed in 4.6, -fstrict-enums restores the old semantics
[Bug c++/46806] -O3 implies 0 = 8 = 7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46806 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-05 04:18:55 UTC --- (In reply to comment #2) 8 is out of range of the enum. I agree. Unfortunately, with -O3, 8 is reported as in the range. if a program has undefined behaviour then you shouldn't expect consistent results at different optimisation levels ... but luckily for you gcc 4.6 is more forgiving of out-of-range enums
[Bug c++/46759] incorrect array bounds warning?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46759 --- Comment #4 from rwgk at yahoo dot com 2010-12-05 06:14:35 UTC --- Created attachment 22639 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22639 reproducer for similar warning from gcc 4.6 I'm getting a similar warning with g++ from the current svn trunk: svn trunk rev. 167466 g++ (GCC) 4.6.0 20101205 (experimental) % g++ -Wall -O3 pr46759_bounds_warning_2.cpp pr46759_bounds_warning_2.cpp: In function 'int main()': pr46759_bounds_warning_2.cpp:11:3: warning: array subscript is above array bounds [-Warray-bounds] The reproducer is attached. g++ 4.5.1 doesn't emit a warning. Would it be better to file this as a new bug?
[Bug c++/46807] New: internal compiler error: in synthesized_method_walk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46807 Summary: internal compiler error: in synthesized_method_walk Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@yahoo.com Fedora 14 64-bit gcc svn trunk rev. 167466 g++ (GCC) 4.6.0 20101205 (experimental) % g++ -c gcc46_ice.cpp In file included from gcc46_ice.cpp:1:0: /usr/include/boost/foreach.hpp: In function 'boost::foreach_detail_::auto_anyT boost::foreach_detail_::contain(const T, mpl_::true_*) [with T = boost::iterator_range__gnu_cxx::__normal_iteratoritem**, std::vectoritem* , mpl_::true_ = mpl_::bool_true]': gcc46_ice.cpp:12:3: instantiated from 'void work(const boost::iterator_rangeT) [with ForwardIteratorType = __gnu_cxx::__normal_iteratoritem**, std::vectoritem* ]' gcc46_ice.cpp:19:42: instantiated from here /usr/include/boost/foreach.hpp:609:12: internal compiler error: in synthesized_method_walk, at cp/method.c:1308 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/46807] internal compiler error: in synthesized_method_walk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46807 --- Comment #1 from rwgk at yahoo dot com 2010-12-05 07:42:02 UTC --- Created attachment 22640 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22640 reproducer Reproducer depends on vector and boost as shipped with Fedora 14.
[Bug fortran/46794] ICE on valid code involving power of small integer kinds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46794 --- Comment #2 from Daniel Kraft domob at gcc dot gnu.org 2010-12-04 09:27:20 UTC --- Author: domob Date: Sat Dec 4 09:27:17 2010 New Revision: 167453 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167453 Log: 2010-12-04 Daniel Kraft d...@domob.eu PR fortran/46794 * trans-expr.c (gfc_conv_power_op): Handle kind of result expression correctly for integer kind 1 and 2 operands. 2010-12-04 Daniel Kraft d...@domob.eu PR fortran/46794 * gfortran.dg/power2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/power2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/46794] ICE on valid code involving power of small integer kinds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46794 --- Comment #3 from Daniel Kraft domob at gcc dot gnu.org 2010-12-04 09:29:31 UTC --- Fixed on trunk. Since Tobias sees this problem also with 4.4, I will investigate further whether we should backport to 4.5 and 4.4.
[Bug fortran/46797] New: libquadmath: make install relinks libgfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46797 Summary: libquadmath: make install relinks libgfortran Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org If one runs make install, libgfortran is relinked - and the following message is shown. I think that's related to the inclusion of libquadmath. The message appears on x86-64-linux, which uses libquadmath. I have not checked whether it also occurs on non-libquadmath systems. /bin/sh ./libtool --mode=install /usr/bin/install -c libgfortran.la '/projects/tob/gcc-git/gcc-trunk/lib/../lib' libtool: install: warning: relinking `libgfortran.la'
[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #34 from rguenther at suse dot de rguenther at suse dot de
2010-12-04 10:27:58 UTC ---
On Sat, 4 Dec 2010, mikestump at comcast dot net wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #31 from Mike Stump mikestump at comcast dot net 2010-12-04
00:18:07 UTC ---
On Dec 3, 2010, at 3:20 PM, rguenther at suse dot de wrote:
yes, I would have expected that this happens already. Now, I (or
somebody else) needs to take the time and investigate why this
doesn't happen.
Ah, I can explain it, collect2 does `stuff', and what it does is to remove the
lto temporary files, early. The below are the files that are too early, and
will `fix' the issue.
Index: collect2.c
===
--- collect2.c(revision 167409)
+++ collect2.c(working copy)
@@ -1056,7 +1056,9 @@
fork_execute (ld, out_lto_ld_argv);
free (lto_ld_argv);
+#if 0
maybe_unlink_list (lto_o_files);
+#endif
}
else if (force)
{
If collect2 was folded into gcc.c and all the lto stuff was flat, inside gcc.c
and then we let record_temp_file register _all_ the temporary files, and the
let gcc.c delete the temporary files at the end, all work work just fine.
Well - yes. There is the complication called linker-plugin (which
is also removing the files). You can't fold the linker plugin
(thus, the linker) into the gcc driver.
I thought a long time on what a solution to the problem could be and
only see the following:
- The GCC driver is the place where we can detect if we need to
execute dsymutil because we'll only have temporary object files.
The GCC driver needs to arrange for a new -dsym option being
passed to the linker (which might be collect2 for example)
- The _linker_ (or collect2 for example) is responsible for
invoking dsymutil if there is a -dsym option on the command-line.
Only at link time we are sure all object files are still around.
If darwin only ever uses collect2 (and not the linker-plugin) then
this would be a easy and localized change. It would of course also
offer the user to specify that he wants dsymutil to run.
Richard.
[Bug fortran/46794] ICE on valid code involving power of small integer kinds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46794 --- Comment #4 from Daniel Kraft domob at gcc dot gnu.org 2010-12-04 12:12:40 UTC --- Author: domob Date: Sat Dec 4 12:12:35 2010 New Revision: 167454 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167454 Log: 2010-12-04 Daniel Kraft d...@domob.eu PR fortran/46794 * trans-expr.c (gfc_conv_power_op): Handle kind of result expression correctly for integer kind 1 and 2 operands. 2010-12-04 Daniel Kraft d...@domob.eu PR fortran/46794 * gfortran.dg/power2.f90: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/power2.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/trans-expr.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug lto/46769] LTO failed to build gold
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46769 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2010-12-04 12:17:09 UTC --- Created attachment 22627 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22627 reduced testcase Fails with -g -flto -flto-partition=none -r -nostdlib
[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46584 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-04 13:08:15 UTC --- Author: burnus Date: Sat Dec 4 13:08:12 2010 New Revision: 167455 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167455 Log: 2010-12-04 Tobias Burnus bur...@net-b.de PR fortran/46584 * gfortran.dg/quad_1.f90: Remove some complex math checks as they fail on some non-libquadmath systems. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/quad_1.f90
[Bug libfortran/46584] FAIL: gfortran.dg/quad_1.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46584 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2010-12-04 13:13:51 UTC --- The committed patch removed the complex math functions from the quad_1.f90 test. I think the PR can be closed after confirmation that the failure is gone. Regarding hppa64-hp-hpux: I think one could (e.g. with weak alias) consider building a libquadmath which provides also long double names on platforms where the libm does not provide the required functionality and where __float128 and long double are the same data type. However, I think that's an unrelated issue, which I want to leave to the maintainers of the relevant platforms (seemingly only: HPUX on ia64).
[Bug lto/46798] New: [4.6 Regression] invalid conversion in gimple call; verify_stmts failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46798 Summary: [4.6 Regression] invalid conversion in gimple call; verify_stmts failed Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: d.g.gorbac...@gmail.com Host: i686-pc-linux-gnu Target: i686-pc-linux-gnu Build: i686-pc-linux-gnu Created attachment 22628 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22628 testcase In file included from :0:0: main.c: In function 'main': main.c:5:5: error: invalid conversion in gimple call unnamed-signed:32 void D.1987_1 = foo.constprop.0 (); main.c:5:5: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate.
[Bug lto/46798] [4.6 Regression] invalid conversion in gimple call; verify_stmts failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46798 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2010-12-04 14:23:36 UTC --- Created attachment 22629 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22629 backtrace
[Bug debug/46799] New: -fcompare-debug failure (length) with -ftree-parallelize-loops=2 -fno-tree-dce
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46799
Summary: -fcompare-debug failure (length) with
-ftree-parallelize-loops=2 -fno-tree-dce
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 22630
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22630
reduced testcase
Compiler output:
$ gcc -O -ftree-parallelize-loops=2 -fno-tree-dce -ftree-pre -fcompare-debug
pr46799.c
gcc: error: pr46799.c: -fcompare-debug failure (length)
$ diff pr46799.*gkd
204c204
(reg:DI 6 bp))# {*pushdi2_rex64}
---
(reg:DI 6 bp)) pr46799.c:1# {*pushdi2_rex64}
208c208
(reg:DI 3 bx))# {*pushdi2_rex64}
---
(reg:DI 3 bx)) pr46799.c:1# {*pushdi2_rex64}
217c217
])# {pro_epilogue_adjust_stack_di_add}
---
]) pr46799.c:1# {pro_epilogue_adjust_stack_di_add}
227c227
(const_int 8 [0x8])) [ .paral_data_load.11_3-D.+0 S4
A32])) pr46799.c:33554427# {*movsi_internal}
---
(const_int 8 [0x8])) [ .paral_data_load.11_3-D.+0 S4
A32])) pr46799.c:1# {*movsi_internal}
Tested revisions:
r167424 - fail
r153685 - OK
4.5 r166509 - fail
