[Bug bootstrap/24382] ORIGINAL_LD_FOR_TARGET has bizarre value
--- Comment #3 from sherpya at netfarm dot it 2005-12-11 08:09 --- looking at gcc/Makefile ORIGINAL_LD_FOR_TARGET = ./j:/mingw/bin/../lib/gcc/mingw32/4.0.2/../../../../mingw32/bin/ld.exe ORIGINAL_NM_FOR_TARGET = /mingw/bin/nm so LD path takes a : that interfers with make, on gcc 402 it works fine, so I think the problem is how configure finds the path of ld, somehow changed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24382
[Bug fortran/25264] write to internal unit from the string itself gives wrong result ?
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2005-12-11 08:09 --- Patch submitted for approval. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25264
[Bug libfortran/25349] New: T edit descriptor broken for output on files
$ cat t.f program main character(len=10) line write (*,'(1X,A,T1,A)') 'A','B' write (line,'(1X,A,T1,A)') 'A','B' print '(A)',line end $ gfortran t.f $ ./a.out B BA $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../gcc/trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran Thread model: posix gcc version 4.2.0 20051204 (experimental) $ g77 t.f $ ./a.out BA BA -- Summary: T edit descriptor broken for output on files Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tkoenig at gcc dot gnu dot org OtherBugsDependingO 19292 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25349
[Bug target/23378] [4.1/4.2 Regression] code quality regression for complicated loop
--- Comment #8 from martin at mpa-garching dot mpg dot de 2005-12-11 09:40 --- I re-tested today with versions 3.3.2, 4.0-branch, 4.1-branch, trunk and gomp-branch, and could not reproduce the regression any more. So I think this report can be closed. Thanks to the unknown patcher! ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23378
[Bug libfortran/25349] T edit descriptor broken for output on files
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2005-12-11 10:20 --- I *hate* T format descriptors. And I thought we had this topic working and covered by the testsuite. This is not a regression, though, since 4.0.3 segfaults on this same example. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|19292 | nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.0.3 4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2005-12-11 10:20:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25349
[Bug libfortran/25340] Runtime error: Read past ENDFILE record
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2005-12-11 10:52 --- So, following Steven's question on c.l.f, this code is illegal. Most compilers report an EOF error (including Intel and g77), and branch if an END tag is present. I think the error issued by gfortran currently is better (Read past ENDFILE record), ie more precise. If people provide an END tag in the I/O statement, what do we want to do? I am in favour of throwing an error, and not branching silently. I know (from c.l.f) Brook thinks the same. I think we can close this as INVALID if you agree, Steven. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25340
[Bug libfortran/25349] T edit descriptor broken for output on files
--- Comment #2 from tkoenig at gcc dot gnu dot org 2005-12-11 10:57 --- (In reply to comment #1) I *hate* T format descriptors. And I thought we had this topic working and covered by the testsuite. The testsuite often uses internal writes. I just converted tl_editing.f90 to use external instead of internal I/O, and it failed, as well. This is not a regression, though, since 4.0.3 segfaults on this same example. It does work with g77. Why did you remove PR 19292? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25349
[Bug libfortran/25349] T edit descriptor broken for output on files
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2005-12-11 12:51 --- (In reply to comment #2) It does work with g77. Why did you remove PR 19292? Sorry, must have been a wrong keypress, didn't mean to do it. Another thing. I updated my tree (Thomas' convert patch got in) and this changed the problem: $ cat t.f write (*,'(1X,A,T1,A)') 'A','B' end $ gfortran t.f ./a.out At line 1 of file t.f Fortran runtime error: End of record Does someone else see this? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19292 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25349
[Bug c/25350] New: Can't include mmintrin.h
when trying to include file mmintrin.h in any file, compilation fails with the following message: mmintrin.h: In function '_mm_add_si64': mmintrin.h:280: error: can't convert between vector values of different size mmintrin.h: In function '_mm_sub_si64': mmintrin.h:382: error: can't convert between vector values of different size It works okay with older versions of gcc, and fails with 4.2.0 20051211 both with the include file that ships with it and with it's older versions. Environment: System: Linux amazonia 2.6.10-5-386 #1 Mon Oct 10 11:15:41 UTC 2005 i686 GNU/Linux Architecture: i686 host: i686-pc-linux-gnu build: i686-pc-linux-gnu target: i686-pc-linux-gnu configured with: ../gcc/configure --enable-languages=c --disable-nls --prefix=/home/glauber/usr How-To-Repeat: create a file containing the single directive #include mmintrin.h and compile it with gcc -msse filename -- Summary: Can't include mmintrin.h Product: gcc Version: 2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: glommer at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25350
[Bug c++/25351] New: Segmentation fault in function coverage_checksum_string
coverage_checksum_string function in gcc/coverage.c fails (SIGSEGV) with this input: = _GLOBAL__D__ZN5boost9unit_test88_GLOBAL__N_C__work_FlexIDE_libs_boost_libs_test_src_unit_test_main.cpp__17results_collectorE = This function is called if compilation is started with -fprofile-arcs and/or -ftest-coverage flags. -- Summary: Segmentation fault in function coverage_checksum_string Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cyberax at elewise dot com GCC build triplet: i686-mingw32 GCC host triplet: i686-mingw32 GCC target triplet: i686-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25351
[Bug libfortran/25349] T edit descriptor broken for output on files
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2005-12-11 13:59 --- (In reply to comment #3) Does someone else see this? Answering to myself: it disappeared with a clean build. As for the cause of the problem, it's truncation after the last character write. Another slightly different example: $ cat t.f open(11,status=replace) write (11,'(A,TL2,A)') 'AA','B' end $ gfortran t.f ./a.out $ cat fort.11 B -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-12-11 10:20:20 |2005-12-11 13:59:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25349
[Bug c++/25351] Segmentation fault in function coverage_checksum_string
--- Comment #1 from cyberax at elewise dot com 2005-12-11 14:10 --- Created an attachment (id=10450) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10450action=view) Quick fix Quick-and-dirty fix for this bug (works for me). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25351
[Bug testsuite/25352] New: xfail within dg-do command has no effect
If you use an xfail command within a dg-do, it has no effect. E.g this generic
testcase will FAIL rather than XFAIL:
/* { dg-do preprocess { xfail *-*-* } } */
#error intentional failure!
int main(void)
{
return 0;
}
Right now, none of the ~100 testcases in the testsuite using this idiom are
honoring it. So they're either now passing or unnecessarily cluttering up
testsuite results.
--
Summary: xfail within dg-do command has no effect
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25352
[Bug testsuite/25352] xfail within dg-do command has no effect
--- Comment #1 from ghazi at gcc dot gnu dot org 2005-12-11 15:14 --- We probably should have some sort of dg conformance test directory with simple tests ensuring all the directives work as advertised. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25352
[Bug target/25168] FAIL: g++.old-deja/g++.abi/cxa_vec.C execution test
--- Comment #1 from danglin at gcc dot gnu dot org 2005-12-11 15:47 --- Proposed fix is here: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00325.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25168
[Bug gcov/profile/25351] Segmentation fault in function coverage_checksum_string
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-11 15:52 --- Do you have a normal testcase that is C++ which produces this symbol? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Severity|critical|normal Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25351
[Bug testsuite/25171] FAIL: gfortran.dg/mixed_io_1.f90
--- Comment #2 from danglin at gcc dot gnu dot org 2005-12-11 16:00 --- Proposed fix is here: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00820.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25171
[Bug objc/25348] ICE encoding zero sized struct array
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-11 16:12 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00822.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||12/msg00822.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25348
[Bug testsuite/24478] gcc.dg/weak/weak-14.c (test for excess errors) fails
--- Comment #2 from danglin at gcc dot gnu dot org 2005-12-11 16:12 --- Subject: Bug 24478 Author: danglin Date: Sun Dec 11 16:12:48 2005 New Revision: 108382 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108382 Log: PR testsuite/25167 PR testsuite/24478 * gcc.dg/weak/weak-14.c: Add dg-require-alias. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/weak/weak-14.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24478
[Bug testsuite/25167] FAIL: gcc.dg/weak/weak-14.c
--- Comment #3 from danglin at gcc dot gnu dot org 2005-12-11 16:12 --- Subject: Bug 25167 Author: danglin Date: Sun Dec 11 16:12:48 2005 New Revision: 108382 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108382 Log: PR testsuite/25167 PR testsuite/24478 * gcc.dg/weak/weak-14.c: Add dg-require-alias. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/weak/weak-14.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25167
[Bug gcov/profile/25351] Segmentation fault in function coverage_checksum_string
--- Comment #3 from cyberax at elewise dot com 2005-12-11 16:23 --- Yes, preprocessed file attached. But this bug is somewhat hard to reproduce, I've spent about 3 hours trying to create a minimal test-case without much success - sometimes compilation is finished successfully, but the resulting code is invalid. This is the most reliable test case I could come up with. Example command line: i686-mingw32-g++ -ftemplate-depth-100 -Wno-attributes -O0 -fno-inline -Wall -g -mthreads -c C:\work\FlexIDE\flex-core\tests\xml_report_formatter.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25351
[Bug target/16589] [4.0/4.1/4.2 regression] [m68k] segmentation fault on identical array accesses in the ?: operators' body
--- Comment #14 from cyberax at elewise dot com 2005-12-11 16:25 --- Created an attachment (id=10451) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10451action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16589
[Bug gcov/profile/25351] Segmentation fault in function coverage_checksum_string
--- Comment #4 from cyberax at elewise dot com 2005-12-11 16:29 --- Created an attachment (id=10452) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10452action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25351
[Bug fortran/25106] [4.0/4.1] statement label is zero
--- Comment #5 from kargl at gcc dot gnu dot org 2005-12-11 16:47 --- http://gcc.gnu.org/ml/fortran/2005-12/msg00215.html This patch changes the handling of labels to catch problems with too many digits from laeding zeros. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25106
[Bug fortran/25055] numeric STOP code should be limited to five digits
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-11 16:47 --- Patch http://gcc.gnu.org/ml/fortran/2005-12/msg00215.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25055
[Bug fortran/25078] EQUILALENCE requires two or more objects
--- Comment #2 from kargl at gcc dot gnu dot org 2005-12-11 17:06 --- I have a tentative patch for this bug. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org AssignedTo|unassigned at gcc dot gnu |kargl at gcc dot gnu dot org |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25078
[Bug libobjc/25354] New: There should be an automated testsuite for objc_sizeof_type and objc_alignof_type
There is a need for an automated testsuite so that when convert libobjc not to use GCC's target headers, it can actually be tested. -- Summary: There should be an automated testsuite for objc_sizeof_type and objc_alignof_type Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org OtherBugsDependingO 24775 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25354
[Bug libobjc/25354] There should be an automated testsuite for objc_sizeof_type and objc_alignof_type
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-11 17:48 --- Mine. -- 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-11 17:48:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25354
[Bug libfortran/25349] T edit descriptor broken for output on files
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2005-12-11 17:54 --- This is simialr to pr25264. I had to fix a regression in tl-editing, so maybe i need to extend that to the regular files. I was beginning to wonder why internal units seemed so different fromn files. Perhaps the underlying bug in files, if fixed, will bring some of this code back into uniformity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25349
[Bug c++/25355] New: reinterpret_cast yields different (and incorrect) results when using -O2
The test case:
#include iostream
using namespace std;
int main()
{
unsigned int test = 1067320345;
cout reinterpret_castfloat (test) endl;
cout reinterpret_castfloat (test):
reinterpret_castfloat (test) endl;
}
When compiled using -g or -O1, the correct output is produced:
1.2345
reinterpret_castfloat (test): 1.2345
When compiled using -O2, the first reinterpret_cast produces incorrect
results. The actual value produced depends on the OS:
-NaN
reinterpret_castfloat (test): 1.2345
I tested this on Solaris 8 and on Linux Redhat WS3, with identical results. My
conclusion is that we're looking at an optimizer bug.
--
Summary: reinterpret_cast yields different (and incorrect)
results when using -O2
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason dot elbaum at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25355
[Bug c++/25355] reinterpret_cast yields different (and incorrect) results when using -O2
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-11 17:58 --- You are violating C/C++ aliasing rules. *** This bug has been marked as a duplicate of 21920 *** -- 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=25355
[Bug c/21920] alias violating
--- Comment #80 from pinskia at gcc dot gnu dot org 2005-12-11 17:58 --- *** Bug 25355 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jason dot elbaum at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug preprocessor/25356] New: -MT appends target name, rather than replacing it
The -MT name option with -MMD is supposed to substitute name for the target in the generated makefile. In most cases it seems to do so. However (using the attached file, which is a rename .ii file), the command: g++ -c -o accum.o -MMD accum.cc produces the makefile: accum.o: accum.cc as expected, but the command: g++ -c -o accum.o -MMD -MTfoo accum.cc produces: foo accum.o: accum.cc instead of the correct: foo: accum.cc -- Summary: -MT appends target name, rather than replacing it Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25356
[Bug preprocessor/25356] -MT appends target name, rather than replacing it
--- Comment #1 from igodard at pacbell dot net 2005-12-11 18:43 --- Created an attachment (id=10453) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10453action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25356
[Bug fortran/25078] EQUILALENCE requires two or more objects
--- Comment #3 from kargl at gcc dot gnu dot org 2005-12-11 18:45 --- http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00826.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25078
[Bug preprocessor/25356] -MT appends target name, rather than replacing it
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-11 18:46 --- *** This bug has been marked as a duplicate of 12448 *** *** This bug has been marked as a duplicate of 12448 *** -- 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=25356
[Bug driver/12448] -MT / -MQ don't behave as documented.
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-11 18:46 --- *** Bug 25356 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12448
[Bug preprocessor/25356] -MT appends target name, rather than replacing it
--- Comment #3 from igodard at pacbell dot net 2005-12-11 18:57 --- Reported *and patched* two years ago and still not fixed? What gives? Ivan -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25356
Re: hi, ive a new mail address
La cuenta a la que has tratado de enviar el mail no existe, favor de confirmarla.
[Bug bootstrap/24382] ORIGINAL_LD_FOR_TARGET has bizarre value
--- Comment #4 from sherpya at netfarm dot it 2005-12-11 20:41 --- My latest build unaffected from this bug is 4.1.0 cvs 20051013 (now I've switched to svn), anyway fixing the ld path compiles fine. -- sherpya at netfarm dot it changed: What|Removed |Added CC||sherpya at netfarm dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24382
[Bug driver/20425] -print-search-dirs doesn't honor mutil-os/multilib settings
--- Comment #9 from aoliva at gcc dot gnu dot org 2005-12-11 20:54 --- IMHO it's better to add a new option with the desired meaning than modifying the behavior of the current option. -print-multi-search-dirs maybe? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
[Bug c++/5509] -Wunused-parameter and tree inlining
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-11 21:53 --- Fixed in 4.0.x. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5509
[Bug c++/11314] [DR139] unqualified lookup prefers functions to non-functions
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-11 23:19 --- This is fixed in 4.1.0 as what is happening before was the friend was injecting when it should not have been. This was fixed by the patch which fixed PR 7874. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||7874 Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 Bug 11314 depends on bug 7874, which changed state. Bug 7874 Summary: [3.4/4.0/4.1 regression] g++ finds friend functions defined in class-definition but not declared in the enclosing namespace http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7874 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11314
[Bug c++/11685] typeinfo is not demangled in error messages
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-12-11 23:24 --- I think I Know why this shows up this way, we lower typeid(T) very early on. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-09-10 19:06:53 |2005-12-11 23:24:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11685
[Bug target/25299] Another ABI incompatibility with Apple's gcc
--- Comment #3 from amodra at gcc dot gnu dot org 2005-12-12 01:28 --- Subject: Bug 25299 Author: amodra Date: Mon Dec 12 01:28:50 2005 New Revision: 108393 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108393 Log: PR target/25299 * config/rs6000/rs6000.c (rs6000_special_round_type_align): Increase alignment to doubleword if the first field is a double array. * config/rs6000/linux64.h (TARGET_ALIGN_NATURAL): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/linux64.h trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25299
[Bug c++/25337] [3.4/4.0/4.1/4.2 Regression]ICE with template processing
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-12-12 01:40 --- Subject: Bug 25337 Author: mmitchel Date: Mon Dec 12 01:40:25 2005 New Revision: 108394 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108394 Log: PR c++/25337 * pt.c (tsubst_copy_and_build): Permit dependent types for the object in a class member access expression. PR c++/25337 * g++.dg/template/defarg7.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/defarg7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25337
[Bug c++/25337] [3.4/4.0/4.1/4.2 Regression]ICE with template processing
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-12-12 01:41 --- Subject: Bug 25337 Author: mmitchel Date: Mon Dec 12 01:41:16 2005 New Revision: 108395 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108395 Log: PR c++/25337 * pt.c (tsubst_copy_and_build): Permit dependent types for the object in a class member access expression. PR c++/25337 * g++.dg/template/defarg7.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/defarg7.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/pt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25337
[Bug c++/25337] [3.4/4.0/4.1/4.2 Regression]ICE with template processing
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-12 01:42 --- Subject: Bug 25337 Author: mmitchel Date: Mon Dec 12 01:42:33 2005 New Revision: 108396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108396 Log: PR c++/25337 * pt.c (tsubst_copy_and_build): Permit dependent types for the object in a class member access expression. PR c++/25337 * g++.dg/template/defarg7.C: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/template/defarg7.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/pt.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25337
[Bug c++/25337] [3.4 Regression]ICE with template processing
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-12 01:43 --- Fixed in 4.0.3. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[3.4/4.0/4.1/4.2|[3.4 Regression]ICE with |Regression]ICE with template|template processing |processing | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25337
[Bug rtl-optimization/24626] [4.1/4.2 Regression] internal compiler error: verify_flow_info failed
--- Comment #21 from pinskia at gcc dot gnu dot org 2005-12-12 02:38 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00832.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||12/msg00832.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
[Bug c++/25342] [3.4/4.0/4.1/4.2 Regression] internal compiler error: in lookup_member, at cp/search.c:1209
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-12 02:45 --- : Search converges between 2003-10-17-trunk (#379) and 2003-10-18-trunk (#380). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25342
[Bug target/23378] [4.1/4.2 Regression] code quality regression for complicated loop
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-12-12 02:46 --- Fixed so closing as such. -- 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=23378
[Bug c/25309] [3.4/4.0/4.1/4.2 Regression] ICE on initialization of a huge array
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-12 02:50 --- : Search converges between 2002-02-17-trunk (#59) and 2002-02-24-trunk (#60). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25309
[Bug c/25309] [3.4/4.0/4.1/4.2 Regression] ICE on initialization of a huge array
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-12 02:55 --- Hmm, I almost want to say this was caused by: 2002-02-20 Roger Sayle [EMAIL PROTECTED] Jakub Jelinek [EMAIL PROTECTED] PR c/4389 * tree.c (host_integerp): Ensure that the constant integer is representable in a HOST_WIDE_INT or an unsigned HOST_WIDE_INT when pos is zero or nonzero respectively. Clarify comment. * c-format.c (check_format_info_recurse): Fix host_integerp usage; the pos argument should be zero when assigning to a signed HOST_WIDE_INT. Which means it was a latent bug as this added the ICE in the first place. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||roger at eyesopen dot com, ||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25309
[Bug c/25314] [3.4/4.0/4.1/4.2 Regression] Unreachable code at beginning of switch statement is not reported anymore
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-12-12 03:01 --- : Search converges between 2003-04-16-trunk (#231) and 2003-04-17-trunk (#232). From that I almost think it was orginally caused by (but I should note that the 4.0 regression would have been caused by the change over to tree-ssa): 2003-04-16 Roger Sayle [EMAIL PROTECTED] * c-semantics.c (find_reachable_label): New function to find a potentially reachable label in an expression. (expand_unreachable_if_stmt): Similar to expand_if_stmt but assumes the start of the IF_STMT is unreachable (dead) code. (expand_unreachable_stmt): Similar to expand_stmt but assumes the start of the statement list is unreachable (dead) code. (genrtl_if_stmt): If the controlling expression of the IF is constant, use expand_unreachable_stmt for the THEN or ELSE clause as appropriate. (genrtl_switch_stmt): Use expand_unreachable_stmt to expand the body of a SWITCH statement. (expand_stmt): The code immediately following a return, break, continue or goto is unreachable. * Makefile.in (c-semantics.o): Depend upon tree-inline.h. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25314
[Bug c++/25294] [4.0/4.1/4.2 Regression] Bogus unterminated comment error from #pragma comment
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-12 03:09 --- : Search converges between 2004-09-20-161001-trunk (#551) and 2004-09-21-094824-trunk (#552). Looks like this was caused by: 2004-09-20 Matt Austern [EMAIL PROTECTED] Zack Weinberg [EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25294
[Bug c++/25357] New: ICE in typeid
The following code fails on 3.3.6 and 3.4.5. It does work on 4.0.2 and 4.1.0,
so I'm not sure if a fix would be backported to the 3.4 branch.
#include typeinfo
using namespace std;
class A
{
public:
A ();
virtual int a() = 0;
};
int main(void)
{
A *B;
typeid(typeid(*B)).name();
}
--
Summary: ICE in typeid
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: halcy0n at gentoo dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25357
[Bug c++/25357] [3.4 Regression] ICE in typeid
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to work|4.0.2 4.1.0 |4.0.2 4.1.0 2.95.3 Summary|ICE in typeid |[3.4 Regression] ICE in ||typeid Target Milestone|--- |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25357
[Bug c++/25357] [3.4 Regression] ICE in typeid
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-12 04:30 --- Confirmed, only a 3.4 regression. -- 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-12 04:30:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25357
[Bug fortran/25358] New: vector assignment to assumed-size Cray Pointee error
I must confess I don't much about cray pointers, but the model I work on contains a bunch of them. Therefore I can't provide a reduced testcase of this, but i'm attaching a code that proceduces the error. The code is valid according to lahey source checker (if fixed form), and compiles (and execute properly) with pgf90 and ifort compilers. -- Summary: vector assignment to assumed-size Cray Pointee error Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: deji_aking at yahoo dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25358
[Bug fortran/25358] vector assignment to assumed-size Cray Pointee error
--- Comment #1 from deji_aking at yahoo dot ca 2005-12-12 05:08 --- Created an attachment (id=10454) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10454action=view) Code that produces above error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25358
[Bug libobjc/25354] There should be an automated testsuite for objc_sizeof_type and objc_alignof_type
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-12 05:47 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25354
[Bug libobjc/25354] There should be an automated testsuite for objc_sizeof_type and objc_alignof_type
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-12 05:47 --- Subject: Bug 25354 Author: pinskia Date: Mon Dec 12 05:47:52 2005 New Revision: 108398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=108398 Log: 2005-12-12 Andrew Pinski [EMAIL PROTECTED] PR libobjc/25354 * objc.dg/gnu-encoding: New directory. * objc.dg/gnu-encoding/compat-common.h: New file. * objc.dg/gnu-encoding/struct-layout-1.h: New file. * objc.dg/gnu-encoding/struct-layout-1_test.h: New file. * objc.dg/gnu-encoding/vector-defs.h: New file. * objc.dg/gnu-encoding/gnu-encoding.exp: New file. * objc.dg/gnu-encoding/generate-random.c: New file. * objc.dg/gnu-encoding/generate-random_r.c: New file. * objc.dg/gnu-encoding/struct-layout-encoding-1_generate.c: New file. * objc.dg/gnu-encoding/generate-random.h: New file. 2005-12-12 Andrew Pinski [EMAIL PROTECTED] * encoding.c (TYPE_FIELDS): Fix to skip over just _C_STRUCT_B and the name. (get_inner_array_type): Fix to skip over _C_ARY_B and size. (rs6000_special_round_type_align): Update for the ABI fix. (objc_layout_finish_structure): Correct the encoding which is passed to ROUND_TYPE_ALIGN. Added: trunk/gcc/testsuite/objc.dg/gnu-encoding/ trunk/gcc/testsuite/objc.dg/gnu-encoding/compat-common.h trunk/gcc/testsuite/objc.dg/gnu-encoding/generate-random.c trunk/gcc/testsuite/objc.dg/gnu-encoding/generate-random.h trunk/gcc/testsuite/objc.dg/gnu-encoding/generate-random_r.c trunk/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp trunk/gcc/testsuite/objc.dg/gnu-encoding/struct-layout-1.h trunk/gcc/testsuite/objc.dg/gnu-encoding/struct-layout-1_test.h trunk/gcc/testsuite/objc.dg/gnu-encoding/struct-layout-encoding-1_generate.c trunk/gcc/testsuite/objc.dg/gnu-encoding/vector-defs.h Modified: trunk/gcc/testsuite/ChangeLog trunk/libobjc/ChangeLog trunk/libobjc/encoding.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25354
[Bug libobjc/25359] New: some objc.dg-struct-layout-encoding-1 failures
The objc.dg-struct-layout-encoding-1 failures happen on ppc-darwin:
FAIL: objc.dg-struct-layout-encoding-1/t003_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t004_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t006_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t008_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t010_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t012_main.m execution test
FAIL: objc.dg-struct-layout-encoding-1/t021_main.m execution test
This is due to ADJUST_FIELD_ALIGN returning the wrong value for struct {double
a;} which needs an alignment of 4 and not 8.
--
Summary: some objc.dg-struct-layout-encoding-1 failures
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libobjc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc-darwin
BugsThisDependsOn: 24775
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25359
[Bug libobjc/25359] some objc.dg-struct-layout-encoding-1 failures
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-12 05:51 --- Mine, I am working on this via PR 24775. -- 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-12 05:51:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25359
[Bug objc/25360] New: Complex types are not encoded
The following testsuite fails because of this
FAIL: objc.dg-struct-layout-encoding-1/t024_main.m execution test
unknown type ]}
struct { _Complex float a;} size is 8, but is calulated as 0
struct { _Complex float a;} align is 4, but is calulated as 1
struct { _Complex unsigned int a;} size is 8, but is calulated as 0
struct { _Complex unsigned int a;} align is 4, but is calulated as 1
FAIL: objc.dg-struct-layout-encoding-1/t024_main.m execution test
--
Summary: Complex types are not encoded
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
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=25360
[Bug objc/25361] New: vectors are not encoded
The following testsuite failures is because of this:
FAIL: objc.dg-struct-layout-encoding-1/t025_main.m execution test
unknown type ]}
struct { v4hi a;} size is 8, but is calulated as 0
struct { v4hi a;} align is 8, but is calulated as 1
FAIL: objc.dg-struct-layout-encoding-1/t025_main.m execution test
--
Summary: vectors are not encoded
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc
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=25361
[Bug objc/25348] ICE encoding zero sized struct array
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-12-12 05:55 --- I should note that this causes all of objc.dg-struct-layout-encoding-1 tests to fail on x86_64 and i?86. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25348
[Bug c/25314] [3.4/4.0/4.1/4.2 Regression] Unreachable code at beginning of switch statement is not reported anymore
--- Comment #6 from Uwe dot Seimet at seimet dot de 2005-12-12 06:21 --- Subject: Re: [3.4/4.0/4.1/4.2 Regression] Unreachable code at beginning of switch statement is not reported anymore Hello, Another comment from my side: When using -Wunreachable-code as a means to detect unreachable code in a switch statement I noticed that, just like the manpage says, -Wunreachable-code issues a lot of warnings when compiling with -g. There are so many warnings with -g -Wunreachable-code that it is impossible to see which warning is justified and which is not. The behavior with old versions of gcc was much more transparent. With gcc 3.3 I got an accurate warning for the unreachable code in the code sample I sent you. Which gcc 4.0 I only get this warning with -Wunreachable-code, but there are so many other (not useful) warnings that -Wunreachable-code is not a good solution wrt the switch statement. Best regards, Uwe -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25314
[Bug c++/25300] [4.1/4.2 regression] ICE with g++.dg/template/inherit.C
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25300
