On 15/01/15 21:56, Joseph Myers wrote:
On Thu, 15 Jan 2015, Jiong Wang wrote:
+ if (bitsize + bitnum > unit && bitnum < unit)
+{
+ warning (OPT_Wextra, "write of "HOST_WIDE_INT_PRINT_UNSIGNED"bit data "
+ "outside the bound of destination object, data truncated into "
+
On Thu, 15 Jan 2015, Jiong Wang wrote:
> + if (bitsize + bitnum > unit && bitnum < unit)
> +{
> + warning (OPT_Wextra, "write of "HOST_WIDE_INT_PRINT_UNSIGNED"bit data "
> +"outside the bound of destination object, data truncated into "
> +HOST_WIDE_INT_PRINT_UNSI
On 01/15/15 09:27, Jiong Wang wrote:
On 15/01/15 03:51, Jeff Law wrote:
On 01/14/15 15:31, Jiong Wang wrote:
agree, and I think the truncation is needed otherwise there may have ICE
on some target.
and I found current gcc LOCATION info is very good !
have done an experimental hack on at "expa
On 15/01/15 03:51, Jeff Law wrote:
On 01/14/15 15:31, Jiong Wang wrote:
agree, and I think the truncation is needed otherwise there may have ICE
on some target.
and I found current gcc LOCATION info is very good !
have done an experimental hack on at "expand_assignment": 4931 where the
tree is
On 01/14/15 15:31, Jiong Wang wrote:
agree, and I think the truncation is needed otherwise there may have ICE
on some target.
and I found current gcc LOCATION info is very good !
have done an experimental hack on at "expand_assignment": 4931 where the
tree is expanded,
gcc could give quite usef
On 13/01/15 21:45, Jeff Law wrote:
On 01/09/15 06:39, Jiong Wang wrote:
the bug testcase is
===
typedef short U __attribute__((may_alias, aligned (1)));
struct S
{
_Complex float d __attribute__((aligned (8)));
};
void bar(struct S);
void f5 (int x)
{
struct S s;
(
On 01/13/15 15:42, Joseph Myers wrote:
On Tue, 13 Jan 2015, Jeff Law wrote:
In many ways having the compiler or assembler spitting out an error here is
preferable to silently compiling the code. That would also help explain why
As usual, an error is incorrect in such a case that only has und
On Tue, 13 Jan 2015, Jeff Law wrote:
> In many ways having the compiler or assembler spitting out an error here is
> preferable to silently compiling the code. That would also help explain why
As usual, an error is incorrect in such a case that only has undefined
behavior at runtime (but it may
On 01/09/15 06:39, Jiong Wang wrote:
the bug testcase is
===
typedef short U __attribute__((may_alias, aligned (1)));
struct S
{
_Complex float d __attribute__((aligned (8)));
};
void bar(struct S);
void f5 (int x)
{
struct S s;
((U *)((char *) &s.d + 1))[3] = x;
ba
2015-01-09 13:39 GMT+00:00 Jiong Wang :
>
> the following code in store_bit_field_using_insv haven't consider above
> MEM->REG situation,
> it always assume bitnum + bitsize is within unit which is wrong.
>if (BITS_BIG_ENDIAN != BYTES_BIG_ENDIAN)
> bitnum = unit - bitsize - bitnum;
>
> whil
On 09/01/15 05:46, Jeff Law wrote:
On 12/30/14 03:21, Jiong Wang wrote:
PR64011 is actually a general problem on all target support bit insertion
instructions.
we overflow check at the start of store_bit_field_1, but that only check
the
situation where the field lies completely outside the reg
On 12/30/14 03:21, Jiong Wang wrote:
PR64011 is actually a general problem on all target support bit insertion
instructions.
we overflow check at the start of store_bit_field_1, but that only check
the
situation where the field lies completely outside the register, while
there do
have situation
PR64011 is actually a general problem on all target support bit insertion
instructions.
we overflow check at the start of store_bit_field_1, but that only check the
situation where the field lies completely outside the register, while there do
have situation where the field lies partly in the reg
13 matches
Mail list logo
