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]> 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 > to be fairly routine for the kind of portability we aim for. Only one > person has to get them right once. > > But I'm fine with using size_t also, if it does the right thing on > W64. If size_t is fine then long is also fine if W64 is compatible with C90 (guess what - it is not). So I'd rather go the full lenghth of using C99 uintptr_t which is what even W64 would be compatible with (C99, that is). Richard.
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 Guenther wrote:
> > On Fri, May 30, 2008 at 10:57 AM, Kai Tietz [EMAIL PROTECTED]> 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
> > to be fairly routine for the kind of portability we aim for. Only one
> > person has to get them right once.
> >
> > But I'm fine with using size_t also, if it does the right thing on
> > W64.
>
> If size_t is fine then long is also fine if W64 is compatible with C90
> (guess what - it is not). So I'd rather go the full lenghth of using
> C99 uintptr_t which is what even W64 would be compatible with (C99, that
is).
>
> Richard.
>
w64 is compatible to C90, because we use a trick to generate a compatible
declaration for size_t in C90 mode. We declare it via __attribute__ ((mode
(DI))). So size_t would be fine fow w64, too (at least for mingw-w64).
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
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 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)
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 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.
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 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). The patent examiners i've spoken with in the past (and their supervisors) consider publicly available source code to be prior art. I am too lazy to search federal circuit case law, but my recollection is that their is a case or two on point here saying it is. (They read "printed publication" very broadly to include any document available to the public)
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 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). > > The patent examiners i've spoken with in the past (and their > supervisors) consider publicly available source code to be prior art. > I am too lazy to search federal circuit case law, but my recollection > is that their is a case or two on point here saying it is. > (They read "printed publication" very broadly to include any document > available to the public) > Here you go: http://www.uspto.gov/web/offices/pac/mpep/documents/2100_2128.htm
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 > > supervisors) consider publicly available source code to be prior art. > > I am too lazy to search federal circuit case law, but my recollection > > is that their is a case or two on point here saying it is. > > (They read "printed publication" very broadly to include any document > > available to the public) > > > Here you go: > > http://www.uspto.gov/web/offices/pac/mpep/documents/2100_2128.htm Hmm I'm not sure. Nothing in there seems to be talking about viewing source code as a "publication". The way I read that, it's addressing the issue of "printed" vs "electronic", not "source code" vs "publication".
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). >> > >> > The patent examiners i've spoken with in the past (and their >> > supervisors) consider publicly available source code to be prior art. >> > I am too lazy to search federal circuit case law, but my recollection >> > is that their is a case or two on point here saying it is. >> > (They read "printed publication" very broadly to include any document >> > available to the public) >> > >> Here you go: >> >> http://www.uspto.gov/web/offices/pac/mpep/documents/2100_2128.htm > > Hmm I'm not sure. Nothing in there seems to be talking about viewing > source code as a "publication". The way I read that, it's addressing the > issue of "printed" vs "electronic", not "source code" vs "publication". Uh? "We agree that 'printed publication' should be approached as a unitary concept. The traditional dichotomy between 'printed' and 'publication' is no longer valid. Given the state of technology in document duplication, data storage, and data retrieval systems, the 'probability of dissemination' of an item very often has little to do with whether or not it is 'printed' in the sense of that word when it was introduced into the patent statutes in 1836. In any event, interpretation of the words 'printed' and 'publication' to mean 'probability of dissemination' and 'public accessibility' respectively, now seems to render their use in the phrase 'printed publication' somewhat redundant." 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. Anyway, this is wildly off topic.
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 issue here isn't whether it matters if the GCC sources were printed in a book someplace or just available electronically. The issue that Robert was raising is not the "printed" part, but the "publication" part. Specifically, if source code could be considered a "publication". Reading the reference you gave makes it sound like they're using the term "publication" interchangably with "technical paper" in that they're talking about online references and databases. Nothing in that document (I didn't go to the referenced cases) seems on point to the issue of whether source code is a "publication".
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 appropriate skills. Surely you would not argue that machine code is sufficient, on the grounds you could reverse engineer it to determine that it was using somme particular arlgorithm? "interpretation of the words 'printed' and 'publication' to mean 'probability of dissemination' and 'public accessibility'" (note that publication is equated with public accessibility, not form of document If you want to argue they are not exactly on point, you could try, but given there is absolutely no caselaw i can find coming down that would support such a position, I think you would be hard pressed to find a judge who would not roll their eyes at you. :)
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 matter. However, the issue here isn't whether it matters if the GCC sources were printed in a book someplace or just available electronically. The issue that Robert was raising is not the "printed" part, but the "publication" part. Specifically, if source code could be considered a "publication". Reading the reference you gave makes it sound like they're using the term "publication" interchangably with "technical paper" in that they're talking about online references and databases. Nothing in that document (I didn't go to the referenced cases) seems on point to the issue of whether source code is a "publication". For example, at one extreme, the source code may have extensive comments so that it is clearly a publication. At the other extreme it could be uncommented junk, and an argument could be made that someone with appropriate skills could not reasonably extract the information needed. At a really really extreme level, object code can document stuff if you are willing to do enough reverse engineering, but would be unlikely to qualify as publication. I don't think this is entirely off topic, we do want to make sure that anything we do within gcc acts at the very least as its own defence against a patent that comes along later.
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. That's exactly what I meant. They are saying that "printed" >> vs "electronic" doesn't matter. >> >> However, the issue here isn't whether it matters if the GCC sources were >> printed in a book someplace or just available electronically. >> >> The issue that Robert was raising is not the "printed" part, but the >> "publication" part. Specifically, if source code could be considered >> a "publication". Reading the reference you gave makes it sound like >> they're >> using the term "publication" interchangably with "technical paper" in >> that they're talking about online references and databases. >> >> Nothing in that document (I didn't go to the referenced cases) seems on >> point to the issue of whether source code is a "publication". > > For example, at one extreme, the source code may have extensive comments > so that it is clearly a publication. > > At the other extreme it could be uncommented junk, and an argument could > be made that someone with appropriate skills could not reasonably extract > the information needed. > 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". "interpretation of the words 'printed' and 'publication' to mean 'probability of dissemination' and 'public accessibility'" (note that publication is equated with public accessibility, not form of document If you want to argue they are not exactly on point, you could try, but given there is absolutely no caselaw i can find coming down that would support such a position, I think you would be hard pressed to find a judge who would not roll their eyes at you. :)
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. So go easy on me. Thanks $ make -f Makefile C:/msys/1.0/mingw/bin/gfortran -o cirfets CIRFTYPES.o CIRFETS.o CIRFCHANS.o CIRFERRS.o CIRFIO.o CIRFPOST.o CIRFSUBS.o libiolib.a -lstdc++ -Wl C:/msys/1.0/mingw/lib/libstdc++.a(eh_throw.o):eh_throw.cc:(.text+0x7b): undefined reference to `__w32_sharedptr_unexpected' C:/msys/1.0/mingw/lib/libstdc++.a(eh_throw.o):eh_throw.cc:(.text+0x8c): undefined reference to `__w32_sharedptr_terminate' C:/msys/1.0/mingw/lib/libstdc++.a(eh_globals.o):eh_globals.cc:(.text+0x4e): undefined reference to `__w32_sharedptr' C:/msys/1.0/mingw/lib/libstdc++.a(eh_globals.o):eh_globals.cc:(.text+0xb9): undefined reference to `__w32_sharedptr' C:/msys/1.0/mingw/lib/libstdc++.a(eh_globals.o):eh_globals.cc:(.text+0x179): undefined reference to `__w32_sharedptr' C:/msys/1.0/mingw/lib/libstdc++.a(eh_globals.o):eh_globals.cc:(.text+0x186): undefined reference to `__w32_sharedptr' C:/msys/1.0/mingw/lib/libstdc++.a(eh_globals.o):eh_globals.cc:(.text+0x1e3): undefined reference to `__w32_sharedptr' C:/msys/1.0/mingw/lib/libstdc++.a(eh_globals.o):eh_globals.cc:(.text+0x1ef): more undefined references to `__w32_sharedptr' follow C:/msys/1.0/mingw/lib/libstdc++.a(eh_terminate.o):eh_terminate.cc:(.text+0x67): undefined reference to `__w32_sharedptr_terminate' C:/msys/1.0/mingw/lib/libstdc++.a(eh_terminate.o):eh_terminate.cc:(.text+0x97): undefined reference to `__w32_sharedptr_unexpected' C:/msys/1.0/mingw/lib/libstdc++.a(eh_terminate.o):eh_terminate.cc:(.text+0xb3): undefined reference to `__w32_sharedptr_terminate' C:/msys/1.0/mingw/lib/libstdc++.a(eh_terminate.o):eh_terminate.cc:(.text+0xd3): undefined reference to `__w32_sharedptr_unexpected' collect2: ld returned 1 exit status C:\msys\1.0\mingw\bin\make.exe: *** [cirfets] Error 1 Below is the makefile I'm using # Directories: # appdir = ./CIRFETS # libdir = ./IOLIB # VPATH = $(appdir):$(libdir) # objs = CIRFTYPES.o CIRFETS.o CIRFCHANS.o CIRFERRS.o CIRFIO.o CIRFPOST.o CIRFSUBS.o mods = cirf_types.mod incs = CIRF.FI CIRFCONST.FI CIRFCHANS.FI CIRFERRS.FI CIRFGRIDS.FI \ CIRFIO.FI CIRFPOWER.FI CIRFREALZ.FI IMPLICIT.FI # libs = C:/msys/1.0/mingw/lib/libstdc++.a libs = -lstdc++ -Wl # Compiler Rules: CXX = C:/msys/1.0/mingw/bin/g++ CXXFLAGS = FC = C:/msys/1.0/mingw/bin/gfortran FFLAGS = -fno-underscoring LINK = C:/msys/1.0/mingw/bin/gfortran # Implicit Rules: %o: %.cpp $(CXX) -c $(CXXFLAGS) $< -o $@ %.o: %.F $(FC) -c $(FFLAGS) $< -o $@ # Executable: cirfets : $(objs) libiolib.a $(LINK) -o $@ $(objs) libiolib.a $(libs) # Objects: CIRFTYPES.o cirf_types.mod : CIRFTYPES.F $(incs) $(FC) -c $(FFLAGS) $< -verbose -o $@ CIRFETS.o : CIRFETS.F $(incs) CIRFCHANS.o : CIRFCHANS.F $(incs) CIRFERRS.o : CIRFERRS.F $(incs) CIRFIO.o : CIRFIO.F $(incs) CIRFPOST.o : CIRFPOST.F $(incs) CIRFSUBS.o : CIRFSUBS.F $(incs) # IOLIB Makefile libiolib.a : ChanIO.o ar cru $@ $< ChanIO.o : ChanIO.cpp ChanIO.h iomacs.h clean: rm -f ChanIO.o libiolib.a rm -f cirfets $(objs) $(mods)
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 compiler itself. So unless you have some actual reason to believe that there is a bug in the compiler itself, rather than in your code or the options you use to compile it, your question belongs on gcc-help. cheers, DaveK -- Can't think of a witty .sigline today
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:SI SP_REG) (match_dup 2)))
(set (mem:XF (reg:SI SP_REG)) (float_extend:XF (match_dup 1)))]
"operands[2] = GEN_INT (TARGET_128BIT_LONG_DOUBLE ? -16 : -12);")
(define_split
[(set (match_operand:XF 0 "push_operand" "")
(float_extend:XF (match_operand:SF 1 "fp_register_operand" "")))]
"TARGET_64BIT"
[(set (reg:DI SP_REG) (plus:DI (reg:DI SP_REG) (match_dup 2)))
(set (mem:DF (reg:DI SP_REG)) (float_extend:XF (match_dup 1)))]
"operands[2] = GEN_INT (TARGET_128BIT_LONG_DOUBLE ? -16 : -12);")
The first section will be used on 32-bit and on 64-bit, the second
just for 64-bit. Isn't this wrong? Should in the first define_split
not explicit said "!TARGET_64BIT"?
There some other places where this happens too, and for the ESP
adjustments there seems to be present just the 32-bit version?.
Thanks in advance for anwser,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
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 (reg:SI SP_REG) (match_dup 2))) (set (mem:XF (reg:SI SP_REG)) (float_extend:XF (match_dup 1)))] "operands[2] = GEN_INT (TARGET_128BIT_LONG_DOUBLE ? -16 : -12);") (define_split [(set (match_operand:XF 0 "push_operand" "") (float_extend:XF (match_operand:SF 1 "fp_register_operand" "")))] "TARGET_64BIT" [(set (reg:DI SP_REG) (plus:DI (reg:DI SP_REG) (match_dup 2))) (set (mem:DF (reg:DI SP_REG)) (float_extend:XF (match_dup 1)))] "operands[2] = GEN_INT (TARGET_128BIT_LONG_DOUBLE ? -16 : -12);") The first section will be used on 32-bit and on 64-bit, the second just for 64-bit. Isn't this wrong? Should in the first define_split not explicit said "!TARGET_64BIT"? There some other places where this happens too, and for the ESP adjustments there seems to be present just the 32-bit version?. This is wrong, the first splitter should have !TARGET_64BIT. Even better approach would be to copy what MIPS does: ;; This mode iterator allows :P to be used for patterns that operate on ;; pointer-sized quantities. Exactly one of the two alternatives will match. (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")]) and use P iterator instead of SI and DI in one macroized pattern that substitutes both splitters. Uros.
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/gcc-4_1-branch revision 136303 You'll find: gcc-4.1-20080602.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20080602.tar.bz2 C front end and core compiler gcc-ada-4.1-20080602.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20080602.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20080602.tar.bz2 C++ front end and runtime gcc-java-4.1-20080602.tar.bz2 Java front end and runtime gcc-objc-4.1-20080602.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20080602.tar.bz2The GCC testsuite Diffs from 4.1-20080526 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[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 handle these cases is to use a langhook. I appreciate that we are trying to get rid of these, but this is only a langhook used when streaming things out (in cc1plus). On the way in (lto1), we would not need the langhook, as we would just mechanically recreate the fields. Thoughts? Diego.
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. The only way I see to handle these cases is to use a langhook. I appreciate that we are trying to get rid of these, but this is only a langhook used when streaming things out (in cc1plus). On the way in (lto1), we would not need the langhook, as we would just mechanically recreate the fields. Thoughts? Diego. i had been told (but such statements are often lies) that there were not supposed to be any languages specific tree codes this late in the compilation. if there needs to be, then this should not be a lang specific tree code and needs to become a regular tree code. the problem with making this a langhook is that there is no "there-there" in that on the serialize in side, you would have to recreate the c++ front end code that expects this tree code. (if there is no such code, then this tree code could/should have been removed before you got there. On the other hand, if this tree code needs to be there, then copying the c++ front end code that processes it later is a bad road to go down. I would like to see this publicly discussed by the c++ front end people to see why this tree code lingers so long. In all other cases, these late lived fe specific tree codes either have or are supposed to have been removed. Kenny
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, we can't even access its fields from lto-function-out.c. TEMPLATE_DECL should have been converted to a FUNCTION_DECL already by this time as far as I can read the sources. Does TEMPLATE_DECL show up in the context or where does it show up? Thanks, Andrew Pinski
