: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160612 (experimental) [trunk revision 237336] (GCC)
$
$ g++-6.1 -c small.cpp
small.cpp:8:6: error: variable ‘A B::a’ has initializer but incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71403
--- Comment #7 from Jeffrey A. Law ---
So, to follow-up on my own comment. We start with 3 nested loops. The first
backward jump threading pass threads the backedge of the outermost loop to the
head of the middle loop.
That essentially combine
/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160612 (experimental) [trunk revision 237336] (GCC)
$
$ g++-4.6 -c small.cpp
$
$ g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71403
--- Comment #6 from Jeffrey A. Law ---
But what doesn't make sense here Jan is jump threading, has had the ability to
peel loop iterations forever, so if we're storing that data prior to threading
and expecting it to persist accurately across jum
: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160612 (experimental) [trunk revision 237336] (GCC)
$
$ gcc-trunk -O0 -std=c11 small.c
$
$ gcc-trunk -O1 -std=c11
--enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160612 (experimental) [trunk revision 237336] (GCC)
$
$ g++-5.4 -std=c++11 -c small.cpp
$ clang++-3.8 -std=c++11 -c small.cpp
$
$ g++-trunk -std=c++11 -c small.cpp
small.cpp: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
--- Comment #9 from Michael Duggan ---
"timshen at gcc dot gnu.org" writes:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500
>
> --- Comment #8 from Tim Shen ---
> (In reply to Michael Duggan from comment #7)
>> Hmm... Okay. For the sake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71512
Bug ID: 71512
Summary: ICE: verify_gimple failed libbacktrace could not find
executable to open
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norm
with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160612 (experimental) [trunk revision 237336] (GCC)
$
$ g++-trunk -std=c++11 -c small.cpp
small.cpp:8:52: internal compiler error: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71510
Bug ID: 71510
Summary: [7 Regression] Failed to bootstrap with
--with-arch=corei7 --with-cpu=intel
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71183
--- Comment #8 from James Clarke ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 38691 [details]
> gcc7-pr71183.patch
>
> Not fundamentally flawed, just one line omitted.
> Untested patch that should fix this.
Apologies for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
Bug ID: 71509
Summary: Bitfield causes load hit store with larger store than
load
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #25 from Walter Spector ---
Thank you Dominique!
Walter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71463
--- Comment #3 from Andrew Pinski ---
__warn_unused_result__ is only used when Fortified is used. Which is not the
default unless you are using a distro compiler.
#if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0 \
&& __GNUC_PREREQ (4, 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71508
Bug ID: 71508
Summary: Huge memory usage on compiling with many types
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71507
--- Comment #4 from Dr. David Alan Gilbert ---
Ah thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71507
--- Comment #3 from Markus Trippelsdorf ---
More precisely: It was fixed by Jakub's r237151.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71507
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71507
--- Comment #1 from Dr. David Alan Gilbert ---
Created attachment 38692
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38692&action=edit
compressed, preprocessed c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71507
Bug ID: 71507
Summary: Unending compilation/google's protobuf
(protstream_objectsource_test.cc)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #23 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Jun 12 18:25:25 2016
New Revision: 237340
URL: https://gcc.gnu.org/viewcvs?rev=237340&root=gcc&view=rev
Log:
2016-06-12 Dominique d'Humieres
PR fortran/6075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71183
--- Comment #7 from Jakub Jelinek ---
Created attachment 38691
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38691&action=edit
gcc7-pr71183.patch
Not fundamentally flawed, just one line omitted.
Untested patch that should fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71241
--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Sun Jun 12 17:22:16 2016
New Revision: 237338
URL: https://gcc.gnu.org/viewcvs?rev=237338&root=gcc&view=rev
Log:
PR target/71241
* config/i386/i386.i386-builtin-ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71183
--- Comment #6 from James Clarke ---
This approach is still fundamentally flawed; SOURCE_DATE_EPOCH is still not
honoured when preprocessing:
$ echo 'int main() { puts(__DATE__); }' | SOURCE_DATE_EPOCH=86400 gcc -x c -
: In function ‘main’:
:1:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69659
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71068
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751
--- Comment #22 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Jun 12 14:04:08 2016
New Revision: 237337
URL: https://gcc.gnu.org/viewcvs?rev=237337&root=gcc&view=rev
Log:
2016-06-12 Dominique d'Humieres
PR fortran/6075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66591
--- Comment #2 from Oleg Endo ---
I have started working on the R0 issue...
An R0-pre-allocating pass might potentially break down again when reload/LRA
tries to emit mem access insns, which have an R0 constraint. Although the
pre-allocating wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71506
Bug ID: 71506
Summary: ICE with libvpx with -floop-interchange:
isl_constraint.c:627: expecting integer value
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Se
30 matches
Mail list logo