https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64895
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316
--- Comment #4 from Markus Trippelsdorf ---
I'm not sure that uninitialized memory is the cause of this bug.
Looks more like a bug in the hash-table implementation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
--- Comment #29 from rguenther at suse dot de ---
On Thu, 5 Mar 2015, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
>
> --- Comment #26 from Jan Hubicka ---
> I completely missed the discussion concerni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321
--- Comment #5 from rguenther at suse dot de ---
On Thu, 5 Mar 2015, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65321
>
> --- Comment #4 from rsandifo at gcc dot gnu.org
> ---
> (In reply to Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292
--- Comment #6 from John Marino ---
Thanks Khem,
With your patch, webkit-qt5 continued to build on gcc7 (good news) but I did
not succeed with gcc-5. The new error during linking is:
/usr/libexec/binutils224/elf/ld.bfd:
/wrkdirs/www/webkit-qt5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65292
--- Comment #7 from John Marino ---
typo -- it was gcc 4.7, not gcc7 that succeeded. (I say that to help answer
the question in the QT5 bug report)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58158
--- Comment #20 from Tom Li ---
Great job, I'll test it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65325
--- Comment #7 from Stephane Cerveau ---
It is already without the cast ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316
--- Comment #5 from Tobias Burnus ---
Created attachment 34972
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34972&action=edit
valgrind output (for the lto1 child call)
(In reply to Jan Hubicka from comment #3)
> $ while true ; do ./xgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316
--- Comment #6 from Markus Trippelsdorf ---
(In reply to Tobias Burnus from comment #5)
> Created attachment 34972 [details]
> valgrind output (for the lto1 child call)
>
> (In reply to Jan Hubicka from comment #3)
> > $ while true ; do ./xgcc -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65120
--- Comment #10 from Richard Biener ---
It was just noted that
"But then again (!a == 0) is the same as !(a == 0), so the warning
is pretty pointless when the right side is constant zero."
so we should probably not warn for this case either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65330
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Priority|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65325
--- Comment #8 from Stephane Cerveau ---
Created attachment 34973
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34973&action=edit
assembly code
This is the version with float casting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928
--- Comment #14 from Richard Biener ---
Note that if we fix out-of-SSA coalescing (patch in testing) then RTL CSE
explodes via DF.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65325
--- Comment #9 from Sebastian Dröge ---
The assembly code looks exactly the same to me, except for the source
locations. But I also don't see the multiplication in either, only conversion
between integers and floating point values, and then stori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65200
--- Comment #3 from Janne Blomqvist ---
Untested patch:
Index: io/open.c
===
--- io/open.c (revision 221202)
+++ io/open.c (working copy)
@@ -502,34 +502,12 @@
s = open_exter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65200
--- Comment #4 from Janne Blomqvist ---
Suggested doc patch:
Index: gfortran.texi
===
--- gfortran.texi (revision 221234)
+++ gfortran.texi (working copy)
@@ -1328,6 +13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928
--- Comment #15 from Richard Biener ---
Author: rguenth
Date: Fri Mar 6 12:34:28 2015
New Revision: 221237
URL: https://gcc.gnu.org/viewcvs?rev=221237&root=gcc&view=rev
Log:
2015-03-06 Richard Biener
PR middle-end/64928
* tree-ssa-l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928
--- Comment #16 from Richard Biener ---
Created attachment 34974
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34974&action=edit
Patch to limit coalescing amount
The committed patch improves peak memory usage from 7.6GB to 5.8GB for the
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883
--- Comment #31 from Dominique d'Humieres ---
> I've committed Iain's patch, any further changes can wait for stage 1.
Revision r221160 does not fix the failures on x86_64-apple-darwin10: see
https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928
--- Comment #17 from Richard Biener ---
Created attachment 34975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34975&action=edit
do not compute live/conflict for abnormal coalesces
This is the other idea of simply not computing live/confl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65200
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928
--- Comment #18 from Richard Biener ---
(In reply to Richard Biener from comment #17)
> Created attachment 34975 [details]
> do not compute live/conflict for abnormal coalesces
>
> This is the other idea of simply not computing live/conflict for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155
--- Comment #6 from Richard Biener ---
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00364.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65200
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65248
H.J. Lu changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #4 from H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63158
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
Richard Biener changed:
What|Removed |Added
Blocks||47344
--- Comment #56 from Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65331
Bug ID: 65331
Summary: C99 format macros doesn't accept bit fields for 64-bit
integer types
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64958
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65332
Bug ID: 65332
Summary: [5 Regression] error: expected template-name before
‘<’ token
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #13 from Richard Biener ---
GCC 5 needs 31s and a peak of 2GB at -O0:
integrated RA : 5.91 (19%) usr 0.69 (11%) sys 6.41 (17%) wall
1615872 kB (55%) ggc
LRA non-specific: 2.41 ( 8%) usr 0.31 ( 5%) sys
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65333
Bug ID: 65333
Summary: [5 Regression] error: incomplete type used in nested
name specifier
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65333
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65332
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883
Dominique d'Humieres changed:
What|Removed |Added
Summary|FAIL: |FAIL:
|17_intro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65331
--- Comment #1 from Dmitry Petrov ---
UPD: it appears that bug doesn't related to PRI* format specifiers:
-m64:
printf("%lu\n", value); // usigned long value:31 => error (ok)
printf("%lu\n", value); // usigned long value:33 => error (not ok IMHO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65334
Bug ID: 65334
Summary: [5 Regression] r221099 caused: FAIL:
gfortran.fortran-torture/execute/in-pack.f90
execution, -O2 -ftree-vectorize -msse2
Product: gcc
Versi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65334
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
--- Comment #30 from Jan Hubicka ---
OK, thanks! Any ideas on Comment 26/27 testcases?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65302
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65302
--- Comment #6 from Jan Hubicka ---
Author: hubicka
Date: Fri Mar 6 16:12:43 2015
New Revision: 221244
URL: https://gcc.gnu.org/viewcvs?rev=221244&root=gcc&view=rev
Log:
PR ipa/65302
* value-prof.c (gimple_ic): Pure dead eh edges when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65335
Bug ID: 65335
Summary: Potential optimization issue with
'tree-loop-vectorize'
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316
--- Comment #7 from Jan Hubicka ---
Hmm. memory space randomization, perhaps? I have this turned off, will give it
a try.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467
Segher Boessenkool changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883
--- Comment #34 from Iain Sandoe ---
(In reply to Dominique d'Humieres from comment #33)
> Changed the summary to x86_64-apple-darwin10 (this probably affects
> powerpc-apple-darwin9 also).
correct; there is one additional needed for ppc-darwin9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #36 from boger at us dot ibm.com ---
I'd like to take a step back and clarify what the functions in question,
runtime_callers, runtime.Caller, and runtime.Callers should be returning: the
pc values for the call instruction, or the pc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64883
--- Comment #35 from Jonathan Wakely ---
(In reply to Iain Sandoe from comment #34)
> .. will apply an incremental change for earlier darwin as "obvious" at the
> first available opportunity (unless anyone has an objection) … (about to
> re-sync
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159
Jonathan Wakely changed:
What|Removed |Added
Target|x86_64-apple-darwin*|x86_64-apple-darwin14.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159
--- Comment #4 from Dominique d'Humieres ---
> Other people are building OK on Darwin so you'll need to give more info.
I don't see that at r221188. What is needed to reproduce it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #37 from Ian Lance Taylor ---
The PC returned by runtime.Caller is the same as that returned by
runtime.Callers: the instruction following the call.
Otherwise, yes, I agree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207
Matthias Klose changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159
--- Comment #5 from Jonathan Wakely ---
Dunno, I just logged into a darwin14 box and tried to build. I'm trying again
with a clean build now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65270
Jan Hubicka changed:
What|Removed |Added
Summary|issues with merging memory |[5 regression] issues with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65336
Bug ID: 65336
Summary: name lookup finds operator in unnamed namespace
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316
--- Comment #8 from Jan Hubicka ---
I suppose I will need to split ODR hash into hash with types having names and
hash with types not having names defined and insert types with names into both.
The types_same_for_odr really does not play well wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63175
--- Comment #34 from Martin Sebor ---
Author: msebor
Date: Fri Mar 6 18:43:24 2015
New Revision: 221248
URL: https://gcc.gnu.org/viewcvs?rev=221248&root=gcc&view=rev
Log:
2015-03-05 Martin Sebor
* PR testsuite/63175
* gcc.dg/vect/co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170
Eric Gallager changed:
What|Removed |Added
CC||egall at gwmail dot gwu.edu
--- Comment
with-cloog --disable-isl-version-check --enable-libsanitizer
--with-build-config=bootstrap-lto
Thread model: posix
gcc version 4.10.0-pre20150305 20150306 (experimental) [trunk revision 221246]
(Gentoo 4.10.0_pre20150305)
Binutils are vanilla version 2.25.51.20150305 from git.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37041
--- Comment #7 from Eric Gallager ---
(In reply to Manuel López-Ibáñez from comment #6)
> (In reply to Eric Gallager from comment #5)
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> >
> > /* code that is C-only */
>
> This is not what exte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65334
--- Comment #2 from Jan Hubicka ---
We ICE at:
0x080486d9 <+409>: cmp%eax,%ebx
0x080486db <+411>: jge0x80486c8
=> 0x080486dd <+413>: movdqa 0x80cf41c,%xmm7
0x080486e5 <+421>: movl $0x5,0x10(%edi)
0x080486ec <+428>:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65336
--- Comment #1 from Jonathan Wakely ---
(In reply to Thibaut LUTZ from comment #0)
> This might be a duplicate of 51577.
Yes, I think so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65243
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #5 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65338
Bug ID: 65338
Summary: [5 Regression] Offloading from DSO is broken after
OpenACC merge to trunk
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65010
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65339
Bug ID: 65339
Summary: [5 Regression] C++ ICE with lambda and no capture list
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65339
Aldy Hernandez changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65135
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #38 from boger at us dot ibm.com ---
I've spent some time thinking about a fix for this and made a few other
observations...
I've noticed that when runtime_callers calls backtrace_full, it locks the
thread using runtime_xadd and then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #15 from Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467
--- Comment #15 from Jonathan Wakely ---
I suggest we just do this and get on with our lives:
index 8f71910..62d3740 100644
--- a/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc
+++ b/libstdc++-v3/testsuite/28_regex/traits/char/isctype.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159
--- Comment #6 from Jonathan Wakely ---
A clean non-bootstrap build completed OK. Running a clean bootstrap now.
David, are you seeing this for a completely clean build?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64999
--- Comment #39 from Ian Lance Taylor ---
Unfortunately backtrace_simple does not handle inlined calls correctly, so it
won't work for a couple of very important cases: doing a stack backtrace on
panic, and skipping the right number of frames whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64467
--- Comment #16 from Segher Boessenkool ---
It turns out I built with config/os/generic, since I do not configure
--with-newlib. It still is newlib though, and the dejagnu test knows
that. Impedance mismatch, kaboom. It also seems that isctype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52664
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65284
Aldy Hernandez changed:
What|Removed |Added
Attachment #34959|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65010
--- Comment #3 from Martin Sebor ---
Created attachment 34978
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34978&action=edit
.expand RTL dump for simplified test case from comment #1.
(In reply to Jeffrey A. Law from comment #2)
Sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65316
--- Comment #9 from Jan Hubicka ---
This is patch adding the separate hash tables and also bit of extra sanity
checking for merging
types with ODR info and types without.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65334
--- Comment #3 from Jan Hubicka ---
This is patch I am testing. It turns out that vectorizer does update of
alignment twice and both are wrong in aliases in different ways.
In increase_alignment it decides to bump up alignment of alias target t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65280
--- Comment #2 from Marek Polacek ---
Author: mpolacek
Date: Fri Mar 6 23:44:56 2015
New Revision: 221250
URL: https://gcc.gnu.org/viewcvs?rev=221250&root=gcc&view=rev
Log:
PR sanitizer/65280
* doc/invoke.texi: Update description of -fs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65280
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65330
--- Comment #3 from Jan Hubicka ---
> I was thinking of sth else first - make sure that points-to analysis processes
> initializers of readonly globals (when they bind to the current def). In
when ctor_for_folding returns non-NULL;
> your testca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65159
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |WAITING
CC|jwakely.gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65331
--- Comment #2 from joseph at codesourcery dot com ---
Indeed, for C bit-field width is considered part of the type, meaning no
promotion for those wider than int (and no way for va_arg to extract the
value of such a bit-field passed to a varia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563
--- Comment #14 from Jan Hubicka ---
Yeah, this is the old problem that after each inline we recompute the size of
the whole function inlined into. This means walking the whole inline tree and
sum size of all non-inlined call sites. If you get ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59156
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61207
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65340
Bug ID: 65340
Summary: [C++14]ICE in mark_used, at decl2.c:5040
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
91 matches
Mail list logo
