[Bug target/46586] New: Can't compile libiberty for bfin-elf target.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46586 Summary: Can't compile libiberty for bfin-elf target. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mon...@monami-software.com Host: i386-apple-darwin10.5.0 Target: bfin-elf Build: i386-apple-darwin10.5.0 configuration was failed with this message. configure:5724: error: Link tests are not allowed after GCC_NO_EXECUTABLES. This issue is not similar to #46553. It is required -mcpu option by bfin-elf-gcc. But there is no case in configuration phase. So the link test is failed with this message: xgcc: error: no processor type specified for linking
[Bug driver/46516] Non-multilib search problem in gcc.c / gfortran error: libgfortran.spec: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #18 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-21 08:02:53 UTC --- FIXED on the trunk (4.6), hopefully. Thanks for the report.
[Bug debug/46583] [4.6 Regression] -fcompare-debug failure with -O -fno-inline -fipa-cp -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46583 --- Comment #4 from Alexandre Oliva aoliva at gcc dot gnu.org 2010-11-21 08:06:28 UTC --- Created attachment 22474 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22474 Patch that fixes the problem This is the patch I'm testing.
[Bug tree-optimization/46312] gcc.dg/vec-scal-opt2.c fails for ARM targets.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46312 Ira Rosen irar at il dot ibm.com changed: What|Removed |Added Status|REOPENED|RESOLVED CC||irar at il dot ibm.com Resolution||FIXED --- Comment #12 from Ira Rosen irar at il dot ibm.com 2010-11-21 08:01:08 UTC --- Fixed.
[Bug bootstrap/46533] [alpha] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46533 --- Comment #1 from uros at gcc dot gnu.org 2010-11-21 08:18:38 UTC --- Author: uros Date: Sun Nov 21 08:18:31 2010 New Revision: 166999 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166999 Log: PR target/46533 * config/alpha/predicates.md (direct_call_operand): Return false for !TARGET_SMALL_TEXT targets. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/predicates.md
[Bug bootstrap/43328] multilib bootstrap broken.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328
Pawel Sikora pluto at agmk dot net changed:
What|Removed |Added
Known to work||
--- Comment #18 from Pawel Sikora pluto at agmk dot net 2010-11-21 08:23:27
UTC ---
(In reply to comment #17)
Subject: Bug 43328
Author: rwild
Date: Thu Apr 1 16:32:38 2010
New Revision: 157916
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157916
Log:
/:
PR bootstrap/43615
PR bootstrap/43328
Revert:
2010-03-31 Ralf Wildenhues ralf.wildenh...@gmx.de
* configure.ac: Do not pass --enable-multilib nor
--disable-multilib in baseargs. Accept explicitly passed
--enable_multilib.
* configure: Regenerate.
Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
what's the current status of the --{dis/en}able-multilib switches?
afaics at least the --disable-multilib is ignored on 4.5/4.6 svn head.
[Bug bootstrap/46533] [alpha] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46533 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2010-11-21 08:23:35 UTC --- Fixed.
[Bug bootstrap/43328] multilib bootstrap broken.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328
--- Comment #19 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-11-21
08:28:07 UTC ---
(In reply to comment #18)
what's the current status of the --{dis/en}able-multilib switches?
As far as I know that of from before this PR: enabled multilib is the default
(if you don't pass any option), and you can disable that by passing
--disable-multilib. So the only thing to remember is not to pass
--enable-multilib explicitly.
afaics at least the --disable-multilib is ignored on 4.5/4.6 svn head.
That would seem to be a new regression; please open a new PR for it, including
full details as usual for a PR. Thanks.
[Bug bootstrap/46533] [alpha] bootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46533 --- Comment #3 from uros at gcc dot gnu.org 2010-11-21 08:38:17 UTC --- Author: uros Date: Sun Nov 21 08:38:13 2010 New Revision: 167000 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167000 Log: PR target/46533 * gcc.dg/inline-2.c: Do not scan for jsr on alpha*-*-* targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/inline-2.c
[Bug bootstrap/43328] multilib bootstrap broken.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43328
--- Comment #20 from Pawel Sikora pluto at agmk dot net 2010-11-21 08:41:34
UTC ---
(In reply to comment #19)
(In reply to comment #18)
what's the current status of the --{dis/en}able-multilib switches?
As far as I know that of from before this PR: enabled multilib is the default
(if you don't pass any option), and you can disable that by passing
--disable-multilib. So the only thing to remember is not to pass
--enable-multilib explicitly.
afaics at least the --disable-multilib is ignored on 4.5/4.6 svn head.
That would seem to be a new regression; please open a new PR for it, including
full details as usual for a PR. Thanks.
ooops, false alarm. it was a typo (mutlilib) in my scripts.
[Bug c++/46580] -fcompare-debug failure with -gstabs -g due to different symbol mangling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46580 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.21 09:23:01 Component|debug |c++ Ever Confirmed|0 |1 --- Comment #3 from Alexandre Oliva aoliva at gcc dot gnu.org 2010-11-21 09:23:01 UTC --- Indeed, not a typical -fcompare-debug error. I looked a bit into the second testcase. The problem is that finish_struct calls debughooks-type_decl through finish_struct_1 and rest_of_type_compilation, and within dbxout_type_decl we compute the assembler_name for the type and nested decls. Later on, when we override the class name when processing the typedef name for the still anonymous class, the assembler names are not touched, and remain with incorrect name mangling. I can't decide whether this is a problem in the C++ front end, that should call rest_of_type_compilation only at the end of the typedef declaration, or in dbxout, that should refrain from resolving assembler names of anonymous types before the end of compilation, if that's at all possible. I don't know much about stabs, so I'll leave this to someone else who does. Reassigning to c++ in the hope that some g++ expert will chime in.
[Bug c++/46587] New: ICE when instantiating template member function in another template member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46587
Summary: ICE when instantiating template member function in
another template member
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: crexfex...@yandex.ru
$ cat test.cc
struct x {
template typename T void op1(void) { x::op2T; }
template typename T void op2(void) {}
};
int main(void) {
x().op1int();
return 0;
}
$ g++ -Wall test.cc
test.cc: In member function 'void x::op1() [with T = int]':
test.cc:7:18: instantiated from here
test.cc:2:44: 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.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr
--enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-gnu-unique-object --enable-lto --enable-plugin --disable-multilib
--disable-libstdcxx-pch --with-system-zlib --with-ppl --with-cloog
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info
Thread model: posix
gcc version 4.5.1 (GCC)
[Bug fortran/42112] overloaded function with allocatable result problem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #4 from Paul Thomas pault at gcc dot gnu.org 2010-11-21 11:41:13 UTC --- (In reply to comment #0) Fortran runtime error: Attempting to allocate already allocated array 'j' snip allocate(loc_ar(1)) loc_ar = gen_g() ! does not work !loc_ar = g() ! no problem here deallocate(loc_ar) end function f pure function g() result(j) integer, allocatable :: j(:) allocate( j(1) ) j = 2 end function g This looks correct to me, unless F2003 forces a reallocation in ALLOCATE, when frealloc-lhs is in effect? I will look tonight, unless somebody beats me to it. If the first allocate is omitted, the code compiles. but not with my patch. shucks*** Paul
[Bug fortran/46588] New: Segfault on automatic function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46588 Summary: Segfault on automatic function Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: oleg.steb...@gmail.com $ cat check.f90 program ds implicit none character(len = 4) :: ins = '+ - ' character(len = 20) st, aufun st = aufun(ins) ! результата равна n print *, st end function aufun(pm) character(len = *) pm character(len = *) aufun character(len = len(aufun)) temp temp = pm // pm //pm // pm aufun = '# ' // trim(temp) // ' #' end $ gfortran -v check.f90 Target: i686-pc-cygwin compiled by GNU C version 4.3.2 20080827 (beta) 2, GMP version 4.2.4, MPFR version 2.4.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 check.f90:7: 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. $cat check2.f90 function aufun(pm) character(len = *) pm character(len = *) aufun SAVE character(len = len(aufun)) temp temp = pm // pm //pm // pm aufun = '# ' // trim(temp) // ' #' end $ gfortran check2.f90 check2.f90:4.15: SAVE character(len = len(afun)) temp ! \xD1\xF2\xF0\xEE\xEA\xE0 temp - \xEF\xF0\xE8\xEC\xE5\xF0 1 Error: Syntax error in SAVE statement at (1) check2.f90:5.8: temp = pm // pm //pm // pm ! \xE0\xE2\xF2\xEE\xEC\xE0\xF2\xE8\xF7\xE5\xF1\xEA\xEE\xE3\xEE \xEE\xE1\xFA\xE5\xEA xF2\xE0 \xE4\xE0\xED\xED\xFB\xF5 1 Error: Can't convert CHARACTER(1) to REAL(4) at (1) check2.f90:6.23: aufun = '# ' // trim(temp) // ' #' 1 Error: 'string' argument of 'trim' intrinsic at (1) must be CHARACTER
[Bug c++/46589] New: struct member function not declared global
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46589
Summary: struct member function not declared global
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tempt...@freemail.hu
Summary of bug:
g++ doesn't declare L::G() global in the following code:
typedef struct { void G() ; } L ;
void L::G() { }
although it does here ('typedef struct L' instead of 'typedef struct'):
typedef struct L { void G() ; } L ;
void L::G() { }
Output from gcc -v:
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.4.0/configure
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --dis
able-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp
--with-dwarf2 --disable-win32-
registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs
--prefix=/mingw --with-gmp=
/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32
Thread model: win32
gcc version 4.4.0 (GCC)
File main.cpp:
typedef struct { void G() ; } L ;
static L X ;
int main() { X.G() ; }
File L0.cpp:
typedef struct { void G() ; } L ;
void L::G() { }
The command:
g++ main.cpp L0.cpp
This fails with:
C:\...\Temp\ccCl8AUu.o:main.cpp:(.text+0x16): undefined reference to `L::G()'
collect2: ld returned 1 exit status
BUT: File L1.cpp has 'typedef struct' instead of 'typedef struct L':
typedef struct L { void G() ; } L ;
void L::G() { }
g++ main.cpp L1.cpp
This works!
The difference can be seen in the assembly output:
.fileL0.cpp
.text
.align 2
.def__ZN1L1GEv;.scl3;.type32;.endef
__ZN1L1GEv:
LFB0:
pushl%ebp
LCFI0:
movl%esp, %ebp
LCFI1:
leave
ret
LFE0:
.fileL1.cpp
.text
.align 2
.globl __ZN1L1GEv
.def__ZN1L1GEv;.scl2;.type32;.endef
__ZN1L1GEv:
LFB0:
pushl%ebp
LCFI0:
movl%esp, %ebp
LCFI1:
leave
ret
LFE0:
__ZN1L1GEv is not declared global in L0.s.
[Bug tree-optimization/46590] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-11-21 13:22:50 UTC --- Created attachment 22475 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22475 gzipped test case Test case.
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #17 from Jan Hubicka hubicka at gcc dot gnu.org 2010-11-21 13:25:03 UTC --- Created attachment 22476 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22476 Proposed patch Hi, can you please try this variant? Honza
[Bug tree-optimization/46590] New: long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
Summary: long compile time with -O2 and many loops
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tkoe...@gcc.gnu.org
The attached program, which is a stress-test to test array assignment
dependencies for gfortran, compiles just about forever at -O2;
so far, it's 90 minutes and still no sign of finishing.
Compilation time without -O2 is 45 seconds.
Here is the perl script used to generate the test case.
#! /usr/bin/perl
$cnt = 0;
# @ind = (-6, -3, -1, 1, 3, 6);
@ind = (-5, -3, -1, 1, 3, 5);
$n = 6;
print EOF;
program main
implicit none
integer, dimension(-100:100) :: a,b,original
integer :: i
original = [(15*i+2,i=-100,100)]
EOF
foreach $stride_l (@ind) {
foreach $stride_r (@ind) {
for ($start_l = 1; $start_l $n; $start_l ++) {
for ($start_r = 1; $start_r $n; $start_r ++) {
for ($times = 0; $times $n; $times ++) {
$end_l = $start_l + ($times-1)*$stride_l;
$end_r = $start_r + ($times-1)*$stride_r;
print EOF;
a = original
b = original
a($start_l:$end_l:$stride_l) = a($start_r:$end_r:$stride_r)
b($start_l:$end_l:$stride_l) = original($start_r:$end_r:$stride_r)
if (any (a /= b)) then
print *,$start_l, $end_l,$stride_l,$start_r,$end_r, $stride_r
call abort
end if
EOF
}
}
}
}
}
print end program main\n;
[Bug libgomp/46592] New: -ftree-parallelize-loops attempts to link pthreads on non-posix systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46592 Summary: -ftree-parallelize-loops attempts to link pthreads on non-posix systems Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: gr...@redhat.com *-elf toolchains are failing the -ftree-parallelize-loops test pr46111 because using that option unconditionally attempts to link pthreads. I suppose I could define GOMP_SELF_SPECS to for my target, but why isn't pthreads only linked in with libgomp is linked?
[Bug target/46591] New: Can't build m68k-elf target on i386-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46591 Summary: Can't build m68k-elf target on i386-apple-darwin Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mon...@monami-software.com Host: i386-apple-darwin10.5.0 Target: m68k-pizzafactory-elf Build: i386-apple-darwin10.5.0 gcc -arch i386 -I/Volumes/git/pf3gnuchains4x/libcpp -I. -I/Volumes/git/pf3gnuchains4x/libcpp/../include -I./../intl -I/Volumes/git/pf3gnuchains4x/libcpp/include -g -O2 -W -Wall -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wc++-compat -pedantic -Wno-long-long -I/Volumes/git/pf3gnuchains4x/libcpp -I. -I/Volumes/git/pf3gnuchains4x/libcpp/../include -I./../intl -I/Volumes/git/pf3gnuchains4x/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo /Volumes/git/pf3gnuchains4x/libcpp/charset.c In file included from /Volumes/git/pf3gnuchains4x/libcpp/system.h:30, from /Volumes/git/pf3gnuchains4x/libcpp/charset.c:22: /usr/lib/gcc/i686-apple-darwin10/4.2.1/include/stddef.h:152: error: two or more data types in declaration specifiers make[1]: *** [charset.o] Error 1 make: *** [all-libcpp] Error 2
[Bug libgomp/46592] -ftree-parallelize-loops attempts to link pthreads on non-posix systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46592
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-21
14:34:51 UTC ---
Testing -ftree-parallelize-loops on targets which don't have threads doesn't
make any sense, for C -ftree-parallelize-loops=N tests are all in
gcc.dg/autopar/ which is guarded by
if ![check_effective_target_pthread] {
return
}
perhaps just the test needs
// { dg-require-effective-target pthread }
or we need g++.dg/autopar/
which will be guarded similarly.
[Bug target/46591] Can't build m68k-elf target on i386-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46591 --- Comment #1 from Masaki MURANAKA mon...@monami-software.com 2010-11-21 13:55:45 UTC --- At least AC_HEADER_STDC should be checked before AC_CHECK_TYPE(ptrdiff_t, int) in libcpp/configure.ac. Because it is defined ptrdiff_t in stddef.h on OSX environment, and stddef.h is not included unless STDC_HEADERS not defined. I tried to build with fix based on above and I seems to got correct binaries with no error. But... I can't explain why there is no issue under another targets. So I don't attach patches. Any comments and patches are appreciated.
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #19 from Jan Hubicka hubicka at ucw dot cz 2010-11-21 16:16:51 UTC --- ../../../work/libgomp/barrier.c:41:1: internal compiler error: in decide_is_variable_needed, at varpool.c:341 Hmm, interesting, get_emutls_init_templ_addr should no longer call finalize_decl on externals. Can you, please, post the backtrace? Perhaps there is some other place that is wrong about this. Honza
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #18 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-21 16:12:48 UTC --- can you please try this variant? Applied on tom of revision 167004, I still get on *darwin* ../../../work/libgomp/barrier.c:41:1: internal compiler error: in decide_is_variable_needed, at varpool.c:341
[Bug fortran/46581] [4.6 Regression] [OOP] segfault in SELECT TYPE with associate-name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46581 janus at gcc dot gnu.org changed: What|Removed |Added CC||d at domob dot eu --- Comment #3 from janus at gcc dot gnu.org 2010-11-21 16:32:23 UTC --- (In reply to comment #2) I just checked: It's indeed due to my r166480. Well, at least this commit is the direct cause of the regression, because it changed the names of the temporaries. However, there is nothing wrong with that patch, and I think it rather uncovered a latent bug of Daniel's patch for SELECT TYPE with associate-name: http://gcc.gnu.org/viewcvs?view=revisionrevision=163572 Namely, it does not handle correctly nested ASSOCIATE statements, which is how SELECT TYPE is implemented: There is an outer BLOCK namespace for the whole SELECT TYPE statement, with the selector as associate-name. And then there are inner BLOCK namespaces for each TYPE IS/CLASS IS case with a temporary as associate-name. Right now all the temporaries (and the selector) are initialized in the outer ns, though they should be initialized in their respective inner ns. So it can happen that by accident the temps get initialized before the selector, which causes the error. I have a draft patch which fixes this (regtesting now).
[Bug tree-optimization/46590] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-21 16:59:39 UTC --- On my laptop the test in comment #1 takes ~4mn to compile and at -O1 I had to interrupt the compilation after ~20mn during which all the time was spent in memory pagination!-(with 4Gb of RAM).
[Bug rtl-optimization/46571] [4.6 Regression] bootstrap comparison failure in fortran/trans-openmp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46571 --- Comment #3 from Richard Henderson rth at gcc dot gnu.org 2010-11-21 17:19:40 UTC --- Author: rth Date: Sun Nov 21 17:19:37 2010 New Revision: 167007 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167007 Log: PR rtl-optimization/46571 * gcse.c (hash_scan_set): Use next_nonnote_nondebug_insn. (compute_hash_table_work): Use NONDEBUG_INSN_P. Added: trunk/gcc/testsuite/gcc.dg/pr46571.c Modified: trunk/gcc/ChangeLog trunk/gcc/gcse.c
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #21 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-21 17:25:19 UTC --- (In reply to comment #19) ../../../work/libgomp/barrier.c:41:1: internal compiler error: in decide_is_variable_needed, at varpool.c:341 Hmm, interesting, get_emutls_init_templ_addr should no longer call finalize_decl on externals. Can you, please, post the backtrace? Perhaps there is some other place that is wrong about this. Honza Honza, I don't know how to do a backtrace in gdb when the compiler exits in gdb during the run as... Program exited with code 04. so I uploaded a single step walk from the 32nd instance of the varpool.c:341 breakpoint.
[Bug rtl-optimization/46571] [4.6 Regression] bootstrap comparison failure in fortran/trans-openmp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46571 --- Comment #4 from Richard Henderson rth at gcc dot gnu.org 2010-11-21 17:27:26 UTC --- Author: rth Date: Sun Nov 21 17:27:23 2010 New Revision: 167008 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167008 Log: PR rtl-optimization/46571 * gcse.c (hash_scan_set): Use next_nonnote_nondebug_insn. (compute_hash_table_work): Use NONDEBUG_INSN_P. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/gcse.c
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #20 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-21 17:20:40 UTC --- Created attachment 22477 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22477 backtrace for patch proposed in comment 17
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #22 from Jan Hubicka hubicka at ucw dot cz 2010-11-21 17:47:33 UTC --- Honza, I don't know how to do a backtrace in gdb when the compiler exits in gdb during the run as... Program exited with code 04. breakpoint on internal_error should help. I will take a look. Honza
[Bug fortran/46581] [4.6 Regression] [OOP] segfault in SELECT TYPE with associate-name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46581 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.21 18:15:45 AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug c++/46589] struct member function not declared global
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46589
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-21
17:51:27 UTC ---
typedef struct { void G() ; } L ;
void L::G() { }
This is not the same type as L in main.cpp and the error is correct, L::G is
not defined
What you've defined is {unnamed type in L0.cpp}::G and that's not the same
function as {type L in main.cpp}::G
it's confusing because you've used the typedef L in both files, but that
doesn't make it the same type, and more than this would:
// file1.cpp
typedef struct X { void f(); } L;
// file2.cpp
typedef struct Y { void g(); } L;
Clearly you have two different typedefs called L here (which is an ODR
violation) and not a single type.
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #23 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-21 18:02:40 UTC --- (In reply to comment #22) Honza, I don't know how to do a backtrace in gdb when the compiler exits in gdb during the run as... Program exited with code 04. breakpoint on internal_error should help. I will take a look. Honza That doesn't work here.
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #24 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-21 18:32:49 UTC --- breakpoint on internal_error should help. I will take a look. with breakpoint at fancy_abort: #0 fancy_abort (file=0x100e4f182 ../../work/gcc/varpool.c, line=341, function=0x100e4f28f decide_is_variable_needed) at ../../work/gcc/diagnostic.c:893 #1 0x000100d4d541 in decide_is_variable_needed (node=0x142d0b6e8, decl=0x142ddfaa0) at ../../work/gcc/varpool.c:341 #2 0x000100d4dab0 in varpool_finalize_decl (decl=0x142ddfaa0) at ../../work/gcc/varpool.c:424 #3 0x0001009e1ed3 in new_emutls_decl (decl=0x142d088c0) at ../../work/gcc/tree-emutls.c:332 #4 0x0001009e3ae6 in ipa_lower_emutls () at ../../work/gcc/tree-emutls.c:728 #5 0x000100850420 in execute_one_pass (pass=0x1010ad480) at ../../work/gcc/passes.c:1564 #6 0x000100851431 in execute_ipa_pass_list (pass=0x1010ad480) at ../../work/gcc/passes.c:1931 #7 0x000100ce211a in ipa_passes () at ../../work/gcc/cgraphunit.c:1696 #8 0x000100ce22fd in cgraph_optimize () at ../../work/gcc/cgraphunit.c:1765 #9 0x000100cdf69a in cgraph_finalize_compilation_unit () at ../../work/gcc/cgraphunit.c:1017 #10 0x00010003100d in c_write_global_declarations () at ../../work/gcc/c-decl.c:9837 #11 0x00010096aa40 in compile_file () at ../../work/gcc/toplev.c:888 #12 0x00010096db48 in do_compile () at ../../work/gcc/toplev.c:2319 #13 0x00010096dc98 in toplev_main (argc=8, argv=0x7fff5fbfd900) at ../../work/gcc/toplev.c:2382 #14 0x000100115df7 in main (argc=8, argv=0x7fff5fbfd900) at ../../work/gcc/main.c:36
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #25 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-21 18:37:09 UTC --- This seems to work: --- ../_clean/gcc/tree-emutls.c2010-11-19 18:13:00.0 +0100 +++ gcc/tree-emutls.c2010-11-21 19:34:11.0 +0100 @@ -257,7 +257,12 @@ get_emutls_init_templ_addr (tree decl) targetm.emutls.tmpl_section); } - varpool_finalize_decl (to); + /* Create varpool node for the new variable and finalize it if it is + not external one. */ + if (DECL_EXTERNAL (to)) +varpool_node (to); + else +varpool_finalize_decl (to); return build_fold_addr_expr (to); } @@ -324,7 +329,12 @@ new_emutls_decl (tree decl) record_references_in_initializer (to, false); } - varpool_finalize_decl (to); + /* Create varpool node for the new variable and finalize it if it is + not external one. */ + if (DECL_EXTERNAL (to)) +varpool_node (to); + else +varpool_finalize_decl (to); return to; }
[Bug tree-optimization/46590] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
Thomas Koenig tkoenig at gcc dot gnu.org changed:
What|Removed |Added
Keywords||memory-hog
--- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-11-21
18:49:20 UTC ---
Yes, this is a memory hog as well:
time ~/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 -O2 gener-max.f90
MAIN__ main
Analyzing compilation unit
{GC 183863k - 103486k}Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups {GC 156854k - 151699k}
whole-program ipa-profile cp inline pure-const static-varAssembling
functions:
MAIN__ {GC 281998k - 189095k} {GC 393064k - 341214k} {GC 554029k - 337458k}
{GC 477071k - 337199k} {GC 557246k - 473808k}
f951: out of memory allocating 968552 bytes after a total of 4310765568 bytes
real150m58.614s
user150m16.083s
sys 0m11.924s
i...@linux-fd1f:~/Krempel/Dep-c
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #26 from Jan Hubicka hubicka at ucw dot cz 2010-11-21 18:55:03 UTC --- This seems to work: This is OK, thanks! Honza
Re: [Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
This seems to work: This is OK, thanks! Honza
[Bug fortran/46588] Segfault on automatic function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46588 --- Comment #1 from Oleh Steblev oleg.steblev at gmail dot com 2010-11-21 19:13:43 UTC --- This chunk causes an error. Although PVF 10.8 passes this function. function aufun() character(len = *) aufun character(len = trim(aufun)) t end
[Bug fortran/46588] Segfault on automatic function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46588 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.21 19:18:49 CC||kargl at gcc dot gnu.org Ever Confirmed|0 |1 Severity|enhancement |normal --- Comment #2 from kargl at gcc dot gnu.org 2010-11-21 19:18:49 UTC --- Reduced testcase. function aufun(pm) character(len = *) pm character(len = *) aufun character(len = len(aufun)) temp ! This is the problem. aufun = 'hi' end I haven't checked if this is legal Fortran, but in any event the compiler should not ICE.
[Bug tree-optimization/46590] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-11-21
19:39:23 UTC ---
With -fno-ivopts, the alias statement walking is the clear culprit
(a somewhat shorter test case):
i...@linux-fd1f:~/Krempel/Dep-c time
~/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 -ftime-report -O2 -fno-ivopts
gener-4.f90
MAIN__ main
Analyzing compilation unit
{GC 44026k - 25146k}Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups {GC 37683k - 36011k}
whole-program ipa-profile cp inline pure-const static-varAssembling
functions:
MAIN__ {GC 54739k - 37948k} {GC 61997k - 51931k} {GC 77889k - 51575k} {GC
103199k - 77477k} {GC 100723k - 74180k} {GC 98147k - 73521k} main
Execution times (seconds)
garbage collection: 0.79 ( 0%) usr 0.00 ( 0%) sys 0.81 ( 0%) wall
0 kB ( 0%) ggc
callgraph construction: 0.06 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall
2465 kB ( 1%) ggc
callgraph optimization: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall
2 kB ( 0%) ggc
ipa cp: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
256 kB ( 0%) ggc
ipa profile : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
0 kB ( 0%) ggc
ipa pure const: 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall
0 kB ( 0%) ggc
cfg construction : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
0 kB ( 0%) ggc
cfg cleanup : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.16 ( 0%) wall
344 kB ( 0%) ggc
CFG verifier : 1.40 ( 0%) usr 0.01 ( 0%) sys 1.35 ( 0%) wall
0 kB ( 0%) ggc
trivially dead code : 0.20 ( 0%) usr 0.00 ( 0%) sys 0.20 ( 0%) wall
0 kB ( 0%) ggc
df scan insns : 0.20 ( 0%) usr 0.01 ( 0%) sys 0.21 ( 0%) wall
0 kB ( 0%) ggc
df multiple defs : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall
0 kB ( 0%) ggc
df reaching defs : 2.12 ( 1%) usr 0.01 ( 0%) sys 2.15 ( 1%) wall
0 kB ( 0%) ggc
df live regs : 0.93 ( 0%) usr 0.00 ( 0%) sys 1.00 ( 0%) wall
0 kB ( 0%) ggc
df liveinitialized regs: 0.26 ( 0%) usr 0.00 ( 0%) sys 0.23 ( 0%) wall
0 kB ( 0%) ggc
df use-def / def-use chains: 0.11 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%)
wall 0 kB ( 0%) ggc
df reg dead/unused notes: 0.44 ( 0%) usr 0.00 ( 0%) sys 0.45 ( 0%) wall
2460 kB ( 1%) ggc
register information : 0.11 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall
0 kB ( 0%) ggc
alias analysis: 0.30 ( 0%) usr 0.00 ( 0%) sys 0.31 ( 0%) wall
2816 kB ( 1%) ggc
alias stmt walking: 205.44 (72%) usr 1.33 (58%) sys 207.39 (72%) wall
7023 kB ( 3%) ggc
register scan : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall
0 kB ( 0%) ggc
rebuild jump labels : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.13 ( 0%) wall
0 kB ( 0%) ggc
parser: 0.44 ( 0%) usr 0.03 ( 1%) sys 0.47 ( 0%) wall
20481 kB ( 8%) ggc
inline heuristics : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.09 ( 0%) wall
0 kB ( 0%) ggc
tree gimplify : 0.16 ( 0%) usr 0.01 ( 0%) sys 0.18 ( 0%) wall
17257 kB ( 6%) ggc
tree eh : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
0 kB ( 0%) ggc
tree CFG construction : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall
5915 kB ( 2%) ggc
tree CFG cleanup : 1.08 ( 0%) usr 0.02 ( 1%) sys 1.15 ( 0%) wall
602 kB ( 0%) ggc
tree VRP : 0.44 ( 0%) usr 0.00 ( 0%) sys 0.45 ( 0%) wall
4778 kB ( 2%) ggc
tree copy propagation : 0.23 ( 0%) usr 0.01 ( 0%) sys 0.25 ( 0%) wall
75 kB ( 0%) ggc
tree find ref. vars : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
865 kB ( 0%) ggc
tree PTA : 2.31 ( 1%) usr 0.06 ( 3%) sys 2.38 ( 1%) wall
2253 kB ( 1%) ggc
tree PHI insertion: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
2203 kB ( 1%) ggc
tree SSA rewrite : 3.08 ( 1%) usr 0.01 ( 0%) sys 5.10 ( 2%) wall
6503 kB ( 2%) ggc
tree SSA other: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall
32 kB ( 0%) ggc
tree SSA incremental : 6.20 ( 2%) usr 0.03 ( 1%) sys 7.43 ( 3%) wall
1372 kB ( 1%) ggc
tree operand scan : 0.13 ( 0%) usr 0.10 ( 4%) sys 0.19 ( 0%) wall
13430 kB ( 5%) ggc
dominator optimization: 0.40 ( 0%) usr 0.01 ( 0%) sys 0.41 (
[Bug c/24581] Complex arithmetic on special cases is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581
marco atzeri marco_atzeri at yahoo dot it changed:
What|Removed |Added
CC||marco_atzeri at yahoo dot
||it
--- Comment #11 from marco atzeri marco_atzeri at yahoo dot it 2010-11-21
19:48:40 UTC ---
the compiler produce incorrect output also when multiplying
pure complex numbers (but not adding them).
Using gcc (GCC) 4.5.1 20100924 (Red Hat 4.5.1-4) on x86_64
The outcome of the following code is
(inf,0)
(-nan,inf)
(inf,-nan)
instead of the expected
(inf,0)
(0,inf)
(inf,0)
---
#include iostream
#include complex
using namespace std;
int main()
{
complexdouble z;
complexdouble z2;
complexdouble z3;
double a = 0;
double b = 1. / a;
z = complexdouble (b,a);
z2 = complexdouble (0,1);
z3 = complexdouble (1,0);
std::cout z '\n';
z2 = z * z2 ;
std::cout z2 '\n';
z3 = z * z3 ;
}
[Bug bootstrap/46528] [4.6 Regression] profiledbootstrap failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46528 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||rguenth at gcc dot gnu.org --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2010-11-21 20:00:33 UTC --- It is caused by revision revision 164986: http://gcc.gnu.org/ml/gcc-cvs/2010-10/msg00168.html
[Bug testsuite/46593] FAIL: gcc.dg/pr46571.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46593 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Richard Henderson rth at gcc dot gnu.org 2010-11-21 20:34:30 UTC --- Sorry, the testcase should have included -w.
[Bug tree-optimization/46590] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-21 18:56:58 UTC --- Please strip down the testcase and provide -ftime-report output (I suppose you hit IVOPTs slowness, so try -fno-ivopts).
[Bug tree-optimization/46583] [4.6 Regression] -fcompare-debug failure with -O -fno-inline -fipa-cp -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46583 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Component|debug |tree-optimization --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-21 20:46:37 UTC --- Looks like a sledgehammer. Why does nonlocalize state depends on debug info?
[Bug tree-optimization/46590] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #7 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-11-21 21:07:08 UTC --- Created attachment 22478 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22478 Test case from comment #5 and comment #6 Here is a test case that is a little shorter. A bit hard to trim it down further when the bug depends on test case size...
[Bug testsuite/46593] New: FAIL: gcc.dg/pr46571.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46593 Summary: FAIL: gcc.dg/pr46571.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: r...@gcc.gnu.org On Linux/ia32, I got FAIL: gcc.dg/pr46571.c (test for excess errors) Excess errors: /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/pr46571.c:84:45: warning: assignment from incompatible pointer type [enabled by default] /export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gcc.dg/pr46571.c:87:14: warning: initialization makes pointer from integer without a cast [enabled by default]
[Bug tree-optimization/46590] [4.6 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Known to work||4.4.1 Summary|long compile time with -O2 |[4.6 Regression] long |and many loops |compile time with -O2 and ||many loops Known to fail||4.6.0 --- Comment #8 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-11-21 21:13:24 UTC --- 4.4 compile time is much lower: i...@linux-fd1f:~/Krempel/Dep-c time /usr/bin/gfortran-4.4 -O2 gener-4.f90 real0m59.893s user0m58.172s sys 0m0.664s
[Bug tree-optimization/46590] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-11-21
19:48:41 UTC ---
Without -fno-ivopts:
i...@linux-fd1f:~/Krempel/Dep-c time
~/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 -ftime-report -O2
gener-4.f90
MAIN__ main
Analyzing compilation unit
{GC 44026k - 25146k}Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups {GC 37683k - 36011k}
whole-program ipa-profile cp inline pure-const static-varAssembling
functions:
MAIN__ {GC 54739k - 37948k} {GC 61997k - 51931k} {GC 77889k - 51575k} {GC
75220k - 51694k} {GC 89661k - 77264k} {GC 500191k - 73724k} {GC 106651k -
72832k} main
Execution times (seconds)
garbage collection: 1.05 ( 0%) usr 0.03 ( 2%) sys 1.09 ( 0%) wall
0 kB ( 0%) ggc
callgraph construction: 0.06 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall
2465 kB ( 0%) ggc
callgraph optimization: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
2 kB ( 0%) ggc
ipa pure const: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall
0 kB ( 0%) ggc
cfg construction : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall
0 kB ( 0%) ggc
cfg cleanup : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall
344 kB ( 0%) ggc
CFG verifier : 1.35 ( 0%) usr 0.00 ( 0%) sys 1.35 ( 0%) wall
0 kB ( 0%) ggc
trivially dead code : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall
0 kB ( 0%) ggc
df scan insns : 0.17 ( 0%) usr 0.01 ( 1%) sys 0.18 ( 0%) wall
0 kB ( 0%) ggc
df multiple defs : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall
0 kB ( 0%) ggc
df reaching defs : 2.04 ( 1%) usr 0.01 ( 1%) sys 2.11 ( 1%) wall
0 kB ( 0%) ggc
df live regs : 1.02 ( 0%) usr 0.00 ( 0%) sys 1.06 ( 0%) wall
0 kB ( 0%) ggc
df liveinitialized regs: 0.29 ( 0%) usr 0.01 ( 1%) sys 0.24 ( 0%) wall
0 kB ( 0%) ggc
df use-def / def-use chains: 0.12 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%)
wall 0 kB ( 0%) ggc
df reg dead/unused notes: 0.43 ( 0%) usr 0.00 ( 0%) sys 0.43 ( 0%) wall
2460 kB ( 0%) ggc
register information : 0.10 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall
0 kB ( 0%) ggc
alias analysis: 0.30 ( 0%) usr 0.00 ( 0%) sys 0.33 ( 0%) wall
2816 kB ( 0%) ggc
alias stmt walking: 192.54 (71%) usr 0.22 (16%) sys 193.02 (71%) wall
7023 kB ( 1%) ggc
register scan : 0.06 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall
20 kB ( 0%) ggc
rebuild jump labels : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.12 ( 0%) wall
0 kB ( 0%) ggc
parser: 0.43 ( 0%) usr 0.03 ( 2%) sys 0.47 ( 0%) wall
20481 kB ( 3%) ggc
inline heuristics : 0.09 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 0%) wall
0 kB ( 0%) ggc
tree gimplify : 0.16 ( 0%) usr 0.02 ( 1%) sys 0.19 ( 0%) wall
17257 kB ( 3%) ggc
tree eh : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall
0 kB ( 0%) ggc
tree CFG construction : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall
5915 kB ( 1%) ggc
tree CFG cleanup : 1.06 ( 0%) usr 0.01 ( 1%) sys 1.07 ( 0%) wall
602 kB ( 0%) ggc
tree VRP : 0.40 ( 0%) usr 0.01 ( 1%) sys 0.37 ( 0%) wall
4754 kB ( 1%) ggc
tree copy propagation : 0.23 ( 0%) usr 0.00 ( 0%) sys 0.22 ( 0%) wall
75 kB ( 0%) ggc
tree find ref. vars : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
865 kB ( 0%) ggc
tree PTA : 2.24 ( 1%) usr 0.06 ( 4%) sys 2.30 ( 1%) wall
2253 kB ( 0%) ggc
tree PHI insertion: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall
2203 kB ( 0%) ggc
tree SSA rewrite : 3.18 ( 1%) usr 0.00 ( 0%) sys 2.75 ( 1%) wall
6503 kB ( 1%) ggc
tree SSA other: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall
32 kB ( 0%) ggc
tree SSA incremental : 6.64 ( 2%) usr 0.01 ( 1%) sys 6.73 ( 2%) wall
1372 kB ( 0%) ggc
tree operand scan : 0.17 ( 0%) usr 0.09 ( 7%) sys 0.28 ( 0%) wall
13590 kB ( 2%) ggc
dominator optimization: 0.38 ( 0%) usr 0.01 ( 1%) sys 0.40 ( 0%) wall
22013 kB ( 3%) ggc
tree SRA : 0.09 ( 0%) usr 0.02 ( 1%) sys 0.15 ( 0%) wall
11123 kB ( 2%) ggc
tree CCP : 0.45 ( 0%) usr 0.02 ( 1%) sys 0.43 ( 0%) wall
838 kB ( 0%) ggc
tree
[Bug target/9468] [HP-UX] 3.2.1 ICE building libgcc muldi3.o when dwarf2 is enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9468 --- Comment #17 from John David Anglin danglin at gcc dot gnu.org 2010-11-21 21:45:26 UTC --- Author: danglin Date: Sun Nov 21 21:45:22 2010 New Revision: 167013 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167013 Log: PR target/9468 * configure.ac: Ignore --with-dwarf2 option on 32-bit hppa*-*-hpux*. * configure: Rebuild. Modified: trunk/gcc/ChangeLog trunk/gcc/configure trunk/gcc/configure.ac
[Bug target/9468] [HP-UX] 3.2.1 ICE building libgcc muldi3.o when dwarf2 is enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9468 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #18 from John David Anglin danglin at gcc dot gnu.org 2010-11-21 21:49:59 UTC --- Fixed.
[Bug c/24581] Complex arithmetic on special cases is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-21 22:15:32 UTC --- Note that this specific PR is about *C* not C++. And the issue is supposed to be RESOLVED FIXED. Thus, I would suggest first trying to reproduce the problem in C too and then either reopen this one or a C++ version (search Bugzilla first for duplicates).
[Bug c++/46589] struct member function not declared global
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46589 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-21 22:16:34 UTC --- Let's close this then.
[Bug fortran/46594] New: [4.6 regression] libquadmath intrudes generic (file system) namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46594 Summary: [4.6 regression] libquadmath intrudes generic (file system) namespace Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: ger...@pfeifer.com libquadmath is now installed by default and installs two includes files, specifically include/quadmath.h include/quadmath_weak.h This means one cannot install several versions of GCC into the same prefix (using --program-suffix, --libdir, and --libexecdir) any more, a regression.
[Bug fortran/46594] [4.6] libquadmath intrudes generic (file system) namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46594
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Summary|[4.6 regression]|[4.6] libquadmath intrudes
|libquadmath intrudes|generic (file system)
|generic (file system) |namespace
|namespace |
--- Comment #1 from kargl at gcc dot gnu.org 2010-11-21 22:57:51 UTC ---
This is not a regression. Although I agree that it is perhaps better
to install the headers into lib/gcc/${TARGET}/4.6.0/include.
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #27 from Jan Hubicka hubicka at gcc dot gnu.org 2010-11-21 23:02:20 UTC --- Author: hubicka Date: Sun Nov 21 23:02:15 2010 New Revision: 167014 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=167014 Log: PR target/46510 * tree-emutls.c (get_emutls_init_templ_addr, new_emutls_decl): Do not finalize external decls. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-emutls.c
[Bug fortran/46594] [4.6] libquadmath intrudes generic (file system) namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46594 Gerald Pfeifer gerald at pfeifer dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.21 23:06:03 Ever Confirmed|0 |1 --- Comment #2 from Gerald Pfeifer gerald at pfeifer dot com 2010-11-21 23:06:03 UTC --- It _is_ a regression in that it breaks a (generally agreed upon) desirable characteristic of GCC installations. It is not a regression within libquadmath, but one caused by libquadmath at a global level.
[Bug rtl-optimization/46556] Code size regression in struct access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556 --- Comment #1 from Alan Modra amodra at gmail dot com 2010-11-21 23:09:13 UTC --- I believe this code size regression is due to the fix for #32698. Before that change, gcc calculated the offset for accessing the array elements as n*4 64+n*4 128+n*4 After, we get n*4 (n+16)*4 (n+32)*4 and cse doesn't see the optimization opportunity.
[Bug tree-optimization/46590] [4.6 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug c++/46589] struct member function not declared global
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46589
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2010-11-21
23:14:45 UTC ---
There might still be a bug here, just not demonstrated very well by the
original testcase. Here's a version where the definitions of S agree, but gcc
still defines S::f as local and so the program fails to link:
// file1.cc
typedef struct { int f(); } S;
int main()
{
S s;
return s.f();
}
// file2.cc
typedef struct { int f(); } S;
int S::f() { return 0; }
I'm not sure if [basic.link] paragraph 5 means S::f should have external
linkage or not. Paragraph 4 (third bullet) means that S has external linkage.
Paragraph 5 refers to the name of the class and in this case the class has no
name, but it has the typedef name for linkage purposes. I'm not sure if that
means S::f should or should not have external linkage.
[Bug c/24581] Complex arithmetic on special cases is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581 --- Comment #13 from marco atzeri marco_atzeri at yahoo dot it 2010-11-21 23:16:45 UTC --- (In reply to comment #12) Note that this specific PR is about *C* not C++. And the issue is supposed to be RESOLVED FIXED. Thus, I would suggest first trying to reproduce the problem in C too and then either reopen this one or a C++ version (search Bugzilla first for duplicates). Sorry Paolo, I am a bit confused. If the bug is RESOLVED FIXED why on 4.5.1 the outcome of the original program is still -0.00e+00 0.00e+00 nan inf
[Bug c/24581] Complex arithmetic on special cases is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-21 23:22:25 UTC --- Yes I'm also a bit puzzled, either is just expected behavior or isn't really fixed ;) Myself I was surprised to see you just adding something to the audit trail as if it was just yet another testcase. Anyway, in the meanwhile I double checked that C does exactly the same (in the C++ front-end we have a completely similar piece of code, I'm not surprised), thus let's add in CC Joseph, and ask his opinion before re-opening.
[Bug c/24581] Complex arithmetic on special cases is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581 --- Comment #15 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-11-21 23:33:48 UTC --- For the original program I get -0.00e+00 -0.00e+00 -nan inf which appears correct (if one part of a complex number is an infinity, anything is valid for the other part and the overall value is still an infinity).
[Bug c/24581] Complex arithmetic on special cases is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581 --- Comment #16 from Steve Kargl sgk at troutmask dot apl.washington.edu 2010-11-21 23:43:10 UTC --- On Sun, Nov 21, 2010 at 11:34:46PM +, joseph at codesourcery dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581 --- Comment #15 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-11-21 23:33:48 UTC --- For the original program I get -0.00e+00 -0.00e+00 -nan inf which appears correct (if one part of a complex number is an infinity, anything is valid for the other part and the overall value is still an infinity). The '-nan inf' is incorrect. The correct answer is '0 inf'.
[Bug libgomp/46595] New: libquadmath.0.dylib image not found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46595 Summary: libquadmath.0.dylib image not found Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: i686-apple-darwin9 Target: i686-apple-darwin9 Build: i686-apple-darwin9 The new libquadmath causes many libgomp testsuite failures. For example, Executing on host: /Users/dave/gnu/gcc/objdir/gcc/xgcc -B/Users/dave/gnu/gcc/obj dir/gcc/ /Users/dave/gnu/gcc/gcc/libgomp/testsuite/libgomp.fortran/allocatable1. f90 -B/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/./libgomp/ -B/Users/dave/gn u/gcc/objdir/i686-apple-darwin9/./libgomp/.libs -I/Users/dave/gnu/gcc/objdir/i68 6-apple-darwin9/./libgomp -I/Users/dave/gnu/gcc/gcc/libgomp/testsuite/.. -march= i486 -shared-libgcc -fmessage-length=0 -fopenmp -O0 -B/Users/dave/gnu/gcc/obj dir/i686-apple-darwin9/./libgomp/../libgfortran/.libs -L/Users/dave/gnu/gcc/ob jdir/i686-apple-darwin9/./libgomp/.libs -lgomp -L/Users/dave/gnu/gcc/objdir/i686 -apple-darwin9/./libgomp/../libgfortran/.libs -lgfortran -lm -o ./allocatable1 .exe(timeout = 300) PASS: libgomp.fortran/allocatable1.f90 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/./lib gomp/.libs:/Users/dave/gnu/gcc/objdir/gcc:/Users/dave/gnu/gcc/objdir/i686-apple- darwin9/./libgomp/../libgfortran/.libs:.:/Users/dave/gnu/gcc/objdir/i686-apple-d arwin9/./libgomp/.libs:/Users/dave/gnu/gcc/objdir/gcc:/Users/dave/gnu/gcc/objdir /i686-apple-darwin9/./libgomp/../libgfortran/.libs dyld: Library not loaded: /opt/gnu/gcc/gcc-4.6.0/lib/libquadmath.0.dylib Referenced from: /Users/dave/gnu/gcc/objdir/i686-apple-darwin9/./libgomp/../li bgfortran/.libs/libgfortran.3.dylib Reason: image not found FAIL: libgomp.fortran/allocatable1.f90 -O0 execution test It looks like LD_LIBRARY_PATH needs adjustment.
[Bug c/24581] Complex arithmetic on special cases is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581 --- Comment #17 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-11-21 23:53:10 UTC --- On Sun, 21 Nov 2010, sgk at troutmask dot apl.washington.edu wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581 --- Comment #16 from Steve Kargl sgk at troutmask dot apl.washington.edu 2010-11-21 23:43:10 UTC --- On Sun, Nov 21, 2010 at 11:34:46PM +, joseph at codesourcery dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581 --- Comment #15 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-11-21 23:33:48 UTC --- For the original program I get -0.00e+00 -0.00e+00 -nan inf which appears correct (if one part of a complex number is an infinity, anything is valid for the other part and the overall value is still an infinity). The '-nan inf' is incorrect. The correct answer is '0 inf'. Annex G does not define the results for complex*complex multiplication to that level of detail, and for the complex*real multiplication we have here it seems entirely correct to have a NaN (sign unspecified) as the real part.
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #28 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-22 00:03:38 UTC --- Fixed at r167014.
[Bug c/24581] Complex arithmetic on special cases is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581 --- Comment #18 from Steve Kargl sgk at troutmask dot apl.washington.edu 2010-11-22 00:05:02 UTC --- On Sun, Nov 21, 2010 at 11:53:50PM +, joseph at codesourcery dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581 Annex G does not define the results for complex*complex multiplication to that level of detail, and for the complex*real multiplication we have here it seems entirely correct to have a NaN (sign unspecified) as the real part. We've had this discussion before. Annex G, which I do acknowledge as informative, states: The * and / operators satisfy the following infinity properties for all real, imaginary, and complex operands:319) -- if one operand is an infinity and the other operand is a nonzero finite number or an infinity, then the result of the * operator is an infinity; I'll note the above comes from n1124.pdf (page 468). Perhaps, the actual C99 standard says something else. -nan is not an infinity.
[Bug bootstrap/46451] legacy cloog-ppl test omits necessary linkage on ppl libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46451 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-22 00:05:41 UTC --- Fixed at r19/166670.
[Bug c/24581] Complex arithmetic on special cases is incorrect.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24581 --- Comment #19 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-11-22 00:11:39 UTC --- On Mon, 22 Nov 2010, sgk at troutmask dot apl.washington.edu wrote: We've had this discussion before. Annex G, which I do acknowledge as informative, states: The * and / operators satisfy the following infinity properties for all real, imaginary, and complex operands:319) -- if one operand is an infinity and the other operand is a nonzero finite number or an infinity, then the result of the * operator is an infinity; I'll note the above comes from n1124.pdf (page 468). Perhaps, the actual C99 standard says something else. -nan is not an infinity. That -nan is not an infinity is true but irrelevant, because A complex or imaginary value with at least one infinite part is regarded as an infinity (even if its other part is a NaN). (G.3), so the complex result of the multiplication *is* an infinity (with one part NaN and one part infinity, which is a valid representation of complex infinity).
[Bug c++/45845] g++.dg/pubtypes.C scan-assembler A\\\\\\\\0+[ \\t]+[#;@]+[\\t]+external name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45845 --- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-22 00:11:16 UTC --- Fiexed between r166242 and r166277.
[Bug c++/46589] struct member function not declared global
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46589
--- Comment #4 from TonyK temptony at freemail dot hu 2010-11-22 00:19:18 UTC
---
(In reply to comment #3)
There might still be a bug here, just not demonstrated very well by the
original testcase. Here's a version where the definitions of S agree, but gcc
still defines S::f as local and so the program fails to link:
// file1.cc
typedef struct { int f(); } S;
int main()
{
S s;
return s.f();
}
// file2.cc
typedef struct { int f(); } S;
int S::f() { return 0; }
This is exactly the same as my original submission, isn't it?
[Bug c++/46589] struct member function not declared global
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46589 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2010.11.22 01:39:44 Resolution|INVALID | Ever Confirmed|0 |1 Severity|minor |normal --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-22 01:39:44 UTC --- Oops, let's reopen this.
[Bug c/46596] New: misbehavior when mixing always_inline and alias attributes in the same compilation unit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46596
Summary: misbehavior when mixing always_inline and alias
attributes in the same compilation unit
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vap...@gentoo.org
i have a function foo. its header sets up an always_inline function that
does sanity checks when constants are involved. otherwise it delays the
non-constant checking to another function. here is the portion from the
header:
extern void foo(int i);
extern void __in(int i);
extern inline __attribute__((always_inline))
void foo(int i) { __in(i); }
where i actually define foo, there is an alias used to setup multiple
symbols. also in that file is another function which calls the inline checking
function. together, gcc barfs. here is the portion of the file:
void bar(int i) { foo(i + 1234); }
void __foo(int i) {}
extern typeof(__foo) foo __attribute__((alias(__foo)));
combine them into one and compile like so (this is 4.5.1):
gcc -O2 -c test.c -std=gnu99 -fgnu89-inline -Winline
this produces the error:
test.c: In function ‘bar’:
test.c:18:22: sorry, unimplemented: inlining failed in call to ‘foo’: function
body not available
test.c:14:5: sorry, unimplemented: called from here
that doesnt seem right since the function body *is* available. if i split the
__foo/foo definitions into their own dedicated file, then everything compiles
just fine as i'd expect.
what's even more odd though is that -Winline affects code generation. if you
compile without that flag, you dont get any errors, but the generated code is
wrong:
gcc -O2 -c test.c -std=gnu99 -fgnu89-inline
objdump -dr test.o
...
bar:
0: 81 c7 d2 04 00 00 add$0x4d2,%edi
6: e9 00 00 00 00 jmpq b bar+0xb
7: R_X86_64_PC32foo-0x4
b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1)
...
clearly it's just jumping straight to the definition of foo rather than going
through the inline function.
doesnt seem to be a regression ... every gcc version ive tested fails in the
same way: 4.0.4, 4.1.2, 4.2.4, 4.3.5, 4.4.4, 4.5.1. versions before 4.2.x had
the -fgnu89-inline flag dropped since that was the default behavior and so was
unnecessary (and unrecognized).
[Bug c/46596] misbehavior when mixing always_inline and alias attributes in the same compilation unit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46596 --- Comment #1 from Mike Frysinger vapier at gentoo dot org 2010-11-22 03:49:52 UTC --- Created attachment 22479 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22479 example file
[Bug target/45261] Doesn't indicate failure status when it doesn't support (attiny2313A)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45261 --- Comment #5 from Ian Rees ian.rees at gmail dot com 2010-11-22 04:57:57 UTC --- Created attachment 22480 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22480 Simple fix for bug #45621 Simple patch against gcc-4.5.1 - just adds a call to Error(), which is more appropriate than the current implementation.
[Bug target/45261] Doesn't indicate failure status when it doesn't support (attiny2313A)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45261 Ian Rees ian.rees at gmail dot com changed: What|Removed |Added CC||ian.rees at gmail dot com --- Comment #6 from Ian Rees ian.rees at gmail dot com 2010-11-22 05:00:05 UTC --- Here's a patch to implement change suggested above - added call to error(). I left in the existing fprintf() thinking that the list of supported MCUs is useful.
[Bug fortran/46594] [4.6] libquadmath intrudes generic (file system) namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46594 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org Target Milestone|--- |4.6.0
