Re: Status of GCC 6 on x86_64 (Debian)
On 2016.02.03 at 01:13 +0100, Matthias Klose wrote: > On 22.01.2016 08:27, Matthias Klose wrote: > >On 22.01.2016 06:09, Martin Michlmayr wrote: > >>In terms of build failures, I reported 520 bugs to Debian. Most of them > >>were new GCC errors or warnings (some packages use -Werror and many > >>-Werror=format-security). > >> > >>Here are some of the most frequent errors see: > > > >[...] > >Martin tagged these issues; https://wiki.debian.org/GCC6 has links with these > >bug searches. > > Now added the issues with the gcc6-unknown tag, including packages with > build failures in running the test suites, which might point out wrong-code > issues. Looks like Google Mock (of googletest) invokes undefined behavior (member call on null "this" pointer). So potentially all packages that use googletest in their testsuite may be affected. I've opened: https://github.com/google/googletest/issues/705 -- Markus
[ANN] build2 - C++ build toolchain
Hi, build2 is an open source, cross-platform toolchain for building and packaging C++ code. It includes a build system, package manager, and repository web interface. We've also started cppget.org, a public repository of open source C++ packages. This is the first alpha release and currently it is more of a technology preview rather than anything that is ready for production. We have tested this version on various Linux'es, Mac OS, and FreeBSD. There is no Windows support yet (but cross-compilation is supported). The project's page is: https://build2.org For those who need to see examples right away, here is the introduction: https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml Enjoy, Boris
Re: GCC-Bridge: A Gimple Compiler targeting the JVM
Manuel> Everything is possible! Not sure how hard it would be, though. As Manuel> said, GJC "gcj". Manuel> the Java FE, was doing something similar sometime ago, but Manuel> it has perhaps bit-rotted now. It used to, but when we moved to using ecj for parsing java source, we removed (IIRC) the bytecode generator. Note that it only ever accepted trees generated by the java front end. You couldn't compile trees from other front ends to java byte code. If you wanted that you had to resort to a more extreme measure like mips2java. Tom
Help! Regarding bug 49973
Hi ! I am new to gcc. I would like to solve bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 (Bug 49973 - Column numbers count special characters as multiple columns ). Can somebody guide me? I tried to debug gcc under gdb. I think I have to change code in c-parser.c -- Thanks and Regards, Prasad Ghangal
'current' in URLs of mailing list archives not redirecting to 2016-02
FYI, https://gcc.gnu.org/ml/gcc/current/ currently redirects to https://gcc.gnu.org/ml/gcc/2016-01/ instead of https://gcc.gnu.org/ml/gcc/2016-02/ Other GCC mailing lists also redirect to 2016-01, instead of 2016-02. Keith
Author map correction and additions
Having reviewed entries in the author map for the git conversion that don't correspond directly to current /etc/passwd entries I think the following correction should be made: alanm = Alan Matsuoka (not Alan Modra, at least for the commits I looked at) In addition, at least the following ten committers who are new since the map was created need to be added: afanfa = Alessandro Fanfarillo afomin = Alexander Fomin alahay01 = Alan Hayward andris = Andris Pavenis claziss = Claudiu Zissulescu evandro = Evandro Menezes kelvin = Kelvin Nilsen lkrupp = Louis Krupp ssaraswati = Sujoy Saraswati wilco = Wilco Dijkstra -- Joseph S. Myers jos...@codesourcery.com
gcc-4.9-20160203 is now available
Snapshot gcc-4.9-20160203 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160203/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 233112 You'll find: gcc-4.9-20160203.tar.bz2 Complete GCC MD5=6e4c989968e32d4ad89a8c9a4c108509 SHA1=5dc8d5977755f2c2282f742f86d9be849365a8dc Diffs from 4.9-20160127 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
Snapshots
Thankyou for providing snapshots for those of us who really like gcc, I've been using gcc-5.3 for a while now and it is a pleasure. Many thanks.
Re: Help! Regarding bug 49973
On Thu, 2016-02-04 at 02:31 +0530, Prasad Ghangal wrote: > Hi ! > I am new to gcc. I would like to solve bug > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 (Bug 49973 - > Column > numbers count special characters as multiple columns ). Can somebody > guide me? > > I tried to debug gcc under gdb. I think I have to change code in c > -parser.c Most of gcc's code to handle source locations is in libcpp; specifically: libcpp/include/line-map.h and libcpp/line-map.c but there's also: gcc/input.c I think the routine you'd need to look at is expand_location, which is called by: #define LOCATION_COLUMN(LOC)((expand_location (LOC)).column) Most of the code uses columns as a count of *bytes*, starting at 1. I think the sanest approach may be to retain this idea (store it all as byte counts), but to just fixup the column number when printing the: "foo.c:LINE:COLUMN: error: foo" line (i.e. to treat it as a presentation layer thing, rather than a model thing, if that helps). This string is built by diagnostic_build_prefix in gcc/input.c. I imagine that diagnostic-show-locus.c might need some fixing up as well; it prints the bytes in the input lines, without attempting to convert them to any encoding (using the cache of source lines in input.c). You might want to try putting a breakpoint on diagnostic_show_locus; this is the routine the prints the source code when an error/warning fires; you can go up the stack to see where the diagnostic originated, and how diagnostics get printed. Hope this is helpful; good luck! Dave
Re: Help! Regarding bug 49973
On 03/02/16 21:01, Prasad Ghangal wrote: Hi ! I am new to gcc. I would like to solve bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 (Bug 49973 - Column numbers count special characters as multiple columns ). Can somebody guide me? I tried to debug gcc under gdb. I think I have to change code in c-parser.c I think this should be fixed in libcpp, probably in lex.c, but maybe other places also. A good testcase to start with would be: /* ñ /* */ /* a /* */ cc1 -Wcomment prog.cc:1:7: warning: "/*" within comment [-Wcomment] /* ñ /* */ ^ prog.cc:2:6: warning: "/*" within comment [-Wcomment] /* a /* */ ^ Both locations should point to column 6. Look for places where column info is converted to source_location (linemap_position_for_column or linemap_position_for_line_and_colum). Figure out where the column info got the wrong value. Use something like wcwidth() to measure the width of non-ASCII characters and get the right width of 'ñ'. Unfortunately, GCC 6 seems to be broken for the above testcase (https://gcc.gnu.org/PR69664). Revision 229665 seems fine. Cheers, Manuel.
Help porting to lra
I am trying to enable lra for my vliw architecture and I am encountering a problem of "max number of generated reload insns". The problem seems elementary but I don't see the correction. Consider r1 =r2+r3 s1=r1+r4 call func(r3) r5=s2+r1 where s registers are pseudo registers which ira maps to callee saved registers and r registers are pseudo registers which ira maps to caller saved registers. The inheritance pass sees that r1 is still live across a call so it generates a spill using split_reg. Call_save_p is true so it spills to a pseudo register which ends up getting the same hard register assignment as r1. Therefore nothing is solved, the new register is also live across the call. The call to the emit_spill_move looks like it is expecting a memory destination but it is in fact receiving a pseudo register. Did I miss some kind of hook that makes the spill go to the stack? Reload gets it right. Thanks, Shmeel
