[Bug target/44617] Serial Output on the atmega1280 does not work
--- Comment #11 from westfw at yahoo dot com 2010-08-22 07:18 --- Created an attachment (id=21541) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21541action=view) Suggested patch Tested with the example. Not thoroughly tested, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617
[Bug target/44617] Serial Output on the atmega1280 does not work
--- Comment #12 from westfw at yahoo dot com 2010-08-22 07:21 --- See http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopicp=736616 This is (IMO) a bug in the __do_global_ctors in gcc/config/avr/libgcc.S When support for 24-bit flash pointers was added in edit http://gcc.gnu.org/viewcvs?view=revisionrevision=143306 R20 was used to hold the extra 8 bits of address. But R20 is NOT preserved by called functions according to the AVR C calling conventions, and indeed the class initialization code ends up using R20 if there are sufficient fields to initialize. The attached patch uses R15 instead, and appears to work, but I'm not sure of the implications... I tried to change the summary, but of course it won't let me. I think this is a more serious problem than the initial problem indicates... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617
[Bug c/45152] LTO breaks C99 inline
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-08-22 07:38 --- This is because C frontend implements this by calling cgraph_mark_node_if_needed and the function ends up not being needed for LTO or whole program. This is a hack, since even if I make things needed, whole program will then be penalized. How this function is different from GNU C inline int f() alone? If it is equivalent, is there some chance that C frontend would set the flags same way? (I.e. not setting EXTERN flag on the function) -- hubicka at gcc dot gnu dot org changed: What|Removed |Added CC||jason at redhat dot com, ||joseph at codesourcery dot ||com Component|lto |c Last reconfirmed|2010-08-01 12:29:48 |2010-08-22 07:38:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45152
[Bug bootstrap/45372] warning coverage.c assigns -1 to unsigned, suggest -1u
--- Comment #2 from schwab at linux-m68k dot org 2010-08-22 08:16 --- Assigning -1 to an unsigned type is always safe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45372
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
--- Comment #13 from burnus at gcc dot gnu dot org 2010-08-22 08:34 --- Subject: Bug 36158 Author: burnus Date: Sun Aug 22 08:34:14 2010 New Revision: 163454 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163454 Log: 2010-08-22 Tobias Burnus bur...@net-b.de Dominique d'Humieres domi...@lps.ens.fr PR fortran/45367 PR fortran/36158 * gfortran.dg/bessel_6.f90: Increase numeric tolerence. * gfortran.dg/bessel_7.f90: Increase numeric tolerence. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bessel_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158
[Bug fortran/45367] FAIL: gfortran.dg/bessel_6.f90 and gfortran.dg/bessel_7.f90
--- Comment #3 from burnus at gcc dot gnu dot org 2010-08-22 08:34 --- Subject: Bug 45367 Author: burnus Date: Sun Aug 22 08:34:14 2010 New Revision: 163454 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163454 Log: 2010-08-22 Tobias Burnus bur...@net-b.de Dominique d'Humieres domi...@lps.ens.fr PR fortran/45367 PR fortran/36158 * gfortran.dg/bessel_6.f90: Increase numeric tolerence. * gfortran.dg/bessel_7.f90: Increase numeric tolerence. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bessel_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45367
[Bug fortran/36158] Transformational function BESSEL_YN(n1,n2,x) and BESSEL_JN missing
--- Comment #14 from burnus at gcc dot gnu dot org 2010-08-22 08:40 --- Subject: Bug 36158 Author: burnus Date: Sun Aug 22 08:39:48 2010 New Revision: 163455 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163455 Log: 2010-08-22 Tobias Burnus bur...@net-b.de PR fortran/36158 * gfortran.dg/bessel_7.f90: Disable accidently enabled debug output. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bessel_7.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36158
[Bug c++/45374] New: template keyword incorrectness// failure to parse valid code.
gcc incorrectly handles the following code. The underlying problem is that gcc
does not require the template keyword in certain places where it should
require it. The side effect is that gcc refuses to parse valid code that looks
like a template parameter list but really is not. The first templated function
call in the main() should be rejected by gcc because the template keyword
should be required. The second templated function call is rejected but should
be accepted because it's parseable as a combination of and operators
and makes sense in that way (Visual Studio accepts this code, again
incorrectly; presumably it does not construct a single parse tree).
merlin:~: gcc tmp.cc
tmp.cc: In function 'int MyTemplatedFunction() [with A = char, int B = 6]':
tmp.cc:29: instantiated from here
tmp.cc:23: error: 'MyClass6' is not a base of 'MyDerivedClasschar, 6'
--
#include iostream
templateint B class MyClass {
public:
int MyFunc() {return B;}
};
templateclass A, int B class MyDerivedClass: public MyClassB {
public:
int MyFunc() {return 1;}
};
templateint B class MyDerivedClasschar, B {
public:
int MyClass;
MyDerivedClass(): MyClass(10) {}
};
int MyFunc() { return 5; }
templateclass A, int B int MyTemplatedFunction() {
MyDerivedClassA,B *ptr = new MyDerivedClassA,B;
return ptr-MyClassB::MyFunc();
// should be ptr-template MyClassB::MyFunc()
// to be parsed as template, but gcc does not require this.
}
int main()
{
std::cout First time: MyTemplatedFunctionint,6() std::endl;
std::cout Next time: MyTemplatedFunctionchar,6() std::endl;
while(1);
return 0;
}
--
Summary: template keyword incorrectness// failure to parse valid
code.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpovey at gmail dot com
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45374
[Bug bootstrap/45372] warning coverage.c assigns -1 to unsigned, suggest -1u
--- Comment #3 from jay dot krell at cornell dot edu 2010-08-22 08:56 --- Best imho to put in the cast to quash the warning. To be warning free -- esp. given how close you already are. Sometimes I think warning-free across a range of compilers is untenable. But you are in fact already very close. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45372
[Bug lto/45194] lto1: internal compiler error: in lto_varpool_replace_node, at lto-symtab.c:292
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-08-22 09:15 --- It works for me on clean tree at today mainline. + ../xgcc -B .. -fPIC -fno-exceptions -fwhopr=24 -fuse-linker-plugin -fno-strict-aliasing -pthread -pipe -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer -c sysunix.i + ../xgcc -B .. -fPIC -fno-exceptions -fwhopr=24 -fuse-linker-plugin -fno-strict-aliasing -pthread -pipe -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer -c editline.i + ../g++ -B .. -L ../../x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/ -fPIC -fno-exceptions -fwhopr=24 -fuse-linker-plugin -fno-strict-aliasing -pthread -pipe -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer -c -fno-rtti -fpermissive -Wno-invalid-offsetof js.ii + ../g++ -B .. -L ../../x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/ -fPIC -fno-exceptions -fwhopr=24 -fuse-linker-plugin -fno-strict-aliasing -pthread -pipe -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer -c -fno-rtti -fpermissive -Wno-invalid-offsetof jsworkers.ii + ../g++ -B .. -L ../../x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/ -o js -fPIC -fno-exceptions -fwhopr=24 -fuse-linker-plugin -fno-strict-aliasing -pthread -pipe -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer js.o jsworkers.o editline.o sysunix.o -lpthread -Wl,-rpath-link,/bin -Wl,-rpath-link,/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm /abuild/jh/trunk-install/x86_64-unknown-linux-gnu/bin/ld: /tmp/ccqrfzic.ltrans0.ltrans.o: in function _ZL18split_getObjectOpsP9JSContextP7JSClass.5202.4730:ccqrfzic.ltrans0.o(.text+0x2f): error: undefined reference to 'js_ObjectOps' /abuild/jh/trunk-install/x86_64-unknown-linux-gnu/bin/ld: /tmp/ccqrfzic.ltrans0.ltrans.o: in function _ZL22ShellOperationCallbackP9JSContext.4851.5014:ccqrfzic.ltrans0.o(.text+0xb1): error: undefined reference to 'JS_ClearPendingException' /abuild/jh/trunk-install/x86_64-unknown-linux-gnu/bin/ld: /tmp/ccqrfzic.ltrans0.ltrans.o: in function _ZN8ToStringC2EP9JSContextli.local.285.constprop.348.3463:ccqrfzic.ltrans0.o(.text+0xd4): error: undefined reference to 'JS_ValueToString' Can you double check if it works for you too? Might be also gold bug. Mine is: j...@evans:/abuild/jh/trunk-2/gcc gold --version GNU gold (GNU Binutils; SUSE Linux Enterprise 11 2.20.0.20100122-0.7.9) 1.9 Copyright 2008 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added CC||tglek at mozilla dot com Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45194
[Bug lto/45375] New: Mozilla does not build with LTO
Metabug to track all the issues ;) -- Summary: Mozilla does not build with LTO Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hubicka at gcc dot gnu dot org GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
[Bug fortran/45367] FAIL: gfortran.dg/bessel_6.f90 and gfortran.dg/bessel_7.f90
--- Comment #4 from burnus at gcc dot gnu dot org 2010-08-22 10:10 --- Subject: Bug 45367 Author: burnus Date: Sun Aug 22 10:09:34 2010 New Revision: 163457 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163457 Log: Really commit the following change: 2010-08-22 Tobias Burnus bur...@net-b.de Dominique d'Humieres domi...@lps.ens.fr PR fortran/45367 * gfortran.dg/bessel_6.f90: Increase numeric tolerence. Modified: trunk/gcc/testsuite/gfortran.dg/bessel_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45367
[Bug bootstrap/45376] New: no such instruction: `pcmpestri $0,(%rdi),%xmm0'
Updating today at revision 163455 gave : /home/mik/gcc46/src/libcpp/lex.c: Assembler messages: /home/mik/gcc46/src/libcpp/lex.c:448: Error: no such instruction: `pcmpestri $0,(%rdi),%xmm0' /home/mik/gcc46/src/libcpp/lex.c:432: Error: no such instruction: `pcmpestri $0,(%rdi),%xmm0' A revision from yesterday worked (2010-08-21), but I don't remember the revision number. Possible culprit according to the ChangeLog : revision 163446. -- Summary: no such instruction: `pcmpestri $0,(%rdi),%xmm0' Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikael at gcc dot gnu dot org GCC build triplet: x86_64-unknown-freebsd8.0 GCC host triplet: x86_64-unknown-freebsd8.0 GCC target triplet: x86_64-unknown-freebsd8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45376
[Bug fortran/45367] FAIL: gfortran.dg/bessel_6.f90 and gfortran.dg/bessel_7.f90
--- Comment #5 from burnus at gcc dot gnu dot org 2010-08-22 10:25 --- Subject: Bug 45367 Author: burnus Date: Sun Aug 22 10:24:49 2010 New Revision: 163458 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163458 Log: 2010-08-22 Tobias Burnus bur...@net-b.de PR fortran/45367 * gfortran.dg/bessel_6.f90: Fix numeric tolerence. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bessel_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45367
[Bug bootstrap/45376] no such instruction: `pcmpestri $0,(%rdi),%xmm0'
--- Comment #1 from mikael at gcc dot gnu dot org 2010-08-22 10:33 --- (In reply to comment #0) Possible culprit according to the ChangeLog : revision 163446. confirmed: r163446 _is_ the culprit. The stage1 libcpp builds fine. The failure is at stage2. Configure line: $ /home/mik/gcc46/src/configure --prefix=/home/mik/gcc46 --enable-maintainer-mode --disable-multilib --enable-languages=fortran -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45376
[Bug libgcj/45377] New: java-signal.h warning: declaration 'class java::lang::Throwable' does not declare anything
warning, not error Sorry I lost further details, but probably this was on OSF/1. ./include/java-signal.h:26:19: warning: declaration 'class java::lang::Throwable' does not declare anything -- Summary: java-signal.h warning: declaration 'class java::lang::Throwable' does not declare anything Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jay dot krell at cornell dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45377
[Bug bootstrap/45376] no such instruction: `pcmpestri $0,(%rdi),%xmm0'
--- Comment #2 from mikael at gcc dot gnu dot org 2010-08-22 10:49 --- This might be of interest: the machine I'm running on as reported by the kernel. CPU: AMD Athlon(tm) 64 Processor 3000+ (2009.79-MHz K8-class CPU) Origin = AuthenticAMD Id = 0xfc0 Stepping = 0 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe0500800SYSCALL,NX,MMX+,LM,3DNow!+,3DNow! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45376
[Bug fortran/45366] Problem with abstract interface to PURE function
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-22 10:50 --- Confirmed. Thanks for reporting. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2010-08-22 10:50:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45366
[Bug fortran/45366] Problem with abstract interface to PURE function
--- Comment #2 from burnus at gcc dot gnu dot org 2010-08-22 11:02 --- Note: The ABSTRACT, the INTERFACE (vs. host-association), and the use-association of i_f do not seem to play a role. In particular for p: sym-attr.pure == 0 sym-attr.proc_pointer == 1 sym-ts.interface-attr.pure == 1 The problems seems to be that resolve_symbol is called later than the resolve_formal_arglist check for pureness, i.e. one first checks whether p is pure before one copies the attr.pure from ts.interface-attr.pure - which explains the failure. I leave the fixing to Janus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45366
[Bug fortran/45366] Problem with abstract interface to PURE function
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-22 11:10 --- (In reply to comment #2) The problems seems to be that resolve_symbol is called later than the resolve_formal_arglist check for pureness, i.e. one first checks whether p is pure before one copies the attr.pure from ts.interface-attr.pure - which explains the failure. Exactly. I'm regtesting a patch right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45366
[Bug c/45152] LTO breaks C99 inline
--- Comment #3 from joseph at codesourcery dot com 2010-08-22 12:12 --- Subject: Re: LTO breaks C99 inline On Sun, 22 Aug 2010, hubicka at gcc dot gnu dot org wrote: How this function is different from GNU C inline int f() alone? If it is equivalent, is there some chance that C frontend would set the flags same way? (I.e. not setting EXTERN flag on the function) It's equivalent - once the end of the translation unit is reached. But with C99 you can have the declaration with extern or without inline, coming *after* the definition, which is what causes it to be exported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45152
Re: [Bug c/45152] LTO breaks C99 inline
It's equivalent - once the end of the translation unit is reached. But with C99 you can have the declaration with extern or without inline, coming *after* the definition, which is what causes it to be exported. OK, is there any chance to convince the frontend to make the final representation looking same (i.e. not add the DECL_EXTERN flag?). DECL_EXTERN on function across cgraph code is always understood as extern inline and having such function marked as needed is a paradox. Visibility pass already does quite some flags sanitization, so we might do that there, but that would imply need for cgraph to remember those functions somewhere before unit is finalized, so I would preffer frontend to do that. Honza
[Bug c/45152] LTO breaks C99 inline
--- Comment #4 from hubicka at ucw dot cz 2010-08-22 12:29 --- Subject: Re: LTO breaks C99 inline It's equivalent - once the end of the translation unit is reached. But with C99 you can have the declaration with extern or without inline, coming *after* the definition, which is what causes it to be exported. OK, is there any chance to convince the frontend to make the final representation looking same (i.e. not add the DECL_EXTERN flag?). DECL_EXTERN on function across cgraph code is always understood as extern inline and having such function marked as needed is a paradox. Visibility pass already does quite some flags sanitization, so we might do that there, but that would imply need for cgraph to remember those functions somewhere before unit is finalized, so I would preffer frontend to do that. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45152
[Bug target/41484] Please add memory forms of pmovzx* (SSE4.1)
--- Comment #1 from baggett dot patrick at gmail dot com 2010-08-22 12:31
---
I can confirm that is a problem on GCC 4.4.3, though I was using the
Intel-style intrinsic found in the SSE4 manual.
Smallest testcase:
gcc -msse4 -m64
#include smmintrin.h
/* Read four bytes and extend to 4 ints in xmm reg. */
__m128i vint_zx8_32(unsigned char* m)
{
return _mm_cvtepu8_epi32( *((__m128i*)m) );
}
Generated Code:
vint_zx8_32:
movdqa (%rdi), %xmm0
pmovzxbd%xmm0, %xmm0
ret
Expected Code:
vint_zx8_32:
pmovzxbd(%rdi), %xmm0
ret
--
baggett dot patrick at gmail dot com changed:
What|Removed |Added
CC||baggett dot patrick at gmail
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41484
[Bug target/41484] Please add memory forms of pmovzx* (SSE4.1)
--- Comment #2 from baggett dot patrick at gmail dot com 2010-08-22 12:34 --- Created an attachment (id=21542) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21542action=view) Test case showing intrinsics not generating memory operation. Use gcc -msse4 -m64 -S testcase_41484.c to compile, view resulting assembly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41484
[Bug lto/45375] Mozilla does not build with LTO
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-08-22 12:39 --- Quick summary :) 1) -g build is currently broken because of dwarf2out recursion. 2) sqlite still gets miscompiled at 32bit (PR44897), but works now at 64bit for some reason 3) Workaround attached to PR44846 is needed to avoid ICE due to one decl C++ FE issues 4) 32bit mozilla now builds fine for me when linked with -O2, but -Os (the default) leads to segfault at startup apparently because xpcom components do not reproduce correctly 5) Older versions of gold seems to have issues. 6) Martin's devirtualization seems to behave funny doing 7400 clones and the redirecting just about 20 calls. 7) Both Martin and Taras reported ICE in lto-symtab I can't reproduce 8) Mozilla needs some changes, since __attribute__ ((used)) is missing. I will attach diff. 9) One needs 4GB in /tmp, with sane partitioning this goes down to 1GB 10) 32bit build gets close to addressing space issues at WPA stage, probably we should not mmap all the .o files, since only about 1GB goes to garbage collected memory. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added CC||mjambor at suse dot cz Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-22 12:40:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
[Bug lto/45375] Mozilla does not build with LTO
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-08-22 12:43 --- Created an attachment (id=21543) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21543action=view) Mozilla changes needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
[Bug lto/45375] Mozilla does not build with LTO
--- Comment #3 from hubicka at gcc dot gnu dot org 2010-08-22 12:48 --- mozconfig I use: export CC=gcc -flto -fuse-linker-plugin export CXX=g++ -fwhopr=24 -fuse-linker-plugin -fpermissive #export CXX=/builds/slave/tryserver-linux/build/gcc/bin/g++ -fwhopr=16 #-fuse-linker-plugin -static-libstdc++ -fpermissive ac_add_options --enable-application=browser ac_add_options --enable-libxul #ac_add_options --enable-debug ac_add_options --enable-optimize ac_add_options --disable-tests #ac_add_options --enable-debug-symbols export LDFLAGS=-Wl,--no-keep-memory mk_add_options MOZ_MAKE_FLAGS=-j24 mk_add_options MOZ_OBJDIR=/build-mozilla-scratch-O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
[Bug lto/45375] Mozilla does not build with LTO
--- Comment #4 from hubicka at gcc dot gnu dot org 2010-08-22 13:10 --- WPA stage profile after (with sane partitioning). Decl reading and merging is major issue. I am surprised we are faster on streaming out than reading. Execution times (seconds) garbage collection: 5.71 ( 3%) usr 0.00 ( 0%) sys 5.72 ( 3%) wall 0 kB ( 0%) ggc callgraph optimization: 1.70 ( 1%) usr 0.00 ( 0%) sys 1.72 ( 1%) wall 13488 kB ( 0%) ggc varpool construction : 0.58 ( 0%) usr 0.01 ( 0%) sys 0.57 ( 0%) wall 43924 kB ( 1%) ggc ipa cp: 1.62 ( 1%) usr 0.02 ( 0%) sys 1.66 ( 1%) wall 70914 kB ( 2%) ggc ipa lto gimple in : 4.28 ( 2%) usr 0.33 ( 4%) sys 4.63 ( 2%) wall 15 kB ( 0%) ggc ipa lto gimple out: 6.45 ( 3%) usr 0.33 ( 4%) sys 6.74 ( 3%) wall 0 kB ( 0%) ggc ipa lto decl in : 48.34 (26%) usr 1.93 (23%) sys 50.30 (26%) wall 3021266 kB (87%) ggc ipa lto decl out : 40.53 (22%) usr 0.19 ( 2%) sys 40.75 (21%) wall 0 kB ( 0%) ggc ipa lto decl init I/O : 1.03 ( 1%) usr 0.06 ( 1%) sys 1.08 ( 1%) wall 77094 kB ( 2%) ggc ipa lto cgraph I/O: 0.94 ( 1%) usr 0.21 ( 3%) sys 1.15 ( 1%) wall 237872 kB ( 7%) ggc ipa lto decl merge: 45.14 (24%) usr 1.08 (13%) sys 46.23 (24%) wall 273 kB ( 0%) ggc ipa lto cgraph merge : 0.89 ( 0%) usr 0.00 ( 0%) sys 0.89 ( 0%) wall 5164 kB ( 0%) ggc whopr wpa : 2.38 ( 1%) usr 0.04 ( 0%) sys 2.41 ( 1%) wall 1 kB ( 0%) ggc whopr wpa I/O : 3.08 ( 2%) usr 3.97 (48%) sys 7.38 ( 4%) wall 0 kB ( 0%) ggc ipa reference : 1.55 ( 1%) usr 0.00 ( 0%) sys 1.59 ( 1%) wall 0 kB ( 0%) ggc ipa profile : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.18 ( 0%) wall 0 kB ( 0%) ggc ipa pure const: 1.05 ( 1%) usr 0.00 ( 0%) sys 1.04 ( 1%) wall 0 kB ( 0%) ggc parser: 0.58 ( 0%) usr 0.00 ( 0%) sys 0.58 ( 0%) wall 17738 kB ( 1%) ggc inline heuristics : 15.73 ( 8%) usr 0.00 ( 0%) sys 15.74 ( 8%) wall 2974 kB ( 0%) ggc callgraph verifier: 2.56 ( 1%) usr 0.02 ( 0%) sys 2.59 ( 1%) wall 0 kB ( 0%) ggc varconst : 0.01 ( 0%) usr 0.02 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc TOTAL : 186.41 8.27 195.10 3491946 kB -- hubicka at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|44871 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
[Bug target/45263] registers used in __do_global_ctors can get clobbered
--- Comment #3 from eric dot weddington at atmel dot com 2010-08-22 13:26 --- *** Bug 44617 has been marked as a duplicate of this bug. *** -- eric dot weddington at atmel dot com changed: What|Removed |Added CC||scott at perturb dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45263
[Bug target/44617] Serial Output on the atmega1280 does not work
--- Comment #13 from eric dot weddington at atmel dot com 2010-08-22 13:26 --- (In reply to comment #12) See http://www.avrfreaks.net/index.php?name=PNphpBB2file=viewtopicp=736616 This is (IMO) a bug in the __do_global_ctors in gcc/config/avr/libgcc.S When support for 24-bit flash pointers was added in edit http://gcc.gnu.org/viewcvs?view=revisionrevision=143306 R20 was used to hold the extra 8 bits of address. But R20 is NOT preserved by called functions according to the AVR C calling conventions, and indeed the class initialization code ends up using R20 if there are sufficient fields to initialize. The attached patch uses R15 instead, and appears to work, but I'm not sure of the implications... I tried to change the summary, but of course it won't let me. I think this is a more serious problem than the initial problem indicates... Duplicate of bug #45263. Closing this one as a dup, as the test case in bug #45263 is simpler. *** This bug has been marked as a duplicate of 45263 *** -- eric dot weddington at atmel dot com changed: What|Removed |Added CC||eric dot weddington at atmel ||dot com Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44617
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #25 from rootkit85 at yahoo dot it 2010-08-22 13:34 --- try -march=i686 it should be the best -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug c++/45378] New: Narrowing error not detected
The following code
int main()
{
int x { 22.2 };
}
includes an initialization which requires narrowing, but the code compiles fine
without any error/warning.
--
Summary: Narrowing error not detected
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: saurabh dot manchanda at yahoo dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45378
[Bug fortran/45367] FAIL: gfortran.dg/bessel_6.f90 and gfortran.dg/bessel_7.f90
--- Comment #6 from burnus at gcc dot gnu dot org 2010-08-22 14:05 --- Subject: Bug 45367 Author: burnus Date: Sun Aug 22 14:05:26 2010 New Revision: 163460 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163460 Log: 2010-08-22 Tobias Burnus bur...@net-b.de Dominique d'Humieres domi...@lps.ens.fr PR fortran/45367 * gfortran.dg/bessel_6.f90: Further reduce required accuracy. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/bessel_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45367
[Bug target/45263] registers used in __do_global_ctors can get clobbered
--- Comment #4 from ah dot linder at arcor dot de 2010-08-22 15:56 --- HelloWorld arduino sketch works now with atmega1280 gcc-4.5.1. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45263
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #22 from danglin at gcc dot gnu dot org 2010-08-22 16:23 --- Subject: Bug 34544 Author: danglin Date: Sun Aug 22 16:23:38 2010 New Revision: 163461 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163461 Log: PR boehm-gc/34544 * gthr-posix.h (__gthread_active_init): Delete. (__gthread_active_p): Do activity check here. Don't include errno.h on hppa-hpux. Update comment. * gthr-posix95.h (__gthread_active_init): Delete. (__gthread_active_p): Do activity check here. Don't include errno.h on hppa-hpux. Update comment. * config.gcc (hppa[12]*-*-hpux11*): Define extra_parts. * config/pa/pa64-hpux.h (LIB_SPEC): When -static is specified, only add -lpthread when -mt or -pthread is specified. * config/pa/pa-hpux11.h (LIB_SPEC): likewise. (LINK_GCC_C_SEQUENCE_SPEC): Define. * config/pa/t-pa-hpux11 (LIBGCCSTUB_OBJS): Define. (stublib.c, pthread_default_stacksize_np-stub.o, pthread_mutex_lock-stub.o, pthread_mutex_unlock-stub.o, $(T)libgcc_stub.a): Add methods. * config/pa/t-pa64 (LIBGCCSTUB_OBJS): Add pthread stubs. (stublib.c, pthread_default_stacksize_np-stub.o, pthread_mutex_lock-stub.o, pthread_mutex_unlock-stub.o): Add methods. * config/pa/stublib.c (pthread_default_stacksize_np, pthread_mutex_lock, pthread_mutex_unlock): New stubs. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/pa/pa-hpux11.h trunk/gcc/config/pa/pa64-hpux.h trunk/gcc/config/pa/stublib.c trunk/gcc/config/pa/t-pa-hpux11 trunk/gcc/config/pa/t-pa64 trunk/gcc/gthr-posix.h trunk/gcc/gthr-posix95.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug middle-end/45379] New: [4.6 Regression] ~10% slowdown on test_fpu at revision 163278
[macbook] lin/test% gfcp -v Using built-in specs. COLLECT_GCC=gfcp COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper Target: x86_64-apple-darwin10 Configured with: ../p_work/configure --prefix=/opt/gcc/gcc4.6p --mandir=/opt/gcc/gcc4.6p/share/man --infodir=/opt/gcc/gcc4.6p/share/info --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 --enable-languages=c,fortran --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-cloog=/opt/sw64 --with-ppl=/opt/sw64 --with-mpc=/opt/sw64 --enable-lto --enable-checking=release Thread model: posix gcc version 4.6.0 20100816 (experimental) [trunk revision 163277] (GCC) [macbook] lin/test% gfcp -Ofast -funroll-loops -fno-whole-file test_fpu.f90 [macbook] lin/test% time a.out Benchmark running, hopefully as only ACTIVE task 0.99755959009261719 Test1 - Gauss 2000 (101x101) inverts 2.0 sec Err= 0.006 Test2 - Crout 2000 (101x101) inverts 2.9 sec Err= 0.014 Test3 - Crout 2 (1001x1001) inverts 3.4 sec Err= 0.043 Test4 - Lapack 2 (1001x1001) inverts 2.6 sec Err= 0.250 total = 10.9 sec 11.080u 0.093s 0:11.18 99.9%0+0k 0+0io 0pf+0w [macbook] lin/test% gfcp -v Using built-in specs. COLLECT_GCC=gfcp COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.6p/libexec/gcc/x86_64-apple-darwin10/4.6.0/lto-wrapper Target: x86_64-apple-darwin10 Configured with: ../p_work/configure --prefix=/opt/gcc/gcc4.6p --mandir=/opt/gcc/gcc4.6p/share/man --infodir=/opt/gcc/gcc4.6p/share/info --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 --enable-languages=c,fortran --with-gmp=/opt/sw64 --with-libiconv-prefix=/opt/sw64 --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-cloog=/opt/sw64 --with-ppl=/opt/sw64 --with-mpc=/opt/sw64 --enable-lto --enable-checking=release Thread model: posix gcc version 4.6.0 20100816 (experimental) [trunk revision 163278] (GCC) [macbook] lin/test% gfcp -Ofast -funroll-loops -fno-whole-file test_fpu.f90 [macbook] lin/test% time a.out Benchmark running, hopefully as only ACTIVE task 0.99755959009261719 Test1 - Gauss 2000 (101x101) inverts 2.8 sec Err= 0.006 Test2 - Crout 2000 (101x101) inverts 2.9 sec Err= 0.014 Test3 - Crout 2 (1001x1001) inverts 3.4 sec Err= 0.043 Test4 - Lapack 2 (1001x1001) inverts 2.8 sec Err= 0.250 total = 11.8 sec 12.028u 0.095s 0:12.13 99.8%0+0k 0+0io 0pf+0w Note that for Gauss 2000 alone the slowdown is ~40%. -- Summary: [4.6 Regression] ~10% slowdown on test_fpu at revision 163278 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45379
[Bug fortran/45309] [4.6 Regression] gfortran.dg/trim_optimize_1.f90 has 4 memmove
--- Comment #4 from mikael at gcc dot gnu dot org 2010-08-22 17:10 --- I'm seeing the failure now at revision 163459. -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45309
[Bug rtl-optimization/45352] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058
--- Comment #2 from zsojka at seznam dot cz 2010-08-22 17:15 --- Created an attachment (id=21544) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21544action=view) different testcase This one crashes with: $ gcc -Os -fselective-scheduling2 -fsel-sched-pipelining -fprofile-generate pr45352-2.c pr45352-2.c: In function 'df_md_alloc': pr45352-2.c:21:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7058 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This set of flags might be more useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45352
[Bug fortran/45380] New: ICE in gfc_conv_intrinsic_any_all at -O{n0}
At revision 163459 with testcase :
implicit none
integer, parameter :: nx = 3, ny = 4
integer, dimension(nx,ny) :: a
if (any (a /= a)) call abort
end
--
Summary: ICE in gfc_conv_intrinsic_any_all at -O{n0}
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikael at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-freebsd8.0
GCC host triplet: x86_64-unknown-freebsd8.0
GCC target triplet: x86_64-unknown-freebsd8.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45380
[Bug fortran/45380] ICE in gfc_conv_intrinsic_any_all at -O{n0}
--- Comment #1 from mikael at gcc dot gnu dot org 2010-08-22 18:00 --- The error: internal compiler error: in gfc_conv_intrinsic_anyall, at fortran/trans-intrinsic.c:1689 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. It seems that the a /= a is simplified to a constant scalar value which triggers the assert. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45380
Re: [Bug bootstrap/45376] New: no such instruction: `pcmpestri $0,(%rdi),%xmm0'
What version of binutils is being used? Have you tried a newer version? On Aug 22, 2010, at 3:11 AM, mikael at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: Updating today at revision 163455 gave : /home/mik/gcc46/src/libcpp/lex.c: Assembler messages: /home/mik/gcc46/src/libcpp/lex.c:448: Error: no such instruction: `pcmpestri $0,(%rdi),%xmm0' /home/mik/gcc46/src/libcpp/lex.c:432: Error: no such instruction: `pcmpestri $0,(%rdi),%xmm0' A revision from yesterday worked (2010-08-21), but I don't remember the revision number. Possible culprit according to the ChangeLog : revision 163446. -- Summary: no such instruction: `pcmpestri $0,(%rdi),%xmm0' Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikael at gcc dot gnu dot org GCC build triplet: x86_64-unknown-freebsd8.0 GCC host triplet: x86_64-unknown-freebsd8.0 GCC target triplet: x86_64-unknown-freebsd8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45376
[Bug bootstrap/45376] no such instruction: `pcmpestri $0,(%rdi),%xmm0'
--- Comment #3 from pinskia at gmail dot com 2010-08-22 18:05 --- Subject: Re: New: no such instruction: `pcmpestri $0,(%rdi),%xmm0' What version of binutils is being used? Have you tried a newer version? On Aug 22, 2010, at 3:11 AM, mikael at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: Updating today at revision 163455 gave : /home/mik/gcc46/src/libcpp/lex.c: Assembler messages: /home/mik/gcc46/src/libcpp/lex.c:448: Error: no such instruction: `pcmpestri $0,(%rdi),%xmm0' /home/mik/gcc46/src/libcpp/lex.c:432: Error: no such instruction: `pcmpestri $0,(%rdi),%xmm0' A revision from yesterday worked (2010-08-21), but I don't remember the revision number. Possible culprit according to the ChangeLog : revision 163446. -- Summary: no such instruction: `pcmpestri $0,(%rdi),%xmm0' Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikael at gcc dot gnu dot org GCC build triplet: x86_64-unknown-freebsd8.0 GCC host triplet: x86_64-unknown-freebsd8.0 GCC target triplet: x86_64-unknown-freebsd8.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45376 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45376
[Bug c++/36310] [avr] Lots of (possibly) unnecesary static initialization code generated.
--- Comment #6 from eric dot weddington at atmel dot com 2010-08-22 19:14 --- (In reply to comment #5) Hmm, I am confused. With my patch for pure constructor removal I get .text .p2align 4,,15 .globl main .type main, @function main: .LFB9: .cfi_startproc movss .LC0(%rip), %xmm0 xorl%eax, %eax mulss _ZN3AvgILi20EE6ResultE(%rip), %xmm0 movss %xmm0, _ZN3AvgILi20EE6ResultE(%rip) ret .cfi_endproc .LFE9: .size main, .-main .p2align 4,,15 .type _GLOBAL__I_main, @function _GLOBAL__I_main: .LFB12: .cfi_startproc cmpb$0, _ZGVN3AvgILi20EE6ResultE(%rip) jne .L2 movb$1, _ZGVN3AvgILi20EE6ResultE(%rip) .L2: rep ret .cfi_endproc .LFE12: that is there is one static constructor that seems necessary. Is that what expected? I think the above comment is misplaced. This bug (#36310) is for the avr target and the above is not avr assembly. Bug #36310 was marked as a duplicate of bug #17736. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36310
[Bug fortran/33197] Fortran 2008: math functions
--- Comment #37 from burnus at gcc dot gnu dot org 2010-08-22 19:32 --- Created an attachment (id=21545) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21545action=view) Draft patch for NORM2 -- and draft run-time test, early PARITY patch Draft patch for NORM2; as PARITY is essentially the same -- thus, an untested PARITY implementation is included as well. TODO - There is some bug in converting the call for NORM2 - probably in trans-intrinsic.c; result: a segfault for the run-time version at compile time - Inline run-time version missing, cf. ISYM_SUM - possibly use lib version with -Os? - Test cases - PARITY: What about logical kinds 1 and 2? Or how to handle this better? -- and the same issues as for NORM2. Note, a simple conversion only works for scalars not for arrays - which require would require a temporary. I could image that INTEGER(1) is often used due to its smaller storage size. PS: NORM2 is described as careful calculation of Euclidean norm in the BCS slides and in the what's new in F2008 article. Currently, I use the trivial brute-force method. Maybe something more careful should be done? -- burnus at gcc dot gnu dot org changed: What|Removed |Added Attachment #17315|0 |1 is obsolete|| Attachment #18173|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33197
[Bug fortran/33197] Fortran 2008: math functions
--- Comment #38 from burnus at gcc dot gnu dot org 2010-08-22 19:34 --- (In reply to comment #37) - PARITY: ... and the same issues as for NORM2. And PARITY documentation is missing. Reminder: For NORM2's inline version, think also about hypot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33197
[Bug fortran/45380] ICE in gfc_conv_intrinsic_any_all at -O{n0}
--- Comment #2 from mikael at gcc dot gnu dot org 2010-08-22 19:41 --- (In reply to comment #1) It seems that the a /= a is simplified to a constant scalar value which triggers the assert. The culprit seems the recent frontend optimization pass. Here is a work-around, but it would be better to have these optimizations working with arrays. Index: frontend-passes.c === --- frontend-passes.c (r#65533;#65533;vision 163459) +++ frontend-passes.c (copie de travail) @@ -399,6 +399,9 @@ return true; } + if (e-rank 0) +return false; + /* Check for direct comparison between identical variables. Don't compare REAL or COMPLEX because of NaN checks. */ if (op1-expr_type == EXPR_VARIABLE By the way, this also fixes runtime failures with widechar_intrinsics_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45380
[Bug fortran/45380] ICE in gfc_conv_intrinsic_any_all at -O{n0}
--- Comment #3 from mikael at gcc dot gnu dot org 2010-08-22 19:45 --- *** Bug 45309 has been marked as a duplicate of this bug. *** -- mikael at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45380
[Bug fortran/45309] [4.6 Regression] gfortran.dg/trim_optimize_1.f90 has 4 memmove
--- Comment #5 from mikael at gcc dot gnu dot org 2010-08-22 19:45 --- The patch for PR45380 fixes this. *** This bug has been marked as a duplicate of 45380 *** -- mikael at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45309
[Bug bootstrap/45381] New: [4.6 Regression] Bootstrap failure for powerpc-apple-darwin9: error: AltiVec argument passed to unprototyped function
Bootstrapping revision 163461 fails with gcc -I../../gcc-4.6-work/libcpp -I. -I../../gcc-4.6-work/libcpp/../include -I../../gcc-4.6-work/libcpp/include -g -fkeep-inline-functions -W -Wall -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long -I../../gcc-4.6-work/libcpp -I. -I../../gcc-4.6-work/libcpp/../include -I../../gcc-4.6-work/libcpp/include -c -o lex.o -MT lex.o -MMD -MP -MF .deps/lex.Tpo ../../gcc-4.6-work/libcpp/lex.c ../../gcc-4.6-work/libcpp/lex.c: In function 'search_line_fast': ../../gcc-4.6-work/libcpp/lex.c:537: warning: implicit declaration of function '__builtin_vec_ld' ../../gcc-4.6-work/libcpp/lex.c:537: error: incompatible types in assignment ../../gcc-4.6-work/libcpp/lex.c:543: warning: implicit declaration of function '__builtin_vec_lvsr' ../../gcc-4.6-work/libcpp/lex.c:543: error: incompatible types in assignment ../../gcc-4.6-work/libcpp/lex.c:544: warning: implicit declaration of function '__builtin_vec_perm' ../../gcc-4.6-work/libcpp/lex.c:544: error: AltiVec argument passed to unprototyped function ../../gcc-4.6-work/libcpp/lex.c:558: error: incompatible types in assignment ../../gcc-4.6-work/libcpp/lex.c:561: warning: implicit declaration of function '__builtin_vec_cmpeq' ../../gcc-4.6-work/libcpp/lex.c:561: error: AltiVec argument passed to unprototyped function ../../gcc-4.6-work/libcpp/lex.c:562: error: AltiVec argument passed to unprototyped function ../../gcc-4.6-work/libcpp/lex.c:563: error: AltiVec argument passed to unprototyped function ../../gcc-4.6-work/libcpp/lex.c:564: error: AltiVec argument passed to unprototyped function ../../gcc-4.6-work/libcpp/lex.c:571: warning: implicit declaration of function '__builtin_vec_vcmpeq_p' ../../gcc-4.6-work/libcpp/lex.c:571: error: AltiVec argument passed to unprototyped function Likely due to revision 163446. -- Summary: [4.6 Regression] Bootstrap failure for powerpc-apple- darwin9: error: AltiVec argument passed to unprototyped function Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45381
[Bug c++/45382] New: internal compiler error: tree code �call_expr� is not supported in gimple streams
# gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.1/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.5.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.5.1/work/gcc-4.5.1/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.5.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.1/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --disable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.5.1/python --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.1 p1.0, pie-0.4.5' Thread model: posix gcc version 4.5.1 (Gentoo 4.5.1 p1.0, pie-0.4.5) Building the attached preprocessed file, I can cause an ICE # g++ -flto -c SmallStrings.i -o SmallStrings.o JavaScriptCore/runtime/SmallStrings.cpp:141:1: internal compiler error: tree code call_expr is not supported in gimple streams Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions. The file is from webkit-gtk-1.2.3. -- Summary: internal compiler error: tree code call_expr is not supported in gimple streams Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mattst88 at gmail dot com GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45382
[Bug c++/45382] internal compiler error: tree code �call_expr� is not supported in gimple streams
--- Comment #1 from mattst88 at gmail dot com 2010-08-22 22:01 --- Created an attachment (id=21546) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21546action=view) SmallStrings.i from webkit-gtk-1.2.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45382
[Bug c++/43850] ice: tree code �template_type_parm� is not supported in gimple streams
--- Comment #9 from mattst88 at gmail dot com 2010-08-22 22:02 --- Can this code be backported to the 4.5 branch? -- mattst88 at gmail dot com changed: What|Removed |Added CC||mattst88 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43850
[Bug fortran/33197] Fortran 2008: math functions
--- Comment #39 from burnus at gcc dot gnu dot org 2010-08-22 21:02 --- (In reply to comment #37) PS: NORM2 is described as careful calculation of Euclidean norm in the BCS slides and in the what's new in F2008 article. Currently, I use the trivial brute-force method. Maybe something more careful should be done? As Dominique points out - the algorithm can be made more robust by doing the calculation as tmp = max(abs(a)) NORM2(a) := tmp*sqrt(dot_product(a/tmp,a/tmp)) That helps a lot for a finite with (a^2 huge(a)) [overflow] ;-) However, there is a method which only requires a single pass, cf. p. 38/39 in http://cpc.cs.qub.ac.uk/MRSN/higham.pdf. The algorithm by Sven Hammarling is also used in BLAS, cf. http://www.netlib.org/blas/snrm2.f -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33197
