Andrew Haley | 1 Jun 12:36 2008
Picon

Re: Question about building hash values from pointers

Ian Lance Taylor wrote:
> Andrew Haley <aph <at> redhat.com> writes:
> 
>> Richard Guenther wrote:
>>> On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <Kai.Tietz <at> onevision.com> wrote:
>>>> Hi,
>>>>
>>>> as I noticed, most hash value calculations are trying to use pointer
>>>> values for building the value and assume that a long/unsigned long scalar
>>>> is wide enough for a pointer. This is at least for w64 target not true. So
>>>> I want to know, if it would be good to introduce an gcc specific type for
>>>> those kind of casts, or to use ssize_t/size_t.?
>>> it's uintptr_t which should be used, if only as an intermediate cast -
>>> (unsigned long)(uintptr_t)ptr.
>> That's not possible because, IIRC, gcc must compile on C90 systems.
> 
> We can just test for it with autoconf and typedef it if we don't have
> it.  We can figure out what to typedef it to by comparing the sizeof
> void* to the sizeof the integer types--we already gather these sizes
> in the configure script anyhow, and use them in hwint.h.

Given that all this seems to be about is avoiding warning messages on
some extremely unlikely architectures on which gcc may not run, I have
to question the sens of such heavyweight measures.  Why not simply use
size_t?  It would be adequate on every architecture anyone here knows
about.

Andrew.

(Continue reading)

Andreas Meier | 1 Jun 23:15 2008
Picon
Picon

Re: GCC 4.3.1 second Release Candidate available from gcc.gnu.org

Richard Guenther schrieb:
> A second release candidate for GCC 4.3.1 is available from
> 
>   ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.1-RC-20080529
> 
> and shortly its mirrors.  It has been generated from SVN revision 136151.
> 
> The branch is still frozen and all checkins until after the final release
> of GCC 4.3.1 require explicit RM approval.
> 
> If all goes well this candidate will become the final 4.3.1 release
> early next week.
> 
> Thanks,
> Richard.
> 
Hello,
bug 36407 is a regression against 4.3.0, see 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36407

Regards

Andreas

Richard Guenther | 1 Jun 23:17 2008
Picon

Re: GCC 4.3.1 second Release Candidate available from gcc.gnu.org

On Sun, 1 Jun 2008, Andreas Meier wrote:

> Richard Guenther schrieb:
> > A second release candidate for GCC 4.3.1 is available from
> > 
> >   ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.1-RC-20080529
> > 
> > and shortly its mirrors.  It has been generated from SVN revision 136151.
> > 
> > The branch is still frozen and all checkins until after the final release
> > of GCC 4.3.1 require explicit RM approval.
> > 
> > If all goes well this candidate will become the final 4.3.1 release
> > early next week.
> > 
> > Thanks,
> > Richard.
> > 
> Hello,
> bug 36407 is a regression against 4.3.0, see
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36407

It's an ICE for invalid code after issuing errors.  We'll fix that for
4.3.2.

Richard.

Ian Lance Taylor | 2 Jun 05:59 2008
Picon

Re: Question about building hash values from pointers

Andrew Haley <aph <at> redhat.com> writes:

> Ian Lance Taylor wrote:
>> Andrew Haley <aph <at> redhat.com> writes:
>> 
>>> Richard Guenther wrote:
>>>> On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <Kai.Tietz <at> onevision.com> wrote:
>>>>> Hi,
>>>>>
>>>>> as I noticed, most hash value calculations are trying to use pointer
>>>>> values for building the value and assume that a long/unsigned long scalar
>>>>> is wide enough for a pointer. This is at least for w64 target not true. So
>>>>> I want to know, if it would be good to introduce an gcc specific type for
>>>>> those kind of casts, or to use ssize_t/size_t.?
>>>> it's uintptr_t which should be used, if only as an intermediate cast -
>>>> (unsigned long)(uintptr_t)ptr.
>>> That's not possible because, IIRC, gcc must compile on C90 systems.
>> 
>> We can just test for it with autoconf and typedef it if we don't have
>> it.  We can figure out what to typedef it to by comparing the sizeof
>> void* to the sizeof the integer types--we already gather these sizes
>> in the configure script anyhow, and use them in hwint.h.
>
> Given that all this seems to be about is avoiding warning messages on
> some extremely unlikely architectures on which gcc may not run, I have
> to question the sens of such heavyweight measures.  Why not simply use
> size_t?  It would be adequate on every architecture anyone here knows
> about.

I don't personally find these measures to be heavyweight.  I find them
(Continue reading)

Richard Guenther | 2 Jun 10:28 2008
Picon

Re: Question about building hash values from pointers

On Mon, Jun 2, 2008 at 5:59 AM, Ian Lance Taylor <iant <at> google.com> wrote:
> Andrew Haley <aph <at> redhat.com> writes:
>
>> Ian Lance Taylor wrote:
>>> Andrew Haley <aph <at> redhat.com> writes:
>>>
>>>> Richard Guenther wrote:
>>>>> On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <Kai.Tietz <at> onevision.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> as I noticed, most hash value calculations are trying to use pointer
>>>>>> values for building the value and assume that a long/unsigned long scalar
>>>>>> is wide enough for a pointer. This is at least for w64 target not true. So
>>>>>> I want to know, if it would be good to introduce an gcc specific type for
>>>>>> those kind of casts, or to use ssize_t/size_t.?
>>>>> it's uintptr_t which should be used, if only as an intermediate cast -
>>>>> (unsigned long)(uintptr_t)ptr.
>>>> That's not possible because, IIRC, gcc must compile on C90 systems.
>>>
>>> We can just test for it with autoconf and typedef it if we don't have
>>> it.  We can figure out what to typedef it to by comparing the sizeof
>>> void* to the sizeof the integer types--we already gather these sizes
>>> in the configure script anyhow, and use them in hwint.h.
>>
>> Given that all this seems to be about is avoiding warning messages on
>> some extremely unlikely architectures on which gcc may not run, I have
>> to question the sens of such heavyweight measures.  Why not simply use
>> size_t?  It would be adequate on every architecture anyone here knows
>> about.
>
(Continue reading)

Kai Tietz | 2 Jun 10:35 2008

Re: Question about building hash values from pointers

"Richard Guenther" <richard.guenther <at> gmail.com> wrote on 02.06.2008 
10:28:12:

> On Mon, Jun 2, 2008 at 5:59 AM, Ian Lance Taylor <iant <at> google.com> 
wrote:
> > Andrew Haley <aph <at> redhat.com> writes:
> >
> >> Ian Lance Taylor wrote:
> >>> Andrew Haley <aph <at> redhat.com> writes:
> >>>
> >>>> Richard Guenther wrote:
> >>>>> On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <Kai.
> Tietz <at> onevision.com> wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> as I noticed, most hash value calculations are trying to use 
pointer
> >>>>>> values for building the value and assume that a long/unsigned
> long scalar
> >>>>>> is wide enough for a pointer. This is at least for w64 target
> not true. So
> >>>>>> I want to know, if it would be good to introduce an gcc 
> specific type for
> >>>>>> those kind of casts, or to use ssize_t/size_t.?
> >>>>> it's uintptr_t which should be used, if only as an intermediate 
cast -
> >>>>> (unsigned long)(uintptr_t)ptr.
> >>>> That's not possible because, IIRC, gcc must compile on C90 systems.
> >>>
> >>> We can just test for it with autoconf and typedef it if we don't 
(Continue reading)

Steven Bosscher | 2 Jun 10:49 2008
Picon

Wolfe patent on "assert chains"

Hi,

This is just a heads-up for this patent Sun Microsystems is claiming
on the construction of "Factored assert chains", see
http://www.patentstorm.us/patents/7272829/description.html

I wonder if GCC's VRP ASSERT_EXPRs would be considered prior art.

Gr.
Steven

Diego Novillo | 2 Jun 15:05 2008
Picon

Re: Wolfe patent on "assert chains"

On Mon, Jun 2, 2008 at 04:49, Steven Bosscher <stevenb.gcc <at> gmail.com> wrote:

> I wonder if GCC's VRP ASSERT_EXPRs would be considered prior art.

Even earlier than that.  The assertion mechanism in GCC was taken
directly from the PLDI'95 Patterson paper.

Diego.

Daniel Berlin | 2 Jun 15:14 2008

Re: Wolfe patent on "assert chains"

On Mon, Jun 2, 2008 at 9:05 AM, Diego Novillo <dnovillo <at> google.com> wrote:
> On Mon, Jun 2, 2008 at 04:49, Steven Bosscher <stevenb.gcc <at> gmail.com> wrote:
>
>> I wonder if GCC's VRP ASSERT_EXPRs would be considered prior art.
>
> Even earlier than that.  The assertion mechanism in GCC was taken
> directly from the PLDI'95 Patterson paper.

Guys, as long as the implementation exactly follows some practice that
pre-dates the priority date on the patent (in this case, 2003), you
have nothing to worry about.

(and by exactly, i mean exactly)

Robert Dewar | 2 Jun 15:14 2008

Re: Wolfe patent on "assert chains"

Diego Novillo wrote:
> On Mon, Jun 2, 2008 at 04:49, Steven Bosscher <stevenb.gcc <at> gmail.com> wrote:
> 
>> I wonder if GCC's VRP ASSERT_EXPRs would be considered prior art.
> 
> Even earlier than that.  The assertion mechanism in GCC was taken
> directly from the PLDI'95 Patterson paper.

Does anyone know if inclusion of something in openly available source
code has been accepted as proper publication for prior art? (it does
not meet the letter, but it does meet the spirit I would say).
> 
> 
> Diego.


Gmane