[Bug tree-optimization/58984] [4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2013-11-04 00:00:00 | CC||jakub at gcc dot gnu.org, ||jamborm at gcc dot gnu.org Target Milestone|4.8.4 |4.8.3 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r193298.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-04 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1
[Bug tree-optimization/58984] [4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- So, before IPA-CP, foo had: _10 = BIT_FIELD_REF p, 32, 0; _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 507904; which is of course wrong, because 32 bits at offset 0 in the structure should contain value 16385 ((1 0) | (1 14)), rather than 1.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
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 = NULL;
and then we're calling gimple_code on that NULL stmt:
if (gimple_code (use_stmt) != GIMPLE_COND
[Bug tree-optimization/58984] [4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- 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.
[Bug c++/58979] [4.8/4.9 Regression] ICE with invalid use of pointer-to-member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- 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.
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #4)
Created attachment 31145 [details]
For a possible patch.
This patch is assuming that a statement like s-mode[-1].b = 0;
is basically invoking undefined behaviour, so it should not matter
if we have correct bitregion_start/end values or just set them to zero
in this case.
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; };
...
void function(struct S *p)
{
p[-1].s = 0;
}
Apparently get_inner_reference only gives negative bitpos if offset is
NULL_TREE, otherwise it adjusts offset such that the bitpos is positive.
I wonder if get_bit_range shouldn't do the same thing if it detects *bitpos
is negative and *offset is NULL_TREE before doing the bitoffset *bitpos
comparison. It might be as easy as replacing the
gcc_assert (*offset != NULL_TREE);
with if (*offset == NULL_TREE) *offset = size_int (0);
Of course, the comment would need to be adjusted.
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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; };
...
void function(struct S *p)
{
p[-1].s = 0;
}
no. I checked that. This is folded quite differently:
MEM[(struct S *)p_1(D) + -1B].s = 0;
and there is no ICE in this case.
Apparently get_inner_reference only gives negative bitpos if offset is
NULL_TREE, otherwise it adjusts offset such that the bitpos is positive.
I wonder if get_bit_range shouldn't do the same thing if it detects *bitpos
is negative and *offset is NULL_TREE before doing the bitoffset *bitpos
comparison. It might be as easy as replacing the
gcc_assert (*offset != NULL_TREE);
with if (*offset == NULL_TREE) *offset = size_int (0);
Of course, the comment would need to be adjusted.
That would work. But if all these negative bit-pos are due to
invalid code as I'd curently expect, we could also just stop generating
code for this type of access, to reduce code size.
What I'm kind of worried here, is that bitpos is signed int,
and bitregion_start/end is unsigned int, and later in the expmed.c
all that stuff is passed as unsigned int bitnum/bitsize.
Therefore, it would make sense to avoid all negative bitpos in
get_inner_reference, but probably only if there exist _valid_ code
with negative bitpos.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- 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_stmt), use2_p, use_stmt)) ; - if (gimple_code (use_stmt) != GIMPLE_COND - || gimple_bb (use_stmt) != cond_bb) + if (use_stmt +(gimple_code (use_stmt) != GIMPLE_COND + || gimple_bb (use_stmt) != cond_bb)) return false; } return true;
[Bug libstdc++/58982] [4.9 Regression] std::vectorstd::atomicint vai(10); does not compile anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug libstdc++/52015] std::to_string does not work under MinGW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015 --- Comment #33 from Jonathan Wakely redi at gcc dot gnu.org --- (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 as out of date Above you said that this was not possible to fix for mingw. It's not possible to fix in GCC without extraordinary effort for a single target, which is not going to happen. If a given target wants to support C++11 features then it needs to provide the necessary C99 features. This is not a GCC issue. If you really meant this would require changes in the mingw runtime, perhaps you should have said that. Then, even if you are not motivated to approach the MinGW developers to effect such changes, someone else (e.g. me) could have. Fine. How about some ACTUALLY DOES SOMETHING USEFUL instead of quibbling over the particular wording I used in a bugzilla comment?
[Bug c++/58979] [4.8/4.9 Regression] ICE with invalid use of pointer-to-member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Yeah, I'll do it.
[Bug c++/58983] ICE when inheriting templated constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58983 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Then let's close it.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase:
int
foo (int x)
{
switch (x)
{
case 0:
case 1:
case 9:
break;
default:
__builtin_unreachable ();
}
return x;
}
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org ---
(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 with say
struct S { unsigned char s : 1; };
...
void function(struct S *p)
{
p[-1].s = 0;
}
no. I checked that. This is folded quite differently:
MEM[(struct S *)p_1(D) + -1B].s = 0;
and there is no ICE in this case.
But this is really nothing the expansion code should rely on to detect if the
code is undefined behavior or not.
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31147 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31147action=edit gcc49-pr58970.patch Untested fix.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- On it.
[Bug c++/58845] [4.8/4.9 Regression] Operator || and broken for vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
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 that
v1 v2
should be emitted as GENERIC
(v1 != { 0, 0, ... }) (v2 != { 0, 0, ... })
where the ANDIF semantics don't make sense for vectors(?) and thus we
can directly emit GENERIC
(v1 != { 0, 0, ... }) (v2 != { 0, 0, ... })
from the frontend.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31148 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31148action=edit gcc49-pr58978.patch While your patch will work too, I think it is better to fix it differently, the problem is that single_imm_use modifies the use_stmt argument even if it returns false, which I didn't expect.
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #10 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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 != NULL_TREE);
*bitpos += adjust;
- *offset
-= size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
+ if (*offset == NULL_TREE)
+*offset = size_int (-adjust / BITS_PER_UNIT);
+ else
+*offset
+ = size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
*bitstart = 0;
}
[Bug c++/58845] [4.8/4.9 Regression] Operator || and broken for vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- If there are no side-effects in v1 or v2, why not, but if there are side-effects, IMHO it should act as ANDIF, not as BIT_AND_EXPR.
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
(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 ((adjust % BITS_PER_UNIT) == 0);
- gcc_assert (*offset != NULL_TREE);
*bitpos += adjust;
- *offset
- = size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
+ if (*offset == NULL_TREE)
+ *offset = size_int (-adjust / BITS_PER_UNIT);
+ else
+ *offset
+ = size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
*bitstart = 0;
}
Can you prove it isn't necessary? I mean, *bitpos could still be smaller than
bitoffset, even when not negative, say with some packed+aligned structures
containing bitfields or similar. NULL_TREE *offset is the same thing as zero
at that spot, just perhaps less efficient in that case, so I think if we can't
prove it will not be hit, it is easy to handle it.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Assignee|mpolacek at gcc dot gnu.org|jakub at gcc dot gnu.org --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Reassigning.
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #12 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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_INT adjust = bitoffset - *bitpos;
-
gcc_assert ((adjust % BITS_PER_UNIT) == 0);
- gcc_assert (*offset != NULL_TREE);
*bitpos += adjust;
- *offset
- = size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
+ if (*offset == NULL_TREE)
+ *offset = size_int (-adjust / BITS_PER_UNIT);
+ else
+ *offset
+ = size_binop (MINUS_EXPR, *offset, size_int (adjust / BITS_PER_UNIT));
*bitstart = 0;
}
Can you prove it isn't necessary? I mean, *bitpos could still be smaller
than bitoffset, even when not negative, say with some packed+aligned
structures containing bitfields or similar. NULL_TREE *offset is the same
thing as zero at that spot, just perhaps less efficient in that case, so I
think if we can't prove it will not be hit, it is easy to handle it.
hmm, my english...
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.
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org ---
(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.
Sure, if *bitpos was initially negative, then *offset won't be NULL there.
But what I mean, are you sure that non-negative *bitpos will never be smaller
than bitoffset if *offset is NULL? Of course not on this testcase...
[Bug c++/51671] g++ fails to allow a redundant typedef if the redundant typedef depends on a template parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51671
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
Another testcase:
template typename T, typename U
struct S
{
static void f()
{
typedef T q;
typedef U q;
}
};
[Bug c++/58845] [4.8/4.9 Regression] Operator || and broken for vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845 --- Comment #7 from rguenther at suse dot de 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 jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- If there are no side-effects in v1 or v2, why not, but if there are side-effects, IMHO it should act as ANDIF, not as BIT_AND_EXPR. Then I'd say leave the whole thing to gimplification. Richard.
[Bug tree-optimization/58946] [4.9 Regression] internal compiler error: in operator[], at vec.h:722
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58946 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Nov 4 10:29:42 2013 New Revision: 204348 URL: http://gcc.gnu.org/viewcvs?rev=204348root=gccview=rev Log: PR tree-optimization/58946 * tree-ssa-reassoc.c (maybe_optimize_range_tests): Update all bbs with bbinfo[idx].op != NULL before all blocks with bbinfo[idx].op == NULL. * gcc.c-torture/compile/pr58946.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr58946.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #14 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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 longer be NULL, and I'd leave the assertion untouched.
Sure, if *bitpos was initially negative, then *offset won't be NULL there.
But what I mean, are you sure that non-negative *bitpos will never be
smaller than bitoffset if *offset is NULL? Of course not on this testcase...
If *bitpos is initially negative, I can proove that *offset is initially NULL.
The second statement cannot be prooved,
because after *bitpos = ... *bitpos is between 0..7.
For instance
struct S
{
struct T
{
int a:8;
int b:1;
} mode[1];
};
Consider p-mode[-1].b = 0, I'd expect bitoffset=8, less than *bitpos=0.
Right?
[Bug middle-end/58981] movmem/setmem use mode wider than Pmode for size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58981 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00179.html
[Bug c++/58845] [4.8/4.9 Regression] Operator || and broken for vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #8 from Marc Glisse glisse at gcc dot gnu.org ---
(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 () will only evaluate
the right hand operand if the left hand operand compares unequal to 0. For
scalar built-in types only, or (||) will only evaluate the right hand operand
if the left hand operand compares equal to 0. For built-in vector types, both
operands are evaluated and the operators are applied component-wise. If one
operand is a scalar and the other is a vector, the scalar may be subject to the
usual arithmetic conversion to the element type used by the vector operand. The
scalar type is then widened to a vector that has the same number of components
as the vector operand. The operation is done component-wise resulting in the
same size vector.
The logical operator exclusive or (^^) is reserved.
The result is a scalar signed integer of type int if the source operands are
scalar and a vector signed integer type of the same size as the source operands
if the source operands are vector types. Vector source operands of type charn
and ucharn return a charn result; vector source operands of type shortn and
ushortn return a shortn result; vector source operands of type intn, uintn and
floatn return an intn result; vector source operands of type longn, ulongn and
doublen return a longn result.
For scalar types, the logical operators shall return 0 if the result of the
operation is false and 1 if the result is true. For vector types, the logical
operators shall return 0 if the result of the operation is false and -1 (i.e.
all bits set) if the result is true.
v1 v2
should be emitted as GENERIC
(v1 != { 0, 0, ... }) (v2 != { 0, 0, ... })
where the ANDIF semantics don't make sense for vectors(?) and thus we
can directly emit GENERIC
(v1 != { 0, 0, ... }) (v2 != { 0, 0, ... })
from the frontend.
IIRC that's what the patch did:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00783.html
(In reply to Jakub Jelinek from comment #6)
If there are no side-effects in v1 or v2, why not, but if there are
side-effects, IMHO it should act as ANDIF, not as BIT_AND_EXPR.
What does ANDIF mean in this case? Only evaluate v2 if v1 has at least one
non-zero element? That still doesn't match the scalar version. Only evaluate
parts of v2? That doesn't seem possible.
(In reply to rguent...@suse.de from comment #7)
Then I'd say leave the whole thing to gimplification.
And implement what semantics in gimplification?
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- (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 single_imm_use modifies the use_stmt argument even if it returns false, which I didn't expect. Yeah, that looks good to me.
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #15 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(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 the
if (*bitpos 0) {...},
*offset can no longer be NULL, and I'd leave the assertion untouched.
Sure, if *bitpos was initially negative, then *offset won't be NULL there.
But what I mean, are you sure that non-negative *bitpos will never be
smaller than bitoffset if *offset is NULL? Of course not on this
testcase...
If *bitpos is initially negative, I can proove that *offset is initially
NULL.
However we can be sure (to assert), that if offset is initially NULL,
and *bitpos is initially = 0, then
the bit offset of the bitfield representative must be = 0 too.
because otherwiese, the bitfield would start at offset 0 and end
at an offset 0. Which is not possible.
Therefore bitoffset = *bitpos if *bitpos is initially = 0 and *offset is
initially == NULL. QED?
[Bug tree-optimization/58946] [4.9 Regression] internal compiler error: in operator[], at vec.h:722
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58946 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c++/58845] [4.8/4.9 Regression] Operator || and broken for vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845
--- Comment #9 from rguenther at suse dot de 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 glisse at gcc dot gnu.org ---
(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 () will only evaluate
the right hand operand if the left hand operand compares unequal to 0. For
scalar built-in types only, or (||) will only evaluate the right hand operand
if the left hand operand compares equal to 0.
For built-in vector types, both
operands are evaluated and the operators are applied component-wise. If one
operand is a scalar and the other is a vector, the scalar may be subject to
the
usual arithmetic conversion to the element type used by the vector operand.
The
scalar type is then widened to a vector that has the same number of components
as the vector operand. The operation is done component-wise resulting in the
same size vector.
Thus no short-circuiting for vector or ||.
The logical operator exclusive or (^^) is reserved.
The result is a scalar signed integer of type int if the source operands are
scalar and a vector signed integer type of the same size as the source
operands
if the source operands are vector types. Vector source operands of type charn
and ucharn return a charn result; vector source operands of type shortn and
ushortn return a shortn result; vector source operands of type intn, uintn and
floatn return an intn result; vector source operands of type longn, ulongn and
doublen return a longn result.
For scalar types, the logical operators shall return 0 if the result of the
operation is false and 1 if the result is true. For vector types, the logical
operators shall return 0 if the result of the operation is false and -1 (i.e.
all bits set) if the result is true.
v1 v2
should be emitted as GENERIC
(v1 != { 0, 0, ... }) (v2 != { 0, 0, ... })
where the ANDIF semantics don't make sense for vectors(?) and thus we
can directly emit GENERIC
(v1 != { 0, 0, ... }) (v2 != { 0, 0, ... })
from the frontend.
IIRC that's what the patch did:
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00783.html
(In reply to Jakub Jelinek from comment #6)
If there are no side-effects in v1 or v2, why not, but if there are
side-effects, IMHO it should act as ANDIF, not as BIT_AND_EXPR.
What does ANDIF mean in this case? Only evaluate v2 if v1 has at least one
non-zero element? That still doesn't match the scalar version. Only evaluate
parts of v2? That doesn't seem possible.
Yeah, exactly. Still if there is a sequence point at or ||
(even if both arms are always executed) then the order of evaluating
side-effects is important. IIRC only AND/ORIF have an implicit
sequence point during gimplification.
(In reply to rguent...@suse.de from comment #7)
Then I'd say leave the whole thing to gimplification.
And implement what semantics in gimplification?
No short-circuiting but preserving the sequence point (if there is one)
[Bug c++/58845] [4.8/4.9 Regression] Operator || and broken for vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58845 --- Comment #10 from Marc Glisse glisse at gcc dot gnu.org --- (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 the mixed scalarvector if we wanted to (though we probably don't). No short-circuiting but preserving the sequence point (if there is one) Ah, I'd completely missed that we might want a sequence point there, thanks, it makes sense.
[Bug c++/58979] [4.8/4.9 Regression] ICE with invalid use of pointer-to-member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- I've posted a patch for this a while ago, but so far it hasn't showed up on gcc-patches.
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org ---
(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 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.
Sure, if *bitpos was initially negative, then *offset won't be NULL there.
But what I mean, are you sure that non-negative *bitpos will never be
smaller than bitoffset if *offset is NULL? Of course not on this
testcase...
If *bitpos is initially negative, I can proove that *offset is initially
NULL.
However we can be sure (to assert), that if offset is initially NULL,
and *bitpos is initially = 0, then
the bit offset of the bitfield representative must be = 0 too.
because otherwiese, the bitfield would start at offset 0 and end
at an offset 0. Which is not possible.
Why is it not possible?
struct __attribute__((packed, aligned (2))) T { int a : 31; int b : 1; };
void
foo (char *p)
{
((struct T *)(p - 2))-b = 1;
}
Here, *bitpos could be (at least in theory) 15, while bitoffset 31 and *offset
could still be NULL_TREE, because the bitpos fits in signed HWI.
Again, perhaps it is right now optimized into a MEM_REF and get_bit_range won't
see that, but can you rule that out just because of that?
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #17 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
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 possible...
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970 --- Comment #18 from Bernd Edlinger bernd.edlinger at hotmail dot de --- 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_range (unsigned HOST_WIDE_INT *b HOST_WIDE_INT adjust = bitoffset - *bitpos; gcc_assert ((adjust % BITS_PER_UNIT) == 0); - gcc_assert (*offset != NULL_TREE); + if (*offset == NULL_TREE) +*offset = size_zero_node; *bitpos += adjust; *offset
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970 --- Comment #19 from Jakub Jelinek jakub at gcc dot gnu.org --- (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:51:55.013931114 +0100 @@ -4582,7 +4582,8 @@ get_bit_range (unsigned HOST_WIDE_INT *b HOST_WIDE_INT adjust = bitoffset - *bitpos; gcc_assert ((adjust % BITS_PER_UNIT) == 0); - gcc_assert (*offset != NULL_TREE); + if (*offset == NULL_TREE) + *offset = size_zero_node; *bitpos += adjust; *offset But you then have undefined behavior if *bitpos is HOST_WIDE_INT_MIN. Or could for very small other *bitpos and not really small bitoffset, etc. And, while you save a few characters on the line, it means it is more expensive at runtime.
[Bug other/58944] [4.9 Regression] bogus -Wunused-macros warnings when compiling Libreoffice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58944 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Looks like a system_header check doesn't work anymore.
[Bug rtl-optimization/57518] [4.8 Regression] Redundant insn generated in LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #8 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Why is the test-case gcc.dg/pr57518.c valid? It just checks that a REG_EQUIV is not attached, but from the analysis it seems the need is to check the related register against some condition; the note seems valid. Or maybe the test-case should be made machine-specific.
[Bug c/58943] [4.7/4.8/4.9 Regression] wrong calculation of indirect structure member arithmetic via function call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58943 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-04 Known to work||3.3.6 Target Milestone|--- |4.7.4 Summary|wrong calculation of|[4.7/4.8/4.9 Regression] |indirect structure member |wrong calculation of |arithmetic via function |indirect structure member |call|arithmetic via function ||call Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug regression/58985] New: [4.7 Regression]: gcc.dg/pr57518.c scan-rtl-dump-not ira REG_EQUIV...
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 Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: vmakarov at gcc dot gnu.org, wmi at google dot com Host: x86_64-unknown-linux-gnu Target: cris-axis-elf This test previously passed, now it fails. Revision r204212 (removing the regmove pass) caused this test to fail for cris-elf. This PR tracks this regression. The situation was problematic because at the time, the tree was broken due to revision r204205, reverted in r204254. In this revision range the regression was tracked with the vital part of r204254 applied; the test still fails at r204346. In gcc.log: PASS: gcc.dg/pr57518.c (test for excess errors) PASS: gcc.dg/pr57518.c scan-rtl-dump-not ira REG_EQUIV[^\n]*mem[^\n]*ip I have some doubts that the test-case is actually valid as-is for all ports, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518#c8. Author of revision 204212 and author of PR57518 CC:ed.
[Bug c/58942] cilkplus internal compiler error: tree check __sec_reduce_max_ind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58942 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-04 CC||bviyer at gmail dot com Version|unknown |4.9.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687 --- Comment #15 from Max TenEyck Woodbury mtewoodbury at gmail dot com --- Could you all give me some idea on how soon this might be applied?
[Bug regression/58985] [4.7 Regression]: gcc.dg/pr57518.c scan-rtl-dump-not ira REG_EQUIV...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Created attachment 31149 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31149action=edit pr57518.c.211r.ira IRA dump at r204211 (plus reverted breakage patch) as scanned by the test.
[Bug middle-end/58941] [4.7/4.8/4.9 Regression] MIPS: value modification on zero-length array optimized away
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58941 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Known to work||4.3.4 Keywords||alias, wrong-code Last reconfirmed||2013-11-04 Component|c |middle-end Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|MIPS: value modification on |[4.7/4.8/4.9 Regression] |zero-length array optimized |MIPS: value modification on |away|zero-length array optimized ||away Target Milestone|--- |4.7.4 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed, mine.
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug rtl-optimization/58934] [4.9 Regression]: build fails on cris-elf in reload_cse_simplify_operands for newlib dtoa.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58934 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug regression/58985] [4.7 Regression]: gcc.dg/pr57518.c scan-rtl-dump-not ira REG_EQUIV...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Created attachment 31150 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31150action=edit pr57518.c.210r.ira IRA dump of r204212 (plus reverted breakage patch) as scanned by the test; this is the one that fails apparently because it has (expr_list:REG_EQUIV (mem/j/c:QI (const:SI (plus:SI (symbol_ref:SI (ip) var_decl 0x7f37b3e5f390 ip) (const_int 2 [0x2]))) [0 ip+2 S1 A8])
[Bug bootstrap/58933] IRA ICE in update_costs_from_allocno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58933 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/58915] [missed optimization] GCC fails to get the loop bound for some loops.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58915 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- 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 || predicates in a vector and simplify / normalize them and solve queries against them, like in this case whether we can derive range information from them.
[Bug regression/58985] [4.7 Regression]: gcc.dg/pr57518.c scan-rtl-dump-not ira REG_EQUIV...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58985 --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Created attachment 31151 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31151action=edit pr57518.s Generated assembly. The contents at r204211 is identical to that at r204212.
[Bug c++/58986] New: [C++11] Narrowing for initializer lists must be an error
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
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.br...@virtuell-zuhause.de
Compiling
#
struct B {
B(int, double) {}
};
void g(B) {};
int main(int argc, char** argv)
{
g( {'a', 'b'} ); // OK: g(B(int,double)) user-defined conversion
g( {1.0, 1.0} ); // error: narrowing
}
#
with LANG=C g++ -std=c++11 gcc-bug-narrowing.cpp
with g++ 4.8.2 compiles fine with the warning:
#
gcc-bug-narrowing.cpp: In function 'int main(int, char**)':
gcc-bug-narrowing.cpp:9:17: warning: narrowing conversion of '1.0e+0' from
'double' to 'int' inside { } [-Wnarrowing]
g( {1.0, 1.0} ); // error: narrowing
#
Although C++11 standard §13.3.3.1.5 3 states that narrowing for initializer
lists is an error.
[Bug libstdc++/58982] [4.9 Regression] std::vectorstd::atomicint vai(10); does not compile anymore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58982 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c++/58966] [4.9 Regression] [c++11] ICE with wrong usage of constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58966 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Target Milestone|--- |4.9.0
[Bug rtl-optimization/58960] [4.9 regression] ICE in bmp_iter_set_init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58960 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/58964] [4.9 Regression] Bogus message: error: -mpreferred-stack-boundary=0 is not between 2 and 12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58964 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #20 from Richard Biener rguenth at gcc dot gnu.org --- Eric declared negative bitpos to be a nono that the expander is not handling well. Thus, Eric, please chime in here.
[Bug tree-optimization/58958] [4.9 Regression] Wrong aliasing info for variable index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58958 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-04 Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug rtl-optimization/57518] [4.8 Regression] Redundant insn generated in LRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57518 --- Comment #9 from Hans-Peter Nilsson hp at gcc dot gnu.org --- See also PR58985.
[Bug tree-optimization/58956] [4.7/4.8/4.9 Regression] wrong code at -O1 and above (affecting gcc 4.6 to trunk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58956 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.7.4
[Bug tree-optimization/58955] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58955 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug bootstrap/58951] [4.9 regression] cilk build fails due to use of -ldl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58951 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Target Milestone|--- |4.9.0
[Bug tree-optimization/58984] [4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- 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 = 1 store as bitfield access. If in the testcase int f0:8 is replaced with char f0, then it is miscompiled even at -O2, and then of course o.f0 = 1 is not a bitfield, but still, it overlaps with the bit field representative of the other bitfields. So, either the replacement code really needs to be taught about bitfields anyway (at least look not just at offset, but also size of the known value and not optimize into a constant if the access is to some bits beyond the known value extent), or the punting in determine_known_aggregate_parts would need to be much more conservative.
[Bug tree-optimization/58957] [4.8 Regression] compilation slow at -O3 on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58957 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog Known to work||4.7.3, 4.9.0 Summary|[4.8 Regression]|[4.8 Regression] |compilation hangs at -O3 on |compilation slow at -O3 on |x86_64-linux-gnu (both |x86_64-linux-gnu (both |32-bit and 64-bit modes)|32-bit and 64-bit modes) Known to fail||4.8.0, 4.8.2 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I think it's just awfully slow (deep loop nest, possible to unroll completely). It terminates for me on the branch and for 4.8.2 and 4.8.1. tree CFG cleanup: 8.49 (88%) usr 0.00 ( 0%) sys 8.52 (87%) wall 783 kB ( 2%) ggc TOTAL : 9.70 0.06 9.80 51528 kB on trunk and 4.7.3: TOTAL : 0.09 0.00 0.10 1865 kB
[Bug c++/58986] [C++11] Narrowing for initializer lists must be an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58986 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 55783 ***
[Bug c++/55783] Warnings instead of compiler errors for narrowing conversions within list-initializations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55783 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||thomas.braun@virtuell-zuhau ||se.de --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 58986 has been marked as a duplicate of this bug. ***
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Closing then.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
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 *obj, MDefinition *index, ^ 0xb15d0f crash_signal ../../gcc/gcc/toplev.c:334 0xd2a30f single_imm_use ../../gcc/gcc/ssa-iterators.h:426 0xd2a30f all_imm_uses_in_stmt_or_feed_cond ../../gcc/gcc/tree-vrp.c:6480 0xd2a30f remove_range_assertions ../../gcc/gcc/tree-vrp.c:6622 0xd2a30f execute_vrp ../../gcc/gcc/tree-vrp.c:9759 0xd2a30f execute ../../gcc/gcc/tree-vrp.c:9842 Please submit a full bug report I'm currently reducing this testcase.
[Bug tree-optimization/58984] [4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31152 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31152action=edit gcc49-pr58984.patch Untested fix. As the access size isn't preserved, I'm checking TYPE_SIZE (TREE_TYPE (v-value)), I believe it should be the same, otherwise we'd have an invalid store in the caller. I'll try to bootstrap/regtest an instrumented version of this to log in the cases where this punted.
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58978 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #31148|0 |1 is obsolete|| --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31153 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31153action=edit gcc49-pr58978.patch Supposedly this updated patch would fix even that?
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
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=gnu++0x -O2 test.ii /home/markus/mozilla-central/js/src/jit/IonBuilder.cpp: In member function ‘bool js::jit::IonBuilder::jsop_getelem_typed(js::jit::MDefinition*, js::jit::MDefinition*, js::Sca larTypeRepresentation::Type)’: /home/markus/mozilla-central/js/src/jit/IonBuilder.cpp:6937:1: internal compiler error: tree check: expected ssa_name, have component_ref in single_imm_use, at ssa-iterators. h:419 IonBuilder::jsop_getelem_typed(MDefinition *obj, MDefinition *index, ^ 0xd21764 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9421 0xd1fc95 tree_check ../../gcc/gcc/tree.h:2902 0xd1fc95 single_imm_use ../../gcc/gcc/ssa-iterators.h:419 0xd1fc95 all_imm_uses_in_stmt_or_feed_cond ../../gcc/gcc/tree-vrp.c:6480 0xd1fc95 remove_range_assertions ../../gcc/gcc/tree-vrp.c:6622 0xd1fc95 execute_vrp ../../gcc/gcc/tree-vrp.c:9759 0xd1fc95 execute ../../gcc/gcc/tree-vrp.c:9842 Please submit a full bug report,
[Bug tree-optimization/58978] [4.9 Regression] ICE: Segmentation fault
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.
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 --- Comment #9 from Rafał Rawicki rafal at rawicki dot org --- 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 (XScale, that is ARMv5), shouldn't have that defined. I'm still checking why I had _GLIBCXX_ATOMIC_BUILTINS_4 on gcc 4.6. I would like to have the same codebase on all platforms and I wouldn't like to stop using std::exception_ptr. Jonathan Wakely wrote, that without hardware support I need libatomic.so or I'd have an undefined behaviour. 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? Why it was decided to remove a part of standard library instead of enforcing user to link with libatomic.so?
[Bug bootstrap/58951] [4.9 regression] cilk build fails due to use of -ldl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58951 Balaji V. Iyer bviyer at gmail dot com changed: What|Removed |Added CC||bviyer at gmail dot com --- Comment #1 from Balaji V. Iyer bviyer at gmail dot com --- I am on it. I will let you know as soon as get a fix. Thanks, Balaji V. Iyer.
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org ---
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
+ ? 3 : exact_log2 (BITS_PER_UNIT)));
+ *bitpos = BITS_PER_UNIT - 1;
+}
hunk with s/\*//g could be moved to the get_bit_range caller, right above the
call. But, do we have testcases that fail now?
[Bug c++/58979] [4.8/4.9 Regression] ICE with invalid use of pointer-to-member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Mon Nov 4 16:01:49 2013 New Revision: 204352 URL: http://gcc.gnu.org/viewcvs?rev=204352root=gccview=rev Log: PR c++/58979 c-family/ * c-common.c (invalid_indirection_error): Handle RO_ARROW_STAR case. testsuite/ * g++.dg/diagnostic/pr58979.C: New test. Added: trunk/gcc/testsuite/g++.dg/diagnostic/pr58979.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/58968] Powerpc -mlra cannot compile ormas1.f in gamess Spec 2006 with -m32 -mcpu=power7 -O3 -mlra -w -ffast-math -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58968 --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Mon Nov 4 16:12:29 2013 New Revision: 204353 URL: http://gcc.gnu.org/viewcvs?rev=204353root=gccview=rev Log: 2013-11-04 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/58968 * lra-spills.c (return_regno_p): New function. (lra_final_code_change): Use it. 2013-11-04 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/58968 * gfortran.dg/pr58968.f: New Added: trunk/gcc/testsuite/gfortran.dg/pr58968.f Modified: trunk/gcc/ChangeLog trunk/gcc/lra-spills.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/58968] Powerpc -mlra cannot compile ormas1.f in gamess Spec 2006 with -m32 -mcpu=power7 -O3 -mlra -w -ffast-math -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58968 Vladimir Makarov vmakarov at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #4 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Steven Bosscher from comment #2) Created attachment 31143 [details] Somewhat reduced test case Thanks for the test reducing.
[Bug c++/58979] [4.8/4.9 Regression] ICE with invalid use of pointer-to-member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Mon Nov 4 16:21:34 2013 New Revision: 204354 URL: http://gcc.gnu.org/viewcvs?rev=204354root=gccview=rev Log: PR c++/58979 c-family/ * c-common.c (invalid_indirection_error): Handle RO_ARROW_STAR case. testsuite/ * g++.dg/diagnostic/pr58979.C: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/diagnostic/pr58979.C Modified: branches/gcc-4_8-branch/gcc/c-family/ChangeLog branches/gcc-4_8-branch/gcc/c-family/c-common.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/58979] [4.8/4.9 Regression] ICE with invalid use of pointer-to-member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58979 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug libstdc++/58938] [4.7/4.8/4.9 Regression] std::exception_ptr is missing on architectures with incomplete atomic int support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org --- (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 could try it. I don't know if it will work correctly. Why it was decided to remove a part of standard library instead of enforcing user to link with libatomic.so? That's the usual policy for the library, we don't define components that rely on features that are missing from target platforms.
[Bug tree-optimization/58984] [4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984 --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org --- As far as I'm concerned, the patch is fine. Thanks for taking care of it.
[Bug tree-optimization/58984] [4.8/4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58984 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Well, there is if (*size_p) which should have been if (size_p) obviously, redoing bootstrap now with that fix.
[Bug middle-end/58970] [4.7/4.8/4.9 Regression] internal compiler error: in get_bit_range, at expr.c:4562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970 --- Comment #22 from Eric Botcazou ebotcazou at gcc dot gnu.org --- 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 bitfields use unsigned HOST_WIDE_INT so, yes, better avoid negative values unless you really know what you're doing...
[Bug c++/58983] ICE when inheriting templated constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58983 --- Comment #4 from William Throwe wtt6 at cornell dot edu --- Testing, I cannot reproduce either on a different machine, so probably something just went wrong with my install here. Sorry for the noise.
[Bug driver/55651] gcc hangs when -Wp, is passed on the command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55651 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Mon, 4 Nov 2013, mingjie.xing at gmail dot com wrote: 2013-11-04 Mingjie Xing mingjie.x...@gmail.com * common.opt (Wa, Wl, Wp,): Change JoinedOrMissing to Joined. That sounds wrong. Empty arguments are valid here and should be passed down as such. See the thread starting at http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00848.html where a change to the handling of empty arguments was rejected.
[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687 --- Comment #16 from joseph at codesourcery dot com 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 preprocessor reviewer will review the patch (after checking that the FSF copyright.list file reflects receipt of the assignment, if the patch seems big enough to need it).
[Bug regression/58985] [4.9 Regression]: gcc.dg/pr57518.c scan-rtl-dump-not ira REG_EQUIV...
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. Thanks for pointing out the problem. Regards, Wei Mi.
[Bug testsuite/58851] FAIL: gfortran.dg/unlimited_polymorphic_13.f90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org --- (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 r204286. Can you re-check that it fails and you have that version or newer?
[Bug ipa/58862] [4.9 Regression] LTO profiledbootstrap failure: lto1: ICE in edge_badness, at ipa-inline.c:1008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862 --- Comment #16 from Teresa Johnson tejohnson at google dot com --- Created attachment 31154 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31154action=edit blocksort.i
[Bug ipa/58862] [4.9 Regression] LTO profiledbootstrap failure: lto1: ICE in edge_badness, at ipa-inline.c:1008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862 --- Comment #17 from Teresa Johnson tejohnson at google dot com --- Created attachment 31155 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31155action=edit blocksort.gcda
[Bug ipa/58862] [4.9 Regression] LTO profiledbootstrap failure: lto1: ICE in edge_badness, at ipa-inline.c:1008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58862 --- Comment #18 from Teresa Johnson tejohnson at google dot com --- 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.c:1011 } ^ 0xe13caa edge_badness /usr/local/google/home/tejohnson/gcc_trunk_1/gcc/ipa-inline.c:1011 0xe16935 update_edge_key /usr/local/google/home/tejohnson/gcc_trunk_1/gcc/ipa-inline.c:1024 0xe16935 inline_small_functions /usr/local/google/home/tejohnson/gcc_trunk_1/gcc/ipa-inline.c:1610 0xe16935 ipa_inline /usr/local/google/home/tejohnson/gcc_trunk_1/gcc/ipa-inline.c:2015 0xe16935 execute /usr/local/google/home/tejohnson/gcc_trunk_1/gcc/ipa-inline.c:2385 Please submit a full bug report, Teresa
[Bug testsuite/58851] FAIL: gfortran.dg/unlimited_polymorphic_13.f90 -O0 execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851 --- Comment #10 from paul.richard.thomas at gmail dot com 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 gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58851 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org --- (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 r204286. Can you re-check that it fails and you have that version or newer? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug fortran/57445] [4.8/4.9 Regression][OOP] ICE in gfc_conv_class_to_class - for OPTIONAL polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57445 --- Comment #3 from Paul Thomas pault at gcc dot gnu.org --- Author: pault Date: Mon Nov 4 19:42:24 2013 New Revision: 204356 URL: http://gcc.gnu.org/viewcvs?rev=204356root=gccview=rev Log: 2013-11-04 Paul Thomas pa...@gcc.gnu.org PR fortran/57445 * trans-expr.c (gfc_conv_class_to_class): Remove spurious assert. 2013-11-04 Paul Thomas pa...@gcc.gnu.org PR fortran/57445 * gfortran.dg/optional_class_1.f90 : New test Added: trunk/gcc/testsuite/gfortran.dg/optional_class_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58987] New: [c++11] ICE with template alias
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++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org The following valid code snippet (compiled with -std=c++11) triggers an ICE since GCC 4.7.3: = templatetypename T using A = T*; templatetypename T, int = AT::X struct B; = bug.cc:3:28: internal compiler error: in cp_parser_type_name, at cp/parser.c:14658 templatetypename T, int = AT::X struct B; ^ 0x65fc8c cp_parser_type_name ../../gcc/gcc/cp/parser.c:14658 0x65027f cp_parser_qualifying_entity ../../gcc/gcc/cp/parser.c:5532 0x65027f cp_parser_nested_name_specifier_opt ../../gcc/gcc/cp/parser.c:5241 0x668459 cp_parser_simple_type_specifier ../../gcc/gcc/cp/parser.c:14517 0x64eddf cp_parser_postfix_expression ../../gcc/gcc/cp/parser.c:5805 0x65156d cp_parser_unary_expression ../../gcc/gcc/cp/parser.c:7097 0x6520df cp_parser_binary_expression ../../gcc/gcc/cp/parser.c:7801 0x6525af cp_parser_assignment_expression ../../gcc/gcc/cp/parser.c:8039 0x652a14 cp_parser_assignment_expression ../../gcc/gcc/cp/parser.c:8089 0x652a14 cp_parser_constant_expression ../../gcc/gcc/cp/parser.c:8299 0x6545cb cp_parser_default_argument ../../gcc/gcc/cp/parser.c:18442 0x660cf0 cp_parser_parameter_declaration ../../gcc/gcc/cp/parser.c:18368 0x66121b cp_parser_template_parameter ../../gcc/gcc/cp/parser.c:12886 0x66121b cp_parser_template_parameter_list ../../gcc/gcc/cp/parser.c:12789 0x6648a1 cp_parser_template_declaration_after_export ../../gcc/gcc/cp/parser.c:22605 0x6709b9 cp_parser_declaration ../../gcc/gcc/cp/parser.c:10849 0x66f548 cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:10771 0x670e86 cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4007 0x670e86 c_parse_file() ../../gcc/gcc/cp/parser.c:31057 0x7914e3 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1046 Please submit a full bug report, [etc.] In GCC 4.7.0 - 4.7.2 the code was wrongly rejected. (Template aliases were introduced in GCC 4.7.0).
[Bug c/58988] New: -Werror=missing-include-dirs does not work
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 Assignee: unassigned at gcc dot gnu.org Reporter: bugzi...@poradnik-webmastera.com I tried to pass -Werror=missing-include-dirs option to gcc in order to find all non-existing include dirs and found that this option in broken. In gcc 4.5.2 this option is ignored - gcc does not print any message when non-existing include dir is specified. gcc 4.7.3 prints warning only. gcc (both tested versions) changes this warnings into errors when both -Wmissing-include-dirs -Werror options are used, but this is not an option for be because of other warnings which are in my code. I tested this using following command: g++ -c test.cc -o test.o -I/a -Werror=missing-include-dirs
