[Bug c/44420] [feature request] Warn for certain integer overflows
--- Comment #4 from fm3 at os dot inf dot tu-dresden dot de 2010-06-08 06:19 --- Yes, you are right. This is a duplicate. Thanks. -- fm3 at os dot inf dot tu-dresden dot de changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44420
[Bug fortran/44446] Error with protected pocedure pointer
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-08 06:37 --- Subject: Bug 6 Author: burnus Date: Tue Jun 8 06:37:32 2010 New Revision: 160424 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160424 Log: 2010-06-07 Tobias Burnus bur...@net-b.de PR fortran/6 * symbol.c (check_conflict): Move protected--external/procedure check ... * resolve.c (resolve_select_type): ... to the resolution stage. 2010-06-07 Tobias Burnus bur...@net-b.de PR fortran/6 * gfortran.dg/proc_ptr_27.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_27.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #33 from Kyle dot D dot Moffett at boeing dot com 2010-06-08 06:48 --- EGLIBC and PPL are still building; I'm heading to sleep and I'll check on them later this morning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug fortran/44446] Error with protected pocedure pointer
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-08 07:02 --- (In reply to comment #1) Untested: And not working ;-) Anyway, the bug is now FIXED on the trunk (4.6). Thanks for the report! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
[Bug tree-optimization/44462] New: Redundant looping pure functions whose return value is dead are not optimized out
For the following testcase:
__attribute__ ((noinline,noclone))
int
i_am_pure (int a)
{
if (a10)
abort();
}
main()
{
int a = i_am_pure (5) + i_am_pure (5);
int b = i_am_pure (8) + i_am_pure (8);
return a;
}
We get only one call to i_am_pure optimized out:
main ()
{
int a;
int D.2721;
bb 2:
D.2721_1 = i_am_pure (5);
a_3 = D.2721_1 + D.2721_1;
i_am_pure (8);
i_am_pure (8);
return a_3;
}
This is becasue removal is done as part of PRE and we are not removing
function calls without return value.
Perhaps this can be improved to at least handle FRE quite easilly? In GCC we
now have about 1/4th of pure functions with WHOPR build and some results
especially in autogenerated files are unused and we end up with a lot of
redundant calls there.
Honza
--
Summary: Redundant looping pure functions whose return value is
dead are not optimized out
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hubicka at gcc dot gnu dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44462
[Bug bootstrap/44458] Bootstrap fails on arm_float_words_big_endian implicit declaration when Ada on arm-linux
--- Comment #2 from mikpe at it dot uu dot se 2010-06-08 08:19 --- The same error occurs for java on ARM, see PR44335. I posted a patch to fix that one (must include both tm.h and tm_p.h in jcf-parse.c) that but so far has gotten no response to it. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44458
[Bug bootstrap/43847] test for plugin is using wrong objdump for host != target
--- Comment #3 from doko at ubuntu dot com 2010-06-08 08:35 --- proposed patch at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00658.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847
[Bug lto/44463] New: whopr does not work with weak functions
Hit this while attempting to compile a large code base with WHOPR:
tweak1.c:
void y(void) { printf(y\n); }
void x(void) __attribute__((weak, alias(y)));
tweak2.c:
void x(void) { printf(strong\n); }
tweak3.c:
extern void x(void);
int main(void) { x(); return 0; }
Compile with
gcc -fwhopr -c -O2 tweak1.c
gcc -fwhopr -c -O2 tweak2.c
gcc -fwhopr -c -O2 tweak3.c
gcc -fwhopr tweak[123].o
/tmp/ccGG7BOa.ltrans1.ltrans.o: In function `x':
ccGG7BOa.ltrans1.o:(.text+0x0): multiple definition of `x'
/tmp/ccGG7BOa.ltrans0.ltrans.o:ccGG7BOa.ltrans0.o:(.text+0x0): first defined
here
collect2: ld returned 1 exit status
Without -fwhopr it works
Version:
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/pkg/gcc-4.6-100607
--enable-checking=release --enable-languages=c,c++ --disable-nls --enable-lto
--enable-gold --with-plugin-ld=/usr/local/bin/gold
--with-elf-include=/usr/include/libelf
Thread model: posix
gcc version 4.6.0 20100607 (experimental) (GCC)
--
Summary: whopr does not work with weak functions
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andi-gcc at firstfloor dot org
GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
[Bug tree-optimization/44462] Redundant looping pure functions whose return value is dead are not optimized out
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-08 08:49 --- Hm? The return values are removed as part of first DCE pass. bb 2: D.2721_1 = i_am_pure (5); D.2722_2 = i_am_pure (5); a_3 = D.2721_1 + D.2722_2; i_am_pure (8); i_am_pure (8); return a_3; and FRE/PRE do not value-number anything that does not DEF an SSA name (nor something that defines something that is not used, so -fno-tree-dce does not help here). Why do we remove register LHS in DCE again? I can fix VN easily to also consider unused LHS on not dead stmts. Thus, mine for -fno-tree-dce. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-08 08:49:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44462
[Bug rtl-optimization/44460] [4.6 Regression] r160380 breaks libjava bootstrap on *-apple-darwin*
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|r160380 breaks libjava |[4.6 Regression] r160380 |bootstrap on *-apple-darwin*|breaks libjava bootstrap on ||*-apple-darwin* Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44460
[Bug rtl-optimization/44460] [4.6 Regression] r160380 breaks libjava bootstrap on *-apple-darwin*
--- Comment #1 from ubizjak at gmail dot com 2010-06-08 08:50 --- FAIL: g++.dg/torture/pr32304.C -O3 -g (internal compiler error) also fails with the same ICE on x86_64-pc-linux-gnu [1]. [1] http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00759.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-08 08:50:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44460
[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-08 08:51 --- By switching the GCC build language to C++, we introduce name mangling, which means that we loose plugin dynamic link compatibility to previous versions of gcc. Also, the interface becomes subject to change when mangling changes, and will not be compatible if the build compiler uses a different mangling scheme. Moreover, it forces to compile plugins with C++. Exactly as designed. We do not have a plugin interface (our interface is called dlopen). Plugins have to deal with that. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
[Bug rtl-optimization/44460] [4.6 Regression] r160380 breaks libjava bootstrap on *-apple-darwin*
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-08 08:53 --- Created an attachment (id=20864) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20864action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44460
[Bug middle-end/44454] [4.6 Regression] Many new failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44454
[Bug middle-end/44453] [4.6 Regression] Revision 160380 caused g++.dg/torture/pr32304.C
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44453
[Bug objc++/27249] FAIL: obj-c++.dg/encode-8.mm execution test
--- Comment #5 from iains at gcc dot gnu dot org 2010-06-08 08:55 --- this has been fixed for some time in the test-suite by running only for *-*-darwin* and skipping for gnu-runtime. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27249
[Bug lto/44464] New: ICE during linux kernel whopr build
I got several ICEs during a linux kernel whopr build, here's one of them. gcc46 -nostdlib -fwhopr -r -o net/ipv4/built-in.o net/ipv4/route.o net/ipv4/inetpeer.o net/ipv4/protocol.o net/ipv4/ip_input.o net/ipv4/ip_fragment.o net/ipv4/ip_forward.o net/ipv4/ip_options.o net/ipv4/ip_output.o net/ipv4/ip_sockglue.o net/ipv4/inet_hashtables.o net/ipv4/inet_timewait_sock.o net/ipv4/inet_connection_sock.o net/ipv4/tcp.o net/ipv4/tcp_input.o net/ipv4/tcp_output.o net/ipv4/tcp_timer.o net/ipv4/tcp_ipv4.o net/ipv4/tcp_minisocks.o net/ipv4/tcp_cong.o net/ipv4/datagram.o net/ipv4/raw.o net/ipv4/udp.o net/ipv4/udplite.o net/ipv4/arp.o net/ipv4/icmp.o net/ipv4/devinet.o net/ipv4/af_inet.o net/ipv4/igmp.o net/ipv4/fib_frontend.o net/ipv4/fib_semantics.o net/ipv4/inet_fragment.o net/ipv4/sysctl_net_ipv4.o net/ipv4/fib_trie.o net/ipv4/proc.o net/ipv4/inet_lro.o net/ipv4/tunnel4.o net/ipv4/ipconfig.o net/ipv4/inet_diag.o net/ipv4/tcp_diag.o net/ipv4/tcp_cubic.o In file included from :377:0: net/ipv4/igmp.c: In function 'igmp_mcf_get_next': net/ipv4/igmp.c:2528:27: 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. lto-wrapper: gcc46 returned 1 exit status collect2: lto-wrapper returned 1 exit status Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/pkg/gcc-4.6-100607 --enable-checking=release --enable-languages=c,c++ --disable-nls --enable-lto --enable-gold --with-plugin-ld=/usr/local/bin/gold --with-elf-include=/usr/include/libelf Thread model: posix gcc version 4.6.0 20100607 (experimental) (GCC) -- Summary: ICE during linux kernel whopr build Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andi-gcc at firstfloor dot org GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug tree-optimization/44258] [4.5/4.6 Regression] possible SRA wrong-code generation.
--- Comment #9 from pluto at agmk dot net 2010-06-08 09:07 --- (In reply to comment #8) (In reply to comment #5) have a look at PR44406... i believe its the same thing. I think it probably is because the patch of mine would lead to code very similar to what exposed PR 44406. However, PR 44406 actually no longer happens on the trunk because it is very likely a duplicate of PR 44164. So can you please verify that this miscompilation still takes place with the current 4.5 branch before I go into all the troubles of looking at what compiles differently and where? Thanks. verification in progress... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44258
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #1 from andi-gcc at firstfloor dot org 2010-06-08 09:38 --- Ok unable to attach and I've been told reporting LTO bugs requires some magic voodoo incarnations first. If it helps here's the gdb information of the crash: (gdb) pt var error_mark 0x1200022 (gdb) bt #0 var_map_base_init (map=0x1102b00) at ../../gcc/gcc/tree-ssa-live.c:87 #1 0x007248fb in coalesce_ssa_name () at ../../gcc/gcc/tree-ssa-coalesce.c:1405 #2 0x006fd30f in rewrite_out_of_ssa (sa=0x10540a0) at ../../gcc/gcc/tree-outof-ssa.c:909 #3 0x004d46d8 in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:3742 #4 0x0062afd1 in execute_one_pass (pass=0xf503e0) at ../../gcc/gcc/passes.c:1576 #5 0x00fe28e0 in ?? () #6 0x0162aeb4 in ?? () #7 0x00f503e0 in ?? () #8 0x in ?? () (gdb) Somehow error_mark got in there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #2 from andi-gcc at firstfloor dot org 2010-06-08 09:40 --- The object files are at http://halobates.de/whopr-ice.tar.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-08 09:55 --- Did you reduce the number of object files already? Note that you are linking without optimization (and you probably built the .o files with optimization?) So this might be a duplicate of PR41159. Can you put output of adding -v to one of the .o file compiles? Can you put preprocessed source of all .o file sources that are required to reproduce the bug somewhere? Thx. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Keywords||lto Version|lto |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-08 09:56 --- (In reply to comment #2) By switching the GCC build language to C++, we introduce name mangling, which means that we loose plugin dynamic link compatibility to previous versions of gcc. Also, the interface becomes subject to change when mangling changes, and will not be compatible if the build compiler uses a different mangling scheme. Moreover, it forces to compile plugins with C++. Exactly as designed. I don't recall any specification for our plugins that says we can use any implementation language, as long it is C++. We do not have a plugin interface (our interface is called dlopen). Plugins have to deal with that. As per plugins.texi, the documented way to pass the GPL license test only works when the plugin is compiled as C code. int plugin_is_GPL_compatible; will give a different mangled symbol name when compiled as C++. The comment at the start of gcc-plugin.h states: Public header file for plugins to include, hence this is part of the plugin interface. The way this header file is now, it will not work when the compiler is built with a C++ compiler, but the plugin is build with a C compiler. Hence, plugins will not work as documented when the compiler is build with a C++ compiler, no matter what compiler you use for the plugins. A small change to the header files will go a long way to allow simple plugins to continue to work as advertised, and preserve interoperability with more languages and compilers, including possible future variants of g++ with mangling differences. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
[Bug fortran/44465] New: polymorphic object oriented example
We are developing object oriented examples for our next book and have hit a compiler bug with the following short program. program polymorphic use shape_module use circle_module use rectangle_module implicit none type shape_w class (shape_type) , allocatable :: shape_v end type shape_w type (shape_w) , dimension(3) :: p print *,' shape ' p(1)%shape_v=shape_type(10,20) call p(1)%shape_v%draw() print *,' circle ' p(2)%shape_v=circle_type(100,200,300) call p(2)%shape_v%draw() print *,' rectangle ' p(3)%shape_v=rectangle_type(1000,2000,3000,4000) call p(3)%shape_v%draw() end program polymorphic The following example program compiles and runs. program polymorphic use shape_module use circle_module use rectangle_module implicit none class (shape_type) , allocatable :: p allocate(shape_type :: p) print *,' ** shape **' p=shape_type(10,20) call p%draw() print *,' ** circle **' p=circle_type(100,200,300) call p%draw() print *,' ** rectangle **' p=rectangle_type(1000,2000,3000,4000) call p%draw() end program polymorphic Here is the rest of the information requested in the bug report document. gcc version --- c:\document\fortran\newbook\examples\ch32gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=c:/program files (x86)/gfortran/bin/../libexec/gcc/i586-pc-mingw32/4.6.0/lto-wrapper.exe Target: i586-pc-mingw32 Configured with: ../gcc-trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/brad/gfortran/dependencies - -disable-werror --enable-threads --disable-nls --build=i586-pc-mingw32 --enable-libgomp --disable-shared --disable-win32-registry --with-dwarf2 --disable-sjlj-exceptions : (reconfigured) ../gcc-trunk/configure --prefix=/mingw --enable-languages=c,fortran --wit h-gmp=/home/brad/gfortran/dependencies --disable-werror --enable-threads --disable-nls --build=i586-pc-mingw32 --enable-libgomp -- disable-shared --disable-win32-registry --with-dwarf2 --disable-sjlj-exceptions Thread model: win32 gcc version 4.6.0 20100524 (experimental) [trunk revision 159774] (GCC) Hardware and Operating system - The information below is from the Intel CPU id utility. ++ Intel(R) Processor Identification Utility Version: 4.22.20100224 Time Stamp: 2010/06/08 09:48:20 Operating System: 6.0-6002-Service Pack 2 Number of processors in system: 1 Current processor: #1 Active cores per processor: 4 Disabled cores per processor: 0 Processor Name: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz stuff deleted ++ The system is running Windows Vista Home Premium SP2 - 64 Bit. gcc build options = I did not build it I just took the gfortran executable from the download site. Compiler command line = c:\document\fortran\newbook\examples\ch32gfortran shape_p.f90 circle_p.f90 rectangle_p.f90 polymorph_array.f90 polymorph_array.f90: In function 'polymorphic': polymorph_array.f90:18:0: 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. Do you want the shape_p.f90, circle_p.f90 and rectangle_p.f90 source files? -- Summary: polymorphic object oriented example Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian at rhymneyconsulting dot co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44465
[Bug tree-optimization/44258] [4.5/4.6 Regression] possible SRA wrong-code generation.
--- Comment #10 from pluto at agmk dot net 2010-06-08 10:15 --- the gcc-4.5-20100608 still miscompiles kde4libs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44258
[Bug other/44116] 64bit inodes for source code causes Value too large for defined data type (XFS,inode64)
--- Comment #4 from kasparek at fit dot vutbr dot cz 2010-06-08 10:34 --- Hello, is there any progress in this, may I help with something? -- kasparek at fit dot vutbr dot cz changed: What|Removed |Added Version|4.5.0 |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44116
[Bug rtl-optimization/44460] [4.6 Regression] r160380 breaks libjava bootstrap on *-apple-darwin*
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-08 10:35 --- Needs '-g -O1' to fails: [macbook] i386/libjava% /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc -nostdinc++ -DHAVE_CONFIG_H -I. -I../../../../work/libjava -I./include -I./gcj -I../../../../work/libjava -Iinclude -I../../../../work/libjava/include -I../../../../work/libjava/classpath/include -Iclasspath/include -I../../../../work/libjava/classpath/native/fdlibm -I../../../../work/libjava/boehm-gc/include -I../boehm-gc/include -I../../../../work/libjava/libltdl -I../../../../work/libjava/libltdl -I../../../../work/gcc -I../../../../work/libffi/include -I../libffi/include -I/sw64/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Wextra -Wall -D_GNU_SOURCE -g -O1 -c ../../../../work/libjava/darwin.cc -fno-common -DPIC ../../../../work/libjava/darwin.cc: In function '(static initializers for ../../../../work/libjava/darwin.cc)': ../../../../work/libjava/darwin.cc:80:21: internal compiler error: in set_mem_attributes_minus_bitpos, at emit-rtl.c:1674 Backtrace #0 fancy_abort (file=0x100ad07d0 ../../work/gcc/emit-rtl.c, line=1674, function=0x100b42a40 set_mem_attributes_minus_bitpos) at ../../work/gcc/diagnostic.c:793 #1 0x00010054125b in set_mem_attributes_minus_bitpos (ref=0x101530bd0, t=0x10151c000, objectp=1, bitpos=0) at ../../work/gcc/emit-rtl.c:1673 #2 0x0001009ba6b9 in make_decl_rtl (decl=0x10151c000) at ../../work/gcc/varasm.c:1599 #3 0x0001009bdaab in make_decl_rtl_for_debug (decl=0x10151c000) at ../../work/gcc/varasm.c:1638 #4 0x00010050f725 in rtl_for_decl_location (decl=0x10151c000) at ../../work/gcc/dwarf2out.c:16264 #5 0x000100525d7d in add_location_or_const_value_attribute (die=0x10152af20, decl=0x10151c000) at ../../work/gcc/dwarf2out.c:16351 #6 0x00010052fc0e in dwarf2out_finish (filename=0x7fff5fbfd965 ../../../../work/libjava/darwin.cc) at ../../work/gcc/dwarf2out.c:21895 #7 0x0001007e7592 in toplev_main (argc=37, argv=0x7fff5fbfd338) at ../../work/gcc/toplev.c:1059 #8 0x00010cc4 in start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44460
[Bug c/44466] New: Segmentation fault in compilation
When doing (node_refine.i attached): gcc -DNDEBUG -O3 -I. -c node_refine.i I get: node_refine.c: In function KWayNodeRefine__: node_refine.c:162:6: internal compiler error: Violació de segment Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: Segmentation fault in compilation Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: msteghofer at cistib dot upf dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44466
[Bug middle-end/44453] [4.6 Regression] Revision 160380 caused g++.dg/torture/pr32304.C
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-08 10:37 --- pr44460 is probably a duplicate. The test fails with -g -O1 and the backtrace is #0 fancy_abort (file=0x100ad07d0 ../../work/gcc/emit-rtl.c, line=1674, function=0x100b42a40 set_mem_attributes_minus_bitpos) at ../../work/gcc/diagnostic.c:793 #1 0x00010054125b in set_mem_attributes_minus_bitpos (ref=0x142875780, t=0x141f24280, objectp=1, bitpos=0) at ../../work/gcc/emit-rtl.c:1673 #2 0x0001009ba6b9 in make_decl_rtl (decl=0x141f24280) at ../../work/gcc/varasm.c:1599 #3 0x0001009bdaab in make_decl_rtl_for_debug (decl=0x141f24280) at ../../work/gcc/varasm.c:1638 #4 0x00010048becf in expand_debug_expr (exp=0x141f24280) at ../../work/gcc/cfgexpand.c:2349 #5 0x00010048bad2 in expand_debug_expr (exp=0x141f04a50) at ../../work/gcc/cfgexpand.c:2902 #6 0x00010048ef25 in gimple_expand_cfg () at ../../work/gcc/cfgexpand.c:3093 #7 0x00010071e954 in execute_one_pass (pass=0x100d17820) at ../../work/gcc/passes.c:1587 #8 0x00010071ec2d in execute_pass_list (pass=0x100d17820) at ../../work/gcc/passes.c:1642 #9 0x00010084d3ec in tree_rest_of_compilation (fndecl=0x14285fd00) at ../../work/gcc/tree-optimize.c:420 #10 0x000100a0c700 in cgraph_expand_function (node=0x141f0cc18) at ../../work/gcc/cgraphunit.c:1632 #11 0x000100a0f5e9 in cgraph_optimize () at ../../work/gcc/cgraphunit.c:1711 #12 0x000100a0fc7a in cgraph_finalize_compilation_unit () at ../../work/gcc/cgraphunit.c:1171 #13 0x0001000c5afa in cp_write_global_declarations () at ../../work/gcc/cp/decl2.c:3927 #14 0x0001007e7511 in toplev_main (argc=4, argv=0x7fff5fbfd9d8) at ../../work/gcc/toplev.c:1024 #15 0x00010cc4 in start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44453
[Bug c/44466] Segmentation fault in compilation
--- Comment #1 from msteghofer at cistib dot upf dot edu 2010-06-08 10:38 --- Created an attachment (id=20865) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20865action=view) The code that produces the error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44466
[Bug c/44466] Segmentation fault in compilation
--- Comment #2 from msteghofer at cistib dot upf dot edu 2010-06-08 10:38 --- GCC version info: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/data/home/msteghofer/gcc-4.5/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.5.0/configure --prefix=/data/home/msteghofer/gcc-4.5/dist --with-gmp=/data/home/msteghofer/gcc-4.5/dist --with-mpfr=/data/home/msteghofer/gcc-4.5/dist --with-mpc=/data/home/msteghofer/gcc-4.5/dist --enable-werror --enable-languages=c,c++,fortran --with-libelf=/data/home/msteghofer/gcc-4.5/dist --with-ppl=/data/home/msteghofer/gcc-4.5/dist --with-cloog=/data/home/msteghofer/gcc-4.5/dist Thread model: posix gcc version 4.5.0 (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44466
[Bug target/42495] redundant memory load
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2010-06-08 10:41
---
Elimination of subsequent calculations of PIC addresses should be handled in
code hoisting optimization.
However, there are two problems that inhibit the optimization:
1. ARM backend outputs calculation of a PIC address as two instructions (load
GOT offset from constant pool and then load PIC address from GOT) and hoist
only handles expressions contained in a single_set().
2. Hoisting algorithm misses many opportunities for expression hoisting to
basic blocks that contain calculation of the expression. I.e., expr from bb4
will not be hoisted to bb2 even though it is trivially profitable:
bb2:
expr
condjump bb4
bb3:
no expr
jump bb5
bb4:
expr
bb5:
I'm testing patches to the ARM backend and code hoisting pass which fix the
above problems. The generated code calculates address of the global variable
only once:
goo:
push{r3, r4, r5, lr}
ldr r3, .L6
ldr r2, .L6+4
.LPIC0:
add r3, pc
ldr r5, [r3, r2]
mov r4, r0
ldr r3, [r5]
ldr r0, [r3]
cmp r0, #0
beq .L2
mov r1, r4
bl foo
.L2:
ldr r3, [r4]
mov r0, #0
cmp r3, #0
beq .L3
ldr r2, [r5]
cmp r3, r2
beq .L3
ldr r0, [r3]
.L3:
@ sp needed for prologue
pop {r3, r4, r5, pc}
.L7:
.align 2
.L6:
.word _GLOBAL_OFFSET_TABLE_-(.LPIC0+4)
.word gObj(GOT)
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot
|dot org |org
Status|WAITING |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-06-08 10:41:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug c/44466] Segmentation fault in compilation
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-08 11:11 --- This has been fixed for 4.5.1. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44466
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #34 from gcc at breakpoint dot cc 2010-06-08 11:23 --- (In reply to comment #28) #define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \ (TARGET_E500_DOUBLE ((MODE) == VOIDmode || (MODE) == DFmode) \ ? DFmode \ : choose_hard_reg_mode ((REGNO), (NREGS), false)) I applied it on 4.4 branch. The big Perl thing is passes its testsuite with this. Also I don't see evldd X, stw X, ld X constructs, there is just one evldd. It looks good so far. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug tree-optimization/44467] New: [4.6 Regression]: cris-elf build broken in libstdc++
With revision 160368 the tree built. From revision 160380 and on including at least 160431, build has failed as follows: libtool: compile: /tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc -shared-libgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc -nostdinc++ -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/src -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/src/.libs -nostdinc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/ -isystem /tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/targ-include -isystem /tmp/hpautotest-gcc1/gcc/newlib/libc/include -B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/cris -L/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libgloss/libnosys -L/tmp/hpautotest-gcc1/gcc/libgloss/cris -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/bin/ -B/tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/lib/ -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/include -isystem /tmp/hpautotest-gcc1/cris-elf/pre/cris-elf/sys-include -I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/../gcc -I/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include/cris-elf -I/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/libstdc++-v3/include -I/tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c /tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++/eh_alloc.cc -o eh_alloc.o /tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++/eh_alloc.cc: In function 'void* __cxxabiv1::__cxa_allocate_exception(std::size_t)': /tmp/hpautotest-gcc1/gcc/libstdc++-v3/libsupc++/eh_alloc.cc:97:1: internal compiler error: in set_mem_attributes_minus_bitpos, at emit-rtl.c:1674 will attach eh_alloc.ii momentarily. Authors of patches in suspect revision range CC:ed. -- Summary: [4.6 Regression]: cris-elf build broken in libstdc++ Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hp at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: cris-axis-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44467
[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-08 12:40 --- This is the patch set for the fix: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00741.html http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00740.html -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
[Bug tree-optimization/44467] [4.6 Regression]: cris-elf build broken in libstdc++
--- Comment #1 from hp at gcc dot gnu dot org 2010-06-08 12:43 --- Created an attachment (id=20866) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20866action=view) preprocessed cc1plus -fpreprocessed eh_alloc.ii -melf -quiet -dumpbase eh_alloc.cc -auxbase-strip eh_alloc.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o eh_alloc.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44467
[Bug tree-optimization/44468] New: Bogus access re-construction from offset calculation
#include stddef.h
struct S {
int i;
int j;
};
struct R {
int k;
struct S a;
};
struct Q {
float k;
struct S a;
};
struct Q s;
int __attribute__((noinline,noclone))
test1 (void *q)
{
struct S *b = (struct S *)((char *)q + sizeof (int));
s.a.i = 0;
b-i = 3;
return s.a.i;
}
int __attribute__((noinline,noclone))
test2 (void *q)
{
struct S *b = ((struct R *)q)-a;
s.a.i = 0;
b-i = 3;
return s.a.i;
}
int __attribute__((noinline,noclone))
test3 (void *q)
{
s.a.i = 0;
((struct S *)((char *)q + sizeof (int)))-i = 3;
return s.a.i;
}
extern void abort (void);
int
main()
{
if (sizeof (float) != sizeof (int)
|| offsetof (struct R, a) != sizeof (int)
|| offsetof (struct Q, a) != sizeof (int))
return 0;
s.a.i = 1;
s.a.j = 2;
if (test1 ((void *)s) != 3)
abort ();
s.a.i = 1;
s.a.j = 2;
if (test2 ((void *)s) != 3)
abort ();
s.a.i = 1;
s.a.j = 2;
if (test3 ((void *)s) != 3)
abort ();
return 0;
}
is miscompiled (in test2 only, I believe I have fixed the other cases
at some point by throttling down maybe_fold_offset_to_component_ref).
We re-construct from
q.1_2 = (struct R *) q_1(D);
b_3 = q.1_2-a;
s.a.i = 0;
b_3-i = 3;
via forwprop
struct R * q.1;
bb 2:
q.1_2 = (struct R *) q_1(D);
s.a.i = 0;
q.1_2-a.i = 3;
and the oracle (or VOP construction in 4.3) believes that we can't access
an object of type Q via a pointer to type R (which is correct).
--
Summary: Bogus access re-construction from offset calculation
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-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=44468
[Bug tree-optimization/44468] Bogus access re-construction from offset calculation
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-08 12:52 --- Argument why the testcase is invalid might go along the line that a pointer to struct Q may not be converted to a pointer to struct R, or that ((struct R *)q)-a is accessing *q as struct R. This is similar to PR41317. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.5 4.4.3 4.5.0 Known to work||4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44468
[Bug tree-optimization/44468] Bogus access re-construction from offset calculation
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-08 12:53 --- Fixed on the mem-ref branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44468
[Bug rtl-optimization/44460] [4.6 Regression] r160380 breaks libjava bootstrap on *-apple-darwin*
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-08 12:57 --- *** Bug 44467 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44460
[Bug tree-optimization/44467] [4.6 Regression]: cris-elf build broken in libstdc++
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-08 12:57 --- *** This bug has been marked as a duplicate of 44460 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44467
[Bug tree-optimization/44467] [4.6 Regression]: cris-elf build broken in libstdc++
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-08 12:58 --- Likely pr44453 and pr44460. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44467
[Bug fortran/44465] [OOP] ICE with polymorphic object oriented example
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-08 13:00 --- (In reply to comment #0) c:\document\fortran\newbook\examples\ch32gfortran shape_p.f90 circle_p.f90 rectangle_p.f90 polymorph_array.f90 polymorph_array.f90: In function 'polymorphic': polymorph_array.f90:18:0: internal compiler error: Segmentation fault Do you want the shape_p.f90, circle_p.f90 and rectangle_p.f90 source files? Yes, please. Without it is difficult to reproduce the segfault. Please attach the modules (unless they are short, then you can also paste them) - probably best by putting all modules into a single file (rather than attaching them one by one, which is also fine). Thanks for the bug report! -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org Summary|polymorphic object oriented |[OOP] ICE with polymorphic |example |object oriented example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44465
[Bug tree-optimization/44468] Bogus access re-construction from offset calculation
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-08 13:03 --- Subject: Bug 44468 Author: rguenth Date: Tue Jun 8 13:02:53 2010 New Revision: 160435 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160435 Log: 2010-06-08 Richard Guenther rguent...@suse.de testsuite/ PR tree-optimization/44468 * gcc.c-torture/execute/pr44468.c: New testcase. Added: branches/mem-ref2/gcc/testsuite/gcc.c-torture/execute/pr44468.c Modified: branches/mem-ref2/gcc/ChangeLog.mem-ref2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44468
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-06-08 13:16 --- Mine -- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-06-05 10:47:29 |2010-06-08 13:16:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug fortran/44465] [OOP] ICE with polymorphic object oriented example
--- Comment #2 from ian at rhymneyconsulting dot co dot uk 2010-06-08 13:21 --- Subject: RE: [OOP] ICE with polymorphic object oriented example I should have included them with the bug report! Things are really progressing with the compiler. Well done! Out of the compilers Jane and I have access to The only one that compiles them is the nag compiler. Cheers Ian Chivers Files are Shape_p.f90 module shape_module type shape_type integer :: x_=0 integer :: y_=0 contains procedure , pass(this) :: getx procedure , pass(this) :: gety procedure , pass(this) :: setx procedure , pass(this) :: sety procedure , pass(this) :: moveto procedure , pass(this) :: draw end type shape_type interface assignment(=) module procedure generic_shape_assign end interface contains integer function getx(this) implicit none class (shape_type) , intent(in) :: this getx=this%x_ end function getx integer function gety(this) implicit none class (shape_type) , intent(in) :: this gety=this%y_ end function gety subroutine setx(this,x) implicit none class (shape_type), intent(inout) :: this integer , intent(in) :: x this%x_=x end subroutine setx subroutine sety(this,y) implicit none class (shape_type), intent(inout) :: this integer , intent(in) :: y this%y_=y end subroutine sety subroutine moveto(this,newx,newy) implicit none class (shape_type), intent(inout) :: this integer , intent(in) :: newx integer , intent(in) :: newy this%x_=newx this%y_=newy end subroutine moveto subroutine draw(this) implicit none class (shape_type), intent(in) :: this print *,' x = ' , this%x_ print *,' y = ' , this%y_ end subroutine draw subroutine generic_shape_assign(lhs,rhs) implicit none class (shape_type) , intent(out) , allocatable :: lhs class (shape_type) , intent(in) :: rhs print *,' In generic_shape_assign' if ( allocated(lhs) ) then deallocate(lhs) end if allocate(lhs,source=rhs) end subroutine generic_shape_assign end module shape_module Circle_p.f90 module circle_module use shape_module type , extends(shape_type) :: circle_type integer :: radius_ contains procedure , pass(this) :: getradius procedure , pass(this) :: setradius procedure , pass(this) :: draw = draw_circle end type circle_type contains integer function getradius(this) implicit none class (circle_type) , intent(in) :: this getradius=this%radius_ end function getradius subroutine setradius(this,radius) implicit none class (circle_type) , intent(inout) :: this integer , intent(in) :: radius this%radius_=radius end subroutine setradius subroutine draw_circle(this) implicit none class (circle_type), intent(in) :: this print *,' x = ' , this%x_ print *,' y = ' , this%y_ print *,' radius = ' , this%radius_ end subroutine draw_circle end module circle_module Rectangle_p.f90 module rectangle_module use shape_module type , extends(shape_type) :: rectangle_type integer :: width_ integer :: height_ contains procedure , pass(this) :: getwidth procedure , pass(this) :: setwidth procedure , pass(this) :: getheight procedure , pass(this) :: setheight procedure , pass(this) :: draw = draw_rectangle end type rectangle_type contains integer function getwidth(this) implicit none class (rectangle_type) , intent(in) :: this getwidth=this%width_ end function getwidth subroutine setwidth(this,width) implicit none class (rectangle_type) , intent(inout) :: this integer , intent(in) :: width this%width_=width end subroutine setwidth integer function getheight(this) implicit none class (rectangle_type) , intent(in) :: this getheight=this%height_ end function getheight subroutine setheight(this,height) implicit none class (rectangle_type) , intent(inout) :: this integer , intent(in) :: height this%height_=height end subroutine setheight subroutine draw_rectangle(this) implicit none class (rectangle_type), intent(in) :: this print *,' x = ' , this%x_ print *,' y = ' , this%y_ print *,' width = ' , this%width_ print *,' height = ' , this%height_ end subroutine draw_rectangle end module rectangle_module -Original Message- From: burnus at gcc dot gnu dot org [mailto:gcc-bugzi...@gcc.gnu.org] Sent: 08 June 2010 14:01 To: i...@rhymneyconsulting.co.uk Subject: [Bug fortran/44465] [OOP] ICE with polymorphic object oriented example --- Comment #1 from burnus at gcc dot gnu dot org 2010-06-08 13:00 --- (In reply to comment #0) c:\document\fortran\newbook\examples\ch32gfortran shape_p.f90 circle_p.f90 rectangle_p.f90 polymorph_array.f90 polymorph_array.f90: In function 'polymorphic': polymorph_array.f90:18:0: internal compiler error: Segmentation fault Do you
[Bug fortran/44465] [OOP] ICE with polymorphic object oriented example
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-08 13:53 --- Valgrind shows: ==26969== Invalid read of size 4 ==26969==at 0x553131: gfc_conv_scalarized_array_ref (trans-array.c:2494) ==26969==by 0x553824: gfc_conv_array_ref (trans-array.c:2547) ==26969==by 0x572CE0: gfc_conv_variable (trans-expr.c:698) ==26969==by 0x56F8E9: gfc_conv_procedure_call (trans-expr.c:1523) ==26969==by 0x58CF62: gfc_trans_call (trans-stmt.c:375) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2010-06-08 13:53:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44465
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #5 from martin at mpa-garching dot mpg dot de 2010-06-08 13:54 --- (In reply to comment #2) We have (4.4): bb 2: va.f[0] = a-r; va.f[1] = a-g; va.f[2] = a-b; va.f[3] = 0.0; pretmp.40 = va.v; ivtmp.61 = 0; [...] Could you please tell me the compiler flag(s) needed to produce this kind of information? That seems much more useful for debugging and chasing performance bottlenecks than assembler dumps... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-08 14:02 --- (In reply to comment #5) (In reply to comment #2) We have (4.4): bb 2: va.f[0] = a-r; va.f[1] = a-g; va.f[2] = a-b; va.f[3] = 0.0; pretmp.40 = va.v; ivtmp.61 = 0; [...] Could you please tell me the compiler flag(s) needed to produce this kind of information? That seems much more useful for debugging and chasing performance bottlenecks than assembler dumps... -fdump-tree-all will leave you with a hunded dump files, program state after each individual tree optimization pass. -da will add dumps after each RTL pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP
--- Comment #17 from sfilippone at uniroma2 dot it 2010-06-08 14:09 --- (In reply to comment #16) (In reply to comment #14) The attached variation of generic_23 still does not work. [sfili...@donald bug15]$ ./generic_23_1 FOO%DOIT base version Aborted (core dumped) (In reply to comment #15) Created an attachment (id=20853) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20853action=view) [edit] REOPEN as the issue of the attachment is different from PR 44434; it uses allocatable scalars and might be thus yet another problem. I should probably add that in my full code I am seeing failures in cases where the variable is not allocatable (i.e. similar to the already existing tests in generic_23). There is something very fishy here. Salvatore -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
[Bug fortran/44465] [OOP] ICE with polymorphic object oriented example
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-08 14:22 --- Actually this seems to be a duplicate of PR 44211. It is fixed by the patch I submitted yesterday: http://gcc.gnu.org/ml/fortran/2010-06/msg00060.html The patch has been approved by Tobias, and I will commit it once the trunk is unfrozen again. *** This bug has been marked as a duplicate of 44211 *** -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44465
[Bug fortran/44211] [OOP] ICE with TBP of pointer component of derived type array
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-08 14:22 --- *** Bug 44465 has been marked as a duplicate of this bug. *** -- janus at gcc dot gnu dot org changed: What|Removed |Added CC||ian at rhymneyconsulting dot ||co dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44211
[Bug pch/40272] error using precompiled headers with extra debug info (-g3)
--- Comment #3 from jay dot foad at gmail dot com 2010-06-08 14:24 ---
I've just seen this too:
$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
[...]
$ cat a.h
void a(void);
$ cat b.h
#include a.h
$ cat b.c
#include b.h
void b(void) {}
$ gcc -c -g3 a.h
$ gcc -c -g3 b.c
/tmp/ccpqcXiZ.s: Assembler messages:
/tmp/ccpqcXiZ.s:429: Error: file number 2 already allocated
--
jay dot foad at gmail dot com changed:
What|Removed |Added
CC||jay dot foad at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40272
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-06-08 14:29 --- I don't think I can fix this bug in its most general form without doing some flow-sensitive decisions (which can be difficult for aggregates) and without causing PR 43846 again. (Aggregate copy-propagation and either of the two things described below should do the trick, though). As noted, this is caused by a fix to PR 43846 which on the other hand is certainly not necessary for non-aggregate types when we do type punning of register types through unions. I've got a two line patch testing that and it works (and bootstraps and tests) fine. However, that is only a change in the new heuristics and if the array elements are individually read somewhere else in the function too, a different decision making condition will kick in and we will end up with the replacements and extra statements in the loop again. Therefore, I now tend to think that these accesses to SSE vectors are a good reason to simply disallow scalarization of anything that has a non-aggregate parent in the SRA access tree. This would only affect type punning through unions and weird typecasts (none of which could be processed by previous SRA). Actually, I had this disallowed when I was developing the new SRA most of the time and then decided to allow it only very late. I don't remember why I did that. I'm now testing a patch doing that, maybe some testcase will remind me what the reason was. I will ponder about this a bit more but probably will soon submit a patch doing the latter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug tree-optimization/44336] [4.4/4.5/4.6 Regression] ICE: verify_ssa failed: SSA_NAME_DEF_STMT is wrong with -fipa-struct-reorg -fwhole-program
--- Comment #2 from zsojka at seznam dot cz 2010-06-08 14:41 --- Created an attachment (id=20867) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20867action=view) different testcase This testcase fails with similiar message: $ gcc -O1 -fipa-struct-reorg -fwhole-program pr44336-2.c pr44336-2.c: In function 'main': pr44336-2.c:11:1: error: SSA_NAME_DEF_STMT is wrong Expected definition statement: # .MEM_4 = VDEF .MEM_3 D.2721_1 = foo (s.0); Actual definition statement: # .MEM_3 = VDEF .MEM_2(D) D.2721_1 = foo (s); pr44336-2.c:11:1: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Fails in 4.4 r158133 and 4.5 r158978 too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44336
[Bug bootstrap/44469] New: [4.5/4.6 Regression] internal compiler error: in fixup_reorder_chain, at cfglayout.c:797
Target: armv7l-unknown-linux-gnueabi Configured with: ../gcc-4_5-branch/configure --prefix=/home/ssvb/gcc-test/bin --target=armv7l-unknown-linux-gnueabi --enable-languages=c --without-headers Thread model: posix gcc version 4.5.1 20100607 (prerelease) (GCC) $ armv7l-unknown-linux-gnueabi -O2 testcase.i testcase.i: In function a: testcase.i:15:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:797 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This bug prevents bootstrap on ARM when configured with '--disable-checking' option. Also see PR42347 comment 28 -- Summary: [4.5/4.6 Regression] internal compiler error: in fixup_reorder_chain, at cfglayout.c:797 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: siarhei dot siamashka at gmail dot com GCC target triplet: armv7l-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44469
[Bug bootstrap/44469] [4.5/4.6 Regression] internal compiler error: in fixup_reorder_chain, at cfglayout.c:797
--- Comment #1 from siarhei dot siamashka at gmail dot com 2010-06-08 14:45 --- Created an attachment (id=20868) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20868action=view) testcase.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44469
[Bug bootstrap/42347] [4.5/4.6 Regression] sched-deps.c:3840:1: internal compiler error: in fixup_reorder_chain, at cfglayout.c:796
--- Comment #30 from siarhei dot siamashka at gmail dot com 2010-06-08 14:49 --- (In reply to comment #29) Please file a new PR for that, with preprocessed source and all other relevant info for reproduction. Thanks, filed PR44469 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-08 14:50 --- I don't think you need flow-sensitivity. Basically when you have only aggregate uses (as in this case) then you only want to scalarize if the destination of the use is scalarized as well (to be able to copyprop out the aggregate copy). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug bootstrap/44469] [4.5/4.6 Regression] internal compiler error: in fixup_reorder_chain, at cfglayout.c:797
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44469
[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64
--- Comment #3 from dgohman at gmail dot com 2010-06-08 14:54 --- Callers of compare are already exposed to __builtin_memcmp result values (with default traits) which vary depending on the target and compiler flags. And since _S_compare is only used as a tie-breaker after the memcmp, it's hard to imagine any code innocently relying on it returning a particular value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44413
[Bug tree-optimization/44468] [4.3/4.4/4.5/4.6 Regression] Bogus access re-construction from offset calculation
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|Bogus access re-construction|[4.3/4.4/4.5/4.6 Regression] |from offset calculation |Bogus access re-construction ||from offset calculation Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44468
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #9 from jamborm at gcc dot gnu dot org 2010-06-08 15:00 --- (In reply to comment #8) I don't think you need flow-sensitivity. Basically when you have only aggregate uses (as in this case) Vectors are considered scalars in GCC. That is why the solutions described above work. then you only want to scalarize if the destination of the use is scalarized as well (to be able to copyprop out the aggregate copy). Well, that is what I thought until someone filed PR 43846. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-08 15:09 --- I'm not convinced. The code at issue is used when memcmp returns zero, thus one string is a prefix of the other, a well defined situation. For *eons* we have been returning a number which is much larger (in modulo) if one string is much longer. Before considering changing this, I want to see a very solid real life example, with numbers, of code benefiting from this tuning. Otherwise, I guess we'll do it, but only when we'll break the ABI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44413
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-06-08 15:11 --- (In reply to comment #9) (In reply to comment #8) I don't think you need flow-sensitivity. Basically when you have only aggregate uses (as in this case) Vectors are considered scalars in GCC. That is why the solutions described above work. then you only want to scalarize if the destination of the use is scalarized as well (to be able to copyprop out the aggregate copy). Well, that is what I thought until someone filed PR 43846. Hm, yes. But there you know that D.2464.m[0] = D.2473_20; D.2464.m[1] = D.2472_19; D.2464.m[2] = D.2471_18; *b_1(D) = D.2464; D.2464 will be dead after scalarization. In the particular case of the current bug the aggregate remains live because of the load from va.v which we cannot scalarize(*). (*) we can scalarize this particular case if you manage to build a proper constructor from the elements - but that's probably a bit involved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #35 from Kyle dot D dot Moffett at boeing dot com 2010-06-08 15:23 --- Hrm, well PPL still seems to be failing the interval1 test, but I'm not sure that one's related as the part that fails is test01float. More info to come shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug middle-end/42574] [4.3/4.4/4.5/4.6 Regression] Address of global variable is calculated multiple times (missed CSE)
--- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2010-06-08 15:24
---
Steven, I'm shamelessly stealing this PR from you.
There are two sides to this missed optimization:
1. Calculation of PIC address is not CSE'd; this is the same as PR42495 and
will be fixed there.
2. Constant 400, which expands to 2 instructions is not CSE'd.
After addressing the first issue, the second problem can be fixed by asking
hoist to CSE complicated constants and making sure that RA will rematerialize
them instead of spilling under high register pressure.
We can define a constant complicated if it takes a PARALLEL -- (parallel
[(set (reg1) (const)) (clobber reg2)]) -- to set it; this is a common way of
defining instructions that should be split later and require a temporary
register to hold intermediate value.
I'm now testing a patch that makes ARM backend to expand constants into
parallels instead of sequences of two instructions and tweaking hoist to gcse
complicated const_int's.
The result is the following:
test:
push{r4, r5, r6, lr}
ldr r3, .L3
ldr r2, .L3+4
.LPIC0:
add r3, pc
ldr r5, [r3, r2]
mov r4, #200
lsl r4, r4, #1
mov r6, r0
ldr r0, [r5, r4]
bl func1
ldr r0, [r5, r4]
mov r1, r6
bl func2
cmp r0, #0
beq .L2
bl func
.L2:
ldr r0, [r5, r4]
bl func3
@ sp needed for prologue
pop {r4, r5, r6, pc}
.L4:
.align 2
.L3:
.word _GLOBAL_OFFSET_TABLE_-(.LPIC0+4)
.word glob(GOT)
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |mkuvyrkov at gcc dot gnu dot
|org |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42574
[Bug rtl-optimization/40615] unnecessary CSE
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
[Bug rtl-optimization/42500] Unnecessary mov of sp to a register
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42500
[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-08 15:59 --- Let's do this change first in ext/vstring and let's see how people react. In that case we also have the advantage that nothing is exported from the *.so, thus old code linking to the new lib will not risk behaving differently all of a sudden. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44413
[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
--- Comment #21 from changpeng dot fang at amd dot com 2010-06-08 16:23 --- Just for the record, non-constant step prefetching improves 459.GemsFDTD by 5.5% (under -O3 + prefetch) on amd-linux64 systems. And the gains are from the following set of loops: NFT.fppized.f90:1268 NFT.fppized.f90:1227 NFT.fppized.f90:1186 NFT.fppized.f90:1148 NFT.fppized.f90:1109 NFT.fppized.f90:1072 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug tree-optimization/44393] [4.5/4.6 Regression] ICE: verify_ssa failed: no immediate_use list with -Os -ftree-loop-distribution
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-08 16:47 --- It is caused by revision 145494: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00115.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-08 16:47:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44393
[Bug tree-optimization/44393] [4.5/4.6 Regression] ICE: verify_ssa failed: no immediate_use list with -Os -ftree-loop-distribution
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-08 17:33 --- Whatever. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-06-08 16:47:23 |2010-06-08 17:33:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44393
[Bug libstdc++/43838] Incorrect output from abi::__cxa_demangle
--- Comment #3 from slawomir at ezono dot com 2010-06-08 17:55 --- Created an attachment (id=20869) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20869action=view) simpler example Preprocessed source of simpler program. The only #include used was typeinfo which is needed in order to compile with g++ -- slawomir at ezono dot com changed: What|Removed |Added Attachment #20456|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
[Bug libstdc++/43838] Incorrect output from abi::__cxa_demangle
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-08 17:57 --- Excellent, thanks a lot. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-08 17:57:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
[Bug libstdc++/43838] Incorrect output from abi::__cxa_demangle
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-08 18:02 --- I also double checked that indeed the last null_type appears truncated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
[Bug libstdc++/43838] Incorrect output from abi::__cxa_demangle
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-08 18:05 --- Ian, any idea what may be happening here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
[Bug tree-optimization/39874] [4.4 regression] missing VRP (submission)
--- Comment #5 from sandra at gcc dot gnu dot org 2010-06-08 18:16 --- Subject: Bug 39874 Author: sandra Date: Tue Jun 8 18:15:53 2010 New Revision: 160445 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160445 Log: 2010-06-08 Sandra Loosemore san...@codesourcery.com PR tree-optimization/39874 PR middle-end/28685 gcc/ * gimple.h (maybe_fold_and_comparisons, maybe_fold_or_comparisons): Declare. * gimple-fold.c (canonicalize_bool, same_bool_comparison_p, same_bool_result_p): New. (and_var_with_comparison, and_var_with_comparison_1, and_comparisons_1, and_comparisons, maybe_fold_and_comparisons): New. (or_var_with_comparison, or_var_with_comparison_1, or_comparisons_1, or_comparisons, maybe_fold_or_comparisons): New. * tree-ssa-reassoc.c (eliminate_redundant_comparison): Use maybe_fold_and_comparisons or maybe_fold_or_comparisons instead of combine_comparisons. * tree-ssa-ifcombine.c (ifcombine_ifandif, ifcombine_iforif): Likewise. gcc/testsuite/ * gcc.dg/pr39874.c: New file. Added: trunk/gcc/testsuite/gcc.dg/pr39874.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/gimple.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ifcombine.c trunk/gcc/tree-ssa-reassoc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39874
[Bug middle-end/28685] Multiple comparisons are not simplified
--- Comment #16 from sandra at gcc dot gnu dot org 2010-06-08 18:16 --- Subject: Bug 28685 Author: sandra Date: Tue Jun 8 18:15:53 2010 New Revision: 160445 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160445 Log: 2010-06-08 Sandra Loosemore san...@codesourcery.com PR tree-optimization/39874 PR middle-end/28685 gcc/ * gimple.h (maybe_fold_and_comparisons, maybe_fold_or_comparisons): Declare. * gimple-fold.c (canonicalize_bool, same_bool_comparison_p, same_bool_result_p): New. (and_var_with_comparison, and_var_with_comparison_1, and_comparisons_1, and_comparisons, maybe_fold_and_comparisons): New. (or_var_with_comparison, or_var_with_comparison_1, or_comparisons_1, or_comparisons, maybe_fold_or_comparisons): New. * tree-ssa-reassoc.c (eliminate_redundant_comparison): Use maybe_fold_and_comparisons or maybe_fold_or_comparisons instead of combine_comparisons. * tree-ssa-ifcombine.c (ifcombine_ifandif, ifcombine_iforif): Likewise. gcc/testsuite/ * gcc.dg/pr39874.c: New file. Added: trunk/gcc/testsuite/gcc.dg/pr39874.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/gimple.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ifcombine.c trunk/gcc/tree-ssa-reassoc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28685
[Bug libffi/42275] pkg-config (.pc) file missing in libffi (lost during import)
--- Comment #2 from ensonic at hora-obscura dot de 2010-06-08 19:16 --- There are even patches flying around on the net for this, please! http://www.mail-archive.com/pld-cvs-com...@lists.pld-linux.org/msg178946.html -- ensonic at hora-obscura dot de changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42275
[Bug middle-end/44297] Big spec cpu2006 prefetch regressions on gcc 4.6 on x86
--- Comment #22 from borntraeger at de dot ibm dot com 2010-06-08 19:42 --- I bootstrapped with patches 0002 and 0003. The results are also good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44297
[Bug libffi/42275] pkg-config (.pc) file missing in libffi (lost during import)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42275
[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-06-08 19:55 --- There is no specifications for plugins really. And really this is on purpose as we don't want to freeze down the rest of the compiler just for plugins. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
[Bug tree-optimization/44462] Redundant looping pure functions whose return value is dead are not optimized out
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-08 20:10 --- Why do we remove register LHS in DCE again? Because it reduces the amount of garbage produced by expand :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44462
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #36 from Kyle dot D dot Moffett at boeing dot com 2010-06-08 20:34 --- Ok, I'm pretty sure this is unrelated to this bug, but I still get one test-failure with PPL 0.10.2. The interval1 test fails due to the test01float subtest, apparently due to very slightly excessive float rounding errors (after 100 rounds of the equivalent of x = (x + (2/x)) / 2 it approximates ~0.02% past the maximum acceptable error bounds). The double testcase passes just fine (although with the same error bounds and extra precision that seems perfectly reasonable). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-06-08 20:34 --- (In reply to comment #5) There is no specifications for plugins really. And really this is on purpose as we don't want to freeze down the rest of the compiler just for plugins. There is a difference between freezing the rest of the compiler and making reasonable adaptations to avoid unnecessary interface churn / cross-language linking issues. I intend to apply the approved patch to gcc-plugin.h on Wednesday (we are supposedly still in a trunk freeze right now, even though I have seen a few non-merge patches going in). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
[Bug fortran/43040] Wrong decl for mathbuiltins - wrong code with LTO
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2010-06-08 20:39 --- I'm currently looking at math builtins for __float128 support, so I'll check that. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-02-12 11:07:37 |2010-06-08 20:39:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43040
[Bug fortran/32049] Support on x86_64 also kind=16
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-06-02 07:37:11 |2010-06-08 20:42:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32049
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-08 20:52 --- (In reply to comment #1) A patch is here: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01200.html This is an update of the patch to revision 160389: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00822.html -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.5.0 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-06-08 20:52:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug bootstrap/44470] New: [4.6 Regression] Failed to bootstrap with - -with-arch=atom
Revision 160417 failed to compile libgcc:
[...@gnu-32 rrs]$ cat testcase.i
typedef int SItype __attribute__ ((mode (SI)));
typedef unsigned int USItype __attribute__ ((mode (SI)));
typedef int DItype __attribute__ ((mode (DI)));
struct DWstruct {SItype low, high;};
typedef union
{
struct DWstruct s;
DItype ll;
} DWunion;
DItype
__negdi2 (DItype u)
{
const DWunion uu = {.ll = u};
const DWunion w = { {.low = -uu.s.low,
.high = -uu.s.high - ((USItype) -uu.s.low 0) } };
return w.ll;
}
[...@gnu-32 rrs]$ /export/gnu/import/rrs/160417/usr/bin/gcc -m32 -march=atom
-O2 -fPIC -S testcase.i
testcase.i: In function __negdi2:
testcase.i:17: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.
[...@gnu-32 rrs]$
--
Summary: [4.6 Regression] Failed to bootstrap with - -with-
arch=atom
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
[Bug fortran/44471] New: Wrong call with variadic declaration
Reported by Jakub. gfortran -O2 -fwhole-file generates a variadic call to bar_. (The decl of the procedure itself is OK.) Expected: a) With -fwhole-file, the actual declaration should be used. b) As Fortran does not support variadic calls at all, there should be never variatic calls be generated. (variadic calls are those whose prototype ends in C with ...; when generating the argument list with build_function_type_list the function is always non-variadic (cf. also build_varargs_function_type_list) - if one generates the argument list manually, the last argument should be VOID_TYPE.) * * * subroutine bar (a, n) integer :: n, a(*) end subroutine bar subroutine foo (b, n) integer :: n, b(n) n = 6 call bar (b, 5) b(1:5) = 0 end subroutine foo * * * How to test (thanks to Jakub for the list of options): a) x86_64 (for non floating points): Assembler has xorl %eax, %eax before the call (i.e. the variadic function has no floating-point arguments) b) In a debugger: b var-tracking.c:8357 if insn-code == CALL_INSN (which is if (INSN_P (insn)) in vt_initialize) -- and then: debug_rtx (insn) -- Summary: Wrong call with variadic declaration Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44471
[Bug bootstrap/44458] Bootstrap fails on arm_float_words_big_endian implicit declaration when Ada on arm-linux
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-08 21:51:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44458
[Bug bootstrap/44335] [4.6 regression] gcc-4.6-20100529 java bootstrap failure on arm-linux-gnueabi
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-08 21:51:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44335
[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-08 22:00 --- It may be broken by revision 160394: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||uros Summary|[4.6 Regression] Failed to |[4.6 Regression] Failed to |bootstrap with - -with- |bootstrap with - -with- |arch=atom |arch=atom http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
[Bug bootstrap/44432] [boot with C++] configure does not check presence of host C++ compiler
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-08 22:50 --- A patch is here: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00835.html -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2010-06-08 22:50:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44432
[Bug bootstrap/44433] [meta-bug] --enable-build-with-cxx issues
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-08 23:15 --- I think PR44362 no longer block adoption of --enable-build-with-cxx in trunk, since the C++ part of the patch for that PR was checked in. It might sense to keep it in the dependency list if we need this to backport the fixes into a branch, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44433
[Bug plugins/44459] plugin interface depends on name mangling
--- Comment #7 from amylaar at gcc dot gnu dot org 2010-06-08 23:21 --- Subject: Bug 44459 Author: amylaar Date: Tue Jun 8 23:21:48 2010 New Revision: 160448 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160448 Log: PR plugins/44459: * gcc-plugin.h: Encapsulate all declarations in extern C. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc-plugin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44459
[Bug target/44067] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713
--- Comment #9 from amodra at gcc dot gnu dot org 2010-06-09 00:16 --- Subject: Bug 44067 Author: amodra Date: Wed Jun 9 00:15:46 2010 New Revision: 160449 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160449 Log: PR target/44067 * config/rs6000/rs6000.md (DIFD): Do not split dpfp values for e500v2 target. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44067
[Bug target/44067] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713
--- Comment #10 from amodra at gcc dot gnu dot org 2010-06-09 00:20 --- Subject: Bug 44067 Author: amodra Date: Wed Jun 9 00:20:27 2010 New Revision: 160454 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160454 Log: PR target/44067 * config/rs6000/rs6000.md (DIFD): Do not split dpfp values for e500v2 target. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/rs6000/rs6000.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44067
[Bug target/44067] internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16713
--- Comment #11 from amodra at gmail dot com 2010-06-09 00:29 --- Fixed -- amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44067
