[Bug libgcj/38872] [4.4 Regression] libgcj.so dropped _Jv_CreateJavaVM and _Jv_GetStringChars symbols
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-17 08:00 --- Then _Jv_GetStringChars should be dropped from libgcj_bc.so too. And for the other function, I think adding a C alias in libgcj.so.* and a C++ in libgcj_bc.so wouldn't hurt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38872
[Bug fortran/38657] [4.4, 4.3 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #12 from pault at gcc dot gnu dot org 2009-01-17 08:39 --- The fix has caused the regression reported in http://gcc.gnu.org/ml/fortran/2009-01/msg00197.html so I am reverting on trunk and 4.3. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[4.3 Regression]|[4.4, 4.3 Regression] |PUBLIC/PRIVATE Common blocks|PUBLIC/PRIVATE Common blocks http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- Comment #6 from paolo dot carlini at oracle dot com 2009-01-17 09:04 --- Maybe this issue isn't sufficiently clarified in the audit. Unless I'm badly mistaken (Jon, Chris will correct me), this is not a bug for a C++03 + TR1 bind (indeed the testcases provided by Doug are rather clear about that). Only in C++0x the specs say it must work. Of course implementations can also fix it for C++03 + TR1, but this is not in general the way we are managing these issues, we prefer leaving the TR1 version alone. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
[Bug fortran/38894] New: c_f_funpointer - add missing argument checking
Found in PR 38871. The following is invalid as C_F_FUNPTR takes function/procedure pointers as arguments. TODO: Check also that C_F_POINTER doesn't take a type(c_ptr) as argument. use iso_c_binding type(c_ptr) :: fun integer, pointer :: bar call c_f_funpointer(fun,bar) end -- Summary: c_f_funpointer - add missing argument checking Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: accepts-invalid 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=38894
[Bug libfortran/38871] [4.4 Regression] libgfortran.so.3 dropped __iso_c_binding_c_f_procpointer@@GFORTRAN_1.0
--- Comment #7 from burnus at gcc dot gnu dot org 2009-01-17 09:18 --- (In reply to comment #6) I'd say re-adding that symbol until you change libgfortran ABI wouldn't hurt anything, but if you can prove no program could ever use it except for referencing directly that symbol, I guess I can live with a WONTFIX too. The symbol was added with Rev. 126185 (2007-07-01) and removed with Rev. 135877 (2008-05-25). The first SoC 2008 proc pointer patch was Rev. 137386 on 2008-07-02. However, I just saw that due to missing argument checking the following works in gfortran 4.3: use iso_c_binding type(c_ptr) :: fun integer, pointer :: bar call c_f_funpointer(fun,bar) ! Invalid; should be C_F_POINTER end The program is *invalid* as c_f_funpointer is for FUN(ction) pointers - for normal pointers, one shall use c_f_pointer - but due to missing argument checking it was accepted. As one cannot rule out that some invalid program uses c_f_funpointer, I will submit a patch which re-adds it. (I think the probability that c_f_funpointer is used is extremely low, though.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-17 09:18:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38871
[Bug fortran/38657] [4.4, 4.3 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #13 from pault at gcc dot gnu dot org 2009-01-17 09:29 --- Subject: Bug 38657 Author: pault Date: Sat Jan 17 09:28:50 2009 New Revision: 143458 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143458 Log: 2009-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/38657 * module.c (write_common_0): Revert patch of 2009-01-10. 2009-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/38657 * gfortran.dg/module_commons_3.f90: Remove Removed: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/module_commons_3.f90 Modified: branches/gcc-4_3-branch/gcc/fortran/ChangeLog branches/gcc-4_3-branch/gcc/fortran/module.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug libfortran/38871] [4.4 Regression] libgfortran.so.3 dropped __iso_c_binding_c_f_procpointer@@GFORTRAN_1.0
--- Comment #8 from burnus at gcc dot gnu dot org 2009-01-17 09:37 --- However, I just saw that due to missing argument checking the following works in gfortran 4.3: call c_f_funpointer(fun,bar) ! Invalid; should be C_F_POINTER That's actually nonsense. The procedure name is C_F_PROCPOINTER (-proc- not -FUN-). (It's C_FUNLOC and type(c_funptr) but c_f_procpointer). There is no argument checking, but the library function called is __iso_c_binding_c_f_procpointer_i4 ! note extra _i4. (which does not exist). I don't see how one could get rid of the _datatype and thus I maintain what I wrote before: It is not possible from gfortran to access that procedure, except by calling __iso_c_binding_c_f_procpointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38871
[Bug fortran/38657] [4.4, 4.3 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #14 from pault at gcc dot gnu dot org 2009-01-17 09:44 --- Subject: Bug 38657 Author: pault Date: Sat Jan 17 09:43:57 2009 New Revision: 143459 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143459 Log: 2009-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/38657 * module.c (write_common_0): Revert patch of 2009-01-10. 2009-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/38657 * gfortran.dg/module_commons_3.f90: Remove Removed: trunk/gcc/testsuite/gfortran.dg/module_commons_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug libfortran/38871] [4.4 Regression] libgfortran.so.3 dropped __iso_c_binding_c_f_procpointer@@GFORTRAN_1.0
--- Comment #9 from burnus at gcc dot gnu dot org 2009-01-17 09:58 --- Patch http://gcc.gnu.org/ml/fortran/2009-01/msg00209.html or one can close it as WONTFIX. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38871
[Bug fortran/38894] c_f_procpointer/c_f_pointer - add missing argument checking
--- Comment #1 from burnus at gcc dot gnu dot org 2009-01-17 10:46 --- The example was wrong as the name is c_f_PROCpointer (no -fun- only in type(c_funptr) and c_FUNloc). Working example: use iso_c_binding type(c_ptr) :: fun procedure(), pointer :: bar call c_f_procpointer(fun,bar) ! fun is c_ptr not c_funptr end The same for C_F_POINTER: use iso_c_binding type(c_funptr) :: fun integer, pointer :: bar call c_f_pointer(fun,bar) ! fun is c_funptr not a normal c_ptr end The bar argument seems to be correctly checked. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|c_f_funpointer - add missing|c_f_procpointer/c_f_pointer |argument checking |- add missing argument ||checking http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38894
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-01-17 10:57 --- Well, I don't know how fortran strings are supposed to work, but for the 80 chars in a C string you need 81 bytes, 1 byte for the terminating null character. Also you single-file testcase prints nothing at -O0 for me, the expected output with optimization. At -O0 I see loads of ==5461== Conditional jump or move depends on uninitialised value(s) ==5461==at 0x40D1E7A: (within /usr/lib/libgfortran.so.3.0.0) ==5461==by 0x40D0921: (within /usr/lib/libgfortran.so.3.0.0) ==5461==by 0x8048FA6: print2_ (in /tmp/t) ==5461==by 0x8048A16: printe_ (in /tmp/t) ==5461==by 0x8048819: MAIN__ (in /tmp/t) ==5461== Use of uninitialised value of size 4 ==5461==at 0x41624E6: (within /lib/i686/cmov/libc-2.7.so) ==5461==by 0x4165C9B: vfprintf (in /lib/i686/cmov/libc-2.7.so) ==5461==by 0x418B323: vsnprintf (in /lib/i686/cmov/libc-2.7.so) ==5461==by 0x416D451: snprintf (in /lib/i686/cmov/libc-2.7.so) ==5461==by 0x40CB189: (within /usr/lib/libgfortran.so.3.0.0) ==5461==by 0x40D0CBA: (within /usr/lib/libgfortran.so.3.0.0) ==5461==by 0x8048FA6: print2_ (in /tmp/t) ==5461==by 0x8048A16: printe_ (in /tmp/t) ==5461==by 0x8048819: MAIN__ (in /tmp/t) this is with GFortran 4.3. With GFortran 4.4 I get output at -O0 but also ==5485== Conditional jump or move depends on uninitialised value(s) ==5485==at 0x40D1E7A: (within /usr/lib/libgfortran.so.3.0.0) ==5485==by 0x40D0921: (within /usr/lib/libgfortran.so.3.0.0) ==5485==by 0x8048FC0: print2_ (in /tmp/t) ==5485==by 0x80489F7: printe_ (in /tmp/t) ==5485==by 0x80487FC: MAIN__ (in /tmp/t) ==5485==by 0x80493F8: main (in /tmp/t) so I guess this is a problem in the Fortran runtime or the problem is exposed there. But I wonder why there is a difference with optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3
--- Comment #22 from pault at gcc dot gnu dot org 2009-01-17 11:32 --- Subject: Bug 34955 Author: pault Date: Sat Jan 17 11:32:02 2009 New Revision: 143462 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143462 Log: 2009-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/34955 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Has been absorbed into gfc_conv_intrinsic_transfer. All references to it in trans-intrinsic.c have been changed accordingly. PR fixed by using a temporary for scalar character transfer, when the source is shorter than the destination. 2009-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/34955 * gfortran.dg/transfer_intrinsic_1.f90: New test. * gfortran.dg/transfer_intrinsic_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_intrinsic_1.f90 trunk/gcc/testsuite/gfortran.dg/transfer_intrinsic_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_cast_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
[Bug fortran/34955] transfer_assumed_size_1.f90: Valgrind error: invalid read of size 3
--- Comment #23 from pault at gcc dot gnu dot org 2009-01-17 11:34 --- Fixed on trunk. Thanks for the report and sorry that it took so long to fix. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
[Bug libfortran/38871] [4.4 Regression] libgfortran.so.3 dropped __iso_c_binding_c_f_procpointer@@GFORTRAN_1.0
--- Comment #10 from mikael at gcc dot gnu dot org 2009-01-17 11:54 --- I vote for WONTFIX. But I can live with a patch revert. ;) While a program could reference the symbol, it seems highly unlikely. And anyway, 4.3 is still there in case it is needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38871
[Bug fortran/38657] [4.4, 4.3 Regression] PUBLIC/PRIVATE Common blocks
--- Comment #15 from pault at gcc dot gnu dot org 2009-01-17 11:58 --- Subject: Bug 38657 Author: pault Date: Sat Jan 17 11:58:48 2009 New Revision: 143463 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143463 Log: 2009-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/38657 * module.c (write_common_0): Add argument 'this_module' and check that non-use associated common blocks are written first. (write_common): Call write_common_0 twice, once with true and then with false. 2009-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/38657 * gfortran.dg/module_commons_3.f90: Reapply. Added: trunk/gcc/testsuite/gfortran.dg/module_commons_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38657
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #19 from dominiq at lps dot ens dot fr 2009-01-17 12:29 ---
Further reduced test case:
PROGRAM testcase
IMPLICIT NONE
INTEGER NENERT
PARAMETER (NENERT=62)
LOGICAL QENER(NENERT)
CHARACTER*4 ANER(NENERT)
CHARACTER*80 LINE
INTEGER NTERMS, J, START, STOP, PUNIT
PUNIT = 6
qener = .false.
qener(5:10) = .true.
aner = ''
ANER(5)='BOND'
ANER(6)='ANGL'
ANER(7)='DIHE'
ANER(8)='IMPR'
ANER(9) ='VDW '
ANER(10)='ELEC'
LINE=' '
LINE(2:2)='|'
LINE(80:80)='|'
NTERMS=2
DO J=1,NENERT
! IF (QENER(J).AND.ANER(J).NE.'') THEN
IF (QENER(J)) THEN
IF (NTERMS.GE.4) THEN
WRITE(PUNIT,'(A80)') LINE
LINE=' '
LINE(2:2)='|'
LINE(80:80)='|'
NTERMS=0
write(10,*) LINE
END IF
NTERMS=NTERMS+1
START=(NTERMS-1)*19 +3
STOP=NTERMS*19+2
write (10,*) stop, LINE(80:80)
WRITE(LINE(START:STOP),'(4A)') ' E(',ANER(J),')='
END IF
END DO
IF (NTERMS.GE.1) WRITE(PUNIT,'(A80)') LINE
END
gives at -O3
| E(BOND)= E(ANGL)=
| E(DIHE)= E(IMPR)= E(VDW )= E(ELEC)=
|
If I replace the line
IF (QENER(J)) THEN
by the commented one, I get
| E(BOND)= E(ANGL)=
| E(DIHE)= E(IMPR)= E(VDW )= E(ELEC)=
The content of fort.10 show that the content of LINE(80:80) is wrong.
One thing I did not realized when writing comment #10, is that I don't build
gcc with graphite on my G5:
Using built-in specs.
Target: powerpc-apple-darwin9
Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
--mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info
--build=powerpc-apple-darwin9
--enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/usr --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.4.0 20090116 (experimental) [trunk revision 143431] (GCC)
while I have it on i686-apple-darwin9:
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
--mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info
--build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
--with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--with-cloog=/opt/cloog/build --with-ppl=/opt/ppl/build
Thread model: posix
gcc version 4.4.0 20090116 (experimental) [trunk revision 143431p3] (GCC)
Somehow I got the impression that graphite is now enabled at -O2, although I
may have misunderstood what I read. Could the correlation of this pr with
graphite be checked? Just in case I cc Sebastian Pop.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
CC||sebpop at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-01-17 12:54 --- With Dominique's reduced test case I see three valgrind errors. Actual output is fine. I am looking further. ==4359== Conditional jump or move depends on uninitialised value(s) ==4359==at 0x43793D: strlen (in /home/jerry/prs/pr38868/a.out) ==4359==by 0x40871F: write_integer (write.c:859) ==4359==by 0x40BB4E: _gfortrani_list_formatted_write (write.c:1081) ==4359==by 0x400610: MAIN__ (pr38868.f:38) ==4359==by 0x400819: main (fmain.c:21) ==4359== ==4359== Conditional jump or move depends on uninitialised value(s) ==4359==at 0x4170A4: __ctype_toupper_loc (in /home/jerry/prs/pr38868/a.out) ==4359==by 0x40DF02: next_char (format.c:93) ==4359==by 0x40DFAE: format_lex (format.c:183) ==4359==by 0x40EE86: _gfortrani_parse_format (format.c:1034) ==4359==by 0x4053F7: data_transfer_init (transfer.c:1932) ==4359==by 0x4006D6: MAIN__ (pr38868.f:39) ==4359==by 0x400819: main (fmain.c:21) ==4359== ==4359== Conditional jump or move depends on uninitialised value(s) ==4359==at 0x417064: __ctype_b_loc (in /home/jerry/prs/pr38868/a.out) ==4359==by 0x40E15F: format_lex (format.c:168) ==4359==by 0x40E34C: parse_format_list (format.c:463) ==4359==by 0x40EEB7: _gfortrani_parse_format (format.c:1035) ==4359==by 0x4053F7: data_transfer_init (transfer.c:1932) ==4359==by 0x4006D6: MAIN__ (pr38868.f:39) ==4359==by 0x400819: main (fmain.c:21) | E(BOND)= E(ANGL)= | | E(DIHE)= E(IMPR)= E(VDW )= E(ELEC)= | ==4359== -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug tree-optimization/38895] New: missed type-based disambiguation
RTL alias analysis (nonoverlapping_component_refs_p) with a quadratic loop
finds that c-a1.i and b-a1.j cannot alias based on a offset test on the
common sub-reference base a1. The tree based alias oracle only does two
linear searches for the base type *c in b-a1.j and for *b in c-a1.i.
This is related to PR13146 where even that is not enough, but a
(non-conservative?) answer based on not finding a common base needs to be
given.
/* { dg-do compile } */
/* { dg-options -O -fstrict-aliasing -fdump-tree-optimized } */
struct A {
int i;
int j;
};
struct B {
struct A a1;
struct A a2;
};
struct C {
struct A a1;
struct B b;
};
int foo(struct C *c, struct B *b)
{
c-a1.i = 1;
b-a1.j = 0;
return c-a1.i;
}
/* { dg-final { scan-tree-dump return 1; optimized } } */
/* { dg-final { cleanup-tree-dump optimized } } */
--
Summary: missed type-based disambiguation
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization, alias, TREE
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38895
[Bug middle-end/13146] inheritance for nonoverlapping_component_refs_p
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-01-17 12:58
---
Note that we have to be very careful here because
struct X {
int i;
};
struct A {
int i;
};
struct B {
struct A a;
int j;
};
int foo (struct X *p, struct B *q)
{
p-i = 0;
q-a.i = 1;
return p-i;
}
may be aliasing. One need to consult the C standard and defect reports again
for the common initial sequence in structs stuff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13146
[Bug fortran/38152] [4.4 Regression] procedure pointers as module variables
--- Comment #12 from dominiq at lps dot ens dot fr 2009-01-17 13:20 --- (In reply to comment #11) This PR can be closed, provided there are no remaining issues on darwin9 (see comment #4 and #5). I cannot check this myself (since I don't have access to a darwin system), but maybe Dominique can? AFAICT all the tests I have run passed, so this PR can probably be closed. If I see anything I'll reopen it and report. Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug fortran/38152] [4.4 Regression] procedure pointers as module variables
--- Comment #13 from burnus at gcc dot gnu dot org 2009-01-17 13:25 --- Close as FIXED based on Dominique's remark. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug tree-optimization/38895] missed type-based disambiguation
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-17 13:57 --- Mine. -- 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 |2009-01-17 13:57:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38895
[Bug java/38717] gcc 4.4.0 20090102 - jc1: out of memory allocating ... (with 1 G of RAM)
--- Comment #6 from rob1weld at aol dot com 2009-01-17 14:32 --- Created an attachment (id=17126) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17126action=view) Screenshot of build shows libgcj_tools crashing (hogging memory) Here we have a screenshot of gcc building 'libgcj_tools' (the two humps) and crashing on the second one. The next attachment (a reboot was necessary to continue the build) shows that the second hump completes and the build finished shortly thereafter. I configured gcc using: # gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --with-long-double-128 --enable-nls --with-included-gettext --enable-gather-detailed-mem-stats --with-stabs --enable-debug --enable-largefile --enable-symvers --without-system-zlib --enable-gtk-cairo --enable-gconf-peer --enable-xmlj --enable-gtk-peer --enable-qt-peer --enable-plugin --enable-tool-wrappers --enable-local-sockets --enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug --enable-libgcj-debug --enable-objc-gc --enable-libstdcxx-debug --disable-stage1-checking --enable-checking=release --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC) It does matter which options you use since I had 'little trouble' a week ago with few additional ./configure options and 'some trouble' with a few more options added. Now that I've added all these extra options I am at a point where gcc will barely compile with all my available memory. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38717
[Bug java/38717] gcc 4.4.0 20090102 - jc1: out of memory allocating ... (with 1 G of RAM)
--- Comment #7 from rob1weld at aol dot com 2009-01-17 14:41 --- Created an attachment (id=17127) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17127action=view) Screenshot of build shows libgcj_tools building (after reboot) Before reboot: # gmake ... gmake[3]: Entering directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava' if /bin/sh ./libtool --tag=GCJ --mode=compile /usr/share/src/gcc_build/gcc/gcj -B/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/ -B/usr/share/src/gcc_build/gcc/ -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../gcc_trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -findirect-dispatch -fno-indirect-classes -fsource-filename=/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/classpath/tools/all-classes.lst -g -O2 -MT classpath/tools/libgcj_tools_la-tools.lo -MD -MP -MF classpath/tools/.deps/libgcj_tools_la-tools.Tpo -c -o classpath/tools/libgcj_tools_la-tools.lo `test -f 'classpath/tools/tools.zip' || echo '../../../gcc_trunk/libjava/'`classpath/tools/tools.zip; \ then mv -f classpath/tools/.deps/libgcj_tools_la-tools.Tpo classpath/tools/.deps/libgcj_tools_la-tools.Plo; else rm -f classpath/tools/.deps/libgcj_tools_la-tools.Tpo; exit 1; fi libtool: compile: /usr/share/src/gcc_build/gcc/gcj -B/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/ -B/usr/share/src/gcc_build/gcc/ -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../gcc_trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -findirect-dispatch -fno-indirect-classes -fsource-filename=/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava/classpath/tools/all-classes.lst -g -O2 -MT classpath/tools/libgcj_tools_la-tools.lo -MD -MP -MF classpath/tools/.deps/libgcj_tools_la-tools.Tpo -c classpath/tools/tools.zip -fPIC -o classpath/tools/.libs/libgcj_tools_la-tools.o jc1: out of memory allocating 4072 bytes after a total of 688709632 bytes gmake[3]: *** [classpath/tools/libgcj_tools_la-tools.lo] Error 1 gmake[3]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava' gmake[1]: *** [all-target-libjava] Error 2 gmake[1]: Leaving directory `/usr/share/src/gcc_build' After reboot: # gmake ... libtool: link: /usr/share/src/gcc_build/./gcc/xgcc -shared-libgcc -B/usr/share/src/gcc_build/./gcc -nostdinc++ -L/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/src -L/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/src/.libs -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -shared -nostdlib /usr/lib/crti.o /usr/lib/values-Xa.o /usr/share/src/gcc_build/./gcc/crtbegin.o classpath/tools/.libs/libgcj_tools_la-tools.o -L/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/src -L/usr/share/src/gcc_build/i386-pc-solaris2.11/libstdc++-v3/src/.libs -L/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava -L/usr/share/src/gcc_build/./gcc -L/usr/local/i386-pc-solaris2.11/bin -L/usr/local/i386-pc-solaris2.11/lib -lgcc_s /usr/share/src/gcc_build/./gcc/crtend.o /usr/lib/crtn.o -Wl,--version-script=../../../gcc_trunk/libjava/libgcj.ver -Wl,-Bsymbolic-functions -Wl,-soname -Wl,libgcj-tools.so.10 -o .libs/libgcj-tools.so.10.0.0 libtool: link: (cd .libs rm -f libgcj-tools.so.10 ln -s libgcj-tools.so.10.0.0 libgcj-tools.so.10) libtool: link: (cd .libs rm -f libgcj-tools.so ln -s libgcj-tools.so.10.0.0 libgcj-tools.so) libtool: link: ( cd .libs rm -f libgcj-tools.la ln -s ../libgcj-tools.la libgcj-tools.la ) ... I was at a point were the size of gcc's build was very near all the memory that I had available and I needed to reboot my OS to ensure I had every last byte available. With the reboot I was just barely able to compile the second 'libgcj_tools' using the maximum available under VirtualBox. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38717
[Bug fortran/38859] [4.3/4.4 Regression] ubound and lbound treat structure component references as whole arrays
--- Comment #4 from mikael at gcc dot gnu dot org 2009-01-17 14:59 --- shouldn't this be fixed for 4.3.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38859
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #21 from sebpop at gmail dot com 2009-01-17 15:11 --- Subject: Re: r143152 breaks output routines in xplor-nih On Sat, Jan 17, 2009 at 6:29 AM, dominiq at lps dot ens dot fr gcc-bugzi...@gcc.gnu.org wrote: Somehow I got the impression that graphite is now enabled at -O2 We did enabled -floop-block and -fgraphite-identity in -O2 and higher, again, only in the graphite branch, not in trunk. Sebastian -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug other/38805] sed Unterminated `s' command
--- Comment #10 from thomas dot jourdan at gmail dot com 2009-01-17 15:23
---
Hi
My mistake was to export a function in the bash to fool a shell script. But
then I configured GCC without removing it.
I did :
function install() { ginstall $@; }
export -f install
Then I configured GCC, which led to the problem. Thanks to Ralf :
./config.status -d
config.status: creating as
sed: file ./confstatg0aq6N/subs-5.sed line 7: unterminated `s' command
config.status: creating collect-ld
sed: file ./confstatg0aq6N/subs-5.sed line 7: unterminated `s' command
config.status: creating nm
sed: file ./confstatg0aq6N/subs-5.sed line 7: unterminated `s' command
config.status: creating Makefile
sed: file ./confstatg0aq6N/subs-5.sed line 7: unterminated `s' command
config.status: creating gccbug
sed: file ./confstatg0aq6N/subs-5.sed line 7: unterminated `s' command
config.status: creating libada-mk
sed: file ./confstatg0aq6N/subs-5.sed line 7: unterminated `s' command
config.status: creating ada/Makefile
sed: file ./confstatg0aq6N/subs-5.sed line 7: unterminated `s' command
config.status: creating auto-host.h
config.status: auto-host.h is unchanged
config.status: executing default commands
Then we can see the output file :
cat confstatg0aq6N/subs-5.sed
:t
/@[a-zA-Z_][a-zA-Z_0-9]*@/!b
s,@host_xm_file_list@, auto-host.h $(srcdir)/../include/ansidecl.h,;t t
s,@host_xm_include_list@, auto-host.h ansidecl.h,;t t
s,@host_xm_defines@,,;t t
s,@out_host_hook_obj@,host-solaris.o,;t t
s,@install@,() { ginstall $@
},;t t
s,@lang_opt_files@,
/export/home/thomas/workspace/cdk/i686/targets/src/gcc-4.3.2/gcc/ada/lang.opt
/export/home/thomas/workspace/cdk/i686/targets/src/gcc-4.3.2/gcc/fortran/lang.opt
/export/home/thomas/workspace/cdk/i686/targets/src/gcc-4.3.2/gcc/java/lang.opt
/export/home/thomas/workspace/cdk/i686/targets/src/gcc-4.3.2/gcc/treelang/lang.opt,;t
t
s,@lang_specs_files@,,;t t
s,@lang_tree_files@,
/export/home/thomas/workspace/cdk/i686/targets/src/gcc-4.3.2/gcc/ada/ada-tree.def
/export/home/thomas/workspace/cdk/i686/targets/src/gcc-4.3.2/gcc/cp/cp-tree.def
/export/home/thomas/workspace/cdk/i686/targets/src/gcc-4.3.2/gcc/java/java-tree.def
/export/home/thomas/workspace/cdk/i686/targets/src/gcc-4.3.2/gcc/objc/objc-tree.def,;t
t
s,@local_prefix@,/export/home/thomas/x-tools/i686-nptl-linux-gnu/i686-nptl-linux-gnu/sys-root,;t
t
s,@md_file@,i386/i386.md,;t t
s,@objc_boehm_gc@,,;t t
s,@out_file@,i386/i386.c,;t t
s,@out_object_file@,i386.o,;t t
s,@thread_file@,single,;t t
s,@tm_file_list@,options.h $(srcdir)/config/i386/i386.h
$(srcdir)/config/i386/unix.h $(srcdir)/config/i386/att.h
$(srcdir)/config/dbxelf.h $(srcdir)/config/elfos.h $(srcdir)/config/svr4.h
$(srcdir)/config/linux.h $(srcdir)/config/i386/linux.h $(srcdir)/defaults.h,;t
t
s,@tm_include_list@,options.h config/i386/i386.h config/i386/unix.h
config/i386/att.h config/dbxelf.h config/elfos.h config/svr4.h config/linux.h
config/i386/linux.h defaults.h,;t t
s,@tm_defines@, UCLIBC_DEFAULT=0,;t t
s,@tm_p_file_list@, $(srcdir)/config/i386/i386-protos.h tm-preds.h,;t t
s,@tm_p_include_list@, config/i386/i386-protos.h tm-preds.h,;t t
s,@xm_file_list@, auto-host.h $(srcdir)/../include/ansidecl.h,;t t
s,@xm_include_list@, auto-host.h ansidecl.h,;t t
s,@xm_defines@,,;t t
s,@c_target_objs@,,;t t
s,@cxx_target_objs@,,;t t
s,@target_cpu_default@,,;t t
s,@GMPLIBS@,-L/export/home/thomas/x-tools/i686-nptl-linux-gnu/lib
-L/export/home/thomas/x-tools/i686-nptl-linux-gnu/lib -lmpfr -lgmp,;t t
s,@GMPINC@,-I/export/home/thomas/x-tools/i686-nptl-linux-gnu/include
-I/export/home/thomas/x-tools/i686-nptl-linux-gnu/include,;t t
s,@LIBOBJS@,,;t t
s,@LTLIBOBJS@,,;t t
/@language_hooks@/r Make-hooks
s,@language_hooks@,,;t t
And as you can see, you find my install function replaced. This makes sed
unhappy.
Regards,
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38805
[Bug debug/38896] New: [4.3 Regression] building libstdc++ stumbles on invalid bignum, 0x8000000000000000
Attached is locale-inst.ii for gcc-4_3-branch revision 143448. The assembler says, during build: locale-inst.s: Assembler messages: locale-inst.s:192360: Error: bignum invalid The line, with context, is (with -dA -mpdebug for improved clarity, but causing the line number to change to 203626): 203615 .dword 0x1fd ;# DW_AT_type 203616 .byte 0x1 ;# DW_AT_external 203617 .byte 0x1 ;# DW_AT_declaration 203618 .uleb128 0xb6 ;# (DIE (0x227ba) DW_TAG_variable) 203619 .dword .LASF1471 ;# DW_AT_name: __min 203620 .byte 0x36;# DW_AT_decl_file (/tmp/hptest/v32l/gccobj/crisv32-axis-linux-gnu/libstdc++-v3/include/ 203620 ext/numeric_traits.h) 203621 .byte 0x3e;# DW_AT_decl_line 203622 .dword .LASF1591 ;# DW_AT_MIPS_linkage_name: _ZN9__gnu_cxx24__numeric_traits_integerIxE5__minE 203623 .dword 0x839f ;# DW_AT_type 203624 .byte 0x1 ;# DW_AT_external 203625 .byte 0x1 ;# DW_AT_declaration 203626 .sleb128 -9223372036854775808 ;# DW_AT_const_value 203627 .uleb128 0xba ;# (DIE (0x227d6) DW_TAG_variable) 203628 .dword .LASF1472 ;# DW_AT_name: __max 203629 .byte 0x36;# DW_AT_decl_file (/tmp/hptest/v32l/gccobj/crisv32-axis-linux-gnu/libstdc++-v3/include/ 203629 ext/numeric_traits.h) 203630 .byte 0x3f;# DW_AT_decl_line 203631 .dword .LASF1592 ;# DW_AT_MIPS_linkage_name: _ZN9__gnu_cxx24__numeric_traits_integerIxE5__maxE 203632 .dword 0x839f ;# DW_AT_type 203633 .byte 0x1 ;# DW_AT_external 203634 .byte 0x1 ;# DW_AT_declaration 203635 .quad 0x7fff ;# DW_AT_const_value 203636 .uleb128 0x4f ;# (DIE (0x227f0) DW_TAG_variable) 203637 .dword .LASF1561 ;# DW_AT_name: __is_signed The number -9223372036854775808 is also known as 0x8000. I've been able to build for this target on the gcc-4.3 branch before. -- Summary: [4.3 Regression] building libstdc++ stumbles on invalid bignum, 0x8000 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: debug 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: crisv32-axis-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
[Bug debug/38896] [4.3 Regression] building libstdc++ stumbles on invalid bignum, 0x8000000000000000
--- Comment #1 from hp at gcc dot gnu dot org 2009-01-17 15:44 --- Created an attachment (id=17128) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17128action=view) as mentioned Use cc1plus -fpreprocessed locale-inst.ii -march=v32 -quiet -dumpbase locale-inst.cc -dA -mpdebug -auxbase-strip .libs/locale-inst.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -fPIC -o locale-inst.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
[Bug fortran/38859] [4.3/4.4 Regression] ubound and lbound treat structure component references as whole arrays
--- Comment #5 from burnus at gcc dot gnu dot org 2009-01-17 15:45 --- shouldn't this be fixed for 4.3.3? Too late - the release is too soon (freeze; release-candidate build is running). Regarding 4.4.0: Do you plan to submit a patch soonish? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38859
[Bug debug/38896] [4.3 Regression] building libstdc++ stumbles on invalid bignum, 0x8000000000000000
--- Comment #2 from hp at gcc dot gnu dot org 2009-01-17 15:46 --- Configured with /tmp/hptest/v32l/gcc/configure --prefix=/n/common_data/comptools/cris-1.64-64 --target=crisv32-axis-linux-gnu --with-gnu-ld --with-gnu-as --enable-checking -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
[Bug libstdc++/32666] FAIL: abi_check hppa
--- Comment #16 from dave at hiauly1 dot hia dot nrc dot ca 2009-01-17 16:02 --- Subject: Re: FAIL: abi_check hppa I think we also need float stubs. I saw some problems with floorf in the testsuite in my last build. There are four testsuite fails due to floorf being missing. Here's one: Executing on host: /test/gnu/gcc/objdir/./gcc/g++ -shared-libgcc -B/test/gnu/gcc /objdir/./gcc -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++ -v3/src -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs -B/o pt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.4.0/hppa2.0 w-hp-hpux11.11/lib/ -isystem /opt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/includ e -isystem /opt/gnu/gcc/gcc-4.4.0/hppa2.0w-hp-hpux11.11/sys-include -g -O2 -D_GL IBCXX_ASSERT -fmessage-length=0 -g -O2 -g -O2 -DLOCALEDIR=. -nostdinc++ -I/t est/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11 .11 -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include -I/test/gn u/gcc/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backwa rd -I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util /test/gnu/gcc/gcc/libstdc++-v 3/testsuite/tr1/5_numerical_facilities/special_functions/12_ellint_1/check_nan.c c-include bits/stdc++.h ./libtestc++.a -lm -o ./check_nan.exe (timeout = 600) /usr/ccs/bin/ld: Unsatisfied symbols: floorf (first referenced in /var/tmp//ccLVzphs.o) (code) collect2: ld returned 1 exit status ... FAIL: tr1/5_numerical_facilities/special_functions/12_ellint_1/check_nan.cc (tes t for excess errors) Other f functions that are checked for and missing on hppa2.0w-hp-hpux11.11 are, ceilf, finitef, frexpf, hypotf, isnanf, ldexpf, modff, sincosf, strtof. HP-UX 10 is the same except for having finitef and isnanf. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32666
[Bug tree-optimization/38895] missed type-based disambiguation
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-17 16:03 --- Subject: Bug 38895 Author: rguenth Date: Sat Jan 17 16:02:36 2009 New Revision: 143469 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143469 Log: 2009-01-17 Richard Guenther rguent...@suse.de PR middle-end/13146 PR tree-optimization/38895 * tree-ssa-alias.c (same_type_for_tbaa): New helper function. (refs_may_alias_p): Use it. Extend access path based disambiguation. * gcc.dg/tree-ssa/pr13146.c: New testcase. * gcc.dg/tree-ssa/pr38895.c: Likewise. * g++.dg/tree-ssa/pr13146.C: Likewise. Added: branches/alias-improvements/gcc/testsuite/g++.dg/tree-ssa/pr13146.C branches/alias-improvements/gcc/testsuite/gcc.dg/tree-ssa/pr13146.c branches/alias-improvements/gcc/testsuite/gcc.dg/tree-ssa/pr38895.c Modified: branches/alias-improvements/gcc/ChangeLog.alias branches/alias-improvements/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38895
[Bug middle-end/13146] inheritance for nonoverlapping_component_refs_p
--- Comment #13 from rguenth at gcc dot gnu dot org 2009-01-17 16:03 --- Subject: Bug 13146 Author: rguenth Date: Sat Jan 17 16:02:36 2009 New Revision: 143469 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143469 Log: 2009-01-17 Richard Guenther rguent...@suse.de PR middle-end/13146 PR tree-optimization/38895 * tree-ssa-alias.c (same_type_for_tbaa): New helper function. (refs_may_alias_p): Use it. Extend access path based disambiguation. * gcc.dg/tree-ssa/pr13146.c: New testcase. * gcc.dg/tree-ssa/pr38895.c: Likewise. * g++.dg/tree-ssa/pr13146.C: Likewise. Added: branches/alias-improvements/gcc/testsuite/g++.dg/tree-ssa/pr13146.C branches/alias-improvements/gcc/testsuite/gcc.dg/tree-ssa/pr13146.c branches/alias-improvements/gcc/testsuite/gcc.dg/tree-ssa/pr38895.c Modified: branches/alias-improvements/gcc/ChangeLog.alias branches/alias-improvements/gcc/tree-ssa-alias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13146
[Bug debug/38896] [4.3 Regression] building libstdc++ stumbles on invalid bignum, 0x8000000000000000
--- Comment #3 from hp at gcc dot gnu dot org 2009-01-17 16:06 --- Um, ok, it's __gnu_cxx::__numeric_traits_integerlong long::__min so the number as such is most likely valid. :) Not sure if that number is supposed to be valid as a .sleb128 operand though. I'd better assign this to myself and check. -- hp at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-17 16:06:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
[Bug debug/38896] [4.3 Regression] building libstdc++ stumbles on invalid bignum, 0x8000000000000000
--- Comment #4 from hp at gcc dot gnu dot org 2009-01-17 16:12 --- Trunk binutils accepts it but produces junk: Contents of section .text: 80808080 80808080 807f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
[Bug debug/38896] [4.3 Regression] building libstdc++ stumbles on invalid bignum, 0x8000000000000000
--- Comment #5 from hp at gcc dot gnu dot org 2009-01-17 16:15 --- (In reply to comment #4) 80808080 80808080 807f Silly me, that's the right sleb128 encoding, IIUC. Doh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
[Bug debug/38896] [4.3 Regression] building libstdc++ stumbles on invalid bignum, 0x8000000000000000
--- Comment #6 from hp at gcc dot gnu dot org 2009-01-17 16:38 --- (In reply to comment #3) I'd better assign this to myself and check. FWIW, the assembler that complained was an old 2.12.something. There's a gcc sleb128 configure check, but it doesn't check for large numbers. -- hp at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
[Bug middle-end/38868] r143152 breaks output routines in xplor-nih
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2009-01-17 16:40 --- Comment 20 was compiled with -static -g. Each error is at functions outside libgfortran. Valgrind reports zero errors if the test case is compiled without -static. I suspect comment 20 is misleading. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #1 from ubizjak at gmail dot com 2009-01-17 17:04 ---
The problem is in a thinko in alias.c, base_alias_check (). For our problematic
addresses, we enter base_alias_check with:
x = (reg:DI 18 $18 [ i ])
and
y = (and:DI (reg/f:DI 16 $16 [orig:69 __result ] [69])
(const_int -8 [0xfff8]))
We actually have the code that handles this situation, just after the comment:
/* The base addresses of the read and write are different expressions.
If they are both symbols and they are not accessed via AND, there is
no conflict. We can bring knowledge of object alignment into play
here. For example, on alpha, char a, b; can alias one another,
though char a; long b; cannot. */
At the start of this code, we have:
base_x = (address (reg:DI 18 $18))
and
base_y = (address (reg:DI 16 $16))
These RTXes should trigger the code that analyses addresses involving AND
operation. So, actually we have to reverse the guarding condition!
Following patch fixes the failure:
--cut here--
Index: alias.c
===
--- alias.c (revision 143461)
+++ alias.c (working copy)
@@ -1527,7 +1527,7 @@ base_alias_check (rtx x, rtx y, enum mac
no conflict. We can bring knowledge of object alignment into play
here. For example, on alpha, char a, b; can alias one another,
though char a; long b; cannot. */
- if (GET_CODE (x_base) != ADDRESS GET_CODE (y_base) != ADDRESS)
+ if (GET_CODE (x_base) == ADDRESS || GET_CODE (y_base) == ADDRESS)
{
if (GET_CODE (x) == AND GET_CODE (y) == AND)
return 1;
--cut here--
Now, the scheduler creates correct schedule:
;; 12--17 $7=$17|$8 :(ev4_ib0+ev4_ebox)
;; 13--21 $4=unspec[$7,0x40,$16] 2 :(ev4_ib0+ev4_ebox)
;; 14--22 $5=$7$160x3 :(ev4_ib0+ev4_ebox)
;; 15--25 $3=$6|$4 :(ev4_ib0+ev4_ebox)
;; 15--27 [$16+0x70xfff8]=$3 :(ev4_ib1+ev4_abox)
;; 16--26 $0=$2|$5 :(ev4_ib0+ev4_ebox)
;; 16--28 [$160xfff8]=$0 :(ev4_ib1+ev4_abox)
;; 17--30 [$18]=$1 :(ev4_ib1+ev4_abox)
;; 18--45 return
:(ev4_ib1+ev4_bbox),ev4_bbox
And the asm is correct:
w_:
.frame $30,0,$26,0
ldah $29,0($27) !gpdisp!1
lda $29,0($29) !gpdisp!1
$w_..ng:
.prologue 1
ldah $25,$LC0($29) !gprelhigh
cpys $f31,$f31,$f31
lda $22,$LC0($25) !gprellow
ldq_u $21,7($16)
and $22,7,$20
ldq_u $24,$LC0($25) !gprellow
ldq_u $23,7($22)
bis $31,$31,$31
mskqh $21,$16,$6
ldq_u $19,0($16)
extql $24,$22,$17
extqh $23,$22,$8
mskql $19,$16,$2
cmoveq $20,0,$8
lda $1,8($31)
bis $17,$8,$7
insqh $7,$16,$4
insql $7,$16,$5
bis $6,$4,$3
stq_u $3,7($16)
bis $2,$5,$0
stq_u $0,0($16)
stl $1,0($18)
ret $31,($26),1
.end w_
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-01-17 17:04:31
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
[Bug debug/38896] [4.3 Regression] building libstdc++ stumbles on invalid bignum, 0x8000000000000000
--- Comment #7 from hp at gcc dot gnu dot org 2009-01-17 17:19 --- So... fixing the sleb128 configure test (to check that this number is parsed and handled correctly) is fairly simple, but should perhaps only be done for targets that actually will use 64-bit numbers. If someone wants to take this and run with it, fine by me. Unassigning, for now. -- hp at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|hp at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #2 from steven at gcc dot gnu dot org 2009-01-17 18:05 --- That code is ancient, and wrong from day 1 if your analysis is correct :-) http://gcc.gnu.org/viewcvs/trunk/gcc/alias.c?r1=21967r2=23060 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
[Bug libstdc++/38897] New: Parallel mode example code does not compile
Compilation fails of the small code sample found at:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch31s03.html
I am using the suggested compiler options.
This is the code (cut and pasted from your documentation):
#include vector
#include parallel/algorithm
int main()
{
std::vectorint v(100);
// ...
// Explicitly force a call to parallel sort.
__gnu_parallel::sort(v.begin(), v.end());
return 0;
}
If it is this code that is incorrect the docs should be fixed as there are not
many examples of parallel libstdc++ usage to be found on the net at the
moment.
This is g++ output:
g++ -v -save-temps -fopenmp -march=i686 -o test parallelsort.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-march=i686' '-o' 'test'
'-shared-libgcc' '-pthread'
/usr/lib/gcc/i486-linux-gnu/4.3.2/cc1plus -E -quiet -v -D_GNU_SOURCE
-D_REENTRANT parallelsort.cpp -D_FORTIFY_SOURCE=2 -march=i686 -fopenmp
-fpch-preprocess -o parallelsort.ii
ignoring nonexistent directory /usr/local/include/i486-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/i486-linux-gnu/4.3.2/../../../../i486-linux-gnu/include
ignoring nonexistent directory /usr/include/i486-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.3
/usr/include/c++/4.3/i486-linux-gnu
/usr/include/c++/4.3/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.3.2/include
/usr/lib/gcc/i486-linux-gnu/4.3.2/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-fopenmp' '-march=i686' '-o' 'test'
'-shared-libgcc' '-pthread'
/usr/lib/gcc/i486-linux-gnu/4.3.2/cc1plus -fpreprocessed parallelsort.ii
-quiet -dumpbase parallelsort.cpp -march=i686 -auxbase parallelsort -version
-fopenmp -fstack-protector -o parallelsort.s
GNU C++ (Ubuntu 4.3.2-1ubuntu11) version 4.3.2 (i486-linux-gnu)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: dc8f858cacda993dd8f70837f0d9565d
/usr/include/c++/4.3/parallel/algo.h: In function void
std::__parallel::sort(_RAIter, _RAIter) [with _RAIter =
__gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint ]:
parallelsort.cpp:11: instantiated from here
/usr/include/c++/4.3/parallel/algo.h:1736: error: call of overloaded
sort(__gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint
, __gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint
, std::lessint) is ambiguous
/usr/include/c++/4.3/parallel/algo.h:1741: note: candidates are: void
std::__parallel::sort(_RAIter, _RAIter, _Compare) [with _RAIter =
__gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint ,
_Compare = std::lessint]
/usr/include/c++/4.3/bits/stl_algo.h:4806: note: void
std::sort(_RAIter, _RAIter, _Compare) [with _RAIter =
__gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint ,
_Compare = std::lessint]
So it can't resolve the ambiguous overloading between a parallel and
non-parallel version of sort.
I am not sure which -march option i should be using, but i tried using none,
-march=i686, and -march=native, with identical results.
This is an up-to-date ubuntu 8.10, by the way.
--
Summary: Parallel mode example code does not compile
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j dot s dot sebastian at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38897
[Bug middle-end/38846] [Graphite] 70% slower using -floop* than without graphite (gas_dyn of Polyhedron)
--- Comment #4 from dominiq at lps dot ens dot fr 2009-01-17 18:12 --- I have similar results as comment #0 on i686-apple-darwin9 (Core2) trunk revision 143468: Date Time : 17 Jan 2009 17:41:32 Test Name : pbharness Compile Command : gfc %n.f90 -m64 -O3 -ffast-math -funroll-loops -fgraphite -fgraphite-identity -floop-block -floop-strip-mine -floop-interchange -ftree-loop-linear -fomit-frame-pointer -finline-limit=600 --param min-vect-loop-bound=2 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 300.0 Target Error % : 0.200 Minimum Repeats : 2 Maximum Repeats : 5 Benchmark Compile Executable Ave Run Number Estim Name(secs) (bytes)(secs) Repeats Err % - --- -- --- --- -- ac 4.86 42560 12.31 5 0.2625 aermod 87.72 1270544 30.36 5 0.2338 air 5.73 77336 8.38 5 0.0536 capacita 4.13 72760 45.60 2 0.0055 channel 1.69 30456 2.71 2 0.0368 doduc 11.71 200024 42.88 2 0.0501 fatigue 4.26 76736 12.91 2 0.0852 gas_dyn 5.83 692200 22.24 5 0.4693 induct 10.17 177072 34.38 2 0.1440 linpk 1.67 42536 28.21 5 0.3051 mdbx 3.43 73000 14.79 2 0.0068 nf 14.82 112264 32.25 2 0.1612 protein 9.92 114136 45.90 2 0.1961 rnflow 11.24 171464 37.49 2 0.0960 test_fpu 9.49 154224 13.06 2 0.1263 tfft 1.15 26432 2.88 5 0.2609 Geometric Mean Execution Time = 18.18 seconds ... Finished Testing 16 benchmarks - 16 passed, and 0 failed compared to Date Time : 17 Jan 2009 18:03:59 Test Name : pbharness Compile Command : gfc %n.f90 -m64 -O3 -ffast-math -funroll-loops -ftree-loop-linear -fomit-frame-pointer -finline-limit=600 --param min-vect-loop-bound=2 -o %n Benchmarks : ac aermod air capacita channel doduc fatigue gas_dyn induct linpk mdbx nf protein rnflow test_fpu tfft Maximum Times : 300.0 Target Error % : 0.200 Minimum Repeats : 2 Maximum Repeats : 5 Benchmark Compile Executable Ave Run Number Estim Name(secs) (bytes)(secs) Repeats Err % - --- -- --- --- -- ac 2.38 42560 12.33 5 0.3327 aermod 86.86 1270544 29.86 2 0.0151 air 5.53 77336 8.39 5 0.2713 capacita 3.40 72760 55.49 5 0.5426 channel 1.98 38648 2.27 2 0. doduc 11.42 200024 42.93 2 0.1456 fatigue 4.94 89024 10.83 5 0.2533 gas_dyn 6.61 708584 10.38 2 0.1541 induct 9.95 181168 34.41 2 0.0727 linpk 1.50 42536 27.98 2 0.0804 mdbx 3.30 73000 14.81 2 0.0911 nf 24.30 161416 32.06 4 0.1922 protein 10.54 126424 46.18 2 0.1646 rnflow 10.93 179616 36.00 2 0.0014 test_fpu 10.26 166512 12.45 2 0.0723 tfft 1.10 26432 2.86 5 0.2793 Geometric Mean Execution Time = 17.05 seconds The 70% for gas_dyn turns to be more than a factor 2, and capacita is faster by almost 20% with floop-block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38846
[Bug rtl-optimization/38879] scheduler does not look for conflicting alias sets
--- Comment #3 from ubizjak at gmail dot com 2009-01-17 18:40 ---
(In reply to comment #2)
That code is ancient, and wrong from day 1 if your analysis is correct :-)
Hm, no. The code is correct, but applies only to symbols involving ANDs.
We need somehing like this code also for the case when one of operands is
non-symbol and the other involves AND. I'm testing following patch:
--cut here--
Index: alias.c
===
--- alias.c (revision 143461)
+++ alias.c (working copy)
@@ -1543,6 +1543,20 @@ base_alias_check (rtx x, rtx y, enum mac
return 0;
}
+ if (GET_CODE (x_base) == ADDRESS || GET_CODE (y_base) == ADDRESS)
+{
+ if (GET_CODE (x) == AND GET_CODE (y) == AND)
+ return 1;
+ if (GET_CODE (x) == AND
+ (GET_CODE (XEXP (x, 1)) != CONST_INT
+ || (int) GET_MODE_UNIT_SIZE (y_mode) -INTVAL (XEXP (x, 1
+ return 1;
+ if (GET_CODE (y) == AND
+ (GET_CODE (XEXP (y, 1)) != CONST_INT
+ || (int) GET_MODE_UNIT_SIZE (x_mode) -INTVAL (XEXP (y, 1
+ return 1;
+}
+
/* If one address is a stack reference there can be no alias:
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38879
[Bug testsuite/38898] New: gcc 4.4.0 20090117 - Testsuite - tree-ssa.exp - unmatched brace
The Testsuite is broken. # gmake -i -k check ... Running /usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp ... Running /usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp ... XPASS: gcc.dg/tree-ssa/20040204-1.c scan-tree-dump-times optimized link_error 0 ERROR: tcl error sourcing /usr/share/src/gcc_trunk/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp. ERROR: unmatched open brace in list ... # gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --with-long-double-128 --enable-nls --with-included-gettext --enable-gather-detailed-mem-stats --with-stabs --enable-debug --enable-largefile --enable-symvers --without-system-zlib --enable-gtk-cairo --enable-gconf-peer --enable-xmlj --enable-gtk-peer --enable-qt-peer --enable-plugin --enable-tool-wrappers --enable-local-sockets --enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug --enable-libgcj-debug --enable-objc-gc --enable-libstdcxx-debug --disable-stage1-checking --enable-checking=release --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090117 (experimental) [trunk revision 143454] (GCC) Thanks, Rob -- Summary: gcc 4.4.0 20090117 - Testsuite - tree-ssa.exp - unmatched brace Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38898
[Bug testsuite/38898] gcc 4.4.0 20090117 - Testsuite - tree-ssa.exp - unmatched brace
--- Comment #1 from schwab at suse dot de 2009-01-17 19:37 --- http://gcc.gnu.org/ml/gcc-cvs/2009-01/msg00468.html -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38898
[Bug target/38899] New: pessimizes function without SSE intrinsics
[ Forwarded from http://bugs.debian.org/512050 ] brian m. carlson reports the following problem with gcc 4.3 and trunk: Attached is a C file that is compiled with -O3. mul and mul2 perform the same operation; mul uses a loop, and mul2 uses SSE intrinsics. mul2 results in three instructions, whereas mul results in many, many more. Obviously, since the two functions do the exact same thing, they should be optimized to be identical. Instead, mul is pessimized. Note that there are no alignment issues present since the arrays declared in main are 16-byte aligned (since they are allocated on the stack, which is 16-byte aligned on x86_64). And: I also just noted that gcc-4.1 and gcc-4.2 produce much less bad code: they each use 8 movss and 4 mulss. Nevertheless, they still do not convert the code into three SSE instructions. -- Summary: pessimizes function without SSE intrinsics Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38899
[Bug target/38899] pessimizes function without SSE intrinsics
--- Comment #1 from tbm at cyrius dot com 2009-01-17 19:40 ---
Testcase:
#include stdio.h
#include xmmintrin.h
#ifndef MUL
#define MUL mul
#endif
void mul(float in1[4], float in2[4], float out[4])
{
int i;
for (i = 0; i 4; i++)
out[i] = in1[i] * in2[i];
}
void mul2(float in1[4], float in2[4], float out[4])
{
__m128 a, b, c;
a = _mm_load_ps(in1);
b = _mm_load_ps(in2);
c = _mm_mul_ps(a, b);
_mm_store_ps(out, c);
}
int main(void)
{
float inp1[] = {
1.2, 3.5, 1.7, 2.8
};
float inp2[] = {
-0.7, 2.6, 3.3, -4.0
};
float outp[4];
MUL(inp1, inp2, outp);
printf(%f %f %f %f\n, outp[0], outp[1], outp[2], outp[3]);
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38899
[Bug bootstrap/38862] Bootstrap failure on HEAD with static linking vs. graphite
--- Comment #2 from davek at gcc dot gnu dot org 2009-01-17 21:06 --- Subject: Bug 38862 Author: davek Date: Sat Jan 17 21:06:17 2009 New Revision: 143472 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143472 Log: PR bootstrap/38862 * Makefile.in (BACKENDLIBS): Reorder to match dependencies. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38862
[Bug c/38891] ms_abi function attribute fails with -mno-sse
--- Comment #1 from a dot pignotti at sssup dot it 2009-01-17 22:11 --- Created an attachment (id=17129) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17129action=view) Proposed test case compile using gcc -mno-sse to trigger the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38891
[Bug fortran/38887] [4.4 Regression] run-time abort for MVBITS with run-time zero sized array arguments
--- Comment #2 from burnus at gcc dot gnu dot org 2009-01-17 22:20 --- Created an attachment (id=17130) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17130action=view) Difference of the dump The problem is the call _gfortran_internal_unpack (parm.2, D.1572); since the array has zero extent. The _gfortrani_internal_unpack_4 has the following check: 61extent[n] = d-dim[n].ubound + 1 - d-dim[n].lbound; 62if (extent[n] = 0) 63 abort (); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38887
[Bug rtl-optimization/38740] [4.4 Regression] Incorrect delayed branch optimization
--- Comment #10 from danglin at gcc dot gnu dot org 2009-01-17 22:34
---
This is the last output of the register usage information prior to the dbr
pass. I am somewhat puzzled as to why register 124 doesn't appear as
allocated to %r28 in the lr in and lr use lines for blocks 4 and 9.
;; Start of basic block ( 4) - 9
;; bb 9 artificial_defs: { }
;; bb 9 artificial_uses: { u-1(3){ }u-1(30){ }}
;; lr in3 [%r3] 30 [%r30] 124
;; lr use 3 [%r3] 30 [%r30] 124
;; lr def 140
;; Pred edge 4
(code_label 35 466 453 9 774 [1 uses])
(note 453 35 36 9 [bb 9] NOTE_INSN_BASIC_BLOCK)
(insn 36 453 37 9 LZMAEncoder.cc:3105 (set (reg:SI 19 %r19 [140])
(const_int 1105 [0x451])) 37 {*pa.md:2552} (nil))
(jump_insn 37 36 454 9 LZMAEncoder.cc:3105 (set (pc)
(if_then_else (eq (reg:SI 28 %r28 [orig:124 D.7781 ] [124])
(reg:SI 19 %r19 [140]))
(label_ref 124)
(pc))) 25 {*pa.md:1780} (nil))
;; End of basic block 9 - ( 25 10)
;; lr out 3 [%r3] 30 [%r30] 124
;; Succ edge 25
;; Succ edge 10 (fallthru)
;; Start of basic block ( 9) - 10
;; bb 10 artificial_defs: { }
;; bb 10 artificial_uses: { u-1(3){ }u-1(30){ }}
;; lr in3 [%r3] 30 [%r30] 124
;; lr use 3 [%r3] 30 [%r30] 124
;; lr def 141
;; Pred edge 9 (fallthru)
(note 454 37 38 10 [bb 10] NOTE_INSN_BASIC_BLOCK)
(insn 38 454 39 10 LZMAEncoder.cc:3105 (set (reg:SI 19 %r19 [141])
(const_int 1105 [0x451])) 37 {*pa.md:2552} (nil))
(jump_insn 39 38 455 10 LZMAEncoder.cc:3105 (set (pc)
(if_then_else (gtu (reg:SI 28 %r28 [orig:124 D.7781 ] [124])
(reg:SI 19 %r19 [141]))
(label_ref 44)
(pc))) 25 {*pa.md:1780} (nil))
;; End of basic block 10 - ( 13 11)
;; lr out 3 [%r3] 30 [%r30] 124
;; Start of basic block ( 9) - 25
;; bb 25 artificial_defs: { };; bb 25 artificial_uses: { u-1(3){ }u-1(30){ }}
;; lr in3 [%r3] 30 [%r30]
;; lr use 3 [%r3] 30 [%r30]
;; lr def 118 177 178
;; Pred edge 9
(code_label 124 482 125 25 771 [1 uses])
(note 125 124 126 25 [bb 25] NOTE_INSN_BASIC_BLOCK)
(insn 126 125 127 25 LZMAEncoder.cc:3128 (set (reg/f:SI 28 %r28 [177])
(mem/f/c/i:SI (plus:SI (reg/f:SI 3 %r3)
(const_int 48 [0x30])) [0 prop+0 S4 A64])) 37 {*pa.md:2552}
(nil
))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38740
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #23 from burnus at gcc dot gnu dot org 2009-01-17 22:51 --- Program of comment 19 works here (x86-64) with all options I tried, incl. -m32, -fgraphite-identity etc. - valgrind shows no problems. For the program in attachment 17125 / commment 13: I get the same valgrind output as Richard, but comparing with NAG f95 shows similar valgrind errors and with checking turned on, the NAG f95 compiled program aborts with: Reference to undefined variable ANER In PRINT2, line 162 of test.f -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Summary|r143152 breaks output |[4.4 Regression] r143152 |routines in xplor-nih |breaks output routines in ||xplor-nih http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug target/38900] New: ICE: unable to find a register to spill
gcc -S -O1 -foptimize-sibling-calls bug.c
bug.c: In function 'f':
bug.c:9: error: unable to find a register to spill in class 'CREG'
bug.c:9: error: this is the insn:
(call_insn/j 11 9 12 2 bug.c:8 (call (mem:QI (reg/f:SI 3 bx [59]) [0 S1 A8])
(const_int 0 [0x0])) 468 {*sibcall_1} (expr_list:REG_DEAD (reg/f:SI 3
bx [59])
(expr_list:REG_DEAD (reg:SI 2 cx)
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 2 cx))
(nil)))
bug.c:9: internal compiler error: in spill_failure, at reload1.c:2093
--
Summary: ICE: unable to find a register to spill
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot g dot gorbachev at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i386-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-01-17
23:19 ---
bug.c:
void __attribute__((dllimport,fastcall)) h(int);
void f(int i)
{
static void (__attribute__((fastcall)) *g)(int) = h;
g(i);
g(i);
}
--
d dot g dot gorbachev at gmail dot com changed:
What|Removed |Added
Known to fail||4.3.2 4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug target/38900] ICE: unable to find a register to spill
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-01-17
23:20 ---
ok.c:
void __attribute__((dllimport,fastcall)) h(int);
void f(int i)
{
static void (__attribute__((fastcall)) *g)(int);
g = h;
g(i);
g(i);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38900
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2009-01-17 23:23 --- I've had no luck triggering this problem on targets other than i686-apple-darwin9. On that target -m64, suppresses the problem. As to the issue with ANER(J) being undefined on line 162, this can be fixed with... --- testcase2.f.org 2009-01-17 18:21:01.0 -0500 +++ testcase2.f 2009-01-17 18:22:00.0 -0500 @@ -17,6 +17,7 @@ RENRL(SSSD)=5.03071296871847578E-003 DO I=1,NENERT + ANER(I)='' QENER(I)=.false. END DO but has no impact on the bug observed under Intel darwin9 either way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #25 from dominiq at lps dot ens dot fr 2009-01-17 23:28 --- In the reduced case in comment #19 ANER is initialized and the output is still wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug middle-end/38868] [4.4 Regression] r143152 breaks output routines in xplor-nih
--- Comment #26 from dominiq at lps dot ens dot fr 2009-01-17 23:48 --- Further reduced test case: PROGRAM testcase IMPLICIT NONE INTEGER NENERT PARAMETER (NENERT=62) CHARACTER*4 ANER(NENERT) CHARACTER*80 LINE INTEGER PUNIT PUNIT = 6 aner = '' ANER(5)='BOND' ANER(6)='ANGL' LINE=' ' LINE(2:2)='|' LINE(80:80)='|' write (10,*) ', line, ' WRITE(PUNIT,'(A80)') LINE END [ibook-dhum] f90/bug% cat fort.10 ' | ' If I comment one of the two lines: ANER(5)='BOND' ANER(6)='ANGL' the bug disappears. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38868
[Bug inline-asm/38901] New: Inline assembly swallows mmx register on duplicate input under optimization
I've tested this under gcc 4.2.1 (DJGPP) and gcc 3.4.4 (cygwin) (see below for
gcc -v outputs). The test program is simple: generate two random complex
numbers, multiply them using the FPU, and do it again using 3dnow inline
assembly. I can get it to work with different code, but this version
illustrates an apparent bug in the optimization scheme.
Compiling as gcc -m3dnow cdtest.c produces the correct output:
x = 0.122114 + 0.096877iy = 0.372626 + 0.199503i
z = 0.026175 + 0.060461iz = 0.026175 + 0.060461i
Compiling as above with an additional -O(1,2, or 3) produces:
x = 0.122114 + 0.096877iy = 0.372626 + 0.199503i
z = 0.026175 + 0.060461iz = 0.011737 + 0.018312i
with the inline-assembly (second) value wrong.
--- cdtest.c
#include stdio.h
#include stdlib.h
#define fRand()(((float)rand())/RAND_MAX)
typedef struct fComp { float x,y; } fComp __attribute__ ((aligned (8)));
#define fCIni(d,X,Y) do { (d)-x = (X); (d)-y = (Y); } while(0)
int main(int nArgs, char *Args[], char *Env[]) {
fComp x,y,z; /* x,y random complex numbers, z = x*y */
fCIni(x,fRand(),fRand()); fCIni(y,fRand(),fRand());
fCIni(z,x.x*y.x - x.y*y.y, x.x*y.y + x.y*y.x);
printf(x = %f + %fi\ty = %f + %fi\nz = %f + %fi\t,x.x,x.y,y.x,y.y,z.x,z.y);
/* Recalculate the same product using 3dNow */
asm(pswapd %[X],%[X]\n\t/* X = r1 | i1 */
pfmul%[Y],%[Z]\n\t/* Z = i1i2 | r1r2 */
pfmul%[X],%[Y]\n\t/* Y = r1i2 | r2i1 */
pfpnacc %[Y],%[Z]\n\t/* Z = r1i2+r2i1 | r1r2-i1i2 */
movq %[Z],(%[Zp]) /* Store result at *Zp */
:
: [X]y(x), [Y]y(y), [Z]y(x), [Zp]r(z)
: memory );
asm(femms);
printf(z = %f + %fi\n, z.x, z.y);
return 0;
}
Inspecting the .s output, the unoptimized compilation assigns
[X] = %mm0, [Y] = %mm1, [Z] = %mm2,
while the optimized version fails to work because of the duplication
[X] = %mm0, [Y] = %mm1, [Z] = %mm0.
This seems to happen because both X and Z are initialized to the same value;
doing [Z]y(0) or something similar (and movq %[X],%[Z] manually) resolves the
problem, but with an unfortunate side-effect that %[Z] is actually set twice,
wasting instructions. It would be saner for the compiler to just automatically
re-copy the first instance to the second one, rather than erroneously
concluding that I don't really need the extra register just because it has the
same input value.
Using built-in specs.
Target: djgpp
Configured with: /v203/gcc-4.21/configure djgpp --prefix=/dev/env/DJDIR
--disabl
e-nls --disable-werror --enable-languages=c,c++,fortran,objc,obj-c++,ada
Thread model: single
gcc version 4.2.1
-
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /usr/build/package/orig/test.respin/gcc-3.4.4-3/configure
--ver
bose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
--libe
xecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-langu
ages=c,ada,c++,d,f77,pascal,java,objc --enable-nls --without-included-gettext
--
enable-version-specific-runtime-libs --without-x --enable-libgcj
--disable-java-
awt --with-system-zlib --enable-interpreter --disable-libgcj-debug
--enable-thre
ads=posix --enable-java-gc=boehm --disable-win32-registry
--enable-sjlj-exceptio
ns --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
A similar problem occurs if I replace the first inline asm with:
asm(movq %[X],%[Z]\n\t
pswapd %[X],%[X]\n\t/* X = r1 | i1 */
pfmul%[Y],%[Z]\n\t/* Z = i1i2 | r1r2 */
pfmul%[X],%[Y]\n\t/* Y = r1i2 | r2i1 */
pfpnacc %[Y],%[Z]\n\t/* Z = r1i2+r2i1 | r1r2-i1i2 */
: [Z]=y(z)
: [X]y(x), [Y]y(y) );
both [Z] and [X] again being mapped to the same register. (This code also even
more wasteful, but that's not the point.)
BTW: Is there any way to tell gcc that I need a random register different from
the rest, but I don't care about its initial value--something like [foo]y()
in inputs or [bar]y in clobber? I know if I put, say mm0 in the clobber
list, then gcc seems to know to pick different ones for [X],[Y],[Z], but
letting gcc pick one would be a convenient feature.
--
Summary: Inline assembly swallows mmx register on duplicate input
under optimization
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stanlio at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38901
[Bug bootstrap/38862] Bootstrap failure on HEAD with static linking vs. graphite
--- Comment #3 from dave dot korn dot cygwin at gmail dot com 2009-01-18 00:17 --- This is now fixed. Will file a separate PR later for -lstdc++ problems. -- dave dot korn dot cygwin at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38862
[Bug target/38902] New: gcc.dg/pr38616.c fails
[...@gnu-17 gcc]$ /export/gnu/import/svn/gcc-test/bld/gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/gcc/ /export/gnu/import/svn/gcc-test/src-4.3/gcc/testsuite/gcc.dg/pr38616.c -S -fstack-protector -fno-show-column -lm -O2 -Wall -w [...@gnu-17 gcc]$ ./a.out [...@gnu-17 gcc]$ echo $? 255 [...@gnu-17 gcc]$ /export/gnu/import/svn/gcc-test/bld/gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../src-4.3/configure --enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld Thread model: posix gcc version 4.3.3 20090117 (prerelease) [gcc-4_3-branch revision 143471] (GCC) [...@gnu-17 gcc]$ -- Summary: gcc.dg/pr38616.c fails Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38902
[Bug inline-asm/38901] Inline assembly swallows mmx register on duplicate input under optimization
--- Comment #1 from schwab at suse dot de 2009-01-18 00:25 --- The asm statement modifies an input-only operand. If an operand is modified it must be listed as output operand, possibly marked as early-clobber if it is written before all input operands are consumed. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38901
[Bug fortran/38823] Diagnose and treat (-2.0)**2.0 properly
-- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-18 00:25:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38823
[Bug bootstrap/38903] New: Bootstrap failure on Cygwin vs. libiberty.
[refs: http://gcc.gnu.org/ml/gcc/2009-01/threads.html#00060 http://gcc.gnu.org/ml/gcc/2009-01/threads.html#00216 ] Bootstrap on cygwin is currently failing during stage 3 with: /home/andy/live-gcc/my_gcc/./gcc/xgcc -B/home/andy/live-gcc/my_gcc/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2-I. -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../../gcc/libiberty/strsignal.c -o pic/strsignal.o; \ else true; fi /home/andy/live-gcc/my_gcc/./gcc/xgcc -B/home/andy/live-gcc/my_gcc/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2-I. -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../../gcc/libiberty/strsignal.c -o strsignal.o ../../../gcc/libiberty/strsignal.c:408: error: conflicting types for 'strsignal' /usr/include/string.h:78: note: previous declaration of 'strsignal' was here make[2]: *** [strsignal.o] Error 1 make[2]: Leaving directory `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty' make[1]: *** [all-target-libiberty] Error 2 make[1]: Leaving directory `/home/andy/live-gcc/my_gcc' make: *** [all] Error 2 This happens because libiberty configure has a hard-coded hack that kicks in when building libiberty as a target library, which causes strsignal (and a couple of others) to be removed from the list of functions for configure to check against the system libraries, causing the libiberty versions to be built when they aren't needed. (They used to be required; formerly, Cygwin pulled in the object files from libiberty when linking the DLL, but this was fixed some time ago and the hack has been obsolete since then). I am testing a patch to remove the hack. -- Summary: Bootstrap failure on Cygwin vs. libiberty. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot korn dot cygwin at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903
[Bug bootstrap/38903] Bootstrap failure on Cygwin vs. libiberty.
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-18 00:31 --- Created an attachment (id=17131) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17131action=view) Remove troublesome clause from libiberty configure Now testing vs. both src/ and gcc/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903
[Bug target/38904] New: Shared libgcc DLL violates Cygwin platform conventions.
The shared libgcc DLL currently built for cygwin is named libgcc_s_1.dll, and it comes with an import library named libgcc_s.a. These both violate the Cygwin platform naming conventions. All DLLs are prefixed with 'cyg' rather than 'lib' on the Cygwin target, and the corresponding import library should be prefixed with 'lib' and use a '.dll.a' extension. Although this is a problem in a new feature, rather than a regression, I will appeal for special consideration (as a target-specific change) to apply a patch (that I will post shortly) for this issue during stage 4, so that it can be in the released GCC 4.4 series, avoiding an ABI break between 4.4 and 4.5 on the Cygwin platform. -- Summary: Shared libgcc DLL violates Cygwin platform conventions. Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot korn dot cygwin at gmail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38904
[Bug target/38904] Shared libgcc DLL violates Cygwin platform conventions.
--- Comment #1 from dave dot korn dot cygwin at gmail dot com 2009-01-18 00:41 --- Oh, I forgot to mention a further non-standardness about the DLL's name: on the Cygwin platform, the shared library version number should be separated from the name by a hyphen, not an underscore. So for Cygwin, the DLL should be named cyggcc_s-1.dll and the import library libgcc_s.dll.a. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38904
[Bug fortran/38122] file already opened in another unit error when opening /dev/null or /dev/tty twice
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-01-18 01:33 --- Closing, the code is invalid Fortran -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38122
[Bug target/38902] __builtin_strcpy doesn't work with -fstack-protector
--- Comment #1 from hjl dot tools at gmail dot com 2009-01-18 01:41 ---
bash-3.2$ cat /tmp/x.c
extern void abort ();
int foo (const char *, const char *);
int main (void)
{
char buffer[1024]=;
__builtin_strcpy (buffer, 1234567890abcdefghijklmno);
if (foo (buffer, 1234567890abcdefghijklmno))
abort ();
}
bash-3.2$ cat /tmp/y.c
int
foo (const char *x , const char * y)
{
return __builtin_strcmp (x, y);
}
bash-3.2$ ./xgcc -B./ -O2 -m32 -c /tmp/y.c
bash-3.2$ ./xgcc -B./ -O2 -m32 -O2 -fstack-protector /tmp/x.c y.o
bash-3.2$ ./a.out
Aborted
bash-3.2$
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Summary|gcc.dg/pr38616.c fails |__builtin_strcpy doesn't
||work with -fstack-protector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38902
[Bug target/38902] __builtin_strcpy doesn't work with -fstack-protector
--- Comment #2 from hjl dot tools at gmail dot com 2009-01-18 01:43 ---
bash-3.2$ cat /tmp/x.c
extern void abort ();
int foo (const char *, const char *);
int main (void)
{
char buffer[1024]=;
__builtin_strcpy (buffer, 1234567890abcdefghijklmno);
if (foo (buffer, 1234567890abcdefghijklmno))
abort ();
}
bash-3.2$ cat /tmp/y.c
int
foo (const char *x , const char * y)
{
return __builtin_strcmp (x, y);
}
bash-3.2$ ./xgcc -B./ -O2 -m32 -c /tmp/y.c
bash-3.2$ ./xgcc -B./ -O2 -m32 -O2 -fstack-protector /tmp/x.c -c
bash-3.2$ ./xgcc -B./ -m32 x.o y.o
bash-3.2$ ./a.out
Aborted
bash-3.2$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38902
[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues
--- Comment #7 from bangerth at dealii dot org 2009-01-18 03:58 --- (In reply to comment #6) Maybe this issue isn't sufficiently clarified in the audit. Unless I'm badly mistaken (Jon, Chris will correct me), this is not a bug for a C++03 + TR1 bind (indeed the testcases provided by Doug are rather clear about that). Only in C++0x the specs say it must work. Of course implementations can also fix it for C++03 + TR1, but this is not in general the way we are managing these issues, we prefer leaving the TR1 version alone. And it should work if you do -std=c++0x, which I believe (from the title of the PR) is what the original intent was. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35569
[Bug bootstrap/37660] [4.4 Regression] Error Building libssp, recent update
--- Comment #7 from dave dot korn dot cygwin at gmail dot com 2009-01-18 05:57 --- Created an attachment (id=17132) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17132action=view) Move _ctors* and _chkstk* to import lib Danny, this is the approach that I think I'd like to take for Cygwin; what do you think about doing it this way? I'm currently testing a full bootstrap using this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37660
