detecting integer overflows
Recently I came across http://embed.cs.utah.edu/ioc/ which describes a sophisticated integer overflow checker for Clang. The reported results obtained by analyzing C/C++ open source projects make a convincing case for implementing such functionality in gcc/g++ as well. Is somebody looking into this? /MB
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, Oct 29, 2012 at 02:07:55PM -0400, David Miller wrote: > > I'd like to close the stage 1 phase of GCC 4.8 development > > on Monday, November 5th. If you have still patches for new features you'd > > like to see in GCC 4.8, please post them for review soon. Patches > > posted before the freeze, but reviewed shortly after the freeze, may > > still go in, further changes should be just bugfixes and documentation > > fixes. > > I'd like to get the Sparc cbcond stuff in (3 revisions posted) which > is waiting for Eric B. to do some Solaris specific work. That has been posted in stage 1, so it is certainly ok to commit it even during early stage 3. And, on a case by case basis exceptions are always possible. This hasn't changed in the last few years. By the reviewed shortly after the freeze I just want to say that e.g. having large intrusive patches posted now, but reviewed late December is already too late. As for postponing end of stage 1 by a few weeks because of the storm, I'm afraid if we want to keep roughly timely releases we don't have that luxury. If you look at http://gcc.gnu.org/develop.html, ending stage 1 around end of October happened already for 4.6 and 4.7, for 4.5 if was a month earlier and for 4.4 even two months earlier. The 4.7 bugfixing went IMHO smothly, but we certainly have to expect lots of bugfixing. > I'd also like to enable LRA for at least 32-bit sparc, even if I can't > find the time to work on auditing 64-bit completely. I agree with Eric that it is better to enable it for the whole target together, rather than based on some options. Enabling LRA in early stage 3 for some targets should be ok, if it doesn't require too large and intrusive changes to the generic code that could destabilize other targets. Jakub
Re: detecting integer overflows
On Tue, 2012-10-30 at 01:09 -0600, Michael Buro wrote: > Recently I came across http://embed.cs.utah.edu/ioc/ which describes a > sophisticated integer overflow checker for Clang. The reported results > obtained by analyzing C/C++ open source projects make a convincing > case for implementing such functionality in gcc/g++ as well. Is > somebody looking into this? Not sure, but we've still got a half-broken -ftrapv :) E.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412 Or like on SH, some of the arithmetic ops get expanded to libcalls and some (afair SImode plus and minus) end up as normal ops. Cheers, Oleg
Informazioni
Buonasera. Vorrei segnalarvi i servizi della mia azienda: realizzazione siti web professionali ad alto impatto grafico e cura estetica; inoltre si sviluppano programmi per computer e gestionali personalizzati, con attenzione all'usabilità. Sono sviluppatore con ampia esperienza e le mie competenze includono siti web di impatto grafico, con possibilità di più lingue, possibilità di sviluppo di e-commerce per la vendita on-line di prodotti e servizi, app per dispositivi mobili, app catalogo, app per realtà aumentata, sviluppo per tablet, i QR-Code (codici quadrati), sviluppo in tecnologia Adobe Flash, le innovative app per Facebook, gestionali, integrazione con servizi SMS e/o newsletter via email; ci occupiamo inoltre di grafica tradizionale. Alcune mie recenti creazioni: www . studiolegalederasis . it www . bereniceshoes . it Al seguente indirizzo trovate inoltre una piccola novità del web: un sito navigabile dall'interno di una normale pagina aziendale su Facebook: http://www.facebook.com/pezflash.previews/app_146195685451991 Potete contattarmi al presente indirizzo e-mail. Nella speranza di non aver arrecato disturbo, resto a disposizione e vi auguro un buon lavoro. Distinti saluti. Marco Nextep Solutions, Genova "Il segreto per andare avanti è iniziare" (Sally Berger)
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On Mon, Oct 29, 2012 at 1:56 PM, Jakub Jelinek wrote: > Status > == > > I'd like to close the stage 1 phase of GCC 4.8 development > on Monday, November 5th. If you have still patches for new features you'd > like to see in GCC 4.8, please post them for review soon. Patches > posted before the freeze, but reviewed shortly after the freeze, may > still go in, further changes should be just bugfixes and documentation > fixes. I will be committing the VEC overhaul soon. With any luck this week, but PCH and gengtype are giving me a lot of grief. Diego.
Question on load motion in GCSE
Hi, When doing load motion in GCSE, it depends on different simple memory refers in pre_ldst_table won't clobber(alias to) each other. I am assuming function simple_mem is the answer to this question, but what I don't understand is how simple_mem can make sure of this? Did I understand the load motion in a wrong way? Please help. Thanks. -- Best Regards.
Ada bootstrap broken?
I'm getting the following while trying to bootstrap a clean trunk at rev 192986: cd ada/bldtools/einfo; gnatmake -q xeinfo ; ./xeinfo einfo.h ) In file included from gcc/clean/trunk/gcc/ada/seh_init.c:48:0: gcc/clean/trunk/gcc/system.h:499:34: error: declaration of C function 'const char* strsignal(int)' conflicts /usr/include/string.h:566:14: error: previous declaration 'char* strsignal(int)' here In file included from gcc/clean/trunk/gcc/system.h:639:0, from gcc/clean/trunk/gcc/ada/initialize.c:55: gcc/clean/trunk/gcc/../include/libiberty.h:110:36: error: new declaration 'char* basename(const char*)' /usr/include/string.h:603:28: error: ambiguates old declaration 'const char* basename(const char*)' In file included from /usr/local/google/home/dnovillo/gcc/clean/trunk/gcc/system.h:639:0, from /usr/local/google/home/dnovillo/gcc/clean/trunk/gcc/ada/env.c:76: /usr/local/google/home/dnovillo/gcc/clean/trunk/gcc/../include/libiberty.h:110:36: error: new declaration 'char* basename(const char*)' /usr/include/string.h:603:28: error: ambiguates old declaration 'const char* basename(const char*)' In file included from gcc/clean/trunk/gcc/system.h:639:0, from gcc/clean/trunk/gcc/ada/seh_init.c:48: gcc/clean/trunk/gcc/../include/libiberty.h:110:36: error: new declaration 'char* basename(const char*)' /usr/include/string.h:603:28: error: ambiguates old declaration 'const char* basename(const char*)' On IRC, Richi says that this is a parallel make issue. Re-starting make works around the issue. For now, I'm forced to disable Ada bootstraps. Could someone in ada land take a look at this? Thanks. Diego.
Re: Ada bootstrap broken?
> On IRC, Richi says that this is a parallel make issue. Re-starting > make works around the issue. > > For now, I'm forced to disable Ada bootstraps. Could someone in ada > land take a look at this? I'll have a look. Arno
Re: Question on load motion in GCSE
On Tue, Oct 30, 2012 at 9:47 PM, Bin.Cheng wrote: > Hi, > When doing load motion in GCSE, it depends on different simple memory > refers in pre_ldst_table won't clobber(alias to) each other. > I am assuming function simple_mem is the answer to this question, but > what I don't understand is how simple_mem can make sure of this? > > Did I understand the load motion in a wrong way? Please help. Thanks. > Please ignore this message. I just realized that GCC retreats to normal alias information in mems_conflict_for_gcse_p function for different memory refs in pre_ldst_table. -- Best Regards.
Re: Ada bootstrap broken?
On Tue, Oct 30, 2012 at 11:44 AM, Arnaud Charlet wrote: > I'll have a look. Thanks!
Re: Ada bootstrap broken?
> I'll have a look. I cannot reproduce, but this might come from missing dependencies in Make- lang.in for the affected files. -- Eric Botcazou
Re: Ada bootstrap broken?
> I cannot reproduce, but this might come from missing dependencies in Make- > lang.in for the affected files. Right, there's no explicit dependencies for seh_init.o at all, although this is not something new. Has something changed recently in the way e.g. system.h or similar are generated/handled that would explain this change in behavior? I guess we should in any case go ahead and add explicit deps for seh_init.o? Eric, would you mind have a shot at it? Diego, can you confirm that it's indeed seh_init.o which is failing? Arno
Re: Ada bootstrap broken?
On Tue, Oct 30, 2012 at 12:45 PM, Arnaud Charlet wrote: > Diego, can you confirm that it's indeed seh_init.o which is failing? Yes. The error was given on seh_init.c:48 Thanks. Diego.
Re: Build/Makefile question
I should have mentioned sooner, but thanks, that fixed my problem! -- Caroline cmt...@google.com On Mon, Oct 29, 2012 at 10:34 AM, Ian Lance Taylor wrote: > On Mon, Oct 29, 2012 at 10:24 AM, Caroline Tice wrote: >> >> Actually, I did have to edit the Makefile.in slightly. When I >> generate it with automake, it automatically adds the lines: >> >> libvtv_init_la_LIBADD = >> libvtv_init_la_SOURCES = libvtv_init.c >> libvtv_init_la_OBJECTS = libvtv_init.lo >> libvtv_stubs_la_LIBADD = >> libvtv_stubs_la_SOURCES = libvtv_stubs.c >> libvtv_stubs_la_OBJECTS = libvtv_stubs.lo >> >> as well as the lines: >> >> SOURCES = $(libsupc___la_SOURCES) $(libsupc__convenience_la_SOURCES) \ >> libvtv_init.c libvtv_stubs.c >> >> >> >> I don't know where it's getting those source file names, but they're >> wrong. I went in and removed the "lib" prefix from them, but I hadn't >> noticed that it had made them ".c" files instead of ".cc" files. If >> you know how to fix the .am file so that it doesn't generate these >> bogus & wrong source files in the .in file, I would appreciate your >> sharing with me... > > > Hmmm, never, ever, edit the Makefile.in file. And if you do edit it, > for goodness sakes tell us. But never edit it in the first place. > >> libvtv_init_la_SOURCES = libvtv_init.c > > automake came up with that because it is the default SOURCES for a > library. It means that you didn't define the required SOURCES > variable. You can see the name of that SOURCE variable from the line > that automake introduced: it's libvt_init_la_SOURCES. > > Ian
Rename IDENTIFIER_NODE in a plugin
Hello, I am in the process of writing a plugin that parses the header files of a C library using GCC, walks the AST in GENERIC format, and translates to C code for a foreign function interface (for LuaJIT). Many libraries internally use different C type names than those part of the API, using the C preprocessor for name mangling. I would like to rename certain tree nodes back to their known API name, before generating the C output code. How does one reassign the IDENTIFIER_POINTER of an IDENTIFIER_NODE? How is the memory of the identifier string allocated and freed? I have looked at build_string() in tree.c, but this function seems to apply only to STRING_CST nodes. There are also the functions make_node_stat() and build*_stat(), but I cannot find any call to these functions with tree code IDENTIFIER_NODE. I would be thankful for any pointers. Peter
Re: Ada bootstrap broken?
> Right, there's no explicit dependencies for seh_init.o at all, although > this is not something new. Has something changed recently in the way > e.g. system.h or similar are generated/handled that would explain this > change in behavior? No changes as far as I know, but maybe Diego got a brand new box. :-) > I guess we should in any case go ahead and add explicit deps for seh_init.o? > Eric, would you mind have a shot at it? OK, I'm going to audit the dependencies (env.o is missing, initialize.o is incomplete, etc) and install something shortly. -- Eric Botcazou
Re: Ada bootstrap broken?
On Tue, Oct 30, 2012 at 2:04 PM, Eric Botcazou wrote: >> Right, there's no explicit dependencies for seh_init.o at all, although >> this is not something new. Has something changed recently in the way >> e.g. system.h or similar are generated/handled that would explain this >> change in behavior? > > No changes as far as I know, but maybe Diego got a brand new box. :-) It's not brand new, but it's fairly recent. My parallel makes are -j24. I think it was happening at -j12 as well. >> I guess we should in any case go ahead and add explicit deps for seh_init.o? >> Eric, would you mind have a shot at it? > > OK, I'm going to audit the dependencies (env.o is missing, initialize.o is > incomplete, etc) and install something shortly. Thanks! Diego.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
jakub, i am hoping to get the rest of my wide integer conversion posted by nov 5. I am under some adverse conditions here: hurricane sandy hit her pretty badly. my house is hooked up to a small generator, and no one has any power for miles around. So far richi has promised to review them. he has sent some comments, but so far no reviews.Some time after i get the first round of them posted, i will do a second round that incorporates everyones comments. But i would like a little slack here if possible.While this work is a show stopper for my private port, the patches address serious problems for many of the public ports, especially ones that have very flexible vector units.I believe that there are significant set of latent problems currently with the existing ports that use ti mode that these patches will fix. However, i will do everything in my power to get the first round of the patches posted by nov 5 deadline. kenny On 10/29/2012 01:56 PM, Jakub Jelinek wrote: Status == I'd like to close the stage 1 phase of GCC 4.8 development on Monday, November 5th. If you have still patches for new features you'd like to see in GCC 4.8, please post them for review soon. Patches posted before the freeze, but reviewed shortly after the freeze, may still go in, further changes should be just bugfixes and documentation fixes. Quality Data Priority # Change from Last Report --- --- P1 23 + 23 P2 77 + 8 P3 85 + 84 --- --- Total 185 +115 Previous Report === http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html The next report will be sent by me again, announcing end of stage 1.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
On 10/30/12, Diego Novillo wrote: > On Mon, Oct 29, 2012 at 1:56 PM, Jakub Jelinek wrote: >> Status >> == >> >> I'd like to close the stage 1 phase of GCC 4.8 development >> on Monday, November 5th. If you have still patches for new features >> you'd >> like to see in GCC 4.8, please post them for review soon. Patches >> posted before the freeze, but reviewed shortly after the freeze, may >> still go in, further changes should be just bugfixes and documentation >> fixes. > > I will be committing the VEC overhaul soon. With any luck this week, > but PCH and gengtype are giving me a lot of grief. I have three remaining bitmap patches and the recently approved is_a/symtab/cgraph patch. However, Alexandre Oliva has a patch for bootstrap failure that is biting me. I can either incorporate it into my patches or wait for his patch and then submit. Comments? -- Lawrence Crowl
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Hi Jakub, My function multiversioning patch is being reviewed and I hope to get this in by Nov. 5. Thanks, -Sri. On Mon, Oct 29, 2012 at 10:56 AM, Jakub Jelinek wrote: > Status > == > > I'd like to close the stage 1 phase of GCC 4.8 development > on Monday, November 5th. If you have still patches for new features you'd > like to see in GCC 4.8, please post them for review soon. Patches > posted before the freeze, but reviewed shortly after the freeze, may > still go in, further changes should be just bugfixes and documentation > fixes. > > > Quality Data > > > Priority # Change from Last Report > --- --- > P1 23 + 23 > P2 77 + 8 > P3 85 + 84 > --- --- > Total 185 +115 > > > Previous Report > === > > http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html > > The next report will be sent by me again, announcing end of stage 1.
Re: GCC 4.8.0 Status Report (2012-10-29), Stage 1 to end soon
Hi Jakub, My -fopt-info pass filtering patch (http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02704.html) is being reviewed and I hope to get this in by Nov. 5 for inclusion in gcc 4.8.0. Thanks, Sharad On Mon, Oct 29, 2012 at 10:56 AM, Jakub Jelinek wrote: > Status > == > > I'd like to close the stage 1 phase of GCC 4.8 development > on Monday, November 5th. If you have still patches for new features you'd > like to see in GCC 4.8, please post them for review soon. Patches > posted before the freeze, but reviewed shortly after the freeze, may > still go in, further changes should be just bugfixes and documentation > fixes. > > > Quality Data > > > Priority # Change from Last Report > --- --- > P1 23 + 23 > P2 77 + 8 > P3 85 + 84 > --- --- > Total 185 +115 > > > Previous Report > === > > http://gcc.gnu.org/ml/gcc/2012-03/msg00011.html > > The next report will be sent by me again, announcing end of stage 1.
Re: Rename IDENTIFIER_NODE in a plugin
On Tue, Oct 30, 2012 at 01:39:59PM -0400, Peter Colberg wrote: > How does one reassign the IDENTIFIER_POINTER of an IDENTIFIER_NODE? My question does not make sense, since identifiers are immutable. I found an alternative solution used throughout the GCC code: DECL_NAME(decl) = get_identifier(name) get_identifier is mentioned in the documentation as well… http://gcc.gnu.org/onlinedocs/gccint/Identifiers.html#Identifiers Peter
