> Ok, I'll take care of properly comitting the patch.
Thanks!
On Thu, May 15, 2008 at 8:15 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
>> The patch simply enabled type checking by default. As I don't see how
>> we can easily address the underlying problem can you try the following
>> which simply makes this typechecking weaker?
>
> That seems to work.
>
> FY
> The patch simply enabled type checking by default. As I don't see how
> we can easily address the underlying problem can you try the following
> which simply makes this typechecking weaker?
That seems to work.
FYI test results show 98% pass rate for C++ and 98.6% pass rate for C,
so I'm not s
On Thu, May 15, 2008 at 2:44 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> More digging has identified this patch as the cause of the ongoing
> C++-related m32c build failures:
>
> 2008-03-24 Richard Guenther <[EMAIL PROTECTED]>
>
> PR c/22371
> * gimplify.c (gimplify_modify_ex
More digging has identified this patch as the cause of the ongoing
C++-related m32c build failures:
2008-03-24 Richard Guenther <[EMAIL PROTECTED]>
PR c/22371
* gimplify.c (gimplify_modify_expr): For frontend type-correct
pointer assignments change conversions according
On Wed, Apr 9, 2008 at 10:40 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> I tracked it down to this:
>
>
> /* Allow conversions between integral types and pointers only if
>there is no sign or zero extension involved. */
> if (((POINTER_TYPE_P (type) && INTEGRAL_TYPE_
I tracked it down to this:
/* Allow conversions between integral types and pointers only if
there is no sign or zero extension involved. */
if (((POINTER_TYPE_P (type) && INTEGRAL_TYPE_P (TREE_TYPE (op)))
|| (POINTER_TYPE_P (TREE_TYPE (op)) && INTEGRAL_TY
Sigh, I cleaned out my local patches and now I'm tripping over this again:
if ((code == MINUS_EXPR || code == PLUS_EXPR || code == MULT_EXPR)
&& arg0 && arg1 && tt && POINTER_TYPE_P (tt))
gcc_assert (TREE_CODE (arg0) == INTEGER_CST && TREE_CODE (arg1) ==
INTEGER_CST);
I had locall
On Wed, Apr 9, 2008 at 4:05 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> FYI: my h8/300h builds are failing with the same message, but with
> different types. Haven't investigated yet.
>
>
> > What size is the internal 'sizetype'?
>
> 16 bits.
>
>
> > Is there an integer type with the same w
FYI: my h8/300h builds are failing with the same message, but with
different types. Haven't investigated yet.
> What size is the internal 'sizetype'?
16 bits.
> Is there an integer type with the same width as the pointer type?
No. The m32c doesn't have enough operators to have a pointer-size
On Wed, Apr 9, 2008 at 3:28 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> Continuation of the last one, different bug, building libstdc++ ...
> Look familiar to anyone? If not, I'll try to hunt down the cause.
> The culprit is this line:
>
> D.25530 = (unsigned int) D.25529;
>
> For m32cm,
Continuation of the last one, different bug, building libstdc++ ...
Look familiar to anyone? If not, I'll try to hunt down the cause.
The culprit is this line:
D.25530 = (unsigned int) D.25529;
For m32cm, "int" is 16 bits, "long" is 32 bits, and "void*" is 24
bits. A cast to unsigned int t
12 matches
Mail list logo
