http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50939
Bug #: 50939
Summary: [C++0x] lambda expression causes ICE when lambda
captures const variable and odr-uses the variable in
function templates
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50869
--- Comment #4 from Alexandre Oliva 2011-11-01
02:09:04 UTC ---
Author: aoliva
Date: Tue Nov 1 02:09:00 2011
New Revision: 180725
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180725
Log:
PR debug/50869
* cselib.c (cfa_base_preserved_re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50920
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45650
Gerald Pfeifer changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50503
simon at pushface dot org changed:
What|Removed |Added
CC||simon at pushface dot org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328
--- Comment #6 from janus at gcc dot gnu.org 2011-10-31 21:51:22 UTC ---
One other thing that just occurred to me is that one might consider cleaning up
'gfc_extend_expr' by removing the 'real_error' argument and returning
{MATCH_YES, MATCH_NO, MAT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46328
--- Comment #5 from janus at gcc dot gnu.org 2011-10-31 21:03:49 UTC ---
For the code in comment #2, there is actually a problem with the 'class_ok'
attribute, which can be fixed with the following patchlet:
Index: gcc/fortran/resolve.c
==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937
--- Comment #9 from Steve Kargl
2011-10-31 21:02:52 UTC ---
On Mon, Oct 31, 2011 at 08:17:51PM +, fwi at inducks dot org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937
>
> --- Comment #8 from fwi at inducks dot org 2011-10-31 20:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50938
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50922
--- Comment #8 from Manuel López-Ibáñez 2011-10-31
20:38:17 UTC ---
(In reply to comment #7)
> I tried this new variant with "gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1"
> With this version it works correctly. Also with avr-gcc this variant
> works corre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937
--- Comment #8 from fwi at inducks dot org 2011-10-31 20:17:51 UTC ---
I do not(In reply to comment #7)
> On Mon, Oct 31, 2011 at 07:25:38PM +, fwi at inducks dot org wrote:
> Yes, the problem of integer overflow that Janne mentioned has
> been
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50922
--- Comment #7 from Rolf Pfister 2011-10-31
19:58:07 UTC ---
I wrote:
> long x=2147483647;
> ulong c;
> for(c=0;c<2147483648UL;c++)
> {
> lcdSendData(x--);
> }
I tried this new variant with "gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1"
Wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937
--- Comment #7 from Steve Kargl
2011-10-31 19:50:41 UTC ---
On Mon, Oct 31, 2011 at 07:25:38PM +, fwi at inducks dot org wrote:
>
> Has the bug been corrected in recent versions of gfortran, or do you really
> mean it's OK that gfortran clai
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50920
--- Comment #1 from Jason Merrill 2011-10-31
19:34:22 UTC ---
Author: jason
Date: Mon Oct 31 19:34:14 2011
New Revision: 180707
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180707
Log:
PR c++/50920
gcc/c-family
* c-common.h (cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50917
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
--- Comment #123 from Jason Merrill 2011-10-31
19:34:32 UTC ---
Author: jason
Date: Mon Oct 31 19:34:26 2011
New Revision: 180708
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180708
Log:
PR libstdc++/1773
* init.c (cpp_init_built
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937
--- Comment #6 from fwi at inducks dot org 2011-10-31 19:25:38 UTC ---
Has the bug been corrected in recent versions of gfortran, or do you really
mean it's OK that gfortran claims an array has been allocated when it really
has not been?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50932
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45650
--- Comment #7 from Anton Shterenlikht 2011-10-31
18:32:07 UTC ---
Yes, *without* files/patch-unwind-ia64.h.
I've built and installed gcc-4.7.0.20111029
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937
--- Comment #4 from fwi at inducks dot org 2011-10-31 18:29:27 UTC ---
I'm using:
$ gfortran --version
GNU Fortran (Ubuntu 4.4.3-4ubuntu5) 4.4.3
I've now tested the same program on a 64-bit CentOs machine
with 16-Gb RAM, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937
--- Comment #3 from Janne Blomqvist 2011-10-31 18:24:14
UTC ---
>From the metadata, it seems you're using version 4.4.3, where the overflow
check when calculating the size to allocate was a bit stupid. Basically it did
the calculation, and if the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937
--- Comment #2 from fwi at inducks dot org 2011-10-31 18:15:57 UTC ---
With "E=1.0D0" instead of "E(N,N,N,N)=1.0D0"
$ gfortran test.f90; for i in `seq -w 10 10 400`; do LANG=C ./a.out $i; done
Sucesfully allocated array of size 10 **4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50882
--- Comment #6 from Graham Reed 2011-10-31 17:53:18
UTC ---
This seems to be enough to trigger the ICE:
int _Unwind_RaiseException(void)
{
int code;
int (*personality) (void);
code=(*personality) ();
}
No flags other than -Bprefix are nee
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50938
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50938
Bug #: 50938
Summary: x86 alloca adds 15 twice
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937
Bug #: 50937
Summary: STAT option with ALLOCATE statement on large arrays
Classification: Unclassified
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50936
Bug #: 50936
Summary: Warnung: abstract method in non-abstract class
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50926
Dmitry changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114
--- Comment #11 from vincenzo Innocente
2011-10-31 16:16:54 UTC ---
the example in comment 10 compiles fine if I add a move constructor
D(A && ia) : a(ia) {}
or a "by value constructor"
D(A ia) : a(ia) {}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45114
--- Comment #10 from vincenzo Innocente
2011-10-31 16:06:41 UTC ---
using the patch of comment 8
in the example below I get
$ c++ -std=gnu++0x -c talias.cc
$ c++ -std=gnu++0x -c talias.cc -DALIAS
talias.cc: In instantiation of ‘Bar::D Bar::d()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935
Bug #: 50935
Summary: All slim LTO tests FAIL on 32-bit Solaris
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50934
Bug #: 50934
Summary: Allocated address for new controlled object is offset
by 16 bytes
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50882
Graham Reed changed:
What|Removed |Added
CC||greed at pobox dot com
--- Comment #5 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50919
--- Comment #4 from Tobias Burnus 2011-10-31
14:41:19 UTC ---
(In reply to comment #2)
> Created attachment 25672 [details]
> patch
Thanks for the patch!
> The second one breaks the ABI, while the first one does not. So, should I
> start
> by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50933
Bug #: 50933
Summary: Wrongly regards BIND(C) types as incompatible
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50915
--- Comment #3 from Titu 2011-10-31 14:07:19
UTC ---
(In reply to comment #2)
> You used --with-included-gettext, that's probably breaking things for you
> (together with -nodefaultlibs I guess).
>
> Anyway, 3.4.3 is no longer supported.
Thanks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50908
--- Comment #5 from vries at gcc dot gnu.org 2011-10-31 14:03:56 UTC ---
> Are these also the same bug?
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50878
Yes, see PR50878 comment 11
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50886
Probably
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50919
--- Comment #3 from janus at gcc dot gnu.org 2011-10-31 13:55:55 UTC ---
(In reply to comment #2)
> Created attachment 25672 [details]
> patch
... regtests cleanly!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50908
Joel Sherrill changed:
What|Removed |Added
CC||joel at gcc dot gnu.org
--- Comment #4 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50932
Bug #: 50932
Summary: inserting a gimple_call with gsi_insert_after creates
error in remove_unreachable_handler
Classification: Unclassified
Product: gcc
Version: 4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #19 from Michael Matz 2011-10-31 13:41:59
UTC ---
Bah, I checked against the patched compiler. Nope, with the unpatched
compiler both descriptor variables stay in the local_decls of native_cpu_up
after inlining (with the source chang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #18 from Michael Matz 2011-10-31 13:37:33
UTC ---
Ah, wrong, native_cpu_up of course calls check_tsc_sync_source, which under
LTO can be inlined. So it's the same issues as PR50741, the patch from
there works around the issue. Unfor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #17 from Michael Matz 2011-10-31 13:16:49
UTC ---
Thank you very much! This really helps and at least reveals something quite
strange with LTO. It falls over the __func__ member of one of the two
static initializers:
Program receiv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50931
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50931
Bug #: 50931
Summary: [avr] Support a 24-bit scalar integer mode
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50919
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46004
Paolo Carlini changed:
What|Removed |Added
CC||jarrydb at cse dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50929
Paolo Carlini changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #9 from Paolo Carli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50919
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50929
--- Comment #8 from Jonathan Wakely 2011-10-31
11:45:32 UTC ---
this is a duplicate of PR 46004
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50922
--- Comment #6 from Rolf Pfister 2011-10-31
11:01:33 UTC ---
Am 31.10.11 11:18, schrieb manu at gcc dot gnu.org:
>
> http://gcc.gnu.org/wiki/FAQ#signed_overflow
>
Im not really convinced that the reason is the overflow.
Where is the overflow in t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #58 from Sebastian Huber
2011-10-31 10:45:43 UTC ---
I tested Jiangning Liu's latest patch. With it GCC 4.6.2 produces valid code
for -march=armv4t, -march=armv5t, -march=armv5te, -march=armv6, and
-march=armv7-m. GCC 4.6.2 produces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50929
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50929
--- Comment #6 from Jarryd Beck 2011-10-31
10:34:16 UTC ---
Yeah I understand now. Basically having a perfect forwarding constructor means
that I need a non-const constructor if I want my example to work as I initially
said.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50922
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50929
--- Comment #5 from Daniel Krügler
2011-10-31 10:18:04 UTC ---
(In reply to comment #4)
> I didn't realise that A(A&) was a better match. I was thinking of C++ code
> where you might write:
>
> template
> A(const T& t);
>
> A(const A& rh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50929
--- Comment #4 from Jarryd Beck 2011-10-31
10:07:04 UTC ---
I didn't realise that A(A&) was a better match. I was thinking of C++ code
where you might write:
template
A(const T& t);
A(const A& rhs);
in which case A(const A&) would be ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50878
--- Comment #11 from vries at gcc dot gnu.org 2011-10-31 10:02:38 UTC ---
> Posted fix: http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02782.html
Posted fix has been approved:
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02787.html, but the patch do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50908
--- Comment #3 from vries at gcc dot gnu.org 2011-10-31 09:42:11 UTC ---
Created attachment 25671
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25671
tentative patch
2011-10-31 Tom de Vries
PR tree-optimization/50908
* tree-ssa-t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50924
--- Comment #4 from fwi at inducks dot org 2011-10-31 08:43:23 UTC ---
Actually contrary to what I wrote my system is 64 bit (I clicked on "edit" on
the top right and somehow the system sent a message that I was starting to
write).
Still when I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #57 from Mikael Pettersson 2011-10-31
08:32:09 UTC ---
(In reply to comment #56)
> (In reply to comment #54)
> > I tested with GCC 4.6.2 and the patch provided by Mikael Pettersson. It
> > works
> > for -march=armv4t and -march=armv
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50929
--- Comment #3 from Daniel Krügler
2011-10-31 08:24:58 UTC ---
(In reply to comment #2)
> That's a shame, and rather annoying. I read pages and pages of the standard to
> try to understand this one. Do you know where this is explained?
Actually
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50926
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50930
Daniel Krügler changed:
What|Removed |Added
Keywords||rejects-valid
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
--- Comment #56 from Jiangning Liu 2011-10-31
07:48:25 UTC ---
(In reply to comment #54)
> I tested with GCC 4.6.2 and the patch provided by Mikael Pettersson. It works
> for -march=armv4t and -march=armv5t, but not for -march=armv5te:
>
Sebas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50930
Bug #: 50930
Summary: [C++0x] Valid brace-or-equal-initializer of non-static
data member rejected
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50929
--- Comment #2 from Jarryd Beck 2011-10-31
07:42:54 UTC ---
That's a shame, and rather annoying. I read pages and pages of the standard to
try to understand this one. Do you know where this is explained?
I added a non-const constructor and also
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50922
--- Comment #4 from Rolf Pfister 2011-10-31
07:38:01 UTC ---
Am 30.10.11 20:14, schrieb pinskia at gcc dot gnu.org:
> --- Comment #3 from Andrew Pinski 2011-10-30
> 19:14:49 UTC ---
> Signed integer overflow is undefined so this is invalid.
>
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50929
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
|
71 matches
Mail list logo
