[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

--- Comment #4 from tromey at gcc dot gnu dot org 2008-07-08 02:45 --- My guess is that comment #3 is the right theory, because this warning is issued from the front end. I did not investigate deeply though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

--- Comment #3 from paolo dot carlini at oracle dot com 2008-07-08 02:02 --- Or this pure C++ case is really just a missing TREE_NO_WARNING set somewhere (check_return_expr?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36760

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-08 01:40 --- By the way, apparently, even after the fix for c++/32256 and c++/32368, warnings keep coming from inside the system headers... Any idea why, Tom? Another case would be this one: http://gcc.gnu.org/ml/libstdc

[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c

--- Comment #8 from hjl dot tools at gmail dot com 2008-07-08 01:19 --- HFA stands for homogeneous floating point aggregates as specified in IA-64 Software Conventions and Runtime Architecture Guide. To pass complex float, if we run out of available FP argument registers, we will pass it

[Bug c++/36749] sizeof returns 0 for class

--- Comment #6 from paolo dot carlini at oracle dot com 2008-07-07 23:40 --- I see, thanks Wolfgang, I didn't check -pedantic, my bad... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36749

[Bug c++/36749] sizeof returns 0 for class

--- Comment #5 from bangerth at dealii dot org 2008-07-07 23:36 --- Zero-sized arrays are a GNU extension to the C++ standard. Since the compiler can't know the size of the object, sizeof returns zero. This behavior is documented in the "Extensions" part of the GCC manual, in the "Arrays

[Bug c++/36760] Simple std::bind use causes warnings with -Wextra

--- Comment #1 from paolo dot carlini at oracle dot com 2008-07-07 23:35 --- Doug, I'm sorry, can you have a look to this one too? I'm slightly confused, we have PR 36052, and then PR 30601, ... Seems that the warning is intended?!? Do we have to change bind?!? -- paolo dot carlini

[Bug c++/36699] not compile code, but must

--- Comment #1 from bangerth at dealii dot org 2008-07-07 23:30 --- Not a bug: type arguments to templates need to be *named* types with external linkage. The declaration of 'x' uses an unnamed structure, the declaration of 'z' a type of function-scope (and so internal) linkage. W. --

[Bug c++/36628] [c++0x] incorrect decltype() handling of conditional operator

--- Comment #3 from dgregor at gcc dot gnu dot org 2008-07-07 23:28 --- The problem here is that fold() is simplifying the expression before we look at its type. The simplification here turns something that's not a function call (a conditional expression) into a function call, thereby tr

[Bug c++/36641] erroneous ambiguous error for subclasses overloaded templated interfaces

--- Comment #2 from bangerth at dealii dot org 2008-07-07 23:17 --- Yes, the code is indeed ambiguous. Both icc and pgCC also agree. W. -- bangerth at dealii dot org changed: What|Removed |Added -

[Bug c++/36760] New: Simple std::bind use causes warnings with -Wextra

Consider: #include void f() {} void g() { std::bind(&f)(); } Compiling this with g++-svn -c -std=c++0x -Wextra gives: In file included from /home/eelis/soft/lib/gcc/i686-pc-linux-gnu/4.4.0/../../../../include/c++/4.4.0/functional:75, from t.cpp:1: /home/eelis/soft/lib/g

[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds

--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-07 22:46 --- > b = a(1:12) > Error: Different shape for array assignment at (1) on dimension 1 (1 and 12) > ? I don't have that many patches left. Hmm, I currently get the same (with all gfortrans I have). I really wonder why I d

[Bug middle-end/36753] [4.3/4.4 Regression] Forward propagation interacts badly with global register variable

--- Comment #4 from pinskia at gcc dot gnu dot org 2008-07-07 22:42 --- (In reply to comment #2) > If it's a bad language extension, why is it implemented? Because someone thought it was nice but it really hard to get correct as it changes the ABI. -- http://gcc.gnu.org/bugzilla/sh

[Bug fortran/36759] C_LOC and characters greater then one in length.

--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-07 22:41 --- > A = c_loc(arg1) >1 > Error: CHARACTER argument 'arg1' to 'c_loc' at (1) must have a length of 1 > > I'm not sure where this restriction comes from (it's not part of the > standard). One could argue

[Bug middle-end/36753] [4.3/4.4 Regression] Forward propagation interacts badly with global register variable

--- Comment #3 from slava at factorcode dot org 2008-07-07 22:41 --- So is this extension bad/deprecated or not? I'd appreciate a clarification from the gcc team. If the resolution is that this feature should simply not be used, I would strongly suggest removing it. Otherwise I'm not sur

[Bug middle-end/36753] [4.3/4.4 Regression] Forward propagation interacts badly with global register variable

--- Comment #2 from schlieper at unc dot edu 2008-07-07 22:38 --- If it's a bad language extension, why is it implemented? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36753

[Bug target/36736] [4.3 Regression] gfortran unrecognizable insn on sh4

--- Comment #7 from kkojima at gcc dot gnu dot org 2008-07-07 22:31 --- Subject: Bug 36736 Author: kkojima Date: Mon Jul 7 22:30:53 2008 New Revision: 137602 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137602 Log: Backport from mainline: PR target/36736

[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c

--- Comment #7 from drow at gcc dot gnu dot org 2008-07-07 22:31 --- Subject: Re: [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c On Mon, Jul 07, 2008 at 10:25:08PM -, hjl dot tools at gmail dot com wrote: > is incorrect for ia64 HFA. You can't do >

[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c

--- Comment #6 from hjl dot tools at gmail dot com 2008-07-07 22:25 --- assign_parm_remove_parallels: if (GET_CODE (entry_parm) == PARALLEL && GET_MODE (entry_parm) != BLKmode) { rtx parmreg = gen_reg_rtx (GET_MODE (entry_parm)); emit_group_store (parmreg, entry_parm,

[Bug target/36756] g++.dg/tls-3.C ICE with section-anchors, unit-at-a-time, no-toplevel-reorder

--- Comment #1 from janis at gcc dot gnu dot org 2008-07-07 21:59 --- There's an ICE in the same place for libgomp.fortran/appendix_a/a.22.7.f90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36756

[Bug middle-end/36758] [4.3/4.4 Regression] address addition moved out of the loop

--- Comment #2 from pinskia at gcc dot gnu dot org 2008-07-07 21:51 --- (In reply to comment #1) > 4.1.1 actually did the right thing. That is it produced: .L.f1: mflr 0 std 0,16(1) stdu 1,-128(1) .p2align 4,,15 .L3: addi 3,1,112 bl f0

[Bug fortran/36759] New: C_LOC and characters greater then one in length.

When I compile the code: PROGRAM main USE, INTRINSIC :: ISO_C_BINDING IMPLICIT NONE CHARACTER(LEN=2), TARGET :: arg1 = '12' TYPE(c_ptr) :: A A = c_loc(arg1) END PROGRAM main I get the error: A = c_loc(arg1) 1 Error: CHARACTER argument 'arg1' to 'c_loc' at (1) must have a

[Bug middle-end/36758] [4.3/4.4 Regression] address addition moved out of the loop

--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-07 21:36 --- 4.1.1 actually did the right thing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/36758] New: address addition moved out of the loop

Take the following testcase: extern int f0(int *); void f1() { int x; while (f0(&x)); } -- CUT --- Currently GCC produces: addi 31,1,112 .p2align 3,,7 .L2: mr 3,31 bl f0 nop cmpdi 7,3,0 bne 7,.L2 Notice how there is mr 3, 31 inside the l

[Bug middle-end/36757] New: __builtin_signbit should be type-generic

The function __builtin_signbit should be type-generic so that libraries can define the standard signbit macro with "#define signbit(x) __builtin_signbit(x)". (Mentioned several times before in the context of discussions of the other type-generic built-in functions, but doesn't seem to be filed in

[Bug target/36756] New: g++.dg/tls-3.C ICE with section-anchors, unit-at-a-time, no-toplevel-reorder

Test g++.dg/gomp/tls-3.C started failing on powerpc-unknown-linux-gnu with an ICE in rs6000_emit_move when the -O0 defaults were changed for -funit-at-a-time, -fsection-anchors, and -ftop-level-reorder. This smaller C test: __thread int i; int foo () { static __thread int k; return k; } gets

[Bug libfortran/36755] Avoid fork/exec in chmod intrinsic

--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-07 21:00 --- Why is really an issue anyways? chmod should not be used too much anyways. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug libfortran/36755] New: Avoid fork/exec in chmod intrinsic

The chmod intrinsic should be implemented with chmod () instead of fork/exec. -- Summary: Avoid fork/exec in chmod intrinsic Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: lib

[Bug c++/34963] [4.3/4.4 regression] ICE completely broken destructor

--- Comment #4 from simartin at gcc dot gnu dot org 2008-07-07 20:42 --- Subject: Bug 34963 Author: simartin Date: Mon Jul 7 20:42:03 2008 New Revision: 137598 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137598 Log: gcc/cp/ 2008-07-07 Simon Martin <[EMAIL PROTECTED]>

[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds

--- Comment #2 from dominiq at lps dot ens dot fr 2008-07-07 19:57 --- > Confirmed. How do I get: pr36754.f90:4.1: b = a(1:12) 1 Error: Different shape for array assignment at (1) on dimension 1 (1 and 12) ? I don't have that many patches left. -- http://gcc.gnu.org/bugzilla/sho

[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds

--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-07-07 19:51 --- Confirmed. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Severity|norma

[Bug fortran/36670] Missing compile-time checks on sum and product

--- Comment #2 from tkoenig at gcc dot gnu dot org 2008-07-07 19:48 --- Fixed on trunk. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/36341] MATMUL: Bounds check missing

--- Comment #16 from tkoenig at gcc dot gnu dot org 2008-07-07 19:47 --- Fixed both for compile-time and run-time on trunk. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/36670] Missing compile-time checks on sum and product

--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-07-07 19:46 --- Subject: Bug 36670 Author: tkoenig Date: Mon Jul 7 19:45:55 2008 New Revision: 137595 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137595 Log: 2008-07-07 Thomas Koenig <[EMAIL PROTECTED]> PR fo

[Bug fortran/36341] MATMUL: Bounds check missing (run time)

--- Comment #15 from tkoenig at gcc dot gnu dot org 2008-07-07 19:44 --- Subject: Bug 36341 Author: tkoenig Date: Mon Jul 7 19:43:33 2008 New Revision: 137594 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137594 Log: 2008-07-07 Thomas Koenig <[EMAIL PROTECTED]> PR

[Bug libfortran/34670] bounds checking for array intrinsics

--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-07-07 19:44 --- Subject: Bug 34670 Author: tkoenig Date: Mon Jul 7 19:43:33 2008 New Revision: 137594 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137594 Log: 2008-07-07 Thomas Koenig <[EMAIL PROTECTED]> PR fo

[Bug fortran/36754] New: Compile-time bound-checking for allocatable arrays with known bonds

The following bounds problem is not detected with gfortran at compile time (it is at run time): integer,allocatable :: a(:) integer :: b(1) allocate(a(12)) b = a(1:12) end Expected: The same output as NAG f95 has: Error: a.f90, line 4: Different vector lengths (1 and 12) -- Summar

[Bug fortran/36029] Off-by-one runtime bounds checking message

-- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||27766 nThis|| St

[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c

--- Comment #5 from hjl dot tools at gmail dot com 2008-07-07 19:37 --- A small testcase: [EMAIL PROTECTED] good]$ cat ../complex-7.c volatile _Complex float f1 = 1.1f + 2.2if; volatile _Complex float f2 = 3.3f + 4.4if; volatile _Complex float f3 = 5.5f + 6.6if; volatile _Complex float

[Bug middle-end/36753] [4.3/4.4 Regression] Forward propagation interacts badly with global register variable

--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-07 19:26 --- global register should really not be used anyways :). They are an example of a bad extension. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug middle-end/36753] Forward propagation interacts badly with global register variable

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot |

[Bug c/36753] New: Forward propagation interacts badly with global register variable

The attached test case is supposed to print '31337' when run. Correct output: [EMAIL PROTECTED] factor]$ gcc -O1 testcase.c [EMAIL PROTECTED] factor]$ ./a.out 31337 Correct output: [EMAIL PROTECTED] factor]$ gcc -O2 -fno-forward-propagate testcase.c [EMAIL PROTECTED] factor]$ ./a.out 31337 *In

[Bug c++/35396] possible incorrect optimization due to missed dependency

--- Comment #3 from hjl dot tools at gmail dot com 2008-07-07 19:00 --- The testcase is invalid. Please try #define DECL_CMPSWP(S,T,X) \ static inline T machine_cmpswp##S (volatile void *ptr, T value, T comparand ) \ { \ T result; \ \ __asm__ __volatile__("lock\ncm

[Bug target/34780] Bootstrapping libstdc++-v3 failed

--- Comment #11 from rwild at gcc dot gnu dot org 2008-07-07 18:55 --- The reported failure is fixed. However, building with --enable-maintainer-mode still fails due to this error, already described in : bin/sh ../libtool --tag C

[Bug middle-end/36583] [4.3/4.4 Regression] ICE on 5282/5206 at -O2

--- Comment #3 from eric dot norum at usask dot ca 2008-07-07 18:41 --- When I compile for an MC68040 target I don't get the fault. So the problem may be in the ColdFire-specific parts of the compiler. /usr/local/rtems/rtems-4.9/bin/m68k-rtems4.9-gcc --pipe -B/usr/local/rtems/rtems-4.

[Bug fortran/36751] assignment between allocatable arrays of different size causes glibc error

--- Comment #2 from dominiq at lps dot ens dot fr 2008-07-07 18:37 --- I don't see that on ppc/intel Darwin9, but the following modified code gives at run time: PROGRAM repro IMPLICIT NONE REAL(KIND=8), ALLOCATABLE :: a2(:,:), a(:,:) INTEGER(KIND=4) :: i, m, n m = 4 n = 3 A

[Bug other/36752] assembler error and segfault when compiling a wine 1.0 souce program with -O2

--- Comment #3 from johnlumby at hotmail dot com 2008-07-07 18:33 --- Subject: RE: assembler error and segfault when compiling a wine 1.0 souce program with -O2 Well, good question. I started off trying to report it to redhat , but the redhat bugzilla page asks what component, and

[Bug rtl-optimization/36663] IRA ICE in save_call_clobbered_regs at caller-save.c:1949

--- Comment #3 from vmakarov at redhat dot com 2008-07-07 18:30 --- Liveness info was missed in data-flow equation calculation for set free when the save/restore placement optimization was written. Fortunately, the case was catched by an assertion. The patch solving the problem has be

[Bug other/36752] assembler error and segfault when compiling a wine 1.0 souce program with -O2

--- Comment #2 from johnlumby at hotmail dot com 2008-07-07 18:29 --- Created an attachment (id=15873) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15873&action=view) core dump -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36752

[Bug rtl-optimization/36663] IRA ICE in save_call_clobbered_regs at caller-save.c:1949

--- Comment #2 from vmakarov at gcc dot gnu dot org 2008-07-07 18:29 --- Subject: Bug 36663 Author: vmakarov Date: Mon Jul 7 18:28:37 2008 New Revision: 137586 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137586 Log: 2008-07-07 Vladimir Makarov <[EMAIL PROTECTED]>

[Bug rtl-optimization/36673] IRA -O3 -fno-pic ICE in save_con_fun_n, at caller-save.c:1389

--- Comment #4 from vmakarov at gcc dot gnu dot org 2008-07-07 18:22 --- Subject: Bug 36673 Author: vmakarov Date: Mon Jul 7 18:21:28 2008 New Revision: 137585 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137585 Log: 2008-07-07 Vladimir Makarov <[EMAIL PROTECTED]>

[Bug rtl-optimization/36673] IRA -O3 -fno-pic ICE in save_con_fun_n, at caller-save.c:1389

--- Comment #3 from vmakarov at redhat dot com 2008-07-07 18:21 --- The case when saving mode or saving pseudo are different in the data-flow equation was missed when the save/restore placement optimization was written. Fortunately, the case was catched by the assertion. The patch solv

[Bug other/36752] assembler error and segfault when compiling a wine 1.0 souce program with -O2

--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-07 18:18 --- >--with-bugurl=http://bugzilla.redhat.com/bugzilla Why are you reporting this bug to us, when it says to report it to redhat? -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug target/34780] Bootstrapping libstdc++-v3 failed

--- Comment #10 from rwild at gcc dot gnu dot org 2008-07-07 18:17 --- Subject: Bug 34780 Author: rwild Date: Mon Jul 7 18:17:08 2008 New Revision: 137583 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137583 Log: gcc/ PR target/34780 * unwind-pe.h (size_of_enco

[Bug target/34780] Bootstrapping libstdc++-v3 failed

--- Comment #9 from rwild at gcc dot gnu dot org 2008-07-07 18:16 --- Subject: Bug 34780 Author: rwild Date: Mon Jul 7 18:16:04 2008 New Revision: 137582 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137582 Log: gcc/ PR target/34780 * unwind-pe.h (size_of_encod

[Bug rtl-optimization/36672] IRA + -fno-pic ICE in emit_swap_insn, at reg-stack.c:829

--- Comment #3 from vmakarov at gcc dot gnu dot org 2008-07-07 18:14 --- Subject: Bug 36672 Author: vmakarov Date: Mon Jul 7 18:13:13 2008 New Revision: 137581 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137581 Log: 2008-07-07 Vladimir Makarov <[EMAIL PROTECTED]>

[Bug c/36752] New: assembler error and segfault when compiling a wine 1.0 souce program with -O2

assembler error and segfault when compiling a wine 1.0 souce program with -O2 cd /ahbakup/sysbuild/wine-1.0/dlls/user32/tests;gcc -c -I. -I. -I../../../include -I../../../include -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits -Wpoi

[Bug rtl-optimization/36672] IRA + -fno-pic ICE in emit_swap_insn, at reg-stack.c:829

--- Comment #2 from vmakarov at redhat dot com 2008-07-07 18:07 --- Incorrect order in reload insn chain results in wrong reload inheritance which crashed the compiler. The patch solving the problem will follow soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36672

[Bug c++/35396] possible incorrect opitmization due to missed dependency

--- Comment #2 from hjl dot tools at gmail dot com 2008-07-07 18:03 --- I can reproduce it on Linux/x86. -- hjl dot tools at gmail dot com changed: What|Removed |Added

[Bug fortran/36751] assignment between allocatable arrays of different size causes glibc error

--- Comment #1 from sdirkse at gams dot com 2008-07-07 18:00 --- Created an attachment (id=15872) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15872&action=view) test case No flags required to reproduce: gfortran -o repro repro.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi

[Bug fortran/36751] New: assignment between allocatable arrays of different size causes glibc error

If I assign allocatable arrays of different size I get a glibc error and a backtrace. This happens with every version of gfortran I've tried, including 4.1, 4.3, and 4.4. The workaround is easy enough, but perhaps the compiler could be improved also. Here's the output: $gfortran --version GNU

[Bug target/36701] [4.4 Regression] unaligned access in gcc.c-torture/execute/complex-7.c

--- Comment #4 from hjl dot tools at gmail dot com 2008-07-07 17:50 --- Revision 137575 is the cause and revision 137575 doesn't help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36701

[Bug c/36750] New: -Wmissing-field-initializers relaxation request

While trying to compile coreutils with -Wextra, I noticed many warnings due to automatic variables initialized with { 0, }. As I understand it, since C90 the above will initialize [all members of] the type to that used in static scope, including any unused padding space in the structure. I.E. the

[Bug middle-end/36726] [4.4 Regression] ICE in move_stmt_r, at tree-cfg.c:5699 with -fopenmp

--- Comment #3 from jakub at gcc dot gnu dot org 2008-07-07 15:33 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug middle-end/36726] [4.4 Regression] ICE in move_stmt_r, at tree-cfg.c:5699 with -fopenmp

--- Comment #2 from jakub at gcc dot gnu dot org 2008-07-07 15:27 --- Subject: Bug 36726 Author: jakub Date: Mon Jul 7 15:26:35 2008 New Revision: 137572 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137572 Log: PR middle-end/36726 * f95-lang.c (poplevel): Don'

[Bug target/36713] [4.4 regression] r137252 breaks -O2 optimization on x86_64-unknown-linux-gnu

--- Comment #24 from rguenth at gcc dot gnu dot org 2008-07-07 15:16 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNE

[Bug target/36713] [4.4 regression] r137252 breaks -O2 optimization on x86_64-unknown-linux-gnu

--- Comment #23 from rguenth at gcc dot gnu dot org 2008-07-07 15:12 --- Subject: Bug 36713 Author: rguenth Date: Mon Jul 7 15:11:29 2008 New Revision: 137571 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=137571 Log: 2008-07-07 Richard Guenther <[EMAIL PROTECTED]>

[Bug c++/13699] Extern "C" routine in different namespaces accepted with different exception signature

--- Comment #3 from dseketel at redhat dot com 2008-07-07 14:54 --- Created an attachment (id=15871) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15871&action=view) first attempt at trying to fix the bug This patch checks that re-declaration of extern "C" functions complies with

[Bug c++/36749] sizeof returns 0 for class

--- Comment #4 from paolo dot carlini at oracle dot com 2008-07-07 14:38 --- I mean the entire snippet should be just rejected in the first place. In other terms, this is an accept-invalid. -- paolo dot carlini at oracle dot com changed: What|Removed

[Bug c++/36749] sizeof returns 0 for class

--- Comment #3 from limanski at narod dot ru 2008-07-07 14:29 --- (In reply to comment #2) > The problem is one of diagnostic: the code should be just rejected because Foo > is an incomplete type. > But the instanse of Foo can be created and both sizeof(Foo) and sizeof(foo) are equals

[Bug c++/36749] sizeof returns 0 for class

--- Comment #2 from paolo dot carlini at oracle dot com 2008-07-07 14:24 --- The problem is one of diagnostic: the code should be just rejected because Foo is an incomplete type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36749

[Bug c++/36749] sizeof returns 0 for class

--- Comment #1 from limanski at narod dot ru 2008-07-07 14:02 --- Created an attachment (id=15870) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15870&action=view) The test file for the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36749

[Bug c++/36749] New: sizeof returns 0 for class

The class contains only one array member with unspecified size has a zero size. The problem was reproduced on gcc 3.3.6 (Knoppix), 4.1.2 (Gentoo x86), 3.4.4. Also array with the zero size elements was created. The test file is attached. -- Summary: sizeof returns 0 for class

[Bug debug/36748] scev const-prop pass adds bad line numbers

--- Comment #1 from drow at gcc dot gnu dot org 2008-07-07 13:56 --- Created an attachment (id=15869) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15869&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36748

[Bug middle-end/36747] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4785 with -O

--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-07 13:51 --- I think this was fixed by 2008-06-25 Richard Guenther <[EMAIL PROTECTED]> * tree-ssa-structalias.c (fieldoff_compare): Make sure to not overflow the result type. as I can no longer reproduce this

[Bug debug/36748] New: scev const-prop pass adds bad line numbers

I'm testing inlined function support for GCC. When I compile the attached testcase with GCC (Debian's 4.3 package or unmodified trunk) and -g -O2, "break main" in the patched GDB puts a breakpoint at the start of main and again inside the inlined copy of factorial. This happens because there are

[Bug middle-end/36747] ICE in set_uids_in_ptset, at tree-ssa-structalias.c:4785 with -O

--- Comment #1 from burnus at gcc dot gnu dot org 2008-07-07 13:34 --- I can reproduce this with 4.3.1 (and "-O"). It works with 4.2.1 and 4.4.0. -- burnus at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/36726] [4.4 Regression] ICE in move_stmt_r, at tree-cfg.c:5699 with -fopenmp

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

[Bug fortran/36747] New: Internal compiler error

When compiling this stripped down fragment of code: subroutine dmnwgenod() integer dmnwmaxno,dmnwmaxme Parameter ( dmnwmaxno = 60, >dmnwmaxme = 200 ) integer dmnwmemli(dmnwmaxme,dmnwmaxno), >dmnwnodco common / dmwpnodes / dmnwmemli,

[Bug target/36745] [4.4 Regression] ICE in gen_reg_rtx, at emit-rtl.c:868

--- Comment #3 from krebbel at gcc dot gnu dot org 2008-07-07 12:35 --- The shorter testcase does not fail with -O2 -fPIC on GCC rev. 137553. But I can confirm the ICE with the first example. For large GOTs (>4k) we rewrite a symbol reference as a GOTENT relocation in the LEGITIMIZE_AD

[Bug preprocessor/36453] PR36320 breaks boost

--- Comment #4 from mueller at gcc dot gnu dot org 2008-07-07 09:25 --- well, lets keep it at that for now -- mueller at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/36570] segmentation fault

--- Comment #7 from aldot at gcc dot gnu dot org 2008-07-07 09:20 --- Closing as INVALID as suggested by the reporter. -- aldot at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/36745] [4.4 Regression] ICE in gen_reg_rtx, at emit-rtl.c:868

--- Comment #2 from mueller at gcc dot gnu dot org 2008-07-07 09:00 --- Created an attachment (id=15868) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15868&action=view) slightly shorter (different testcase, same bug) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36745

[Bug other/26208] Serious problem with unwinding through signal frames

--- Comment #32 from ebotcazou at gcc dot gnu dot org 2008-07-07 08:33 --- Jakub, the patch contains a workaround for the missing S in the CIE augmentation string for "old" kernels on PPC. Is this problem really specific to PPC? It seems that I'm seeing it on x86 too with 2.6.8 and 2.