.
Apparently, this bug is fixed in gcc HEAD 6.0.0 20150619 (experimental).
My command line was:
g++ -std=c++14 main.cpp -o main.exe
And here is the output of 'g++ -v' on my system:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=d:/tools/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66610
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Summary|C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66610
Bug ID: 66610
Summary: Compound assignments prevent value-numbering
optimization
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65882
--- Comment #6 from Mikhail Maltsev ---
Author: miyuki
Date: Sat Jun 20 00:10:00 2015
New Revision: 224702
URL: https://gcc.gnu.org/viewcvs?rev=224702&root=gcc&view=rev
Log:
PR c++/65882
gcc/cp/
* call.c (build_new_op_1): Check tf_warni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66523
--- Comment #4 from Jack Howarth ---
FYI, Apple's response on radar was...
This is correct behavior from the assembler. The GNU objc runtime is doing bad
things here by assuming an assembler local symbol (any symbol starting with
“L”) is not, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66591
--- Comment #1 from Kazumoto Kojima ---
Author: kkojima
Date: Fri Jun 19 22:58:58 2015
New Revision: 224701
URL: https://gcc.gnu.org/viewcvs?rev=224701&root=gcc&view=rev
Log:
PR target/66591
* config/sh/sh.c (prepare_move_operands): Pre-allocate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #17 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #16)
>From the dump and
floatformat.c:529:2: internal compiler error: Segmentation fault
dto = ldexp (1.0, exponent);
wmfire.c:559:6: internal compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609
Bug ID: 66609
Summary: [sh] Relative address expressions bind at as-time,
even if symbol is weak
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66608
--- Comment #1 from siflfran at hawo dot net ---
% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /usr/src/gcc-5.1.0/configure --dis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66608
Bug ID: 66608
Summary: gnat 5.1 fails with compilation abandoned, minimal
testcase included
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66104
--- Comment #1 from Thomas Schweikle ---
ERROR: Failed to check out http://gcc.gnu.org/svn/gcc/branches/gcc-5-branch
org.tmatesoft.svn.core.SVNException: svn: E175002: Processing REPORT request
response failed: Elementtyp "D:creator-displayname"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66607
Bug ID: 66607
Summary: ICE instantiating a template on a function reference
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66606
--- Comment #1 from Martin Sebor ---
One other observation (and actually the reason why I found this problem) is
that the diagnostic GCC issues for the call to main in bar:
int bar () { return main (); }
is misleading. The operand of the retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66606
Bug ID: 66606
Summary: missing diagnostic on using function main
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66603
--- Comment #5 from Marc Glisse ---
Another detail that might confuse you: if you write
in n=400;
int a[n];
it will probably not crash. The reason is that variables like 'int a[400]'
exist for the whole length of the function, the memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66604
Mikhail Maltsev changed:
What|Removed |Added
CC||miyuki at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66603
--- Comment #4 from Marc Glisse ---
(In reply to gunney1 from comment #3)
> Because of the effects of the stream insertion. But maybe I don't
> understand very well their relationship.
First, I guess it does not crash with icpc because icpc opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66603
--- Comment #3 from gunney1 at llnl dot gov ---
Because of the effects of the stream insertion. But maybe I don't understand
very well their relationship.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66603
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66515
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Fri Jun 19 19:30:37 2015
New Revision: 224695
URL: https://gcc.gnu.org/viewcvs?rev=224695&root=gcc&view=rev
Log:
PR c++/66515
* call.c (implicit_conversion): Call reshape_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66605
--- Comment #1 from Kyle ---
I should note that removing "-Wunused-parameter" allows compilation without
error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66585
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Fri Jun 19 19:17:16 2015
New Revision: 224694
URL: https://gcc.gnu.org/viewcvs?rev=224694&root=gcc&view=rev
Log:
PR c++/66585
* pt.c (instantiate_class_template_1): Clear
.
||com
--- Comment #1 from Daniel Krügler ---
The segfault also occurs in the current head (tested: gcc HEAD 6.0.0 20150619
(experimental))
(tested agains gcc HEAD
6.0.0 20150619 (experimental)) has fixed that problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66605
Bug ID: 66605
Summary: -Wunused-parameter causes internal compiler error with
gfortran 5.1.0
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66597
--- Comment #4 from Aldy Hernandez ---
On 06/19/2015 11:50 AM, krebbel at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66597
>
> --- Comment #2 from Andreas Krebbel ---
> (In reply to Aldy Hernandez from comment #1)
>> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66597
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66482
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66597
--- Comment #2 from Andreas Krebbel ---
(In reply to Aldy Hernandez from comment #1)
> Is that the actual line number (18034) with current mainline? 18034 does
> not look like a place we could ICE in.
>
> Perhaps it's the ICE in 25535, because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66585
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Fri Jun 19 18:37:41 2015
New Revision: 224684
URL: https://gcc.gnu.org/viewcvs?rev=224684&root=gcc&view=rev
Log:
PR c++/66585
* pt.c (instantiate_class_template_1): Clear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65880
--- Comment #2 from Jason Merrill ---
Author: jason
Date: Fri Jun 19 18:24:29 2015
New Revision: 224683
URL: https://gcc.gnu.org/viewcvs?rev=224683&root=gcc&view=rev
Log:
PR c++/65880
* decl.c (build_ptrmemfunc_type): Check TYPE_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65973
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Fri Jun 19 18:24:24 2015
New Revision: 224682
URL: https://gcc.gnu.org/viewcvs?rev=224682&root=gcc&view=rev
Log:
PR c++/65973
* constexpr.c (build_constexpr_constructor_me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65843
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Fri Jun 19 18:24:18 2015
New Revision: 224681
URL: https://gcc.gnu.org/viewcvs?rev=224681&root=gcc&view=rev
Log:
PR c++/65843
* pt.c (tsubst_copy_and_build): Register a ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66061
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Fri Jun 19 18:24:13 2015
New Revision: 224680
URL: https://gcc.gnu.org/viewcvs?rev=224680&root=gcc&view=rev
Log:
PR c++/66061
* g++.dg/cpp1y/var-templ31.C: New.
Added:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65973
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Fri Jun 19 18:15:30 2015
New Revision: 224677
URL: https://gcc.gnu.org/viewcvs?rev=224677&root=gcc&view=rev
Log:
PR c++/65973
* constexpr.c (build_constexpr_constructor_me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65843
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Fri Jun 19 18:15:24 2015
New Revision: 224676
URL: https://gcc.gnu.org/viewcvs?rev=224676&root=gcc&view=rev
Log:
PR c++/65843
* pt.c (tsubst_copy_and_build): Register a ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66061
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Fri Jun 19 18:15:17 2015
New Revision: 224675
URL: https://gcc.gnu.org/viewcvs?rev=224675&root=gcc&view=rev
Log:
PR c++/66061
* g++.dg/cpp1y/var-templ31.C: New.
Added:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65880
--- Comment #1 from Jason Merrill ---
Author: jason
Date: Fri Jun 19 18:15:36 2015
New Revision: 224678
URL: https://gcc.gnu.org/viewcvs?rev=224678&root=gcc&view=rev
Log:
PR c++/65880
* decl.c (build_ptrmemfunc_type): Check TYPE_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66604
--- Comment #1 from Eric Moyer ---
Created attachment 35817
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35817&action=edit
Preprocessed source (zipped because of attachment length limit)
C_OPTIONS='-v' '-save-temps' '-c' '-Wno-format-y2k' '-pthread' '-O2'
'-fPIC' '-std=c++11' '-g' '-Wall' '-Wextra' '-Werror'
'-Wpedantic' '-I' '../../../../.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66603
Bug ID: 66603
Summary: using std::cout causes segfault with unrelated array
declaration
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66602
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66601
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #1 from Jonatha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #16 from John Paul Adrian Glaubitz ---
I included some more context:
glaubitz@tirpitz:~/debian/segfault-test$ objdump -d
/usr/lib/gcc/sh4-linux-gnu/4.9/cc1 |grep -C20 763a40
763a18: 10 38 cmp/eq r1,r8
763a1a:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
--- Comment #6 from David Malcolm ---
(In reply to ktkachov from comment #4)
> (In reply to David Malcolm from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > This should be true on all targets which have -mcpu=native (or
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
--- Comment #5 from David Malcolm ---
Created attachment 35815
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35815&action=edit
Hacky work-in-progress fix, using hardcoded calls to host_detect_local_cpu
The attached patch is a hack, in tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66601
Bug ID: 66601
Summary: RFE: improve diagnostics for failure to deduce
template parameter pack that is not in the last
position in the parameter list
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66602
Bug ID: 66602
Summary: std::tuple bug when constructed with temporary empty
object
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66599
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #7 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66599
--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to Romain Dolbeau from comment #5)
> OK thank you everyone. Not yet used to the idiosyncrasy of aarch64. Perhaps
> the explanation of the "Q" constraint should mention it's required for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66599
Romain Dolbeau changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #5 from Romain Dolbea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914
--- Comment #7 from Bill Schmidt ---
Looking at the vsx_register_operand predicate in predicates.md, this seems to
need some TLC. Will discuss with Mike Meissner offline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66600
Bug ID: 66600
Summary: sign_mask meets valgrind
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66599
--- Comment #4 from ktkachov at gcc dot gnu.org ---
You should use "Q" when you want a memory address with only a register
addressing mode (i.e. no offsets), which is what AdvancedSIMD ldn/stn
instructions take.
I used:
void fun(unsigned int *src
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66599
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66599
--- Comment #2 from Romain Dolbeau ---
Do you mean "Q" in this case, or always when using ld4/st4 (and probably quite
a few others)?
If I pre-compute a pointer with src+16, I still get the error (I'm guessing an
optimization is propagating the p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66549
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to David Malcolm from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > This should be true on all targets which have -mcpu=native (or
> > -march=native). Note x86 options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
--- Comment #3 from David Malcolm ---
Some notes:
The following archs seem to implement a "host_detect_local_cpu" C++ callback,
implementing the spec-language function "local_cpu_detect":
grep -nH -e host_detect_local_cpu */*/*.h
config/aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
--- Comment #2 from David Malcolm ---
(In reply to Andrew Pinski from comment #1)
> This should be true on all targets which have -mcpu=native (or
> -march=native). Note x86 options are not always the same on x86 vs arm vs
> aarch64 vs ppc.
Tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57600
--- Comment #6 from Marc Glisse ---
(In reply to alalaw01 from comment #5)
> Can you give an example where it not only doesn't help, but actually hurts?
I don't remember at all what I was talking about. I can imagine that if we are
in a branch p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66599
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=64190
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66599
Bug ID: 66599
Summary: on aarch64, some parameters to memory constraints
causes wrong ASM generation
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592
--- Comment #5 from Steve Kargl ---
On Fri, Jun 19, 2015 at 11:49:55AM +, matz at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592
>
> --- Comment #4 from Michael Matz ---
> Can't reproduce with r224605 and r22464
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57600
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
CC||alalaw01 at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #15 from Kazumoto Kojima ---
(In reply to John Paul Adrian Glaubitz from comment #14)
> Created attachment 35812 [details]
> Log for strace -i -f -o segfaultlog /usr/lib/gcc/sh4-linux-gnu/4.9/cc1
> wmfire.i
30836 [00763a40] --- SIGSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66597
--- Comment #1 from Aldy Hernandez ---
Is that the actual line number (18034) with current mainline? 18034 does not
look like a place we could ICE in.
Perhaps it's the ICE in 25535, because if it is, then it is a duplicate of
PR66482.
Could yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66482
--- Comment #2 from Aldy Hernandez ---
Proposed patch awaiting review:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00943.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308
Christophe Lyon changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308
--- Comment #15 from Christophe Lyon ---
Testcase committed to trunk as r224649, to gcc-5-branch as r224670.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308
--- Comment #14 from Christophe Lyon ---
Author: clyon
Date: Fri Jun 19 14:41:32 2015
New Revision: 224671
URL: https://gcc.gnu.org/viewcvs?rev=224671&root=gcc&view=rev
Log:
2015-06-19 Christophe Lyon
PR target/62308
Backport
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65843
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #14 from John Paul Adrian Glaubitz ---
Created attachment 35812
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35812&action=edit
Log for strace -i -f -o segfaultlog /usr/lib/gcc/sh4-linux-gnu/4.9/cc1 wmfire.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #13 from John Paul Adrian Glaubitz ---
Alright:
glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc -E wmfire.c -o
wmfire.i $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0)
glaubitz@tirpitz:~/debian/segfaul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
--- Comment #12 from James Y Knight ---
Since this would at least theoretically be a c++11 ABI change -- although it
seems likely not to impact the ABI of most actual software -- it seems like
it'd be a really good idea to fix it ASAP, before too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #12 from Kazumoto Kojima ---
All my 4.9 compilers don't fail for given pre-processed source.
Could you show us segfaultlog with running the following commands?
gcc -E wmfire.c -o wmfire.i
strace -i -f -o segfaultlog /usr/lib/gcc/sh4-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66581
--- Comment #1 from Ilya Enkovich ---
Fixed in trunk by r224644.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #11 from John Paul Adrian Glaubitz ---
Created attachment 35811
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35811&action=edit
Same compiler invocation, but this time with strace -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #10 from John Paul Adrian Glaubitz ---
Created attachment 35810
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35810&action=edit
Pre-processed source for wmfire.c test compile (run without strace)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #9 from John Paul Adrian Glaubitz ---
Created attachment 35809
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35809&action=edit
Pre-processed source for wmfire.c test compile (run with strace)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #8 from John Paul Adrian Glaubitz ---
Created attachment 35808
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35808&action=edit
strace of gcc segfaulting when compiling wmfire.c on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #7 from John Paul Adrian Glaubitz ---
Alright, I did some further tests. I downloaded the source package for "wmfire"
with "apt-get source wmfire" and installed its build dependencies with "apt-get
build-dep wmfire".
Then I just trie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598
Bug ID: 66598
Summary: With -O3 gcc incorrectly assumes aligned SSE
instructions (e.g. movapd) can be used
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #6 from John Paul Adrian Glaubitz ---
(In reply to Kazumoto Kojima from comment #5)
> (In reply to Matthias Klose from comment #0)
> > Created attachment 35792 [details]
> > preprocessed source
> >
> > seen while building the GCC 5 b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66549
--- Comment #5 from Mikael Morin ---
Author: mikael
Date: Fri Jun 19 12:50:00 2015
New Revision: 224648
URL: https://gcc.gnu.org/viewcvs?rev=224648&root=gcc&view=rev
Log:
Fix openmp global state fortran regression
PR fortran/66549
gcc/f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66597
Bug ID: 66597
Summary: [6 Regression] Bootstrap failure since debug-early
merge
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #5 from Kazumoto Kojima ---
(In reply to Matthias Klose from comment #0)
> Created attachment 35792 [details]
> preprocessed source
>
> seen while building the GCC 5 branch using GCC 4.9 SVN 20150531 (r223898):
I can't reproduce the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66253
Michael Matz changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592
--- Comment #4 from Michael Matz ---
Can't reproduce with r224605 and r224647. Can you update and retry?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592
Richard Biener changed:
What|Removed |Added
CC||matz at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
--- Comment #10 from kugan at gcc dot gnu.org ---
(In reply to Marc Glisse from comment #6)
> (In reply to kugan from comment #5)
> > I think it should be in from front-end?
>
> ?
Sorry for the confusing terminology.
for the case
int fsigned(i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #4 from John Paul Adrian Glaubitz ---
Created attachment 35807
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35807&action=edit
strace of journalctl_220-6-sh4 during segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #3 from John Paul Adrian Glaubitz ---
So, it seems Matthias is right, there is definitely a regression in gcc-4.9 in
the code generation. Packages that were recently build with gcc-4.9_4.9.2-20 or
newer tend to segfault.
I noticed th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66464
--- Comment #7 from Jonathan Wakely ---
No, it will be in 5.1.1-4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578
--- Comment #12 from vehre at gcc dot gnu.org ---
Created attachment 35806
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35806&action=edit
Incomplete patch
The attached patch addresses some of the issues, but unfortunately does it open
som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66596
--- Comment #1 from Ed Catmur ---
Note: error produced is:
prog.cc: In instantiation of 'void g() [with T = int]':
prog.cc:6:21: required from here
prog.cc:5:30: error: 'U::f()' is not a member of 'V'
template void g() { t.f(); }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578
--- Comment #11 from Mikael Morin ---
In gfc_conv_expr_descriptor, the bounds used to initialize the descriptor are
different from the ones passed to gfc_get_array_type_bounds. That is the heart
of the problem, I think.
What I don't understand i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578
--- Comment #10 from Mikael Morin ---
(In reply to Thomas Koenig from comment #9)
> Unfortunately, this does not appear to fix the bug (at least not completely).
> I still get an invalid free.
Indeed, unfortunately this:
(In reply to Mikael Mor
1 - 100 of 109 matches
Mail list logo
