-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r164319-install
--program-prefix=r164319- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100915 (experime
I've configured GCC with following options:
../gcc-current/configure --prefix=/home/artem/testing/gcc46 --enable-shared
--enable-bootstrap --enable-languages=c,c++ --enable-threads=posix
--enable-checking=release --with-system-zlib --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libs
--- Comment #7 from pault at gcc dot gnu dot org 2010-09-16 05:11 ---
Created an attachment (id=21808)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21808&action=view)
A fix for this PR
Bootstraps and regtests on FC9/x86_64.
It is clear that many other array intrinsics fail with
--- Comment #1 from ekuznetsov at divxcorp dot com 2010-09-16 01:18 ---
Created an attachment (id=21807)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21807&action=view)
Sample code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685
I've attached two copies of a simple function. They are identical except for
the type of the internal variable (one uses 'int64_t', the other uses 'int').
When compiled with GCC 4.4.3 on a x64 platform using -O3 optimizations, the
assembly code for the first version will contain a conditional move
la GDB 7.2 build (with python
support!)
moria:shm$ cat pr45403.cc
#include
int main()
{
std::string s( "foo" );
s.size();
}
moria:shm$ ~/gcc/4.5/bin/g++ pr45403.cc -v 2>&1 | fgrep 'version 4.5'
gcc version 4.5.2 20100915 (prerelease) (GCC)
GNU C++ (GC
--- Comment #8 from redi at gcc dot gnu dot org 2010-09-15 23:43 ---
Hmm, OK, I can reproduce that with a current 4.5.2 build, but not with a
snapshot from last week. Please file a separate bug for that, component=c++ -
thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45403
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-09-15 22:57
---
Thanks for the reduced testcase.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
---
reorg.c (relax_delay_slots): Use emit_copy_of_insn_after to re-emit
insns that were in delay slots as stand-alone insns.
Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/20100915-1.c
- copied unchanged from r164318,
trunk/gcc/testsuite/gcc.c-torture/compile/2010
--- Comment #2 from danglin at gcc dot gnu dot org 2010-09-15 22:49 ---
Bug returns in build with revision 164294.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--
reorg.c (relax_delay_slots): Use emit_copy_of_insn_after to re-emit
insns that were in delay slots as stand-alone insns.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20100915-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reorg.c
trunk/gcc/testsuite/ChangeLog
--
--- Comment #9 from hubicka at ucw dot cz 2010-09-15 22:39 ---
Subject: Re: Missed devirtualization
> We fold a stmt only if it is propagated to (by ccp, copyprop, forwprop,
> dom or by inlining).
Well, since fold_stmt is stornger than what fe does, I guess we should fold
each stmt at
--- Comment #47 from LpSolit at netscape dot net 2010-09-15 21:16 ---
Per the email Ian sent a few minutes ago, we will upgrade Bugzilla this Friday,
September 17, for three hours starting at 18:00 GMT (11:00 PDT).
So *please* give a try at our test installation, and report any problem
--- Comment #3 from kargl at gcc dot gnu dot org 2010-09-15 21:08 ---
(In reply to comment #2)
> Hi,
>
> as it's already fixed in newer versions, please don't spend any more time on
> this.
>
OK.
Once again thanks for sending a bug report.
--
kargl at gcc dot gnu dot org changed:
--- Comment #9 from dwitte at gmail dot com 2010-09-15 21:01 ---
Created an attachment (id=21806)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21806&action=view)
testcase
Here you go. This passes at -O0 but fails at -O2. Note that the testcase
requires >= 7 args to the test funct
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-09-15 21:00 ---
*** Bug 45684 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 2010-09-15 21:00 ---
*** This bug has been marked as a duplicate of 43085 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
my system:
kje...@familien:~/git/incanter$ lsb_release -rd
Description:Ubuntu maverick (development branch)
Release:10.10
my gcc version: (standard version from ubuntu Maverick):
kje...@familien:~/git/incanter$ gcc --version
gcc (Ubuntu/Linaro 4.4.4-14ubuntu3) 4.4.5
Copyright (C) 20
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-15 20:56 ---
D.1837_4 = () D.1836_3;
Looks like the support 128bit integer is not fully there for x86.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from generalruzzmo at gmail dot com 2010-09-15 20:54 ---
this bug is bugging me too..
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43118
--- Comment #2 from mail at rink dot nu 2010-09-15 20:40 ---
Created an attachment (id=21805)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21805&action=view)
.i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45683
--- Comment #1 from mail at rink dot nu 2010-09-15 20:40 ---
Created an attachment (id=21804)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21804&action=view)
Failing code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45683
The attached tiny program gives the following:
$ gcc -m32 -std=c99 -c faal.c
faal.c:18:50: warning: integer constant is so large that it is unsigned
faal.c:20:13: warning: integer constant is so large that it is unsigned
faal.c: In function main:
faal.c:18: internal compiler error: Segmentation
--- Comment #8 from jakub at gcc dot gnu dot org 2010-09-15 19:21 ---
Yes, x86-64 requires 16 byte stack alignment, but alloca should ensure that.
Can you come up with a small testcase which was misbehaving before? It would
be great to add it to the libffi testsuite.
--
http://gcc
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45680
--- Comment #8 from rguenther at suse dot de 2010-09-15 19:09 ---
Subject: Re: Missed devirtualization
On Wed, 15 Sep 2010, jamborm at gcc dot gnu dot org wrote:
> --- Comment #7 from jamborm at gcc dot gnu dot org 2010-09-15 18:42
> ---
> Well, it turns out that fold_stmt_1
For the example below, when using gcc 4.5 and svn head, gcc -gdwarf-4 is not
emitting the class definition in an enclosing namespace parent die.
foo.cc:
namespace thread {
class Executor {
public:
static Executor* CurrentExecutor();
};
}
namespace thread {
Executor* Executor::CurrentExecut
--- Comment #2 from jteg68 at gmail dot com 2010-09-15 18:57 ---
Hi,
as it's already fixed in newer versions, please don't spend any more time on
this.
/Jörgen
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45681
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-09-15 18:42 ---
Well, it turns out that fold_stmt_1 is never called on that statement
(neither with -O -finline or -O2 or -O3). Where is it supposed to be
called from?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45605
--- Comment #12 from zsojka at seznam dot cz 2010-09-15 18:39 ---
You are right, it still fails in the graphite branch, though with different
ICE:
(r164299, x86_64-linux)
$ gcc gcc/testsuite/gcc.c-torture/execute/strncmp-1.c -Os -m32
gcc/testsuite/gcc.c-torture/execute
--- Comment #1 from kargl at gcc dot gnu dot org 2010-09-15 18:30 ---
Thanks for the bug report. The problem appears to be fixed in
gcc version 4.6.0 20100913 (experimental) (GCC)
and
gcc version 4.5.1 20100728 (prerelease) (GCC).
It is unlikely that this will be fixed in 4.4.x becaus
--- Comment #3 from ubizjak at gmail dot com 2010-09-15 18:26 ---
(In reply to comment #2)
> (In reply to comment #0)
>
> > This is most likely from this patch
>
> FYI, this patch also introduced the same build failure when building cc1 from
> linux to cygwin cross. Before this patch,
--- Comment #4 from Joost dot VandeVondele at pci dot uzh dot ch
2010-09-15 18:25 ---
If realspace_grid_type%r is declared as pointer instead of allocatable, the
testcase can be compiled, and a similar workaround in CP2K allows an LTO build
of CP2K to finish (after updating binutils to
--- Comment #2 from ubizjak at gmail dot com 2010-09-15 18:21 ---
(In reply to comment #0)
> This is most likely from this patch
FYI, this patch also introduced the same build failure when building cc1 from
linux to cygwin cross. Before this patch, cc1 build went just fine even without
-bugzi...@gcc.gnu.org]
Sent: Wednesday, September 15, 2010 10:28 AM
To: Yazdani, Reza
Subject: [Bug bootstrap/45680] New: [4.6 regression] cc1 fails to link on
Solaris 9/x86 with Sun as: min_insn_size missing
Between 20100908 and 20100915, mainline failed to bootstrap on Solaris 9/x86
with Sun as
ICE on buggy? code.
#cat buggy.f
integer function fcall(c,n)
character*(n) c
integer n
character c2
c2=c(1)
return
end
#gfortran buggy.f --save-temps
buggy.f: In function fcall:
buggy.f:1: internal compiler error: in make_decl_rtl, at varasm.c:1297
Ple
--- Comment #7 from mh+gcc at glandium dot org 2010-09-15 18:13 ---
Nice catch. BTW I read recently that gcc 4.5 assumes 16 bytes stack alignment,
is that x86 only or does that apply to x86-64 too ? (in which case we'd need to
be careful about that as well)
--
http://gcc.gnu.org/bug
--- Comment #6 from jakub at gcc dot gnu dot org 2010-09-15 17:51 ---
No, the 8 in the final ALIGN is because that's the stack word size, everything
smaller than that is passed as low bits of the whole 64-bit word.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677
Em bare And gripped the ground and grasped the air, Staggered, and
strove to stand. He bent them back
with spear and spade, With desperate dyke and wall, With foemen
leaning on his shield And roaring on him when he reeled; And no help
came at all. He
broke them with a broken sword A little toward
Between 20100908 and 20100915, mainline failed to bootstrap on Solaris 9/x86
with Sun as: cc1 doesn't link any more due to an undefined referenced to
min_insn_size.
This is most likely from this patch
2010-09-09 Reza Yazdani
* config/i386/i386.c: Include sched-
--- Comment #5 from dwitte at mozilla dot com 2010-09-15 17:24 ---
Yeah, that sounds right to me. The final alignment really wants to be the
alignment of whatever comes next, right? Which happens to be cif->flags, so 8
is fine. I wonder if just assuming 8 is fragile, but since we'll only
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-15 17:07 ---
That patch looks wrong. The padding for alignment must be done before the
arguments, not after them.
Say if bytes is 24 at the start of one iteration, cif->arg_types[i]->alignment
is 32 and cif->arg_types[i]->size is
--- Comment #3 from dwitte at mozilla dot com 2010-09-15 16:18 ---
(Oh, and please include a description of your change in ChangeLog -- makes his
job easier.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677
--- Comment #2 from dwitte at mozilla dot com 2010-09-15 16:17 ---
I'd recommend upstreaming things directly to the maintainer, Anthony Green
(that's what I do). If you'd like, close this out, and post the patch to
libffi-disc...@sourceware.org and CC gr...@redhat.com?
--
dwitte at m
--- Comment #8 from jamborm at gcc dot gnu dot org 2010-09-15 16:06 ---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from jakub at gcc dot gnu dot org 2010-09-15 16:06 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-09-15 16:00 ---
Subject: Bug 45644
Author: jamborm
Date: Wed Sep 15 15:59:27 2010
New Revision: 164313
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164313
Log:
2010-09-15 Martin Jambor
PR middle-end/45644
--- Comment #12 from jakub at gcc dot gnu dot org 2010-09-15 15:54 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from jakub at gcc dot gnu dot org 2010-09-15 15:43 ---
Subject: Bug 45633
Author: jakub
Date: Wed Sep 15 15:42:41 2010
New Revision: 164312
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164312
Log:
PR tree-optimization/45633
* tree-cfg.c (verify_
--- Comment #11 from jakub at gcc dot gnu dot org 2010-09-15 15:40 ---
Subject: Bug 45635
Author: jakub
Date: Wed Sep 15 15:39:57 2010
New Revision: 164311
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164311
Log:
PR c++/45635
* class.c (build_vtbl_initializer):
--- Comment #2 from ro at gcc dot gnu dot org 2010-09-15 15:37 ---
Jan, this is the second of your recent patches (after PR bootstrap/45612) to
break Ada/SPARC bootstrap. Could you please have a look?
Thanks.
Rainer
--
ro at gcc dot gnu dot org changed:
What|Remov
--- Comment #3 from dietmar dot ebner at gmail dot com 2010-09-15 15:36
---
(In reply to comment #2)
> Actually I think this patch is ok. Are you interested in committing it
> yourself? [Note that you'll need an FSF copyright assignment, if you don't
> already have one.] Otherwise I can
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-09-15
15:34 ---
Subject: Re: New: [4.6 regression] Comparison failure in gcc/ada/ali.o on
Solaris 2/SPARC
A reghunt identified the responsible patch:
2010-09-10 Jan Hubicka
* tree-ssa-ccp.c (fold_const_aggre
--- Comment #6 from Joost dot VandeVondele at pci dot uzh dot ch
2010-09-15 15:17 ---
OK, fixed with using CVS binutils...
ld -v
GNU gold (GNU Binutils 2.20.51.20100915) 1.10
--
Joost dot VandeVondele at pci dot uzh dot ch changed:
What|Removed |
--- Comment #2 from hubicka at gcc dot gnu dot org 2010-09-15 15:17 ---
Created an attachment (id=21803)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21803&action=view)
second part of testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45679
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-09-15 15:16 ---
Created an attachment (id=21802)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21802&action=view)
first part of testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45679
~/trunk-install/bin/g++ -O3 -fwhopr a.ii b.ii -r -nostdlib
leads to
unit size
align 32 symtab 0 alias set -1 canonical type 0x77ed8498
precision 32 min max
pointer_to_this >
QI
size
unit size
align 8 symtab 0 alias se
--- Comment #2 from janus at gcc dot gnu dot org 2010-09-15 14:46 ---
(In reply to comment #0)
> Index: fortran/interface.c
> ===
> --- fortran/interface.c (revision 164288)
> +++ fortran/interface.c (working copy)
> @@ -142
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-15 14:23 ---
Actually
typedef float V __attribute__ ((vector_size (16)));
V g;
int
main ()
{
float d[4] = { 4, 3, 2, 1 };
V e;
__builtin_memcpy (&e, &d, sizeof (d));
V f = { 5, 15, 25, 35 };
e = e * f;
g = e;
return
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary|gcc-4.4: crash on vector|[4.4 Regression] crash on
|code with -m32 -msse
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-15 14:10 ---
No longer crashes in 4.5/4.6 since r147980, aka SRA rewrite. The only
difference in *.optimized is though that before r147980 we have:
m3.3_3 = VIEW_CONVERT_EXPR(m2);
m3.5_4 = m3.3_3 * { 5.0e+0, 1.5e+1, 2.5e+1, 3.
--- Comment #25 from mh+gcc at glandium dot org 2010-09-15 14:01 ---
Oh, I was trying with -O2, yes, it works with -O1 -fno-tree-pta. Let me try on
the original code, too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
--- Comment #24 from rguenth at gcc dot gnu dot org 2010-09-15 13:59
---
Created an attachment (id=21801)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21801&action=view)
patch
I am testing this patch (for 4.5 branch).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-15 13:57 ---
Confirmed. From a quick glimpse it seems the patch goes in the right direction.
Will have a closer look soon.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #23 from rguenther at suse dot de 2010-09-15 13:56 ---
Subject: Re: [4.5/4.6 Regression] GCC 4.5.[01]
breaks our ffi on Linux64. ABI break?
On Wed, 15 Sep 2010, mh+gcc at glandium dot org wrote:
> --- Comment #22 from mh+gcc at glandium dot org 2010-09-15 13:52 -
--- Comment #10 from janus at gcc dot gnu dot org 2010-09-15 13:52 ---
Fixed with r164305. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from mh+gcc at glandium dot org 2010-09-15 13:52 ---
(In reply to comment #21)
> For the original code? Then your reduced testcase is different from the
> original problem.
It doesn't work for the reduced testcase here, with gcc 4.5.1
--
http://gcc.gnu.org/bugzilla
--- Comment #9 from janus at gcc dot gnu dot org 2010-09-15 13:50 ---
Subject: Bug 45577
Author: janus
Date: Wed Sep 15 13:50:15 2010
New Revision: 164305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164305
Log:
2010-09-15 Janus Weil
PR fortran/45577
* reso
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-09-15 13:50
---
(In reply to comment #20)
> (In reply to comment #19)
> > Another workaround is to use -fno-tree-pta.
>
> Doesn't work here.
For the original code? Then your reduced testcase is different from the
original probl
--- Comment #20 from mh+gcc at glandium dot org 2010-09-15 13:41 ---
(In reply to comment #19)
> Another workaround is to use -fno-tree-pta.
Doesn't work here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-09-15 13:25 ---
I have just sent a proposed fix to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01244.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45644
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-09-15 13:24
---
Another workaround is to use -fno-tree-pta.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
--- Comment #18 from mh+gcc at glandium dot org 2010-09-15 13:14 ---
(In reply to comment #17)
> Thus, as a workaround you should make sure the asBits field matches
> pointer-size (so for example use uintptr_t isntead of uint64_t).
which is not possible in the original code, as the unio
--- Comment #17 from rguenth at gcc dot gnu dot org 2010-09-15 13:03
---
points-to analysis does not honor GCCs type-punning through union extension
(it works on x86_64 because ptr and asBits match in size and thus SRA
cleans the code up before pointer-analysis). So PTA sees
ss1.0_1
--- Comment #16 from mh+gcc at glandium dot org 2010-09-15 12:52 ---
The real code where this gets problematic:
http://mxr.mozilla.org/mozilla-central/source/js/src/ctypes/CTypes.cpp#5615
The function it calls:
http://mxr.mozilla.org/mozilla-central/source/js/src/ctypes/CTypes.cpp#5542
--- Comment #15 from mh+gcc at glandium dot org 2010-09-15 12:47 ---
Note that the original code doesn't use char *. I used char * to make it easily
visible with a printf. Actually, just writing
void foo(jsval_layout l, void *s2) {
jsval_layout m;
m.asBits = l.asBits;
void *
This testcase crashes when compiled with gcc 4.4 -m32 -msse -O2, but not when
compiled with 4.3 or 4.5. It doesn't crash when compiled as -m64.
/* compile me with -O2 -msse -m32 */
#include
typedef float v4sf __attribute__ ((vector_size (16)));
int main(void)
{
float m4[4];
v4sf m3;
f
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-09-15 12:31
---
You are accessing a pointer of type char *s1 via an lvalue of type void *
(*data). Or speaking in C++, you are accessing an object of dynamic type
void * (stored to via *data) by an lvalue of type char * (s1).
Th
--- Comment #1 from mh+gcc at glandium dot org 2010-09-15 12:21 ---
Created an attachment (id=21800)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21800&action=view)
Fix stack allocation for ffi function calls on x86-64
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45677
The stack space allocated by ffi_call for the non-register arguments is not big
enough (and not properly aligned) when calling the target function, and
depending on what the called function does with the stack, it can end up
overwriting ffi_call_unix64's stack. A case where this occurred is with a
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-09-15 12:16
---
Confirmed and investigating.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from mh+gcc at glandium dot org 2010-09-15 12:11 ---
FWIW, it's still broken on a gcc trunk snapshot from the 28th of august.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
--- Comment #11 from mh+gcc at glandium dot org 2010-09-15 12:05 ---
Created an attachment (id=21799)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21799&action=view)
Reduced testcase
Inlining JSVAL_TO_PRIVATE by hand still makes it break, and reduces the
testcase further.
--
--- Comment #10 from mh+gcc at glandium dot org 2010-09-15 11:53 ---
Please note this actually only happens on x86. (I would change the summary and
target if I could)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45623
--- Comment #9 from mh+gcc at glandium dot org 2010-09-15 11:45 ---
Created an attachment (id=21798)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21798&action=view)
Reduced testcase
Both issues Taras mentioned are actually separated. One is an actual bug in ffi
(to be filed), the
--- Comment #7 from pluto at agmk dot net 2010-09-15 11:34 ---
(In reply to comment #6)
> (In reply to comment #5)
> > with -gdwarf-4 enabled it fails on gdb-7.2 with runtime error:
>
> I couldn't reproduce that with 4.5.2 20100909, can you give more details?
$ cat t.cpp
#include
int
--- Comment #6 from redi at gcc dot gnu dot org 2010-09-15 11:21 ---
(In reply to comment #5)
> with -gdwarf-4 enabled it fails on gdb-7.2 with runtime error:
I couldn't reproduce that with 4.5.2 20100909, can you give more details?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45
--- Comment #5 from vladimir dot a dot kharchenko at intel dot com
2010-09-15 10:11 ---
When I run "./soplex -s1 -e -m45000 pds-50.mps" Seg fault is:
Program received signal SIGSEGV, Segmentation fault.
0x004363a7 in size (this=0x7fffce40, ds=) at
svector.h:174
174
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-15 09:49 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-09-15 09:49 ---
Another dumping artifact probably. At some point I'd like to dump all
MEM_REFs as MEM[(...)p + cst] and drop the fancy ways.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45673
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45663
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-09-15 09:47 ---
We can't hoist invariant control flow. Also print *,c is surely thought
to be an escape point for c and thus may clobber it.
I'd rate this impossible to do for the middle-end (and generally not worth
the hassle to
--- Comment #21 from mexas at bristol dot ac dot uk 2010-09-15 09:20
---
Just to confirm that 45 now builds on ia64: gcc-4.5.2.20100909
The error for 46 is this:
*skip*
gmake[4]: Entering directory
`/usr/ports/lang/gcc46/work/build/ia64-portbld-freebsd9.0/libgfortran'
if [ -z "" ]; t
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-15 09:08
---
Fixed for 4.6.0.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #3 from paolo at gcc dot gnu dot org 2010-09-15 09:06 ---
Subject: Bug 45665
Author: paolo
Date: Wed Sep 15 09:06:32 2010
New Revision: 164299
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164299
Log:
/cp
2010-09-15 Paolo Carlini
PR c++/45665
* d
--- Comment #9 from numerical dot simulation at web dot de 2010-09-15
09:03 ---
Hi!
Looks like http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#502
now has a resolution, namely that a type is dependent if it is
a nested class or enumeration that is a member of the current i
--- Comment #5 from t7 at gmail dot com 2010-09-15 08:56 ---
Peeled this skin (164193) off and then blood comes running out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45362
--- Comment #11 from jakub at gcc dot gnu dot org 2010-09-15 08:37 ---
You're right, it doesn't call compute_spt_expr on all the actual arguments's
->expr. If/when it will use a generic walker, that will be fixed
automatically, but I'll fix it in the meantime as well.
--
http://gcc
--- Comment #5 from mrs at gcc dot gnu dot org 2010-09-15 07:55 ---
Fixed.
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #5 from pluto at agmk dot net 2010-09-15 07:52 ---
there's one more issue with std::string pretty printing.
with -gdwarf-4 enabled it fails on gdb-7.2 with runtime error:
$1 = Traceback (most recent call last):
File
"/local/devel/toolchain45/x86_64-gnu-linux.mt_alloc/share
100 matches
Mail list logo
