[Bug target/43725] New: Poor instructions selection, scheduling and registers allocation for ARM NEON intrinsics

gcc version 4.5.0-rc20100406 /**/ #include void x(int32x4_t a, int32x4_t b, int32x4_t *p) { #define X(n) p[n] = vaddq_s32(p[n], a); p[n] = vorrq_s32(p[n], b); X(0); X(1); X(2); X(3); X(4); X(5); X(6); X(7); X(8); X(9); X(10); X(11); X(12); } /**/

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

--- Comment #12 from jakub at gcc dot gnu dot org 2010-04-12 08:21 --- GCC would ICE if the referenced DIE wasn't being output on: gcc_assert (AT_ref (a)->die_offset); in output_die. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43254

[Bug target/43698] [4.5/4.6 Regression] Invalid code when building gentoo pax-utils-0.1.19 with -Os optimizations

--- Comment #7 from ramana at gcc dot gnu dot org 2010-04-12 08:38 --- Patch submitted here. http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00401.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43698

[Bug target/43700] [4.4/4.5/4.6 Regression] global register variables defect

--- Comment #4 from jakub at gcc dot gnu dot org 2010-04-12 08:41 --- Isn't this just a user error then? You should have used -ffixed-20 if you use a call saved register as global register IMHO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43700

[Bug target/43722] ICE when passing NEON registers using const refrences

--- Comment #2 from mikpe at it dot uu dot se 2010-04-12 08:48 --- The equivalent C version of this test case ICEs with 4.4.4 but works with 4.3.5 and 4.5.0-RC-20100406. -- mikpe at it dot uu dot se changed: What|Removed |Added

[Bug tree-optimization/43629] [4.3 Regression] Struct to register optimization fails

--- Comment #13 from julien dot etienne at gmail dot com 2010-04-12 08:50 --- Thanks for the fix ! Do you plan to backport it to 4.3.x ? Best regards, Julien Etienne -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43629

[Bug tree-optimization/43629] [4.3 Regression] Struct to register optimization fails

--- Comment #14 from rguenther at suse dot de 2010-04-12 09:00 --- Subject: Re: [4.3 Regression] Struct to register optimization fails On Mon, 12 Apr 2010, julien dot etienne at gmail dot com wrote: > --- Comment #13 from julien dot etienne at gmail dot com 2010-04-12 > 08:50 -

[Bug target/43700] [4.4/4.5/4.6 Regression] global register variables defect

--- Comment #5 from mikpe at it dot uu dot se 2010-04-12 09:02 --- (In reply to comment #4) > Isn't this just a user error then? You should have used -ffixed-20 if you use > a call saved register as global register IMHO. gcc's documentation (I'm looking at the global register variables

[Bug target/43703] Unexpected floating point precision loss due to ARM NEON autovectorization

--- Comment #3 from ramana at gcc dot gnu dot org 2010-04-12 09:17 --- Could you post a cleaned-up testcase ? I tried a cleaned up testcase with the values appropriately zero-initialized and gcc ends up generating the vectorized value in this case. -- ramana at gcc dot gnu dot org c

[Bug target/43698] [4.5/4.6 Regression] Invalid code when building gentoo pax-utils-0.1.19 with -Os optimizations

--- Comment #8 from siarhei dot siamashka at gmail dot com 2010-04-12 09:34 --- (In reply to comment #7) > Patch submitted here. > > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00401.html Thank you. I have been testing it for two days already. It really helps (in the sense that it

[Bug middle-end/43690] [4.3/4.4/4.5 Regression] Internal compiler error detected by avr-gcc.

--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-12 09:44 --- Created an attachment (id=20362) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20362&action=view) gcc46-pr43690.patch This is very ugly. Either we should reject all these during gimplification ("m" (x+1) is als

[Bug fortran/43696] [OOP] Bogus error: Passed-object dummy argument must not be POINTER

--- Comment #5 from janus at gcc dot gnu dot org 2010-04-12 09:50 --- (In reply to comment #4) > I've tried to isolate the error message from the ICE. The smallest code is > a_module for the error and b_module for the ICE. Thanks. However, ... > !!$ f951: internal compiler error: in

Re: [Bug target/43698] [4.5/4.6 Regression] Invalid code when building gentoo pax-utils-0.1.19 with -Os optimizations

On Mon, 2010-04-12 at 09:34 +, siarhei dot siamashka at gmail dot com wrote: > > --- Comment #8 from siarhei dot siamashka at gmail dot com 2010-04-12 > 09:34 --- > (In reply to comment #7) > > Patch submitted here. > > > > http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00401.html >

[Bug target/43698] [4.5/4.6 Regression] Invalid code when building gentoo pax-utils-0.1.19 with -Os optimizations

--- Comment #9 from ramana dot radhakrishnan at arm dot com 2010-04-12 09:51 --- Subject: Re: [4.5/4.6 Regression] Invalid code when building gentoo pax-utils-0.1.19 with -Os optimizations On Mon, 2010-04-12 at 09:34 +, siarhei dot siamashka at gmail dot com wrote: > > -

[Bug tree-optimization/43611] [4.5/4.6 Regression] ICE: SIGSEGV with -fipa-cp-clone -fkeep-inline-functions

--- Comment #14 from rguenth at gcc dot gnu dot org 2010-04-12 09:53 --- Subject: Bug 43611 Author: rguenth Date: Mon Apr 12 09:52:50 2010 New Revision: 158218 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158218 Log: 2010-04-12 Richard Guenther PR c++/43611

[Bug tree-optimization/43560] [4.3 Regression] possible wrong code bug

--- Comment #16 from jakub at gcc dot gnu dot org 2010-04-12 10:18 --- Subject: Bug 43560 Author: jakub Date: Mon Apr 12 10:18:39 2010 New Revision: 158220 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158220 Log: PR tree-optimization/43560 * gcc.c-torture/execu

[Bug tree-optimization/43560] [4.3 Regression] possible wrong code bug

--- Comment #17 from jakub at gcc dot gnu dot org 2010-04-12 10:22 --- Subject: Bug 43560 Author: jakub Date: Mon Apr 12 10:22:21 2010 New Revision: 158221 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158221 Log: PR tree-optimization/43560 * gcc.c-torture/execu

[Bug tree-optimization/43560] [4.3 Regression] possible wrong code bug

--- Comment #18 from jakub at gcc dot gnu dot org 2010-04-12 10:25 --- Subject: Bug 43560 Author: jakub Date: Mon Apr 12 10:25:11 2010 New Revision: 158222 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158222 Log: PR tree-optimization/43560 * gcc.c-torture/execu

[Bug target/43722] ICE when passing NEON registers using const refrences

--- Comment #3 from mikpe at it dot uu dot se 2010-04-12 10:31 --- gcc-4.5-20090514 (r147545): ICE gcc-4.5-20090521 (r147778): no ICE Continuing to investigate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43722

[Bug lto/42776] LTO doesn't work on non-ELF platforms.

--- Comment #35 from steven at gcc dot gnu dot org 2010-04-12 10:40 --- So if I understand correctly, the "state of things" at the moment is this: Without LTO: > Time: 419.938 sec (6 m 59 s) with LTO incl linker flags: > Time: 443.047 sec (7 m 23 s) In other words, "with LTO" is ~6% s

[Bug target/43613] Some architecture-dependent codes

--- Comment #4 from aflyhorse at foxmail dot com 2010-04-12 10:44 --- Maybe I should still choose the proprietary compiler of M$ for my Win_x64-target platform... -- aflyhorse at foxmail dot com changed: What|Removed |Added

[Bug c++/43720] undefined reference to static const integral class member

--- Comment #2 from redi at gcc dot gnu dot org 2010-04-12 11:06 --- dup of Bug 42101 and Bug 14404 and Bug 38624 and Bug 37175 etc. etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43720

[Bug c++/43719] uninitialized const member incorrectly accepted, using an array

-- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirme

[Bug c++/7614] Warning when function returning reference to volatile called in void context

--- Comment #6 from redi at gcc dot gnu dot org 2010-04-12 11:19 --- (In reply to comment #5) > you're writing a smart pointer class in C++, users expect that you will > support > all the same operators with all the same semantics. do you mean that users expect this? volatile SmartPtr

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

--- Comment #10 from rguenth at gcc dot gnu dot org 2010-04-12 11:21 --- - D.1850_209 = -alt_90; - D.2093_151 = -alb_86; - D.1849_208 = D.1848_207 - alb_86; + D.2093_151 = -alt_90; + D.1849_208 = D.1848_207 - alt_90; D.1851_210 = D.1849_208 + -1.0e+0; - z1a_211 = D.1851_210 + D

[Bug target/43726] New: lm32-rtems* ICE

gcc-4.5.0-RC-20100406 triggers an ICE while building RTEMS: ... lm32-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I.. -I../../cpukit/../../../lm32_evr/lib/include -DNO_SSI -DNO_SSL -DNO_CGI -O0 -g -Wall -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT l ../../../../../../c/src/

[Bug target/43726] lm32-rtems* ICE

--- Comment #1 from corsepiu at gcc dot gnu dot org 2010-04-12 11:52 --- Created an attachment (id=20363) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20363&action=view) *.i of the source file triggering the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726

[Bug target/43726] lm32-rtems* ICE

--- Comment #2 from joel at gcc dot gnu dot org 2010-04-12 12:11 --- Did you have patches to get past http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43527 or has it just gone away? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726

[Bug c++/7614] Warning when function returning reference to volatile called in void context

--- Comment #7 from joseph dot h dot garvin at gmail dot com 2010-04-12 12:19 --- Right, I think that's what users expect, assuming you are in a situation where volatile smart pointers make sense in the first place (in my case they are smart pointers to addresses within a shared memory

[Bug c++/7614] Warning when function returning reference to volatile called in void context

--- Comment #8 from redi at gcc dot gnu dot org 2010-04-12 12:30 --- (In reply to comment #7) > smart pointers to addresses within a shared memory region then shouldn't that be "SmartPtr" rather than "volatile SmartPtr" ? the former points to an object which might change due to effects

[Bug target/43726] lm32-rtems* ICE

--- Comment #3 from corsepiu at gcc dot gnu dot org 2010-04-12 12:31 --- (In reply to comment #2) > Did you have patches to get past > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43527 or has it just gone away? Neither. This breakdown is with the rtems-4.11-lm32-rtems4.11-gcc rpm, i.

[Bug c++/43720] undefined reference to static const integral class member

--- Comment #3 from roman at binarylife dot net 2010-04-12 12:41 --- sorry for bothering :) thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43720

[Bug bootstrap/37632] Darwin bootstrap failure, "ld: bl out of range"

--- Comment #10 from lucier at math dot purdue dot edu 2010-04-12 13:17 --- Subject: Re: Darwin bootstrap failure, "ld: bl out of range" On Sun, 2010-04-11 at 10:29 +, iains at gcc dot gnu dot org wrote: > 2. As a matter of curiosity - do you see a big improvement in performance

[Bug bootstrap/43699] [4.6 regression] "variable set but not used" error during bootstrap

--- Comment #7 from jakub at gcc dot gnu dot org 2010-04-12 13:27 --- Subject: Bug 43699 Author: jakub Date: Mon Apr 12 13:27:07 2010 New Revision: 158224 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158224 Log: PR bootstrap/43699 * c-typeck.c (c_process_expr_s

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

--- Comment #13 from iains at gcc dot gnu dot org 2010-04-12 13:28 --- Created an attachment (id=20364) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20364&action=view) hack wrapper for dsymutil This is a simple script that edits one specific warning out of the output from dsymuti

[Bug lto/42776] LTO doesn't work on non-ELF platforms.

--- Comment #36 from davek at gcc dot gnu dot org 2010-04-12 13:30 --- (In reply to comment #35) > http://www.cs.rice.edu/~keith/512/Lectures/30IDFAO.pdf Thanks for the link, not just because it's full of intersting information, but also because I now have a new candidate for most-un

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

--- Comment #14 from iains at gcc dot gnu dot org 2010-04-12 13:36 --- Created an attachment (id=20365) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20365&action=view) sort out some nits with config/{*,}/darwin*.h and hack in a solution for dsymtuil The dsymutils issue is not a G

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

--- Comment #15 from iains at gcc dot gnu dot org 2010-04-12 13:39 --- (In reply to comment #12) > GCC would ICE if the referenced DIE wasn't being output on: > gcc_assert (AT_ref (a)->die_offset); > in output_die. thanks Jakub, for now we need to work around this .. (a) until dsymuti

[Bug middle-end/40386] wrong code generation for several SPEC CPU2000 benchmarks (lucas, mgrid, face, applu, apsi) with -O1 -fno-ira-share-spill-slots

--- Comment #7 from zsojka at seznam dot cz 2010-04-12 13:47 --- Running check on gcc/g++ shows further miscompilations with -fno-ira-share-spill-slots (as of r158131, x86_64-linux): gcc.c-torture/execute/20021120-1.c FAILs with: -O2 -fno-ira-share-spill-slots or -O1 -foptimize-register

[Bug target/43613] Some architecture-dependent codes

--- Comment #5 from pinskia at gcc dot gnu dot org 2010-04-12 14:12 --- I don't get why you closed this bug. Anyways if you have a patch, post it to gcc-patc...@. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug target/43722] ICE when passing NEON registers using const refrences

--- Comment #4 from mikpe at it dot uu dot se 2010-04-12 14:18 --- Appears to have been "fixed" for 4.5 by r147566, see . But that patch doesn't change any ARM code so the issue may be still be latent in 4.5 unless some other patch

[Bug c++/7614] Warning when function returning reference to volatile called in void context

--- Comment #9 from joseph dot h dot garvin at gmail dot com 2010-04-12 15:00 --- (In reply to comment #8) > (In reply to comment #7) > the former points to an object which might change due to effects outside the > program, the latter implies that the smart pointer itself might change,

[Bug target/43727] New: undefined reference to `_restgpr_30_x'

In -Os mode I see undefined references to _restgpr_* _savefpr_* and similar functions. Michael Matz sees libgcc.a not added to the linkline in this mode. testcase: g++ -Os -shared -o libhello.so -Wl,-z,defs -fPIC hello.c /tmp/cc8oo25Z.o: In function `hello()': hello.c:(.text+0x30): undefined ref

[Bug target/43727] undefined reference to `_restgpr_30_x'

--- Comment #1 from marcus at jet dot franken dot de 2010-04-12 15:04 --- Created an attachment (id=20366) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20366&action=view) hello.c g++ -Os -shared -o libhello.so -Wl,-z,defs -fPIC hello.c -- http://gcc.gnu.org/bugzilla/show_bu

[Bug c/43728] New: Warning for redundant static function prototypes

Prototypes for static functions that aren't used in between the prototype and the actual static function definition are useless and could be cleaned up, I think gcc itself has thousands of such useless prototypes. It isn't hard to add a warning for this. Given: static void foo (int); #ifdef D vo

[Bug c/43728] Warning for redundant static function prototypes

--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-12 15:14 --- Created an attachment (id=20367) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20367&action=view) gcc46-pr43728.patch Quick patch, so far without documentation and testsuite and almost untested. -- http://g

[Bug c/43728] Warning for redundant static function prototypes

--- Comment #2 from jakub at gcc dot gnu dot org 2010-04-12 15:16 --- *** Bug 36195 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c/36195] Add warnings for useless static functions prototypes in -Wredundant-decls

--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-12 15:16 --- *** This bug has been marked as a duplicate of 43728 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added --

[Bug target/43727] undefined reference to `_restgpr_30_x'

--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-12 15:16 --- Nathan, you touched the relevant code last. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug target/43727] undefined reference to `_restgpr_30_x'

--- Comment #3 from froydnj at gcc dot gnu dot org 2010-04-12 15:27 --- This should have been taken care of by: 2009-09-09 Jakub Jelinek * config/t-slibgcc-elf-ver (SHLIB_MAKE_SOLINK, SHLIB_INSTALL_SOLINK): New variables. (SHLIB_LINK, SHLIB_INSTALL): Use them

[Bug c++/43641] [C++0x] internal compiler error: tree check: expected call_expr, have target_expr in maybe_add_lambda_conv_op

-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org

[Bug c/43728] Warning for redundant static function prototypes

--- Comment #3 from manu at gcc dot gnu dot org 2010-04-12 15:38 --- If you are going to add such a warning, please be more explicit. I suggest: "redundant prototype for static function %qD because it is never used before its definition" -- manu at gcc dot gnu dot org changed:

[Bug target/43727] undefined reference to `_restgpr_30_x'

--- Comment #4 from froydnj at gcc dot gnu dot org 2010-04-12 15:41 --- FWIW, I cannot reproduce with 'gcc version 4.5.0 20100205'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43727

[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

--- Comment #12 from ramana at gcc dot gnu dot org 2010-04-12 15:50 --- A git bisect between the ranges suggested by Dave in Comment #6, gave me r149470 this as the first broken commit using a cross-compiler to arm-linux-gnueabi with qemu as the simulator . 2009-07-02 Richard Guenther

[Bug target/43729] New: MachO LTO support needed for darwin

This bug report is a placeholder for discussing the changes required for LTO via collect2 on darwin. It exists to have a distinct discussion about darwin since we don't use either ELF or binutils. It would be optimal if the required changes would not involve modifications to the darwin linker since

[Bug target/43729] MachO LTO support needed for darwin

-- steven at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW E

[Bug lto/42776] LTO doesn't work on non-ELF platforms.

--- Comment #37 from steven at gcc dot gnu dot org 2010-04-12 15:58 --- LTO for Mach-O is now being tracked in bug 43729. -- steven at gcc dot gnu dot org changed: What|Removed |Added

[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-12 15:59 --- (In reply to comment #12) > A git bisect between the ranges suggested by Dave in Comment #6, gave me > r149470 this as the first broken commit using a cross-compiler to > arm-linux-gnueabi with qemu as the simulato

[Bug target/43729] MachO LTO support needed for darwin

--- Comment #1 from steven at gcc dot gnu dot org 2010-04-12 15:59 --- >From http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776#c8 : > Can we use a similar approach for Mach-O [as for PE-COFF]? I don't speak Mach-O, but yes, the approach should work. You'd start by saying lto_binary_

[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

--- Comment #14 from dave at hiauly1 dot hia dot nrc dot ca 2010-04-12 16:02 --- Subject: Re: [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers > A git bisect between the ranges suggested by Dave in Comment #6, gave me > r149470 this as th

[Bug lto/42776] LTO doesn't work on non-ELF platforms.

--- Comment #38 from ro at gcc dot gnu dot org 2010-04-12 16:10 --- Could be interesting for Tru64 UNIX, which uses ECOFF, too. -- ro at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c/43730] New: internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313

Compilation of this test file with versions of gcc-4.5 dated 20090528 to 20100107 produce a fatal internal compiler error; comparable versions of gcc-4.3 and gcc-4.4 do not have this problem: % cat bug003.c extern int (isinfl)(long double); int bugfun(long double x, long double y) { int resul

[Bug target/43729] MachO LTO support needed for darwin

--- Comment #2 from steven at gcc dot gnu dot org 2010-04-12 16:15 --- For the Mach-O file format, follow this link: http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html First step for Mach-O support would be figuring out w

[Bug c/43728] Warning for redundant static function prototypes

--- Comment #4 from jason at gcc dot gnu dot org 2010-04-12 16:16 --- ...and then after removing the prototype, compiling with -DD would fail. I don't object to having such a flag, but I don't think we want it in -Wall. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43728

[Bug ada/43731] New: Missing ada multilib on i686-w64-mingw32 target

When compiling a Win64 i686-w64-mingw32 compiler with multilib, ada fails to build with similar errors as reported in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37993 There is currently no selection on the i686 side for multilib, as the gcc/gcc-interface/ada Makefile assumes that no ix86 mingw* t

[Bug c/43728] Warning for redundant static function prototypes

--- Comment #5 from jakub at gcc dot gnu dot org 2010-04-12 16:29 --- -Wredundant-decls is a non-default warning already, not enabled with -Wall nor -W and I certainly don't want to enable it by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43728

[Bug tree-optimization/43716] [4.6 Regression] Revision 158105 miscompiles doduc.f90

--- Comment #11 from mkuvyrkov at gcc dot gnu dot org 2010-04-12 16:38 --- Confirmed with mac os x gcc build. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/43732] New: -ffixed-reg and register globals broken for MIPS

With gcc 4.4.3 and 4.3.4 and MIPS target, code is incorrectly generated to save/restore registers specified as "fixed" via the "-ffixed-reg" command-line option to gcc. This also applies to register globals (which should be treated as "fixed".) Test code (test.c): register int foo asm ("$23")

[Bug bootstrap/43733] New: bootstrap fails building libgfortran on Solaris x86 with GNU as

../gcc-4.4.3/configure --prefix=/opt/gcc-4.4.3-64/gcc-4.4.3 --enable-languages=c,fortran --with-system-zlib --with-arch=core2 --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld Bootstrap fails with gmake[5]: Entering directory `/var/tmp/gcc/tmp/i386-pc-solaris2.10

[Bug bootstrap/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #1 from redi at gcc dot gnu dot org 2010-04-12 16:51 --- P.S. I'm using in-tree gmp 4.4.3 and mpfr 2.4.2 I'm currently trying another bootstrap without --with-arch=core2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733

[Bug lto/42776] LTO doesn't work on non-ELF platforms.

--- Comment #39 from sherpya at netfarm dot it 2010-04-12 16:55 --- (In reply to comment #35) > So if I understand correctly, the "state of things" at the moment is this: > > Without LTO: > > Time: 419.938 sec (6 m 59 s) > > with LTO incl linker flags: > > Time: 443.047 sec (7 m 23 s)

[Bug target/43729] MachO LTO support needed for darwin

--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-04-12 17:11 --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776#c8 also contains a short list of some of the required code changes for MachO LTO. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729

[Bug bootstrap/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #2 from ubizjak at gmail dot com 2010-04-12 17:11 --- configure should detect if assembler supports sahf mnemonic. In your build directory, check gcc/config.log for: configure:23019: checking assembler for sahf mnemonic configure:23028: /usr/local/x86_64-unknown-linux-gnu/b

[Bug bootstrap/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #3 from redi at gcc dot gnu dot org 2010-04-12 17:15 --- (In reply to comment #1) > I'm currently trying another bootstrap without --with-arch=core2 That worked OK, so it's only the combination of /usr/sfw/bin/gas, fortran and arch=core2 that files -- http://gcc.gnu.or

[Bug bootstrap/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #4 from redi at gcc dot gnu dot org 2010-04-12 17:15 --- configure:22928: checking assembler for sahf mnemonic configure:22937: /usr/sfw/bin/gas -o conftest.o conftest.s >&5 configure:22940: $? = 0 configure:22951: result: yes -- http://gcc.gnu.org/bugzilla/show_bug.cgi

[Bug libfortran/43572] [4.5/4.6 Regression] FAIL: gfortran.dg/PR19872.f execution test; formatted read - wrong numbers

--- Comment #15 from ramana at gcc dot gnu dot org 2010-04-12 17:21 --- (In reply to comment #12) > A git bisect between the ranges suggested by Dave in Comment #6, gave me > r149470 this as the first broken commit using a cross-compiler to > arm-linux-gnueabi with qemu as the simulator

[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #5 from ubizjak at gmail dot com 2010-04-12 17:24 --- Looks to me that this is libgfortran messing with choosen assembler. The bootstrap would die way before libgfortran is touched otherwise. I'm changing component to libgfortran in the hope that fortraners will confirm (an

[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #6 from redi at gcc dot gnu dot org 2010-04-12 17:25 --- running the failing command with -save-temps shows that sahf isused here: .LM312: fprem fnstsw %ax sahf jp .L103 fstp%st(1) fstpl -56(%rbp) movsd -56(%rbp), %xmm1 ucomisd %xmm1

[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #7 from redi at gcc dot gnu dot org 2010-04-12 17:30 --- the failure is while building the 64bit libgfortran, is sahf valid in 64-bit mode? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733

[Bug c++/43734] New: cerr related segmentation fault

Version of GCC: 4.4.3 System Type: SunOS 5.10 Generic_139555-08 sun4u sparc SUNW,SPARC-Enterprise Source Code: // foo.C // #include // main.C / #include int main() { std::cerr << "Hello, World!" << std::endl; return 0; } Build Options: g++ -v -save-temps -G -o libfo

[Bug c++/43734] cerr related segmentation fault

--- Comment #1 from paul dot shaklan at solipsys dot com 2010-04-12 17:38 --- Created an attachment (id=20368) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20368&action=view) .ii file associated with foo.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734

[Bug c++/43734] cerr related segmentation fault

--- Comment #2 from paul dot shaklan at solipsys dot com 2010-04-12 17:39 --- Created an attachment (id=20369) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20369&action=view) .ii file associated with main.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734

[Bug rtl-optimization/25972] pack and unpack of long doubles via union generates poor code

--- Comment #5 from bergner at gcc dot gnu dot org 2010-04-12 17:45 --- Subject: Bug 25972 Author: bergner Date: Mon Apr 12 17:44:59 2010 New Revision: 158231 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158231 Log: Backport from ibm/gcc-4_3-branch 2009-06-11

[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #8 from ubizjak at gmail dot com 2010-04-12 17:47 --- (In reply to comment #3) > (In reply to comment #1) > > I'm currently trying another bootstrap without --with-arch=core2 > > That worked OK, so it's only the combination of /usr/sfw/bin/gas, fortran and > arch=core2 that

[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #9 from ubizjak at gmail dot com 2010-04-12 17:56 --- (In reply to comment #6) > running the failing command with -save-temps shows that sahf isused here: > > .LM312: > fprem > fnstsw %ax > sahf > jp .L103 > fstp%st(1) > fstpl -56(%rbp) >

[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #10 from ubizjak at gmail dot com 2010-04-12 17:57 --- (In reply to comment #9) > Let me guess, /usr/sfw/bin/gas compiles this asm file OK, while > /usr/ccs/bin/ld > doesn't? Well, /usr/ccs/bin/as, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43733

[Bug c++/43734] cerr related segmentation fault

--- Comment #3 from pinskia at gcc dot gnu dot org 2010-04-12 17:58 --- What happens if you do: g++ -v -save-temps -G -o libfoo.so foo.C -fPIC aka add -fPIC when building the shared library? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734

[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #11 from redi at gcc dot gnu dot org 2010-04-12 18:02 --- (In reply to comment #10) > (In reply to comment #9) > > > Let me guess, /usr/sfw/bin/gas compiles this asm file OK, while > > /usr/ccs/bin/ld > > doesn't? > > Well, /usr/ccs/bin/as, of course. > gas barfs on it,

[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #12 from redi at gcc dot gnu dot org 2010-04-12 18:05 --- (In reply to comment #3) > (In reply to comment #1) > > I'm currently trying another bootstrap without --with-arch=core2 > > That worked OK, so it's only the combination of /usr/sfw/bin/gas, fortran and > arch=core2 t

[Bug middle-end/43702] [4.6 regression] FAIL: g++.dg/other/pr35504.C execution test

--- Comment #2 from ktietz at gcc dot gnu dot org 2010-04-12 18:06 --- Committed at revision 158232. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added

[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #13 from redi at gcc dot gnu dot org 2010-04-12 18:08 --- I can't read or write assembler, but searching the interweb tells me that sahf is not valid in 64-bit mode, e.g. http://www.x86-64.org/pipermail/discuss/2004-April/004615.html and also "Introduction to 80x86 Assembly L

[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #14 from ubizjak at gmail dot com 2010-04-12 18:16 --- (In reply to comment #13) > I can't read or write assembler, but searching the interweb tells me that sahf > is not valid in 64-bit mode, e.g. > http://www.x86-64.org/pipermail/discuss/2004-April/004615.html and also > "I

[Bug target/43700] [4.4/4.5/4.6 Regression] global register variables defect

--- Comment #6 from pinskia at gcc dot gnu dot org 2010-04-12 18:18 --- *** Bug 43732 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c/43732] -ffixed-reg and register globals broken for MIPS

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-12 18:18 --- *** This bug has been marked as a duplicate of 43700 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug target/43700] [4.4/4.5/4.6 Regression] global register variables defect

--- Comment #7 from pinskia at gcc dot gnu dot org 2010-04-12 18:20 --- Well -ffixed-reg-r20 is also broken the same way :) See the duplicated bug which has a patch which I have not looked into to see if it is the correct fix yet or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?i

[Bug libfortran/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #15 from redi at gcc dot gnu dot org 2010-04-12 18:21 --- (In reply to comment #14) > > Why is that instruction being issued when compiling amd64/libgfortran? > > Don't worry about this insn, it works for core2. GNU as 2.15 doesn't believe you :-) $ echo sahf > test.s $ /

[Bug c/43730] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-04-12 18:34 --- Still ICEd as of 20100401. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43730

[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313

--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-12 18:38 --- And as of: gcc version 4.6.0 20100408 (experimental) [trunk revision 158138] (GCC) So confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug middle-end/43730] [4.5/4.6 Regression] internal compiler error: in expand_builtin_interclass_mathfn, at builtins.c:2313

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |major GCC build triplet|x86_64-unknown-linux-gnu| GCC host tr

[Bug bootstrap/43733] bootstrap fails building libgfortran on Solaris x86 with GNU as

--- Comment #16 from ubizjak at gmail dot com 2010-04-12 18:42 --- Can you try this (untested) patch? Index: acinclude.m4 === --- acinclude.m4(revision 158225) +++ acinclude.m4(working copy) @@ -452,6 +452,9

  1   2   >