[Bug classpath/25389] File(new URI(file:./)) - java.lang.NullPointerException
--- Comment #7 from caolanm at redhat dot com 2005-12-14 08:35 --- Throwing IllegalArgumentException should be fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25389
[Bug libstdc++/24660] versioning weak symbols in libstdc++
--- Comment #20 from bkoz at gcc dot gnu dot org 2005-12-14 09:12 --- This arrangement of debug mode does indeed seem to fix the longstanding swap issue. ie, -D_GLIBCXX_DEBUG runs are == normal runs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
[Bug fortran/25403] gfortran run-time error with multiple tabs in format continuation
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-12-14 09:26 --- Confirmed (and it's a regression wrt g77). The tree dump has: dt_parm.0.format = (i4,i4, \ti4,i4); so I think it's up to the front-end to remove that. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19292 nThis|| Status|UNCONFIRMED |NEW Component|libfortran |fortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-14 09:26:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25403
[Bug libstdc++/24660] versioning weak symbols in libstdc++
--- Comment #21 from pcarlini at suse dot de 2005-12-14 09:48 --- (In reply to comment #20) This arrangement of debug mode does indeed seem to fix the longstanding swap issue. ie, -D_GLIBCXX_DEBUG runs are == normal runs. Yeah! (about the rest of the work too ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
[Bug target/25254] ICE with -mcmodel=medium -mlarge-data-threshold=1
--- Comment #2 from jakub at gcc dot gnu dot org 2005-12-14 11:00 --- Subject: Bug 25254 Author: jakub Date: Wed Dec 14 11:00:50 2005 New Revision: 108506 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108506 Log: PR target/25254 PR target/24188 * config/i386/i386.c (x86_64_elf_select_section): If DECL is not DECL_P, call get_section rather than get_named_section. Supply section flags to it. * gcc.target/i386/pr25254.c: New test. * gfortran.dg/PR24188.f: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr25254.c trunk/gcc/testsuite/gfortran.dg/PR24188.f Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25254
[Bug target/24188] [4.1/4.2 Regression] WRITE(6,*) causes an ICE with -mcmodel=medium
--- Comment #7 from jakub at gcc dot gnu dot org 2005-12-14 11:00 --- Subject: Bug 24188 Author: jakub Date: Wed Dec 14 11:00:50 2005 New Revision: 108506 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108506 Log: PR target/25254 PR target/24188 * config/i386/i386.c (x86_64_elf_select_section): If DECL is not DECL_P, call get_section rather than get_named_section. Supply section flags to it. * gcc.target/i386/pr25254.c: New test. * gfortran.dg/PR24188.f: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr25254.c trunk/gcc/testsuite/gfortran.dg/PR24188.f Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24188
[Bug target/24188] [4.1/4.2 Regression] WRITE(6,*) causes an ICE with -mcmodel=medium
--- Comment #8 from jakub at gcc dot gnu dot org 2005-12-14 11:01 --- Subject: Bug 24188 Author: jakub Date: Wed Dec 14 11:01:15 2005 New Revision: 108507 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108507 Log: PR target/25254 PR target/24188 * config/i386/i386.c (x86_64_elf_select_section): If DECL is not DECL_P, call named_section_flags rather than named_section. Supply section flags to it. * gcc.target/i386/pr25254.c: New test. * gfortran.dg/PR24188.f: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr25254.c branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/PR24188.f Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24188
[Bug target/25254] ICE with -mcmodel=medium -mlarge-data-threshold=1
--- Comment #3 from jakub at gcc dot gnu dot org 2005-12-14 11:01 --- Subject: Bug 25254 Author: jakub Date: Wed Dec 14 11:01:15 2005 New Revision: 108507 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108507 Log: PR target/25254 PR target/24188 * config/i386/i386.c (x86_64_elf_select_section): If DECL is not DECL_P, call named_section_flags rather than named_section. Supply section flags to it. * gcc.target/i386/pr25254.c: New test. * gfortran.dg/PR24188.f: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr25254.c branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/PR24188.f Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25254
[Bug java/24572] [4.0 regression] ICE in gimplify_expr, at gimplify.c:3983
--- Comment #6 from debian-gcc at lists dot debian dot org 2005-12-14 11:04 --- works for me Matthias -- debian-gcc at lists dot debian dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24572
[Bug target/25406] [4.2 Regression] gcc.dg/20030625-1.c, gcc.dg/20050620-1.c, gcc.dg/940510-1.c, gcc.dg/c99-flex-array-1.c, gcc.dg/pr14475.c, and gcc.dg/noncompile/incomplete-1.c fail on powerpc-darwi
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|NEW |ASSIGNED Last reconfirmed|2005-12-14 05:04:32 |2005-12-14 11:07:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25406
[Bug libstdc++/25409] New: STL mt_allocator crash in global construcutor
[ I've raised this against 4.2 as I've verified that it's still an issue for
that branch, but it's also valid for 4.0.2 4.1 ]
I have a crash in some code that dlopen()s a library (with a static deque
constructor), which happens to be dependant upon another couple of libraries,
one of which uses libpthread.
The crash occurs in the static library construction mt_allocator.h, within
_M_adjust_freelist:
void
_M_adjust_freelist(const _Bin_record __bin, _Block_record* __block,
size_t __thread_id)
{
if (__gthread_active_p())
{
__block-_M_thread_id = __thread_id;
HERE - --__bin._M_free[__thread_id];
++__bin._M_used[__thread_id];
}
}
At the point at which it happens, _M_free is NULL.
I've done some investigation, and the mal-initialisation is caused by
__gthread_active_p() sometimes returning '1' [e.g.,in mt_allocator.h's
__pooltrue::_M_initialize_once()] and '0':
__common_pool_base_PoolTp,true::_S_initialize_once() calls this
_M_initialise_once() [if I'm right], which runs down to mt_allocator.cc's
__pooltrue::_M_initialize(). At this point, __gthread_active_p() returns
/0/, (even though it's only just previously returned 1) and the routine doesn't
seem to quite know how to handle it, leaving the bin(s) uninitialised.
I found this problem using Fedora Core's 4.0.1/4.0.2 but have replicated it
with vanilla builds with mt_allocator enabled. This *may* be a dup. of PR
24071; I'm not sure it's exactly the same, but I feel we may be circling round
the same issue.
Redhat's https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=165728 may also
be relevant.
I'm fairly confident that the GLIBCXX_FORCE_NEW env. var. makes things work
properly. I've also found that, instead, the semi-documented '-pthread'
compilation [from the above PR] option makes things work OK too
[semi-documented as it's listed as being PPC/Sparc/HP-UX specific, whereas this
is a basic 32-bit i686 system].
The last thing I tried which *also* made things work on its own (ref,. the
RedHat report) was to link my test util. (the one that does the dlopen()) with
'-lpthread'.
--
Summary: STL mt_allocator crash in global construcutor
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at fnxweb dot com
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25409
[Bug libstdc++/25409] STL mt_allocator crash in global construcutor
--- Comment #1 from neil at fnxweb dot com 2005-12-14 11:44 --- Created an attachment (id=10484) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10484action=view) Example of the crash Do 'make' in top level of build tree. 'make symbolcheck' afterwards just demos the crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25409
[Bug target/24071] __gthread_active_p vs __gthread_once
--- Comment #10 from neil at fnxweb dot com 2005-12-14 11:47 --- For ref., I've just raised PR 25409 which may possible be a dup. of this problem. It's nothing to do with Solaris, though, so I didn't just add the details here. -- neil at fnxweb dot com changed: What|Removed |Added CC||neil at fnxweb dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24071
[Bug tree-optimization/25211] [4.1/4.2 Regression] verify_ssa ICE for mesa with -Os -ftree-loop-linear
--- Comment #4 from irar at il dot ibm dot com 2005-12-14 13:11 --- I think the reason why this ICE occurs with my patch (http://gcc.gnu.org/viewcvs?view=revrev=102356) is that my patch enables data-refs analysis for INDIRECT_REFs. Similar ICE in PR 20256 happens also before my patch since the data-refs there are ARRAY_REFs, and ARRAY_REFs were already supported before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25211
[Bug c++/25410] New: poor ostringstream output
The following code compiles, but the result of the first line of main is poor
(it prints the address of the string):
#include iostream
#include sstream
using namespace std;
templatetypename A, typename B
basic_ostreamA,B tic(basic_ostreamA,B o)
{
return o;
}
templatetypename A, typename B
basic_ostreamA,B tac(basic_ostreamA,B o)
{
if( ostringstream* oo = dynamic_castostringstream*(o) ) {
cout oo-str() endl;
}
return o;
}
int main()
{
ostringstream() tac alone does not give a nice result tac;
ostringstream() tic tic+tac together work tac;
}
#if 0
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.2 (Debian 4.0.2-2)
#endif
--
Summary: poor ostringstream output
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aburger at cea dot fr
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25410
[Bug target/25254] ICE with -mcmodel=medium -mlarge-data-threshold=1
--- Comment #4 from jakub at gcc dot gnu dot org 2005-12-14 13:36 --- Fixed in CVS. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25254
[Bug target/24188] [4.1/4.2 Regression] WRITE(6,*) causes an ICE with -mcmodel=medium
--- Comment #9 from jakub at gcc dot gnu dot org 2005-12-14 13:36 --- Fixed in CVS. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24188
[Bug libfortran/24991] [4.1/4.2 Regression] gfortran build fails with - error:gthr-default.h: No such file or directory
--- Comment #44 from jakub at gcc dot gnu dot org 2005-12-14 13:37 --- Fixed in SVN. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24991
[Bug c++/25411] New: Optimization with -O2 -finline-functions gives wrong code
A test for functor expressions in the Vigra library testsuite gives erroneous
results if compiled with -O2 -finline-functions. No problem occurs if either
option is dropped. The error occurs as well with g++ 4.0.0, but not with
3.4.3. The error occurs under Tru64 V5.1B on an AlphaServer, but not under
Linux on i686 (g++ 4.0.0).
The program in question is
#include iostream
#include vigra/functorexpression.hxx
#include vigra/rgbvalue.hxx
using namespace vigra::functor;
int main()
{
vigra::RGBValueint data[] = { vigra::RGBValueint(0),
vigra::RGBValueint(1) };
vigra::RGBValueint sum(0);
int count = 0;
for ( int j = 0 ; j 2 ; ++j )
std::cerr data[ j ]: data[j] std::endl;
std::for_each(data, data+2,
(
Var(count) += Param(1) ,
Var(sum) += Arg1()
));
std::cerr count: count
\nsum: sum
std::endl;
return 0;
}
The expected output is
data[0]: (0, 0, 0)
data[1]: (1, 1, 1)
count: 2
sum: (1, 1, 1)
If compiled with -O2 -finline-functions, the following is produced:
data[0]: (0, 0, 0)
data[1]: (1, 1, 1)
count: 0
sum: (3, 1, 1)
If the two items in the comma-expression that forms the third argument of
std::for_each() are exchanged, correct code is produced with the
-finline-functions option in place.
I will be happy to supply header files or the preprocessor output on request.
Hans E Plesser
--
Summary: Optimization with -O2 -finline-functions gives wrong
code
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hans dot ekkehard dot plesser at umb dot no
GCC build triplet: alphaev7-dec-osf5.1b
GCC host triplet: alphaev7-dec-osf5.1b
GCC target triplet: alphaev7-dec-osf5.1b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25411
[Bug bootstrap/25397] [4.2 Regression] Bootstrap failed
--- Comment #11 from amylaar at gcc dot gnu dot org 2005-12-14 13:41 --- Subject: Bug 25397 Author: amylaar Date: Wed Dec 14 13:41:22 2005 New Revision: 108508 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108508 Log: 2005-12-14 Jorn Rennecke [EMAIL PROTECTED] PR bootstrap/25397: * struct-equiv.c (struct_equiv_init): Fix off-by-one error in clearing of STACK_REGS bits. * struct-euiv.c (rtx_equiv_p): Remove SUBREG case. Modified: trunk/gcc/ChangeLog trunk/gcc/struct-equiv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25397
[Bug c++/25411] Optimization with -O2 -finline-functions gives wrong code
--- Comment #1 from hans dot ekkehard dot plesser at umb dot no 2005-12-14 13:45 --- Created an attachment (id=10485) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10485action=view) Preprocessed reproducer for optimize bug This is the complete preprocessed source code for bug 25411. g++ -O2 -finline-functions Bug25411.ii -o Bug25411 yields an executable that causes the erroneous output reported under Tru64. Hans E Plesser -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25411
[Bug c++/25410] poor ostringstream output
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 15:11 --- *** This bug has been marked as a duplicate of 9925 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25410
[Bug c++/9925] ostrstream (buf, size) ... does not work properly
--- Comment #17 from pinskia at gcc dot gnu dot org 2005-12-14 15:11 --- *** Bug 25410 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aburger at cea dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
[Bug c++/25407] [3.4 Regression] ICE when assigning value of variable passed to template as reference
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 15:15 --- Confirmed a regression from 3.0.4. Only a 3.4.x regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||3.3.3 3.2.3 3.4.0 Known to work||3.0.4 4.0.0 4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-12-14 15:15:12 date|| Summary|ICE when assigning value of |[3.4 Regression] ICE when |variable passed to template |assigning value of variable |as reference|passed to template as ||reference Target Milestone|--- |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25407
[Bug fortran/25412] New: gfortran 4.0.2 seg fault
Segmentation fault: #gfortran4.0 -c wave.f90 wave.f90:80: internal compiler error: Segmentation fault I believe this worked under gfortran 4.0. Environment: System: Linux FUME.WPI.EDU 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:00:54 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux Architecture: x86_64 host: x86_64-unknown-linux-gnu build: x86_64-unknown-linux-gnu target: x86_64-unknown-linux-gnu configured with: ../configure --prefix=/usr/local --exec-prefix=/usr/local --program-suffix=4.0 --without-java How-To-Repeat: Just attempt to compile it. Here's the processed source code: -snip !#define debug ! to be costumized by user (usually done in the makefile)--- !#define vector compile for vector machine !#define essluse ESSL instead of LAPACK !#define single_BLAS use single prec. BLAS !#define wNGXhalfgamma only wavefunctions (X-red) !#define wNGZhalfgamma only wavefunctions (Z-red) !#define 1 charge stored in REAL array (X-red) !#define NGZhalf charge stored in REAL array (Z-red) !#define NOZTRMM replace ZTRMM by ZGEMM !#define REAL_to_DBLEconvert REAL() to DBLE() !#define MPI compile for parallel machine with MPI !- end of user part ! ! charge density: half grid mode X direction ! ! ! charge density real ! ! ! wavefunctions: full grid mode ! ! ! wavefunctions complex ! ! ! common definitions ! ! ! RCS: $Id: wave.F,v 1.6 2002/08/14 13:59:43 kresse Exp $ ! ! this module contains the routines required to setup ! the distribution of wavefunctions over and all basic routines ! handling wavedes etc. ! !*** MODULE WAVE USE prec USE mpimy INCLUDE wave.inc CONTAINS !=== ! initialize and descriptor for the wavefunctions ! mainly allocation !=== SUBROUTINE ALLOCWDES(WDES,LEXTEND) USE prec IMPLICIT NONE INTEGER NK TYPE (wavedes) WDES INTEGER NRPLWV,NKPTS,NCOL LOGICAL LEXTEND NRPLWV=WDES%NGDIM NKPTS =WDES%NKPTS NCOL =WDES%NCOL ALLOCATE( WDES%NPLWKP(NKPTS),WDES%NGVECTOR(NKPTS),WDES%NPLWKP_TOT(NKPTS),WDES%NINDPW(NRPLWV,NKPTS)) IF (NCOL0) THEN ALLOCATE(WDES%PL_INDEX(NCOL,NKPTS),WDES%PL_COL(NCOL,NKPTS)) ELSE NULLIFY(WDES%PL_INDEX); NULLIFY(WDES%PL_COL) ENDIF IF (LEXTEND) THEN !-MM- changes to accommodate spin spirals ! original statement ! ALLOCATE( WDES%DATAKE(NRPLWV,NKPTS), ! WDES%IGX(NRPLWV,NKPTS),WDES%IGY(NRPLWV,NKPTS),WDES%IGZ(NRPLWV,NKPTS)) ALLOCATE(WDES%DATAKE(NRPLWV,NKPTS,2), WDES%IGX(NRPLWV,NKPTS),WDES%IGY(NRPLWV,NKPTS),WDES%IGZ(NRPLWV,NKPTS)) !-MM- end of alteration ELSE NULLIFY(WDES%DATAKE) NULLIFY(WDES%IGX); NULLIFY(WDES%IGY); NULLIFY(WDES%IGZ) NULLIFY(WDES%PL_INDEX); NULLIFY(WDES%PL_COL) END IF END SUBROUTINE !=== ! deallocate a descriptor for the wavefunctions !=== SUBROUTINE DEALLOCWDES(WDES,LEXTEND) USE prec IMPLICIT NONE TYPE (wavedes) WDES LOGICAL LEXTEND DEALLOCATE( WDES%NPLWKP,WDES%NGVECTOR,WDES%NPLWKP_TOT,WDES%NINDPW) IF (WDES%NCOL0) THEN DEALLOCATE(WDES%PL_INDEX,WDES%PL_COL) NULLIFY(WDES%PL_INDEX); NULLIFY(WDES%PL_COL) ENDIF IF (LEXTEND) THEN DEALLOCATE( WDES%DATAKE,WDES%IGX,WDES%IGY,WDES%IGZ) NULLIFY(WDES%DATAKE) NULLIFY(WDES%IGX); NULLIFY(WDES%IGY); NULLIFY(WDES%IGZ) END IF END SUBROUTINE !=== ! initialize the projector part of the descriptor for the ! wavefunctions !=== SUBROUTINE WDES_SET_NPRO(WDES,T_INFO,P) USE prec USE mpimy USE poscar USE pseudo TYPE (wavedes) WDES TYPE (type_info) :: T_INFO TYPE (potcar) P(T_INFO%NTYP) ! local varibles INTEGER NALLOC,NPRO_TOT,NT,NI,NIS,NODE_TARGET,NPRO, LMMAXC,NIONS,LASTTYP WDES%NIONS = T_INFO%NIONS WDES%NTYP = T_INFO%NTYP WDES%NITYP =T_INFO%NITYP ALLOCATE(WDES%LMMAX(WDES%NTYP)) DO NT=1,T_INFO%NTYP WDES%LMMAX(NT)=P(NT)%LMMAX ENDDO WDES%NPRO =SUM(WDES%LMMAX*WDES%NITYP) WDES%NPRO_TOT=SUM(WDES%LMMAX*WDES%NITYP) WDES%NPROD =WDES%NPRO WDES%NPRO =WDES%NPRO *WDES%NRSPINORS WDES%NPRO_TOT=WDES%NPRO_TOT*WDES%NRSPINORS
[Bug tree-optimization/25413] New: wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE
(The same phenomenon happens in 4.2 subversion alpha.) Incorrect code is generated when using -ftree-vectorize on the SSE2 Pentium 4 target. (The same code works on the AMD64 64-bit target.) See attached source code. $ gcc -O2 -Wall -march=pentium4 -mfpmath=sse -ftree-vectorize -ftree-vectorizer-verbose=1 gcc_plantage2.c -o ./gcc_plantage2 $ ./gcc_plantage2 will segfault (the same program works perfectly without -ftree-vectorize). The segfault appears at the second movapd instruction: movapd .LC0, %xmm0 .L17: movapd %xmm0, (%eax) addl$1, %edx addl$16, %eax cmpl%edx, %ebx ja .L17 %eax is at this point equal to 4 modulo 16, which results in a segmentation fault, since movapd assumes 16-byte alignment. -- Summary: wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: David dot Monniaux at ens dot fr 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=25413
[Bug target/25413] wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE
--- Comment #1 from David dot Monniaux at ens dot fr 2005-12-14 15:26 --- Created an attachment (id=10486) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10486action=view) preprocessed C source code (assumes Linux glibc) exhibiting the code generation bug Compile this program with -O2 -march=pentium4 -ftree-vectorize on a Pentium 4 and run it. It will segfault. It works perfectly without vectorization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
[Bug fortran/25412] gfortran 4.0.2 seg fault
--- Comment #2 from root at WPI dot EDU 2005-12-14 15:35 --- Created an attachment (id=10487) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10487action=view) the file that breaks gfortran 4.0.2, for easier retrieval -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25412
[Bug target/24378] [4.1/4.2 Regression] gcc.dg/vect/pr24300.c (test for excess errors) fails
--- Comment #9 from dorit at il dot ibm dot com 2005-12-14 15:38 --- Thanks for testing the patch. I finally submitted it: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01071.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24378
[Bug c++/25411] Optimization with -O2 -finline-functions gives wrong code
--- Comment #2 from rguenth at gcc dot gnu dot org 2005-12-14 15:54 --- Cannot reproduce with gcc (GCC) 4.1.0 20050916 (experimental) on x86_64-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25411
[Bug libgcj/25414] New: must update rmic
Upstream RMIC uses the ASM library and is generally better. We should import ASM and the cp-tools RMIC into libgcj, and remove our outdated version -- Summary: must update rmic Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25414
[Bug tree-optimization/24378] [4.1/4.2 Regression] gcc.dg/vect/pr24300.c (test for excess errors) fails
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2005-12-14 16:38 --- Recategorizing and assigning to Dorit. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Component|target |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24378
[Bug rtl-optimization/24899] [4.1/4.2 Regression] loop.c miscompiles libgnomecanvas
--- Comment #21 from jakub at gcc dot gnu dot org 2005-12-14 17:06 --- Created an attachment (id=10488) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10488action=view) pr24899.c Even shorter testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
[Bug c++/21494] condensed nested namespaces
--- Comment #5 from bkoz at gcc dot gnu dot org 2005-12-14 17:16 ---
I'm encouraged by this work!!! Great news.
The reason this would be useful is that then it would be possible to use a
single macro to represent both scope and namespace. Ie,
#define ACTIVE_SCOPE
works for
namespace ACTIVE_SCOPE
{
}
and explicit qualifications like
ACTIVE_SCOPE::obj;
Anyway.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21494
[Bug fortran/25403] gfortran run-time error with multiple tabs in format continuation
--- Comment #3 from kargl at gcc dot gnu dot org 2005-12-14 17:29 --- Technically, gfortran can do whatever it wants, because the code is nonconforming. The tab character is not a member of the Fortran character set. The code is using a tab where a member of the Fortran character set is expected. This is just one more example of PR 18537, for which I submitted a patch on 05 Mar 05. Unfortunately, the dialogue about that patch never resolved how a tab should be handled. I will revisit that patch with the following plan: 1) gfortran will issue an error during compiliation if a tab is found in the input. The only exceptions that I am currently contemplating are tabs in comments and character constants. 2) I'll probably introduce a -fexpand-stupid-tabs or similar pejorative named option for those user who fail to read Chapter 3 of the Fortran 95 standard. The option will simply replace the tab with a space (which happens to be a member of the Fortran character set). 3) Document that tabs are evil in gfortran.texi. rant Finally, I don't care if this isn't backwards compatible with g77. g77 is a cesspool of nonstandard features. The introduction of this cesspool into gfortran is severely reducing the quality of gfortran's code and affect its maintainability. /rant -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Keywords||accepts-invalid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25403
[Bug testsuite/19278] failure in gcc.dg/sibcall-6.c with -fpic/-fPIC on i686-pc-linux-gnu
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-12-14 17:34 --- Fixed on 4.x. Awaiting testsuite infrastructure before backporting to 3.4. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Known to fail|3.4.5 4.0.3 4.1.0 4.2.0 |3.4.5 Known to work||4.0.3 4.1.0 4.2.0 Last reconfirmed|2005-11-03 17:10:31 |2005-12-14 17:34:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19278
[Bug c/25415] New: gcc 4.0.2 fails to compile gmp 4.1.1
This looks to be the same as reported in bug 15095.
I have followed the suggested workaround of adding REGPARM (1) to the files
that would fail to compile, and that parameter is already in those files.
I am running Fedora Core 4 on a Dell SC1425. Kernel is 2.6.14-1.1637_FC4smp.
The package I am attempting to install is the JUNOScript API. It has an
automated build package that is attempting to install gmp 4.1.1. This is the
only module that is failing out of the 48 loaded. The log from the failure is
below.
[EMAIL PROTECTED] output]# cat gmp-4.1.1.log
Installing gmp on Linux
=
Invoking: tar -C tmp -zxf
/var/www/html/JUNOScript/junoscript-perl-7.1R3.3/prereqs/gmp-4.1.1.tar.gz
=
=
Invoking: cd tmp/gmp-4.1.1 ./configure
=
checking build system type... pentium4-pc-linux-gnu
checking host system type... pentium4-pc-linux-gnu
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking compiler gcc -g -O2 -fomit-frame-pointer ... yes
checking compiler gcc -g -O2 -fomit-frame-pointer -mcpu=pentium4... yes
checking compiler gcc -g -O2 -fomit-frame-pointer -mcpu=pentium4
-march=pentium4... yes
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix...
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
using ABI=standard
CC=gcc
CFLAGS=-g -O2 -fomit-frame-pointer -mcpu=pentium4 -march=pentium4
CPPFLAGS=
MPN_PATH= x86/pentium4/sse2 x86/pentium4/mmx x86/pentium4 x86 generic
checking for gcc option to accept ANSI C... none needed
checking for function prototypes... yes
checking for ANSI C header files... yes
checking for string.h... yes
checking for ar... ar
checking for BSD-compatible nm... /usr/bin/nm -B
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking whether ln -s works... yes
checking how to recognise dependant libraries... file_magic ELF [0-9][0-9]*-bit
[LM]SB (shared object|dynamic lib )
checking for dlfcn.h... yes
checking the maximum length of command line arguments... 49153
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ranlib... ranlib
checking for strip... strip
checking for file... /usr/bin/file
checking if gcc static flag works... no
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... no
checking if we can lock with hard links... yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
checking if the assembler knows about MMX instructions... yes
checking if the assembler knows about SSE2 instructions... yes
checking for ANSI C header files... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking for fcntl.h... yes
checking for locale.h... yes
checking for sys/mman.h... yes
checking for sys/param.h... yes
checking for sys/processor.h... no
checking for sys/resource.h... yes
checking for sys/sysctl.h... yes
checking for sys/syssgi.h... no
checking for sys/systemcfg.h... no
checking for sys/time.h... yes
checking for sys/times.h... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... (cached) yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether fgetc is declared... yes
checking whether fscanf is declared... yes
checking whether optarg is declared... yes
checking whether ungetc is declared... yes
checking whether vfprintf is declared... yes
checking return type of signal handlers...
[Bug target/25415] gcc 4.0.2 fails to compile gmp 4.1.1
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 17:44 --- This is invalid code and this is the same as reported PR 15095. *** This bug has been marked as a duplicate of 15095 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target GCC target triplet||i686-pc-linux-gnu Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25415
[Bug target/15095] [3.4/4.0 Regression] gcc-3.4.0 fails to compile gmp-4.1.2
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-14 17:44 --- *** Bug 25415 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tachapman at ucdavis dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15095
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Comment #16 from ppluzhnikov at charter dot net 2005-12-14 17:46 --- Same picture using gcc-4.1-20051209 for i686-pc-linux-gnu: 7 bogus violations on original test, 1 on reduced test. Here are other version results: original reduced gcc-4.1-20051209 i686-pc-linux-gnu 7 1 gcc-4.2-20051210 i686-pc-linux-gnu 1 1 gcc-4.2-20051210 x86_64-unknown-linux-gnu0 0 gcc-4.2-20051210 x86_64-unknown-linux-gnu -m32 1 1 Encouraged by the absence of bogus warnings on x86_64 in 64-bit mode, I tried 4.2-20051210 on my real code. This resulted in 100s of bogus violations, though I have not been able to produce a reduced test case yet :-( I then tried 4.2-20051210 i686 on pure C real code, and got 100s more bogus violations. IMHO, the -fmudflap either needs to be made to work correctly on real C/C++ programs, or it should be removed altogether (bogus reports lead to a lot of wasted time, as each new user discovers the feature, and then finds out it doesn't work). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug debug/25194] [4.1/4.2 Regression] ICE in dwarf2out for mesa with -O2 -funroll-loops -g
--- Comment #6 from janis at gcc dot gnu dot org 2005-12-14 17:56 --- Compiling mesa with the options mentioned in the original description passes on mainline and 4.1 with the fix for PR 24908. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25194
[Bug target/25415] gcc 4.0.2 fails to compile gmp 4.1.1
--- Comment #2 from tachapman at ucdavis dot edu 2005-12-14 18:02 --- Subject: RE: gcc 4.0.2 fails to compile gmp 4.1.1 Can you provide some additional info other than invalid code? What code is invalid? The bug that you refer to as a duplicate does not provide any resolution or information regarding 'invalid code' either. Please advise. Todd Chapman -Original Message- From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 14, 2005 9:45 AM To: [EMAIL PROTECTED] Subject: [Bug target/25415] gcc 4.0.2 fails to compile gmp 4.1.1 --- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 17:44 --- This is invalid code and this is the same as reported PR 15095. *** This bug has been marked as a duplicate of 15095 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target GCC target triplet||i686-pc-linux-gnu Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25415 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25415
[Bug fortran/25416] New: Segmentation fault in gfc_conv_function_call
The following test case
function bug(self,strvec) result(res)
character(*) :: self
character(*), dimension(:), intent(in) :: strvec
logical(kind=kind(.true.)) :: res
res = any(index(strvec,spread(self,1,size(strvec))) /= 0)
end function
triggers this ICE
#0 0x80070008 in gfc_conv_function_call (se=0x3ffdfc0,
sym=0x8059e770, arg=0x8059d850)
at ../../gcc-4_1/gcc/fortran/trans-expr.c:1542
#1 0x80074256 in gfc_conv_intrinsic_funcall (se=0x3ffdfc0,
expr=0x8059e040)
at ../../gcc-4_1/gcc/fortran/trans-intrinsic.c:1257
#2 0x80077220 in gfc_conv_intrinsic_function (se=0x3ffdfc0,
expr=0x8059e040)
at ../../gcc-4_1/gcc/fortran/trans-intrinsic.c:3256
#3 0x80070576 in gfc_conv_function_expr (se=0x3ffdfc0,
expr=0x8059d850) at ../../gcc-4_1/gcc/fortran/trans-expr.c:1951
#4 0x800709e0 in gfc_conv_expr (se=0x3ffdfc0, expr=0x8059e040) at
../../gcc-4_1/gcc/fortran/trans-expr.c:2314
#5 0x80066e5e in gfc_add_loop_ss_code (loop=0x3ffe1d0,
ss=0x8059e470, subscript=0 '\0')
at ../../gcc-4_1/gcc/fortran/trans-array.c:1480
#6 0x80067346 in gfc_conv_loop_setup (loop=0x3ffe1d0) at
../../gcc-4_1/gcc/fortran/trans-array.c:2732
#7 0x800743a2 in gfc_conv_intrinsic_anyall (se=0x3fff290,
expr=0x80572730, op=101)
at ../../gcc-4_1/gcc/fortran/trans-intrinsic.c:1323
#8 0x800779e4 in gfc_conv_intrinsic_function (se=0x3fff290,
expr=0x8059d3a0)
at ../../gcc-4_1/gcc/fortran/trans-intrinsic.c:2991
#9 0x80070576 in gfc_conv_function_expr (se=0x3fff290,
expr=0x8059d850) at ../../gcc-4_1/gcc/fortran/trans-expr.c:1951
#10 0x800709e0 in gfc_conv_expr (se=0x3fff290, expr=0x8059d3a0) at
../../gcc-4_1/gcc/fortran/trans-expr.c:2314
#11 0x80072c86 in gfc_trans_assignment (expr1=0x8059d220,
expr2=0x8059d3a0) at ../../gcc-4_1/gcc/fortran/trans-expr.c:2751
#12 0x800730c8 in gfc_trans_assign (code=0x0) at
../../gcc-4_1/gcc/fortran/trans-expr.c:2813
#13 0x80060a68 in gfc_trans_code (code=0x8059cb50) at
../../gcc-4_1/gcc/fortran/trans.c:493
#14 0x8006def8 in gfc_generate_function_code (ns=0x805654d0) at
../../gcc-4_1/gcc/fortran/trans-decl.c:2639
#15 0x80060b60 in gfc_generate_code (ns=0x0) at
../../gcc-4_1/gcc/fortran/trans.c:659
#16 0x80042bd0 in gfc_parse_file () at
../../gcc-4_1/gcc/fortran/parse.c:2680
#17 0x8005c0d0 in gfc_be_parse_file (set_yydebug=0) at
../../gcc-4_1/gcc/fortran/f95-lang.c:286
#18 0x802648d0 in toplev_main (argc=7, argv=0x8055e6a0) at
../../gcc-4_1/gcc/toplev.c:990
#19 0x80083fcc in main (argc=0, argv=0x0) at
../../gcc-4_1/gcc/main.c:35
in the line
1542 need_interface_mapping = ((sym-ts.type == BT_CHARACTER
1543 sym-ts.cl-length-expr_type !=
EXPR_CONSTANT)
1544|| sym-attr.dimension);
because sym-ts.cl-length is NULL.
(gdb) print *sym
$1 = {name = 0x8059ba7c _gfortran_spread_char_scalar, module = 0x0,
declared_at = {nextc = 0x80578268 , lb = 0x80578240},
ts = {type = BT_CHARACTER, kind = 1, derived = 0x0, cl = 0x80572730}, attr =
{allocatable = 0, dimension = 1, external = 1,
intrinsic = 0, optional = 0, pointer = 0, save = 0, target = 0, dummy = 0,
result = 0, assign = 0, data = 0, use_assoc = 0,
in_namelist = 0, in_common = 0, in_equivalence = 0, function = 1,
subroutine = 0, generic = 0, implicit_type = 0, untyped = 0,
sequence = 0, elemental = 0, pure = 0, recursive = 0, unmaskable = 0,
masked = 0, contained = 0, noreturn = 0, entry = 0,
entry_master = 0, mixed_entry_master = 0, always_explicit = 1, referenced =
0, is_main_program = 0, access = ACCESS_UNKNOWN,
intent = INTENT_UNKNOWN, flavor = FL_PROCEDURE, if_source = IFSRC_UNKNOWN,
proc = PROC_INTRINSIC, cray_pointer = 0,
cray_pointee = 0}, generic = 0x0, component_access = ACCESS_UNKNOWN, formal
= 0x0, formal_ns = 0x0, value = 0x0,
as = 0x8059e8a0, result = 0x8059e770, components = 0x0, cp_pointer = 0x0,
common_next = 0x0, common_head = 0x0, dummy_order = 0,
namelist = 0x0, namelist_tail = 0x0, old_symbol = 0x0, tlink = 0x0, mark = 0,
new = 0, equiv_built = 0, refs = 0, ns = 0x0,
backend_decl = 0x0}
(gdb) print *sym-ts.cl
$2 = {length = 0x0, next = 0x0, backend_decl = 0x21f8460}
--
Summary: Segmentation fault in gfc_conv_function_call
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uweigand at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25416
[Bug rtl-optimization/24899] [4.1/4.2 Regression] loop.c miscompiles libgnomecanvas
--- Comment #22 from jakub at gcc dot gnu dot org 2005-12-14 18:12 --- Created an attachment (id=10489) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10489action=view) pr24899.c Even shorter one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24899
[Bug fortran/25416] Segmentation fault in gfc_conv_function_call
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 18:14 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-12-14 18:14:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25416
[Bug c++/25417] New: internal compiler error in check_initializer; hits clisp
This small testcase is extracted from clisp, and throws an ICE:
---
struct object {
int a;
int b;
};
void f (int c, int d)
{
object o = ((object){ a : c, b : d});
}
% g++ -c bla.ii
bla.ii: In function #8216;void f(int, int)#8217;:
bla.ii:8: internal compiler error: in check_initializer, at cp/decl.c:4613
Removing the explicit cast and the surrounding parentheses, i.e. to read like
so:
object o = { a : c, b : d};
makes this compile.
--
Summary: internal compiler error in check_initializer; hits clisp
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at suse dot de
GCC host triplet: ia64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25417
[Bug testsuite/25352] xfail within dg-do command has no effect
--- Comment #5 from janis at gcc dot gnu dot org 2005-12-14 18:17 --- I've got an ugly fix that reaches up a couple of levels to get the variable from the DejaGnu proc that records that the test should be xfailed. Ben Elliston, who is a DejaGnu maintainer, says that 1.4.5 will be released in a month or so and it could be fixed there as well. Having GCC depend on a fix in DejaGnu would not be popular unless there were other compelling reasons to require people to upgrade. Thoughts? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25352
[Bug middle-end/25418] New: ftrapv sometimes does not emit checking for addition
Compile the following C program for x86 (mingw, i686) using gcc -ftrapv -S -O0
filename (Note: Includes omitted for brevity; GCC will warn. Including
stdio.h or stdlib.h does not fix the bug):
int main(void)
{
int a,b;
printf(Enter two signed int values: );
scanf(%d %d,a,b);
printf(\na + b = %d, a * b = %d, a - b = %d\n,a+b,a*b,a-b);
exit(0);
}
The assembly listing produced does not include a call to __addvsi3. It does,
however, contain calls to __subvsi3 and __mulvsi3. This occurs at all
optimisation levels with GCC 4.0.2.
I also tested this with GCC 3.4.0 (RedHat Linux 9, i686). The call to __addvsi3
is correctly done at -O0 and -O1, but not at any higher optimisation levels,
where it is replaced by an explicit addl.
--
Summary: ftrapv sometimes does not emit checking for addition
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: someone42 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25418
[Bug fortran/25412] gfortran 4.0.2 seg fault
--- Comment #3 from jb at gcc dot gnu dot org 2005-12-14 18:29 --- VASP is a commercial code, you shouldn't post large portions of it here. FWIW, I have been able to compile and run vasp with trunk as of October 2005. IIRC it never worked with gfortran 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25412
[Bug c++/25417] [4.1/4.2 Regression] internal compiler error in check_initializer; hits clisp
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 18:31 --- First this uses two GNU extensions to C++. Named initializers and C99 anonymous struct variables initializers (though the first is C99 if done differently). Anyways confirmed a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.1.0 4.2.0 Known to work||4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-12-14 18:31:10 date|| Summary|internal compiler error in |[4.1/4.2 Regression] |check_initializer; hits |internal compiler error in |clisp |check_initializer; hits ||clisp Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25417
[Bug middle-end/25418] ftrapv sometimes does not emit checking for addition
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 18:32 --- *** This bug has been marked as a duplicate of 19020 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25418
[Bug middle-end/19020] libcalls are removed (-ftrapv does not work)
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-14 18:32 --- *** Bug 25418 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||someone42 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
[Bug classpath/25389] File(new URI(file:./)) - java.lang.NullPointerException
--- Comment #8 from tromey at gcc dot gnu dot org 2005-12-14 18:35 --- Subject: Bug 25389 Author: tromey Date: Wed Dec 14 18:35:37 2005 New Revision: 108527 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108527 Log: PR classpath/25389: * java/io/File.java (File): Throw IllegalArgumentException if URI is non-hierarchical. Modified: branches/gcc-4_1-branch/libjava/ChangeLog branches/gcc-4_1-branch/libjava/java/io/File.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25389
[Bug testsuite/25352] xfail within dg-do command has no effect
--- Comment #6 from ghazi at gcc dot gnu dot org 2005-12-14 18:36 --- (In reply to comment #5) Having GCC depend on a fix in DejaGnu would not be popular unless there were other compelling reasons to require people to upgrade. Thoughts? If the breakage is in dejagnu, certainly a fix should go there. However I don't feel strongly about whether to fix it in GCC additionally and separately. If forced to pick, I'd lean towards dejagnu only since I'll upgrade once the new version is out. If we don't fix it in GCC, then we should remove the documentation that says it works. Perhaps we could recommend dg-xfail-if instead? Either way we should probably continue to remove the existing dg-do xfails since we'll start getting a bunch of spurious XPASSes once people start upgrading to the new dejagnu. I'll try and handle the ones that trigger on my platforms but some I can't test to know whether simply to remove the xfail or change it to dg-xfail-if. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25352
[Bug classpath/25389] File(new URI(file:./)) - java.lang.NullPointerException
--- Comment #9 from tromey at gcc dot gnu dot org 2005-12-14 18:36 --- Subject: Bug 25389 Author: tromey Date: Wed Dec 14 18:36:55 2005 New Revision: 108528 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108528 Log: PR classpath/25389: * java/io/File.java (File): Throw IllegalArgumentException if URI is non-hierarchical. Modified: trunk/libjava/ChangeLog trunk/libjava/java/io/File.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25389
[Bug classpath/25389] File(new URI(file:./)) - java.lang.NullPointerException
--- Comment #10 from tromey at gcc dot gnu dot org 2005-12-14 18:37 --- Fix in gcc 4.1, gcc trunk, and classpath cvs head. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |0.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25389
[Bug fortran/25416] Segmentation fault in gfc_conv_function_call
--- Comment #2 from jb at gcc dot gnu dot org 2005-12-14 18:40 --- Richard Guenther made a patch to get rid of gfc_conv_function_call and replace all usage of it with build_function_call_expr: http://gcc.gnu.org/ml/fortran/2005-12/msg00235.html . If we're lucky that patch might fix this issue? -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25416
[Bug libfortran/25419] New: gfortran read does not take comma for default on one entry
When there is a read statement expecting a single entry and a single comma is entered, the read expects more input. The test program is: stuff = 1 stuff2 = 2 write(*,'(1x,a,$)')'Enter 2 somethings: ' read(5,*)stuff,stuff2 write(*,'(1x,a,$)')'Enter something: ' read(5,*)stuff call exit(0) end [ashtray] image 205 % gfortran -o inputbug inputbug.f [ashtray] image 206 % ./inputbug Enter 2 somethings: ,, Enter something: , , / [ashtray] image 207 % It does not accept a , as a default entry for a single number, although two commas work when two numbers are expected. Once it gets one comma it even refuses a / until a second return is entered. This happens on Fedora Core 4 with gcc-gfortran-4.0.2-8.fc4 and on Mac OSX 10.4 with gcc version 4.1.0 20051026 (experimental) -- Summary: gfortran read does not take comma for default on one entry Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mast at colorado dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25419
[Bug fortran/25078] EQUILALENCE requires two or more objects
--- Comment #5 from kargl at gcc dot gnu dot org 2005-12-14 18:55 --- Subject: Bug 25078 Author: kargl Date: Wed Dec 14 18:55:31 2005 New Revision: 108531 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108531 Log: 2005-12-12 Steven G. Kargl [EMAIL PROTECTED] PR fortran/25078 * match.c (gfc_match_equivalence): Count number of objects. gfortran.dg/equiv_5.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/equiv_5.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/match.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25078
[Bug fortran/25078] EQUILALENCE requires two or more objects
--- Comment #6 from kargl at gcc dot gnu dot org 2005-12-14 18:57 --- Fixed. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25078
[Bug fortran/25412] gfortran 4.0.2 seg fault
--- Comment #4 from kargl at gcc dot gnu dot org 2005-12-14 19:11 --- Changed severity to normal. This doesn't compile because wave.inc is not available and prec.mod is not present. MODULE WAVE USE prec USE mpimy INCLUDE wave.inc -- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25412
[Bug c++/9925] ostrstream (buf, size) ... does not work properly
--- Comment #18 from aburger at cea dot fr 2005-12-14 19:16 ---
This does not compile, and it is much simpler than ostr(ing)stream:
class A {
public:
int a;
A() : a(0) {}
A operator(int aa) { return *this; }
};
A operator(A thys, A (*f)(A))
{ return f(thys); }
A tic(A a)
{ return a; }
int main()
{
A() 12 tic; // ok
A a; a tic 12; // ok
//A() tic 12; // does not compile:
#if 0
err.cxx:28: invalid conversion from 'A(*)(A)' to 'int'
err.cxx:28: initializing argument 1 of 'A A::operator(int)'
#endif
}
#if 0
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-53)
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
[Bug fortran/25412] gfortran 4.0.2 seg fault
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2005-12-14 19:20 --- (In reply to comment #3) VASP is a commercial code, you shouldn't post large portions of it here. And your code excerpt doesn't even allow us to reproduce the bug. It requires other modules, without which it doesn't compile. What you should do (apart from trying a newer gfortran) is to reduce the bug to something that is standalone. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |critical Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25412
[Bug pch/14940] PCH largefile test fails on various platforms
--- Comment #33 from brett dot albertson at stratech dot com 2005-12-14 19:24 --- I think I'm seeing this same problem on Solaris x86. Executing on host: /var/tmp/gcc_svn/gcc20051214/gcc/xgcc -B/var/tmp/gcc_svn/gcc2 0051214/gcc/ largefile.c -O0 -g -I. -S -o largefile.s(timeout = 300) largefile.c:1: fatal error: had to relocate PCH^M compilation terminated.^M compiler exited with status 1 output is: largefile.c:1: fatal error: had to relocate PCH^M compilation terminated.^M FAIL: largefile.c -O0 -g (test for excess errors) Excess errors: largefile.c:1: fatal error: had to relocate PCH Should the SPARC fix apply for x86 also? Brett Albertson -- brett dot albertson at stratech dot com changed: What|Removed |Added CC||brett dot albertson at ||stratech dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940
[Bug rtl-optimization/25420] New: ICE in refers_to_regno_for_reload_p
gcc 4.1.0 20051206 rev.108118 $ gcc sp_enc.i -c -O2 amr_float/sp_enc.c: In function #8216;cbsearch#8217;: amr_float/sp_enc.c:7028: internal compiler error: in refers_to_regno_for_reload_p, at reload.c:6281 i've tested the testcase from PR24982 and it works so this is a different bug in compiler, i suppose. -- Summary: ICE in refers_to_regno_for_reload_p Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net GCC build triplet: i486-pld-linux GCC host triplet: i486-pld-linux GCC target triplet: i486-pld-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25420
[Bug rtl-optimization/25420] ICE in refers_to_regno_for_reload_p
--- Comment #1 from pluto at agmk dot net 2005-12-14 19:38 --- Created an attachment (id=10490) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10490action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25420
[Bug bootstrap/25397] [4.2 Regression] Bootstrap failed
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-12-14 19:54 --- I get passed these two places so closing as fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25397
[Bug rtl-optimization/25420] ICE in refers_to_regno_for_reload_p
--- Comment #2 from pluto at agmk dot net 2005-12-14 19:56 --- (gdb) bt #0 fancy_abort (file=0x8462bb6 ../../gcc/reload.c, line=6281, function=0x846317e refers_to_regno_for_reload_p) at ../../gcc/diagnostic.c:602 #1 0x082ae331 in refers_to_regno_for_reload_p (regno=0, endregno=1, x=0x0, loc=0x0) at ../../gcc/reload.c:6281 #2 0x082ae1aa in refers_to_regno_for_reload_p (regno=0, endregno=1, x=0xb6b7d408, loc=0x0) at ../../gcc/reload.c:6348 #3 0x082ae1aa in refers_to_regno_for_reload_p (regno=0, endregno=1, x=0xb6cc25f4, loc=0xb6cbe6ec) at ../../gcc/reload.c:6348 #4 0x082ae272 in refers_to_regno_for_reload_p (regno=0, endregno=1, x=0xb6cbe6f8, loc=0xb6cbe6ec) at ../../gcc/reload.c:6356 #5 0x082b0a96 in find_dummy_reload (real_in=0xb6cbe6d0, real_out=0xb6cbfe20, inloc=0xb6cbe6dc, outloc=0xb6cbe6ec, inmode=SImode, outmode=SImode, class=AREG, for_real=-1, earlyclobber=0) at ../../gcc/reload.c:1962 #6 0x082b86ec in find_reloads (insn=0xb6cc3438, replace=0, ind_levels=0, live_known=1, reload_reg_p=0x84f1760) at ../../gcc/reload.c:3145 #7 0x082c3e1b in reload (first=0xb6f960e0, global=1) at ../../gcc/reload1.c:1476 #8 0x083810b2 in global_alloc (file=0x0) at ../../gcc/global.c:628 #9 0x08381eed in rest_of_handle_global_alloc () at ../../gcc/global.c:2497 #10 0x082fbbe4 in execute_one_pass (pass=0x848b8c0) at ../../gcc/passes.c:828 #11 0x082fbd57 in execute_pass_list (pass=0x848b8c0) at ../../gcc/passes.c:860 #12 0x082fbd6b in execute_pass_list (pass=0x848ab40) at ../../gcc/passes.c:861 #13 0x080a2d82 in tree_rest_of_compilation (fndecl=0xb7afae00) at ../../gcc/tree-optimize.c:419 #14 0x08052560 in c_expand_body (fndecl=0xb7afae00) at ../../gcc/c-decl.c:6641 #15 0x0833441f in cgraph_expand_function (node=0xb7af3c98) at ../../gcc/cgraphunit.c:1055 #16 0x08334b78 in cgraph_optimize () at ../../gcc/cgraphunit.c:1121 #17 0x08057dc7 in c_write_global_declarations () at ../../gcc/c-decl.c:7649 #18 0x082dfc3d in toplev_main (argc=13, argv=0xbfffeaf4) at ../../gcc/toplev.c:1003 #19 0x0809432d in main (argc=1074593826, argv=0x739) at ../../gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25420
[Bug rtl-optimization/25420] ICE in refers_to_regno_for_reload_p
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-14 19:56 --- (In reply to comment #0) i've tested the testcase from PR24982 and it works so this is a different bug in compiler, i suppose. That is because the testcase in PR 24982 is for sh and the one in the other dup bugs of PR 24982 are for x86. Anyways this is still a dup of bug 24982. *** This bug has been marked as a duplicate of 24982 *** *** This bug has been marked as a duplicate of 24982 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25420
[Bug rtl-optimization/24982] [4.1/4.2 Regression] Bootstrap failure with ICE in refers_to_regno_for_reload_p
--- Comment #12 from pinskia at gcc dot gnu dot org 2005-12-14 19:56 --- *** Bug 25420 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24982
[Bug target/23067] Incorrect struct layout on darwin
--- Comment #23 from pinskia at gcc dot gnu dot org 2005-12-14 20:10
---
(In reply to comment #22)
struct a{long long t; int i;};
struct f{int tt; struct a d; int t;};
This one is still wrong after the (updated) patch in comment #20.
The size which Apple's GCC gives is 24 but the FSF gcc gives 32 even after
using the patch in comment #20.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23067
[Bug debug/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792
--- Comment #19 from jakub at gcc dot gnu dot org 2005-12-14 20:30 --- Subject: Bug 25023 Author: jakub Date: Wed Dec 14 20:30:46 2005 New Revision: 108537 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108537 Log: PR debug/25023 * config/i386/i386.c (ix86_force_to_memory): Always use SImode push for HImode in -m32. (ix86_free_from_memory): Likewise. * gcc.dg/pr25023.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr25023.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
[Bug fortran/25416] Segmentation fault in gfc_conv_function_call
--- Comment #3 from rguenth at gcc dot gnu dot org 2005-12-14 20:34 --- I doubt it, this seems to be about gfc_conv_function_call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25416
[Bug debug/25023] [4.1/4.2 Regression] ICE in def_cfa_1, at dwarf2out.c:792
--- Comment #20 from jakub at gcc dot gnu dot org 2005-12-14 20:38 --- Subject: Bug 25023 Author: jakub Date: Wed Dec 14 20:38:31 2005 New Revision: 108539 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108539 Log: PR debug/25023 * config/i386/i386.c (ix86_force_to_memory): Always use SImode push for HImode in -m32. (ix86_free_from_memory): Likewise. * gcc.dg/pr25023.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr25023.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/i386.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25023
[Bug classpath/25389] File(new URI(file:./)) - java.lang.NullPointerException
--- Comment #11 from cvs-commit at developer dot classpath dot org 2005-12-14 21:28 --- Subject: Bug 25389 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Tom Tromey [EMAIL PROTECTED]05/12/14 17:32:35 Modified files: java/io: File.java . : ChangeLog Log message: PR classpath/25389: * java/io/File.java (File): Throw IllegalArgumentException if URI is non-hierarchical. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/java/io/File.java.diff?tr1=1.59tr2=1.60r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.5810tr2=1.5811r1=textr2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25389
[Bug libstdc++/25421] New: catching exception from codecvt_byname() segfaults
[forwarded from http://bugs.debian.org/343108]
4.0 branch 20051204, 4.1 20051124
The following code segfaults. Looks like a double delete,
_S_destroy_c_locale() being called twice: first in the regular path of
codecvt.h:codecvt_byname ctor, then a second time when ~codecvt() is
automatically called to clean up the inherited class.
#include iostream
#include stdexcept
typedef std::codecvt_bynamewchar_t, char, mbstate_t cvt_byname_t;
int main()
{
cvt_byname_t *cvt;
char name[] = invalid-loc;
try {
cvt = new cvt_byname_t(name);
} catch (const std::runtime_error re) {
std::cerr successfully catched misnamed locale std::endl;
}
}
--
Summary: catching exception from codecvt_byname() segfaults
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25421
[Bug libstdc++/25421] [4.0/4.1/4.2 Regression] catching exception from codecvt_byname() segfaults
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 22:02 --- This worked in 3.3.x so this is a regression. Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-12-14 22:02:12 date|| Summary|catching exception from |[4.0/4.1/4.2 Regression] |codecvt_byname() segfaults |catching exception from ||codecvt_byname() segfaults Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25421
[Bug target/25350] [4.2 Regression] Can't include mmintrin.h
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-14 22:15 --- This causes the following testsuite errors: FAIL: gcc.target/i386/3dnow-1.c (test for excess errors) FAIL: gcc.target/i386/3dnow-2.c (test for excess errors) FAIL: gcc.target/i386/3dnowA-1.c (test for excess errors) FAIL: gcc.target/i386/3dnowA-2.c (test for excess errors) FAIL: gcc.target/i386/mmx-1.c (test for excess errors) FAIL: gcc.target/i386/mmx-2.c (test for excess errors) FAIL: gcc.target/i386/mmx-4.c (test for excess errors) WARNING: gcc.target/i386/mmx-4.c compilation failed to produce executable FAIL: gcc.target/i386/mmx-5.c (test for excess errors) FAIL: gcc.target/i386/pr13366.c (test for excess errors) FAIL: gcc.target/i386/sse-1.c (test for excess errors) ERROR: gcc.target/i386/sse-1.c: error executing dg-final: couldn't open sse-1.s: no such file or directory FAIL: gcc.target/i386/sse-13.c (test for excess errors) FAIL: gcc.target/i386/sse-14.c (test for excess errors) FAIL: gcc.target/i386/sse-2.c (test for excess errors) FAIL: gcc.target/i386/sse-3.c (test for excess errors) WARNING: gcc.target/i386/sse-3.c compilation failed to produce executable FAIL: gcc.target/i386/sse-7.c (test for excess errors) WARNING: gcc.target/i386/sse-7.c compilation failed to produce executable FAIL: gcc.target/i386/sse-9.c (test for excess errors) WARNING: gcc.target/i386/sse-9.c compilation failed to produce executable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25350
[Bug target/25138] [4.2 Regression] [m68k] undefined reference to `__floatunsidf'
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-14 22:17 --- Fixed by: 2005-12-13 Paul Brook [EMAIL PROTECTED] * config/m68k/fpgnulib.c (__unordsf2, __unorddf2, __unordxf2, __floatunsidf, __floatunsisf, __floatunsixf): New functions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25138
[Bug testsuite/25422] New: [4.2 Regression] gcc.dg/20031012-1.c and gcc.dg/weak/weak-3.c (and a couple others) fails, forgot to update for new option, -Walways-true
FAIL: gcc.dg/20031012-1.c (test for warnings, line 13) FAIL: gcc.dg/weak/weak-3.c (test for warnings, line 57) FAIL: g++.old-deja/g++.mike/warn8.C (test for warnings, line 14) FAIL: g++.old-deja/g++.mike/warn8.C (test for warnings, line 16) Those all fail because the tests were forgot to be updated for the new option -Walways-true. -- Summary: [4.2 Regression] gcc.dg/20031012-1.c and gcc.dg/weak/weak-3.c (and a couple others) fails, forgot to update for new option, -Walways-true Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite 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=25422
[Bug testsuite/25422] [4.2 Regression] gcc.dg/20031012-1.c and gcc.dg/weak/weak-3.c (and a couple others) fails, forgot to update for new option, -Walways-true
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25422
[Bug objc/25360] Complex types are not encoded
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 22:41 --- I am handling this one, I sent a RFC to the objective-C language list. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-14 22:41:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25360
[Bug c++/25407] [3.4 Regression] ICE when assigning value of variable passed to template as reference
--- Comment #2 from reichelt at gcc dot gnu dot org 2005-12-14 22:48 --- Probably related to PR19982. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org OtherBugsDependingO||19982 nThis|| Keywords||monitored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25407
[Bug testsuite/25422] [4.2 Regression] gcc.dg/20031012-1.c and gcc.dg/weak/weak-3.c (and a couple others) fails, forgot to update for new option, -Walways-true
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 22:52 --- Caused by: 2005-12-14 Ben Elliston [EMAIL PROTECTED] * c-common.c (c_common_truthvalue_conversion): Generalise warning for addresses converted to booleans; not just function addresses. * c-typeck.c (build_binary_op): Warn for address comparisons which can never be NULL (eg. func == NULL or var == NULL). * common.opt (Walways-true): New option. * c-opts.c (c_common_handle_option): Set it with -Wall. * doc/invoke.texi: Document it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-14 22:52:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25422
[Bug middle-end/25402] [4.2 Regression] PCH is broken
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-14 22:53 --- Confirmed via http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg00804.html (there was an email to the list too but I cannot find it). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-14 22:53:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25402
[Bug libstdc++/25421] [4.0/4.1/4.2 Regression] catching exception from codecvt_byname() segfaults
--- Comment #2 from pcarlini at suse dot de 2005-12-14 23:09 --- Ok, thanks. Seems a long standing but rather simple issue. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25421
[Bug rtl-optimization/25310] [4.1/4.2 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393
--- Comment #4 from uweigand at gcc dot gnu dot org 2005-12-14 23:35 --- Subject: Bug 25310 Author: uweigand Date: Wed Dec 14 23:34:51 2005 New Revision: 108543 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108543 Log: PR rtl-optimization/25310 * reload1.c (eliminate_regs_in_insn): Handle lowpart SUBREGs of the eliminable register when substituting into a PLUS. PR rtl-optimization/25310 * gcc.c-torture/compile/pr25310.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr25310.c Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25310
[Bug rtl-optimization/25310] [4.1/4.2 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393
--- Comment #5 from uweigand at gcc dot gnu dot org 2005-12-14 23:40 --- Subject: Bug 25310 Author: uweigand Date: Wed Dec 14 23:40:22 2005 New Revision: 108544 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108544 Log: PR rtl-optimization/25310 * reload1.c (eliminate_regs_in_insn): Handle lowpart SUBREGs of the eliminable register when substituting into a PLUS. PR rtl-optimization/25310 * gcc.c-torture/compile/pr25310.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/pr25310.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/reload1.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25310
[Bug rtl-optimization/25310] [4.1/4.2 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393
--- Comment #6 from uweigand at gcc dot gnu dot org 2005-12-14 23:40 --- Fixed. -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25310
[Bug rtl-optimization/23837] [4.0/4.1/4.2 regression] Wrong code with REG_NO_CONFLICT notes (caused by combine)
--- Comment #25 from steven at gcc dot gnu dot org 2005-12-15 00:52 --- Smarter folks than me (iant ;-) suggest that a multi-word rotate will normally need all the input bits when setting any of the output bits, so the entire no-conflict thing doesn't make sense here. So, let's not do that: --- optabs.c2005-12-15 01:49:23.0 +0100 +++ optabs.c.jj 2005-12-15 01:49:55.0 +0100 @@ -1525,7 +1525,14 @@ expand_binop (enum machine_mode mode, op else equiv_value = 0; - emit_insn (insns); + /* We can't make this a no conflict block if this is a word swap, +because the word swap case fails if the input and output values +are in the same register. */ + if (shift_count != BITS_PER_WORD) + emit_no_conflict_block (insns, target, op0, op1, equiv_value); + else + emit_insn (insns); + return target; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug rtl-optimization/23837] [4.0/4.1/4.2 regression] Wrong code with -fschedule-insns
--- Comment #23 from steven at gcc dot gnu dot org 2005-12-15 00:00 --- lreg decides to do this: ;; Register 95 in 25. ;; Register 97 in 28. ;; Register 99 in 22. ;; Register 102 in 21. ;; Register 104 in 25. ;; Register 111 in 28. ;; Register 112 in 19. ;; Register 113 in 28. and reload/greg agree (note the missing page breaks in the .greg dump btw): ;; Register dispositions: 95 in 25 97 in 28 99 in 22 102 in 21 104 in 25 111 in 28 112 in 19 113 in 28 So reg 95 and reg 104 are indeed assigned the same hard register. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug rtl-optimization/23837] [4.0/4.1/4.2 regression] Wrong code with REG_NO_CONFLICT notes (caused by combine)
--- Comment #26 from steven at gcc dot gnu dot org 2005-12-15 00:54 --- Needless to say really, but the patchlet in comment #25 is inverted... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug rtl-optimization/23837] [4.0/4.1/4.2 regression] Wrong code with REG_NO_CONFLICT notes (caused by combine)
--- Comment #24 from steven at gcc dot gnu dot org 2005-12-15 00:09 --- I think we can blame combine for this bug. -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression]|[4.0/4.1/4.2 regression] |Wrong code with -fschedule- |Wrong code with |insns |REG_NO_CONFLICT notes ||(caused by combine) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23837
[Bug fortran/18197] bus error on returning from a function
--- Comment #9 from eedelman at gcc dot gnu dot org 2005-12-15 00:47 --- Subject: Bug 18197 Author: eedelman Date: Thu Dec 15 00:47:13 2005 New Revision: 108555 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108555 Log: fortran/ 2005-12-14 Erik Edelmann [EMAIL PROTECTED] PR fortran/18197 * resolve.c (resolve_formal_arglist): Remove code to set the type of a function symbol from it's result symbol. testsuite/ 2005-12-14 Erik Edelmann [EMAIL PROTECTED] PR fortran/18197 * gfortran.dg/dummy_functions_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/dummy_functions_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18197
[Bug fortran/25423] New: Error with nested where statements
The source code subroutine sub (i, j) implicit none logical i(10), j(10) where (i) where (j) end where end where end subroutine sub leads to the error message $ ~/gcc/bin/gfortran -c where.f90 In file where.f90:6 end where 1 Error: Unsupported statement inside WHERE at (1) when compiled with $ ~/gcc/bin/gfortran --version GNU Fortran 95 (GCC) 4.2.0 20051129 (experimental) The end where statement should not lead to an error message; end where statements are allowed in where clauses. -- Summary: Error with nested where statements Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: schnetter at aei dot mpg dot de GCC build triplet: powerpc-apple-darwin8.3.0 GCC host triplet: powerpc-apple-darwin8.3.0 GCC target triplet: powerpc-apple-darwin8.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25423
[Bug target/25384] gcc 4.0.2 compile fails on AIX 5.2: target bigtoc not found
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-15 02:27 --- /openpkg/bin/ld: target bigtoc not found GNU binutils is not recommend at all on AIX because it has not been updated for weak or any newer features for AIX. Can you try this without using GNU binutils? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25384
[Bug tree-optimization/23838] [4.1/4.2 Regression] infinite loop in dse
--- Comment #3 from law at redhat dot com 2005-12-15 02:53 --- Subject: Re: [4.1/4.2 Regression] infinite loop in dse On Tue, 2005-12-13 at 00:23 +, pinskia at gcc dot gnu dot org wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-13 00:23 --- I am going to say this is 4.1 regression as it worked in 4.0.0 when removing the -fno-tree-copy-prop option but fails on the mainline and 4.1 branche with it. Somehow or another someone could come up with a testcase which fails also without any options which turn off optimizations (it is just harder to come up with one). I just checked in the attached patch to the 4.1 branch. I'm testing the same patch for mainline now. Basically we had a PHI node which both used and defined the same SSA_NAME (which can only occur at the head of a loop where the SSA_NAME is an invariant and copies have not been fully propagated). The safe thing to do is not try and optimize this case. --- Comment #4 from law at redhat dot com 2005-12-15 02:54 --- Created an attachment (id=10491) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10491action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23838
[Bug c++/21494] condensed nested namespaces
--- Comment #6 from gdr at integrable-solutions dot net 2005-12-15 03:40
---
Subject: Re: condensed nested namespaces
bkoz at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| --- Comment #5 from bkoz at gcc dot gnu dot org 2005-12-14 17:16 ---
|
| I'm encouraged by this work!!! Great news.
|
| The reason this would be useful is that then it would be possible to use a
| single macro to represent both scope and namespace. Ie,
|
| #define ACTIVE_SCOPE
|
| works for
|
| namespace ACTIVE_SCOPE
| {
| }
|
| and explicit qualifications like
|
| ACTIVE_SCOPE::obj;
|
| Anyway.
I see what you mean. However, as ever, macro-based tehcniques just
don't play nicely with othe scope rules.
When I read the code, I don't want to be deceived. When I see
namespace ACTIVE_SCOPE { /* blah blah */ }
I really think of a named scope. Later, when I see
ACTIVE_SCOPE::obj, I really think of the obj found in ACTIVE_SCOPE
through usual rules. However, if ACTIVE_SCOPE is #defined to nothing,
then that breaks down -- the obj found is not the one from the unnamed
namespace through usual rules.
So. while I believe this work can be useful, I'm not convinced that
the macro-based techniques make a case for the extension that would
require a different set of lookup rules.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21494
[Bug libgcj/25414] should update rmic
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-15 04:32 --- Confirmed (must is usually too harse of a word). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-12-15 04:32:08 date|| Summary|must update rmic|should update rmic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25414
[Bug rtl-optimization/25310] [4.1/4.2 Regression] ICE in reload_cse_simplify_operands, at postreload.c:393
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25310
