Re: [RFC] Ignore TREE_CONSTANT_OVERFLOW in integer_zerop

[Falk Hueffner]

Roger Sayle <[EMAIL PROTECTED]> writes:

> [...] the patch below removes the TREE_CONSTANT_OVERFLOW checks from
> integer_zerop, integer_onep, and friends in tree.c.

Incidentally, this fixes PR 26729.

-- 
Falk

Re: GNU Pascal branch

[Steven Bosscher]

On 4/1/06, Ed Smith-Rowland <[EMAIL PROTECTED]> wrote:
> All,
>
> FWIW, I would like to add my support for creating a branch for gpc with
> the eventual goal
> of integrating Pascal into mainline.

While I agree with most of the the points you make, the issue is not
whether GCC should allow a gpc-branch to be created or not. I think
that question would be just be a formality, if it were clear that the
maintainers of GNU Pascal want integration with GCC.

The fact is, that the GNU Pascal crew did not want integration with
gcc the last time this was discussed. GCC, the project, can not just
suck in every front end out there if the maintainers of that front end
do not want that.

Gr.
Steven

Re: [RFC] Ignore TREE_CONSTANT_OVERFLOW in integer_zerop

[Eric Botcazou]

> 2006-04-01  Roger Sayle  <[EMAIL PROTECTED]>
>
>   * tree.c (integer_zerop): Ignore TREE_CONSTANT_OVERFLOW.
>   [...]
>   (int_size_in_bytes): Likewise.
>   (host_integerp): Likewise.

Is this an oversight?

*** int_size_in_bytes (tree type)
*** 1725,1731 
t = TYPE_SIZE_UNIT (type);
if (t == 0
|| TREE_CODE (t) != INTEGER_CST
-   || TREE_OVERFLOW (t)
|| TREE_INT_CST_HIGH (t) != 0
/* If the result would appear negative, it's too big to represent.  */
|| (HOST_WIDE_INT) TREE_INT_CST_LOW (t) < 0)
--- 1717,1722 
*** int
*** 4404,4410 
  host_integerp (tree t, int pos)
  {
return (TREE_CODE (t) == INTEGER_CST
- && ! TREE_OVERFLOW (t)
  && ((TREE_INT_CST_HIGH (t) == 0
   && (HOST_WIDE_INT) TREE_INT_CST_LOW (t) >= 0)
  || (! pos && TREE_INT_CST_HIGH (t) == -1
--- 4395,4400 

-- 
Eric Botcazou

Re: [RFC] Ignore TREE_CONSTANT_OVERFLOW in integer_zerop

[Roger Sayle]

On Sun, 2 Apr 2006, Eric Botcazou wrote:
> > 2006-04-01  Roger Sayle  <[EMAIL PROTECTED]>
> >
> > * tree.c (integer_zerop): Ignore TREE_CONSTANT_OVERFLOW.
> >   [...]
> > (int_size_in_bytes): Likewise.
> > (host_integerp): Likewise.
>
> Is this an oversight?

Doh.  Indeed.  The last two lines of the ChangeLog should read

(int_size_in_bytes): Ignore TREE_OVERFLOW.
(host_integerp): Likewise.

As one aspect of the series I've been investigating is to unify these
two flags, I tend to think of them a synonymous.  The only difference
in semantics is that the C/C++ front-ends uses both to track whether
a diagnostic has been emitted.  It turns out that this conceptual
difference can be handled entirely in the C family front-ends, and
at the same time improve the diagnostic warnings that are emitted.

Indeed, a many of the uses of TREE_OVERFLOW or TREE_CONSTANT_OVERFLOW
currently test the wrong one, but the vast majority of writes are
to clear these flags to prevent them screwing things up.


Good catch.  Thanks.

Roger
--

Re: [RFC] Ignore TREE_CONSTANT_OVERFLOW in integer_zerop

[Joseph S. Myers]

On Sat, 1 Apr 2006, Roger Sayle wrote:

> As a step in this direction, the patch below removes the
> TREE_CONSTANT_OVERFLOW checks from integer_zerop, integer_onep,

Has there been a patch to the C++ front end corresponding to my patch 
 to the C front 
end, or did you determine that one was not needed for the C++ front end to 
avoid counting overflowed 0 as a null pointer constant?

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: the loss of SET_TYPE

[Gerald Pfeifer]

On Mon, 27 Mar 2006, Steven Bosscher wrote:
> That would be up to the Steering Committee, I suppose.  Gerald?

Yes, as Mark noted in a related thread, this would be the case.

Note that it's not only about technical issues, copyright assignment,
and coding standards. Adding and especially carrying a frontend does
come at a cost for the mainline GCC developers, so we may have to
assess the benefits versus these costs.

Gerald

Re: GNU Pascal branch

[Adriaan van Os]

Steven Bosscher wrote:


Ed Smith-Rowland <[EMAIL PROTECTED]> wrote:

All,

FWIW, I would like to add my support for creating a branch for gpc 
with

the eventual goal
of integrating Pascal into mainline.


While I agree with most of the the points you make, the issue is not
whether GCC should allow a gpc-branch to be created or not. I think
that question would be just be a formality, if it were clear that the
maintainers of GNU Pascal want integration with GCC.

The fact is, that the GNU Pascal crew did not want integration with
gcc the last time this was discussed. GCC, the project, can not just
suck in every front end out there if the maintainers of that front end
do not want that.


Apparently, the GNU Pascal crew did not want integration with every 
buggy back-end that sucks out there.



Thanks for your great cooperation.


Perhaps you should go look for a mirror and say this again.


At least, I  don't need to look in the mirror to see someone barking.

Can we have a normal discussion please ? Try to become a mature human 
being.


Adriaan van Os

Re: GNU Pascal branch

[Paolo Bonzini]

The fact is, that the GNU Pascal crew did not want integration with
gcc the last time this was discussed. GCC, the project, can not just
suck in every front end out there if the maintainers of that front end
do not want that.


Apparently, the GNU Pascal crew did not want integration with every 
buggy back-end that sucks out there.


You left out a part of the sentence: even if it is subject to decision 
of the SC, it is ok for the GCC project to suck in more front ends, but 
it can't be done if their maintainers do not want that.


If a back-end (in the sense of machine description, which is how it is 
commonly used in the GCC context) is buggy, rest assured that it will be 
up to its maintainers to fix it.  If a back-end triggers a latent bug in 
GNU Pascal, on the other hand, you can only be happy of the additional 
testing to which gpc got exposed.  Can't you?


Paolo