[Bug fortran/37580] New: invalid code accepted without notice
Hi, following invalid code compiles w/o error with gfortran 4.4.0 program test real, pointer :: a(:), b(:) a(:) = b(:) end program test works as expected with earliear versions. $ gfortran -v Using built-in specs. Target: i586-pc-linux-gnu Configured with: /home/fx/gfortran_nightbuild/trunk/configure --prefix=/home/fx/gfortran_nightbuild/irun-20080918 --enable-languages=c,fortran --build=i586-pc-linux-gnu --enable-checking=release --with-gmp=/home/fx/gfortran_nightbuild/software Thread model: posix gcc version 4.4.0 20080918 (experimental) [trunk revision 140443] (GCC) Regards, Juha -- Summary: invalid code accepted without notice Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jpr at csc dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
[Bug tree-optimization/14703] [4.4 regression] Inadequate optimization of inline templated functions, infinite loop in ipa-reference and memory hog
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-09-19 06:22 --- The infinite loop in ipa-reference is solved now. Is the sixtrack problem remaining and if so, would be possible to test the proposed patch? We probably could track it as independent PR and close this one. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14703
[Bug target/37581] New: IEEE inexact-flag not working on the Alpha
The following shows a problem on the Alpha whereby
the division 2/3 made on floats is flagged as exact.
Here are the details:
$ cat sf.cc
#include fenv.h
#include cstdio
int main() {
float x = 2;
float y = 3;
feclearexcept(FE_INEXACT);
x = x / y;
printf(%d %.1000g\n, fetestexcept(FE_INEXACT) != 0, x);
}
$ g++ -v
Using built-in specs.
Target: alpha-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --with-long-double-128
--enable-checking=release --build=alpha-linux-gnu --host=alpha-linux-gnu
--target=alpha-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-3)
$ g++ -mieee-with-inexact sf.cc
$ ./a.out
0 0.66686534881591796875
$ cat /proc/cpuinfo
cpu : Alpha
cpu model : EV56
cpu variation : 7
cpu revision: 0
cpu serial number :
system type : Rawhide
system variation: Tincup
system revision : 0
system serial number: AY74642662
cycle frequency [Hz]: 399642346 est.
timer frequency [Hz]: 1200.00
page size [bytes] : 8192
phys. address bits : 40
max. addr. space # : 127
BogoMIPS: 705.16
kernel unaligned acc: 0 (pc=0,va=0)
user unaligned acc : 31 (pc=2074c18,va=87)
platform string : AlphaServer 1200 5/400 4MB
cpus detected : 1
cpus active : 1
cpu active mask : 0001
L1 Icache : 8K, 1-way, 32b line
L1 Dcache : 8K, 1-way, 32b line
L2 cache: 96K, 3-way, 64b line
L3 cache: 4096K, 1-way, 64b line
$
I attach the generated assembly code, which shows this is not a constant
propagation issue.
--
Summary: IEEE inexact-flag not working on the Alpha
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bagnara at cs dot unipr dot it
GCC host triplet: alphaev56-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37581
[Bug target/37581] IEEE inexact-flag not working on the Alpha
--- Comment #1 from bagnara at cs dot unipr dot it 2008-09-19 07:04 --- Created an attachment (id=16359) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16359action=view) Assembly code generated with g++ -S -mieee-with-inexact sf.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37581
[Bug c++/37582] New: std::pow strange overload resolution
gcc is complaining about an ambiguous overloading of operator in the statement (last non-trivial line) return std::pow(a,2.0); where no such operator appears. (I haven't seen a macro definition of 'pow' which pulls in '') If I replace the statement above by return ::pow(a,2.0); the error disappears. The function 'pow' should be injected into namespace 'std' when doing #include cmath or am I missing something? -- Summary: std::pow strange overload resolution Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jarausch at igpm dot rwth-aachen dot de GCC build triplet: i386 GCC host triplet: i386 GCC target triplet: i386 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
[Bug c++/37582] std::pow strange overload resolution
--- Comment #1 from jarausch at igpm dot rwth-aachen dot de 2008-09-19 07:33 --- Created an attachment (id=16360) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16360action=view) preprocessed failing source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
[Bug c++/37582] std::pow strange overload resolution
--- Comment #2 from jarausch at igpm dot rwth-aachen dot de 2008-09-19 07:35 --- gcc -v -save-temps -c TEST3.C Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.1 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.1 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.1/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.1/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-cld --enable-java-awt=gtk --with-arch=i686 --enable-languages=c,c++,java,treelang,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.1-r1 p1.1' Thread model: posix gcc version 4.3.1 (Gentoo 4.3.1-r1 p1.1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic' '-march=i686' /usr/libexec/gcc/i686-pc-linux-gnu/4.3.1/cc1plus -E -quiet -v -D_GNU_SOURCE TEST3.C -mtune=generic -march=i686 -fpch-preprocess -o TEST3.ii ignoring nonexistent directory /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/g++-v4 /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/g++-v4/i686-pc-linux-gnu /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/g++-v4/backward /usr/local/include /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-mtune=generic' '-march=i686' /usr/libexec/gcc/i686-pc-linux-gnu/4.3.1/cc1plus -fpreprocessed TEST3.ii -quiet -dumpbase TEST3.C -mtune=generic -march=i686 -auxbase TEST3 -version -o TEST3.s GNU C++ (Gentoo 4.3.1-r1 p1.1) version 4.3.1 (i686-pc-linux-gnu) compiled by GNU C version 4.3.1, GMP version 4.2.3, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 80f6aed7cf0c473d383e5ba3eede TEST3.C: In function 'double S_Precision::square(double)': TEST3.C:57: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: TEST3.C:57: note: candidate 1: operator(bool, bool) built-in TEST3.C:46: note: candidate 2: bool S_Precision::operator(int, const S_Precision::super_real) /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/g++-v4/cmath:389: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/g++-v4/cmath:389: note: candidate 1: operator(bool, bool) built-in TEST3.C:46: note: candidate 2: bool S_Precision::operator(int, const S_Precision::super_real) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
[Bug fortran/37583] New: ICE insert_bbt(): Duplicate key for self-calling ENTRY subprogram
Reported by Arjen Markus. http://gcc.gnu.org/ml/fortran/2008-09/msg00327.html The following program causes an ICE (insert_bbt(): Duplicate key found!) when compiled with gfortran 4.1 to 4.4. a) The unmodified program seems to be invalid as NAG f95 and ifort show: Error: ENTRY point GLOCAL is not in a RECURSIVE function error #6437: A subroutine or function is calling itself recursively. [GLOCAL] I believe the error message is correct (cf. quote from F2003 below). - accepts-invalid/diagnostic bug b) With recursive, Lahey, NAG f95 and ifort compile the program without errors/warnings. - ICE-on-valid-code module gsub contains subroutine sub( g ) ! prefix with RECURSIVE interface real function g(x) real x end function end interface real :: x, y call mysub( glocal ) return entry glocal( x, y ) y = x end subroutine end module Regarding RECURSIVE, Fortran 2003 has: The prefix-spec RECURSIVE shall appear if the function directly or indirectly invokes itself or a function defined by an ENTRY statement in the same subprogram. Similarly, RECURSIVE shall appear if a function defined by an ENTRY statement in the subprogram directly or indirectly invokes itself, another function defined by an ENTRY statement in that subprogram, or the function defined by the FUNCTION statement. (12.5.2.1, analogously in 12.5.2.2) -- Summary: ICE insert_bbt(): Duplicate key for self-calling ENTRY subprogram Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37583
[Bug rtl-optimization/37544] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #14 from uros at gcc dot gnu dot org 2008-09-19 08:02 --- Subject: Bug 37544 Author: uros Date: Fri Sep 19 08:01:07 2008 New Revision: 140484 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140484 Log: PR rtl-optimization/37544 * regrename.c (maybe_mode_change): Exit early when copy_mode is narrower than orig_mode and narrower than new_mode. testsuite/ChangeLog: PR rtl-optimization/37544 * gcc.dg/pr37544.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr37544.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/regrename.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug fortran/37580] invalid code accepted without notice
--- Comment #1 from jpr at csc dot fi 2008-09-19 08:20 --- Small update: this bug is already present in 4.3.1. The 4.2.x series seems OK. Juha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
[Bug middle-end/37567] tree SSA to normal checking takes abnormally long time
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-09-19 08:36 --- Indeed ;) Honza, mention this PR in the changelog please. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37567
[Bug fortran/37583] ICE insert_bbt(): Duplicate key for self-calling ENTRY subprogram
--- Comment #2 from pault at gcc dot gnu dot org 2008-09-19 09:00 --- Hah! I never did like ENTRY in Modules:-( Changing the actual argument reference to 'glocal' to appear after the ENTRY, by use of a GOTO, allows the horror below to run correctly. Thus, in the reporter's version, the symbol for glocal that is generated by the call to mysub is not being detected until the attempt to create the ENTRY symbol, whereupon the symtree 'glocal' is found to be a duplicate. The version below still misses the requirement that sub be RECURSIVE. Confirmed Paul module gsub contains recursive subroutine sub( g ) interface real function g(x) real x end function end interface interface subroutine mysub(proc) interface recursive subroutine proc(x, y) real x, y end subroutine end interface end subroutine end interface real :: x, y go to 100 ! Putting the reference to 'glocal' entry glocal( x, y ) ! after the ENTRY is OK. print *, glocal(x,y), x, y return 100call mysub( glocal ) ! here print *, Check call to g(x), g(21.0) end subroutine end module use gsub interface real function fcn(x) real x end function end interface print *, Direct call of call glocal (1.0, 2.0) print *, Call via 'sub' of call sub (fcn) end subroutine mysub(proc) interface recursive subroutine proc(x, y) real x, y end subroutine end interface call proc (3.0, 4.0) end subroutine real function fcn (x) real x fcn = 2.0 * x end function -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-19 09:00:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37583
[Bug ada/37572] compile Ada program fails (XML/Ada, 64 bit AMD)
--- Comment #3 from sam at gcc dot gnu dot org 2008-09-19 09:05 --- Could you try a more recent GCC version and check whether the bug is still present or not? It compiles fine with GCC 4.3.1 on x86_64/Debian GNU/Linux. -- sam at gcc dot gnu dot org changed: What|Removed |Added CC||sam at gcc dot gnu dot org GCC host triplet||x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37572
[Bug fortran/37580] invalid code accepted without notice
--- Comment #2 from jpr at csc dot fi 2008-09-19 09:25 --- This invalid peace of code gives an ICE: program test integer, pointer :: a(:),b(:) a(1) = b(1) end program test gfortran -c test.f90 test.f90: In function 'test': test.f90:3: internal compiler error: in gimplify_expr, at gimplify.c:7056 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- jpr at csc dot fi changed: What|Removed |Added CC||jpr at csc dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
[Bug c++/37582] [4.3 Regression] std::pow strange overload resolution
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-09-19 09:34 ---
Shorter testcase:
#include cmath
class super_real {
public:
super_real (double);
};
bool operator (int i, const super_real a);
double square(double a) {
return std::pow(a,2.0);
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||rejects-valid
Known to fail||4.3.0 4.3.2
Known to work||4.2.4 4.4.0
Priority|P3 |P1
Last reconfirmed|-00-00 00:00:00 |2008-09-19 09:34:07
date||
Summary|std::pow strange overload |[4.3 Regression] std::pow
|resolution |strange overload resolution
Target Milestone|--- |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37582
[Bug rtl-optimization/37544] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #15 from uros at gcc dot gnu dot org 2008-09-19 10:06 --- Subject: Bug 37544 Author: uros Date: Fri Sep 19 10:04:46 2008 New Revision: 140487 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140487 Log: PR rtl-optimization/37544 * regrename.c (maybe_mode_change): Exit early when copy_mode is narrower than orig_mode and narrower than new_mode. testsuite/ChangeLog: PR rtl-optimization/37544 * gcc.dg/pr37544.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr37544.c - copied, changed from r140484, branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr37544.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/regrename.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug fortran/37580] [4.3/4.4 Regression] Accepts pointer(:) = target without lower bound
--- Comment #3 from burnus at gcc dot gnu dot org 2008-09-19 10:12 --- program test real, pointer :: a(:), b(:) a(:) = b(:) end program test That program is invalid. R735 pointer-assignment-stmt is data-pointer-object [ (bounds-spec-list) ] = data-target or data-pointer-object (bounds-remapping-list ) = data-target The remapping on the LHS is in principle OK, however, the lower bound is missing: R737 bounds-spec is lower-bound-expr : R738 bounds-remapping is lower-bound-expr : upper-bound-expr For pointer bounds-remapping, see PR 29785. * * * program test integer, pointer :: a(:),b(:) a(1) = b(1) end program test This is also invalid as (1) is not an array bound (neither lower-bound:upper-bound nor a lower-bound:) but a single element. As A is a pointer to an array (and not an array of pointers) this is invalid. * * * I marked this as regression, but it is not a true regression as it was before only rejected because bound-specs where not allowed at all in earlier gfortran versions. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid, ice-on- ||invalid-code Last reconfirmed|-00-00 00:00:00 |2008-09-19 10:12:15 date|| Summary|invalid code accepted |[4.3/4.4 Regression] Accepts |without notice |pointer(:) = target ||without lower bound http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
[Bug rtl-optimization/37544] [4.4 Regression] Conversion double - unsigned long long - unsigned - double gives wrong results
--- Comment #16 from ubizjak at gmail dot com 2008-09-19 11:11 --- Fixed everywhere. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|Conversion double -|[4.4 Regression] Conversion |unsigned long long - |double - unsigned long long |unsigned - double gives|- unsigned - double gives |wrong results |wrong results http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37544
[Bug tree-optimization/37584] New: -ftree-ch causes stack corruption on mingw32
Unfortunately there is no simple testcase for this, but compiling mplayer I get a lot of crashes related to stack corruption i.e. a function allocates in the stack 8 bytes and later gdb says that it cannot access to a byte that instead is bound I've tested with --stack-size on the linker but nothing changes gcc version 4.4.0 20080916 (experimental) does the same thing while gcc 4.2 is ok it can be reproduced compiling mplayer/mencoder with gcc = 4.3 and doing a simple encoding using snow codec: mencoder -oac faac -faacopts br=64 -ovc lavc -lavcopts vcodec=snow:vstrict=-2:vqscale=3:pred=0:cmp=1:subcmp=1:mbcmp=1:qpel a.mpg -o a.avi Please tell me if I can provide more infos -- Summary: -ftree-ch causes stack corruption on mingw32 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sherpya at netfarm dot it GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
[Bug libstdc++/37470] parallel/base.h log2 conflicts with math.h
--- Comment #4 from singler at gcc dot gnu dot org 2008-09-19 11:38 --- Subject: Bug 37470 Author: singler Date: Fri Sep 19 11:37:16 2008 New Revision: 140490 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140490 Log: 2008-09-19 Johannes Singler [EMAIL PROTECTED] PR libstdc++/37470 * include/parallel/base.h: Rename log2 to __log2. (__log2) Avoid infinite loop for n = 0, return 0. * include/parallel/losertree.h: Rename log2 to __log2. * include/parallel/multiseq_selection.h: Likewise. * include/parallel/random_shuffle.h: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/parallel/base.h trunk/libstdc++-v3/include/parallel/losertree.h trunk/libstdc++-v3/include/parallel/multiseq_selection.h trunk/libstdc++-v3/include/parallel/random_shuffle.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37470
[Bug libstdc++/37470] parallel/base.h log2 conflicts with math.h
--- Comment #5 from singler at gcc dot gnu dot org 2008-09-19 11:44 --- Fixed. -- singler at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37470
[Bug middle-end/37576] [4.4 Regression] -v --help ICEs
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-19 11:54:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37576
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #37 from b0ntrict0r at yandex dot ru 2008-09-19 12:22 --- Created an attachment (id=16361) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16361action=view) Updated patch Could someone test updated patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug ada/37585] New: ACATS c650001 fails to link at -O1 because of undefined references
On trunk at Thu Sep 18 22:45:12 UTC 2008 (revision 140476) $ gnatchop ../trunk/gcc/testsuite/ada/acats/support/rep* $ gnatchop ../trunk/gcc/testsuite/ada/acats/tests/c6/c650001.a $ gnatmake -gnat95 -f -O1 c650001.adb ... gnatlink c650001.ali ./c650001.o: In function `_ada_c650001': c650001.adb:(.text+0x83d): undefined reference to `c650001_0__Ttask_arrayBIP__L27s__F24s.3033' c650001.adb:(.text+0x96d): undefined reference to `c650001_0__Ttask_arrayBIP___clean.3019' c650001.adb:(.text+0x97f): undefined reference to `c650001_0__Ttask_arrayBIP___clean.3019' At -O0 the test links and PASS. The test PASSed normally at: LAST_UPDATED: Wed Sep 17 10:26:14 UTC 2008 (revision 140411) http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01465.html -- Summary: ACATS c650001 fails to link at -O1 because of undefined references Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: link-failure Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37585
[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws
--- Comment #4 from bitti at iki dot fi 2008-09-19 12:12 --- (In reply to comment #3) Similar to Bug 15764. I ran again into this bug in gcc 4.3.2. Any idea when there's time to fix it? Matti Rintala -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799
[Bug ada/37572] compile Ada program fails (XML/Ada, 64 bit AMD)
--- Comment #4 from jdecs at mssblue dot net 2008-09-19 13:03 --- (In reply to comment #3) Could you try a more recent GCC version I can try. The last time I tried to find updates to GCC, GIT, and GNAT, there were dependency problems on 64 bit systems. I have also been in touch with Thomas and this may be a GPS related problem. I will research more today and return here, so you are welcome to simply let this sit for 24 hours or so. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37572
[Bug ada/37585] [4.4 regression] undefined references at -O for ACATS c650001
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-09-19 13:17 --- It's a fallout of the recent changes to the inlining machinery. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-19 13:17:53 date|| Summary|ACATS c650001 fails to link |[4.4 regression] undefined |at -O1 because of undefined |references at -O for ACATS |references |c650001 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37585
[Bug c++/36796] Support c++ override keyword
--- Comment #1 from b0ntrict0r at yandex dot ru 2008-09-19 13:18 --- (In reply to comment #0) This keyword seems to be Microsoft specific, right? -- b0ntrict0r at yandex dot ru changed: What|Removed |Added CC||b0ntrict0r at yandex dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36796
[Bug ada/37585] [4.4 regression] undefined references at -O for ACATS c650001
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-09-19 13:18 --- Looking into it. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-09-19 13:17:53 |2008-09-19 13:18:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37585
[Bug middle-end/37567] tree SSA to normal checking takes abnormally long time
--- Comment #9 from amacleod at redhat dot com 2008-09-19 13:27 --- Created an attachment (id=16362) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16362action=view) patch to fix the bug Looking a little closer, Im going to change Honza's patch a little. Since the checks are no longer being done after each BB is processed, they serve less purpose, and are runn just before the free_() routine. Moving them to the free_ routine makes more sense, and when I did that, it was clear then that there was a duplicate check there, as well as an extra loop of potential free()s which could never be called. so this cleans that all up. I'll check this in once its finishes testing this morning -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37567
[Bug fortran/37583] ICE insert_bbt(): Duplicate key for self-calling ENTRY subprogram
--- Comment #3 from pault at gcc dot gnu dot org 2008-09-19 13:33 --- Created an attachment (id=16363) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16363action=view) Fix for both aspects of PR The bit in decl.c fixes the duplicate key business and that in resolve.c flags up the need for a recursive subroutine. It has not been regtested yet but it does the right thing with gfortran.dg/entry* Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37583
[Bug tree-optimization/37574] [4.4 Regression] ICE with the vectorizer and GC
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-19 13:58 --- The problem is const_vector_from_tree called on: vector_cst 0x73375e10 type vector_type 0x733ed540 __vector signed int type integer_type 0x7332d540 int sizes-gimplified public SI size integer_cst 0x73319930 constant 32 unit size integer_cst 0x733195a0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x7332d540 precision 32 min integer_cst 0x733198a0 -2147483648 max integer_cst 0x733198d0 2147483647 pointer_to_this pointer_type 0x7333c9c0 V4SI size integer_cst 0x73319c90 constant 128 unit size integer_cst 0x73319cc0 constant 16 align 128 symtab 0 alias set -1 canonical type 0x733ed540 nunits 4 constant elt0: integer_cst 0x73352570 type integer_type 0x7332d540 int constant 3 elt1: integer_cst 0x73352570 3 elt2: integer_cst 0x73352570 3 elt3: integer_cst 0x73352570 3 elt4: integer_cst 0x73352570 3 elt5: integer_cst 0x73352570 3 elt6: integer_cst 0x73352570 3 elt7: integer_cst 0x73352570 3 Note V4SImode, yet 8 elements. This allocates a vector with rtvec_alloc (4), yet fills in 8 elements. Looking what creates it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37574
[Bug tree-optimization/37574] [4.4 Regression] ICE with the vectorizer and GC
--- Comment #2 from jakub at gcc dot gnu dot org 2008-09-19 14:12 ---
vect_get_vec_def_for_operand has:
tree vectype = STMT_VINFO_VECTYPE (stmt_vinfo);
int nunits = TYPE_VECTOR_SUBPARTS (vectype);
...
/* Case 1: operand is a constant. */
case vect_constant_def:
...
for (i = nunits - 1; i = 0; --i)
{
t = tree_cons (NULL_TREE, op, t);
}
vector_type = get_vectype_for_scalar_type (TREE_TYPE (op));
gcc_assert (vector_type);
vec_cst = build_vector (vector_type, t);
and similarly in a few other cases. vectype in this case is V8HI, but op is
SImode, so nunits is 8, yet vector_type has just 4 units.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||irar at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-09-19 14:12:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37574
[Bug ada/37543] Assembler error during compilation
--- Comment #3 from anhvofrcaus at gmail dot com 2008-09-19 14:23 --- On the second attempt to build gcc-4.4-20080912 using the latest binutils along with gmp-4.2.2 and mpfr-2.3.2, this problem goes away. In summary, GNAT works fines now. Additional note: c, ada, and c++ languages are built this time due to process run away, 25% CPU, when fortran is included. I just wonder if any one have ran into this problem at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37543
[Bug libgomp/37586] New: OpenMP thinks that I have 1 processor on an 8 processor pc
Hi, I have tried various OpenMP examples on the web and got them all to work fine. When I tried to parallelize some software that is part of a larger project, I have had a problem; OpenMP reports only one processor available and so I get only 1 thread. More details follow. I am running on an dual quad-core PC. I use RHEL 5.2 and have used the gcc 4.3.2 compiler (compiled it myself) and the RedHat's stock 4.1.2 compiler that has had OpenMP backported to it. Both exhibit the same problem. In some simple example code (e.g., dotproduct_reduction.cpp that found on the web), I can put in the following print: #ifdef _OPENMP cout Number of processors available: omp_get_num_procs() MAX Number of threads omp_get_max_threads() endl; cout.flush(); #endif and get something like: Number of processors available:8 MAX Number of threads 8 The example runs 8 threads and appears to run on multiple processors. In my large project on the same computer: #ifdef _OPENMP cout Number of processors available: omp_get_num_procs() MAX number of OpenMP threads omp_get_max_threads() endl; #endif and get: Number of processors available:1 MAX number of OpenMP threads 1 And so it doesn't parallelize. I am stumped! What could be causing OpenMP to be confused with regard to the number of processors? I thought it might be something in the compile, so I re-compiled absolutely everything with -fopenmp turned on and it made no difference. I tried setting the environment variable OMP_NUM_THREADS to 2 and got 2 threads, but only one processor was running the job. Compile samples: cd /home/hopper/UMBRA_4/umbra/SNL/rwm/buildRWM/utility /usr/bin/g++-4.3.2 -DBOOST_ALL_NO_LIB -Dutility_EXPORTS -O3 -DNDEBUG -fopenmp -fPIC -I/usr/include/boost-1_35 -I/home/hopper/UMBRA_4/umbra/SNL/rwm/TNT -I/home/hopper/UMBRA_4 -Wall -fPIC -o CMakeFiles/utility.dir/matrix_math.o -c /home/hopper/UMBRA_4/umbra/SNL/rwm/utility/matrix_math.cpp cd /home/hopper/UMBRA_4/umbra/SNL/rwm/buildRWM/micp /usr/bin/g++-4.3.2 -DBOOST_ALL_NO_LIB -Dmicp_EXPORTS -O3 -DNDEBUG -fopenmp -fPIC -I/usr/include/boost-1_35 -I/home/hopper/UMBRA_4/umbra/SNL/rwm/utility -I/home/hopper/UMBRA_4/umbra/SNL/rwm/CDF -I/home/hopper/UMBRA_4 -I/home/hopper/UMBRA_4/include/cstk2 -Wall -fPIC -o CMakeFiles/micp.dir/icp.o -c /home/hopper/UMBRA_4/umbra/SNL/rwm/micp/icp.cpp Link sample (everything is linked as a shared library) Linking CXX shared library ../libutility.so cd /home/hopper/UMBRA_4/umbra/SNL/rwm/buildRWM/utility /usr/bin/cmake -E cmake_link_script CMakeFiles/utility.dir/link.txt --verbose=1 /usr/bin/g++-4.3.2 -fPIC -O3 -DNDEBUG -fopenmp -Wl,--no-undefined -shared -Wl,-soname,libutility.so -o ../libutility.so CMakeFiles/utility.dir/CharObj.o CMakeFiles/utility.dir/Classify.o CMakeFiles/utility.dir/crc16_func.o CMakeFiles/utility.dir/crc32_func.o CMakeFiles/utility.dir/dsvdfit.o CMakeFiles/utility.dir/geometry.o CMakeFiles/utility.dir/math_funcs.o CMakeFiles/utility.dir/math_predicate.o CMakeFiles/utility.dir/matrix_math.o CMakeFiles/utility.dir/PCI.o CMakeFiles/utility.dir/rwm_status.o CMakeFiles/utility.dir/statistics.o CMakeFiles/utility.dir/string_funcs.o CMakeFiles/utility.dir/timing.o CMakeFiles/utility.dir/utility.o CMakeFiles/utility.dir/ValIndex.o /usr/local/lib/libumb.so -Wl,-rpath,/usr/local/lib BTW, the .tgz file containing the source code (exclude *.o and*.so) for this project has a size of 315788806, so its huge! -- Summary: OpenMP thinks that I have 1 processor on an 8 processor pc Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rrpeter at sandia dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586
[Bug libgomp/37586] OpenMP thinks that I have 1 processor on an 8 processor pc
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-19 14:43 --- I tried setting the environment variable OMP_NUM_THREADS to 2 and got 2 threads, but only one processor was running the job. this suggests your operating system is limiting your job to one CPU. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586
[Bug tree-optimization/36343] [4.3 Regression] Wrong code due to bad TBAA pruning of points-to-sets and use in call clobbering
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-09-19 15:05 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.3.0 |4.3.0 4.3.2 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36343
[Bug tree-optimization/36343] [4.3 Regression] Wrong code due to bad TBAA pruning of points-to-sets and use in call clobbering
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-09-19 15:06 --- Subject: Bug 36343 Author: rguenth Date: Fri Sep 19 15:04:36 2008 New Revision: 140492 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140492 Log: 2008-09-19 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36343 * tree-ssa-structalias.c (struct variable_info): Remove directly_dereferenced member. (new_var_info): Do not set it. (process_constraint_1): Likewise. (set_uids_in_ptset): Remove TBAA-pruning code. (find_what_p_points_to): Do not pass TBAA-pruning related parameters. * gcc.c-torture/execute/pr36343.c: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/execute/pr36343.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36343
[Bug middle-end/37587] New: ICE when use graphite
gfortran -v GNU Fortran (GCC) 4.4.0 20080919 (experimental) [~/tmp]$gfortran test.f90 -floop-block -O2 test.f90: In function 'main': test.f90:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. the fortran source: program main implicit none integer,parameter :: N=900 real(kind=8) :: x(N) integer(kind=4) :: i do i=1,N x(i)=sin(real(i,8)) end do print *, sum(x) end program main -- Summary: ICE when use graphite Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: linuxl4 at sohu 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=37587
[Bug ada/37543] Assembler error during compilation
--- Comment #4 from anhvofrcaus at gmail dot com 2008-09-19 15:24 ---
/home/voax/linux/build-4.4.0/./prev-gcc/xgcc
-B/home/voax/linux/build-4.4.0/./prev-gcc/ -B/usr/local/i686-pc-linux-gnu/bin/
-c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition
-Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
-DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4-20080912/gcc
-I../../gcc-4.4-20080912/gcc/. -I../../gcc-4.4-20080912/gcc/../include
-I../../gcc-4.4-20080912/gcc/../libcpp/include
-I/home/voax/linux/tools/gmp-4.2.2/include
-I/home/voax/linux/tools/mpfr-2.3.2/include
-I../../gcc-4.4-20080912/gcc/../libdecnumber
-I../../gcc-4.4-20080912/gcc/../libdecnumber/bid -I../libdecnumber
insn-attrtab.c -o insn-attrtab.o
The process, cc1, runs away when it attempts to execute the above line.
Additionally, other information is shown below.
[sjswdev3]:{79#}% uname -a
Linux sjswdev3 2.4.21-40.ELsmp #1 SMP Thu Feb 2 22:22:39 EST 2006 i686 i686
i386 GNU/Linux
[sjswdev3]:{80#}% gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3-20080911/configure
--enable-languages=c,ada,c++,fortran
--with-gmp=/home/voax/linux/tools/gmp-4.2.2
--with-mpfr=/home/voax/linux/tools/mpfr-2.3.2
Thread model: posix
gcc version 4.3.3 20080911 (prerelease) (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37543
[Bug target/37571] [4.4 regression] Performance regression due to compare/branch fuse optimization
--- Comment #3 from hjl dot tools at gmail dot com 2008-09-19 16:00 --- This regression is caused by compare/branch fuse optimization. Gcc 4.3 is OK. Turn it off fixes it. -- hjl dot tools at gmail dot com changed: What|Removed |Added Summary|Performance regression with |[4.4 regression] Performance |-mtune=core2|regression due to ||compare/branch fuse ||optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37571
[Bug tree-optimization/37568] [4.4 regression] ICE returning a struct
--- Comment #1 from jakub at gcc dot gnu dot org 2008-09-19 16:01 ---
Caused by http://gcc.gnu.org/viewcvs?view=revrevision=140415
C++ FE has a weird habit of sticking error_mark_node in DECL_INITIAL, in this
case in finalize_nrv_r:
if (DECL_INITIAL (dp-var)
DECL_INITIAL (dp-var) != error_mark_node)
{
init = build2 (INIT_EXPR, void_type_node, dp-result,
DECL_INITIAL (dp-var));
DECL_INITIAL (dp-var) = error_mark_node;
}
else
init = build_empty_stmt ();
IMHO either we relax the checking, allowing DECL_INITIAL to be error_mark_node
even for !TREE_STATIC, or finalize_nrv_r would need to clear DECL_INITIAL.
I don't know what consequences the latter might have though.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot
||org, hubicka at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37568
[Bug fortran/37588] New: GENERIC type-bound procedure is not resolved
The attached code generates the error log below. Note that the code is very similar to the example of MRC section 16.6.2, with the obvious difference that I am using the rank instead of type to disambiguate, and I am also using the PASS attribute. So, I think it is legal. Salvatore -- output [EMAIL PROTECTED] bugtest]$ gfortran -v -c gen-type-bound.f03 Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnutest --with-mpfr=/usr/local/mpfr --with-gmp=/usr/local/gmp --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20080919 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' /usr/local/gnutest/libexec/gcc/i686-pc-linux-gnu/4.4.0/f951 gen-type-bound.f03 -quiet -dumpbase gen-type-bound.f03 -mtune=generic -auxbase gen-type-bound -version -fintrinsic-modules-path /usr/local/gnutest/lib/gcc/i686-pc-linux-gnu/4.4.0/finclude -o /tmp/ccFO3fae.s GNU Fortran (GCC) version 4.4.0 20080919 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.4.0 20080919 (experimental), GMP version 4.2.2, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 gen-type-bound.f03:8.13: procedure, pass(a) :: foo_m = foo_m_inner 1 Warning: Polymorphic entities are not yet implemented, non-polymorphic passed-object dummy argument of 'foo_m_inner' at (1) accepted gen-type-bound.f03:7.13: procedure, pass(a) :: foo_v = foo_v_inner 1 Warning: Polymorphic entities are not yet implemented, non-polymorphic passed-object dummy argument of 'foo_v_inner' at (1) accepted gen-type-bound.f03:39.10: call dat%foo(x1) 1 Error: Found no matching specific binding for the call to the GENERIC 'foo' at (1) gen-type-bound.f03:40.10: call dat%foo(x2) 1 Error: Found no matching specific binding for the call to the GENERIC 'foo' at (1) -- Summary: GENERIC type-bound procedure is not resolved Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it 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=37588
[Bug fortran/37588] GENERIC type-bound procedure is not resolved
--- Comment #1 from sfilippone at uniroma2 dot it 2008-09-19 16:39 --- Created an attachment (id=16364) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16364action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37588
[Bug testsuite/37589] New: FAIL: objc.dg/stubify-(1|2).m (test for excess errors)
The following failures
FAIL: objc.dg/stubify-1.m (test for excess errors)
ERROR: objc.dg/stubify-1.m: error executing dg-final: couldn't open
stubify-1.s: no such file or directory
FAIL: objc.dg/stubify-2.m (test for excess errors)
FAIL: objc.dg/stubify-2.m scan-rtl-dump-not jump symbol_ref.*objc_msgSend:
dump file does not exist
are due to the error: unrecognized command line option -mdynamic-no-pic.
At the beginning of the sources I read:
/* { dg-do compile { target *-*-darwin* } } */
/* { dg-options -Os -mdynamic-no-pic } */
or
/* { dg-do compile { target *-*-darwin* } } */
/* { dg-options -mdynamic-no-pic -fdump-rtl-jump } */
What's wrong here?
--
Summary: FAIL: objc.dg/stubify-(1|2).m (test for excess errors)
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC build triplet: i686-apple-darwin9
GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37589
[Bug libgomp/37586] OpenMP thinks that I have 1 processor on an 8 processor pc
--- Comment #2 from rrpeter at sandia dot gov 2008-09-19 16:59 --- Subject: Re: OpenMP thinks that I have 1 processor on an 8 processor pc rguenth at gcc dot gnu dot org wrote: --- Comment #1 from rguenth at gcc dot gnu dot org 2008-09-19 14:43 --- I tried setting the environment variable OMP_NUM_THREADS to 2 and got 2 threads, but only one processor was running the job. this suggests your operating system is limiting your job to one CPU. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. Hi, Thanks for the response! If I run the simple sample code, then I get 8 processors and 8 threads while my umbra test case always replys that only 1 processor is available. The umbra test case that I am loading is small with regards to memory used and runs well (if slowly... 30 seconds or so), so it seems odd that the OS thinks that only 1 of 8 processors are available when the system-monitor shows that the remaining 6 or 7 are not being used ( 1%). So there is something strange going on... Either the query to the operating system is providing an invalid answer or the compile is somehow wrong or something!??? What do you think is the root cause of the problem? What does the code making the query do? Where is it? I am quite willing and (probably) able to work with someone to run tests on my computers to try to understand what the root problem is. There are a number of people here at the Intelligent Systems and Robotics Center interested in parallelizing umbra ( http://www.sandia.gov/isrc/UMBRA.html) and I have NO idea why my simple test inside umbra has FAILED. Thanks, Ralph Peters Principal Member of the Technical Staff Intelligent Systems and Robotics Sandia National Laboratories Albuquerque, NM USA -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #4 from jakub at gcc dot gnu dot org 2008-09-19 17:02 ---
Self-contained testcase, which will work even for non-ascii compatible
exec-charset:
/* PR tree-optimization/37573 */
struct S
{
unsigned int *a;
unsigned int b;
unsigned int c[624];
};
static unsigned char __attribute__((noinline))
foo (struct S *s)
{
unsigned int r;
if (!--s-b)
{
unsigned int *c = s-c;
unsigned int i;
s-a = c;
for (i = 0; i 227; i++)
c[i]
= c[i] ^ c[i + 1]) 0x7ffe) ^ c[i]) 1)
^ ((0 - (c[i + 1] 1)) 0x9908b0df) ^ c[i + 397];
}
r = *(s-a++);
r ^= (r 11);
r ^= ((r 0xff3a58ad) 7);
r ^= ((r 0xdf8c) 15);
r ^= (r 18);
return (unsigned char) (r 1);
}
static void __attribute__((noinline))
bar (unsigned char *p, unsigned int q, unsigned int r)
{
struct S s;
unsigned int i;
unsigned int *c = s.c;
*c = r;
for (i = 1; i 624; i++)
c[i] = i + 0x6c078965 * ((c[i - 1] 30) ^ c[i - 1]);
s.b = 1;
while (q--)
*p++ ^= foo (s);
};
static unsigned char p[23] = {
0xc0, 0x49, 0x17, 0x32, 0x62, 0x1e, 0x2e, 0xd5, 0x4c, 0x19, 0x28, 0x49,
0x91, 0xe4, 0x72, 0x83, 0x91, 0x3d, 0x93, 0x83, 0xb3, 0x61, 0x38
};
static unsigned char q[23] = {
0x3e, 0x41, 0x55, 0x54, 0x4f, 0x49, 0x54, 0x20, 0x55, 0x4e, 0x49, 0x43,
0x4f, 0x44, 0x45, 0x20, 0x53, 0x43, 0x52, 0x49, 0x50, 0x54, 0x3c
};
int
main (void)
{
unsigned int s;
s = 23;
bar (p, s, s + 0xa25e);
if (__builtin_memcmp (p, q, s) != 0)
__builtin_abort ();
return 0;
}
The bug is in the bar function, as can be proven by compiling it with -O3 and
adding optimize (0) attribute to bar.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug debug/28064] .debug_str is used only when optimizing
--- Comment #2 from tromey at gcc dot gnu dot org 2008-09-19 17:37 --- FWIW -- on trunk, debug_str is controlled by -fmerge-debug-strings, which is enabled by default (on supporting platforms). -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28064
[Bug middle-end/37567] tree SSA to normal checking takes abnormally long time
--- Comment #10 from amacleod at redhat dot com 2008-09-19 17:38 --- Subject: Bug 37567 Author: amacleod Date: Fri Sep 19 17:37:13 2008 New Revision: 140494 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140494 Log: PR middle-end/37567 * tree-ssa-ter.c (free_temp_expr_table): Make sure fields are actually empty before freeing them. (find_replaceable_exprs): Move asserts to free_temp_expr_table. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-ter.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37567
[Bug debug/20403] dwarf-3: DW_MACINFO_define - wrong lineno fields for predefined macros
--- Comment #3 from tromey at gcc dot gnu dot org 2008-09-19 17:42 --- I'm closing this. It is fixed on mainline and is not apparently a regression. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20403
[Bug tree-optimization/37573] [4.4 Regression] gcc-4.4 regression: incorrect code generation with -O1 -ftree-vectorize
--- Comment #5 from jakub at gcc dot gnu dot org 2008-09-19 17:52 --- The data dependence on the previous loop is clearly not considered, the loop is vectorized as if c on the rhs and c on the lhs were different non-overlapping arrays. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37573
[Bug c++/37590] New: g++ should emit different debug info for variable's type
Consider this code: #include string std::string s; I compiled this with -g and examined the resulting dwarf. 's' is represented as: 124e8: Abbrev Number: 63 (DW_TAG_variable) 24e9 DW_AT_name: s 24eb DW_AT_decl_file : 1 24ec DW_AT_decl_line : 3 24ed DW_AT_type: 24dd 24f1 DW_AT_external: 1 24f2 DW_AT_location: 5 byte block: 3 0 0 0 0(DW_OP_addr: 0) The type of s is: 124dd: Abbrev Number: 3 (DW_TAG_typedef) 24de DW_AT_name: (indirect string, offset: 0xf4e): string 24e2 DW_AT_decl_file : 17 24e3 DW_AT_decl_line : 61 24e4 DW_AT_type: f51 However, the declared type is not 'string', it is 'std::string'. I think it would be better to always emit the declared type as it appears in the source. That way, whatis s in gdb will give an answer which is expected by the user, and which is a valid type name at the point of declaration. -- Summary: g++ should emit different debug info for variable's type Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ 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=37590
[Bug target/37571] [4.4 regression] Performance regression due to compare/branch fuse optimization
--- Comment #4 from hjl dot tools at gmail dot com 2008-09-19 18:03 --- (In reply to comment #1) Root cause is that instruction length of fused jcc is set to 16, which prevent the block from merging and copying. For some reason Core2 runs poorly with a unmerged branch block under certain circonstances. I looked at the generated code without TARGET_FUSE_CMP_AND_BRANCH. In most cases, gcc doesn't put any instructions between TEST/CMP and JCC and we get macro-fusion optimization automatically even when TARGET_FUSE_CMP_AND_BRANCH is off. Since TARGET_FUSE_CMP_AND_BRANCH generates patterns with incorrect instruction length, it prevents the block from merging and copying, which hurt performance. We have 2 choices: 1. Correct insn length for *jcc_fused_X patterns, which what Joey's patch does. 2. Remove *jcc_fused_X patterns and optimize macro-fusion in Core 2 scheduling. I think we should do #2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37571
Re: [Bug c++/37590] New: g++ should emit different debug info for variable's type
Sent from my iPhone On Sep 19, 2008, at 10:58 AM, tromey at gcc dot gnu dot org [EMAIL PROTECTED] wrote: Consider this code: #include string std::string s; I compiled this with -g and examined the resulting dwarf. 's' is represented as: 124e8: Abbrev Number: 63 (DW_TAG_variable) 24e9 DW_AT_name: s 24eb DW_AT_decl_file : 1 24ec DW_AT_decl_line : 3 24ed DW_AT_type: 24dd 24f1 DW_AT_external: 1 24f2 DW_AT_location: 5 byte block: 3 0 0 0 0 (DW_OP_addr: 0) The type of s is: 124dd: Abbrev Number: 3 (DW_TAG_typedef) 24de DW_AT_name: (indirect string, offset: 0xf4e): string 24e2 DW_AT_decl_file : 17 24e3 DW_AT_decl_line : 61 24e4 DW_AT_type: f51 However, the declared type is not 'string', it is 'std::string'. No it is string inside the namespace of std. This typedef should be a sibling of a namespace. If it is, then it is the job of the debugger to show the correct thing. I think it would be better to always emit the declared type as it appears in the source. That way, whatis s in gdb will give an answer which is expected by the user, and which is a valid type name at the point of declaration. -- Summary: g++ should emit different debug info for variable's type Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ 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=37590
[Bug c++/37590] g++ should emit different debug info for variable's type
--- Comment #1 from pinskia at gmail dot com 2008-09-19 18:11 --- Subject: Re: New: g++ should emit different debug info for variable's type Sent from my iPhone On Sep 19, 2008, at 10:58 AM, tromey at gcc dot gnu dot org [EMAIL PROTECTED] wrote: Consider this code: #include string std::string s; I compiled this with -g and examined the resulting dwarf. 's' is represented as: 124e8: Abbrev Number: 63 (DW_TAG_variable) 24e9 DW_AT_name: s 24eb DW_AT_decl_file : 1 24ec DW_AT_decl_line : 3 24ed DW_AT_type: 24dd 24f1 DW_AT_external: 1 24f2 DW_AT_location: 5 byte block: 3 0 0 0 0 (DW_OP_addr: 0) The type of s is: 124dd: Abbrev Number: 3 (DW_TAG_typedef) 24de DW_AT_name: (indirect string, offset: 0xf4e): string 24e2 DW_AT_decl_file : 17 24e3 DW_AT_decl_line : 61 24e4 DW_AT_type: f51 However, the declared type is not 'string', it is 'std::string'. No it is string inside the namespace of std. This typedef should be a sibling of a namespace. If it is, then it is the job of the debugger to show the correct thing. I think it would be better to always emit the declared type as it appears in the source. That way, whatis s in gdb will give an answer which is expected by the user, and which is a valid type name at the point of declaration. -- Summary: g++ should emit different debug info for variable's type Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ 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=37590 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
[Bug c/37591] New: suppress signed and unsigned warnings when signed value known to be positive
In a case such as this, GCC ought to be able to prove that the signed variable
is positive and therefore suppress signed and unsigned warnings. I see this
in both C and C++.
#define MAX(a,b) ((a) (b) ? (a) : (b))
#define MIN(a,b) ((a) (b) ? (a) : (b))
unsigned int
constrain(unsigned int index, unsigned int offset, unsigned int limit)
{
int adj = index - offset;
adj = MAX(adj, 0);
return MIN(adj, limit); /* { dg-bogus signed and unsigned } */
}
--
Summary: suppress signed and unsigned warnings when signed
value known to be positive
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zackw at panix dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
[Bug tree-optimization/37568] [4.4 regression] ICE returning a struct
--- Comment #2 from jason at redhat dot com 2008-09-19 18:14 --- Subject: Re: [4.4 regression] ICE returning a struct jakub at gcc dot gnu dot org wrote: IMHO either we relax the checking, allowing DECL_INITIAL to be error_mark_node even for !TREE_STATIC, or finalize_nrv_r would need to clear DECL_INITIAL. I don't know what consequences the latter might have though. There is a general convention that DECL_INITIAL of error_mark_node means this is initialized by other code. But that doesn't seem to apply to automatic variables; changing finalize_nrv_r to clear DECL_INITIAL instead of setting it to error_mark_node shouldn't break anything. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37568
[Bug testsuite/37561] [4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C
--- Comment #5 from janis at gcc dot gnu dot org 2008-09-19 18:24 --- The operand of a postincrement and friends must be a modifiable lvalue. The type check code for both C and C++ calls get_unwidened, which removes the cast when it's a different size but leaves the cast when it's the same size. The later call to lvalue_p (via lvalue_or_else) says the operand is not an lvalue when there's still a cast, but doesn't complain when the cast has been removed. -- janis at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org, jsm28 at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37561
[Bug objc/7098] ObjC front end doesn't understand attributes on method parameters
--- Comment #7 from dominiq at lps dot ens dot fr 2008-09-19 18:32 --- Although I know this is not the right way to fix pr34310 I have done the following change to /usr/include/objc/Protocol.h: --- /usr/include/objc/Protocol.h-orig 2008-09-19 17:16:42.0 +0200 +++ /usr/include/objc/Protocol.h2008-09-19 17:19:36.0 +0200 @@ -43,16 +43,16 @@ /* Obtaining attributes intrinsic to the protocol */ -- (const char *)name OBJC2_UNAVAILABLE; +- (const char *)name; /* OBJC2_UNAVAILABLE; */ /* Testing protocol conformance */ -- (BOOL) conformsTo: (Protocol *)aProtocolObject OBJC2_UNAVAILABLE; +- (BOOL) conformsTo: (Protocol *)aProtocolObject; /* OBJC2_UNAVAILABLE; */ /* Looking up information specific to a protocol */ -- (struct objc_method_description *) descriptionForInstanceMethod:(SEL)aSel DEPRECATED_IN_MAC_OS_X_VERSION_10_5_AND_LATER; -- (struct objc_method_description *) descriptionForClassMethod:(SEL)aSel DEPRECATED_IN_MAC_OS_X_VERSION_10_5_AND_LATER; +- (struct objc_method_description *) descriptionForInstanceMethod:(SEL)aSel; /* DEPRECATED_IN_MAC_OS_X_VERSION_10_5_AND_LATER; */ +- (struct objc_method_description *) descriptionForClassMethod:(SEL)aSel; /* DEPRECATED_IN_MAC_OS_X_VERSION_10_5_AND_LATER; */ @end and the number of failures has gone fom: === objc Summary for unix === # of expected passes2896 # of unexpected failures85 # of expected failures 7 # of unresolved testcases 74 # of unsupported tests 2 to === objc Summary === # of expected passes3047 # of unexpected failures9 # of expected failures 7 # of unresolved testcases 2 # of unsupported tests 2 Now the failures are FAIL: objc.dg/headers.m (test for excess errors) ... /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:345: error: expected ';' before '__attribute__' ... FAIL: objc.dg/no-extra-load.m (test for excess errors) ... /System/Library/Frameworks/Foundation.framework/Headers/NSObject.h:122: error: expected ';' before '__attribute__' ... /System/Library/Frameworks/Foundation.framework/Headers/NSPointerFunctions.h:59: error: stray '@' in program ... FAIL: objc.dg/stret-2.m scan-assembler objc_msgSend_stret FAIL: objc.dg/stret-2.m scan-assembler-not objc_msgSend[^_S] FAIL: objc.dg/stret-2.m scan-assembler-not objc_msgSendSuper[^_] ... FAIL: objc.dg/stubify-1.m (test for excess errors)-| ... |-- see pr37589 FAIL: objc.dg/stubify-2.m (test for excess errors)-| ... FAIL: objc.dg/stubify-2.m scan-rtl-dump-not jump symbol_ref.*objc_msgSend: dump file does not exist ... FAIL: objc.dg/symtab-1.m scan-assembler L_OBJC_SYMBOLS.*:\n\t.long\t0\n\t.long\t0\n\t.short\t2\n\t.short\t0\n\t.long\tL_OBJC_CLASS_Derived.*\n\t.long\tL_OBJC_CLASS_Base.*\n ... I have also done similar changes to /System/Library/Frameworks/Foundation.framework/Headers/NSArray.h-mine /System/Library/Frameworks/Foundation.framework/Headers/NSCoder.h-mine /System/Library/Frameworks/Foundation.framework/Headers/NSDictionary.h-mine /System/Library/Frameworks/Foundation.framework/Headers/NSObject.h-mine /System/Library/Frameworks/Foundation.framework/Headers/NSRunLoop.h-mine /System/Library/Frameworks/Foundation.framework/Headers/NSSet.h-mine /System/Library/Frameworks/Foundation.framework/Headers/NSString.h-mine /System/Library/Frameworks/Foundation.framework/Headers/NSURL.h-mine /System/Library/Frameworks/Foundation.framework/Headers/NSURLHandle.h-mine but all of them only fix objc.dg/headers.m because I have been unable to find what to change in /System/Library/Frameworks/Foundation.framework/Headers/NSPointerFunctions.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7098
[Bug fortran/37577] Change internal array descriptor format for better syntax, C interop TR, rank 15
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-09-19 18:53:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37577
[Bug c++/37590] g++ should emit different debug info for variable's type
--- Comment #2 from tromey at gcc dot gnu dot org 2008-09-19 18:59 --- Consider this code: #include string std::string zardoz1; using std::string; string zardoz2; In this case, IMO, 'whatis' should print 'std::string' for zardoz1, but just 'string' for zardoz2. This is simply not possible given today's dwarf output, as the two variables share a type: 124ef: Abbrev Number: 63 (DW_TAG_variable) 24f0 DW_AT_name: (indirect string, offset: 0x47b): zardoz1 24f4 DW_AT_decl_file : 1 24f5 DW_AT_decl_line : 2 24f6 DW_AT_type: 27b 24fa DW_AT_external: 1 24fb DW_AT_location: 5 byte block: 3 0 0 0 0(DW_OP_addr: 0) 12501: Abbrev Number: 63 (DW_TAG_variable) 2502 DW_AT_name: (indirect string, offset: 0x483): zardoz2 2506 DW_AT_decl_file : 1 2507 DW_AT_decl_line : 5 2508 DW_AT_type: 27b 250c DW_AT_external: 1 250d DW_AT_location: 5 byte block: 3 0 0 0 0(DW_OP_addr: 0) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590
[Bug c++/37592] New: compiler gives up optimizing even on 64bit systems
When compiling certain complex calculation files I'm getting the message: /a/new/scs/glow/d2/pfoelsch/build/opt/linux_x86_64-o/gglib/../../../source_opt/gglib/hicum222/NLM.cpp: In member function 'void NLM_hicumshxpm::CModel::calcDer(NLM_hicumshxpm*, double*, CDer13u, double, const double, CDerHelper*, CDer13u, double, const double, CDerHelper*) const': /a/new/scs/glow/d2/pfoelsch/build/opt/linux_x86_64-o/gglib/../../../source_opt/gglib/hicum222/NLM.cpp:1014: warning: GCSE disabled: 59869 basic blocks and 139067 registers /a/new/scs/glow/d2/pfoelsch/build/opt/linux_x86_64-o/gglib/../../../source_opt/gglib/hicum222/NLM.cpp:1014: warning: jump bypassing disabled: 59833 basic blocks and 139067 registers I think giving up optimizing because of memory problems should not be done anymore on 64bit systems. Sorry -- I cannot attach the source code. -- Summary: compiler gives up optimizing even on 64bit systems Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peter_foelsche at agilent dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37592
[Bug fortran/37588] GENERIC type-bound procedure is not resolved
--- Comment #2 from burnus at gcc dot gnu dot org 2008-09-19 20:07 --- I believe the program is valid [modulo the CLASS/TYPE issue]. (NAG f95 by the way give an odd error message and crashes than with a segfault.) -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||d at domob dot eu, burnus at ||gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2008-09-19 20:07:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37588
[Bug fortran/37588] GENERIC type-bound procedure is not resolved
--- Comment #3 from domob at gcc dot gnu dot org 2008-09-19 20:17 --- I'll take this on as it is about GENERIC type-bound procedures. -- domob at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-09-19 20:07:54 |2008-09-19 20:17:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37588
[Bug c++/37592] compiler gives up optimizing even on 64bit systems (GCSE disabled, jump bypassing disabled)
--- Comment #1 from peter_foelsche at agilent dot com 2008-09-19 20:39 --- sorry -- I did discover the matching option to increase memory. -- peter_foelsche at agilent dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37592
[Bug c++/37592] compiler gives up optimizing even on 64bit systems (GCSE disabled, jump bypassing disabled)
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-19 20:41 --- Also it is not just about memory but also compile time. GCSE (PRE) is O(BBs * Regs). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37592
[Bug c/37593] New: -mlong-calls doesn't affect calls to _mcount generated with -pg
$ cat c.c
void blurb(void)
{
}
$ mips-linux-gcc -O2 -S -fno-pic -mno-abicalls c.c
$ cat c.s
.file 1 c.c
.section .mdebug.abi32
.previous
.gnu_attribute 4, 1
.text
.align 2
.globl blurb
.entblurb
.type blurb, @function
blurb:
.setnomips16
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
.setnoat
move$1,$31 # save current return address
subu$sp,$sp,8 # _mcount pops 2 words from stack
jal _mcount
.setat
j $31
.endblurb
.ident GCC: (GNU) 4.3.0
$
This breaks loadable kernel modules on Linux where _mcount is defined in the
kernel itself thus outside the range of a jal instruction.
--
Summary: -mlong-calls doesn't affect calls to _mcount generated
with -pg
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ralf at linux-mips dot org
GCC target triplet: mips*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37593
[Bug testsuite/37589] FAIL: objc.dg/stubify-(1|2).m (test for excess errors)
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-19 20:53 --- *** This bug has been marked as a duplicate of 25763 *** -- 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=37589
[Bug testsuite/25763] objc.dg/stubify-*.m, and obj-c++.dg/stubify-*.mm fail on i686-darwin
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-19 20:53 --- *** Bug 37589 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25763
[Bug c/37591] suppress signed and unsigned warnings when signed value known to be positive
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-19 20:55 --- I think this needs to delay the warning until VRP time really but I don't see how that can be done really. Also the front-end does known that adj will only be positive, the middle-end only knows during VRP really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
[Bug target/37584] -ftree-ch causes stack corruption on mingw32
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-19 21:03 --- We really need a testcase. And I really doubt -ftree-ch is causing any issues, there must be a latent bug in the back-end. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|tree-optimization |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37584
[Bug c/37591] suppress signed and unsigned warnings when signed value known to be positive
--- Comment #2 from zackw at panix dot com 2008-09-19 21:28 --- I'd be fine with it being like uninitialized value warnings. The false positives here are *really* annoying. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37591
[Bug c/33787] remove globals from c-format.c
--- Comment #4 from tromey at gcc dot gnu dot org 2008-09-19 21:38 --- FWIW -- I think this patch turned out to have some GC-related bug. And, I don't think I need this for the incremental branch either, any more. So, I'm just dropping it and closing this. If someone else wants to clean it up, that is fine by me. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33787
[Bug libgomp/37586] OpenMP thinks that I have 1 processor on an 8 processor pc
--- Comment #3 from jakub at gcc dot gnu dot org 2008-09-19 21:45 --- As already said in the openmp.org forum, omp_get_num_procs () will only return smaller number than the number of system CPUs online, if GOMP_CPU_AFFINITY env var is used, or if the calling process and/or thread has CPU affinity limited to a subset of CPUs. You can just step through omp_get_num_procs () / get_num_procs () routine and/or look at strace to see what is the case. omp_get_max_threads () in 4.3 and earlier incorrectly adjusts for dyn_var etc., works like parallel region determines the number of threads if num_thread isn't specified, only on the GCC trunk (4.4 and later) it returns the nthreads_var ICV. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Keywords||openmp Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586
[Bug libgomp/37586] OpenMP thinks that I have 1 processor on an 8 processor pc
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586
[Bug libgomp/37586] OpenMP thinks that I have 1 processor on an 8 processor pc
--- Comment #4 from rrpeter at sandia dot gov 2008-09-19 22:01 --- Subject: Re: OpenMP thinks that I have 1 processor on an 8 processor pc jakub at gcc dot gnu dot org wrote: --- Comment #3 from jakub at gcc dot gnu dot org 2008-09-19 21:45 --- As already said in the openmp.org forum, omp_get_num_procs () will only return smaller number than the number of system CPUs online, if GOMP_CPU_AFFINITY env var is used, or if the calling process and/or thread has CPU affinity limited to a subset of CPUs. You can just step through omp_get_num_procs () / get_num_procs () routine and/or look at strace to see what is the case. omp_get_max_threads () in 4.3 and earlier incorrectly adjusts for dyn_var etc., works like parallel region determines the number of threads if num_thread isn't specified, only on the GCC trunk (4.4 and later) it returns the nthreads_var ICV. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Keywords||openmp Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. Hi, Do you mean that there might be a problem with gcc 4.3 with regards to the problem that I see, but it may be fixed with gcc 4.4? It appears to me that GOMP_CPU_AFFINITY allows you to force threads onto particular processors -- is this correct? So are you suggesting that I could use GOMP_CPU_AFFINITY to sidestep this problem? If so, I will try it Monday. Thanks! Have a nice weekend! Ralph -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37586
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #6 from janis at gcc dot gnu dot org 2008-09-19 22:19 --- Created an attachment (id=16365) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16365action=view) minimized C testcase I don't yet understand what's going on but was able to come up with a relatively small executable test case in C. It fails with -O1 -funsafe-math-optimizations for r134833 but passes with those options for r134831. With r134833 it passes without -funsafe-math-optimizations. This testcase doesn't care about -ftree-fre. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug tree-optimization/30930] [4.3 Regression] vector can cause to create an extra variable, DECL_GIMPLE_REG_P not recomputed
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-09-19 22:24 --- Fixed on the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.2.3 |4.2.3 4.4.0 Summary|[4.3/4.4 Regression] vector |[4.3 Regression] vector can |can cause to create an extra|cause to create an extra |variable, DECL_GIMPLE_REG_P |variable, DECL_GIMPLE_REG_P |not recomputed |not recomputed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30930
[Bug tree-optimization/30930] [4.3 Regression] vector can cause to create an extra variable, DECL_GIMPLE_REG_P not recomputed
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-09-19 22:25 --- Subject: Bug 30930 Author: pinskia Date: Fri Sep 19 22:24:06 2008 New Revision: 140501 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140501 Log: 2008-09-19 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/30930 * tree-ssa.c (execute_update_addresses_taken): Also update DECL_GIMPLE_REG_P for vector and complex types. 2008-09-19 Andrew Pinski [EMAIL PROTECTED] PR tree-opt/30930 * gcc.dg/tree-ssa/vector-2.c: New test. * gcc.dg/tree-ssa/vector-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/vector-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/vector-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30930
[Bug c++/37594] New: Assembler reports wrong symbol already defined
Using this test code:
// #define _FILE_OFFSET_BITS 64
// #include fcntl.h
// #include features.h
// extern C int __REDIRECT (open, (__const char *__file, int __oflag, ...),
open64)
// __nonnull ((1));
extern C int open (__const char *__file, int __oflag, ...) __asm__
(open64);
extern C int
open(const char *path, int flags, ...)
{
return 0;
}
extern C int
open64 (__const char *path, int flags, ...)
{
return 0;
}
gcc reports the following error:
g++ -g -g -Wall -Wundef -I../../lib/win32 -I../../lib/common
-DBOX_VERSION=\trunk_2278M\ -DBOX_MODULE=\lib/intercept\ -c
intercept.cpp -o ../../debug/lib/intercept/intercept.o
/tmp/ccSJqEux.s: Assembler messages:
/tmp/ccSJqEux.s:32: Error: symbol `open64' is already defined
However, open64() is not already defined. If anything, open() is already
defined, by both a redirect and a definition. Commenting out either allows the
code to compile.
--
Summary: Assembler reports wrong symbol already defined
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris+gcc at qwirx dot com
GCC build triplet: i386-linux-gnu
GCC host triplet: i386-linux-gnu
GCC target triplet: i386-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37594
[Bug c++/37594] Assembler reports wrong symbol already defined
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-19 22:42 --- open64 in this case is defined twice in the assembly. You said that open is open64 via: extern C int open (__const char *__file, int __oflag, ...) __asm__ (open64); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37594
[Bug target/37381] [4.4 Regression] ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902
--- Comment #6 from sje at cup dot hp dot com 2008-09-19 23:01 --- I am not sure what I would be reviewing. Alexander, do you want me to review the patch from comment #4 as a fix for this bug or is there another patch you would like to propose to bring the ia64 sel-sched changes over. I checked out the sel-sched branch but I don't see any real differences between ia64.c on that branch and on main line. What changes would be checked in that would make the change in comment #4 unnecessary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37381
[Bug c/37595] New: funcs.c:323: internal compiler error: Segmentation fault
I got this ICE when compiling rpm 5.1.4. Detailed gcc output: gcc -v -save-temps -DHAVE_CONFIG_H -I. -I.. -I../.. -DMAGIC=\/Programs/RPM/5.1.4/lib/rpm/magic\ -DHAVE_LIBZ=1 -O3 -pipe -mcpu=cell -maltivec -mabi=altivec -fomit-frame-pointer -MT funcs.lo -MD -MP -MF .deps/funcs.Tpo -c funcs.c -fPIC -DPIC -o .libs/funcs.o gcc: warning: -pipe ignored because -save-temps specified Using built-in specs. Target: powerpc64-unknown-linux-gnu Configured with: /Files/Compile/Sources/gcc-4.3.2/./configure --prefix=/Programs/GCC/4.3.2 --sysconfdir=/Programs/GCC/Settings --localstatedir=/System/Variable --with-local-prefix=/Programs/GCC/4.3.2 --with-cpp-install-dir=lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --with-system-zlib --disable-bootstrap --enable-altivec --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=cell --with-cpu=default32 --with-tune=cell --with-long-double-128 Thread model: posix gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DHAVE_CONFIG_H' '-I.' '-I..' '-I../..' '-DMAGIC=/Programs/RPM/5.1.4/lib/rpm/magic' '-DHAVE_LIBZ=1' '-O3' '-pipe' '-mcpu=cell' '-maltivec' '-mabi=altivec' '-fomit-frame-pointer' '-MT' 'funcs.lo' '-MD' '-MP' '-MF' '.deps/funcs.Tpo' '-c' '-fPIC' '-DPIC' '-o' '.libs/funcs.o' '-mtune=cell' /Programs/GCC/4.3.2/libexec/gcc/powerpc64-unknown-linux-gnu/4.3.2/cc1 -E -quiet -v -I. -I.. -I../.. -MD .libs/funcs.d -MF .deps/funcs.Tpo -MP -MT funcs.lo -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -DHAVE_CONFIG_H -DMAGIC=/Programs/RPM/5.1.4/lib/rpm/magic -DHAVE_LIBZ=1 -DPIC funcs.c -mcpu=cell -maltivec -mabi=altivec -mtune=cell -fomit-frame-pointer -fPIC -O3 -fpch-preprocess -o funcs.i ignoring nonexistent directory /Programs/GCC/4.3.2/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/../../../../powerpc64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: . .. ../.. /Programs/GCC/4.3.2/include /Programs/GCC/4.3.2/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/include /Programs/GCC/4.3.2/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DHAVE_CONFIG_H' '-I.' '-I..' '-I../..' '-DMAGIC=/Programs/RPM/5.1.4/lib/rpm/magic' '-DHAVE_LIBZ=1' '-O3' '-pipe' '-mcpu=cell' '-maltivec' '-mabi=altivec' '-fomit-frame-pointer' '-MT' 'funcs.lo' '-MD' '-MP' '-MF' '.deps/funcs.Tpo' '-c' '-fPIC' '-DPIC' '-o' '.libs/funcs.o' '-mtune=cell' /Programs/GCC/4.3.2/libexec/gcc/powerpc64-unknown-linux-gnu/4.3.2/cc1 -fpreprocessed funcs.i -quiet -dumpbase funcs.c -mcpu=cell -maltivec -mabi=altivec -mtune=cell -auxbase-strip .libs/funcs.o -O3 -version -fomit-frame-pointer -fPIC -o funcs.s GNU C (GCC) version 4.3.2 (powerpc64-unknown-linux-gnu) compiled by GNU C version 4.3.2 20080819 (prerelease), GMP version 4.2.2, MPFR version 2.3.1. warning: MPFR header version 2.3.1 differs from library version 2.3.2. GGC heuristics: --param ggc-min-expand=45 --param ggc-min-heapsize=28092 Compiler executable checksum: df4e6b20e681dc8e226915a54ff05b81 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DHAVE_CONFIG_H' '-I.' '-I..' '-I../..' '-DMAGIC=/Programs/RPM/5.1.4/lib/rpm/magic' '-DHAVE_LIBZ=1' '-O3' '-pipe' '-mcpu=cell' '-maltivec' '-mabi=altivec' '-fomit-frame-pointer' '-MT' 'funcs.lo' '-MD' '-MP' '-MF' '.deps/funcs.Tpo' '-c' '-fPIC' '-DPIC' '-o' '.libs/funcs.o' '-mtune=cell' as -a32 -K PIC -mcell -maltivec -many -V -Qy -o .libs/funcs.o funcs.s GNU assembler version 2.18 (powerpc64-unknown-linux-gnu) using BFD version (GNU Binutils) 2.18 COMPILER_PATH=/Programs/GCC/4.3.2/libexec/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/Programs/GCC/4.3.2/libexec/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/Programs/GCC/4.3.2/libexec/gcc/powerpc64-unknown-linux-gnu/:/Programs/GCC/4.3.2/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/Programs/GCC/4.3.2/lib/gcc/powerpc64-unknown-linux-gnu/:/usr/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/usr/lib/gcc/powerpc64-unknown-linux-gnu/ LIBRARY_PATH=/Programs/GCC/4.3.2/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/usr/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/:/Programs/GCC/4.3.2/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/Programs/GCC/4.3.2/lib/gcc/powerpc64-unknown-linux-gnu/4.3.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DHAVE_CONFIG_H' '-I.' '-I..' '-I../..' '-DMAGIC=/Programs/RPM/5.1.4/lib/rpm/magic' '-DHAVE_LIBZ=1' '-O3' '-pipe' '-mcpu=cell' '-maltivec' '-mabi=altivec' '-fomit-frame-pointer' '-MT' 'funcs.lo' '-MD' '-MP' '-MF' '.deps/funcs.Tpo' '-c' '-fPIC' '-DPIC' '-o' '.libs/funcs.o' '-mtune=cell' -- Summary: funcs.c:323: internal compiler error: Segmentation fault Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot
[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception
--- Comment #9 from vmakarov at gcc dot gnu dot org 2008-09-19 23:24 --- Subject: Bug 37535 Author: vmakarov Date: Fri Sep 19 23:23:34 2008 New Revision: 140504 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140504 Log: 2008-09-19 Vladimir Makarov [EMAIL PROTECTED] PR middle-end/37535 * ira-lives.c (mark_reg_live, mark_reg_dead): New functions. (mark_ref_live, mark_ref_dead): Use them. (def_conflicts_with_inputs_p): Remove. (mark_early_clobbers): New function. (process_bb_node_lives): Call preprocess_constraints and mark_early_clobbers. Modified: branches/ira-merge/gcc/ChangeLog branches/ira-merge/gcc/ira-lives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37535
[Bug c/37595] funcs.c:323: internal compiler error: Segmentation fault
--- Comment #1 from giamby at infinito dot it 2008-09-19 23:26 --- Created an attachment (id=16366) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16366action=view) .i preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37595
[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math
--- Comment #7 from janis at gcc dot gnu dot org 2008-09-20 00:26 --- Sigh. My nifty small C testcase doesn't fail with current mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37449
[Bug c++/37596] New: g++ randomly does or doesn't require .template
In this testcase:
template class T
struct A
{
template class U void f();
template class U void g();
};
template class T
struct B
{
AT a;
template class U void f();
void h()
{
a.fint();
a.gint();
}
};
we currently accept the call to a.f, but reject the call to a.g. It seems that
we're doing unqualified lookup that finds B::f, and as a result assume that
A::f will also be a template, which is an odd thing to do.
--
Summary: g++ randomly does or doesn't require .template
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37596
[Bug target/37593] -mlong-calls doesn't affect calls to _mcount generated with -pg
--- Comment #1 from daney at gcc dot gnu dot org 2008-09-20 00:38 ---
This may be an ABI issue, but since -mlong-calls -mno-abicalls doesn't seem to
have a very rigorous ABI definition, we probably have some latitude with
respect to implementing this.
foo.c:
--
extern int a;
int foo(int, int, int);
int b(int i, int j, int k)
{
a++;
return foo(i, k, j) + 5;
}
--
$ mipsel-linux-gcc -mabi=64 -march=r5000 -O2 -S -fno-pic -pg -mno-abicalls
-mlong-calls foo.c
$ cat foo.s
.file 1 foo.c
.section .mdebug.abiN64
.previous
.gnu_attribute 4, 3
.text
.align 2
.align 3
.globl b
.entb
.type b, @function
b:
.setnomips16
.frame $sp,16,$31 # vars= 0, regs= 1/0, args= 0, gp= 0
.mask 0x8000,-8
.fmask 0x,0
daddiu $sp,$sp,-16
sd $31,8($sp)
.setnoat
move$1,$31 # save current return address
jal _mcount
.setat
lui $8,%highest(a)
daddiu $8,$8,%higher(a)
lui $2,%hi(a)
dsll$8,$8,32
daddu $8,$8,$2
lw $2,%lo(a)($8)
move$7,$5
lui $3,%highest(foo)
move$5,$6
daddiu $3,$3,%higher(foo)
move$6,$7
lui $7,%hi(foo)
addiu $2,$2,1
daddiu $7,$7,%lo(foo)
dsll$3,$3,32
daddu $3,$3,$7
.setnoreorder
.setnomacro
jalr$3
sw $2,%lo(a)($8)
.setmacro
.setreorder
ld $31,8($sp)
addiu $2,$2,5
.setnoreorder
.setnomacro
j $31
daddiu $sp,$sp,16
.setmacro
.setreorder
.endb
.ident GCC: (GNU) 4.3.2
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-09-20 00:38:15
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37593
[Bug c++/37596] g++ randomly does or doesn't require .template
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-20 00:41 --- I think this is a duplicate of bug 11814. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37596
[Bug c++/20308] parser thinks something is a start of a template-id when it is just less than
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-09-20 02:56 --- *** This bug has been marked as a duplicate of 10200 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20308
[Bug c++/10200] Weird clash with same names in different scopes
--- Comment #14 from pinskia at gcc dot gnu dot org 2008-09-20 02:56 --- *** Bug 20308 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=10200
[Bug c++/37596] g++ randomly does or doesn't require .template
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-09-20 02:57 --- Also PR 10200 which shows a rejects valid testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37596
[Bug other/37515] [meta-bug] GCC 4.5 pending patches
-- 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 |2008-09-20 02:59:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37515
[Bug c++/37533] ICE with parallel for loop
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-20 03:06 --- Well this is an accepts invalid code since it compiles at -O0 when it should not. The ICE is during scev analysis. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2008-09-20 03:06:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37533
[Bug c++/37561] [4.4 Regression] Revision 140405 caused g++.old-deja/g++.mike/warn1.C
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-09-20 03:09 --- This is a bug in the front-end ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|testsuite |c++ Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2008-09-20 03:09:18 date|| Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37561
[Bug target/37571] [4.4 regression] Performance regression due to compare/branch fuse optimization
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37571
[Bug fortran/37580] [4.3/4.4 Regression] Accepts pointer(:) = target without lower bound
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37580
[Bug tree-optimization/37579] [4.4 Regression] Vectorizer is causing code bloat and worse performance than unrolling would for a loop in SPEC 2k's eon
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-09-20 03:12 --- This is a regression as 4.3 enables the vectorizer at -O3. This is just one example of where tuning is still needed for the vectorizer. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Vectorizer is causing code |[4.4 Regression] Vectorizer |bloat and worse performance |is causing code bloat and |than unrolling would for a |worse performance than |loop in SPEC 2k's eon |unrolling would for a loop ||in SPEC 2k's eon Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37579
[Bug tree-optimization/37539] [4.4 Regression] Hang for -O3
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||compile-time-hog Summary|Hang for -O3|[4.4 Regression] Hang for - ||O3 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37539
[Bug tree-optimization/37579] [4.3/4.4 Regression] Vectorizer is causing code bloat and worse performance than unrolling would for a loop in SPEC 2k's eon
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] Vectorizer |[4.3/4.4 Regression] |is causing code bloat and |Vectorizer is causing code |worse performance than |bloat and worse performance |unrolling would for a loop |than unrolling would for a |in SPEC 2k's eon|loop in SPEC 2k's eon Target Milestone|4.4.0 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37579
