Reported by Paul van Delst at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/196e69ca0ed38f98
Seemingly, gfortran leaks memory with allocatables and user-defined operators.
Might be a duplicate of some other bug - I have not yet check thoroughly. I
also have not checked the
--- Comment #2 from jakub at gcc dot gnu dot org 2009-11-04 09:27 ---
Seems to be caused by the PR38699 changes. Looking into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41935
--- Comment #6 from rguenther at suse dot de 2009-11-04 09:32 ---
Subject: Re: -fdump-tree-all for lto does not work as
expected
On Tue, 3 Nov 2009, pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-11-03 20:02
---
My /tmp is
--- Comment #3 from jakub at gcc dot gnu dot org 2009-11-04 09:35 ---
Shorter testcase:
/* PR middle-end/41935 */
extern void abort (void);
struct A { int a; int b[10]; };
int
foo (struct A *p)
{
return __builtin_offsetof (struct A, b[p-a]);
}
int
main ()
{
struct A a;
a.a = 7;
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2009-11-04 09:58
---
Subject: Bug 41302
Author: mkuvyrkov
Date: Wed Nov 4 09:57:55 2009
New Revision: 153890
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153890
Log:
2009-11-04 Maxim Kuvyrkov ma...@codesourcery.com
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-04 10:18 ---
Subject: Bug 41919
Author: rguenth
Date: Wed Nov 4 10:18:33 2009
New Revision: 153891
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153891
Log:
2009-11-04 Richard Guenther rguent...@suse.de
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-11-04 10:24 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-04 10:29 ---
I see the same on x86_64-linux
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41929
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-04 10:32 ---
Reduce this line:
gcc-trunk -flto -O2 -shared -o libcamlrun_shared.so interp.pic.o misc.pic.o
stacks.pic.o fix_code.pic.o startup.pic.o freelist.pic.o major_gc.pic.o
minor_gc.pic.o memory.pic.o alloc.pic.o
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-11-04 10:35 ---
Subject: Bug 41919
Author: rguenth
Date: Wed Nov 4 10:35:04 2009
New Revision: 153893
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153893
Log:
2009-11-04 Richard Guenther rguent...@suse.de
PR
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-04 10:37 ---
Created an attachment (id=18962)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18962action=view)
gcc45-pr41935.patch
Patch I'm going to bootstrap/regtest.
--
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-11-04 11:19
---
I see the same on x86_64-linux
That would be surprising, nothing has changed since they were installed. Are
you sure it's not gnat.dg/stack_check1.adb instead? It passes on my machine,
both 32-bit and 64-bit
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2009-11-04 11:47
---
Fixed.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenther at suse dot de 2009-11-04 11:49 ---
Subject: Re: 64-bit null_pointer_deref1 gnat.dg test consumes
all available memory
On Wed, 4 Nov 2009, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-11-04
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-11-04 11:57
---
Running target unix//-m32
FAIL: gnat.dg/null_pointer_deref1.adb execution test
the 64bit variant passes.
the log just states
raised STORAGE_ERROR : stack overflow (or erroneous memory access)
OK,
--- Comment #2 from simon_baldwin at yahoo dot com 2009-11-04 12:17 ---
I have a minimal failing case for this, I think. I'm using trunk 153803, for
what it's worth.
$ cat demo.c
typedef long intnat;
typedef intnat value;
void caml_darken (value v, value *p) { }
$ .../gcc -flto
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-04 12:22
---
Jason, at the moment I don't know Lambdas well enough to say whether this is
exactly the same issue as 41933 or not, CC-ing you on this one too...
--
paolo dot carlini at oracle dot com changed:
When trying to compile the sample file, gfortran (I'm referring to the revision
r153847) chokes over allocating an allocatable array whose length depends on an
integer derived type in the same abstract type.
gfortran -c cuba_types_bug.f03
cuba_types_bug.f03:16.28:
--- Comment #1 from reuter at physik dot uni-freiburg dot de 2009-11-04
12:39 ---
Created an attachment (id=18963)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18963action=view)
sample code for the bug case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41937
--- Comment #3 from simon_baldwin at yahoo dot com 2009-11-04 12:57 ---
A bit more info from a gdb trace:
Program received signal SIGSEGV, Segmentation fault.
0x00b798ce in ipa_populate_param_decls (node=0x2b453300,
info=0x15eb768) at ../../gcc/gcc/ipa-prop.c:141
141
--- Comment #6 from rguenther at suse dot de 2009-11-04 13:12 ---
Subject: Re: 64-bit null_pointer_deref1 gnat.dg test consumes
all available memory
On Wed, 4 Nov 2009, ebotcazou at gcc dot gnu dot org wrote:
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2009-11-04
Sent from my iPhone
On Nov 4, 2009, at 1:32 AM, rguenther at suse dot de gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #6 from rguenther at suse dot de 2009-11-04 09:32
---
Subject: Re: -fdump-tree-all for lto does not work as
expected
On Tue, 3 Nov 2009, pinskia at gcc dot
--- Comment #7 from pinskia at gmail dot com 2009-11-04 13:57 ---
Subject: Re: -fdump-tree-all for lto does not work as expected
Sent from my iPhone
On Nov 4, 2009, at 1:32 AM, rguenther at suse dot de
gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #6 from rguenther at suse
I am useing the following CFLAGS
export CFLAGS=-no-cpp-precom
with the configure command:
../configure --target=i386-elf --prefix=/usr/local/i386elfgcc --with-gnu-as
--with-gnu-ld --disable-libssp --enable-languages=c,c++,objc --with-newlib
--with-headers=../../newlib-1.9.0/newlib/libc/include
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-04 14:00 ---
This is -O vs. -O2 ICE because different IPA passes are selected then. I think
we have a dup for this - Martin, is it somehow easy to avoid the ICE?
--
rguenth at gcc dot gnu dot org changed:
What
4.4.x has a problem with the floating point emulation libraries with respect to
the EABI in that they access an area below the stack pointer.
This is fixed on trunk with
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00372.html but needs backporting
to 4.4.x and 4.3.x branches. I will do so once
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-04 14:01 ---
Note that I wonder why we write/read summaries (do we?) with -flto at all.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-11-04 14:10
---
Subject: Bug 40835
Author: rearnsha
Date: Wed Nov 4 14:09:55 2009
New Revision: 153895
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153895
Log:
2009-11-04 Richard Earnshaw rearn...@arm.com
PR
--- Comment #3 from uros at gcc dot gnu dot org 2009-11-04 14:15 ---
Subject: Bug 41900
Author: uros
Date: Wed Nov 4 14:14:49 2009
New Revision: 153896
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153896
Log:
PR target/41900
* config/i386/i386.h
integer, allocatable :: a
allocate(a(4))
end
gives the - correct - error:
Error: Syntax error in ALLOCATE statement at (1)
However, I prefer the error message of ifort:
error #8196: An ALLOCATE shape must not be given for a scalar object.
--
Summary: Improve error message for
--- Comment #2 from burnus at gcc dot gnu dot org 2009-11-04 14:33 ---
Confirmed. The following - untested - should fix it. I am not sure, when I have
time to submit it. Janus, if you want to do the honour, go ahead.
Index: resolve.c
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-04 14:36
---
Are you sure using newlib is supported (and that you definitely need it)? I do
not have access to Leopard anymore but certainly the library builds fine for a
default configure, in fact the entire 4.4.x, we
--- Comment #9 from redi at gcc dot gnu dot org 2009-11-04 14:41 ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#653
and
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#683
and
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2762
I'm still not
--- Comment #10 from redi at gcc dot gnu dot org 2009-11-04 15:28 ---
To be clear: In C++0x struct A would have a deleted copy assign operator, and
union U would be allowed, but its copy assignment operator would be deleted.
IMHO C++03 is not clear whether struct A has a trivial
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-04 15:34 ---
Created an attachment (id=18964)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18964action=view)
qmc2main.ii.bz2
Another testcase where var-tracking takes almost forever on setupUi on
x86_64-linux with -g -O2.
compiling a assembler inline code which use a log of registers and with -O2
option instructions like
movq%rbx, -40(%rsp)
are generated which are wrong cause it writes to not allocated stack which
could lead to corruption on interrupts
code
void foo(const unsigned char *p)
{
unsigned int
--- Comment #1 from freddy77 at gmail dot com 2009-11-04 15:37 ---
Created an attachment (id=18965)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18965action=view)
source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941
--- Comment #2 from freddy77 at gmail dot com 2009-11-04 15:37 ---
Created an attachment (id=18966)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18966action=view)
output assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941
--- Comment #3 from freddy77 at gmail dot com 2009-11-04 15:37 ---
Created an attachment (id=18967)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18967action=view)
gcc command output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941
--- Comment #4 from freddy77 at gmail dot com 2009-11-04 15:39 ---
Oh... I forgot. I used gcc from Ubuntu 9.10 distro either gcc 4.4.1, g++ 4.4.1,
gcc 4.3.4 and g++ 4.3.4 have same issue. The issue does not occur using -Os
option (which use push instructions)
--
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-04 15:40 ---
*** Bug 41934 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933
--- Comment #2 from jason at gcc dot gnu dot org 2009-11-04 15:40 ---
Yeah, this and 41933 are both that capturing a parameter pack isn't implemented
yet.
*** This bug has been marked as a duplicate of 41933 ***
--
jason at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from nathan at gcc dot gnu dot org 2009-11-04 15:47 ---
Subject: Bug 11810
Author: nathan
Date: Wed Nov 4 15:47:00 2009
New Revision: 153900
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153900
Log:
PR driver/11810
* gcc.c (SWITCHES_NEED_SPACES):
--- Comment #5 from mikpe at it dot uu dot se 2009-11-04 15:47 ---
On x86_64 there's a 128 byte area below %rsp which is free to use without first
setting up a stack frame. This is described in the x86_64 ABI document. The
Linux kernel skips this area before pushing signal handler stack
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work|4.5.0 |4.3.4 4.5.0
Summary|ICE (segmentation fault) for|[4.4
--- Comment #12 from jason at gcc dot gnu dot org 2009-11-04 16:05 ---
My drafting to ratify the G++ behavior was adopted at the Santa Cruz meeting,
so this is not a bug.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from jason at gcc dot gnu dot org 2009-11-04 16:08 ---
Fixed for 4.5 by the patch for PR 37177.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-11-04 16:10 ---
(In reply to comment #4)
This is -O vs. -O2 ICE because different IPA passes are selected
then. I think we have a dup for this - Martin, is it somehow easy
to avoid the ICE?
Well, it seems that calling
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-04 16:33 ---
(In reply to comment #2)
Janus, if you want to do the honour, go ahead.
Yes, I can do it.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-04 16:43 ---
(In reply to comment #0)
Error: ABSTRACT INTERFACE 'dot' must not be referenced at (1)
The same error appears in PR 41556.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41873
--- Comment #6 from ubizjak at gmail dot com 2009-11-04 16:47 ---
This is called red zone and is part of x86_64 ABI. Use -mno-red-zone if you
don't like this feature for some reason.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2009-11-04 16:57
---
It appears that 'lea' serves some compatibility purpose. The code is there
since 1995.
Recent GLIBC defines _mcount as
void
_mcount (void)
{
mcount_internal ((u_long)
--- Comment #1 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-04
17:52 ---
Subject: [4.5 regression] cc1 SEGV compiling maxval_r16.c
Unfortunately, gdb 7.0 crashes as well, so I cannot investigate the
problem this way. But I've been able to produce a minimized testcase,
which
--- Comment #2 from ro at gcc dot gnu dot org 2009-11-04 17:53 ---
Created an attachment (id=18968)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18968action=view)
minimized testcase
Compile with gcc -std=c99 -c -O2 to produce SEGV.
--
--- Comment #12 from jason at gcc dot gnu dot org 2009-11-04 18:14 ---
Subject: Bug 17365
Author: jason
Date: Wed Nov 4 18:13:57 2009
New Revision: 153905
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153905
Log:
PR c++/17365, DR 218
* name-lookup.c
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-04
18:15 ---
Subject: Re: [4.5 regression] cc1 SEGV compiling maxval_r16.c
I'll build a cross compiler from i386-pc-solaris2.10 and see if I can
reproduce the problem there.
Unfortunately, the problem does not
const char * __attribute__ ((visibility (hidden))) foo(void)
{ return foo; }
const char __attribute__ ((visibility (hidden))) * bar(void)
{ return bar; }
Compile this with:
gcc -fPIC -Wl,--version-script=foobar.map -Wl,--strip-all -shared -o foobar.so
foobar.c
foo() now issues the warning
--- Comment #4 from ro at gcc dot gnu dot org 2009-11-04 18:32 ---
Richard, this may be due to your patch.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-04
18:34 ---
Subject: Re: [4.5 regression] cc1 SEGV compiling maxval_r16.c
Unfortunately, the problem does not reproduce in such a cross compiler,
so I'll have to either start a native reghunt or find a way to debug
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-04 18:36 ---
Subject: Bug 41833
Author: pinskia
Date: Wed Nov 4 18:35:57 2009
New Revision: 153906
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153906
Log:
2009-11-04 Andrew Pinski andrew_pin...@playstation.sony.com
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-04 18:37 ---
Fixed on the trunk for 4.5.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from bstarynk at gcc dot gnu dot org 2009-11-04 18:37
---
With gcc trunk rev 153897 Simon Baldwin's demo.c file
typedef long intnat;
typedef intnat value;
void caml_darken (value v, value *p) { }
is passing ok.
But ocaml-trunk is still crashing the gcc-trunk. And
--- Comment #8 from bstarynk at gcc dot gnu dot org 2009-11-04 18:45
---
(In reply to comment #7)
With gcc trunk rev 153897 Simon Baldwin's demo.c file
typedef long intnat;
typedef intnat value;
void caml_darken (value v, value *p) { }
is passing ok.
No I was wrong. It
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-04 19:07 ---
Yes it is weird but really it should be placed either before the type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41942
--- Comment #26 from dodji at gcc dot gnu dot org 2009-11-04 19:24 ---
Subject: Bug 37093
Author: dodji
Date: Wed Nov 4 19:23:40 2009
New Revision: 153908
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153908
Log:
Revert Fix PR c++/37093
This reverts commit 153841 on
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-04 19:34 ---
Subject: Bug 15882
Author: jason
Date: Wed Nov 4 19:34:25 2009
New Revision: 153909
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153909
Log:
PR c++/15882
* method.c (use_thunk): Check
--- Comment #10 from jason at gcc dot gnu dot org 2009-11-04 19:37 ---
Oops, wrong PR number on that checkin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15882
--- Comment #13 from jason at gcc dot gnu dot org 2009-11-04 19:39 ---
Fixed for 4.5.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-04 19:41 ---
Subject: Bug 41556
Author: janus
Date: Wed Nov 4 19:41:07 2009
New Revision: 153911
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153911
Log:
2009-11-04 Tobias Burnus bur...@gcc.gnu.org
Janus
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-04 19:41 ---
Subject: Bug 41937
Author: janus
Date: Wed Nov 4 19:41:07 2009
New Revision: 153911
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153911
Log:
2009-11-04 Tobias Burnus bur...@gcc.gnu.org
Janus
--- Comment #2 from joseph at codesourcery dot com 2009-11-04 19:42 ---
Subject: Re: New: __attribute__ ((visibility)) weird with
functions returning pointers
Visibility attributes are in the nature of storage class specifiers and so
should be placed at the start of the
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-04 19:46 ---
Fixed with r153911. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from bkoz at gcc dot gnu dot org 2009-11-04 19:53 ---
FWIW, I think even in the case that the total message (error + context) is more
than can fit at one time on the current terminal window, it is advantageous to
have the fixed length part (error) first, and then the
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-04 19:55 ---
The commit in comment #2 contains the patchlet from comment #1 and fixes the
first of the error messages in comment #0.
At this point, the test case still triggers three error messages:
c0.f90:34.14:
operand =
--- Comment #13 from jason at gcc dot gnu dot org 2009-11-04 19:56 ---
Subject: Bug 35067
Author: jason
Date: Wed Nov 4 19:55:56 2009
New Revision: 153912
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153912
Log:
PR c++/35067
* method.c (use_thunk): Check
--- Comment #14 from jason at gcc dot gnu dot org 2009-11-04 20:08 ---
Subject: Bug 35067
Author: jason
Date: Wed Nov 4 20:08:44 2009
New Revision: 153913
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153913
Log:
PR c++/35067
* method.c (use_thunk): Check
--- Comment #15 from jason at gcc dot gnu dot org 2009-11-04 20:10 ---
Fixed for 4.3.5, 4.4.3, 4.5.0. Vincent, can you verify that it works with the
current sources?
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-04 20:13 ---
Reduced test case:
implicit none
type, abstract :: inner_product_class
contains
procedure(dot), public, nopass, deferred :: dot_g_g
end type
abstract interface
real function dot ()
end
--- Comment #10 from jason at gcc dot gnu dot org 2009-11-04 20:16 ---
In 4.5 this will compile with -std=c++0x.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from paolo dot carlini at oracle dot com 2009-11-04 20:18
---
(In reply to comment #10)
At least that way you'll know the error is always at the top, instead of at
some point between the end of the compile line and the next prompt.
Yes, but is this true with
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-04 20:39 ---
(In reply to comment #2)
While one might not access (type)%dot_g_g as dot_g_g is deferred, using
(class)%dot_g_g is valid. (And using (type)%dot_g_g is not possible as one
cannot use type(abstract_t); thus it
--- Comment #22 from jason at gcc dot gnu dot org 2009-11-04 20:40 ---
This was fixed in 4.0.2.
*** This bug has been marked as a duplicate of 21514 ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from jason at gcc dot gnu dot org 2009-11-04 20:40 ---
*** Bug 20589 has been marked as a duplicate of this bug. ***
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
$prefix/include isn't searched!
$ /mingw/test/prefix/bin/gcc -v -E -o test.ii test.c
Using built-in specs.
COLLECT_GCC=C:\MinGW\test\prefix\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/test/prefix/bin/../libexec/gcc/i686-w64-mingw32/4.5.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with:
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-04 21:19 ---
That is because the way you configured GCC with
--with-sysroot=/mingw/test/sysroot
Since that is true, it adds the sysroot to C:/MinGW/test/prefix/include.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41943
--- Comment #6 from jason at gcc dot gnu dot org 2009-11-04 21:27 ---
This is not a SFINAE issue, the bug is that we shouldn't be instantiating
member_ptr in the first place in order to resolve the operator= overload.
--
jason at gcc dot gnu dot org changed:
What
--- Comment #39 from ebotcazou at gcc dot gnu dot org 2009-11-04 21:46
---
Subject: Bug 20548
Author: ebotcazou
Date: Wed Nov 4 21:45:54 2009
New Revision: 153918
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153918
Log:
PR target/10127
PR ada/20548
*
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2009-11-04 21:46
---
Subject: Bug 10127
Author: ebotcazou
Date: Wed Nov 4 21:45:54 2009
New Revision: 153918
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153918
Log:
PR target/10127
PR ada/20548
*
--- Comment #40 from ebotcazou at gcc dot gnu dot org 2009-11-04 21:49
---
Tentatively on mainline.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenther at suse dot de 2009-11-04 21:51 ---
Subject: Re: 64-bit null_pointer_deref1 gnat.dg test consumes
all available memory
On Wed, 4 Nov 2009, rguenther at suse dot de wrote:
--- Comment #6 from rguenther at suse dot de 2009-11-04 13:12 ---
my output looks roughly like this:
fi...@bigdog24vm1ub90432:/tmp/usession-trunk-57/testing_1$ gcc -v -save-temps
-O1 -g testcase.i
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/fijal/b/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with:
--- Comment #1 from fijall at gmail dot com 2009-11-04 22:01 ---
Since attachments are far too small, the testcase is available for download
here:
http://codespeak.net/~fijal/testcase.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41944
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #1 from hideaki at sogetthis dot com 2009-11-04 22:16 ---
Created an attachment (id=18969)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18969action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41945
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-04 22:19 ---
Likely a dup of PR41935
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c |middle-end
GCC build triplet|i586-suse-linux and x86_64 |
GCC
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-04 22:25 ---
Likely a dup of PR41891.
(gdb) bt
#0 0x081bc9a2 in bitmap_clear (head=0x74)
at /home/richard/src/trunk/gcc/bitmap.c:297
#1 0x0846602c in free_loop_data (loop=0xb3470bb0)
at
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-04 22:29 ---
Subject: Bug 39413
Author: jason
Date: Wed Nov 4 22:29:35 2009
New Revision: 153920
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153920
Log:
PR c++/39413
* search.c (lookup_base): Don't
1 - 100 of 119 matches
Mail list logo
