https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69978
--- Comment #2 from Ibrahim Gokhan YANIKLAR ---
template < class T, class U, class... TL >
void goo( T, U, TL... )
{
std::cout << (B::value) << std::endl;
std::cout << (D::value) << std::endl;
std::cout << (C< B >::type::value << std:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69977
Jonathan Wakely changed:
What|Removed |Added
Keywords|accepts-invalid,|ice-on-valid-code
|i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
--- Comment #10 from Markus Trippelsdorf ---
markus@x4 tmp % cat foo.ii
namespace Glib {
class ObjectBase {
protected:
virtual ~ObjectBase();
};
class A : virtual public ObjectBase {};
class B : virtual public ObjectBase {};
}
namespace Gtk {
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69978
Jonathan Wakely changed:
What|Removed |Added
Severity|major |normal
--- Comment #1 from Jonathan Wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69978
Bug ID: 69978
Summary: Invalid sizeof... value for variadic template
arguments
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: major
Priorit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69796
--- Comment #5 from Jakub Jelinek ---
Created attachment 37805
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37805&action=edit
gcc6-pr69796-2.patch
Or don't change it at all. If the FE emits error, then we are in error
recovery and don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69796
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|bernds at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #2)
Gah; I had typos in some of these; fixing them inline below (I hope):
> With Damerau-Levenshtein, we'd have (I think):
>
> coorzd1 -> coordz1 (Damerau-Levenshte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69789
Tomek Mrugalski changed:
What|Removed |Added
CC||thomson at klub dot com.pl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968
--- Comment #2 from David Malcolm ---
(In reply to Richard Biener from comment #1)
> but the distance from coorzd1 to coordz1 should be 2 one deletion and one
> insertion. Why's that not found?
I think the distance given in the initial comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #27 from rguenther at suse dot de ---
[...]
>> Maybe we'll need the Solaris 9-only fix from PR libgomp/60107 on Solaris
>> 10+, too.
>
> Or do -mstackrealign by default li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #27 from rguenther at suse dot de ---
On Thu, 25 Feb 2016, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
>
> --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69974
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |6.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69974
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69970
--- Comment #3 from Lars Gullik Bjønnes ---
The warning might be right, but is very unhelpful.
Also with gcc 5 I get no warning (and seeming working code).
Note that this is reduced (and thus a bit strange) from a much
larger code base.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69977
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
--- Comment #12 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to Jakub Jelinek from comment #9)
> > Created attachment 37801 [details]
> > gcc6-pr69891.patch
> >
> > Full patch I'm going to bootstrap/regtest.
>
> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
--- Comment #11 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 37801 [details]
> gcc6-pr69891.patch
>
> Full patch I'm going to bootstrap/regtest.
+/* PR rtl-optimization/69891 */
+/* { dg-do run } */
+/*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69977
Jonathan Wakely changed:
What|Removed |Added
Severity|major |normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69946
--- Comment #2 from Jakub Jelinek ---
Created attachment 37803
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37803&action=edit
gcc6-pr69946.patch
What about this untested patch? Ideas for better name of the new helper
function? Seems th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
Eric Botcazou changed:
What|Removed |Added
Assignee|ebotcazou at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69977
Bug ID: 69977
Summary: internal compiler error: Segmentation fault when using
generic lambdas
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
Markus Trippelsdorf changed:
What|Removed |Added
CC||hubicka at ucw dot cz
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69834
--- Comment #9 from Dominique d'Humieres ---
> > > Created attachment 37791 [details]
> > > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37791&action=edit
> > > Better Patch
> >
> > With the patch applied to my working tree (many patches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
--- Comment #9 from Jakub Jelinek ---
Created attachment 37801
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37801&action=edit
gcc6-pr69891.patch
Full patch I'm going to bootstrap/regtest.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976
Bug ID: 69976
Summary: Zero the local stack on function exit; don't optimize
out memset before return
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
--- Comment #8 from Jakub Jelinek ---
I think the right fix is just:
--- gcc/dse.c.jj2016-01-19 13:32:12.0 +0100
+++ gcc/dse.c 2016-02-26 11:03:36.694206088 +0100
@@ -2556,6 +2556,8 @@ scan_insn (bb_info_t bb_info, rtx_insn *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69834
--- Comment #8 from Paul Thomas ---
(In reply to Dominique d'Humieres from comment #6)
> > Created attachment 37791 [details]
> > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37791&action=edit
> > Better Patch
>
> Withe patch applied to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
--- Comment #6 from Eric Botcazou ---
> But the memset could be also SIBLING_CALL_P.
> Wouldn't it be better to change the else if to if, and add
> if (const_call) return;
> plus return to the end of mems_found == 1 then block? Then it would fal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
--- Comment #5 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #3)
> The problematic store is based on argp so it isn't killed by the memset,
> since only those based on sp or fp are:
>
> **scanning insn=20
> mem: (symbol_ref:SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
--- Comment #4 from Eric Botcazou ---
> It's apparently a small loophole in the PR middle-end/31150 enhancement.
In fact this is sufficient:
Index: dse.c
===
--- dse.c (revis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69975
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69891
Eric Botcazou changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69961
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69967
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69970
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968
--- Comment #1 from Richard Biener ---
but the distance from coorzd1 to coordz1 should be 2 one deletion and one
insertion. Why's that not found?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69970
--- Comment #1 from Richard Biener ---
You are comparing this against null when invoking the constructor and the
compiler tells you the code is equivalent to
Bar ()
: foo_ (new (true))
{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54349
Alexander Peslyak changed:
What|Removed |Added
CC||solar-gcc at openwall dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69887
--- Comment #6 from Eric Botcazou ---
> But the original bug has been fixed by r204592, as mentioned by c#27 of
> pr59039. The ICE in this report should be a new issue.
No, PR c/59039 is open and not fixed, the patch is still pending.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
--- Comment #8 from Markus Trippelsdorf ---
(In reply to john.frankish from comment #7)
> err, OK - excuse my ignorance, but that does that imply?
It it the reason for your link failure.
Now the question is, if the compiler is right to make the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69887
--- Comment #5 from Eric Botcazou ---
> But we shouldn't ICE on this. It is fine to reject it with error.
See the discussion under PR c/59039. These builtins are undocumented and
people must know what they are doing if they use them, which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69887
--- Comment #4 from Qirun Zhang ---
(In reply to Eric Botcazou from comment #2)
> __builtin_longjmp cannot be used in the same function as __builtin_setjmp.
>
> *** This bug has been marked as a duplicate of bug 59039 ***
But the original bug h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
--- Comment #6 from Markus Trippelsdorf ---
markus@x4 tmp % g++ -flto -fPIC -DPIC -shared -nostdlib treeviewcolumn.i && nm
./a.out | grep _ZTVN3Gtk14TreeViewColumnE
b4d8 d _ZTVN3Gtk14TreeViewColumnE.lto_priv.2
markus@x4 tmp % g++ -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
--- Comment #7 from john.frankish at outlook dot com ---
err, OK - excuse my ignorance, but that does that imply?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69951
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69551
--- Comment #12 from Richard Biener ---
Author: rguenth
Date: Fri Feb 26 08:34:58 2016
New Revision: 233734
URL: https://gcc.gnu.org/viewcvs?rev=233734&root=gcc&view=rev
Log:
2016-02-26 Richard Biener
PR tree-optimization/69551
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Markus Tri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69887
--- Comment #3 from Jakub Jelinek ---
But we shouldn't ICE on this. It is fine to reject it with error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69887
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59039
Eric Botcazou changed:
What|Removed |Added
CC||helloqirun at gmail dot com
--- Comment
101 - 154 of 154 matches
Mail list logo
