Re: Question about building hash values from pointers

On Mon, Jun 2, 2008 at 5:59 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Andrew Haley <[EMAIL PROTECTED]> writes: > >> Ian Lance Taylor wrote: >>> Andrew Haley <[EMAIL PROTECTED]> writes: >>> Richard Guenther wrote: > On Fri, May 30, 2008 at 10:57 AM, Kai Tietz <[EMAIL PROTECTED]> wro

Re: Question about building hash values from pointers

"Richard Guenther" <[EMAIL PROTECTED]> wrote on 02.06.2008 10:28:12: > On Mon, Jun 2, 2008 at 5:59 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > Andrew Haley <[EMAIL PROTECTED]> writes: > > > >> Ian Lance Taylor wrote: > >>> Andrew Haley <[EMAIL PROTECTED]> writes: > >>> > Richard Gue

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

Re: Wolfe patent on "assert chains"

On Mon, Jun 2, 2008 at 04:49, Steven Bosscher <[EMAIL PROTECTED]> 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.

Re: Wolfe patent on "assert chains"

On Mon, Jun 2, 2008 at 9:05 AM, Diego Novillo <[EMAIL PROTECTED]> wrote: > On Mon, Jun 2, 2008 at 04:49, Steven Bosscher <[EMAIL PROTECTED]> 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

Re: Wolfe patent on "assert chains"

Diego Novillo wrote: On Mon, Jun 2, 2008 at 04:49, Steven Bosscher <[EMAIL PROTECTED]> 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 in

Re: Wolfe patent on "assert chains"

On Mon, Jun 2, 2008 at 9:14 AM, Robert Dewar <[EMAIL PROTECTED]> wrote: > Diego Novillo wrote: >> >> On Mon, Jun 2, 2008 at 04:49, Steven Bosscher <[EMAIL PROTECTED]> >> wrote: >> >>> I wonder if GCC's VRP ASSERT_EXPRs would be considered prior art. >> >> Even earlier than that. The assertion mech

Re: Wolfe patent on "assert chains"

On Mon, Jun 2, 2008 at 9:47 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote: > On Mon, Jun 2, 2008 at 9:14 AM, Robert Dewar <[EMAIL PROTECTED]> wrote: >> Diego Novillo wrote: >>> >>> On Mon, Jun 2, 2008 at 04:49, Steven Bosscher <[EMAIL PROTECTED]> >>> wrote: >>> I wonder if GCC's VRP ASSERT_EXPRs

Re: Wolfe patent on "assert chains"

> >> 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). > > > > The patent examiners i've spoken with in the past (and their > > superviso

Re: Wolfe patent on "assert chains"

On Mon, Jun 2, 2008 at 10:09 AM, Richard Kenner <[EMAIL PROTECTED]> wrote: >> >> 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). >> >

Re: Wolfe patent on "assert chains"

> IE they don't care whether it i printed, and don't care whether it i a > publication, they care whether it is accessible to the public and has > been disseminated to the public. Right. That's exactly what I meant. They are saying that "printed" vs "electronic" doesn't matter. However, the is

Re: Wolfe patent on "assert chains"

Daniel Berlin wrote: I understand the problem you are facing, but the cited case (and those following it) make clear they do not equate "publication" with "technical paper", but instead "something available to the public, regardless of form". It still has to be reasonably accessible to one of

Re: Wolfe patent on "assert chains"

Richard Kenner wrote: IE they don't care whether it i printed, and don't care whether it i a publication, they care whether it is accessible to the public and has been disseminated to the public. Right. That's exactly what I meant. They are saying that "printed" vs "electronic" doesn't matte

Re: Wolfe patent on "assert chains"

On Mon, Jun 2, 2008 at 10:55 AM, Robert Dewar <[EMAIL PROTECTED]> wrote: > Richard Kenner wrote: >>> >>> IE they don't care whether it i printed, and don't care whether it i a >>> publication, they care whether it is accessible to the public and has >>> been disseminated to the public. >> >> Right.

Re: Wolfe patent on "assert chains"

Could you folks take this off list please? It was barely on topic when it began. It's now totally off topic. Thanks. Diego.

undefined reference to `__w32_sharedptr_unexpected'

Hi I'm using gcc (g++) and keep getting the following error I've tried exporting LD_LIBRARY_PATH to the mingw/lib. I've tried adding the -Wl, -brtl flag (I'm not sure it I did correctly -- It kept saying that it did not recognize the -brtl option) Anyways, I've run out of ideas. I'm a beginner

RE: undefined reference to `__w32_sharedptr_unexpected'

Aaron Patton wrote on 02 June 2008 17:59: > I'm a beginner. So go easy on me. Ok, then I will /gently/ point out that this is the wrong list. End-user questions about how to drive gcc go to the gcc-help list. This list is for the gcc dev team to discuss their work on the internals of the

Question about i386.md and 32-bit and 64-bit split and peephole rules

Hi, As I noticed are some parts in i386.md existing for just for 32-bit, but will be used in 64-bit, too. For example: (define_split [(set (match_operand:XF 0 "push_operand" "") (float_extend:XF (match_operand:SF 1 "fp_register_operand" "")))] "" [(set (reg:SI SP_REG) (plus:SI (reg

Re: Question about i386.md and 32-bit and 64-bit split and peephole rules

Hello! As I noticed are some parts in i386.md existing for just for 32-bit, but will be used in 64-bit, too. For example: (define_split [(set (match_operand:XF 0 "push_operand" "") (float_extend:XF (match_operand:SF 1 "fp_register_operand" "")))] "" [(set (reg:SI SP_REG) (plus:SI

gcc-4.1-20080602 is now available

Snapshot gcc-4.1-20080602 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080602/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

[lto] Streaming out language-specific DECL/TYPEs

In g++.dg/torture/20070621-1.C we are trying to stream out a structure that contains a TEMPLATE_DECL. This currently causes a failure in lto-function-out.c:output_tree because not only TEMPLATE_DECL is C++-specific, we can't even access its fields from lto-function-out.c. The only way I see to ha

Re: [lto] Streaming out language-specific DECL/TYPEs

Diego Novillo wrote: In g++.dg/torture/20070621-1.C we are trying to stream out a structure that contains a TEMPLATE_DECL. This currently causes a failure in lto-function-out.c:output_tree because not only TEMPLATE_DECL is C++-specific, we can't even access its fields from lto-function-out.c. T

Re: [lto] Streaming out language-specific DECL/TYPEs

On Mon, Jun 2, 2008 at 5:10 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > In g++.dg/torture/20070621-1.C we are trying to stream out a structure > that contains a TEMPLATE_DECL. This currently causes a failure in > lto-function-out.c:output_tree because not only TEMPLATE_DECL is > C++-specific, w