http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed|2013-11-04 00:00:00 |
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984
--- Comment #3 from Jakub Jelinek ---
So, before IPA-CP, foo had:
_10 = BIT_FIELD_REF ;
_11 = _10 & 507904;
Now, IPA-CP does:
Modification phase of node foo.constprop.0/3
Aggregate replacements: 0[14]=1, 0[8]=0, 0[0]=1
_4 = 1;
_5 = _4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #2 from Marek Polacek ---
Here, single_imm_use can set the stmt to NULL:
/* If there aren't any uses whatsoever, we're done. */
if (ptr == ptr->next)
{
return_false:
*use_p = NULL_USE_OPERAND_P;
*stmt = NUL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984
--- Comment #4 from Jakub Jelinek ---
Note that likely since r199252 Aggregate replacements: 0[14]=1, 0[8]=0, 0[0]=1
is replaced with just 0[0]=1, still the effect is exactly the same.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979
--- Comment #2 from Marc Glisse ---
When I introduced RO_ARROW_STAR I didn't realize it could end up in
invalid_indirection_error, probably just needs an extra "case" there.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #7 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #6)
> That doesn't look safe, negative rbitpos is not necessarily undefined
> behavior.
> Can't you get the same with say
> struct S { unsigned char s : 1; };
>
> ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #3 from Marek Polacek ---
Thus, hopefully:
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -6479,8 +6479,9 @@ all_imm_uses_in_stmt_or_feed_cond (tree var, gimple stmt,
basic_blo
&& single_imm_use (gimple_assign_lhs (use_stm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015
--- Comment #33 from Jonathan Wakely ---
(In reply to Nathan Ridge from comment #32)
> No one, but they need to know about issues like this in order to do
> something about them.
It's been in the MinGW bug tracker for years, although now closed a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58983
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #4 from Jakub Jelinek ---
Reduced testcase:
int
foo (int x)
{
switch (x)
{
case 0:
case 1:
case 9:
break;
default:
__builtin_unreachable ();
}
return x;
}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #8 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #7)
> (In reply to Jakub Jelinek from comment #6)
> > That doesn't look safe, negative rbitpos is not necessarily undefined
> > behavior.
> > Can't you get the same wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #9 from Jakub Jelinek ---
Created attachment 31147
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31147&action=edit
gcc49-pr58970.patch
Untested fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #5 from Richard Biener ---
Well, what does OpenCL specify here? IIRC we've decided on -1 (all bits set)
as true for vectors and 0 as false. I'd prefer to allow trivial lowering
to | and & which IIRC are already supported. That means
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #6 from Jakub Jelinek ---
Created attachment 31148
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31148&action=edit
gcc49-pr58978.patch
While your patch will work too, I think it is better to fix it differently, the
problem is th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #10 from Bernd Edlinger ---
but this should'nt be neccessary then?
if (bitoffset > *bitpos)
{
HOST_WIDE_INT adjust = bitoffset - *bitpos;
-
gcc_assert ((adjust % BITS_PER_UNIT) == 0);
- gcc_assert (*offset !
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #11 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #10)
> but this should'nt be neccessary then?
>
>if (bitoffset > *bitpos)
> {
>HOST_WIDE_INT adjust = bitoffset - *bitpos;
> -
>gcc_assert ((
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
Marek Polacek changed:
What|Removed |Added
Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #12 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to Bernd Edlinger from comment #10)
> > but this should'nt be neccessary then?
> >
> >if (bitoffset > *bitpos)
> > {
> >HOST_WIDE_IN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #13 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #12)
> I meant the change here is not necessary, because after the
> if (*bitpos < 0) {...},
> *offset can no longer be NULL, and I'd leave the assertion untouched.
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51671
--- Comment #4 from Paolo Carlini ---
Another testcase:
template
struct S
{
static void f()
{
typedef T q;
typedef U q;
}
};
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #7 from rguenther at suse dot de ---
On Mon, 4 Nov 2013, jakub at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
>
> Jakub Jelinek changed:
>
>What|Removed |Added
> --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58946
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Mon Nov 4 10:29:42 2013
New Revision: 204348
URL: http://gcc.gnu.org/viewcvs?rev=204348&root=gcc&view=rev
Log:
PR tree-optimization/58946
* tree-ssa-reassoc.c (maybe_optimize_rang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #14 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #13)
> (In reply to Bernd Edlinger from comment #12)
> > I meant the change here is not necessary, because after the
> > if (*bitpos < 0) {...},
> > *offset can no lon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58981
--- Comment #7 from H.J. Lu ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00179.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #8 from Marc Glisse ---
(In reply to Richard Biener from comment #5)
> Well, what does OpenCL specify here?
"The logical operators and (&&), or (||) operate on all scalar and vector
built-in types. For scalar built-in types only, and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 31148 [details]
> gcc49-pr58978.patch
>
> While your patch will work too, I think it is better to fix it differently,
> the problem is that si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #15 from Bernd Edlinger ---
(In reply to Bernd Edlinger from comment #14)
> (In reply to Jakub Jelinek from comment #13)
> > (In reply to Bernd Edlinger from comment #12)
> > > I meant the change here is not necessary, because after th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58946
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #9 from rguenther at suse dot de ---
On Mon, 4 Nov 2013, glisse at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
>
> --- Comment #8 from Marc Glisse ---
> (In reply to Richard Biener from comment #5)
> >
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #10 from Marc Glisse ---
(In reply to rguent...@suse.de from comment #9)
> Thus no short-circuiting for vector && or ||.
Indeed. Though we already deviated from OpenCL for ?: and as mentioned in my
patch we could do short-circuit for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979
--- Comment #4 from Marek Polacek ---
I've posted a patch for this a while ago, but so far it hasn't showed up on
gcc-patches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #16 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #15)
> (In reply to Bernd Edlinger from comment #14)
> > (In reply to Jakub Jelinek from comment #13)
> > > (In reply to Bernd Edlinger from comment #12)
> > > > I mea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #17 from Bernd Edlinger ---
struct T {
unsigned char b : 8;
unsigned char s : 1;
};
struct S {
char x;
struct T t[1];
};
void function(int x, struct S *p)
{
if (x == -1)
p->t[x].s = 0;
}
another test case. so this is p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #18 from Bernd Edlinger ---
Well, how about this version?
Does'nt it look like a much smaller change?
--- expr.c.jj2013-10-31 14:57:05.0 +0100
+++ expr.c2013-11-04 12:51:55.013931114 +0100
@@ -4582,7 +4582,8 @@ get_bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #19 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #18)
> Well, how about this version?
> Does'nt it look like a much smaller change?
>
> --- expr.c.jj 2013-10-31 14:57:05.0 +0100
> +++ expr.c2013-11-04 12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58943
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
Bug ID: 58985
Summary: [4.7 Regression]: gcc.dg/pr57518.c scan-rtl-dump-not
ira REG_EQUIV...
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58942
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #15 from Max TenEyck Woodbury ---
Could you all give me some idea on how soon this might be applied?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
--- Comment #1 from Hans-Peter Nilsson ---
Created attachment 31149
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31149&action=edit
pr57518.c.211r.ira
IRA dump at r204211 (plus reverted breakage patch) as scanned by the test.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58941
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.7.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58934
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
--- Comment #2 from Hans-Peter Nilsson ---
Created attachment 31150
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31150&action=edit
pr57518.c.210r.ira
IRA dump of r204212 (plus reverted breakage patch) as scanned by the test; this
is the on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58933
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58915
--- Comment #3 from Richard Biener ---
True, it may still help in some cases though.
On my list of nice-things-to-have is still a generic predicate collecting
& simplification machinery similar to what we have with tree-affine.c.
That is collect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
--- Comment #3 from Hans-Peter Nilsson ---
Created attachment 31151
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31151&action=edit
pr57518.s
Generated assembly. The contents at r204211 is identical to that at r204212.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58986
Bug ID: 58986
Summary: [C++11] Narrowing for initializer lists must be an
error
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58966
Richard Biener changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58960
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58964
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58958
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518
--- Comment #9 from Hans-Peter Nilsson ---
See also PR58985.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58956
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58955
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58951
Richard Biener changed:
What|Removed |Added
Keywords||build
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984
--- Comment #5 from Jakub Jelinek ---
Ah, the reason why r199252 doesn't fix this is that esra changes o.f0 = 1;
into a MEM_REF, essentially *(char *)&o = 1, because the f0 has 8 bits.
So, determine_known_aggregate_parts doesn't consider the o.f0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58957
Richard Biener changed:
What|Removed |Added
Keywords||compile-time-hog
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58986
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55783
Paolo Carlini changed:
What|Removed |Added
CC||thomas.braun@virtuell-zuhau
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #9 from octoploid at yandex dot com ---
With your patch applied I get this new ICE:
/home/markus/mozilla-central/js/src/jit/IonBuilder.cpp:6937:1: internal
compiler error: Segmentation fault
IonBuilder::jsop_getelem_typed(MDefinition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
Jakub Jelinek changed:
What|Removed |Added
Attachment #31148|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #10 from octoploid at yandex dot com ---
(In reply to octoploid from comment #9)
> With your patch applied I get this new ICE:
>
I've posted the wrong backtrace. Here's the correct one:
/var/tmp/gcc_test/usr/local/bin/g++ -w -c -std=gn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #12 from octoploid at yandex dot com ---
(In reply to Jakub Jelinek from comment #11)
> Created attachment 31153 [details]
> gcc49-pr58978.patch
>
> Supposedly this updated patch would fix even that?
Yes. Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
--- Comment #9 from Rafał Rawicki ---
I'm sorry about my confusion of ATOMIC_INT_LOCK_FREE and
_GLIBCXX_ATOMIC_BUILTINS meaning.
In the meantime I've checked, when ATOMIC_INT_LOCK_FREE is defined as 2 and the
target platform I have problems with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58951
Balaji V. Iyer changed:
What|Removed |Added
CC||bviyer at gmail dot com
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #21 from Jakub Jelinek ---
If expansion has issues with that, then supposedly the
+ if (*bitpos < 0)
+{
+ gcc_assert (*offset == NULL_TREE);
+ *offset = size_int (*bitpos >> (BITS_PER_UNIT == 8
+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979
--- Comment #5 from Marek Polacek ---
Author: mpolacek
Date: Mon Nov 4 16:01:49 2013
New Revision: 204352
URL: http://gcc.gnu.org/viewcvs?rev=204352&root=gcc&view=rev
Log:
PR c++/58979
c-family/
* c-common.c (invalid_indirection_error):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58968
--- Comment #3 from Vladimir Makarov ---
Author: vmakarov
Date: Mon Nov 4 16:12:29 2013
New Revision: 204353
URL: http://gcc.gnu.org/viewcvs?rev=204353&root=gcc&view=rev
Log:
2013-11-04 Vladimir Makarov
PR rtl-optimization/58968
* lr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58968
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979
--- Comment #6 from Marek Polacek ---
Author: mpolacek
Date: Mon Nov 4 16:21:34 2013
New Revision: 204354
URL: http://gcc.gnu.org/viewcvs?rev=204354&root=gcc&view=rev
Log:
PR c++/58979
c-family/
* c-common.c (invalid_indirection_error):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938
--- Comment #10 from Jonathan Wakely ---
(In reply to Rafał Rawicki from comment #9)
> I do link with libatomic.so - does that mean, I can patch this conditional
> out (and similar conditional in the exception_ptr.h) and use exception_ptrs?
You c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984
--- Comment #7 from Martin Jambor ---
As far as I'm concerned, the patch is fine. Thanks for taking care of it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984
--- Comment #8 from Jakub Jelinek ---
Well, there is if (*size_p) which should have been if (size_p) obviously,
redoing bootstrap now with that fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #22 from Eric Botcazou ---
> Eric declared negative bitpos to be a nono that the expander is not handling
> well. Thus, Eric, please chime in here.
Well, that's a basic sanity requirement, all the routines in expmed.c dealing
with bi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58983
--- Comment #4 from William Throwe ---
Testing, I cannot reproduce either on a different machine, so probably
something just went wrong with my install here. Sorry for the noise.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55651
--- Comment #3 from joseph at codesourcery dot com ---
On Mon, 4 Nov 2013, mingjie.xing at gmail dot com wrote:
> 2013-11-04 Mingjie Xing
>
> * common.opt (Wa, Wl, Wp,): Change JoinedOrMissing to Joined.
That sounds wrong. Empty arg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687
--- Comment #16 from joseph at codesourcery dot com ---
On Mon, 4 Nov 2013, mtewoodbury at gmail dot com wrote:
> Could you all give me some idea on how soon this might be applied?
At some time after seeing this on gcc-patches, I or another prep
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985
--- Comment #4 from wmi at google dot com ---
This is the testcase problem. For cris-axis-elf target, gcc doesn't use subreg
of reg 31 for the above testcase, so it is ok to generate REG_EQUIV note for
reg 31.
I will send out a patch for it soon.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851
--- Comment #9 from Tobias Burnus ---
(In reply to Andreas Schwab from comment #8)
> Still broken.
> (gdb) ptype r3
> type = real(kind=8)
> (gdb) ptype r4
> type = real(kind=10)
With the same error? That shouldn't be the case since the commit r20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
--- Comment #16 from Teresa Johnson ---
Created attachment 31154
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31154&action=edit
blocksort.i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
--- Comment #17 from Teresa Johnson ---
Created attachment 31155
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31155&action=edit
blocksort.gcda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862
--- Comment #18 from Teresa Johnson ---
Just hit this same error with cpu2006 bzip2. The .i and .gcda are attached.
Reproduce with:
gcc -c -fprofile-use -O2 blocksort.i
blocksort.c:1136:1: internal compiler error: in edge_badness, at
ipa-inline.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851
--- Comment #10 from paul.richard.thomas at gmail dot com ---
Thanks Tobias,
I was completely perplexed by that - you beat me to the reply by 32 minutes :-)
Cheers
Paul
On 4 November 2013 19:39, burnus at gcc dot gnu.org
wrote:
> http://gcc.g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57445
--- Comment #3 from Paul Thomas ---
Author: pault
Date: Mon Nov 4 19:42:24 2013
New Revision: 204356
URL: http://gcc.gnu.org/viewcvs?rev=204356&root=gcc&view=rev
Log:
2013-11-04 Paul Thomas
PR fortran/57445
* trans-expr.c (gfc_conv_c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58987
Bug ID: 58987
Summary: [c++11] ICE with template alias
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58988
Bug ID: 58988
Summary: -Werror=missing-include-dirs does not work
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
1 - 100 of 128 matches
Mail list logo
