https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #42 from Thomas Koenig ---
(In reply to Wilco from comment #41)
> Yes, but it was suggested that -std=legacy wasn't the right flag in comment
> 35...
What -std=legacy mostly does is to allow extensioms, not to accept
code which was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69651
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68679
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Thu Feb 18 05:07:55 2016
New Revision: 233512
URL: https://gcc.gnu.org/viewcvs?rev=233512&root=gcc&view=rev
Log:
PR c++/68679
* decl2.c (reset_type_linkage_2): Look throug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68585
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Thu Feb 18 05:08:02 2016
New Revision: 233513
URL: https://gcc.gnu.org/viewcvs?rev=233513&root=gcc&view=rev
Log:
PR c++/68585
* constexpr.c (cxx_eval_bare_aggregate): Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Thu Feb 18 05:08:09 2016
New Revision: 233514
URL: https://gcc.gnu.org/viewcvs?rev=233514&root=gcc&view=rev
Log:
PR c++/65985
* constexpr.c (build_constexpr_constructor_me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69862
Bug ID: 69862
Summary: STL containers not using allocator's definition of
pointers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: blocker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67767
--- Comment #2 from zerotype at yahoo dot com ---
This can be worked around by using:
[[gnu::cold]] [[gnu::noreturn]]
instead of
[[gnu::cold, gnu::noreturn]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69776
--- Comment #12 from Alexander Cherepanov ---
Seems to be fixed, thanks! I've tried several variations, ok too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586
--- Comment #8 from Thomas Preud'homme ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69856
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709
--- Comment #5 from Dominik Vogt ---
@Matthias: So far it only happens for me when building a gcc rpm from source on
a (very slow VM), but not when compiling the same sources. Is there anything
special about your build machine or environment on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68147
--- Comment #8 from Thomas Koenig ---
The fix for 47674 wasn't complete.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 17 22:27:24 2016
New Revision: 233508
URL: https://gcc.gnu.org/viewcvs?rev=233508&root=gcc&view=rev
Log:
PR c++/69850
* gimplify.c (gimplify_cond_expr): Call gimpl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50847
--- Comment #6 from Manuel López-Ibáñez ---
Other testcases:
int baz()
{
while(1) {
break;
return 5; // dead
}
do {
continue;
return 6; // dead
} while(0);
return 1;
}
int bax()
{
while(1) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69857
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476
--- Comment #7 from Manuel López-Ibáñez ---
Richard, perhaps a less aggressive -Wunreachable-code could be implemented just
after (or while) building the control flow graph?
It would not try to be smart with constant propagation or guessing bran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65985
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68585
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68679
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69842
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69842
--- Comment #2 from Jason Merrill ---
Author: jason
Date: Wed Feb 17 20:45:15 2016
New Revision: 233506
URL: https://gcc.gnu.org/viewcvs?rev=233506&root=gcc&view=rev
Log:
PR c++/69842
* method.c (forward_parm): Split out from...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69842
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69861
--- Comment #1 from Gerhard Steinmetz
---
Whereas, with a scalar parameter :
$ cat z2.f90
program p
type t
character :: c
end type
class(t), parameter :: z = t('a')
print *, z%c
end
$ gfortran-6 z2.f90
$ a.out
a
# no erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69861
Bug ID: 69861
Summary: ICE on declaring class parameter array
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69860
--- Comment #1 from Gerhard Steinmetz
---
No ICE if "kind=4" is changed to "kind=1" :
$ cat z2.f90
program p
character(len=2, kind=1) :: a = 'aa', b = 'bb
end
$ gfortran-6 -g z2.f90
z2.f90:2:46:
character(len=2, kind=1) :: a = 'aa', b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69860
Bug ID: 69860
Summary: ICE on missing end apostrophe with character(kind=4)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69859
--- Comment #2 from Gerhard Steinmetz
---
A bit different :
$ cat z7.f90
program p
type t
character(2), allocatable :: a(*)
character(*), allocatable :: b(2)
character(*), allocatable :: c(*)
end type
end
$ gfortran-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69859
--- Comment #1 from Gerhard Steinmetz
---
Some other variants :
$ cat z3.f90
program p
type t
character a ,
character b =
character c :
character d +
character e .
character f %
!...
end type
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69859
Bug ID: 69859
Summary: ICE on incomplete character declaration statement
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499
--- Comment #3 from Gerhard Steinmetz
---
Yet another example :
$ cat z4.f90
module m
class(*) :: z
select type (x => z)
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #41 from Wilco ---
(In reply to Jerry DeLisle from comment #40)
> Do you have a reduced test case of the Fortran code we can look at?
See comment 13/14, the same common array is declared with different sizes in
various places.
> I a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69853
Ville Voutilainen changed:
What|Removed |Added
Status|ASSIGNED|SUSPENDED
--- Comment #2 from Ville
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69651
--- Comment #15 from Jerry DeLisle ---
Author: jvdelisle
Date: Wed Feb 17 17:34:58 2016
New Revision: 233501
URL: https://gcc.gnu.org/viewcvs?rev=233501&root=gcc&view=rev
Log:
2016-02-17 Jerry DeLisle
PR libgfortran/69651
* i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #27 from Manuel López-Ibáñez ---
(In reply to Mark Wielaard from comment #21)
> Although in C a static const is not really like a #define I suspect that
> there are cases where they are used as such in header files. If that is the
> m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69858
Bug ID: 69858
Summary: OpenACC no free memory
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69651
--- Comment #14 from Jerry DeLisle ---
Author: jvdelisle
Date: Wed Feb 17 16:48:57 2016
New Revision: 233500
URL: https://gcc.gnu.org/viewcvs?rev=233500&root=gcc&view=rev
Log:
2016-02-17 Jerry DeLisle
PR libgfortran/69651
* i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #39 from alalaw01 at gcc dot gnu.org ---
Created attachment 37726
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37726&action=edit
Proposed patch (without flag).
Here's a prototype patch, that sets TYPE_SIZE to NULL_TREE but lea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69848
--- Comment #3 from alahay01 at gcc dot gnu.org ---
The standard way of dealing with condition reductions like this is to ignore
the contents of the "if" statement and produce a lot of code to deal with the
general case (it creates two vectors - o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69845
--- Comment #6 from Jakub Jelinek ---
I believe the bug is in extract_muldiv_1, what it does for PLUS_EXPR/MINUS_EXPR
looks inherently unsafe, unless it changes the operation to be actually
performed in a type with defined overflow and then cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69857
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Target||arm
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69537
Bug 69537 depends on bug 69586, which changed state.
Bug 69586 Summary: [6 Regression] FAIL: gcc.dg/uninit-21.c for target
defaulting to short enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69857
Bug ID: 69857
Summary: gcc/config/arm/arm.c:15949: return in strange place ?
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851
--- Comment #3 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #2)
> Do we want a memcpy/memmove like assignment in this case, something else?
memcpy, yes. Why isn't that the default for whole bytes in memory, anyway?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851
--- Comment #4 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > Do we want a memcpy/memmove like assignment in this case, something else?
>
> memcpy, yes. Why isn't that the de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65313
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65313
--- Comment #7 from Bill Schmidt ---
OK, thanks. We'll get somebody looking at this, then.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609
--- Comment #12 from Richard Biener ---
Author: rguenth
Date: Wed Feb 17 14:57:58 2016
New Revision: 233498
URL: https://gcc.gnu.org/viewcvs?rev=233498&root=gcc&view=rev
Log:
2016-02-17 Richard Biener
PR rtl-optimization/69609
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203
--- Comment #10 from Jonathan Wakely ---
Doc patch posted to https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01184.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69856
Bug ID: 69856
Summary: libgfortran/intrinsics/ctime.c:59: order of evaluation
problem ?
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69363
iverbin at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69586
--- Comment #6 from Richard Biener ---
Author: rguenth
Date: Wed Feb 17 14:51:27 2016
New Revision: 233497
URL: https://gcc.gnu.org/viewcvs?rev=233497&root=gcc&view=rev
Log:
2016-02-17 Richard Biener
PR testsuite/69586
* gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69776
--- Comment #11 from Richard Biener ---
Now hopefully fixed on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69855
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69854
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69854
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69855
Bug ID: 69855
Summary: Missing diagnostic for overload that only differs by
return type
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: accepts-invalid
e_optimize_tail_calls_1
S/gcc/tree-tailcall.c:982
Please submit a full bug report,
with preprocessed source if appropriate.
gcc version 6.0.0 20160217 (experimental) (GCC)
i can reproduce it on arm, aarch64 and x86_64 with the attached test case.
(found while building acos.c in musl li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49899
Nick Clifton changed:
What|Removed |Added
CC||nickc at gcc dot gnu.org
--- Comment #2 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65313
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69609
--- Comment #11 from Jeffrey A. Law ---
The PRE/GCSE limits were changed between gcc-5 and gcc-6 to allow it to run on
larger CFGs such as this, but without totally blowing up. So I don't consider
the PRE/GCSE bump a regression, a conscious deci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826
--- Comment #6 from collette ---
Yes, I use ccache.
Thanks for the highlight ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65313
--- Comment #5 from Bill Schmidt ---
What's the status here? Did Jakub's patch fix the underlying problem, or does
this still need investigation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69853
Ville Voutilainen changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69852
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69161
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69161
--- Comment #24 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Wed Feb 17 13:42:35 2016
New Revision: 233496
URL: https://gcc.gnu.org/viewcvs?rev=233496&root=gcc&view=rev
Log:
[AArch64] PR target/69161: Don't use special predicate fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69161
--- Comment #23 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Wed Feb 17 13:39:30 2016
New Revision: 233495
URL: https://gcc.gnu.org/viewcvs?rev=233495&root=gcc&view=rev
Log:
[ARM] PR target/69161: Don't ignore mode when matching co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838
Dominik Vogt changed:
What|Removed |Added
Component|rtl-optimization|regression
--- Comment #3 from Dominik Vo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826
--- Comment #4 from collette ---
The following bug has been filled on fedora bugtracker:
https://bugzilla.redhat.com/show_bug.cgi?id=1309321
This kind of code is used in the cbc solver (version 2.9.7 - with aboca level 4
enable) from the coin-or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69532
davids at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69522
Bernd Schmidt changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69532
--- Comment #6 from davids at gcc dot gnu.org ---
Author: davids
Date: Wed Feb 17 13:16:31 2016
New Revision: 233494
URL: https://gcc.gnu.org/viewcvs?rev=233494&root=gcc&view=rev
Log:
2016-02-17 David Sherwood
gcc/testsuite:
PR ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69752
Bernd Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826
--- Comment #3 from collette ---
I downloaded gcc-5.3.0 from the gnu ftp server.
The example code compiles fine.
So, this is a problem with the fedora gcc version (labelled 5.3.1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69522
--- Comment #12 from Bernd Schmidt ---
Author: bernds
Date: Wed Feb 17 13:13:08 2016
New Revision: 233493
URL: https://gcc.gnu.org/viewcvs?rev=233493&root=gcc&view=rev
Log:
Backport PR69522 use-after-free fix.
c/
PR c/69522
* c-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69522
--- Comment #11 from Bernd Schmidt ---
Author: bernds
Date: Wed Feb 17 13:10:59 2016
New Revision: 233492
URL: https://gcc.gnu.org/viewcvs?rev=233492&root=gcc&view=rev
Log:
Backport use-after-free fix for PR69522.
c/
PR c/69522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69752
--- Comment #5 from Bernd Schmidt ---
Author: bernds
Date: Wed Feb 17 13:03:44 2016
New Revision: 233491
URL: https://gcc.gnu.org/viewcvs?rev=233491&root=gcc&view=rev
Log:
Backport PR69752 fix from mainline.
PR rtl-optimization/69752
apper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 6.0.0 20160217 (experimental) (GCC)
Git (git://gcc.gnu.org/git/gcc.git) hash
commit 0d85ea34a029adf4c3c31edaf8a317905d852faa
Environment
$ uname -a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69852
Bug ID: 69852
Summary: std::vector out of bounds access does not crash
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709
--- Comment #4 from Matthias Klose ---
still seen today; normal bootstrap works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
--- Comment #23 from rguenther at suse dot de ---
On Wed, 17 Feb 2016, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
>
> --- Comment #22 from Jakub Jelinek ---
> Created attachment 37722
> --> https://g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #57 from rguenther at suse dot de ---
On Wed, 17 Feb 2016, sergstesh at yahoo dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
>
> --- Comment #56 from Sergei Steshenko ---
> "-O2 ... and 820MB peak memory use" v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607
--- Comment #22 from vries at gcc dot gnu.org ---
updated patch with testcase from comment 17-19:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01156.html .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69838
Richard Biener changed:
What|Removed |Added
Keywords||ra, wrong-code
Component|regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
--- Comment #22 from Jakub Jelinek ---
Created attachment 37722
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37722&action=edit
gcc6-pr69671.patch
Actually, on a closer look, I believe the only problem are the patterns that
use a vector_m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #56 from Sergei Steshenko ---
"-O2 ... and 820MB peak memory use" vs "-O3 ... and 700MB peak memory use" -
according to my common sense -O3 is stronger than -02 optimization, and one
should expect greater memory use.
So, can the abov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69844
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
Summary|Possibly bogus e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37448
--- Comment #52 from Richard Biener ---
Even at -O1 the inliner degenerates (and var-tracking gives up if you enable
-g)
ipa inlining heuristics : 260.14 (84%) usr 0.50 (23%) sys 260.91 (84%) wall
102217 kB (10%) ggc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
--- Comment #55 from Richard Biener ---
Current GCC 6 numbers:
-O1 -g
var-tracking dataflow : 89.37 (60%) usr 0.09 (23%) sys 89.53 (59%) wall
11542 kB ( 3%) ggc
var-tracking emit : 47.70 (32%) usr 0.05 (13%) sys 47.81 (32%)
1 - 100 of 122 matches
Mail list logo
