Custom __attribute__ like functionality
Hi all,
I am interested in being able to "mark-up" C++ code with special
meta-information. This is kind of like the existing __attribute__ for GCC but
the semantics are quite different (I.e. Not just function/type level but
statement level meta-data). I wish to ask if anyone knows of anything existing
that may be able to achieve what i desire and if nothing exists what others
think the difficulty would be of modifying existing __attribute__ semantics or
creating something new. Note: This is for a non-mainstream patch and I will not
be requesting it be added to mainstream GCC unless people could see a reason to
do so.
Basically I would like to mark-up arbitrary segments of C++ code "like":
#define EDOC_NOTHROW(Code) __attribute__ ((nothrow)) { Code }
#define EDOC_THROW(Code, Types) __attribute__ ((throw(Types))) { Code }
for (Type i = begin(); EDOC_NOTHROW( i < end() ); i++)
{
}
or:
EDOC_NOTHROW(vec.push_back(blah));
I would probably want meta information for things, like: nothrow, throws (With
additional type arguments), and a doc one that can be used for assigning
documentation meta-information to a "throw x;" statement.
The idea is that a patched GCC (I already have a patched GCC for gathering
other exception based data: http://edoc.sourceforge.net/ ) would then be able
to query tree nodes for some sort of "attached" meta-data that includes this
information. I could then use this with the EDoc++ program in order to allow
users to provide indications of code segments that require different types of
exception guarantees, which is then enforced at a later time.
Any thoughts or ideas are welcome.
Thanks,
Brendon.
Choosing the right TLS access model
Hi, (This message is a duplicate of a message to `gcc-help' where I did not get a definitive answer[*].) I read parts of Drepper's [0] and Oliva's [1] work on TLS access. From my understanding, the `initial-exec' model can be used safely when compiling an executable. However, it's still unclear to me whether/when it can be used within a shared library. Section 3 of [0] explains `initial-exec' like this: A more restrictive optimization is usable if the variables accessed are known to be in one of the modules available and program start and if the programmer selects to use the static access model. I believe it should read "available *at* program start". Likewise, Section 2.1 of [1] reads: Under certain circumstances, [the Initial Exec model] may be used in dynamic libraries as well, but it may come at the cost of being unable to dlopen such libraries. This gives the impression that shared libraries that are not meant to be dlopened can be compiled with `-ftls-model=initial-exec'. Is this true? If so, would using `-ftls-model=initial-exec' cause problems with the way the shared library accesses other library's TLS (e.g., libc's `errno')? IOW, instead of using `-ftls-model', should one instead use an explicit `tls_model' attribute for all the library's thread-local variables? Thanks, Ludovic. [*] http://thread.gmane.org/gmane.comp.gcc.help/20641 [0] http://people.redhat.com/drepper/tls.pdf [1] http://www.lsd.ic.unicamp.br/~oliva/writeups/TLS/paper.pdf
RE: Address of template function bug (was: Overload resolution compilation error)
On 06 August 2007 02:13, Rodolfo Lima wrote: > Rodolfo Schulz de Lima escreveu: >> Dave Korn escreveu: >>> Thanks, and do drop a note back with a summary of what you find out over >>> there when you're done; if there's definitely a bug in gcc's >>> understanding of the resolution rules, obviously we'd like to open a PR >>> and get it fixed. >> >> I think we have finally a consensus at >> >> http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/52 087a72bdc5de5a > > Hi, I'd like some feedback on this thread because if it's really a bug, > I'd fill a bug report. Yes, please go ahead and file a bug report in the GCC bugzilla. http://gcc.gnu.org/bugzilla/ Include the testcase and link to the above thread. This way, it will come to the attention of the C++ maintainers, who can verify the arguments for accepting it. The fact that MSVC and Comeau both accept it very much suggests that this is indeed a genuine problem in GCC, but nobody will be upset if this turns out to be a false alarm; bug reports are all screened and verified after receiving them. cheers, DaveK -- Can't think of a witty .sigline today
Re: [RFC] Improve Tree-SSA if-conversion - convergence of efforts
Michael Matz <[EMAIL PROTECTED]> wrote on 31/07/2007 18:05:53: > Hi, > > On Tue, 31 Jul 2007, Daniel Berlin wrote: > > > > 2. Store-sinking/load hoisting may have an overhead and may degrade > > > performance unless the relevant conditional branch gets if-converted. > > > > I agree with you for conditional stores/loads. > > > > The unconditional store/load stuff, however, is exactly what > > tree-ssa-sink was meant to do, and belongs there (this is #3 above). I'm > > certainly going to fight tooth and nail against trying to shoehorn > > unconditional store sinking into if-conv. > > FWIW I also agree that handling unconditional stores/loads does not belong > in if-conv (or phi-opt), but in ssa-sink (or some similar transformation > which can or can not use value numbers and the like). OK. And what's your opinion WRT conditional loads/stores? Since you've sent your conditional store transformation patch, I guess the meaning could be rewriting it on the top of tree-if-conv. Tehila. > > > Ciao, > Michael.
x64_64-elf support
Is there any reason why this contribution from Mikkel Krautz is still not in the current sources? http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01592.html Hans Kester === This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify Ellips B.V. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Ellips B.V, Urkhovenseweg 11, 5641 KA Eindhoven, The Netherlands, www.ellips.nl, [EMAIL PROTECTED] Deze e-mail en eventuele bijlages zijn vertrouwelijk en alleen voor gebruik door de bedoelde ontvanger. Wanneer u deze e-mail onterecht ontvangen heeft, notificeert u dan Ellips B.V. Dit bericht bevat vertrouwelijke informatie en is alleen bedoeld voor de bedoelde ontvanger. Wanneer u deze ontvanger niet bent, dient u deze e-mail niet te verspreiden of te kopieeren. Bericht de zender alstublieft meteen door de e-mail te beantwoorden en verwijder dan deze e-mail van uw systeem. Wanneer u niet de bedoelde ontvanger bent, bent u bij deze ingelicht dat verspreiden, kopieeren en het oneigenlijk gebruiken van deze inhoud strikt verboden is. Ellips B.V, Urkhovenseweg 11, 5641 KA Eindhoven, Nederland, www.ellips.nl, [EMAIL PROTECTED] Ellips B.V.
Re: x64_64-elf support
"Hans Kester " <[EMAIL PROTECTED]> writes: > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom > they are addressed. If you have received this email in error please > notify Ellips B.V. This message contains confidential information > and is intended only for the individual named. If you are not the > named addressee you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately by e-mail if you have > received this e-mail by mistake and delete this e-mail from your > system. If you are not the intended recipient you are notified that > disclosing, copying, distributing or taking any action in reliance > on the contents of this information is strictly prohibited. Ellips > B.V, Urkhovenseweg 11, 5641 KA Eindhoven, The Netherlands, > www.ellips.nl, [EMAIL PROTECTED] Please do not send messages with this sort of disclaimer to the gcc.gnu.org mailing lists. They are against list policy (http://gcc.gnu.org/lists.html). If you are unable to remove the disclaimer from e-mail sent from your company, then I recommend using a free web-based e-mail account. Thanks.
Re: [RFC] Improve Tree-SSA if-conversion - convergence of efforts
Hi, On Mon, 6 Aug 2007, Tehila Meyzels wrote: > > in if-conv (or phi-opt), but in ssa-sink (or some similar transformation > > which can or can not use value numbers and the like). > > OK. > > And what's your opinion WRT conditional loads/stores? > Since you've sent your conditional store transformation patch, > I guess the meaning could be rewriting it on the top of tree-if-conv. Actually I'm not so sure about that. I found the phi-opt infrastructure much better suited to do the necessary pattern matching, so I only thought of the conditional store replacement as enabling transformation. Also tree-if-conv only handles loops (and only inner ones), not general conditional patterns. Something which might be fixable with some amount of work, but the phi-opt infrastructure simply was already there. Ciao, Michael.
Re: poor optimisation case
Tristan Wibberley <[EMAIL PROTECTED]> writes: > I've found a case which looks like it should be possible to optimise but > gcc (very recent trunk) isn't doing which could give improvements in > many cases - certainly in a case I've come across: Looks reasonable to me. Please open a missed-optimization report, with your test case, at http://gcc.gnu.org/bugzilla/. For more information see http://gcc.gnu.org/bugs.html. Thanks. Ian
GCC Testsuite question (C checks in Fortran suite)
I am running into a problem running the gfortran.dg/c_kind_params.f90
and am wondering how to address it. This test has a C language
component in gfortran.dg/c_kinds.c. This C file includes stdint.h and
uses types like int32_t and int64_t. On HPPA HP-UX platforms we don't
have a stdint.h header file so I would like to disable the test on that
platform. We currently have a test for this so I put
! { dg-require-effective-target stdint_types }
in gfortran.dg/c_kind_params.f90. This did turn off the test for the
HPPA platforms but it also seemed to turn it off on the Linux platforms
and it should not have done that.
So my question is: is it OK to run this type of check (where the check
compiles C code) in a non-C testsuite like gfortran.dg? Should I put
the check in c_kinds.c instead? I didn't try that but I don't think it
would work. Or can I just not use this test in gfortran.dg?
Steve Ellcey
[EMAIL PROTECTED]
Re: top-level configure
> > 2007-07-23 Ralf Wildenhues <[EMAIL PROTECTED]> > > > > * configure.ac (TOPLEVEL_CONFIGURE_ARGUMENTS, baseargs): > > Pass --silent if $silent. Ok.
Re: poor optimisation case
On Mon, 2007-08-06 at 07:38 -0700, Ian Lance Taylor wrote: > Tristan Wibberley <[EMAIL PROTECTED]> writes: > > > I've found a case which looks like it should be possible to optimise but > > gcc (very recent trunk) isn't doing which could give improvements in > > many cases - certainly in a case I've come across: > > Looks reasonable to me. Please open a missed-optimization report, > with your test case, at http://gcc.gnu.org/bugzilla/. For more > information see http://gcc.gnu.org/bugs.html. Thanks. Oh no, not another username and password to remember... :( Would it be a breach of your bugzilla terms and conditions if I write my username and password down and keep it next to my computer? Any chance of moving to launchpad.net? -- Tristan Wibberley Any opinion expressed is mine (or else I'm playing devils advocate for the sake of a good argument). My employer had nothing to do with this communication.
Re: poor optimisation case
On 8/6/07, Tristan Wibberley <[EMAIL PROTECTED]> wrote: > Any chance of moving to launchpad.net? And launchpad.net forces everyone else to remember a new username and password. Anyways the username for gcc bugzilla is your email address. -- Pinski
Re: poor optimisation case
On Mon, Aug 06, 2007 at 07:08:04PM +0100, Tristan Wibberley wrote: > On Mon, 2007-08-06 at 07:38 -0700, Ian Lance Taylor wrote: > > Tristan Wibberley <[EMAIL PROTECTED]> writes: > > > > > I've found a case which looks like it should be possible to optimise but > > > gcc (very recent trunk) isn't doing which could give improvements in > > > many cases - certainly in a case I've come across: > > > > Looks reasonable to me. Please open a missed-optimization report, > > with your test case, at http://gcc.gnu.org/bugzilla/. For more > > information see http://gcc.gnu.org/bugs.html. Thanks. > > Oh no, not another username and password to remember... :( Would it be a > breach of your bugzilla terms and conditions if I write my username and > password down and keep it next to my computer? No, it would not. But your browser can remember the password for you. > Any chance of moving to launchpad.net? Zero. launchpad is proprietary software, with both the software and database controlled by Canonical (Ubuntu's parent company).
Re: GCC Testsuite question (C checks in Fortran suite)
On Mon, 2007-08-06 at 10:28 -0700, Steve Ellcey wrote:
> I am running into a problem running the gfortran.dg/c_kind_params.f90
> and am wondering how to address it. This test has a C language
> component in gfortran.dg/c_kinds.c. This C file includes stdint.h and
> uses types like int32_t and int64_t. On HPPA HP-UX platforms we don't
> have a stdint.h header file so I would like to disable the test on that
> platform. We currently have a test for this so I put
>
> ! { dg-require-effective-target stdint_types }
>
> in gfortran.dg/c_kind_params.f90. This did turn off the test for the
> HPPA platforms but it also seemed to turn it off on the Linux platforms
> and it should not have done that.
>
> So my question is: is it OK to run this type of check (where the check
> compiles C code) in a non-C testsuite like gfortran.dg? Should I put
> the check in c_kinds.c instead? I didn't try that but I don't think it
> would work. Or can I just not use this test in gfortran.dg?
I added it to c_kind_params.f90 in this position:
! { dg-do run }
! { dg-require-effective-target stdint_types }
! { dg-additional-sources c_kinds.c }
! { dg-options "-w -std=c99" }
and the test runs on powerpc64-linux for both -m32 and -m64. Did
you have it in a different position? If so I'll try that and see
if I can figure out why it would be skipped. Also, which target
were you testing?
Most of the effective target checks use C code. I think it's safe
to assume that the build or install tree being tested will always
have a C compiler available.
Janis
Re: poor optimisation case
> Any chance of moving to launchpad.net? And launchpad.net forces everyone else to remember a new username and password. Launchpad is also non-free software.
Re: GCC Testsuite question (C checks in Fortran suite)
> and the test runs on powerpc64-linux for both -m32 and -m64. Did
> you have it in a different position? If so I'll try that and see
> if I can figure out why it would be skipped. Also, which target
> were you testing?
I was testing on an IA64 Linux platform (Debian). I had this:
! { dg-do run }
! { dg-additional-sources c_kinds.c }
! { dg-options "-w -std=c99" }
! { dg-require-effective-target stdint_types }
! the -w option is needed to make f951 not report a warning for
! the -std=c99 option that the C file needs.
Maybe I need to move the dg-require-effective-target up?
> Most of the effective target checks use C code. I think it's safe
> to assume that the build or install tree being tested will always
> have a C compiler available.
OK. I wasn't sure if it should work or not. I certainly built C as
well as C++ and Fortran in the build that I was testing.
Steve Ellcey
[EMAIL PROTECTED]
Re: GCC Testsuite question (C checks in Fortran suite)
On Mon, 2007-08-06 at 13:16 -0700, Steve Ellcey wrote:
> > and the test runs on powerpc64-linux for both -m32 and -m64. Did
> > you have it in a different position? If so I'll try that and see
> > if I can figure out why it would be skipped. Also, which target
> > were you testing?
>
> I was testing on an IA64 Linux platform (Debian). I had this:
>
> ! { dg-do run }
> ! { dg-additional-sources c_kinds.c }
> ! { dg-options "-w -std=c99" }
> ! { dg-require-effective-target stdint_types }
> ! the -w option is needed to make f951 not report a warning for
> ! the -std=c99 option that the C file needs.
>
> Maybe I need to move the dg-require-effective-target up?
Yes. I tried it in the order your used, and the compile to check
for inttypes.h tried to also compile c_kinds.c, which wasn't
available from where the compile was done. In general it's best
to check effective targets before adding files or options, unless
the options are required for the effective-target check.
Janis
Re: missing libtool sources?
[ CVS HEAD's ltmain.sh containing as first line: # Generated from ltmain.m4sh; do not edit by hand ] * DJ Delorie wrote on Thu, Aug 02, 2007 at 05:09:09PM CEST: > > > I don't think this is much of a problem. ltmain.sh is always > > distributed with libtool and you would need the full libtool sources to > > rebuild it anyway. > > I was thinking more of the legality of shipping GPL files without > their sources, being defined as "the preferred form of the work for > making modifications to it", and since the file says "do not edit this > file", we're clearly not complying. > > It would be bad form for an FSF project to not comply 100% with the > GPL. I think we should adjust the Libtool sources in this case. While CVS HEAD's ltmain.sh is generated from ltmain.m4sh, and we prefer patches against the latter file, the former is definitely in a source code form that makes modifications just as easy: both are shell scripts without lots of redundancy (unlike configure scripts). And the intended mode of operation is definitely to have the former file distributed rather than the latter. IMHO the same holds for the other files generated thusly from the Makefile. Would this patch eliminate further doubts? If no, could you suggest an improvement? Thanks, Ralf 2007-08-06 Ralf Wildenhues <[EMAIL PROTECTED]> * Makefile.am (edit): Do not warn against manual editing for the generated files libtool, libtoolize, libltdl/m4/ltversion.m4, tests/defs, as they are still in a preferred source code form as required by GPL. Report by DJ Delorie. Index: Makefile.am === RCS file: /cvsroot/libtool/libtool/Makefile.am,v retrieving revision 1.224 diff -u -r1.224 Makefile.am --- Makefile.am 26 Jul 2007 22:44:39 - 1.224 +++ Makefile.am 6 Aug 2007 21:10:34 - @@ -135,7 +135,7 @@ -e 's,@pkgdatadir\@,$(pkgdatadir),g' \ -e 's,@host_triplet\@,$(host_triplet),g' \ -e 's,@prefix\@,$(prefix),g' \ - -e "s,@configure_input\@,Generated from $$input; do not edit by hand,g" + -e "s,@configure_input\@,Generated from $$input.,g" sh_files = $(auxdir)/general.m4sh $(auxdir)/getopt.m4sh EXTRA_DIST += bootstrap $(srcdir)/libtoolize.in $(auxdir)/ltmain.m4sh \
Re: GCC Testsuite question (C checks in Fortran suite)
> Yes. I tried it in the order your used, and the compile to check > for inttypes.h tried to also compile c_kinds.c, which wasn't > available from where the compile was done. In general it's best > to check effective targets before adding files or options, unless > the options are required for the effective-target check. > > Janis Thanks, I'll change the order and see how things look in tonight's testing. Assuming it goes well I'll send an official patch tomorrow. Steve Ellcey [EMAIL PROTECTED]
gcc-4.1-20070806 is now available
Snapshot gcc-4.1-20070806 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070806/ 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 127256 You'll find: gcc-4.1-20070806.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070806.tar.bz2 C front end and core compiler gcc-ada-4.1-20070806.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070806.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070806.tar.bz2 C++ front end and runtime gcc-java-4.1-20070806.tar.bz2 Java front end and runtime gcc-objc-4.1-20070806.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070806.tar.bz2The GCC testsuite Diffs from 4.1-20070730 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.
Question about PR tree-optimization/32941, bootstrap failure, qsort
I was looking at PR tree-optimization/32941 after seeing a bootstrap failure on my IA64 Linux box. I was wondering if anyone knows why it has started failing now? It looks like this sorting of the goto queue has been around for quite a while (since 4.1 at least). Do we have more goto's than we used to in our GCC code? Does anyone have any ideas on how to fix it? The obvious thing to do is to sort based on the contents of the goto and return expr's instead of the address of them but it is not clear to me that there is anything unique to sort on. Two different goto's or return's could have completely identical data in them but still be different nodes. Types and insn's seem to have unique ID's but it doesn't look like general tree types's do. What if we didn't sort it at all and did a linear search on the goto queue? Is the goto queue actually ever long enough that this would affect the compilation time? Steve Ellcey [EMAIL PROTECTED]
What 64-bit CPU targets dominate in the future?
Hi people, I'm looking for simulators of 64-bit processors for my 32-bit PC and i've found one. "qemu-system-x86_64" works simulating a x86-64 linux as slamd64, ubuntu, etc. http://fabrice.bellard.free.fr/qemu/status.html indicates that x86-64 is OK for System emulation but is not supported for user emulation. The problem is that the x86-64 ISA is too complex to develop i an aplication that generates assembler or machine code like CacaoJVM, JCVM, Flex, ... x86-64 is CISC and not RISC. It will be easy if the 64-bit CPU is RISC. I don't know what 64-bit CPU that will dominate in years 2008 .. 2013. I'm not sure if PearPC or PSIM simulates PowerPC64 ISA but the "Full-System Simulator for IBM PowerPC 970" said that it does but it's closed source. I'm not sure if Sulima simulates Sparc64 ISA from http://ccnuma.anu.edu.au/sulima/0.4/sparc-sulima-0.4.tar.gz but it goes to v0.4 version, not v1.0 :( The IA-64 CPU is monstruous and too complex because there aren't known open source applications that target IA-64. I don't know if that simulator exists or not. After talking, my question is: What popularity of CPU will dominate in the years 2008 .. 2013? By example, 1. x86-64: 75% 2. ppc64: 15% 3. sparc64: 5% 4. others: 5% Any opinion to the respect? Sincerely yours, J.C.
Re: What 64-bit CPU targets dominate in the future?
This doesn't really have much to do with GCC. Perhaps you'd like to ask on comp.arch? Ben
