Re: Problem initializing volatile structures
On Thu, Jan 28, 2010 at 5:13 PM, Byron Stanoszek wrote:
> I've recently upgraded to GCC 4.3.2 from 4.2.2, and I noticed a strange
> change in how volatile bitmask structures are optimized.
>
> Consider the following code:
>
> /* 32-bit MMIO */
> struct hardware {
> int parm1:8;
> int :4;
> int parm2:4;
> int parm3:15;
> int parm4:1;
> };
>
> void f1()
> {
> volatile struct hardware *ptr=(void *)0x11223344;
>
> *ptr=(struct hardware) {
> .parm1=42,
> .parm2=13,
> .parm3=11850,
> .parm4=1,
> };
> }
>
> void f2()
> {
> volatile struct hardware *ptr=(void *)0x11223344;
>
> struct hardware set={
> .parm1=42,
> .parm2=13,
> .parm3=11850,
> .parm4=1,
> };
>
> *ptr=set;
> }
>
>
> In GCC 4.3.2, this produces the following assembly:
>
> f1:
> movl $0, 287454020
> movb $42, 287454020
> movl 287454020, %eax
> andb $15, %ah
> orb $208, %ah
> movl %eax, 287454020
> movl 287454020, %eax
> andl $-2147418113, %eax
> orl $776601600, %eax
> movl %eax, 287454020
> movl 287454020, %eax
> orl $-2147483648, %eax
> movl %eax, 287454020
> ret
>
> f2:
> movl $-1370828758, 287454020
> ret
>
> Aren't both functions syntactically the same, and shouldn't they produce the
> same optimized code as in "f2" above? This used to be the case in GCC 4.2.2.
>
> The problem I'm seeing, apart from the lack of optimization, is that "f1"
> causes 5 separate writes to a single MMIO register, instead of 1. This
> particular hardware register is only expecting one write to this location,
> and
> when multiple writes are received it causes the hardware to fail.
>
> If this new behavior is intended, is there some sort of attribute I can add
> to
> the code to get the original 4.2.2 behavior back?
Please file a bugreport.
THanks
Richard.
> Thanks for your comments,
> -Byron
>
>
Bugzilla and setting priorities
In PR target/42894 rguenth said: > Only RMs may set priority. I beg your pardon? Where in the docs does it say that? R.
Re: GCC-How does the coding style affect the insv pattern recognization?
2010/1/18 Adam Nemet : > fanqifei writes: >> Paolo Bonzini said that insv instruction might be synthesized >> later by combine. But combine only works on at most 3 instructions and >> insv is not generated in such case. >> So exactly when will the insv pattern be recognized and how does >> the coding style affect it? > > Sorry for jumping in late. See make_file_assigment in combine.c. > > The problem usually is that: > > (set A (ior (and B C1) OTHER)) > > can only be turned into a bit-insertion if A and B happen to be the same > pseudos. > > Adam > I did found such kind of pattern for some simple C statements in rtl dump. Unfortunately, A and B are not same. Is it possible and easy to move B to A firstly and replace B with A in the insn? Anyway, this is not required if it's impracticable. Qifei Fan
Re: Bugzilla and setting priorities
On Fri, Jan 29, 2010 at 11:09 AM, Richard Earnshaw wrote: > In PR target/42894 rguenth said: >> Only RMs may set priority. > > I beg your pardon? Where in the docs does it say that? I don't know that, but it's been discussed many times on this list. Ciao! Steven
Re: Bugzilla and setting priorities
Steven Bosscher wrote: >>> Only RMs may set priority. >> >> I beg your pardon? Where in the docs does it say that? > > I don't know that, but it's been discussed many times on this list. As a mere mortal I've used the priority setting combo a few times to specify (perceived) priority, which later was adjusted by a person reviewing bug reports (i.e. Andrew or Paolo), so, at least technically, it is available to anyone. Anyway, speaking of reporting bugs: what's the rule of specifying CCs? Especially to the submitter himself? I would like to be aware of the status of several bugs, so may I add myself to the CC list? Or is it supposed to be used only by the fixers? Best regards Piotr Wyderski
Re: Bugzilla and setting priorities
On 01/29/2010 11:09 AM, Richard Earnshaw wrote: > In PR target/42894 rguenth said: > >> Only RMs may set priority. >> > I beg your pardon? Where in the docs does it say that? > Want to say two words about how I see these issues. Eventually, when the time of releasing comes, only RMs, essentially, decide which bugs block a release or not. In collaboration with the various specific maintainers, whatever, but certainly submitters cannot decide anything in this area. Maybe something tough to say, but true, as far as I can say. Thus, what's the point of submitter fiddling with those Bugzilla fields? Putting some sort of psychological pressure on people actually working on fixing the bugs? Seems really either pointless or even counterproductive, because RMs (and maintainers) may be in the process of categorizing and triaging according to a specific strategy which submitters don't know and, frankly, in general cannot contribute to decide. In my opinion, as a matter of general policy, submitters should essentially add to the audit trail or close bugs which cannot be reproduced anymore (maybe) very little else. Paolo.
Re: Bugzilla and setting priorities
On 29/01/2010 10:29, Piotr Wyderski wrote: > Anyway, speaking of reporting bugs: what's the rule of > specifying CCs? Especially to the submitter himself? > I would like to be aware of the status of several bugs, > so may I add myself to the CC list? Or is it supposed > to be used only by the fixers? I can't see any reason on earth not to CC yourself to any bug that you have even a passing interest in monitoring progress with, and regularly do it myself. Nobody's ever complained. cheers, DaveK
Re: Bugzilla and setting priorities
On 01/29/2010 12:00 PM, Dave Korn wrote: > I can't see any reason on earth not to CC yourself to any bug that you > have > even a passing interest in monitoring progress with, and regularly do it > myself. Nobody's ever complained. > Sure. Maybe it's also worth reminding that submitters don't need to add explicitly themselves in CC. Paolo.
Re: Bugzilla and setting priorities
On 29/01/2010 10:12, Steven Bosscher wrote: > On Fri, Jan 29, 2010 at 11:09 AM, Richard Earnshaw wrote: >> In PR target/42894 rguenth said: >>> Only RMs may set priority. >> I beg your pardon? Where in the docs does it say that? > > I don't know that, but it's been discussed many times on this list. You can understand why people aren't always going to be aware of it if we only ever discuss it in email and there's no mention anywhere in the bug reporting or contributing pages of the website. On 29/01/2010 10:39, Paolo Carlini wrote: > Want to say two words about how I see these issues. Eventually, when the > time of releasing comes, only RMs, essentially, decide which bugs block > a release or not. In collaboration with the various specific > maintainers, whatever, but certainly submitters cannot decide anything > in this area. It's regularly been discussed in terms of just before a release and specifically for bugs targeted against that particular release, but I for one did not infer that this rule also applied to all bugs regardless of the stage of development of the targeted version. It would be good if someone who knew the score was to add something to the bug reporting page (or perhaps the wiki, with a link on the bug reporting page) that gave details about "How we use Bugzilla in GCC"; the generic BZ help linked to from the PR itself isn't so specific. You could say that people should realise from the text: > Priority > This field describes the importance and order in which a bug > should be fixed. This field is utilized by the programmers/engineers to > prioritize their work to be done. The available priorities range from P1 > (most important) to P5 (least important.) ... that it's not for end-users, but it would be much nicer to have something as explicit as what the mozilla project have written up at: https://developer.mozilla.org/en/What_to_do_and_what_not_to_do_in_Bugzilla cheers, DaveK
Re: Bugzilla and setting priorities
Paolo Carlini wrote: > Sure. Maybe it's also worth reminding that submitters don't need to add > explicitly themselves in CC. It's the reason I asked -- I've been recently removed from CC. So thanks for explanation. Best regards Piotr Wyderski
Re: Bugzilla and setting priorities
On Fri, Jan 29, 2010 at 11:29 AM, Piotr Wyderski wrote: > Steven Bosscher wrote: > Only RMs may set priority. >>> >>> I beg your pardon? Where in the docs does it say that? >> >> I don't know that, but it's been discussed many times on this list. > > As a mere mortal I've used the priority setting combo > a few times to specify (perceived) priority, which later > was adjusted by a person reviewing bug reports (i.e. > Andrew or Paolo), so, at least technically, it is available > to anyone. The priority for regressions (only for regressions) is to control the release process and thus is reserved to the release managers. Please do not change priority for regressions from P3 to something else (you might change it from Pn back to P3 to get RM review). This should ideally be documented in http://gcc.gnu.org/bugs/management.html I'll work on a patch. Richard.
Re: Bugzilla and setting priorities
On 29/01/2010 11:03, Richard Guenther wrote: > This should ideally be documented in > http://gcc.gnu.org/bugs/management.html Both the way that page is named, and the way the link to it is indented under the link to the BZ frontpage in the side navbar on the gcc.gnu.org front page, make it look very much like it's intended for BZ admins, rather than ordinary bug-reporting users. Maybe that needs a bit of tweaking too? Or perhaps a prominent link from the "How to report" page? cheers, DaveK
Re: Bugzilla and setting priorities
Paolo Carlini wrote: > Thus, what's the point of submitter fiddling with those Bugzilla > fields? Putting some sort of psychological pressure on people actually > working on fixing the bugs? Well, that's true when it comes to high priorities, but the submitter should have the opportunity to specify lower priorities. For instance a typo is a bug which should be fixed, but certainly it isn't a showstopper, so it doesn't deserve to be classified as a normal priority report. > submitters should essentially add to the audit trail or > close bugs which cannot be reproduced anymore > (maybe) very little else. Submitters should not be allowed to close bug reports themselves, otherwise it will wreak havoc. They should explain the reasons and ask somebody with sufficient credentials to do it on their behalf. Last, but not least, I wolud like to apologise you and Dave for unnecessary investigation of the first part of PR42880, which was obviously my fault. Best regards Piotr Wyderski
Re: Bugzilla and setting priorities
On Fri, Jan 29, 2010 at 12:26 PM, Dave Korn wrote: > On 29/01/2010 11:03, Richard Guenther wrote: > >> This should ideally be documented in >> http://gcc.gnu.org/bugs/management.html > > Both the way that page is named, and the way the link to it is indented > under the link to the BZ frontpage in the side navbar on the gcc.gnu.org front > page, make it look very much like it's intended for BZ admins, rather than > ordinary bug-reporting users. Maybe that needs a bit of tweaking too? Or > perhaps a prominent link from the "How to report" page? Sure - patches welcome ;) Attached is what I will install barring any negative comments. Richard. p Description: Binary data
Re: Bugzilla and setting priorities
On Fri, 2010-01-29 at 12:24 +0100, Richard Guenther wrote: > On Fri, Jan 29, 2010 at 12:26 PM, Dave Korn > wrote: > > On 29/01/2010 11:03, Richard Guenther wrote: > > > >> This should ideally be documented in > >> http://gcc.gnu.org/bugs/management.html > > > > Both the way that page is named, and the way the link to it is indented > > under the link to the BZ frontpage in the side navbar on the gcc.gnu.org > > front > > page, make it look very much like it's intended for BZ admins, rather than > > ordinary bug-reporting users. Maybe that needs a bit of tweaking too? Or > > perhaps a prominent link from the "How to report" page? > > Sure - patches welcome ;) > > Attached is what I will install barring any negative comments. > > Richard. > +A P1 bug blocks the release. Do you really mean that, or do you mean a P1 regression? Maybe it should read: A P1 regression blocks the release; any other P1 bug will hold up the release until this issue has been fully reviewd. R
Re: Bugzilla and setting priorities
On Fri, 2010-01-29 at 11:26 +, Dave Korn wrote: > On 29/01/2010 11:03, Richard Guenther wrote: > > > This should ideally be documented in > > http://gcc.gnu.org/bugs/management.html > > Both the way that page is named, and the way the link to it is indented > under the link to the BZ frontpage in the side navbar on the gcc.gnu.org front > page, make it look very much like it's intended for BZ admins, rather than > ordinary bug-reporting users. Maybe that needs a bit of tweaking too? Or > perhaps a prominent link from the "How to report" page? > > cheers, > DaveK > We have three categories of users of BZ: RMs, Developers, and the rest. Developers are *not* the same as the rest and that extends beyond the ability to modify bug reports. R.
Re: Bugzilla and setting priorities
On Fri, Jan 29, 2010 at 1:00 PM, Richard Earnshaw wrote: > > On Fri, 2010-01-29 at 12:24 +0100, Richard Guenther wrote: >> On Fri, Jan 29, 2010 at 12:26 PM, Dave Korn >> wrote: >> > On 29/01/2010 11:03, Richard Guenther wrote: >> > >> >> This should ideally be documented in >> >> http://gcc.gnu.org/bugs/management.html >> > >> > Both the way that page is named, and the way the link to it is indented >> > under the link to the BZ frontpage in the side navbar on the gcc.gnu.org >> > front >> > page, make it look very much like it's intended for BZ admins, rather than >> > ordinary bug-reporting users. Maybe that needs a bit of tweaking too? Or >> > perhaps a prominent link from the "How to report" page? >> >> Sure - patches welcome ;) >> >> Attached is what I will install barring any negative comments. >> >> Richard. > >> + A P1 bug blocks the release. > > Do you really mean that, or do you mean a P1 regression? Maybe it > should read: > > A P1 regression blocks the release; any other P1 bug will hold > up the release until this issue has been fully reviewd. Priorities do not mean anything for a release if they are not regressions. Note how everything in the priority section talks about regressions only. I'll adjust the wording to "A P1 regression blocks the release.". Thanks, Richard.
Re: Bugzilla and setting priorities
On 29/01/2010 12:02, Richard Earnshaw wrote: > We have three categories of users of BZ: RMs, Developers, and the rest. > Developers are *not* the same as the rest and that extends beyond the > ability to modify bug reports. Ah, I may have overlooked something here; can the creator not adjust the priority of their own bugs if they don't have developer perms? cheers, DaveK
help on gcc source code odification
Hi,
I am working with gcc 4.4.2.
I installed the same on my machine using the following command lines.
1)To extract in a new directory,i used,
mkdir gcc1
cd gcc1
tar -xvf gcc-4.4.2.tar.gz
set srcdir = "/home/swati/gcc1/gcc-4.4.2"
set objdir = "/home/swati/gcc1/gcc-bin"
set insdir = "/home/swati/gcc1//usr/local"
mkdir -p srcdir
mkdir -p objdir
mkdir -p insdir
2)Then i configured it in objdir directory using,
/home/swati/gcc1/gcc-4.4.2/configure --prefix=$insdir
make bootstrap -j3
make install (in root)
3)Then compiled using,
export PATH=$insdir/bin/:$PATH
gcc helloworld.c -v
and finally compiled a helloworld.c file using this version and it worked fine.
Now, i wish to modify the source code of gcc.
So am working on the c-parser.c file to introduce an exception
generation on detection of 'if' statement.
For it ,i used folowing code
static jmp_buf buf;
void exception_handler()
{
FILE *fp1;
fp1=fopen("/home/swati/t.txt","w");
fprintf(fp1,"'if' detected\n");
longjmp(buf,1);
}
static void
c_parser_if_statement (c_parser *parser)
{
FILE *fp;
if (!setjmp(buf) )
{
exception_handler();
}
else
{
fp=fopen("/home/swati/t.txt","a");
fprintf(fp,"\t\t\t\tBack to if block");
}
}
Now , i recompiled the gcc using following commands,
1)Changed to path to build directory,
cd /home/swati/newgcc/objdir/build-i686-pc-linux-gnu/gcc/build/
2) Configured with --disable-bootstrap modification.
/home/swati/newgcc/gcc-4.4.2/configure --disable-bootstrap--prefix=$insdir
make all-gcc
3)Selected newly configured gcc and tried to compile helloworld.c file.
export
PATH=$insdir/bin/:$PATH
gcc helloworld.c -v
However, the changes (t.txt creation and statements insertion within it) were
not reflected and i got an error:
"source is more recent than the executable"
Am i working with the correct file and were the installation and compilation
steps correct. Also was i correct in attempt to modify the source code
Please help.
Swati
Get your preferred Email name!
Now you can @ymail.com and @rocketmail.com.
http://mail.promotions.yahoo.com/newdomains/aa/
Re: Bugzilla and setting priorities
On Fri, 2010-01-29 at 12:25 +, Dave Korn wrote: > On 29/01/2010 12:02, Richard Earnshaw wrote: > > > We have three categories of users of BZ: RMs, Developers, and the rest. > > Developers are *not* the same as the rest and that extends beyond the > > ability to modify bug reports. > > Ah, I may have overlooked something here; can the creator not adjust the > priority of their own bugs if they don't have developer perms? I'm not sure exactly what mod rights a non-developer has, but they are limited. I don't think they can close bug reports for example. R.
Re: Bugzilla and setting priorities
2010/1/29 Richard Earnshaw :
>
> On Fri, 2010-01-29 at 12:25 +, Dave Korn wrote:
>> On 29/01/2010 12:02, Richard Earnshaw wrote:
>>
>> > We have three categories of users of BZ: RMs, Developers, and the rest.
>> > Developers are *not* the same as the rest and that extends beyond the
>> > ability to modify bug reports.
>>
>> Ah, I may have overlooked something here; can the creator not adjust the
>> priority of their own bugs if they don't have developer perms?
>
> I'm not sure exactly what mod rights a non-developer has, but they are
> limited. I don't think they can close bug reports for example.
>
> R.
>
>
They can't. Most fields are read-only for none-developer users.
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Selective notifications for new bug reports
Once my platforms are in reasonably good shape, I plan to go over old bugzilla reports and handle them as appropriate. Due the the sheer volume on gcc-bugs, it's impossible for me to even skim over the list. Since any polling-based scheme to track new bug reports is doomed, I'd like to get automatic notifications instead. While whinings seem to be the way to go, I have not really found which search to use to get notified about new bugs matching certain search critera (like build =~ solaris || hot =~ solaris || target =~ solaris). Any suggestions? Currently, http://gcc.gnu.org/bugs/management.html states: UNCONFIRMED The PR has been filed and the responsible person(s) notified. But how is this notification supposed to happen? Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: help on gcc source code odification
swati raina writes: > Now , i recompiled the gcc using following commands, > > 1)Changed to path to build directory, > > cd /home/swati/newgcc/objdir/build-i686-pc-linux-gnu/gcc/build/ > > 2) Configured with --disable-bootstrap modification. > > /home/swati/newgcc/gcc-4.4.2/configure --disable-bootstrap--prefix=$insdir > > make all-gcc Did you run "make install" again? > Am i working with the correct file and were the installation and compilation > steps correct. Also was i correct in attempt to modify the source code Your changes to c-parser.c should have had some effect when compiling C code, yes. Ian
Re: Selective notifications for new bug reports
Rainer Orth writes: > Currently, http://gcc.gnu.org/bugs/management.html states: > > UNCONFIRMED > The PR has been filed and the responsible person(s) notified. > > But how is this notification supposed to happen? The theory is that the notification is based on the product and component of the bug report. However, we don't actually use that feature for gcc, and it wouldn't help you find Solaris bugs anyhow. Ian
[trans-mem] ipa tm pass and dominator walks
Hey! With my last patch, we only have 3 instances of dominator tree walks left in the tree, all in the TM ipa pass. I believe we can leave those as they are, since the TM ipa pass runs early enough that nothing has altered control flow such that code outside of a transaction ends up inside a transaction. For instance, the original problem that brought about this surgery involved the following flow graph: #1 __transaction // transaction header | | V #3 ---> #4 | trxn_commit() | | | | V | #6 | trxn_commit() | func() | | | | | V | #5<-+ notrxn = 99 return Basic block #5 was inserted into the transaction by a combination of inlining and jump threading. This cannot happen before the IPA pass because it runs much earlier, and AFAICT nothing that alters control flow detrimentally runs before IPA. Consequently, if we have: __transaction // transaction header--+ | | V | INSIDE_TRANSACTION | trxn over edge | | V | OUTSIDE_TRANSACTION <--+ When iterating through INSIDE_TRANSACTION, we are assured that nothing in OUTSIDE_TRANSACTION is *immediately* dominated by anything inside the transaction, because #1 (the transaction header), has an "over" edge into OUTSIDE_TRANSACTION. So by definition, the transaction header will be the immediate dominator of the first block of OUTSIDE_TRANSACTION. Since INSIDE_TRANSACTION hasn't been engrafted anything from outside, and nothing inside immediately dominates anything outside (unless it passes through TransactionCommit), then we can just use immediate dominance as we're currently doing. If you agree, then nothing needs to be done with the rest of the immediate dominator mess. Waddaya think? Aldy
Adding memory write to a sparc fsqrts insn
Hello everybody, I'd like to patch gcc's sparc machine descritpion so that the destination register of a fpu sqareroot operation fsqrts is stored into memory after each fsqrts. like this: fsqrts %f2,%f4 st %f4, -4[%fp] <= add this after every fsqrts where -4[%fp] is a slot allocated on the stack for each fsqrts insn The sparc.md portion that defines the fsqrts pattern is: (define_insn "sqrtsf2" [(set (match_operand:SF 0 "register_operand" "=f") (sqrt:SF (match_operand:SF 1 "register_operand" "f")))] "TARGET_FPU" "fsqrts\t%1, %0" [(set_attr "type" "fpsqrts")]) i thought I could add the "st %f4, -4[%fp]" there. But now my question: - Where/when/how can I allocate the stackframe slot to save the destination fp reg in (the offset to %fp). I'm not that familiar with rtl representation and the stages of compilation. So any help would be apreciated. Maybe another architecture has a similar construct already that I could study and use for my purpose. If somebody can point me to such machine description part ... -- Greetings Konrad
Re: Support for export keyword to use with C++ templates ?
On Mon, Jan 25, 2010 at 8:12 PM, Ian Lance Taylor wrote: > Timothy Madden writes: > >> On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor wrote: >>> Timothy Madden writes: >>> Why is it so hard to store template definitions (and the set of symbols visible to them) in an object file, probably as a representation of the parsed template source tree ? >>> >>> I recommend reading "Why We Can't Afford Export." >> >> I have seen that paper in the link, N1426, and I find it to be biased >> against export ... > > It may be biased, but I think it does a nice job of explaining why it > is so hard to store template definitions and the set of symbols > visible to them. No, it only scares people off the subject ... So nobody here wants to try a big thing ? :( How long would it take for someone to understand how parsing works in g++ ? Or to understand the build system in gcc ? Thank you, Timothy Madden
Re: Support for export keyword to use with C++ templates ?
Timothy Madden writes: > How long would it take for someone to understand how parsing works in > g++ ? Or to understand the build system in gcc ? I don't think you need to understand the build system to implement export in C++. You do clearly need to understand the g++ frontend. However, it's impossible for me to estimate how long it would take somebody to understand it. It would depend greatly on that person's experience as a programmer and knowledge of C++. gcc's C++ frontend is probably some 150,000 lines of code, considering everything. Ian
Re: Support for export keyword to use with C++ templates ?
On 01/30/2010 01:14 AM, Ian Lance Taylor wrote: > I don't think you need to understand the build system to implement > export in C++. You do clearly need to understand the g++ frontend. > However, it's impossible for me to estimate how long it would take > somebody to understand it. It would depend greatly on that person's > experience as a programmer and knowledge of C++. gcc's C++ frontend > is probably some 150,000 lines of code, considering everything. > Even for implementors knowing *very* well both the details of the C++ standard and the internals of a specific front-end, implementing export is an *highly* non-trivial task. You can probably find this paper useful: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf Paolo.
Re: Support for export keyword to use with C++ templates ?
On Fri, Jan 29, 2010 at 8:05 PM, Paolo Carlini wrote: > Even for implementors knowing *very* well both the details of the C++ > standard and the internals of a specific front-end, implementing export > is an *highly* non-trivial task. However, I have a gut feeling that at least a restricted version of 'export' (or a cousin of 'export') could be both useful and trivial to implement: Perhaps a limited form could simply automate the not-infrequently employed practice of creating a translation unit specifically for explicit template instantiations. Sincerely, Michael Witten
Re: Support for export keyword to use with C++ templates ?
Paolo Carlini writes: > On 01/30/2010 01:14 AM, Ian Lance Taylor wrote: >> I don't think you need to understand the build system to implement >> export in C++. You do clearly need to understand the g++ frontend. >> However, it's impossible for me to estimate how long it would take >> somebody to understand it. It would depend greatly on that person's >> experience as a programmer and knowledge of C++. gcc's C++ frontend >> is probably some 150,000 lines of code, considering everything. >> > Even for implementors knowing *very* well both the details of the C++ > standard and the internals of a specific front-end, implementing export > is an *highly* non-trivial task. You can probably find this paper useful: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf I already tried to tell him that upthread. Ian
Re: Support for export keyword to use with C++ templates ?
On Fri, Jan 29, 2010 at 06:23:45PM -0800, Michael Witten wrote: > On Fri, Jan 29, 2010 at 8:05 PM, Paolo Carlini > wrote: > > Even for implementors knowing *very* well both the details of the C++ > > standard and the internals of a specific front-end, implementing export > > is an *highly* non-trivial task. > > However, I have a gut feeling that at least a restricted version of > 'export' (or a cousin of 'export') could be both useful and trivial to > implement: Perhaps a limited form could simply automate the > not-infrequently employed practice of creating a translation unit > specifically for explicit template instantiations. The typical implementations have all sorts of problems: where do you store these extra explicit template expansions? If you make a database for the template expansions, you have locking problem, or experience frequent corruption or the like; I've had such problems making such systems work that we've generally resorted to turning it off (e.g. tell Sun's compiler to expand templates into static functions). These problems might be overcome, but it hasn't been done because it is a hard problem. The main difficulty is building a robust flow that supports parallel builds and an efficient link pass.
