[Bug libfortran/30007] libgfortran doesn't build for sh-elf
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-02-04 10:30 --- Subject: Bug 30007 Author: fxcoudert Date: Sun Feb 4 10:30:17 2007 New Revision: 121569 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121569 Log: PR libfortran/30007 * libgfortran.h: Do not prefix symbol name with __USER_LABEL_PREFIX__ when used in __attribute__((__alias__(...))). Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/libgfortran.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30007
[Bug libfortran/30007] libgfortran doesn't build for sh-elf
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-02-04 10:30 --- Fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30007
[Bug ada/30698] New: in expand_one_stack_var_at, at cfgexpand.c:517
[EMAIL PROTECTED]:~/dns/src$ gnatmake dnsbrowse_gtk `gtkada2-config` gcc-4.1 -c -I/usr/share/ada/adainclude/gtkada2 dnsbrowse_gtk.adb gcc-4.1 -c -I/usr/share/ada/adainclude/gtkada2 communication.adb +===GNAT BUG DETECTED==+ | 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) (i486-pc-linux-gnu) GCC error:| | in expand_one_stack_var_at, at cfgexpand.c:517 | | Error detected at communication.adb:100:8| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.1 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. communication.adb communication.ads dns.ads dns-question.ads communication.adb:17:07: warning: Storage_Error will be raised at run-time compilation abandoned gnatmake: communication.adb compilation error [EMAIL PROTECTED]:~/dns/src$ with Ada.Unchecked_Conversion; with Text_Io; use Text_Io; with Dns.Question; use Dns.Question; package body Communication is package Integer_Io is new Text_Io.Integer_Io(Integer); use Integer_Io; procedure init is begin null; end Init; procedure Send_request is Address : Sock_Addr_Type; Channel : Stream_Access; Port_Dns : Constant := 53; Names : Name_Type; Question : Question_Type; begin Address.Addr := Addresses (Get_Host_By_Name (Host_Name), 1); Address.Port := Port_dns; Names := Dns.Name(rho073.mtke.chalmers.se); Create_Socket(Socket); Connect_Socket(Socket, Address); Put(Nameserver ); Put_Line(Image(Address)); -- print the hosts ip-number:port-number Channel := Stream(Socket); Question := (Dns.Header_Type'(Id = 23, Qr = Dns.Query, Opcode = Dns.Query, Aa = Dns.No, Tc = Dns.No, Rd = Dns.Yes, Ra = Dns.No, Z = Dns.No, Rcode = Dns.No_Error, others = 0), Qname = Names, Qtype = A, Qclass = Internet); Put_Line(Har sänt väntar på svar); --declare -- Svar : Dns_Header_Type; -- Adresses : Octet_Array_Ptr; -- Tmp : Octet4_Array_Ptr; -- Tmp2 : Label_Ptr; --begin -- Dns.Io.Functions.Read(Channel, Svar); -- Put(Har fått svar);New_Line; -- Put(id:);Put(Integer(Svar.Id));New_Line; -- if Svar.Question /= null then -- Put(Questions:);Put(Svar.Question'Length);New_Line; -- for N in Svar.Question'Range loop -- Put( names: ); -- for I in Svar.Question(N).Qname'Range loop --Put(String(Svar.Question(N).Qname(I).all));Put(.); -- end loop; -- New_Line; -- end loop; -- end if; -- if Svar.Answer /= null then -- Put(answers:);Put(Svar.Answer'Length);New_Line; -- for N in Svar.Answer'Range loop -- Put( names: ); -- for I in Svar.Answer(N).Names'Range loop --Put(String(Svar.Answer(N).Names(I).all));Put(.); -- end loop; -- Put( ); -- Adresses := Svar.Answer(N).Rdata;Tmp:=Read_A(Svar.Answer(N)); -- for I in Adresses'Range loop --Put(Integer(Adresses(I)));Put(.); -- end loop; -- New_Line; -- end loop; -- end if; -- if Svar.Authority /= null then -- Put(Authorities:);Put(Svar.Authority'Length);New_Line; -- for N in Svar.Authority'Range loop -- Put( Authority ); -- for I in Svar.Authority(N).Names'Range loop --Put(String(Svar.Authority(N).Names(I).all));Put(.); -- end loop; -- Put( ); -- -- Tmp2:=Read_A(Svar.Authority(N)); -- -- for I in Tmp2'Range loop -- --Put(String(Tmp2(I).all)); -- -- end loop; -- New_Line; -- end loop; -- end if; -- if Svar.Additional /= null then -- Put(Additionals:);Put(Svar.Additional'Length);New_Line; --
[Bug ada/30699] New: in expand_one_stack_var_at, at cfgexpand.c:517
[EMAIL PROTECTED]:~/dns/src$ gnatmake dnsbrowse_gtk `gtkada2-config` gcc-4.1 -c -I/usr/share/ada/adainclude/gtkada2 dnsbrowse_gtk.adb gcc-4.1 -c -I/usr/share/ada/adainclude/gtkada2 communication.adb +===GNAT BUG DETECTED==+ | 4.1.2 20061028 (prerelease) (Debian 4.1.1-19) (i486-pc-linux-gnu) GCC error:| | in expand_one_stack_var_at, at cfgexpand.c:517 | | Error detected at communication.adb:100:8| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.1 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. communication.adb communication.ads dns.ads dns-question.ads communication.adb:17:07: warning: Storage_Error will be raised at run-time compilation abandoned gnatmake: communication.adb compilation error [EMAIL PROTECTED]:~/dns/src$ -- Summary: in expand_one_stack_var_at, at cfgexpand.c:517 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: karlnick at student dot chalmers dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30699
[Bug ada/30699] in expand_one_stack_var_at, at cfgexpand.c:517
--- Comment #1 from karlnick at student dot chalmers dot se 2007-02-04 10:44 --- Created an attachment (id=13004) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13004action=view) Source files -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30699
[Bug bootstrap/30678] sysmacros.h get currupt from Fixincludes with updated glibc.
--- Comment #8 from ron3763 at msn dot com 2007-02-04 11:31 --- Well it worked, in a testing svn/update/export/patch.. rest of gentoo build. Now I am back to dying where I did/was before. Compiling C++ library. Who to contact/group. Here is a portion for a quick glance as to whom/how/catagory to open a new bug. Thank you. Ron == var/tmp/portage/sys-devel/gcc-4.3.98/work/build/./gcc/xgcc -shared-libgcc -B/var/tmp/portage/sys-devel/gcc-4.3.98/work/build/./gcc -nostdinc++ -L/var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -I/var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/var/tmp/portage/sys-devel/gcc-4.3.98/work/gcc-4.3.98/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -pipe -fomit-frame-pointer -O2 -march=core2 -mtune=core2 -mssse3 -frename-registers -fweb -ftracer -D_GNU_SOURCE -c /var/tmp/portage/sys-devel/gcc-4.3.98/work/gcc-4.3.98/libstdc++-v3/src/pool_allocator.cc -o pool_allocator.o /dev/null 21 In file included from /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++locale.h:48, from /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/iosfwd:45, from /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:71, from /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/char_traits.h:46, from /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/string:46, from /var/tmp/portage/sys-devel/gcc-4.3.98/work/gcc-4.3.98/libstdc++-v3/src/compatibility.cc:49: /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:101: error: '::fpos_t' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:103: error: '::clearerr' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:104: error: '::fclose' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:105: error: '::feof' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:106: error: '::ferror' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:107: error: '::fflush' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:108: error: '::fgetc' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:109: error: '::fgetpos' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:110: error: '::fgets' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:111: error: '::fopen' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:112: error: '::fprintf' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:113: error: '::fputc' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:114: error: '::fputs' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:115: error: '::fread' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:116: error: '::freopen' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:117: error: '::fscanf' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:118: error: '::fseek' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:119: error: '::fsetpos' has not been declared /var/tmp/portage/sys-devel/gcc-4.3.98/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/cstdio:120: error: '::ftell' has not been declared
[Bug fortran/30689] equivalence modifies common block
--- Comment #6 from pault at gcc dot gnu dot org 2007-02-04 12:03 --- I think that we can close this one, OK? I've marked it as invalid, although that seems a trifle unfair. Please feel post bugs if you find them - we would rather discuss PRs like this one than have disatisfied users out there! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30689
[Bug fortran/30554] [4.2 and 4.1 only] ICE in mio_pointer_ref at module.c:1945
--- Comment #11 from pault at gcc dot gnu dot org 2007-02-04 12:05 --- PS I need to examine the part of the standard that deals with PRIVATE and PUBLIC in modules to see if this really is right. I should have said, even if it is not correct, this clearly is touching the right place and must be nearly OK. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30554
[Bug fortran/30660] [4.2 and 4.1 only] Allocatable components of a derived type require the SAVE attribute.
--- Comment #5 from toon at moene dot indiv dot nluug dot nl 2007-02-04 13:17 --- It's not completely fixed yet, though. The following: MODULE types_m TYPE coord_t INTEGER ncord REAL,ALLOCATABLE,DIMENSION(:) :: x, y END TYPE TYPE grib_t INTEGER ksec0(2), ksec1(64), ksec2(64), ksec3(2), ksec4(64) REAL psec2(512), psec3(3) LOGICAL packed ! if packed then the data are stored in g_work INTEGER npts REAL,DIMENSION(:),ALLOCATABLE :: vdata TYPE(coord_t) coords END TYPE END MODULE MODULE globals_m USE types_m TYPE(grib_t) g_dest ! output field END MODULE still fails with: globals.f90:21.21: TYPE(grib_t) g_dest ! output field 1 Error: Object 'g_dest' at (1) must have the SAVE attribute for default initialization of a component probably because of the nested nature of the allocatable component in coord_t. Hope this helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30660
[Bug bootstrap/30620] missing dependencies of gcov-io.h breaks --enable-intermodule build
--- Comment #2 from aldot at gcc dot gnu dot org 2007-02-04 14:53 --- 4.1.2 prerelease-20070128 fails on --enable-intermodule too: buildroot.arm/toolchain_build_arm/gcc-4.1.2-20070128/gcc/config/arm/arm.c -o lib backend.o \ -DBASEVER=\4.1.2\ -DDATESTAMP=\ 20070129\ \ -DDEVPHASE=\ (prerelease)\ -combine In file included from /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc- 4.1.2-20070128/gcc/coverage.h:25, from /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc- 4.1.2-20070128/gcc/coverage.c:42: /scratch/obj.x86_64/buildroot.arm/toolchain_build_arm/gcc-4.1.2-20070128/gcc/gco v-io.h:284:22: error: gcov-iov.h: No such file or directory -- aldot at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 |4.2.0 4.1.2 Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30620
[Bug middle-end/30636] [4.3 Regression] incorrect array bounds warning on multi-dimensional arrays
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-02-04 15:15 --- Subject: Bug 30636 Author: rguenth Date: Sun Feb 4 15:15:38 2007 New Revision: 121575 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121575 Log: 2007-02-04 Richard Guenther [EMAIL PROTECTED] PR middle-end/30636 * fold-const.c (try_move_mult_to_index): Make sure to not overflow one dimension of a multi-dimensional array access. * g++.dg/warn/pr30636.C: New testcase. * g++.dg/tree-ssa/tmmti-2.C: XFAIL parts. Added: trunk/gcc/testsuite/g++.dg/warn/pr30636.C Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/tree-ssa/tmmti-2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30636
[Bug middle-end/30636] [4.3 Regression] incorrect array bounds warning on multi-dimensional arrays
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-02-04 15:16 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30636
[Bug bootstrap/30620] missing dependencies of gcov-io.h breaks --enable-intermodule build
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.1.2 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30620
[Bug middle-end/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-02-04 15:28 --- Subject: Bug 27657 Author: rguenth Date: Sun Feb 4 15:27:53 2007 New Revision: 121576 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121576 Log: 2007-02-04 Richard Guenther [EMAIL PROTECTED] Backport from mainline: 2007-01-30 Richard Guenther [EMAIL PROTECTED] PR middle-end/27657 * dwarf2out.c (reference_to_unused): Query varpool if the variable was output. * g++.dg/debug/pr27657.C: New testcase. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/debug/pr27657.C - copied unchanged from r121335, trunk/gcc/testsuite/g++.dg/debug/pr27657.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/dwarf2out.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug middle-end/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-02-04 15:29 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug ada/30698] in expand_one_stack_var_at, at cfgexpand.c:517
--- Comment #1 from schwab at suse dot de 2007-02-04 15:47 --- *** This bug has been marked as a duplicate of 30699 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|in expand_one_stack_var_at, |in expand_one_stack_var_at, |at cfgexpand.c:517 |at cfgexpand.c:517 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30698
[Bug ada/30699] in expand_one_stack_var_at, at cfgexpand.c:517
--- Comment #2 from schwab at suse dot de 2007-02-04 15:47 --- *** Bug 30698 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30699
[Bug libgcj/30606] [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-04 16:00 --- Subject: Re: [4.3 Regression] natVMURLConnection.cc:21: error: 'magic_t' does not name a type With the above patch, the problem still exists but it's moved to a different file: /usr/ccs/bin/ld: CODE_ONE_SYM fixup to non-code subspace in file gnu/javax/swing /text/html/parser/.libs/HTML_401F.o - shared library must be position independen t. Use +z or +Z to recompile. Please try with revision 121506 or later. That may fix this problem. Sadly, it didn't fix the problem. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30606
[Bug target/30259] ICE on valid code
--- Comment #5 from guenter at roeck-us dot net 2007-02-04 16:40 --- Problem is seen with 4.1.2 release candidate. Build is successful with proposed patch for bug 30270 applied. Not really my call to make, but it appears that this is neither P3 nor severity normal. Also, the status of unconfirmed appears to be inappropriate, as the problem is easy to reproduce. -- guenter at roeck-us dot net changed: What|Removed |Added CC||guenter at roeck-us dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30259
[Bug target/30634] FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-04
17:06 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
My patch just exposed a latent bug. Does this fail on the trunk also the same
way? If not can you trace to see where the difference in the IR between the
4.2 branch and trunk show up?
This is the rtl after expansion that's a problem:
(insn 84 82 87 14 (set (reg:DI 76 [ equiv.1 ])
(const_int 4503599627370495 [0xf])) -1 (nil)
(nil))
(insn 87 84 88 14 (set (reg:DF 32 %fr4)
(subreg:DF (reg:DI 76 [ equiv.1 ]) 0)) -1 (nil)
(nil))
After greg, we have:
(note 84 82 239 11 NOTE_INSN_DELETED)
(insn 239 84 87 11 (set (reg:DF 32 %fr4 [ equiv.1 ])
(mem/u/c/i:DF (symbol_ref/u:DI (*L$C0007) [flags 0x2]) [0 S8 A64]))
-1 (nil)
(nil))
(insn 87 239 88 11 (set (reg:DF 32 %fr4 [ equiv.1 ])
(reg:DF 32 %fr4 [ equiv.1 ])) 122 {*pa.md:4332} (insn_list:REG_DEP_TRUE
84 (nil))
(expr_list:REG_DEAD (reg:DI 76 [ equiv.1 ])
(expr_list:REG_EQUAL (const_double:DF
2.22507385850720088902458687608585988765042311224096e-308
[0x0.fp-1022])
(nil
This is what 4.1.1 generated:
(insn 85 83 86 12 (set (reg:DI 93)
(const_int 4503599627370495 [0xf])) -1 (nil)
(nil))
(insn 86 85 88 12 (set (mem/s/j/c:DI (reg/f:DI 62 virtual-stack-vars) [0
equiv.1.i+0 S8 A64])
(reg:DI 93)) -1 (nil)
(nil))
(insn 88 86 91 12 (set (reg/f:DI 74 [ D.611 ])
(reg/f:DI 62 virtual-stack-vars)) -1 (nil)
(nil))
(insn 91 88 92 12 (set (reg:DF 32 %fr4)
(mem:DF (reg/f:DI 74 [ D.611 ]) [0 S8 A64])) -1 (nil)
(nil))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30634
[Bug target/30634] FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-02-04 17:13 ---
Can you try the following C code?
double f(void)
{
long long t = -1;
double t1;
__builtin_memcpy(t1, t, sizeof(long long));
return t;
}
If the above is broken also, then my patch just exposed the above latent bug
really.
Also I don't see anything wrong with the expand's RTL. The difference between
4.1.1 and 4.2's RTL is that we don't go through memory for the case of memcpy
any more.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30634
[Bug tree-optimization/28544] [4.2 regression] ICE in add_virtual_operand, at tree-ssa-operands.c:1309
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2007-02-04 17:23 --- Did the patch fixing this on gcc 4.2 branch get posted to the gcc-patches mailing list? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28544
[Bug pch/13676] GCC failes to recognize files ending in .hpp as headers to be precompiled
--- Comment #16 from alfred dot minarik dot 1 at aon dot at 2007-02-04 17:23 --- (In reply to comment #15) I think you need to resubmit the updated patch. Done http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00331.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13676
[Bug target/30634] FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-04
17:37 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
Can you try the following C code?
double f(void)
{
long long t = -1;
double t1;
__builtin_memcpy(t1, t, sizeof(long long));
return t;
}
Didn't cause a problem. The constant was pushed to memory:
(insn 10 9 11 (set (reg:DI 70)
(plus:DI (reg:DI 27 %r27)
(high:DI (symbol_ref/u:DI (*L$C) [flags 0x2] -1 (nil)
(nil))
(insn 11 10 12 (set (reg/f:DI 69)
(mem/u/c:DI (lo_sum:DI (reg:DI 70)
(unspec:DI [
(symbol_ref/u:DI (*L$C) [flags 0x2])
] 2)) [0 S8 A64])) -1 (nil)
(expr_list:REG_EQUAL (symbol_ref/u:DI (*L$C) [flags 0x2])
(nil)))
(insn 12 11 13 (set (reg:DF 66 [ result ])
(mem/u/c/i:DF (reg/f:DI 69) [3 S8 A64])) -1 (nil)
(expr_list:REG_EQUAL (const_double:DF -1.0e+0 [-0x0.8p+1])
(nil)))
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30634
[Bug middle-end/30700] New: [4.2 Regression] YA bogus undefined reference error to static func with -g and -O
PR27657 addressed a similar problem but this one is slightly different and
remains unsolved:
(sid)1556:[EMAIL PROTECTED]: ~/src/a] cat test.c
static void sand_window_create_shape (int test) {}
static void (* const b) (int test) = sand_window_create_shape;
(sid)1557:[EMAIL PROTECTED]: ~/src/a] cat main.c
int main() {
}
(sid)1558:[EMAIL PROTECTED]: ~/src/a] make
/usr/lib/gcc-snapshot/bin/gcc -c -o main.o main.c
/usr/lib/gcc-snapshot/bin/gcc -c -g -O -o test.o test.c
/usr/lib/gcc-snapshot/bin/gcc main.o test.o
test.o:(.debug_info+0x49): undefined reference to `sand_window_create_shape'
collect2: ld returned 1 exit status
make: *** [all] Error 1
--
Summary: [4.2 Regression] YA bogus undefined reference error to
static func with -g and -O
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30700
[Bug middle-end/27657] [4.2 regression] bogus undefined reference error to static var with -g and -O
--- Comment #23 from tbm at cyrius dot com 2007-02-04 17:52 --- (In reply to comment #22) Fixed. I can confirm this - with the exception of one case for which I filed a new report: PR30700. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug middle-end/30700] [4.2 Regression] YA bogus undefined reference error to static func with -g and -O
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-04 18:02 ---
Index: dwarf2out.c
===
*** dwarf2out.c (revision 121576)
--- dwarf2out.c (working copy)
*** reference_to_unused (tree * tp, int * wa
*** 10007,10012
--- 10007,10018
if (!node-needed)
return *tp;
}
+ else if (DECL_P (*tp) TREE_CODE (*tp) == FUNCTION_DECL)
+ {
+ struct cgraph_node *node = cgraph_node (*tp);
+ if (!node-needed)
+ return *tp;
+ }
return NULL_TREE;
}
honza - does this look sane and can we maybe do this whole function in
graph ways?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-02-04 18:02:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30700
[Bug fortran/30701] New: Segfault on discontinued DATA statement
Initiate command line: == gfortran-4.1 -v -O2 -c test.f95 Resultant output: = Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) /usr/lib/gcc/i486-linux-gnu/4.1.2/f951 test.f95 -quiet -dumpbase test.f95 -mtune=i686 -auxbase test -O2 -version -o test.s GNU F95 version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) (i486-linux-gnu) compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21).GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=63563 In file test.f95:4 k / 0 /, k1 / 1 /, 1 Error: Syntax error in DATA statement at (1) In file test.f95:5 j / 0.0D0 / 1 Error: Unclassifiable statement at (1) test.f95:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.1/README.Bugs. Source text: PROGRAM test REAL (kind=8) j datai / 0 /, k / 0 /, k1 / 1 /, j / 0.0D0 / STOP END program test -- Summary: Segfault on discontinued DATA statement Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: imre dot bartfai at chello dot hu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30701
[Bug pch/30702] New: PCH vs not closing a function in a header
t.h:
int f(void)
{
- cut -
t.c
#include t.h
return 0;
}
- cut -
gcc t.c
works
but
gcc t.h gcc t.c
fails to compile t.h.
As far as I can tell this is not a regression
--
Summary: PCH vs not closing a function in a header
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: pch
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30702
[Bug target/30634] FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-04
19:55 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
Can you try the following C code?
double f(void)
{
long long t = -1;
double t1;
__builtin_memcpy(t1, t, sizeof(long long));
return t;
}
Didn't cause a problem. The constant was pushed to memory:
I realized that we should be returning t1 in the above. Also noticed
that the constant that's a problem isn't -1, it's 0x. So
I tweaked the program to see if it made a difference. It didn't change
the generated code for function f.
However, I noticed that the above constant was not output correctly.
It was output as a pair of 32-bit words and the high and low parts were
reversed:
.section.rodata
.align 8
L$C:
.word -1
.word 1048575
Don't know why TARGET_ASM_ALIGNED_DI_OP wasn't used here.
# cat yy.c
#include stdio.h
double f(void)
{
long long t = 0x000f;
double t1;
__builtin_memcpy(t1, t, sizeof(long long));
return t1;
}
int main()
{
union
{
long long ll;
double d;
} u;
u.d = f ();
printf (ll = 0x%llx\n, u.ll);
return 0;
}
# ../../xgcc -B../../ -O2 -o yy yy.c
# ./yy
ll = 0x000f
# ../../xgcc -B../../ -O0 -o yy yy.c
# ./yy
ll = 0xf
# ../../xgcc -B../../ -v
Reading specs from ../../specs
Target: hppa64-hp-hpux11.00
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64
--prefix=/opt/gnu64/gcc/gcc-4.2.0 --host=hppa64-hp-hpux11.00 --disable-nls
--with-gmp=/opt/gnu64/gcc/gcc-4.2.0
Thread model: posix
gcc version 4.2.0 20070123 (prerelease)
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30634
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2007-02-04 20:10 --- *** Bug 30701 has been marked as a duplicate of this bug. *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||imre dot bartfai at chello ||dot hu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug fortran/30701] Segfault on discontinued DATA statement
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-02-04 20:10 --- Works for me on 4.3, I believe this is a duplicate of pr27954. There is no plan at the moment to back port this to 4.2 or 4.1. Can you upgrade to 4.3? *** This bug has been marked as a duplicate of 27954 *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30701
[Bug c++/14622] type mismatch in explicit template instantiation not detected
--- Comment #2 from patchapp at dberlin dot org 2007-02-04 21:30 --- Subject: Bug number PR c++/14622 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00342.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14622
[Bug fortran/30605] [4.2 only] -Wno-tabs should be active for -std=f2003 and -pedantic
--- Comment #7 from kargl at gcc dot gnu dot org 2007-02-04 21:31 --- Fixed on trunk. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Summary|-Wno-tabs should be active |[4.2 only] -Wno-tabs should |for -std=f2003 and -pedantic|be active for -std=f2003 and ||-pedantic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30605
[Bug fortran/30611] Confusing error message for negative ncopies in REPEAT
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-02-04 21:33 --- Subject: Bug 30611 Author: fxcoudert Date: Sun Feb 4 21:33:10 2007 New Revision: 121581 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121581 Log: PR fortran/30611 * trans-intrinsic.c (gfc_conv_intrinsic_repeat): Evaluate arguments only once. Generate check that NCOPIES argument is not negative. * intrinsics/string_intrinsics.c (string_repeat): Don't check if ncopies is negative. * gcc/testsuite/gfortran.dg/repeat_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/repeat_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/string_intrinsics.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30611
[Bug bootstrap/30678] sysmacros.h get currupt from Fixincludes with updated glibc.
--- Comment #9 from tkoenig at gcc dot gnu dot org 2007-02-04 22:24 --- Same thing happens on i686-pc-linux-gnu with glibc-2.3.6.ds1-10 (Debian testing) while building libgfortran. This currently blocks fortran development on trunk. Confirming, setting severity and priority. Trailing error messages: .libs/in_unpack_generic.o: In function `gnu_dev_minor': /home/ig25/gcc-bin/trunk/./gcc/include/sys/sysmacros.h:66: multiple definition of `gnu_dev_minor' .libs/compile_options.o:/home/ig25/gcc-bin/trunk/./gcc/include/sys/sysmacros.h:66: first defined here .libs/in_unpack_generic.o: In function `gnu_dev_makedev': /home/ig25/gcc-bin/trunk/./gcc/include/sys/sysmacros.h:76: multiple definition of `gnu_dev_makedev' .libs/compile_options.o:/home/ig25/gcc-bin/trunk/./gcc/include/sys/sysmacros.h:76: first defined here collect2: ld returned 1 exit status make[3]: *** [libgfortran.la] Error 1 make[3]: Leaving directory `/home/ig25/gcc-bin/trunk/i686-pc-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/ig25/gcc-bin/trunk/i686-pc-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/ig25/gcc-bin/trunk' make: *** [bootstrap] Error 2 -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Severity|major |blocker Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2007-02-04 22:24:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30678
[Bug fortran/30478] FAIL: gfortran.dg/enum_2.f90 -O (internal compiler error)
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-02-04 22:48 --- Fortran is not release-critical and this bug appears to be purely within the Fortran front end. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30478
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #15 from mark at codesourcery dot com 2007-02-04 22:53 --- Subject: Re: Shared libstdc++ fails to link danglin at gcc dot gnu dot org wrote: Personally, I believe that the fix for PR 29323 was wrong and has bloated the EH data emitted by GCC. The EH data for a module are only relevant to the functions in the module itself. If a function in a module can't throw, then we don't need EH exception data for it. I'm not sure what EH data is being described here. Certainly, it makes no sense at all to emit EH unwind information for functions which are not part of the current object file; their unwind information will be emitted with those function. What sort of data is being emitted? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug fortran/30689] equivalence modifies common block
--- Comment #7 from milan at cmm dot ki dot si 2007-02-04 22:56 --- Subject: Re: equivalence modifies common block pault == pault at gcc dot gnu dot org [EMAIL PROTECTED] writes: pault --- Comment #6 from pault at gcc dot gnu dot org pault 2007-02-04 12:03 --- I think that we can close this pault one, OK? pault I've marked it as invalid, although that seems a trifle pault unfair. pault Please feel post bugs if you find them - we would rather pault discuss PRs like this one than have disatisfied users out pault there! Yes it is OK to close it. I am sorry to bother you with this one, but I was thinking if it works with other compilers it should with gfortran, too. But then it is not very clear how the others do it, and I am not too much interested into other compilers, anyway. Thanks for helping me shed some new light in fortran tricks :-) Milan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30689
[Bug bootstrap/30678] sysmacros.h get currupt from Fixincludes with updated glibc.
--- Comment #10 from ron3763 at msn dot com 2007-02-04 23:06 --- Created an attachment (id=13005) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13005action=view) File/Patch used to update glibc to new c99 semaitics for 4.3.0 gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30678
[Bug bootstrap/30678] sysmacros.h get currupt from Fixincludes with updated glibc.
--- Comment #11 from ron3763 at msn dot com 2007-02-04 23:07 --- I have added the patch file used to update glibc to the new C99 std extern values so as to allow comparing touched/modified files with the fix-include modification tables. sysmacros.h may not be the only one that needs a 'don't touch, if already fixed.' awareness. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30678
[Bug libgomp/30703] New: ICE Segmentation fault on using OpenMP
Using the following version from svn. g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc_4_2_svn/configure --prefix=/local_scratch/owe043/gcc_4_2 --enable-languages=c,c++ Thread model: posix gcc version 4.2.0 20070201 (prerelease) On a Fedora Core 4 system. Using the pre-processed file (to be attached) the ICE occurs with the following command line: g++ -fopenmp foo.ii Note that no ICE occurs if the -fopenmp is omitted. The expected behaviour is compilation completed possibly with errors or warnings. The actual behaviour is an ICE. The error message is as below. foo.cc:509: instantiated from here nlopt/simulated_annealing.h:149: internal compiler error: Segmentation fault -- Summary: ICE Segmentation fault on using OpenMP Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bowie dot owens at csiro dot au GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30703
[Bug libgomp/30703] ICE Segmentation fault on using OpenMP
--- Comment #1 from bowie dot owens at csiro dot au 2007-02-04 23:12 --- Created an attachment (id=13006) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13006action=view) A preprocessed version of foo.cc which causes the ICE (compressed with bzip2). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30703
[Bug target/30634] FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-04 23:31 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 Also I don't see anything wrong with the expand's RTL. The difference between 4.1.1 and 4.2's RTL is that we don't go through memory for the case of memcpy any more. Well, it circumvents the CONST_DOUBLE handling used on hppa64. The only way to load a CONST_DOUBLE to the floating registers is from memory. For that reason, LEGITIMATE_CONSTANT_P rejects CONST_DOUBLEs. We always need a general register to load CONST_DOUBLEs from memory. The ICE is caused in this case by reload trying to load a CONST_DOUBLE directly to fr4. We don't have a general register available for this operation and we can't create a new pseudo at this point. So, we are dead in the water. I'm trying a change to the movdf and movdi expanders to FAIL in such situations. I also noticed that we need to legitimize the address of the MEM created for the CONST_DOUBLE. I suspect that reload won't be able to handle failure. If this scheme doesn't work, then the only solution that I can see is to reserve a general register for emergency use during instruction generation. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30634
[Bug middle-end/30696] [4.3 regression] Linker failure with OpenMP and inline function
--- Comment #3 from hubicka at gcc dot gnu dot org 2007-02-04 23:41 --- Subject: Bug 30696 Author: hubicka Date: Sun Feb 4 23:40:58 2007 New Revision: 121582 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121582 Log: PR middle-end/30696 * ipa-inline.c (cgraph_clone_inlined_nodes): When there are unanalyzed nodes in cgraph, don't remove offline copy of the function. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30696
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-05 00:15 --- Subject: Re: Shared libstdc++ fails to link I'm not sure what EH data is being described here. Certainly, it makes no sense at all to emit EH unwind information for functions which are not part of the current object file; their unwind information will be emitted with those function. What sort of data is being emitted? Unwind data. We're talking about functions compiled in the current object. On the HP-UX PA-RISC targets, unwind data is placed in the data subspace. In principle, there's no problem with other EH data as the HP linker can handle the relocations in noload subspaces. In HP-UX 10, one-only was implemented using COMDAT subspaces. When the linker sees the second or later occurence of a COMDAT subspace with the same name as the first one, it nullifies these subspaces and doesn't emit them in the final object. However, it turns out that that the linker can't handle relocations referring to symbols in that are in a nullified subspace if these references occur in a subspace that is loadable. Didn't see this when developing the DWARF2 unwind support for the 4.1 branch because of the following issue. There are numerous one-only/weak functions which don't bind locally in libstdc++. Previously, *ALL* these functions were determined to be nothrow and no unwind data was emitted for them. Now, unwind data is being emitted because these functions don't bind locally. This breaks the HP-UX 10 DWARF2 unwind implementation (obviously a latent bug) because of the relocation issue mentioned above. It also increases the amount of DWARF2 unwind data emitted on all targets using this exception mechanism and might have an impact on search performance when unwinding. It's my belief that DWARF2 unwind support present in GCC 4.1.0 and 4.1.1 for HP-UX 10 was usable in spite of the linker limitation. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug rtl-optimization/30704] New: Incorrect constant generation for long long
The following problem was seen in a testcase under discussion in PR 30634:
# cat yy.c
#include stdio.h
double f(void)
{
long long t = 0x000f;
double t1;
__builtin_memcpy(t1, t, sizeof(long long));
return t1;
}
int main()
{
union
{
long long ll;
double d;
} u;
u.d = f ();
printf (ll = 0x%llx\n, u.ll);
return 0;
}
# ../../xgcc -B../../ -O2 -o yy yy.c
# ./yy
ll = 0x000f
# ../../xgcc -B../../ -O0 -o yy yy.c
# ./yy
ll = 0xf
# ../../xgcc -B../../ -v
Reading specs from ../../specs
Target: hppa64-hp-hpux11.00
Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64
--prefix=/opt/gnu64/gcc/gcc-4.2.0 --host=hppa64-hp-hpux11.00 --disable-nls
--with-gmp=/opt/gnu64/gcc/gcc-4.2.0
Thread model: posix
gcc version 4.2.0 20070123 (prerelease)
The constant 0x000f appears in the assembler output as a
pair of 32-bit .word values. The values are reversed when the testcase
is compiled at -O2. This doesn't appear to be a target issue since the
target only defines directives for the output of constants.
--
Summary: Incorrect constant generation for long long
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
GCC build triplet: hppa64-hp-hpux11.00
GCC host triplet: hppa64-hp-hpux11.00
GCC target triplet: hppa64-hp-hpux11.00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug c++/30423] compile with -O2 fails.
--- Comment #3 from chat95 at mac dot com 2007-02-05 02:34 --- Sorry for long delay... No, I'm using 4.2's libstdc++. % g++42 -O -fno-strict-aliasing -pipe -o gendoc gendoc.cc ; ldd ./gendoc ./gendoc: libstdc++.so.6 = /usr/local/lib/gcc-4.1.2/libstdc++.so.6 (0x8006a3000) libm.so.4 = /lib/libm.so.4 (0x80089d000) libgcc_s.so.1 = /usr/local/lib/gcc-4.1.2/libgcc_s.so.1 (0x8009b9000) libc.so.6 = /lib/libc.so.6 (0x800ac5000) % g++42 -pipe -o gendoc gendoc.cc ; ldd ./gendoc ./gendoc: libstdc++.so.6 = /usr/local/lib/gcc-4.1.2/libstdc++.so.6 (0x8006a1000) libm.so.4 = /lib/libm.so.4 (0x80089b000) libgcc_s.so.1 = /usr/local/lib/gcc-4.1.2/libgcc_s.so.1 (0x8009b7000) libc.so.6 = /lib/libc.so.6 (0x800ac3000) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30423
[Bug c++/30423] compile with -O2 fails.
--- Comment #4 from chat95 at mac dot com 2007-02-05 02:39 --- it seems amd64 only. with i386-portbld-freebsd6.2, % g++42 -v Using built-in specs. Target: i386-portbld-freebsd6.2 Configured with: ./..//gcc-4.2-20070110/configure --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local --program-suffix=42 --libdir=/usr/local/lib/gcc-4.2.0 --with-gxx-include-dir=/usr/local/lib/gcc-4.2.0/include/c++/ --infodir=/usr/local/info/gcc42 --disable-rpath --prefix=/usr/local i386-portbld-freebsd6.2 Thread model: posix gcc version 4.2.0 20070110 (prerelease) % g++42 -O -fno-strict-aliasing -pipe -o gendoc gendoc.cc ; ldd ./gendoc ./gendoc: libstdc++.so.6 = /usr/local/lib/gcc-4.2.0/libstdc++.so.6 (0x280ed000) libm.so.4 = /lib/libm.so.4 (0x281ca000) libgcc_s.so.1 = /usr/local/lib/gcc-4.2.0/libgcc_s.so.1 (0x281e) libc.so.6 = /lib/libc.so.6 (0x281ea000) % ./gendoc ... works. % g++42 -pipe -o gendoc gendoc.cc ; ldd ./gendoc ./gendoc: libstdc++.so.6 = /usr/local/lib/gcc-4.2.0/libstdc++.so.6 (0x280ef000) libm.so.4 = /lib/libm.so.4 (0x281cc000) libgcc_s.so.1 = /usr/local/lib/gcc-4.2.0/libgcc_s.so.1 (0x281e2000) libc.so.6 = /lib/libc.so.6 (0x281ec000) % ./gendoc ... works. it seems it DOES only happens to amd64... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30423
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #17 from mark at codesourcery dot com 2007-02-05 03:06 ---
Subject: Re: Shared libstdc++ fails to link
dave at hiauly1 dot hia dot nrc dot ca wrote:
Unwind data. We're talking about functions compiled in the
current object.
OK.
I'm not sure it matters, but if these functions don't throw exceptions,
I don't understand why we're not marking them TREE_NOTHROW. I suspect
there's something that I'm just not following.
The fact that linker semantics allow you to replace a function at the
object level do not make it valid at the language level.
So, for example, I would expect:
void f () throw () {}
and:
void g() {}
to both be TREE_NOTHROW, independent of linkage, weakness, etc.
Certainly, not marking such functions as TREE_NOTHROW will inhibit
optimization of their callers, which seems bad.
Why aren't the functions being marked TREE_NOTHROW?
There are numerous one-only/weak functions which don't bind locally
in libstdc++. Previously, *ALL* these functions were determined to be
nothrow and no unwind data was emitted for them. Now, unwind
data is being emitted because these functions don't bind locally.
This breaks the HP-UX 10 DWARF2 unwind implementation (obviously a
latent bug) because of the relocation issue mentioned above.
I understand that this is a latent bug in the HP-UX linker.
To be honest, I'm less concerned about HP-UX 10.10 per se than about the
possible bloat on other targets. (HP-UX 10 is not a primary or
secondary target.) At the same time, I certainly don't want to
gratuitously break any target.
Assuming that the changes in TREE_NOTHROW and emission of exception
information make sense, what solution would you implement for HP-UX 10?
Use SJLJ exception handling?
Thanks,
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug c++/20912] C++ FE emitting assignments to read-only global symbols
--- Comment #13 from mark at codesourcery dot com 2007-02-05 03:18 --- Subject: Re: C++ FE emitting assignments to read-only global symbols steven at gcc dot gnu dot org wrote: Mark was going to leave this for GCC 4.2, but hasn't fixed this for GCC 4.2 yet, either. What's going to happen with this bug? After Diego's comments, it didn't sound like it was still important to fix it. Does the patch in Comment #6 still apply? It looks like to me as if it would (at least in principle; the code affected still looks the same). If so, it's OK to apply to mainline, assuming test results go OK. Would you like to test it? If that fix will also fix PR 23777, then the same fix is also OK for 4.2. If not, then is there any compelling reason to apply it to 4.2? Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20912
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-05
04:02 ---
Subject: Re: Shared libstdc++ fails to link
I'm not sure it matters, but if these functions don't throw exceptions,
I don't understand why we're not marking them TREE_NOTHROW. I suspect
there's something that I'm just not following.
See the testcase for PR 29323 and the initial problem description.
The fact that linker semantics allow you to replace a function at the
object level do not make it valid at the language level.
So, for example, I would expect:
void f () throw () {}
This is essentially identical to the example in weakthrow.C except
that the function there is annotated with __attribute__ ((weak)).
It was argued in PR 29323 that it was incorrect to mark functions
that don't bind locally with TREE_NOTHROW.
I'm not sure whether it's valid at the language level to replace
a function that can't throw with one that can. However, as far
as unwind data goes, the only thing that matters is whether the
function being compiled needs unwind data or not.
Why aren't the functions being marked TREE_NOTHROW?
When a function doesn't bind locally, it may be overloaded/replaced
by one that does throw. So, we no longer mark such functions with
TREE_NOTHROW. This results in unwind data being emitted for functions
that would have been marked TREE_NOTHROW if they were local.
Assuming that the changes in TREE_NOTHROW and emission of exception
information make sense, what solution would you implement for HP-UX 10?
Use SJLJ exception handling?
Yes, config.gcc could be modified to force SJLJ exception handling.
Of course, I'm hoping for a better fix to PR 29323.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug target/28481] regression from 3.x: 4.1.1 uses memory where it can use registers
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481
[Bug tree-optimization/29686] [4.1 Regression] ICE when expanding recursive function containing switch
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29686
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug tree-optimization/29877] [4.0/4.1/4.2 Regression] out of SSA (TER) extends variable life of variable beyond original declared
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29877
[Bug debug/29906] [4.0/4.1/4.2/4.3 Regression] -g option creates internal compiler error
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29906
[Bug c++/30016] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in convert_move, at expr.c:362
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30016
[Bug tree-optimization/30045] [4.1/4.2 Regression] ICE in nonnull_arg_p with the CHAIN decl
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30045
[Bug c++/30108] [4.0/4.1/4.2/4.3 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug fortran/29786] [4.1/4.2/4.3 Regression] rejects equivalence
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29786
[Bug middle-end/30132] [4.1/4.2/4.3 Regression] ICE in find_lattice_value, at tree-complex.c:133
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30132
[Bug target/29487] Shared libstdc++ fails to link
--- Comment #19 from mark at codesourcery dot com 2007-02-05 05:40 --- Subject: Re: Shared libstdc++ fails to link dave at hiauly1 dot hia dot nrc dot ca wrote: --- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-05 04:02 --- Subject: Re: Shared libstdc++ fails to link I'm not sure it matters, but if these functions don't throw exceptions, I don't understand why we're not marking them TREE_NOTHROW. I suspect there's something that I'm just not following. See the testcase for PR 29323 and the initial problem description. Thanks. The fact that the declaration is explicitly declare weak seems somewhat persuasive. C++ has no notion of weak symbols, so once you declare a function weak, you're outside the standard anyhow, and it's reasonable to say that you can replace such a function with one of the same type. However, that doesn't mean that the check for binds_local makes sense. In particular, a COMDAT template instantiation may not bind locally (IIUC), but it's invalid to replace the template instantiation with one that behaves differently. So, it sounds like the change that's been made unduly pessimizes C++ template instantiations, which would plausibly result in the behavior you're seeing. And, as you say, even for explicitly weak functions, it doesn't make sense to emit EH unwind information if the functions never throw. That's just a pessimization. So, as has been said elsewhere, that suggests that -- for the weak function case -- we need to distinguish body of this function needs unwind information from callers of this function must assume it throws exceptions. Frankly, my inclination would be to just declare that in GNU C++, replacing a weak function with an implementation that throws more exceptions than the version in the current translation unit is invalid, no diagnostic required. This doesn't seem like a case worth twisting our internal representations around to support. Assuming that the changes in TREE_NOTHROW and emission of exception information make sense, what solution would you implement for HP-UX 10? Use SJLJ exception handling? Yes, config.gcc could be modified to force SJLJ exception handling. Of course, I'm hoping for a better fix to PR 29323. Right. I've CC'd Richard G on the PR. Richard, what are your thoughts? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
[Bug c++/30156] [4.1/4.2/4.3 regression] ICE on invalid template declaration
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30156
[Bug c++/30168] [4.1/4.2 Regression] C++ constructors can cause invalid gimple to happen with complex typed variables
--- Comment #6 from mmitchel at gcc dot gnu dot org 2007-02-05 05:42 --- This patch is OK for 4.2, and for 4.1 when reopened. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30168
[Bug debug/30189] [4.1 Regression] ICE on modified_type_die
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-02-05 05:46 --- This patch is OK for mainline and 4.2, and for 4.1 after it reopens. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30189
[Bug c++/30221] [4.1/4.2/4.3 Regression] internal compiler error: in reshape_init_r, at cp/decl.c:4632
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30221
[Bug middle-end/30262] [4.0/4.1 Regression] ICE with nested fn accessed var in asm m constraint
--- Comment #9 from mmitchel at gcc dot gnu dot org 2007-02-05 05:48 --- Jakub, you've checked in a patch on the 4.1 branch, but your comment says that this is fixed for 4.2 and 4.3. Was it also fixed for 4.1, or is there still a problem on 4.1? Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30262
[Bug c++/30302] [4.0/4.1/4.2/4.3 regression] ICE with invalid member in anonymous struct
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30302
[Bug preprocessor/30363] [4.0/4.1/4.2/4.3 Regression] Support for -traditional-cpp is incomplete in current gcc relative to gcc 2.95.3
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30363
[Bug middle-end/30364] [4.1/4.2/4.3 Regression] Wrong variable ranges due to constant folding
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
[Bug middle-end/30433] [4.1/4.2/4.3 Regression] no longer folding __complex__(0.0, 1.0) == __complex__(1.0, 0.0)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30433
[Bug fortran/30437] [4.0/4.1/4.2 Regression] -Wno-all is rejected (even when fortran is not included)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug driver/30460] [4.0/4.1/4.2/4.3 Regression] asm_debug is not initialized in gcc.c when using a default specs file
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30460
[Bug preprocessor/30468] [4.0/4.1/4.2 Regression] -M not fully chops dirname
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30468
[Bug target/30472] [4.1 Regression] -gstabs, ICE in output_operand: invalid expression as operand
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30472
[Bug middle-end/30473] [4.0/4.1/4.2/4.3 Regression] Internal Compiler Error with a sprintf with few arguments for format %s
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30473
[Bug tree-optimization/30493] [4.1 Regression] Unexpected compilation results: -O versus no optimization
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30493
[Bug c++/30536] [4.1/4.2/4.3 regression] ICE with __thread and register
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30536
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug ada/30618] [4.1 regression] Infinite loop in sem_ch8.end_use_clauses
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30618
[Bug c++/30659] [4.0/4.1/4.2/4.3 Regression] ICE in undefined template
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30659
[Bug target/30370] [4.1 regression] Build failure in libgcc2 powitf2 with ICE in gen_reg_rtx
--- Comment #12 from mmitchel at gcc dot gnu dot org 2007-02-05 06:05 --- Richard, would you be able to test the patch on SLES9, as David suggests? Thanks, -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||rguenther at suse dot de, ||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30370
[Bug middle-end/30262] [4.0/4.1 Regression] ICE with nested fn accessed var in asm m constraint
--- Comment #10 from jakub at gcc dot gnu dot org 2007-02-05 06:52 --- Only on redhat/gcc-4_1-branch. tree-nested.c on that branch is far closer to gcc-4_2-branch (due to backported OpenMP support). Backporting to vanilla gcc-4_1-branch will need more work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30262
