[Bug fortran/31917] [4.1 only] GFORTRAN_CONVERT_UNIT is ignored

--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-23 08:44 --- > Do you plan a backport? If not, we should close this. I decided to backport it in the basis that the failures are difficult to track as there is not any feedback whether the environment are in effect or not. Additi

[Bug fortran/31917] [4.1 only] GFORTRAN_CONVERT_UNIT is ignored

--- Comment #7 from burnus at gcc dot gnu dot org 2007-05-23 08:44 --- Subject: Bug 31917 Author: burnus Date: Wed May 23 07:44:23 2007 New Revision: 124984 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124984 Log: 2007-05-23 Tobias Burnus <[EMAIL PROTECTED]> PR fortr

[Bug fortran/32046] [4.3 Regression] wrong code with -O2 for gfortran.dg/interface_12.f90 & result_in_spec_1.f90

--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-05-23 09:25 --- Subject: Bug 32046 Author: fxcoudert Date: Wed May 23 08:25:05 2007 New Revision: 124985 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124985 Log: PR fortran/32046 * trans-expr.c (gfc_tra

[Bug fortran/32046] [4.3 Regression] wrong code with -O2 for gfortran.dg/interface_12.f90 & result_in_spec_1.f90

--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-05-23 09:34 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSI

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #124 from rguenther at suse dot de 2007-05-23 09:35 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Tue, 22 May 2007, dberlin at dberlin dot org wrote: > --- Comment #116 from dberlin at gcc dot gnu dot org

[Bug objc++/32052] [4.3 Regression] encode-2.mm, encode-3.mm fail on at least powerpc-darwin

--- Comment #1 from matz at gcc dot gnu dot org 2007-05-23 09:36 --- The ObjC frontend seems to use IDENTIFIER_POINTER directly to produce this encoding. This doesn't contain template arguments anymore. And from quick reading of obj-act.c it's also not clear if it was really expecting

[Bug fortran/32046] [4.3 Regression] wrong code with -O2 for gfortran.dg/interface_12.f90 & result_in_spec_1.f90

--- Comment #10 from patchapp at dberlin dot org 2007-05-23 09:44 --- Subject: Bug number PR32046 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01499.html -- http://gcc.gnu.org/bugzilla/s

[Bug c++/32053] New: Anonymous union members' names should be distinct within enclosing scope

The following program should not compile: extern int foo; static union { int foo; // clash }; C++ standard clause 9.5/2 states that members of anonymous unions must have names distinct from other names in the same scope. If the `extern' keyword is removed from the example above, the error is di

[Bug c++/32054] New: Storage classes on anonymous unions in classes

The following program should not compile. class C { auto union // bad { int a; }; register union // bad { int b; }; static union // bad { int c; }; extern union // bad { int d; }; mutable union // bad { int e; };

[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use

--- Comment #8 from rguenth at gcc dot gnu dot org 2007-05-23 11:17 --- This particular case is indeed an optimization issue and __udivdi3 can be avoided by using volatile as stated and verified. -- rguenth at gcc dot gnu dot org changed: What|Removed

[Bug fortran/32048] max / min and NaN

--- Comment #5 from rguenth at gcc dot gnu dot org 2007-05-23 11:21 --- Of course people are complaining that min/max as of IEEE does not propagate NaNs as other operations do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32048

[Bug fortran/31219] ICE on array of character function results

--- Comment #8 from patchapp at dberlin dot org 2007-05-23 11:25 --- Subject: Bug number PR31219 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01540.html -- http://gcc.gnu.org/bugzilla/sh

[Bug fortran/32047] ICE (segfault) for pure function without argument

--- Comment #2 from pault at gcc dot gnu dot org 2007-05-23 11:36 --- I will submit a patch in a few minutes. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/32047] ICE (segfault) for pure function without argument

--- Comment #3 from patchapp at dberlin dot org 2007-05-23 11:55 --- Subject: Bug number PR32047 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01541.html -- http://gcc.gnu.org/bugzilla/sh

[Bug target/32055] New: reload failure building libgfortran

I have configured gcc (revision 124905) like this: /n/08/rask/src/gcc/configure --target=m32c-unknown-elf --with-gmp=${HOME}/opt --with-mpfr=${HOME}/opt --disable-nls --with-newlib --enable-sim --disable-multilib Building libgfortran fails with this ICE: /home/rask/build/gcc-m32c-unknown-elf/./gc

[Bug c++/32056] New: Storage classes on template parameters

None of the following should be accepted. template struct A {}; template struct B {}; template struct C {}; template struct D {}; template struct E {}; The extern, static and mutable are rejected with this message: t.cxx:2: error: storage class specifiers invalid in parameter declarations t

[Bug other/32051] Patch: Add GCC Extension Modules (GEM) to 4.1.1 4.2.1 4.3.0

--- Comment #7 from manu at gcc dot gnu dot org 2007-05-23 13:06 --- (In reply to comment #6) > Got "mid-air" colision message when clicking submit. I understand this is > closed. > What Andrew is trying to say in his particular way is that we cannot accept those patches (for the reaso

[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use

--- Comment #9 from manu at gcc dot gnu dot org 2007-05-23 13:15 --- (In reply to comment #3) > > The meaning of __builtin_expect is as defined in the documentation. > This particular transformation has nothing to do with __builtin_expect. > The transformation happens regardless of __bu

[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use

--- Comment #10 from malitzke at metronets dot com 2007-05-23 13:17 --- Mr. Guenther! The volatile fix would be fine, but (at least for me) does not work with the kernel. There is that little message: kernel/time.c:479: warning: passing argument 3 of 'div_long_rem_signed' discards qual

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #125 from gdr at cs dot tamu dot edu 2007-05-23 14:22 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "rguenther at suse dot de" <[EMAIL PROTECTED]> writes: [...] | But you can still perform hoisting loads of incom

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #126 from rguenther at suse dot de 2007-05-23 14:43 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Wed, 23 May 2007, gdr at cs dot tamu dot edu wrote: > --- Comment #125 from gdr at cs dot tamu dot edu 200

[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use

--- Comment #11 from malitzke at metronets dot com 2007-05-23 14:51 --- Mr. Ibanez! Thank you (muchas gracias) for looking at the matter from a user's point of view and considering my arguments concerning __builtin_expect. You seem to be the first to look at the timings and amount of co

[Bug testsuite/32057] New: Random failure on gfortran.dg/secnds.f

I got random failure on gfortran.dg/secnds.f, which has t1 = secnds (0.0) call date_and_time (dum1, dum2, dum3, values) t1a = secnds (0.0) dat1 = 0.001*real (values(8)) + real (values(7)) + &60.0*real (values(6)) + 3600.0* real (values(5)) if (((dat1 - t1

[Bug middle-end/32044] udivdi3 counterproductive, unwarranted use

--- Comment #12 from rguenth at gcc dot gnu dot org 2007-05-23 15:13 --- So this is now an enhancement request for sccp to honor loop roll count or basic-block frequency and cost of the replacement. Note the loop appears to be peeled twice before sccp already, but peeling doesn't decay

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #127 from ian at airs dot com 2007-05-23 15:23 --- Re comment #105. The case where TBAA is most useful is on a deeply pipelined in-order processor with multiple function units and a high latency memory cache. One example I've worked on is an embedded VLIW processor with vec

[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9

--- Comment #8 from bonzini at gnu dot org 2007-05-23 15:24 --- I have a Mac so I can fix this, but I'm not sure on the timing. I'm commenting out the BOOT_CFLAGS setting for a moment to unbreak bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009

[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9

--- Comment #9 from bonzini at gnu dot org 2007-05-23 15:26 --- Subject: Bug 32009 Author: bonzini Date: Wed May 23 14:26:31 2007 New Revision: 124990 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124990 Log: 2007-05-23 Paolo Bonzini <[EMAIL PROTECTED]> PR bootstrap/

[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f

--- Comment #1 from dominiq at lps dot ens dot fr 2007-05-23 15:34 --- > I assume the dummy loop is used for delay. I don't think it is that reliable. I think you are right about the delay, but not about the real problem: you have the same with secnds-1.f which does not cantain the loop

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #128 from rguenther at suse dot de 2007-05-23 15:37 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Wed, 23 May 2007, ian at airs dot com wrote: > --- Comment #127 from ian at airs dot com 2007-05-23 15:23

[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9

--- Comment #10 from dominiq at lps dot ens dot fr 2007-05-23 15:39 --- > I have a Mac so I can fix this, but I'm not sure on the timing. > I'm commenting out the BOOT_CFLAGS setting for a moment to unbreak bootstrap. I'll give a try tonight, but it should work (I am not sure to belie

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #129 from gdr at cs dot tamu dot edu 2007-05-23 15:59 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "rguenther at suse dot de" <[EMAIL PROTECTED]> writes: | Note that it is important to retain the capability to im

[Bug testsuite/32057] Random failure on gfortran.dg/secnds.f

--- Comment #2 from kargl at gcc dot gnu dot org 2007-05-23 16:05 --- > > Can't we use sleep here? > No. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32057

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #130 from ian at airs dot com 2007-05-23 16:43 --- In this example void foo(int *p) { float *f = (float *)p; new (p) float; *f = 1.0; } the pointer is p. In fact the relevant pointer is always the argument to placement new, and every pointer which PTA can associate w

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #131 from rguenther at suse dot de 2007-05-23 16:54 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Wed, 23 May 2007, ian at airs dot com wrote: > --- Comment #130 from ian at airs dot com 2007-05-23 16:43

[Bug c/32023] No casts in lvalue error message

--- Comment #10 from manu at gcc dot gnu dot org 2007-05-23 16:57 --- (In reply to comment #8) > The point I'm trying to express is that it's useful for user to have more > precise explanation. > Would you be happy with something like? t.c:9: error: lvalue required as increment operan

[Bug c/32023] No casts in lvalue error message

--- Comment #11 from nshmyrev at yandex dot ru 2007-05-23 17:06 --- Exactly :) Thanks Manuel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023

[Bug c++/32058] New: invalid computed void parameter in template

Can't return void from type function instantiation with dependent args for use in function declaration. all versions from 3.4 to the latest 4.3.0 build on x86 cygwin/linux complain with: error: invalid parameter type 'void' ... = template struct F { type

[Bug c/31673] "`for' loop initial declaration used outside C99 mode" is confusing

--- Comment #6 from manu at gcc dot gnu dot org 2007-05-23 17:36 --- (In reply to comment #1) > Created an attachment (id=13431) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13431&action=view) [edit] > Suggested patch. > Joerg, please test the patch and modify any failing testca

[Bug other/32051] Patch: Add GCC Extension Modules (GEM) to 4.1.1 4.2.1 4.3.0

--- Comment #8 from rob1weld at aol dot com 2007-05-23 17:57 --- Thanks Manuel. I "imagined" that since I read it at http://gcc.gnu.org/readings.html that the GEM would (or _might_) be incorporated in future. My "purpose" in posting: 1): The patches were posted MORE with the thought

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #132 from dberlin at gcc dot gnu dot org 2007-05-23 19:03 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On 23 May 2007 08:35:12 -, rguenther at suse dot de <[EMAIL PROTECTED]> wrote: > > > --- Comment #124

[Bug middle-end/30537] [4.3 regression] ICE with -fno-unit-at-a-time an inlining

--- Comment #3 from janis at gcc dot gnu dot org 2007-05-23 19:39 --- A regression hunt on powerpc-linux using the submitter's test case identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=120835 r120835 | hubicka | 2007-01-16 21:30:54 + (Tue, 16 Jan 200

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #133 from mark at codesourcery dot com 2007-05-23 19:43 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should ian at airs dot com wrote: > The case where TBAA is most useful is on a deeply pipelined in-order processor >

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #134 from rguenth at gcc dot gnu dot org 2007-05-23 19:54 --- But using a union for type-punning is a gcc extension (and of course the extension is only for access through the union), so with strict C99/C++ semantics we can avoid reloading d[i-1] even if a and d were in the

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #135 from rguenth at gcc dot gnu dot org 2007-05-23 19:56 --- Re comment #132 -- you cannot encode this into the IL :/ And I don't propose to do so. And I say any working and optimal (from optimization perspective) variant of a fix for this PR has the same problem. --

[Bug fortran/32059] New: include directives don't work with absolute pathnames

The "include" directive does not accept absolute path names that start with a "/". For example (below). If I use the absolute pathname, the compiler complains that it cannot find the file. Using the relative pathname works fine. module io contains subroutine hi3 !include "/data/L2TC/cmm/linux_

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #136 from mark at codesourcery dot com 2007-05-23 20:10 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenth at gcc dot gnu dot org wrote: > --- Comment #134 from rguenth at gcc dot gnu dot org 2007-05-23 19

[Bug fortran/32059] include directives don't work with absolute pathnames

--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-05-23 20:33 --- Which version of gfortran are you using? This may be a duplicate of PR 30276, which was fixed in 4.2 and 4.3, but not 4.1. Upgrading to 4.2 (which is now released) may help. If the problem persists in 4.2 or 4.3,

[Bug fortran/32059] include directives don't work with absolute pathnames

--- Comment #2 from Catherine dot M dot Moroney at jpl dot nasa dot gov 2007-05-23 20:39 --- Subject: Re: include directives don't work with absolute pathnames I'm using v4.1.1, which I'm stuck at for reasons of compatability with another computing center. Catherine On May 23, 2007,

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #137 from rguenth at gcc dot gnu dot org 2007-05-23 20:46 --- Created an attachment (id=13607) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13607&action=view) patch to perserve store ordering in loop load/store motion Gaby's claim is that given an arbitrary pointer

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #138 from rguenth at gcc dot gnu dot org 2007-05-23 20:57 --- Note the patch is not 100% correct as we need to preserve store ordering on the path to all exit edges which may be different for each exit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #139 from joseph at codesourcery dot com 2007-05-23 21:00 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Wed, 23 May 2007, mark at codesourcery dot com wrote: > Of course, Gaby's memory model doesn't allow thi

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #140 from mark at codesourcery dot com 2007-05-23 21:07 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenth at gcc dot gnu dot org wrote: > > Gaby's claim is that given an arbitrary > pointer "p", saying: > >

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #141 from mark at codesourcery dot com 2007-05-23 21:13 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should joseph at codesourcery dot com wrote: > DR#236 wa

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #142 from rguenther at suse dot de 2007-05-23 21:14 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Wed, 23 May 2007, mark at codesourcery dot com wrote: > --- Comment #140 from mark at codesourcery dot com

[Bug ada/31174] [4.2 regression] ACATS C380004 fails

--- Comment #4 from anhvofrcaus at gmail dot com 2007-05-23 21:19 --- Now ACATS c380004 passes in gcc-4.3-20070518. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31174

[Bug middle-end/31685] [4.3 regression] ICE in set_mem_attributes

--- Comment #3 from janis at gcc dot gnu dot org 2007-05-23 21:26 --- A regression hunt on powerpc-linux using the test case from comment #1 identified the following patch: http://gcc.gnu.org/viewcvs?view=rev&rev=120835 r120835 | hubicka | 2007-01-16 21:30:54 + (Tue, 16 Jan

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #143 from mark at codesourcery dot com 2007-05-23 21:27 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenther at suse dot de wrote: > >> void f(int *p) { >> *p = 3; >> } >> >> under Gaby's interpretation

[Bug testsuite/32060] New: gcc/testsuite/gcc/gcc.log - WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator

Thread model: posix gcc version 4.3.0 20070523 (experimental) --- # grep -B 5 -A 5 gcc.dg-struct-layout-1_generate gcc/testsuite/gcc/gcc.log FAIL: gcc.dg/compat/vector-2 c_compat_x_tst.o-c_compat_y_tst.o execute testcase /root/downloads/gcc-4_3-trunk/gcc/testsuite/gcc.dg/compat/compat.exp

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #144 from rguenther at suse dot de 2007-05-23 21:48 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On Wed, 23 May 2007, mark at codesourcery dot com wrote: > rguenther at suse dot de wrote: > > > >> void f(int *

[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9

--- Comment #11 from dominiq at lps dot ens dot fr 2007-05-23 21:48 --- With the last patch the build passed the critical point!-) I'll have the full build tomorrow morning (Paris time). Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009

[Bug preprocessor/20077] [4.0/4.1/4.2/4.3 Regression] GCC accepts macro definitions that fail a constraint

--- Comment #7 from simartin at gcc dot gnu dot org 2007-05-23 21:58 --- Subject: Bug 20077 Author: simartin Date: Wed May 23 20:58:34 2007 New Revision: 125000 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125000 Log: 2007-05-23 Simon Martin <[EMAIL PROTECTED]> PR

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #145 from dberlin at gcc dot gnu dot org 2007-05-23 22:02 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should On 23 May 2007 18:57:03 -, rguenth at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Commen

[Bug preprocessor/20077] [4.0/4.1/4.2/4.3 Regression] GCC accepts macro definitions that fail a constraint

--- Comment #8 from simartin at gcc dot gnu dot org 2007-05-23 22:05 --- Fixed on the mainline. -- simartin at gcc dot gnu dot org changed: What|Removed |Added

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #146 from mark at codesourcery dot com 2007-05-23 22:13 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenther at suse dot de wrote: > Only so much that we seem to agree on the semantics of placement new. > Gaby

[Bug other/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

--- Comment #2 from sje at cup dot hp dot com 2007-05-23 22:19 --- I am not sure what, if anything, we should do with this bug report. The compiler is working as designed, the test case has a very large number of nested parenthesis which causes the parser to recurse over and over as it

[Bug boehm-gc/21942] boehm-gc doesn't compile on Solaris 10/amd64

--- Comment #6 from philip_walker at raytheon dot com 2007-05-23 22:43 --- I experienced the same error trying to compile 4.2.0 using gcc 4.1.2. gcc -v output is: Target: i386-pc-solaris2.10 configured with: ./configure --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/

[Bug java/32010] bootstrap fails; chooses wrong zlib for building jc1

--- Comment #1 from lucier at math dot purdue dot edu 2007-05-23 23:11 --- I believe you need to add BOOT_LDFLAGS='-Wl,-search_paths_first' to "make bootstrap" to get it to work. If this fixes bootstrap, then I'll prepare a brief patch to the documentation. -- http://gcc.gnu.org

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #147 from gdr at cs dot tamu dot edu 2007-05-23 23:42 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: | Of course, Gaby's memory model doesn't allow this op

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #148 from gdr at cs dot tamu dot edu 2007-05-23 23:50 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: | Gaby's claim, as I understand it, is that writing to

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #149 from gdr at cs dot tamu dot edu 2007-05-23 23:56 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: | --- Comment #140 from mark at codesourcery dot c

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #150 from gdr at cs dot tamu dot edu 2007-05-23 23:57 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: | Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement

[Bug c/32061] New: wrong warning wording

This warning is logically incorrect: logical '&&' with non-zero constant will always evaluate as true should say '... will have no effect'? Reproduce with == /* run: gcc -v -save-temps -Wlogical-op -c xx.c */ #define FORCE 1 #define FLAG1 static int func (int resp, int flags) {

[Bug c/32061] wrong warning wording

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-24 00:47 --- I don't see the problem because "xx.c:7: warning: logical '&&' with non-zero constant will always evaluate as true" means the non-zero constant will evaluate as true and not the logical will evaluate as true. --

[Bug other/31827] limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure

--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-05-24 00:53 --- Subject: Re: limits-exprparen.c: Pid 2297 received a SIGSEGV for stack growth failure > This test runs fine on my IA64 HP-UX and Linux boxes and on my HPPA HP-UX > boxes > where I have increased the stack

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #151 from gdr at cs dot tamu dot edu 2007-05-24 00:58 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "rguenther at suse dot de" <[EMAIL PROTECTED]> writes: [...] | > Gaby's model says that we know less about dynam

[Bug c/32061] wrong warning wording

--- Comment #2 from eyal at eyal dot emu dot id dot au 2007-05-24 01:00 --- (In reply to comment #1) > I don't see the problem because > "xx.c:7: warning: logical '&&' with non-zero constant will always evaluate as > true" > means the non-zero constant will evaluate as true and not the

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #152 from gdr at cs dot tamu dot edu 2007-05-24 01:06 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: [...] | However, I don't like this approach because I

[Bug testsuite/32062] New: gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes "UNSUPPORTED" for working tests

I have 4.3.0 SVN 20070523 and just updated it a minute ago to "revision 125011". I ran "make -i check" and noticed a number of UNSUPPORTED in the "C" tests. # grep -B 5 -A 0 15233 gcc/testsuite/gcc/gcc.log PASS: gcc.target/i386/sse3-movshdup.c execution test E

[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes "UNSUPPORTED" for working tests

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-24 01:56 --- What binutils version do you have? Check via "as --version". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32062

[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes "UNSUPPORTED" for working tests

--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-24 02:01 --- The check in gcc/gcc/testsuite/gcc.target/i386/i386.exp checks if pabsd128 works, so that means if that does not work, then all the testcases will cause an unsupported. This is not really a bug, as the unsupported

[Bug fortran/32059] include directives don't work with absolute pathnames

--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-24 02:17 --- *** This bug has been marked as a duplicate of 30276 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/30276] gfortran include problem

--- Comment #12 from pinskia at gcc dot gnu dot org 2007-05-24 02:17 --- *** Bug 32059 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/30276] gfortran include problem

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.1 4.2.0 4.3.0 |4.1.1 Known to work||4.2.0 4.3.0

[Bug java/32010] bootstrap fails; chooses wrong zlib for building jc1

--- Comment #2 from lucier at math dot purdue dot edu 2007-05-24 02:19 --- My guess was correct, but I don't see where to put the note in the documentation. Perhaps I'll ask Jack to do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32010

[Bug c++/32058] invalid computed void parameter in template

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-24 02:56 --- GCC is correct, this code is invalid C++. See PR 9278. *** This bug has been marked as a duplicate of 9278 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/9278] Illegal use of typedef to "void"

--- Comment #26 from pinskia at gcc dot gnu dot org 2007-05-24 02:56 --- *** Bug 32058 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/32042] linkage confused with scope?

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-24 03:11 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCON

[Bug c++/32029] Internal Compiler Error on instantiation of template parameter

--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-24 03:18 --- Here is a reduced testcase: template struct Factory0Arg { template struct Factory { }; }; template::Factory > struct thing { Al allocator; }; thing t; -- http://gcc.gnu.org/bugzilla/show_

[Bug testsuite/32063] New: "contrib/test_summary" script could output results more neatly

r script, here is an example: ---START--- /opt/gcc-4_3-build/gcc/testsuite/gfortran/../../gfortran version 4.3.0 20070523 (experimental) === gnat tests === Running target unix FAIL: gnat.dg/address_conversion.adb execution test === gnat Summary === # of expected p

[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes "UNSUPPORTED" for working tests

--- Comment #3 from rob1weld at aol dot com 2007-05-24 04:39 --- # as --version GNU assembler 2.17 Debian GNU/Linux That is the _newest_ apt-get from Debian. My test results are here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg01171.html > This is not really a bug, as the unsu

[Bug testsuite/32062] gcc revision 20070523 - Non-existant sse4 test (with wrong path) causes "UNSUPPORTED" for working tests

--- Comment #4 from rob1weld at aol dot com 2007-05-24 06:01 --- According to this page: http://www.gnu.org/software/binutils/ The newest version is being called binutils-2.17.50 (name for snapshot). ftp://sourceware.org/pub/binutils/snapshots/ 05/17/2006 12:00AM 13,716,872 binutil

[Bug fortran/31716] segfault with real array bounds

--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-05-24 06:04 --- Subject: Bug 31716 Author: jvdelisle Date: Thu May 24 05:03:51 2007 New Revision: 125013 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125013 Log: 2007-05-23 Jerry DeLisle <[EMAIL PROTECTED]>

[Bug bootstrap/30341] Makefile using mv instead of ln not working on WinXP Cygwin Bash

--- Comment #4 from rob1weld at aol dot com 2007-05-24 06:05 --- I have found that with very low system load that it _can_ occur using an XTerm window afterall - infrequently. If your compiling for Cygwin it is best to make the mod to the Makefile. -- http://gcc.gnu.org/bugzilla/sh

[Bug fortran/31716] segfault with real array bounds

--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-05-24 06:05 --- Fixed on trunk. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added S

[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap

--- Comment #11 from daney at gcc dot gnu dot org 2007-05-24 06:06 --- Reduced testcase: g++.dg/abi/thunk3.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975

[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap

--- Comment #12 from daney at gcc dot gnu dot org 2007-05-24 06:08 --- Fails with: -mno-shared OK with: -mshared -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975

[Bug libmudflap/31845] Need to adjust libmudflap timeout values in testsuite.

--- Comment #1 from rob1weld at aol dot com 2007-05-24 06:15 --- This has not happened in the last few weeks. It _might_ be fixed. I would need to wait until I'm doing a half a dozen things at once and had a high load; while compiling gcc. If a maintainer happens across this bug report

[Bug bootstrap/32009] [4.3 Regression] building gcc4-4.3.0-20070518 failed on OSX 10.3.9

--- Comment #12 from andreast at gcc dot gnu dot org 2007-05-24 06:21 --- build completed. As expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009

[Bug fortran/31964] [4.2, 4.1 only]ishftc fails with certain thrid argument

--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-05-24 06:22 --- Subject: Bug 31964 Author: jvdelisle Date: Thu May 24 05:22:32 2007 New Revision: 125014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125014 Log: 2007-05-23 Jerry DeLisle <[EMAIL PROTECTED]>

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

I got Executing on host: /export/build/gnu/gcc-isa/build-i686-linux/gcc/xgcc -B/export/build/gnu/gcc-isa/build-i686-linux/gcc/ stack_prot30163.c -fstack-protector -fno-show-column -lm -o stack_prot30163.x(timeout = 300) /usr/local/bin/ld: cannot find -lssp_nonshared^M collect2: ld returned

  1   2   >