https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63457
Bug ID: 63457
Summary: valarray missing std iterator limit functions
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #14 from Teresa Johnson ---
On Fri, Oct 3, 2014 at 3:35 PM, Teresa Johnson wrote:
> Thanks to H.J. for the test case, I have reproduced the issue. It
> exposed two separate problems. Cc'ing Honza and Jeff for input on the
> profile c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63456
Bug ID: 63456
Summary: unordered_map incorrectly frees _M_single_bucket.
Patch Included
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63455
Bug ID: 63455
Summary: decltype of statement expression internal compiler
error: in cp_parser_abort_tentative_parse, at
cp/parser.c:25062
Product: gcc
Version: 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63454
Bug ID: 63454
Summary: [5 Regression] internal compiler error: canonical
types differ for identical types
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #12 from Ian Lance Taylor ---
Created attachment 33644
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33644&action=edit
possible patch
I'm not really happy with Dominik's patch because 1) it doesn't work when
configuring with -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #13 from Teresa Johnson ---
Thanks to H.J. for the test case, I have reproduced the issue. It
exposed two separate problems. Cc'ing Honza and Jeff for input on the
profile count and jump threading issues, respectively.
The first is t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
--- Comment #5 from Michael Veksler ---
Running the delta.c example with -fdump-tree-all-all-lineno produces
delta.c.125t.vrp2.
For some reason, stop_9 (which is the first stop_.* in the file) is initialized
with stop_9 = barD.1593 (), but it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23684
Andrew Pinski changed:
What|Removed |Added
CC||carrot at google dot com
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63447
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57248
--- Comment #9 from Daniel Krügler ---
(In reply to Sumant Tambe from comment #8)
> How does the recursive strmatch function work then?
It works, because the function implementation does not contain any expression
that would depend on being a co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57248
--- Comment #8 from Sumant Tambe ---
Bummer! My assumption/expectation (probably due to my ignorance) is that any
transformation/result obtained using a constexpr function should be usable
(perhaps recursively) in the caller constexpr function. H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #12 from Teresa Johnson ---
Feel free to email it to me at tejohn...@google.com.
Teresa
On Fri, Oct 3, 2014 at 1:23 PM, hjl.tools at gmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
>
> --- Comment #11 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63296
--- Comment #1 from Daniel Krügler ---
The problem also exists in 5.0.0 20141002 (experimental).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #11 from H.J. Lu ---
(In reply to Teresa Johnson from comment #10)
>
> This points to a bigger problem, since esucc->count should be <=
> bb->count. Can you attach the input files and command line and I will
> take a closer look?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54427
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #10 from Teresa Johnson ---
On Fri, Oct 3, 2014 at 12:47 PM, hjl.tools at gmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
>
> H.J. Lu changed:
>
>What|Removed |Added
> --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63453
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63453
--- Comment #2 from Marek Polacek ---
Author: mpolacek
Date: Fri Oct 3 20:14:48 2014
New Revision: 215874
URL: https://gcc.gnu.org/viewcvs?rev=215874&root=gcc&view=rev
Log:
PR c/63453
* c-decl.c (pop_scope): Don't warn about "inline fun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
Marc Glisse changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57198
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #9 from H.J. Lu ---
This works for me:
diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index d660fdb..c6f3956 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -874,7 +874,8 @@ recom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57198
--- Comment #1 from Marc Glisse ---
Author: glisse
Date: Fri Oct 3 19:57:01 2014
New Revision: 215872
URL: https://gcc.gnu.org/viewcvs?rev=215872&root=gcc&view=rev
Log:
2014-10-03 Marc Glisse
PR c++/54427
PR c++/57198
PR c++/588
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #23 from Marc Glisse ---
Author: glisse
Date: Fri Oct 3 19:57:01 2014
New Revision: 215872
URL: https://gcc.gnu.org/viewcvs?rev=215872&root=gcc&view=rev
Log:
2014-10-03 Marc Glisse
PR c++/54427
PR c++/57198
PR c++/58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54427
--- Comment #16 from Marc Glisse ---
Author: glisse
Date: Fri Oct 3 19:57:01 2014
New Revision: 215872
URL: https://gcc.gnu.org/viewcvs?rev=215872&root=gcc&view=rev
Log:
2014-10-03 Marc Glisse
PR c++/54427
PR c++/57198
PR c++/58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
--- Comment #16 from Mikael Morin ---
(In reply to Thomas Koenig from comment #15)
> Hi Mikael,
>
> do you think you can do this using the scalarizer?
>
Not in its current state.
And as I don't see the scalarizer being changed soon to allow it,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #7 from Teresa Johnson ---
On Fri, Oct 3, 2014 at 10:33 AM, hjl.tools at gmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
>
> --- Comment #6 from H.J. Lu ---
> (In reply to Teresa Johnson from comment #5)
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61403
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Fri Oct 3 18:16:09 2014
New Revision: 215866
URL: https://gcc.gnu.org/viewcvs?rev=215866&root=gcc&view=rev
Log:
PR tree-optimization/61403
* config/i386/i386.c (expand_vec_perm_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
--- Comment #28 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #27)
> Shouldn't it be guarded by if (ksvd.ignored_set_reg) too?
Yes, and the published patch implements just that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
--- Comment #27 from Jakub Jelinek ---
Shouldn't it be guarded by if (ksvd.ignored_set_reg) too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55250
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
--- Comment #26 from Uroš Bizjak ---
Additional patch at [1]
[1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00332.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #6 from H.J. Lu ---
(In reply to Teresa Johnson from comment #5)
>
> BTW, I am having a little trouble doing an LTO profiledbootstrap on my
> linux/x86_64 machine. Here's what I did:
>
> $ /usr/local/google/home/tejohnson/gcc_trunk_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #5 from Teresa Johnson ---
On Fri, Oct 3, 2014 at 10:21 AM, hjl.tools at gmail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
>
> --- Comment #4 from H.J. Lu ---
> r215830 introduced:
>
> /* Scale up the f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #4 from H.J. Lu ---
r215830 introduced:
/* Scale up the frequency by REG_BR_PROB_BASE, to avoid rounding
errors applying the edge probability when the frequencies are very
small. */
epath->src->count =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
--- Comment #25 from Uroš Bizjak ---
Patch in testing:
--cut here--
Index: regcprop.c
===
--- regcprop.c (revision 215852)
+++ regcprop.c (working copy)
@@ -1030,6 +1030,12 @@ cop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63453
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63453
Bug ID: 63453
Summary: Bogus warning for gnu_inline functions
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #3 from Teresa Johnson ---
Presumably the fix for PR63422 (r215822) fixed the initial problem,
but r215830 must have introduced this. Will take a look right now.
Teresa
On Fri, Oct 3, 2014 at 8:59 AM, hjl.tools at gmail dot com
wro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432
--- Comment #2 from H.J. Lu ---
r215830 doesn't solve the problem. Now I got
/export/project/git/gcc-regression/gcc/gcc/c/c-parser.c:3898:1: error:
verify_flow_info: Wrong probability of edge 238->241 -1819341072
c_parser_attributes (c_parser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #11 from Jason Merrill ---
Author: jason
Date: Fri Oct 3 15:52:03 2014
New Revision: 215860
URL: https://gcc.gnu.org/viewcvs?rev=215860&root=gcc&view=rev
Log:
PR c++/63362
* tree.c (strip_typedefs): Handle TREE_LIST.
Modifi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877
--- Comment #11 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri Oct 3 15:51:38 2014
New Revision: 215859
URL: https://gcc.gnu.org/viewcvs?rev=215859&root=gcc&view=rev
Log:
PR go/61877
refect: fix direct call of variadic method value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61877
Ian Lance Taylor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63452
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63449
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63449
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Fri Oct 3 15:01:36 2014
New Revision: 215855
URL: https://gcc.gnu.org/viewcvs?rev=215855&root=gcc&view=rev
Log:
PR libstdc++/63449
* doc/xml/manual/containers.xml: Remove outdat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #8 from Manuel López-Ibáñez ---
(In reply to Marc Glisse from comment #7)
> IIRC we don't, and the file contains a comment saying that it would be
> expensive. Actually, properly limiting the maximal depth of the walk (as is
> done in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63452
Bug ID: 63452
Summary: Cross class calling (pure virtual)
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445
--- Comment #2 from Manuel López-Ibáñez ---
Visiting statement:
j_14 = ASSERT_EXPR i_13>;
Intersecting
[i_13 + 1, +INF] EQUIVALENCES: { j_5(D) } (1 elements)
and
VARYING
to
[i_13 + 1, +INF] EQUIVALENCES: { j_5(D) } (1 elements)
Found new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Michael Veksler from comment #2)
>
> This make no sense at all and significantly lowers the usability of
> -Wstrict-overflow=3. Either VRP or constant-propagation must have realized
> that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49283
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63450
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63449
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Fri Oct 3 14:27:01 2014
New Revision: 215852
URL: https://gcc.gnu.org/viewcvs?rev=215852&root=gcc&view=rev
Log:
PR libstdc++/63449
* doc/xml/manual/containers.xml: Remove outdat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
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=57003
--- Comment #24 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #23)
> The difference is, that previously we emit memcpy call as:
Slip of the tongue, this should read:
... that now we emit memcpy call as:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58867
Maxim Ostapenko changed:
What|Removed |Added
CC||chefmax at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #7 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #6)
> What about [...]
That's roughly what I describe in comment #2, amended by comment #3.
> It could be a matter of following the chain of VUSE->VDEF,
> which I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63449
--- Comment #2 from Jonathan Wakely ---
Author: redi
Date: Fri Oct 3 13:36:57 2014
New Revision: 215849
URL: https://gcc.gnu.org/viewcvs?rev=215849&root=gcc&view=rev
Log:
PR libstdc++/63449
* doc/xml/manual/containers.xml: Remove outdat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409
--- Comment #5 from Uroš Bizjak ---
(In reply to Martin Liška from comment #4)
> Can you please verify for me that the following patch fixes the problem for
> your arch?
It works, but generates following warning:
WARNING: lto.exp does not suppo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298
--- Comment #12 from Jerry DeLisle ---
As a volunteer, I simply do not have the time. I am not trying to imply any
opinion pro or con regarding DTIO. The FORTRAN community as a whole needs to
decide what is needed and I invite anyone interested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63435
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409
--- Comment #4 from Martin Liška ---
Can you please verify for me that the following patch fixes the problem for
your arch?
Thanks,
Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409
--- Comment #3 from Martin Liška ---
Created attachment 33643
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33643&action=edit
Fix patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63217
--- Comment #1 from Daniel Krügler ---
The same problem exist in the current trunk (Tested for 5.0.0 20141002
(experimental))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888
Francois-Xavier Coudert changed:
What|Removed |Added
CC||fxcoudert at gcc dot gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63451
Bug ID: 63451
Summary: bad location for the condition in for-loops
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63449
Jonathan Wakely changed:
What|Removed |Added
Keywords||documentation
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Marc Glisse from comment #5)
> A clobber implies that the content is lost, so it is useless to store
> something there right before the clobber (I assume that's why the store is
> removed,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #5 from Marc Glisse ---
(In reply to Manuel López-Ibáñez from comment #4)
> At some moment (in dcce1), gcc decides that x = 4 is not needed. For the
> same reason, it could realize that MEM[(struct foo *)&D.2281] = &x must
> produce a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448
--- Comment #5 from Svante Signell ---
FYI: atlas builds fine with gcc-4.8.3-11 (and gfortran-4.9-15)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Marc Glisse from comment #2)
> make_foo:
>
> MEM[(struct foo *)&D.2281] = &x;
> x ={v} {CLOBBER};
> return D.2281;
>
> That doesn't seem so easy to warn about. We could walk from re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63450
--- Comment #1 from Luis Colorado ---
when i compile a completely empty function i get the rep ret in the same line.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63450
Bug ID: 63450
Summary: Optimizing -O3 generates rep ret on an almost empty
function
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: minor
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63449
Bug ID: 63449
Summary: documentation of vector space overhead management
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61200
--- Comment #4 from Jakub Jelinek ---
Fixed for 4.9+ so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61200
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Fri Oct 3 08:17:34 2014
New Revision: 215838
URL: https://gcc.gnu.org/viewcvs?rev=215838&root=gcc&view=rev
Log:
PR libgomp/61200
* omp-low.c (taskreg_contexts): New variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63186
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61200
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Fri Oct 3 07:29:42 2014
New Revision: 215835
URL: https://gcc.gnu.org/viewcvs?rev=215835&root=gcc&view=rev
Log:
PR libgomp/61200
* omp-low.c (taskreg_contexts): New variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62128
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Fri Oct 3 07:27:50 2014
New Revision: 215834
URL: https://gcc.gnu.org/viewcvs?rev=215834&root=gcc&view=rev
Log:
PR target/62128
* config/i386/i386.c (expand_vec_perm_palignr): If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #3 from Marc Glisse ---
(In reply to Marc Glisse from comment #2)
> make_foo:
>
> MEM[(struct foo *)&D.2281] = &x;
> x ={v} {CLOBBER};
> return D.2281;
>
> That doesn't seem so easy to warn about. We could walk from return to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63446
--- Comment #2 from Marc Glisse ---
make_foo:
MEM[(struct foo *)&D.2281] = &x;
x ={v} {CLOBBER};
return D.2281;
That doesn't seem so easy to warn about. We could walk from return to find some
of the latest non-clobbered dominating writes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63448
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
86 matches
Mail list logo
