--- Comment #9 from ghazi at gcc dot gnu dot org 2009-11-05 02:55 ---
(In reply to comment #8)
> > Say I have a silly question, how is gmp.h getting pulled into gcc.c in the
> > first place? It's supposed to come in via real.h which should only get
> > included by middle-end files linki
--- Comment #9 from bkoz at gcc dot gnu dot org 2009-11-05 02:52 ---
Yes, of course. Just providing the framework, since that was a bit tricky.
I should add all the steps here to the parallel mode docs to make this less
confusing for people trying to experiment.
best,
benjamin
--
# 1 "strcmp.c"
# 1 ""
# 1 ""
# 1 "strcmp.c"
int strcmp (const char *, const char *);
int
strcmp (const char *s1, const char *s2)
{
if ((!s1 && s2) || (s1 && !s2))
return (int) (s1 - s2);
if (s1 == s2)
return 0;
while (*s1 == *s2++)
if (*s1++ == '\0')
--- Comment #2 from lifeng at gcc dot gnu dot org 2009-11-05 02:38 ---
(In reply to comment #1)
> What are the options that you used to produce this?
> I am not able to reproduce the failing clast with -O2, nor with -O3 with the
> current graphite branch.
I produce this with -O2. It see
--- Comment #8 from paolo dot carlini at oracle dot com 2009-11-05 02:33
---
Cool. Now it would be nice to benchmark it a bit, somehow, a version of it with
the actual code not commented out, I mean ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
--- Comment #7 from bkoz at gcc dot gnu dot org 2009-11-05 02:16 ---
Here's how parallel fill would look, based on Johannes patch.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
--- Comment #6 from bkoz at gcc dot gnu dot org 2009-11-05 02:15 ---
Created an attachment (id=18970)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18970&action=view)
patch for parallel fill and fill_n
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-11-05 01:08 ---
Actually I take that back, C99 explicitly says arrays cannot be an incomplete
type. See 6.7.5.2/1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from anhvofrcaus at gmail dot com 2009-11-05 01:00 ---
I did look at it. However, I do not understand it thinks ./a.exe has bad file
number as shown in the fragment of the /intl/config.log. The question is how
can I fix this problem? Thanks.
[...]
configure:2947: /c/Gcc
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-11-05 00:45 ---
6.7.5.3/4 says:
After adjustment, the parameters in the a parameter type list in a function
declarator that is part of a definition of that function shall not have
incomplete type.
But the adjustment is the decaying
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-05 00:42 ---
Actually this is valid C99 code after all.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #16 from vincent dot riviere at freesbee dot fr 2009-11-04
23:41 ---
Hello, I've just tested with GCC trunk, it seems to be fixed !
Thanks, Jason.
--
vincent dot riviere at freesbee dot fr changed:
What|Removed |Added
-
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-04 23:27 ---
The problem is that we use a local_specializations hash table to look up locals
when instantiating a template, and i isn't in bar()'s local_specializations, so
we fail. We need to make static locals their own temploid
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-04 23:24 ---
I'm reducing this one for a C testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41903
--- Comment #13 from jason at gcc dot gnu dot org 2009-11-04 23:13 ---
Subject: Bug 36912
Author: jason
Date: Wed Nov 4 23:13:23 2009
New Revision: 153921
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153921
Log:
PR c++/36912
* varasm.c (initializer_constant_va
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfi
--- Comment #12 from jason at gcc dot gnu dot org 2009-11-04 22:36 ---
Paolo's point about -Wfatal-errors makes me inclined to leave this alone.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41884
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-04 22:34 ---
14.7.1 [temp.local]
Like normal (non-template) classes, class templates have an injected-class-name
(Clause 9). The injected-class-name can be used with or without a
template-argument-list. When it is used without a t
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-04 22:31 ---
Fixed for 4.5.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- 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=gcc&view=rev&rev=153920
Log:
PR c++/39413
* search.c (lookup_base): Don't comp
--- 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 /home/richard/src/trunk/gcc/loop
--
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 ho
--- 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
BugsThisDe
--- 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=18969&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41945
While compiling kernel parts, I got an internal compile error. Testfile is
attached.
$ gcc-4.5 -c ch.i -o ch.o
ch.i: In function ânf_ct_tuplehash_to_ctrackâ:
ch.i:19:65: internal compiler error: tree check: expected integer_cst, have
nop_expr in int_cst_value, at tree.c:9619
Please submit a fu
--
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 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
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: ./co
--- 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 ---
> Subj
--- 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 #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=gcc&view=rev&rev=153918
Log:
PR target/10127
PR ada/20548
*
--- 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=gcc&view=rev&rev=153918
Log:
PR target/10127
PR ada/20548
*
--- 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|Remo
--- 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
$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 #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
--
--- 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 #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 i
--- 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 -Wfatal
--- 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 #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 functio
--- 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 #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=gcc&view=rev&rev=153913
Log:
PR c++/35067
* method.c (use_thunk): Check DECL_
--- 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=gcc&view=rev&rev=153912
Log:
PR c++/35067
* method.c (use_thunk): Check DECL_
--- 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 = o
--- 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 var
--- 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 #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 declaration.
--- 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=gcc&view=rev&rev=153911
Log:
2009-11-04 Tobias Burnus
Janus Weil
PR f
--- 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=gcc&view=rev&rev=153911
Log:
2009-11-04 Tobias Burnus
Janus Weil
PR f
--- 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
Status|AS
--- 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 #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=gcc&view=rev&rev=153909
Log:
PR c++/15882
* method.c (use_thunk): Check DECL_W
--- 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=gcc&view=rev&rev=153908
Log:
Revert "Fix PR c++/37093"
This reverts commit 153841 on gcc-4_3
--- 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 #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.
--- 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 i
--- 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 #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=gcc&view=rev&rev=153906
Log:
2009-11-04 Andrew Pinski
Trevor Smigiel
--- 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 debu
--- 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
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 warn
--- 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 re
--- 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=gcc&view=rev&rev=153905
Log:
PR c++/17365, DR 218
* name-lookup.c (add_functi
--- 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=18968&action=view)
minimized testcase
Compile with gcc -std=c99 -c -O2 to produce SEGV.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- 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 I
--- 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)
__builtin_extract_retur
--- 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 #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 #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 #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 ipa
--- 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 #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
--
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 Regr
--
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 #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
--- 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=gcc&view=rev&rev=153900
Log:
PR driver/11810
* gcc.c (SWITCHES_NEED_SPACES)
--- 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 #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 #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)
--
http://gcc.gnu.org/b
--- 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=18967&action=view)
gcc command output
--
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=18966&action=view)
output assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941
--- 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=18965&action=view)
source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41941
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 t
--- 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=18964&action=view)
qmc2main.ii.bz2
Another testcase where var-tracking takes almost forever on setupUi on
x86_64-linux with -g -O2.
--- 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 assign
--- 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 sure
--- 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 have
--- 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
=
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 #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=gcc&view=rev&rev=153896
Log:
PR target/41900
* config/i386/i386.h (ix86_arch_ind
--- 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=gcc&view=rev&rev=153895
Log:
2009-11-04 Richard Earnshaw
PR target/40835
--- 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
--
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last rec
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 I'
--- 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
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 --wi
--- 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"
wrote:
>
>
> --- Comment #6 from rguenther at suse dot de 2009-11-04 09:
Sent from my iPhone
On Nov 4, 2009, at 1:32 AM, "rguenther at suse dot de" > 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 gnu dot org wrote:
--- 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 11:5
1 - 100 of 120 matches
Mail list logo
