https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242
Bug ID: 62242
Summary: ICE with character function in expression
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169
--- Comment #5 from M Welinder ---
I agree that anyone depending on map and multimap iterators to mix deserves
whatever happens as a result. It would, however, be nice g++ would reject such
programs outright. Currently this is accepted:
st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62206
--- Comment #3 from Jonathan Wakely ---
Yes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62169
--- Comment #4 from Jonathan Wakely ---
The standard allows iterators of different containers to be different, your
program is not portable of it assumes they will (or will not) be the same type.
I don't consider this a bug, and am not very moti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57533
Ville Voutilainen changed:
What|Removed |Added
CC||tsimpson at ubuntu dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62172
Ville Voutilainen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62172
--- Comment #2 from Jonathan Wakely ---
I think this is a DUP of an existing report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62189
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60433
John David Anglin changed:
What|Removed |Added
Component|debug |c++
--- Comment #1 from John David A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62227
--- Comment #1 from Jonathan Wakely ---
A template cannot be a move constructor and so it is not legal to elide it.
Removing line (1) means there is a move constructor implicitly declared, which
will be used and can be elided.
Removing line (2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62229
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62223
--- Comment #7 from Jonathan Wakely ---
(In reply to tower120 from comment #6)
> Because "there are no arguments to 'static_asssert' that depend on a
> template parameter" means that there IS such a function, but it does not
> accept current para
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241
--- Comment #4 from Georg Rudoy <0xd34df00d at gmail dot com> ---
Also, while experimenting I've found that adding a non-initializing capture
element to the list somewhat mitigates the issue. That is, if the capture list
looks like `[smth, foo = b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241
--- Comment #3 from Georg Rudoy <0xd34df00d at gmail dot com> ---
Not yet. Should I?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241
--- Comment #2 from Andrew Pinski ---
Have you tried 5.x yet?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241
--- Comment #1 from Georg Rudoy <0xd34df00d at gmail dot com> ---
Created attachment 33387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33387&action=edit
Successfully compiling code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62241
Bug ID: 62241
Summary: C++14 generalized lambda capture doesn't work with
uniform initialization syntax.
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50374
vincenzo Innocente changed:
What|Removed |Added
Known to fail||4.9.1
--- Comment #27 from vincenzo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62019
John David Anglin changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61858
John David Anglin changed:
What|Removed |Added
Target|hppa-unknown-linux-gnu |hppa*-*-* (32-bit)
Hos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038
John David Anglin changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038
--- Comment #8 from John David Anglin ---
Author: danglin
Date: Sat Aug 23 16:00:46 2014
New Revision: 214399
URL: https://gcc.gnu.org/viewcvs?rev=214399&root=gcc&view=rev
Log:
PR target/62038
* config/pa/pa.c (pa_output_function_epilogu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038
--- Comment #7 from John David Anglin ---
Author: danglin
Date: Sat Aug 23 15:57:57 2014
New Revision: 214398
URL: https://gcc.gnu.org/viewcvs?rev=214398&root=gcc&view=rev
Log:
PR target/62038
* config/pa/pa.c (pa_output_function_epilogu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038
--- Comment #6 from John David Anglin ---
Author: danglin
Date: Sat Aug 23 15:56:07 2014
New Revision: 214397
URL: https://gcc.gnu.org/viewcvs?rev=214397&root=gcc&view=rev
Log:
PR target/62038
* config/pa/pa.c (pa_output_function_epilogu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61669
Steven Bosscher changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160
Dmitry Gorbachev changed:
What|Removed |Added
Attachment #32115|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62240
Bug ID: 62240
Summary: A using-declaration within a class can publish a
public base of a private base.
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62239
Dmitry Gorbachev changed:
What|Removed |Added
Keywords||ice-on-valid-code, lto
Known to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62239
Bug ID: 62239
Summary: [5 Regression] ICE: in execute_todo, at passes.c:1795
with LTO
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
P
/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20140823 (experimental) [trunk revision 214394] (GCC)
$
$ gcc-trunk -O0 -c fn1.c
$ gcc-trunk -O0 -c main.c
$ gcc-trunk -O3 *.o
$ ./a.out
$
$ gcc-4.8 -flto -O0 -c fn1.c
$ gcc-4.8 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160
--- Comment #3 from Marc Glisse ---
ISTR that building with CFLAGS_FOR_TARGET="-g -O2 -flto -ffat-lto-objects",
same for CXXFLAGS_FOR_TARGET, and --disable-bootstrap used to complete, but now
it fails during the link of .libs/libstdc++.so.6.0.21:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60550
--- Comment #4 from Dominique d'Humieres ---
Reduced test (ICE with r208775)
! { dg-do compile }
MODULE m_benchmark_function
IMPLICIT NONE
INTEGER, PARAMETER :: wpr = 8
TYPE, ABSTRACT :: problem
INTEGER, PUBLIC :: problem_dimension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60550
--- Comment #3 from Dominique d'Humieres ---
> This works with current trunk.
Confirmed. I don't get any ICE with the 4.9 releases (4.9.0, 4.9.1, and
prerelease 4.9.2, r214296). I get the ICE for 4.9 r208775 (2014-03-23), but not
for 4.10 r20983
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62237
Bug ID: 62237
Summary: ostream single character printing is slower than
fprintf with "%c".
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60110
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #
35 matches
Mail list logo
