[Bug bootstrap/44226] [4.6 regression] Failed to bootstrap

--- Comment #1 from hjl dot tools at gmail dot com 2010-05-21 06:49 --- Revision 159644: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00697.html may be the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added

[Bug bootstrap/44226] New: [4.6 regression] Failed to bootstrap

On Linux/ia64, revision 159650 gave /export/gnu/import/svn/gcc-test/bld/./gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/./gcc/ -B/usr/local/ia64-unknown-linux-gnu/bin/ -B/usr/local/ia64-unknown-linux-gnu/lib/ -isystem /usr/local/ia64-unknown-linux-gnu/include -isystem /usr/local/ia64-unknown-linu

[Bug c++/44225] Workaround for error: ... cannot appear in a constant-expression

--- Comment #1 from tuschjan at yahoo dot de 2010-05-21 06:32 --- Created an attachment (id=20717) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20717&action=view) demo source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44225

[Bug c++/44225] New: Workaround for error: ... cannot appear in a constant-expression

I observed the following issue with g++-4.3.4: I can work around the restriction of initializing a static const integral class member with a non-constant expression. This violates the standard and should be rejected by "-pedantic". Correct me, if I'm wrong. I cut down my code to the following (c

[Bug regression/43892] PowerPC suboptimal "add with carry" optimization

--- Comment #11 from joakim dot tjernlund at transmode dot se 2010-05-21 06:23 --- (In reply to comment #10) > > On my mpc8321 it is a big difference(don't have numbers handy). Why would > > such a simply insn be a problem performance wise? > > I know the kernel still uses the carry ins

[Bug fortran/44212] [OOP] ICE when defining a pointer component before defining the class and calling a TBP then

--- Comment #3 from dominiq at lps dot ens dot fr 2010-05-21 06:21 --- The patch in comment #2 fixes the ICE, but is probably the cause of FAIL: gfortran.dg/select_type_1.f03 -O (internal compiler error) FAIL: gfortran.dg/select_type_1.f03 -O (test for errors, line 63) FAIL: gfortr

[Bug middle-end/44224] [4.6 Regression]: build broken for cris-elf in libgcc

--- Comment #2 from kkojima at gcc dot gnu dot org 2010-05-21 04:03 --- Similar build failure seen on sh4-unknown-linux-gnu. /exp/ldroot/dodes/xsh-gcc-orig/./gcc/xgcc -B/exp/ldroot/dodes/xsh-gcc-orig/./gcc/ -B/usr/local/sh4-unknown-linux-gnu/bin/ -B/usr/local/sh4-unknown-linux-gnu/lib/

[Bug middle-end/44224] [4.6 Regression]: build broken for cris-elf in libgcc

--- Comment #1 from hp at gcc dot gnu dot org 2010-05-21 03:34 --- Created an attachment (id=20716) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20716&action=view) Shortened libgcc2.i Compile with "./cc1 -fpreprocessed l.i -march=v10 -O2 -o libgcc2.s", observe ICE. -- http:/

[Bug middle-end/44224] New: [4.6 Regression]: build broken for cris-elf in libgcc

With revision 159638 a combined tree built for cris-elf. >From revision 159644, build was broken as follows: # If this is the top-level multilib, build all the other # multilibs. /tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc -B/tmp/hpautote

[Bug target/44199] ppc64 glibc miscompilation

--- Comment #13 from pthaugen at gcc dot gnu dot org 2010-05-21 02:32 --- Bootstrap of trunk went fine. Regression test (contrib/test_summary) showed the following difference between base/patched versions, but didn't have any testcases show up in the diff, so not sure what to make of th

[Bug rtl-optimization/44223] segmentation fault with -g -fsched-pressure

--- Comment #1 from astrange at ithinksw dot com 2010-05-21 02:02 --- Created an attachment (id=20715) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20715&action=view) file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44223

[Bug rtl-optimization/44223] New: segmentation fault with -g -fsched-pressure

> gcc -O3 -g -fsched-pressure -fschedule-insns -S crash1m.i crash1m.i: In function 'ff_adts_write_frame_header': crash1m.i:35:2: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions.

[Bug testsuite/32064] ssp tests can't find libssp

--- Comment #4 from hjl dot tools at gmail dot com 2010-05-21 01:53 --- *** Bug 28242 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug testsuite/28242] running the testsuite with -fstack-protector fail (not finding libssp)

--- Comment #3 from hjl dot tools at gmail dot com 2010-05-21 01:53 --- *** This bug has been marked as a duplicate of 32064 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added --

[Bug target/44222] [4.6 regression] Revision 159621 caused new x86 test failures

--- Comment #1 from pinskia at gmail dot com 2010-05-21 01:52 --- Subject: Re: New: [4.6 regression] Revision 159621 caused new x86 test failures This is the same problem as the other sse testcases. Sent from my iPhone On May 20, 2010, at 6:34 PM, "hjl dot tools at gmail dot com" w

Re: [Bug target/44222] New: [4.6 regression] Revision 159621 caused new x86 test failures

This is the same problem as the other sse testcases. Sent from my iPhone On May 20, 2010, at 6:34 PM, "hjl dot tools at gmail dot com" > wrote: On Linux/x86, revision 159621: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00674.html caused FAIL: gcc.target/i386/3dnow-1.c (internal compiler error

[Bug middle-end/44185] [4.6 regression] New prefetch test failures

--- Comment #5 from hjl dot tools at gmail dot com 2010-05-21 01:41 --- The fix introduced: FAIL: gcc.dg/tree-ssa/prefetch-7.c scan-assembler-times movnti 18 FAIL: gcc.dg/tree-ssa/prefetch-7.c scan-tree-dump-times optimized "={nt}" 18 on Linux/ia32. -- hjl dot tools at gmail dot co

[Bug bootstrap/44220] Will not build on CentOS 5.5 (RHEL 5.5)

--- Comment #5 from jmalcolm at sigphi dot ca 2010-05-21 01:39 --- With more RAM, the compile completed successfully (In reply to comment #4) > I doubled the amount of RAM below and am trying again. I will update here if > it works. > > (In reply to comment #2) > > (In reply to commen

[Bug target/44222] New: [4.6 regression] Revision 159621 caused new x86 test failures

On Linux/x86, revision 159621: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00674.html caused FAIL: gcc.target/i386/3dnow-1.c (internal compiler error) FAIL: gcc.target/i386/3dnow-1.c (test for excess errors) FAIL: gcc.target/i386/3dnow-2.c (internal compiler error) FAIL: gcc.target/i386/3dnow-2.c (

[Bug middle-end/44206] [4.6 Regression] ICE: Inline clone with address taken

--- Comment #1 from hjl dot tools at gmail dot com 2010-05-21 01:16 --- It is caused by revision 159354: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00406.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44206

[Bug c++/44221] modulo of two variables results in: Floating point exception (core dumped)

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-21 00:33 --- x % 0u is undefined which is what you are running into. So an exception happens. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c++/44221] New: modulo of two variables results in: Floating point exception (core dumped)

The following code compiles, but fails to run as expected: #include int main() { for ( size_t ticks = 0; ticks < 100; ++ticks ) { for ( size_t ii = 0; ii < 10; ++ii ) { std::cout << ticks % ii << std::endl; } } } -- Summary: modulo of two varia

[Bug regression/43892] PowerPC suboptimal "add with carry" optimization

--- Comment #10 from dje at gcc dot gnu dot org 2010-05-21 00:28 --- > On my mpc8321 it is a big difference(don't have numbers handy). Why would > such a simply insn be a problem performance wise? > I know the kernel still uses the carry insn's for calculating the > Internet checksum. m

[Bug libstdc++/41792] [C++0x] overloading the address operator confuses the standard containers

--- Comment #7 from paolo dot carlini at oracle dot com 2010-05-20 22:38 --- Fixed, both -std=c++98 and -std=c++0x. -- paolo dot carlini at oracle dot com changed: What|Removed |Added ---

[Bug libstdc++/41792] [C++0x] overloading the address operator confuses the standard containers

--- Comment #6 from paolo at gcc dot gnu dot org 2010-05-20 22:36 --- Subject: Bug 41792 Author: paolo Date: Thu May 20 22:35:49 2010 New Revision: 159643 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159643 Log: 2010-05-20 Paolo Carlini PR libstdc++/41792 *

[Bug fortran/38407] Wishlist: -Wunused-dummy-argument and -Wno-unused-dummy-argument

--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-20 21:53 --- > It would be nice if -Wunused-dummy-argument would be split from > -Wunused-variable and also be moved from -Wall to -Wextra to make > it consistent with C, where -Wunused-parameter plays this role. Mostly done. We

[Bug fortran/38407] Wishlist: -Wunused-dummy-argument and -Wno-unused-dummy-argument

--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-20 21:49 --- Subject: Bug 38407 Author: dfranke Date: Thu May 20 21:49:07 2010 New Revision: 159641 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159641 Log: gcc/fortran/: 2010-05-20 Daniel Franke PR fortran

[Bug fortran/39427] F2003: Procedures with same name as types/type constructors

--- Comment #14 from burnus at gcc dot gnu dot org 2010-05-20 21:13 --- Created an attachment (id=20714) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20714&action=view) Updated draft Use Bugzilla as backup to make sure the patch does not get lost. Mostly regtests now (353 FAILS

[Bug bootstrap/44220] Will not build on CentOS 5.5 (RHEL 5.5)

--- Comment #4 from jmalcolm at sigphi dot ca 2010-05-20 21:06 --- I doubled the amount of RAM below and am trying again. I will update here if it works. (In reply to comment #2) > (In reply to comment #1) > > >xgcc: Internal error: Killed (program cc1) > > > > How much memory do you

[Bug target/43404] ARM: Internal compiler error when using '&foo' in naked function

--- Comment #7 from torsten at debian dot org 2010-05-20 20:47 --- This also hit me. I wanted to build a simple data logger for an ARM board. Of course I wanted to give gcc 4.4 a go (I used a compiler from the 3.x series before...), combined with current FreeRTOS (from www.freertos.org).

[Bug fortran/44213] ICE when extending abstract type

--- Comment #2 from janus at gcc dot gnu dot org 2010-05-20 20:36 --- The ICE is fixed by this more or less obvious patch: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 159561) +++ gcc/fortran/r

[Bug bootstrap/44220] Will not build on CentOS 5.5 (RHEL 5.5)

--- Comment #3 from jmalcolm at sigphi dot ca 2010-05-20 20:27 --- Starting the compile again from unpacked the tar file through to build stops in exactly the same spot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44220

[Bug fortran/44213] ICE when extending abstract type

--- Comment #1 from janus at gcc dot gnu dot org 2010-05-20 20:24 --- My first feeling was that this would be illegal, but I could not find anything in the standard supporting this feeling. F03 only has the following restrictions: C427 (R429) If the type definition contains or inherits (

[Bug bootstrap/44220] Will not build on CentOS 5.5 (RHEL 5.5)

--- Comment #2 from jmalcolm at sigphi dot ca 2010-05-20 20:21 --- (In reply to comment #1) > >xgcc: Internal error: Killed (program cc1) > > How much memory do you have? Do you have virtual memory setup? > MemTotal: 368864 kB MemFree: 14316 kB Buffers: 7844 kB

[Bug fortran/44212] [OOP] ICE when defining a pointer component before defining the class and calling a TBP then

--- Comment #2 from janus at gcc dot gnu dot org 2010-05-20 20:14 --- To fix this, one basically has to defer the generation of the vtype symbol to resolution stage, which is what the following patch does: Index: gcc/fortran/resolve.c ===

[Bug fortran/43851] Add _gfortran_error_stop_numeric

--- Comment #7 from jvdelisle at gcc dot gnu dot org 2010-05-20 19:40 --- Subject: Bug 43851 Author: jvdelisle Date: Thu May 20 19:40:30 2010 New Revision: 159638 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159638 Log: 2010-05-20 Jerry DeLisle PR fortran/43851

[Bug bootstrap/44220] Will not build on CentOS 5.5 (RHEL 5.5)

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-20 19:38 --- >xgcc: Internal error: Killed (program cc1) How much memory do you have? Do you have virtual memory setup? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug bootstrap/44220] New: Will not build on CentOS 5.5 (RHEL 5.5)

GCC 4.5 downloaded from http://mirror.csclub.uwaterloo.ca/gnu/ will not build on my CentOS 5.5 system. - System has all updates applied as of May 20, 2010 - Only base vendor supplied RPMS except for the following: - MySQL 5.5.3 as an RPM from OurDelta (unrelated I am sure) - Mono 2.6.4 built from

[Bug c++/30298] [4.3/4.4/4.5 regression] ICE with duplicate broken inheritance

-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com

[Bug c++/30298] [4.3/4.4/4.5/4.6 regression] ICE with duplicate broken inheritance

--- Comment #13 from paolo dot carlini at oracle dot com 2010-05-20 19:33 --- Fixed for 4.6.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Targ

[Bug c++/30298] [4.3/4.4/4.5/4.6 regression] ICE with duplicate broken inheritance

--- Comment #12 from paolo at gcc dot gnu dot org 2010-05-20 19:32 --- Subject: Bug 30298 Author: paolo Date: Thu May 20 19:31:47 2010 New Revision: 159637 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159637 Log: /cp 2010-05-20 Paolo Carlini PR c++/30298 *

[Bug fortran/39994] Bounds checking (-fcheck=bounds): "A = [ constructor ]" does not work

--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-20 19:19 --- (In reply to comment #2) > I believe that this is a duplicate of PR 31059. Me too. *** This bug has been marked as a duplicate of 31059 *** -- dfranke at gcc dot gnu dot org changed: What|Remove

[Bug fortran/31059] Detect nonconforming assignment of allocatable arrays

--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-20 19:19 --- *** Bug 39994 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/44212] [OOP] ICE when defining a pointer component before defining the class and calling a TBP then

--- Comment #1 from janus at gcc dot gnu dot org 2010-05-20 19:15 --- Confirmed. I think the code is valid. At least 'A_type' being defined after 'B_type' is not a problem, since the Fortran 2003 standard says: C438 (R440) If the POINTER attribute is not specified for a component, the d

[Bug c++/44219] Public inheritance treated as private

--- Comment #3 from zeljkoj at tesla dot rcub dot bg dot ac dot rs 2010-05-20 19:13 --- > > class A private members should be seen as private in class B > > No, they are private to A which means only A can access them, not any base > classes. If you want that, use protected. You are

[Bug fortran/44211] [OOP] ICE with TBP of pointer component of derived type array

--- Comment #1 from janus at gcc dot gnu dot org 2010-05-20 19:01 --- Confirmed. Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00571d67 in gfc_conv_scalarized_array_ref (se=0x7fffd6a0, ar=0x17f6048) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c:249

[Bug target/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2

-- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org |

[Bug bootstrap/43733] bootstrap fails on Solaris 10 x86 with GNU as 2.15 and --with-arch=core2

--- Comment #27 from uros at gcc dot gnu dot org 2010-05-20 18:52 --- Subject: Bug 43733 Author: uros Date: Thu May 20 18:52:03 2010 New Revision: 159636 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159636 Log: PR target/43733 * configure.ac (gcc_cv_as_ix86_sah

[Bug c++/44219] Public inheritance treated as private

--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-20 18:51 --- > class A private members should be seen as private in class B No, they are private to A which means only A can access them, not any base classes. If you want that, use protected. -- pinskia at gcc dot gnu dot

[Bug c++/44219] Public inheritance treated as private

--- Comment #1 from zeljkoj at tesla dot rcub dot bg dot ac dot rs 2010-05-20 18:51 --- Created an attachment (id=20713) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20713&action=view) Preprocessed source of the test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44219

[Bug c++/44219] New: Public inheritance treated as private

I apologize if this is not a bug, or if it has been reported (I thoroughly searched the bug database, but couldn't find anything related). When class B publicly inherit class A, class A private members should be seen as private in class B. However, they are not visible in class B (as if "public" ke

[Bug fortran/44207] ICE with ALLOCATABLE components and SOURCE

--- Comment #3 from janus at gcc dot gnu dot org 2010-05-20 18:45 --- Note: The ICE happens with 4.5 and trunk. With 4.4 one gets allocate(this%list(dim),source=[(i,i=1,dim)]) 1 Error: Syntax error in ALLOCATE statement at (1) since support for the SOURCE

[Bug target/44218] New: Improve powerpc -mrecip support

The current powerpc -mrecip can be improved in several areas. 1) The compiler generates a conditional test to deal with NaN, etc. even though it is only used with -ffast-math, where the programmer declares that he/she is not interested in Nan/infinity/etc. This causes the code to single thread th

[Bug target/44217] New: GCC emits cmpxchg16b which Sun as cannot handle

On Solaris 11/x86 with Sun as, two 64-bit libgomp testcases fail: FAIL: libgomp.c/atomic-2.c (test for excess errors) WARNING: libgomp.c/atomic-2.c compilation failed to produce executable FAIL: libgomp.c/atomic-5.c (test for excess errors) WARNING: libgomp.c/atomic-5.c compilation failed to produ

[Bug testsuite/28242] running the testsuite with -fstack-protector fail (not finding libssp)

--- Comment #2 from ro at gcc dot gnu dot org 2010-05-20 18:26 --- This is not an enhancement, but simply a bug: the testsuite should use the built libraries, not some version that happens (or not) to be installed on the system. -- ro at gcc dot gnu dot org changed: What

[Bug target/44199] ppc64 glibc miscompilation

--- Comment #12 from jakub at gcc dot gnu dot org 2010-05-20 18:23 --- If you could, it would be very much appreciated. Starting 4.4 bootstrap/regtest now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199

[Bug libgcj/44216] [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries

--- Comment #1 from ro at gcc dot gnu dot org 2010-05-20 18:23 --- Paolo, do you happen to have an idea how to handle this cleanly? -- ro at gcc dot gnu dot org changed: What|Removed |Added --

[Bug libgcj/44216] New: [4.6 regression] All libjava tests fail on IRIX 6.5: ld warns about -no-merge-exidx-entries

Since the introduction of the configure check for the --no-merge-exidx-entries linker option, all libjava tests fail on IRIX 6.5: output is: (null): WARNING 1 : Unknown option: -no-merge-exidx-entries (ignored). FAIL: linking PR9577 The problem is that the SGI ld warns about unknown options as

[Bug c++/44193] [4.3/4.4/4.5/4.6 Regression] function types, cv-quals and typename

--- Comment #5 from jason at gcc dot gnu dot org 2010-05-20 18:14 --- Fixed for 4.3.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASS

[Bug rtl-optimization/44214] Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)

--- Comment #2 from meissner at gcc dot gnu dot org 2010-05-20 18:02 --- Created an attachment (id=20712) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20712&action=view) Example program that shows the issue on powerpc. Compile with -mcpu=power7 on powerpc. -- http://gcc.gnu

[Bug rtl-optimization/44214] Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)

--- Comment #1 from meissner at gcc dot gnu dot org 2010-05-20 18:00 --- Actually in looking at it further, I was wrong in the initial claim. Auto vectorization now handles division by a constant. Explicit vectors like PowerPC (and probably SPU) do show the problem. -- http://gcc

[Bug target/44199] ppc64 glibc miscompilation

--- Comment #11 from pthaugen at gcc dot gnu dot org 2010-05-20 17:59 --- No I didn't bootstrap/regtest. I can take care of trunk if you want to do 4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199

[Bug c++/42101] Linking failure with static constants and ternary inline function

--- Comment #13 from pinskia at gcc dot gnu dot org 2010-05-20 17:53 --- *** Bug 44215 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/44215] undefinied reference with static constant initialized data member in conditional expression

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-20 17:53 --- *** This bug has been marked as a duplicate of 42101 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c++/44215] New: undefinied reference with static constant initialized data member in conditional expression

The following code raise undefined reference link errors: toto.C:(.text+0x10): undefined reference to `A::a' toto.C:(.text+0x18): undefined reference to `B::a' The code: struct A { static const int a = 0; }; struct B { static const int a = 1; }; int main() { bool b = true; retur

[Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets

--- Comment #21 from dje at gcc dot gnu dot org 2010-05-20 17:52 --- I tested the patch from comment #14 on top of the DECL_PRESERVE_P patch from PR 44132, which was necessary to get back to a sane level of C++ and libgomp failures on AIX. The DECL_DLLIMPORT_P and DECL_ATTRIBUTES patch

[Bug rtl-optimization/44214] New: Compiler does not optimize vector divide with -freciprocal-math (or -ffast-math)

If you have code that does division by a constant that can be auto vectorized by the compiler, the compiler does not convert the division to multiplication by the reciprocal if -freciprocal-math (or -ffast-math), but instead does the division. The bug is in fold-const.c near line 11254, where the

[Bug tree-optimization/43544] TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION can misoptimize when MD builtins overlap with standard builtins

--- Comment #4 from meissner at gcc dot gnu dot org 2010-05-20 17:39 --- Fix checked in on March 26, 2010. -- meissner at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/40483] gcc 4.x needs to utilize better COMDAT mechanism under Solaris

--- Comment #2 from ro at gcc dot gnu dot org 2010-05-20 17:15 --- Initial patch posted for COMDAT group with Sun as. Will require an updated configure test to work on SPARC, though. -- ro at gcc dot gnu dot org changed: What|Removed |Added --

[Bug debug/43521] java: "this" pointer not marked with DW_AT_artificial

--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-20 17:06 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug other/44210] Extended warning control: like -Wevery -show-warnings

--- Comment #4 from manu at gcc dot gnu dot org 2010-05-20 17:04 --- The manual documents what is enabled by -Wall and -Wextra and all other groups options. We will accept patches fixing any missing/mistaken entries. You could also propose some warnings to be moved to Wextra. Getting int

[Bug fortran/29800] -fbounds-check: For derived types, write not also compound name

--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-20 17:01 --- A proper come-on-and-pick-up testcase would be nice ... -- dfranke at gcc dot gnu dot org changed: What|Removed |Added -

[Bug debug/44178] -fcompare-debug failure with -O1 -fgcse -fsched-pressure -funroll-loops -fschedule-insns

--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-20 17:01 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug debug/43521] java: "this" pointer not marked with DW_AT_artificial

--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-20 17:00 --- Subject: Bug 43521 Author: jakub Date: Thu May 20 17:00:32 2010 New Revision: 159635 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159635 Log: PR debug/43521 * decl.c (start_java_method): Set

[Bug debug/44178] -fcompare-debug failure with -O1 -fgcse -fsched-pressure -funroll-loops -fschedule-insns

--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-20 16:59 --- Subject: Bug 44178 Author: jakub Date: Thu May 20 16:58:52 2010 New Revision: 159634 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159634 Log: PR debug/44178 * haifa-sched.c (initiate_bb_reg_p

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

--- Comment #21 from jason at gcc dot gnu dot org 2010-05-20 16:49 --- The alias_set_subset_of change isn't in 4.5? Then that's not what's making the libstdc++ function tests pass with the swap change reverted...:) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832

[Bug debug/44178] -fcompare-debug failure with -O1 -fgcse -fsched-pressure -funroll-loops -fschedule-insns

--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-20 16:35 --- Subject: Bug 44178 Author: jakub Date: Thu May 20 16:34:43 2010 New Revision: 159632 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159632 Log: PR debug/44178 * haifa-sched.c (initiate_bb_reg_p

[Bug target/44199] ppc64 glibc miscompilation

--- Comment #10 from jakub at gcc dot gnu dot org 2010-05-20 16:31 --- Have you also bootstrapped/regtested the patch? I can do so (easily for 4.4 branch, with more effort for the trunk), but haven't done that yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199

[Bug fortran/38407] Wishlist: -Wunused-dummy-argument and -Wno-unused-dummy-argument

--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-20 16:25 --- Patch: http://gcc.gnu.org/ml/fortran/2010-05/msg00242.html -- dfranke at gcc dot gnu dot org changed: What|Removed |Added --

[Bug target/44199] ppc64 glibc miscompilation

--- Comment #9 from pthaugen at gcc dot gnu dot org 2010-05-20 16:23 --- Spec testing went fine, differences in the noise range. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44199

[Bug other/44210] Extended warning control: like -Wevery -show-warnings

--- Comment #3 from redi at gcc dot gnu dot org 2010-05-20 16:14 --- (In reply to comment #2) > > -W is a synonym for -Wextra, so it is pointless to use both > This perfectly illustrates the problem; I have already spend hours digging Then I have misunderstood the problem. How does this

[Bug debug/44205] Wrong .debug_line for -O0 -g

--- Comment #3 from jan dot kratochvil at redhat dot com 2010-05-20 16:03 --- No regressions for FSF GDB HEAD x86_64-linux-gnu with FSF GCC HEAD. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44205

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

--- Comment #20 from rguenther at suse dot de 2010-05-20 15:44 --- Subject: Re: Revisit std::function for aliasing issues and efficiency On Thu, 20 May 2010, jason at gcc dot gnu dot org wrote: > --- Comment #19 from jason at gcc dot gnu dot org 2010-05-20 15:40 > --- > Aha

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

--- Comment #19 from jason at gcc dot gnu dot org 2010-05-20 15:40 --- Aha. That sounds good to me; I don't expect your testcase to work, because it doesn't involve a char buffer. The copy does need to use the object representation, but I think the new-expression should be undefined (t

[Bug middle-end/44185] [4.6 regression] New prefetch test failures

--- Comment #4 from spop at gcc dot gnu dot org 2010-05-20 15:30 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED

[Bug middle-end/44185] [4.6 regression] New prefetch test failures

--- Comment #3 from spop at gcc dot gnu dot org 2010-05-20 15:30 --- Subject: Bug 44185 Author: spop Date: Thu May 20 15:29:40 2010 New Revision: 159630 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159630 Log: Fix PR44185: new prefetch test failures. 2010-05-20 Changpeng Fan

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

--- Comment #18 from rguenther at suse dot de 2010-05-20 15:17 --- Subject: Re: Revisit std::function for aliasing issues and efficiency On Thu, 20 May 2010, jason at gcc dot gnu dot org wrote: > --- Comment #17 from jason at gcc dot gnu dot org 2010-05-20 15:13 > --- > Hmm

[Bug libstdc++/42832] Revisit std::function for aliasing issues and efficiency

--- Comment #17 from jason at gcc dot gnu dot org 2010-05-20 15:13 --- Hmm...I tried reverting the change to functional::swap, but all the libstdc++ tests still pass on x86_64-linux, and I haven't been able to write a failing testcase either. Anyone else have a testcase that still fails

[Bug driver/44210] Extended warning control: like -Wevery -show-warnings

--- Comment #2 from eric dot estievenart at free dot fr 2010-05-20 15:06 --- > -W is a synonym for -Wextra, so it is pointless to use both This perfectly illustrates the problem; I have already spend hours digging into the manual, what I attempted was to have as much warnings as possibl

[Bug middle-end/44197] [4.6 Regresssion] varpool SEGV

--- Comment #4 from hubicka at gcc dot gnu dot org 2010-05-20 14:57 --- Subject: Bug 44197 Author: hubicka Date: Thu May 20 14:57:27 2010 New Revision: 159629 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159629 Log: PR middle-end/44197 * varpool.c (varpool_remo

[Bug regression/43892] PowerPC suboptimal "add with carry" optimization

--- Comment #9 from joakim dot tjernlund at transmode dot se 2010-05-20 14:47 --- (In reply to comment #8) > Has anyone tested if generating an instruction sequence that uses the carry > bit > actually improves performance on modern POWER processors? It reduces the > number of instruc

[Bug debug/44205] Wrong .debug_line for -O0 -g

--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-20 14:44 --- Created an attachment (id=20711) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20711&action=view) gcc46-pr44205.patch Doing it at gimplification time would be actually very hard, we only create the continue labe

[Bug fortran/44213] New: [OOP] ICE when extending abstract type

module ice_module type :: a_type end type a_type type,extends(a_type),abstract :: b_type end type b_type type,extends(b_type) :: c_type end type c_type end module ice_module f951: interner Compiler-Fehler: in ensure_not_abstract, bei fortran/resolve.c:10559 -- Summary:

[Bug fortran/35849] "wrong" line shown in error message for parameter

--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-20 14:33 --- A similar example: $ cat conversion.f90 REAL(8), PARAMETER :: h = HUGE(0.0_8) real*4 x data x / h / end $ gfortran-svn -Wall conversion.f90 conversion.f90:1.28: REAL(8), PARAMETER :: h = HUGE(0.0_8)

[Bug regression/43892] PowerPC suboptimal "add with carry" optimization

--- Comment #8 from dje at gcc dot gnu dot org 2010-05-20 14:25 --- Has anyone tested if generating an instruction sequence that uses the carry bit actually improves performance on modern POWER processors? It reduces the number of instructions, which is good when optimizing for size, bu

[Bug rtl-optimization/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

--- Comment #19 from jason at gcc dot gnu dot org 2010-05-20 14:01 --- And changing component to rtl-opt. -- jason at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/44164] [4.5 Regression] Aliasing bug triggered by Boost.Bind/Boost.Function

--- Comment #18 from jason at gcc dot gnu dot org 2010-05-20 14:00 --- Unassigning myself. -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo

[Bug fortran/44212] New: [OOP] ICE when defining a pointer component before defining the class and calling a TBP then

module ice_module type :: B_type class(A_type),pointer :: A_comp ! A_type is not yet defined end type B_type type :: A_type contains procedure :: A_proc end type A_type contains subroutine A_proc(this) class(A_type),target,intent(inout) :: this end subroutine A_pro

[Bug fortran/40873] -fwhole-file -fwhole-program: Wrong decls cause too much to be optimized away

--- Comment #11 from pault at gcc dot gnu dot org 2010-05-20 13:51 --- (In reply to comment #10) Am I right in thinking that -fwhole-file could be enabled by default, if this PR were to be fixed? (The appropriate changes in the testsuite would have to be mad too.) Paul -- http://g

[Bug fortran/43851] Add _gfortran_error_stop_numeric

--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-05-20 13:33 --- Also have one tweak to do for blank STOP which I will fix shortly and add some test cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851

  1   2   >