With revision 132792, I got
FAIL: tr1/2_general_utilities/shared_ptr/assign/shared_ptr_neg.cc (test for
excess errors)
on Linux/Intel64. Revision 132763 is OK.
--
Summary: [4.4 Regression]
tr1/2_general_utilities/shared_ptr/assign/shared_ptr_neg
With revision 132792, I got
FAIL: 20_util/shared_ptr/assign/shared_ptr_neg.cc (test for excess errors)
on Linux/Intel64. Revision 132763 is OK.
--
Summary: [4.4 Regression]
20_util/shared_ptr/assign/shared_ptr_neg.cc
Product: gcc
Version: 4.
--- Comment #4 from dgregor at gcc dot gnu dot org 2008-03-01 05:38 ---
Subject: Bug 35315
Author: dgregor
Date: Sat Mar 1 05:37:41 2008
New Revision: 132798
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132798
Log:
2008-02-29 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #9 from pinskia at gmail dot com 2008-03-01 04:19 ---
Subject: Re: static object mangling conflicts with extern object
Sent from my iPhone
On Feb 29, 2008, at 20:05, "geoffk at geoffk dot org" <[EMAIL PROTECTED]
> wrote:
>
>
> --- Comment #8 from geoffk at geoffk do
Sent from my iPhone
On Feb 29, 2008, at 20:05, "geoffk at geoffk dot org" <[EMAIL PROTECTED]
> wrote:
--- Comment #8 from geoffk at geoffk dot org 2008-03-01 04:05
It should be mangled, because there are still three different things
named 'i' declared in this program, and so
--- Comment #8 from geoffk at geoffk dot org 2008-03-01 04:05 ---
Subject: Re: static object mangling conflicts with extern object
On 29/02/2008, at 5:57 AM, mueller at gcc dot gnu dot org wrote:
> extern "C" void abort();
> extern "C" { static int i; }
> int *p = &i;
> int main()
>
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-01 01:55 ---
*** Bug 35414 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-01 01:55 ---
*** This bug has been marked as a duplicate of 35373 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
This is with:
Last Changed Rev: 132782
Last Changed Date: 2008-02-29 22:50:25 + (Fri, 29 Feb 2008)
../../../gcc44/libgfortran/generated/maxloc1_4_r16.c: In function
'mmaxloc1_4_r16':
../../../gcc44/libgfortran/generated/maxloc1_4_r16.c:220: internal compiler
error: in memory_address, at explo
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-03-01 00:28 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-01 00:28 ---
Subject: Bug 35411
Author: rguenth
Date: Sat Mar 1 00:27:26 2008
New Revision: 132791
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132791
Log:
2008-03-01 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu
2008-02-29 23:52 ---
Subject: Re: scope of variables in statement function do not acquire rank from
host
>
> Don't worry, I share your confusion (when I read the standard). :)
>
> I think the passage you quote appli
--- Comment #2 from steven at gcc dot gnu dot org 2008-02-29 23:36 ---
PR19020 shows that -ftrapv vs. libcalls is broken even without Paolo's patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-29 23:33 ---
-ftrapv is seriously broken and nobody wants to fix it; so the most appealing
solution is to remove support for -ftrapv. See PR19020, especially the
libcall part is broken as well.
--
rguenth at gcc dot gnu dot
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDependsOn||35404, 35412
Status|UNCONFIRMED |NEW
This is a placeholder bug to collect references to all issues that cause GCC to
still require libcall notes.
--
Summary: [meta-bug] Remaining issues blocking the removal of
libcall notes from the compiler
Product: gcc
Version: unknown
See http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01011.html
``When -ftrapv is in effect, libcalls are "necessary" so that the results of an
operation can be propagated without making the call to the libgcc functions
dead. The attached patch causes a failure in pr30286.c.''
This has to be investig
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-29 23:08 ---
tmp4.field = () SR.447_374;
which SRA creates is invalid GIMPLE.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2008-02-29 23:05 ---
Subject: Re: scope of variables in statement function do not acquire rank from
host
On Fri, Feb 29, 2008 at 10:55:31PM -, fxcoudert at gcc dot gnu dot org
wrote:
>--- Comment #6 from fxcoudert
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-29 23:00 ---
While I cannot reproduce this on x86_64 I know what can cause it ;)
So, mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2008-02-29 22:55
---
I've thought about it more, and it's probably going to be tricky to solve:
after we have matched the formal arglist, we need to fill the namespace with
replacement symbols for all the dummy args (stripping them fr
--- Comment #17 from rguenth at gcc dot gnu dot org 2008-02-29 22:52
---
A regression according to comments. P2.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-02-29 22:51
---
Subject: Bug 35059
Author: jvdelisle
Date: Fri Feb 29 22:50:25 2008
New Revision: 132782
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132782
Log:
2008-02-29 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #16 from agn at noc dot soton dot ac dot uk 2008-02-29 22:30
---
Many thanks to Jack Howarth for putting in this work to sort out the bug.
Given the comments on the gcc list, I'll reduce the severity of the bug from
blocker to critical.
What originally brought this bug to
--- Comment #2 from tromey at gcc dot gnu dot org 2008-02-29 21:56 ---
Confirmed.
We probably need to make and upload a new canonical ecj jar.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-02-29 21:42 ---
Subject: Bug 35315
Author: dgregor
Date: Fri Feb 29 21:41:38 2008
New Revision: 132779
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132779
Log:
2008-02-29 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #3 from ismail at namtrac dot org 2008-02-29 21:28 ---
This also fails on i686-apple-darwin9 so its not powerpc specific.
--
ismail at namtrac dot org changed:
What|Removed |Added
le-languages=c,c++ --with-gxx-include-dir=/usr/include/c++/4.0.0
--build=i686-apple-darwin9 --with-arch=nocona --with-tune=generic --disable-nls
--disable-mudflap --disable-libmudflap --disable-libssp
Thread model: posix
gcc version 4.4.0 20080229 (experimental) [trunk revision 132769] (GCC)
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-29 21:04 ---
The java source compiler has been removed so this is mostly a ecj bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35410
--- Comment #68 from uros at gcc dot gnu dot org 2008-02-29 20:56 ---
Subject: Bug 25477
Author: uros
Date: Fri Feb 29 20:55:19 2008
New Revision: 132777
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132777
Log:
PR middle-end/19984
* builtins.def (BUILT_IN_NAN):
--- Comment #4 from uros at gcc dot gnu dot org 2008-02-29 20:56 ---
Subject: Bug 19984
Author: uros
Date: Fri Feb 29 20:55:19 2008
New Revision: 132777
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132777
Log:
PR middle-end/19984
* builtins.def (BUILT_IN_NAN):
The clone() method for array types incorrectly returns Object. But the
JLS3, 10.7 Array Members states: "The members of an array type are all
of the following: [...] The return type of the clone method of an array
type T[] is T[]."
The following Java class triggers the problem:
public class Test
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2008-02-29 20:41 ---
Subject: Re: scope of variables in statement function do not acquire rank from
host
On Fri, Feb 29, 2008 at 08:23:16PM -, fxcoudert at gcc dot gnu dot org
wrote:
> (In reply to comment #3)
> >
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2008-02-29
20:31 ---
Created an attachment (id=15249)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15249&action=view)
differences between Makefile's generated in libgfortran with and without
r131198
--
http://gcc.g
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2008-02-29
20:29 ---
I would also add that despite having different linkages...
otool -L
/sw/src/fink.build/gcc43-4.3.0-20080226/darwin_objdir/powerpc-apple-darwin9/ppc64/libgfortran/.libs/libgfortran.3.dylib
/sw/src/fink.bui
--- Comment #2 from axelbergerhoff at compuserve dot com 2008-02-29 20:29
---
(In reply to comment #1)
> --prefix=/usr --libdir=/usr/lib64 \
> --libexecdir=/usr/lib64
>
> Why are you trying to build a system compiler?
>
I'm building a system.
But these options should not cause li
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-02-29 20:23
---
(In reply to comment #3)
> The dummy arguments have a scope of the statement function. Each
> dummy argument has the same type and type parameters as the
> entity of the same name in the scoping unit conta
--- Comment #13 from howarth at nitro dot med dot uc dot edu 2008-02-29
20:17 ---
Created an attachment (id=15248)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15248&action=view)
link commands on powerpc-apple-darwin9 for libgfortran without r131198
--
http://gcc.gnu.org/bug
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2008-02-29
20:17 ---
Created an attachment (id=15247)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15247&action=view)
link commands on powerpc-apple-darwin9 for libgfortran with r131198
--
http://gcc.gnu.org/bugzil
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2008-02-29
20:15 ---
In case anyone sees something I am missing, I have attached the link commands
for libgfortran.dylib from a gcc 4.3.0 build on powerpc-apple-darwin9 with
(libgfortran_badlink.txt) and without (libgfortran_g
--- Comment #3 from sgk at troutmask dot apl dot washington dot edu
2008-02-29 20:15 ---
Subject: Re: scope of variables in statement function do not acquire rank from
host
On Fri, Feb 29, 2008 at 05:53:40PM -, fxcoudert at gcc dot gnu dot org
wrote:
> I disagree. In Fortran 2003
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-02-29 19:50
---
(In reply to comment #2)
> Tobias, what target and options are you compiling with? I can't reproduce this
> on x86_64-linux...
Nor on i686-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34955
--- Comment #2 from ian at airs dot com 2008-02-29 18:43 ---
Whoops, you have to use to -fno-split-wide-types, not -fno-wide-types. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35404
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-02-29 18:27
---
The following patch fixes it, but I don't know yet if it regtests...
Index: trans-array.c
===
--- trans-array.c (revision 132578)
+++ trans-ar
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-02-29 17:53
---
I disagree. In Fortran 2003 12.5.4, C1263/R1238 says "The function-name and
each dummy-arg-name shall be specified, explicitly or implicitly, to be
scalar.". Intel accepts it, but IBM, g95 and (most importantly) L
i386-modes.def has
---
/* In ILP32 mode, XFmode has size 12 and alignment 4.
In LP64 mode, XFmode has size and alignment 16. */
ADJUST_FLOAT_FORMAT (XF, (TARGET_128BIT_LONG_DOUBLE
? &ieee_extended_intel_128_format
: TARGET_96_ROUND_53_LONG_DOUBL
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-02-29 17:12 ---
--prefix=/usr --libdir=/usr/lib64 \
--libexecdir=/usr/lib64
Why are you trying to build a system compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35407
libgjsmalsa.la (32 bit) is built, 64 bit version fails
same with gcc-4.2.2 and 4.2.3
Tools used:
binutils 2.18.0
gmp 4.2.2
bison 2.3
m41.4.10
flex 2.5.33
expect5.43.0
dejagnu 1.4.4
makeinfo 4.11
libtool 1.5.24
gcc 4.2.2 w/o java
gcc -v
Using built-in specs.
T
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2008-02-29
16:52 ---
Regressing r131198 eliminates the problem here...
otool -L libgfortran.3.dylib
libgfortran.3.dylib:
/sw/lib/gcc4.3/lib/libgfortran.3.dylib (compatibility version 4.0.0,
current version 4.0.0)
--- Comment #9 from howarth at nitro dot med dot uc dot edu 2008-02-29
16:12 ---
I'm positive I tested the committed patch...
Author: bonzini
Date: Wed Dec 19 14:28:32 2007
New Revision: 131062
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131062
Log:
2007-12-19 Etsushi Kato
--- Comment #3 from sam at gcc dot gnu dot org 2008-02-29 16:10 ---
Tero,
your patch is similar to the one I proposed a few days ago :)
http://thread.gmane.org/gmane.comp.gcc.patches/157295
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35050
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-02-29 16:05 ---
CCing a build system maintainer.
Did this ever work? That is, is this a regression?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2008-02-29
16:03 ---
Could this problem be caused by...
Author: rsandifo
Date: Thu Dec 27 11:26:06 2007
New Revision: 131198
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131198
Log:
libgcc/
* Makefile.in (all
--- Comment #2 from tero dot koskinen at iki dot fi 2008-02-29 15:52
---
Created an attachment (id=15246)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15246&action=view)
Fix .ali file parsing in xref_lib.adb.
The patch attached in case the url doesn't work.
--
http://gcc.gn
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2008-02-29
15:50 ---
My mistake. I looked at your marking of PR 30572 as fixed rather than the patch
committed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35401
--- Comment #1 from tero dot koskinen at iki dot fi 2008-02-29 15:50
---
I think the problem is in Xref_lib package (xref_lib.adb). It doesn't parse the
current .ali file format properly.
The patch (against gcc-trunk r131693) at
http://iki.fi/tero.koskinen/gcc/gcc-ada-xref_lib_adb.diff
On Linux/x86-64, I got
FAIL: gfortran.dg/ldist-1.f90 -O scan-tree-dump-times ldist "distributed:
split to 4 loops" 1
FAIL: gcc.dg/tree-ssa/ldist-4.c scan-tree-dump-times ldist "distributed: split
to 2 loops" 0
--
Summary: gfortran.dg/ldist-1.f90 and gcc.dg/tree-ssa/ldist-4.c
--
agn at noc dot soton dot ac dot uk changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35401
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-29 14:58 ---
No idea why do you think it I had anything to do with that PR.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35401
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2008-02-29
14:06 ---
Jakub,
I think your fix to this PR could be the cause of
PR 35401. All of gcc 4.3.0's shared libraries are being
linked against the system libgcc in /usr/lib on darwin
rather than the libgcc built and
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2008-02-29
14:03 ---
I think this is likely due to Jakub's fix for PR 30572 instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35401
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2008-02-29
14:00 ---
I doubt that since gcc 4.2.0 doesn't have the problem and all of gcc 4.3.0's
shared libraries are linked incorrectly against the system libgcc on darwin.
(In reply to comment #2)
> Probably the easiest way
--- Comment #7 from mueller at gcc dot gnu dot org 2008-02-29 13:57 ---
how about
extern "C" void abort();
extern "C" { static int i; }
int *p = &i;
int main()
{
int i;
{
extern int i;
i = 1;
*p = 2;
if (i == 2)
abort ();
}
return 0;
}
in this case, the
--- Comment #5 from loki at gcc dot gnu dot org 2008-02-29 13:06 ---
Created an attachment (id=15245)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15245&action=view)
infinite loop patch v1
This proposed patch fixes the reported bug on i386.
I am going to test it for some other t
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-29 12:50 ---
Likely caused by diegos change.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-29 12:48 ---
t.C(13): error #501: argument of type "int" is incompatible with template
parameter of type "C *"
template class C, typename X, C* = 0>
^
2.95.
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-29 12:43 ---
Please change tree-ssa-sccvn.c:try_to_simplify accordingly (eventually that
should use a common helper function to extract a constant initializer for
the tcc_reference case, too). Thanks!
--
http://gcc.gnu.org/
--- Comment #2 from rwild at gcc dot gnu dot org 2008-02-29 12:34 ---
Probably the easiest way to fix this is to fool libtool with a hand-written
libgcc_s.la.
I think PR #5291 is related.
--
rwild at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #10 from tbm at cyrius dot com 2008-02-29 12:23 ---
RTH, can you take the lead on submitting/applying this patch to fix
an Alpha bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34571
--- Comment #15 from jakub at gcc dot gnu dot org 2008-02-29 08:56 ---
.LSFDE3:
.long .LEFDE3-.LASFDE3# FDE Length
.LASFDE3:
.long .LASFDE3-.Lframe1 # FDE CIE offset
.long .LHOTB2 # FDE initial location
.long .LHOTE2-.LHOTB2 # FDE add
70 matches
Mail list logo
