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=66604
Mikhail Maltsev miyuki at gcc dot gnu.org changed:
What|Removed |Added
CC||miyuki at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66603
--- Comment #4 from Marc Glisse glisse at gcc dot gnu.org ---
(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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65882
--- Comment #6 from Mikhail Maltsev miyuki at gcc dot gnu.org ---
Author: miyuki
Date: Sat Jun 20 00:10:00 2015
New Revision: 224702
URL: https://gcc.gnu.org/viewcvs?rev=224702root=gccview=rev
Log:
PR c++/65882
gcc/cp/
* call.c
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=66523
--- Comment #4 from Jack Howarth howarth.at.gcc at gmail dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66606
--- Comment #1 from Martin Sebor msebor at gcc dot gnu.org ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #17 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(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);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66104
--- Comment #1 from Thomas Schweikle t...@vr-web.de ---
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
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66591
--- Comment #1 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
Author: kkojima
Date: Fri Jun 19 22:58:58 2015
New Revision: 224701
URL: https://gcc.gnu.org/viewcvs?rev=224701root=gccview=rev
Log:
PR target/66591
* config/sh/sh.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66603
--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org ---
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
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:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66610
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords|
.
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/5.1.0/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
--- Comment #7 from Andrew Pinski pinskia 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?
?
Yes this is really not a good comment to make. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66541
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66518
--- Comment #1 from Thomas Schwinge tschwinge at gcc dot gnu.org ---
Author: tschwinge
Date: Fri Jun 19 07:41:37 2015
New Revision: 224639
URL: https://gcc.gnu.org/viewcvs?rev=224639root=gccview=rev
Log:
libgomp: XFAIL two libgomp.oacc-* tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66596
Bug ID: 66596
Summary: Type that is not dependent on the variable template
template parameters
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66588
--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #2)
(In reply to Uroš Bizjak from comment #1)
BTW: x86_64 is missing any form of zero-extended cmove.
... please see [1] how x86_64 implements it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #6 from John Paul Adrian Glaubitz glaubitz at physik dot
fu-berlin.de ---
(In reply to Kazumoto Kojima from comment #5)
(In reply to Matthias Klose from comment #0)
Created attachment 35792 [details]
preprocessed source
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #12 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #10 from John Paul Adrian Glaubitz glaubitz at physik dot
fu-berlin.de ---
Created attachment 35810
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35810action=edit
Pre-processed source for wmfire.c test compile (run without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #9 from John Paul Adrian Glaubitz glaubitz at physik dot
fu-berlin.de ---
Created attachment 35809
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35809action=edit
Pre-processed source for wmfire.c test compile (run with strace)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #11 from John Paul Adrian Glaubitz glaubitz at physik dot
fu-berlin.de ---
Created attachment 35811
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35811action=edit
Same compiler invocation, but this time with strace -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #7 from John Paul Adrian Glaubitz glaubitz at physik dot
fu-berlin.de ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #8 from John Paul Adrian Glaubitz glaubitz at physik dot
fu-berlin.de ---
Created attachment 35808
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35808action=edit
strace of gcc segfaulting when compiling wmfire.c on sh4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66581
--- Comment #1 from Ilya Enkovich ienkovich at gcc dot gnu.org ---
Fixed in trunk by r224644.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
--- Comment #12 from James Y Knight foom at fuhm dot net ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #13 from John Paul Adrian Glaubitz glaubitz at physik dot
fu-berlin.de ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66253
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66549
--- Comment #5 from Mikael Morin mikael at gcc dot gnu.org ---
Author: mikael
Date: Fri Jun 19 12:50:00 2015
New Revision: 224648
URL: https://gcc.gnu.org/viewcvs?rev=224648root=gccview=rev
Log:
Fix openmp global state fortran regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||matz at gcc
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(int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #5 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(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):
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592
--- Comment #4 from Michael Matz matz at gcc dot gnu.org ---
Can't reproduce with r224605 and r224647. Can you update and retry?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
--- Comment #6 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to kugan from comment #5)
I think it should be in from front-end?
?
Tried fixing it in VRP like:
You don't seem to use ranges at all. This might be the right place to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52144
--- Comment #7 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Jun 19 06:58:22 2015
New Revision: 224638
URL: https://gcc.gnu.org/viewcvs?rev=224638root=gccview=rev
Log:
PR target/66541
PR target/52144
* config/arm/arm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66541
--- Comment #2 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Fri Jun 19 06:58:22 2015
New Revision: 224638
URL: https://gcc.gnu.org/viewcvs?rev=224638root=gccview=rev
Log:
PR target/66541
PR target/52144
* config/arm/arm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578
--- Comment #9 from Thomas Koenig tkoenig at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #8)
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index fece3ab..0b96de1 100644
--- a/gcc/fortran/trans-array.c
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
--- Comment #8 from Marc Glisse glisse at gcc dot gnu.org ---
(for cmp1 (eq ne)
cmp2 (lt ge)
(simplify
(cmp1 (trunc_div @0 @1) integer_zerop)
(if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
|| VECTOR_INTEGER_TYPE_P (TREE_TYPE (@0)))
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=35806action=edit
Incomplete patch
The attached patch addresses some of the issues, but unfortunately does it open
some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #3 from John Paul Adrian Glaubitz glaubitz at physik dot
fu-berlin.de ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #4 from John Paul Adrian Glaubitz glaubitz at physik dot
fu-berlin.de ---
Created attachment 35807
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35807action=edit
strace of journalctl_220-6-sh4 during segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578
--- Comment #10 from Mikael Morin mikael at gcc dot gnu.org ---
(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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66596
--- Comment #1 from Ed Catmur ed at catmur dot co.uk ---
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'
templateclass T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66464
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org ---
No, it will be in 5.1.1-4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66590
Manuel López-Ibáñez manu at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66593
--- Comment #2 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to David Malcolm from comment #0)
Currently libgccjit uses -mtune=generic; I'm working on enabling
-mtune=native for libgccjit.
However, on i386/x86_64 with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64130
--- Comment #9 from Marc Glisse glisse at gcc dot gnu.org ---
Forget comment #8, it can introduce abs(INT_MIN) which would be bad.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66578
--- Comment #11 from Mikael Morin mikael at gcc dot gnu.org ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308
--- Comment #14 from Christophe Lyon clyon at gcc dot gnu.org ---
Author: clyon
Date: Fri Jun 19 14:41:32 2015
New Revision: 224671
URL: https://gcc.gnu.org/viewcvs?rev=224671root=gccview=rev
Log:
2015-06-19 Christophe Lyon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66597
--- Comment #1 from Aldy Hernandez aldyh at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308
--- Comment #15 from Christophe Lyon clyon at gcc dot gnu.org ---
Testcase committed to trunk as r224649, to gcc-5-branch as r224670.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #15 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #14 from John Paul Adrian Glaubitz glaubitz at physik dot
fu-berlin.de ---
Created attachment 35812
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35812action=edit
Log for strace -i -f -o segfaultlog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308
Christophe Lyon clyon at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66482
--- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org ---
Proposed patch awaiting review:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00943.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65843
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
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=66599
--- Comment #2 from Romain Dolbeau romain.gcc at dolbeau dot name ---
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
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
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |INVALID
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64190
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
--- Comment #2 from David Malcolm dmalcolm at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57600
--- Comment #6 from Marc Glisse glisse at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66594
--- Comment #5 from David Malcolm dmalcolm at gcc dot gnu.org ---
Created attachment 35815
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35815action=edit
Hacky work-in-progress fix, using hardcoded calls to host_detect_local_cpu
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592
--- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
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 matz at
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:
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=66594
--- Comment #3 from David Malcolm dmalcolm at gcc dot gnu.org ---
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
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 are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66549
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65914
--- Comment #7 from Bill Schmidt wschmidt at gcc dot gnu.org ---
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=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
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66592
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66599
Romain Dolbeau romain.gcc at dolbeau dot name changed:
What|Removed |Added
Resolution|INVALID |FIXED
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=66594
--- Comment #6 from David Malcolm dmalcolm at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563
--- Comment #16 from John Paul Adrian Glaubitz glaubitz at physik dot
fu-berlin.de ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66601
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66602
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last
' '-save-temps' '-c' '-Wno-format-y2k' '-pthread' '-O2'
'-fPIC' '-std=c++11' '-g' '-Wall' '-Wextra' '-Werror'
'-Wpedantic' '-I' '../../../../../../include' '-I'
'../../../../../../include/internal' '-I' '.' '-I'
'/netopt/ncbi_tools64/c++.by-
date/20150619/src/internal/variation/snp/dbsnp2.0/lib' '-D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65973
--- Comment #5 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Fri Jun 19 18:15:30 2015
New Revision: 224677
URL: https://gcc.gnu.org/viewcvs?rev=224677root=gccview=rev
Log:
PR c++/65973
* constexpr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65973
--- Comment #6 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Fri Jun 19 18:24:24 2015
New Revision: 224682
URL: https://gcc.gnu.org/viewcvs?rev=224682root=gccview=rev
Log:
PR c++/65973
* constexpr.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65843
--- Comment #4 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Fri Jun 19 18:24:18 2015
New Revision: 224681
URL: https://gcc.gnu.org/viewcvs?rev=224681root=gccview=rev
Log:
PR c++/65843
* pt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66061
--- Comment #5 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Fri Jun 19 18:24:13 2015
New Revision: 224680
URL: https://gcc.gnu.org/viewcvs?rev=224680root=gccview=rev
Log:
PR c++/66061
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65880
--- Comment #2 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Fri Jun 19 18:24:29 2015
New Revision: 224683
URL: https://gcc.gnu.org/viewcvs?rev=224683root=gccview=rev
Log:
PR c++/65880
* decl.c
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=66604
--- Comment #1 from Eric Moyer eric_moyer at yahoo dot com ---
Created attachment 35817
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35817action=edit
Preprocessed source (zipped because of attachment length limit)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65843
--- Comment #3 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Fri Jun 19 18:15:24 2015
New Revision: 224676
URL: https://gcc.gnu.org/viewcvs?rev=224676root=gccview=rev
Log:
PR c++/65843
* pt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66061
--- Comment #4 from Jason Merrill jason at gcc dot gnu.org ---
Author: jason
Date: Fri Jun 19 18:15:17 2015
New Revision: 224675
URL: https://gcc.gnu.org/viewcvs?rev=224675root=gccview=rev
Log:
PR c++/66061
*
1 - 100 of 113 matches
Mail list logo
