Re: typos
On Wed, Jul 03, 2013 at 12:41:42AM +0200, Veres Lajos wrote: Hi, I wrote a small misspell finder/fixer script and when I have a little spare time I clean OS projects with it. (https://github.com/vlajos/misspell_fixer) I ran it on this repository: svn://gcc.gnu.org/svn/gcc/trunk The patch is around 800kb. What is the best way to handle this modifications? I mean most of the modifications are in the comments and in the documentations, but a code-review is needed anyway. The script itself isn't enough intelligent. So how could I smooth the way to land these modifications? Thanks: I am writing similar tool, that checks more style issues. I could try to integrate that. My idea is run this as pre-commit hook, separate comments from diff, check it with aspell and print misspelings in standard output so user can filter them.
Re: typos
On Wed, 3 Jul 2013, Ondrej Bilka wrote: On Wed, Jul 03, 2013 at 12:41:42AM +0200, Veres Lajos wrote: Hi, I wrote a small misspell finder/fixer script and when I have a little spare time I clean OS projects with it. (https://github.com/vlajos/misspell_fixer) I ran it on this repository: svn://gcc.gnu.org/svn/gcc/trunk The patch is around 800kb. What is the best way to handle this modifications? I mean most of the modifications are in the comments and in the documentations, but a code-review is needed anyway. The script itself isn't enough intelligent. So how could I smooth the way to land these modifications? I am writing similar tool, that checks more style issues. I could try to integrate that. My idea is run this as pre-commit hook, separate comments from diff, check it with aspell and print misspelings in standard output so user can filter them. Classic spellchekers are not really efficient for finding typos in program sources. There are too many false positives. Anyway can I help somehow? And if the script will be done you should run it for the whole codebase. Otherwise the issues won't be fixed until anybody touches them. -- Veres Lajos vla...@gmail.com +36 20 438 5909
Re: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0
On 3 July 2013 02:41, Nathan Ridge wrote: Lots of warnings like this: ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally defined but not used [-Wunused-local-typedefs] when building 1.54.0 with gcc-4.8.1 (fedora f19) This warning is new in GCC 4.8, and I have been seeing a ton of them not just in boost, but in every codebase I've built. It was new in GCC 4.7, http://gcc.gnu.org/gcc-4.7/changes.html It affects Boost more than most code because of the prevalent use of concept checks and static assertions which are usually implemented using typedefs but only conditionally compiled. I keep being surprised noone's disabled it in gcc.jam yet.
Re: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0
On 3 July 2013 02:41, Nathan Ridge wrote: Lots of warnings like this: ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally defined but not used [-Wunused-local-typedefs] when building 1.54.0 with gcc-4.8.1 (fedora f19) This warning is new in GCC 4.8, and I have been seeing a ton of them not just in boost, but in every codebase I've built. It was new in GCC 4.7, http://gcc.gnu.org/gcc-4.7/changes.html It affects Boost more than most code because of the prevalent use of concept checks and static assertions which are usually implemented using typedefs but only conditionally compiled. I keep being surprised noone's disabled it in gcc.jam yet. CC'ing the gcc folks. That's not very helpful because posting to the Boost list is subscription only (you'll have two copies of this mail, because the first one I sent from an address subscribed to the GCC list but not this one.)
Re: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0
On 3 July 2013 09:32, Jonathan Wakely jwakely.bo...@kayari.org wrote: I keep being surprised noone's disabled it in gcc.jam yet. That wouldn't work for headers, as they get included when building with other build systems. Since this is new, I guess we can use pragmas to disable the warning, but that's a pain.
Re: typos
Hi, On Wed, Jul 03, 2013 at 09:55:14AM +0200, Veres Lajos wrote: On Wed, 3 Jul 2013, Ondrej Bilka wrote: On Wed, Jul 03, 2013 at 12:41:42AM +0200, Veres Lajos wrote: Hi, I wrote a small misspell finder/fixer script and when I have a little spare time I clean OS projects with it. (https://github.com/vlajos/misspell_fixer) I ran it on this repository: svn://gcc.gnu.org/svn/gcc/trunk The patch is around 800kb. What is the best way to handle this modifications? I mean most of the modifications are in the comments and in the documentations, but a code-review is needed anyway. The script itself isn't enough intelligent. So how could I smooth the way to land these modifications? I am writing similar tool, that checks more style issues. I could try to integrate that. My idea is run this as pre-commit hook, separate comments from diff, check it with aspell and print misspelings in standard output so user can filter them. Classic spellchekers are not really efficient for finding typos in program sources. There are too many false positives. Anyway can I help somehow? And if the script will be done you should run it for the whole codebase. Otherwise the issues won't be fixed until anybody touches them. perhaps you should be aware that there are people who prefer exactly that, though the discussions so far have been about formatting/whitespace problems only. The reason is simpler history browsing which such changes complicate for little gain (I personally can cope with it but I see the point). On the other hand, I think that this would matter much less for lines where there are only comments. So I'd suggest cherry-picking these and submitting fixes in them. If the patch is large, split it into a number of patches for easier review. If there are errors in identifiers etc. I assume that needs to be handled on case by case basis, although some related cases can certainly be dealt with together (and it would upset history a bit so there might even be opposition to that). Thanks, Martin
RE: [boost] lots of warning with gcc-4.8.1 + boost-1.54.0
On 3 July 2013 02:41, Nathan Ridge wrote: Lots of warnings like this: ./boost/bind/arg.hpp:37:22: warning: typedef ‘T_must_be_placeholder’ locally defined but not used [-Wunused-local-typedefs] when building 1.54.0 with gcc-4.8.1 (fedora f19) This warning is new in GCC 4.8, and I have been seeing a ton of them not just in boost, but in every codebase I've built. It was new in GCC 4.7, http://gcc.gnu.org/gcc-4.7/changes.html I stand corrected. (What's new in 4.8 is it being included in -Wall, which is why I never noticed it in 4.7). It affects Boost more than most code because of the prevalent use of concept checks and static assertions which are usually implemented using typedefs but only conditionally compiled. I've seen spews of that warning for other large projects, such as clang or wxWidgets, not just boost. Would GCC consider removing it from -Wall? CC'ing the gcc folks. That's not very helpful because posting to the Boost list is subscription only (you'll have two copies of this mail, because the first one I sent from an address subscribed to the GCC list but not this one.) My apologies. Regards, Nate
Re: typos
On Wed, 3 Jul 2013, Martin Jambor wrote: And if the script will be done you should run it for the whole codebase. Otherwise the issues won't be fixed until anybody touches them. perhaps you should be aware that there are people who prefer exactly that, though the discussions so far have been about formatting/whitespace problems only. The reason is simpler history browsing which such changes complicate for little gain (I personally can cope with it but I see the point). On the other hand, I think that this would matter much less for lines where there are only comments. So I'd suggest cherry-picking these and submitting fixes in them. If the patch is large, split it into a number of patches for easier review. If there are errors in identifiers etc. I assume that needs to be handled on case by case basis, although some related cases can certainly be dealt with together (and it would upset history a bit so there might even be opposition to that). Around 99% of the typos are in comments and documentations a few of them are only in function/variable names (living code). I think it is not really history obtrusive. I will create a small subset for preview and send it for reviewing. (I would not do the whole before getting a green signal... It could take me at least 4-5 hours to review the whole patch...) -- Veres Lajos vla...@gmail.com +36 20 438 5909
Re: Git mirror: asan branch
Hi! On Wed, 3 Jul 2013 00:18:17 +0200, Andreas Schwab sch...@linux-m68k.org wrote: Thomas Schwinge tho...@codesourcery.com writes: If I configure my local Git checkout of the GCC Git mirror to include all branches, per http://gcc.gnu.org/wiki/GitMirror#Fetching_all_branches, then I get: fatal: refs/remotes/origin/asan tracks both refs/heads/asan and refs/remotes/asan Is that a local problem of mine, or a glitch in the gcc.gnu.org Git repository configuration? It's a bug in the remotes configuration. The two remotes should be stored into different namespaces (eg refs/remotes/origin/heads/* and refs/remotes/origin/remotes/*), instead of trying to merge them together. OK, that of course works, but from the wiki page I got the idea that it explicitly was meant to merge these together. So assuming this used to work in the past, I wonder what so that it no longer does; such as Git allowing such duplicates merging in the past, and/or was the intersection of refs/remotes/* and refs/heads/* meant to be the empty set (then I assume the merging would work, too), but no longer is? Grüße, Thomas pgp_ptpHtlMiu.pgp Description: PGP signature
Re: Git mirror: asan branch
On 07/03/2013 02:47 AM, Thomas Schwinge wrote: OK, that of course works, but from the wiki page I got the idea that it explicitly was meant to merge these together. So assuming this used to work in the past, I wonder what so that it no longer does; such as Git allowing such duplicates merging in the past, and/or was the intersection of refs/remotes/* and refs/heads/* meant to be the empty set (then I assume the merging would work, too), but no longer is? Hmm, it looks like I wrote that up without actually doing it myself, oops. I'll correct the wiki. Jason
GNU Tools Cauldron 2013 - Registrations are now closed (plus FAQ)
An update on this year's Cauldron. We have reached the maximum number of attendees that we can accept. Registrations are now closed. If you still wish to attend, contact us at tools-cauldron-ad...@googlegroups.com. We have started a waiting list and will let you know if a slot opens up If you had registered but will no longer be able to attend, please let us know so we can free up that slot for someone else. Some miscellaneous notes for recent questions: - The first night, we will meet at the Computer History Museum (http://www.computerhistory.org/directions/). Registration starts at 18:30. There will be a buffet dinner from 19:00 to 21:00. - Public transit directions from the Hotel Avante to the Google Campus are available online (e.g., http://goo.gl/maps/uKMUH) - The conference will be held at Building 1200 (1200 Charleston Rd, Mountain View). We will be using the conference rooms Tambourine and Triangle. - We will likely be able to record all the presentations. More details to follow. - If you are presenting, you may bring your laptop or a usb stick with your presentation in pdf format. There is wireless connectivity available. Diego.
Remove the __GXX_EXPERIMENTAL_CXX0X__?
While thinking about C++ n3694 feature test macros I noticed we still define __GXX_EXPERIMENTAL_CXX0X__ macro in c-family/c-cppbuiltin.c. We got rid of all uses of it in libstdc++. I propose we get rid of it here too. User's shouldn't be relying on it. No? OTOH, it may have been a proxy for __cplusplus for users for a good while. People may still be using it even if the library no longer uses it. What do folks think?
Error: no such instruction: `eovq -32(%rbp),%rdx'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, With gcc-4.7-20130629 and binutils-2.23.2 I'm getting Error: no such instruction: `eovq -32(%rbp),%rdx' There was no such issue with May' gcc snapshot and binutils-2.22. Is it a binutils-specific problem? Which version of binutils is known to work well with gcc-4.7-20130629 ? Thanks, - - D. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJR1JpTAAoJENwm3+sbf/pMvYoH/2/eao48G2782OaR3654uvJU xdFODidyTMFQXDIF3KXqYFl1AplPN5q95Te71RiAuuqyZLcIjPP3QzrYprgqmtaW RaOLYZ+qHjBlaBK7R8nsERZEGw+C2wcafHah9SFYTTJJWRl2kdita+z/KytlGPlc qhpv64sT0nSeQxDzLca2bzEmveIYfXM/FdPC9GD8tH5tMKeKawwaqN4pnKR9Y9DM 9LyRKWW/CcjisJrrks2UotrlcMuyfw92VWYEj4G80ildDA3ISLfgeX3z3z9lK688 ugmJxKxghuzr988MILPXzqsFI5+0OF3OVqg+7Mc5Rl6A9HnRFj16fj+c+OtAJB4= =fivA -END PGP SIGNATURE-
Re: Remove the __GXX_EXPERIMENTAL_CXX0X__?
On Wed, 3 Jul 2013, Ed Smith-Rowland wrote: While thinking about C++ n3694 feature test macros I noticed we still define __GXX_EXPERIMENTAL_CXX0X__ macro in c-family/c-cppbuiltin.c. We got rid of all uses of it in libstdc++. I propose we get rid of it here too. User's shouldn't be relying on it. No? OTOH, it may have been a proxy for __cplusplus for users for a good while. People may still be using it even if the library no longer uses it. What do folks think? Please keep it. Removing it won't gain you anything, and people do rely on it. -- Marc Glisse
Re: Error: no such instruction: `eovq -32(%rbp),%rdx'
On Wed, Jul 3, 2013 at 2:40 PM, Dmitry Mikushin dmi...@kernelgen.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, With gcc-4.7-20130629 and binutils-2.23.2 I'm getting Error: no such instruction: `eovq -32(%rbp),%rdx' There was no such issue with May' gcc snapshot and binutils-2.22. Is it a binutils-specific problem? Which version of binutils is known to work well with gcc-4.7-20130629 ? I assume it is x86-64. Do you have a testcase? I couldn't find anything in GCC x86 backend to generate eovq. Do you have a typo in asm statement? -- H.J.
Re: Remove the __GXX_EXPERIMENTAL_CXX0X__?
On Wed, Jul 3, 2013 at 4:39 PM, Ed Smith-Rowland 3dw...@verizon.net wrote: While thinking about C++ n3694 feature test macros I noticed we still define __GXX_EXPERIMENTAL_CXX0X__ macro in c-family/c-cppbuiltin.c. We got rid of all uses of it in libstdc++. I propose we get rid of it here too. User's shouldn't be relying on it. No? OTOH, it may have been a proxy for __cplusplus for users for a good while. People may still be using it even if the library no longer uses it. What do folks think? Deprecate it for 4.9.x. Remove it later. We don't need to keep around this macro which has been obsolete for at least two releases. -- Gaby
Re: typos
On Wed, 3 Jul 2013, Veres Lajos wrote: Around 99% of the typos are in comments and documentations a few of them are only in function/variable names (living code). I think it is not really history obtrusive. I will create a small subset for preview and send it for reviewing. (I would not do the whole before getting a green signal... It could take me at least 4-5 hours to review the whole patch...) http://lavela.hu/gcc.misspell-fixer.20130704.notrevised.patch.bz2 This is the patch generated by the misspell fixer script. (This is the patch against the whole tree.) I did NOT reviewed it yet. What do you think could it be usefull? Should I review the file? Probably I could remove some false positives, but I am not a C expert. -- Veres Lajos vla...@gmail.com +36 20 438 5909
Re: Error: no such instruction: `eovq -32(%rbp),%rdx'
Dmitry Mikushin dmi...@kernelgen.org writes:
Error: no such instruction: `eovq -32(%rbp),%rdx'
That's only a one-bit error away from movq ...
('m' = 0x6d = 0b 0110 1101,
'e' = 0x65 = 0b 0110 0101)
Maybe run memory tester overnight?
(This is from personal experience -- I had a bad stick of RAM that
caused all sorts of bizarre compile problems. I eventually isolated
the problem and replaced the DIMM; the compile problems went away.)
Good luck!
Best regards,
Anthony Foiani
La mejor base de datos de Mexico
La mejor base de datos Mexicana a su alcance 10 millones de registros mayores de edad 765 mil empresas con datos completos Y por si fuera poco: 3 suites de software para windows y Mac 150 servidores SMTP ilimitados para envio masivo de correos Videotutoriales de uso Todo actualizado a Julio 2013 Lo invitamos a conocer lo que podemos hacer a favor de su empresa en: http://fur.ly/9mwh
[Bug fortran/57791] Waste work in gfc_check_pointer_assign()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57791 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Po-Chun Chang from comment #0) Suggested patch In method gfc_check_pointer_assign() in expr.c, the loop on line 3763 should break immediately after warn is set to true. All the iterations after warn set to true do not perform any useful work, at best they just set warn again to true. I concur. (Note that the nesting depth is rather shallow [one or two, rarely three and essentially never four or more] and only pointer comparisons are done, which is computationally cheap. Thus, the current version doesn't waste many cycles.)
[Bug tree-optimization/56982] [4.8 Regression] Bad optimization with setjmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982 --- Comment #15 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Mikael Pettersson from comment #14) Your example is invalid C. Referring to WG14 n1494.pdf (there may be more recent C1x documents, but it's the one I had available right now): - you violate 7.13.1.1 which specifies where setjmp() may be called, an assignment statement is not one of the permitted contexts - more importantly, your auto variable a is not volatile-qualified, which means that its value is indeterminate after the longjmp (7.13.2.1). Please fix these issues and check again if it yields wrong results. Thanks for pointing that out. When I add volatile to the auto variable, the code is OK.
[Bug ada/57795] New: Fail cross building Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57795 Bug ID: 57795 Summary: Fail cross building Ada Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: alexpux at gmail dot com I try to build i686 multilib mingw toolchain with Ada from linux x86_64 toolchain. First I build cross-compiler linux-x64 - mingw-x32. Next I try to build mingw-x32 native toolchain from cross and get fail building libada on last step. make[2]: Entering directory `/home/alexx/work32/mingw32-gcc/gnattools' # gnattools1-re make -C ../gcc/ada/tools -f ../Makefile \ CC=i686-w64-mingw32-gcc CFLAGS=-g -O2 -D__USE_MINGW_ACCESS -W -Wall LDFLAGS=-static-libstdc++ -static-libgcc -Wl,--stack,12582912 ADAFLAGS=-gnatpg -gnata ADA_CFLAGS= INCLUDES=-I. -I.. -I../.. -I/home/alexx/src/gcc-4.8.1/gcc/ada -I/home/alexx/src/gcc-4.8.1/gcc/config -I/home/alexx/src/gcc-4.8.1/gcc/../include -I/home/alexx/src/gcc-4.8.1/gcc ADA_INCLUDES=-I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/adalib/../adainclude -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/adalib/ -I. -I/home/alexx/src/gcc-4.8.1/gcc/ada exeext=.exe fsrcdir=/home/alexx/src/gcc-4.8.1/gcc srcdir=/home/alexx/src/gcc-4.8.1/gcc GNATMAKE=gnatmake GNATLINK=gnatlink GNATBIND=gnatbind TOOLSCASE=cross LIBGNAT= INCLUDES= \ gnatmake-re gnatlink-re make[3]: Entering directory `/home/alexx/work32/mingw32-gcc/gcc/ada/tools' gnatmake -j0 -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/adalib/../adainclude -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/adalib/ -I. -I/home/alexx/src/gcc-4.8.1/gcc/ada -u sdefault --GCC=i686-w64-mingw32-gcc gnatmake: objects up to date. gnatmake -j0 -c -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/adalib/../adainclude -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/adalib/ -I. -I/home/alexx/src/gcc-4.8.1/gcc/ada gnatmake --GCC=i686-w64-mingw32-gcc -g -O2 -D__USE_MINGW_ACCESS -W -Wall -gnatpg -gnata i686-w64-mingw32-gcc -c -I./ -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/adalib/../adainclude -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/adalib/ -I. -I/home/alexx/src/gcc-4.8.1/gcc/ada -g -O2 -D__USE_MINGW_ACCESS -W -Wall -gnatpg -gnata -I- /home/alexx/src/gcc-4.8.1/gcc/ada/osint.adb i686-w64-mingw32-gcc -c -I./ -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/adalib/../adainclude -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/adalib/ -I. -I/home/alexx/src/gcc-4.8.1/gcc/ada -g -O2 -D__USE_MINGW_ACCESS -W -Wall -gnatpg -gnata -I- /home/alexx/src/gcc-4.8.1/gcc/ada/prj.adb osint.adb:3182:07: warning: types for unchecked conversion have different sizes gnatmake: /home/alexx/src/gcc-4.8.1/gcc/ada/osint.adb compilation error make[3]: *** [gnatmake-re] Error 4 make[3]: Leaving directory `/home/alexx/work32/mingw32-gcc/gcc/ada/tools' make[2]: *** [gnattools-cross] Error 2 make[2]: Leaving directory `/home/alexx/work32/mingw32-gcc/gnattools' make[1]: *** [all-gnattools] Error 2 make[1]: Leaving directory `/home/alexx/work32/mingw32-gcc' make: *** [all] Error 2 I see that gcc got wrong headers and libs (I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/adalib/../adainclude -I/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/adalib/) from linux native toolchain. But it can be pointed to headers and libs from cross toolchain. I do this operation with different gcc - 4.7.3 and 4.8.1 with the same result. My dirty hack to resolve it is to copy ada headers and libs from cross toolchain to native toolchain. Then build finishing fine. Regards, Alexey.
[Bug ada/57772] Bug box in gnat_to_gnu, at ada/gcc-interface/trans.c:5778 on legal Ada 2005 quantifier expression with exponentiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57772 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.7.3 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Fixed in GCC 4.7.x and later.
[Bug tree-optimization/57796] New: AVX2 gather vectorization: code bloat and reduction of performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796 Bug ID: 57796 Summary: AVX2 gather vectorization: code bloat and reduction of performance Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vincenzo.innocente at cern dot ch At least in scimark2 sparse matrix multiplication the use of gather instructions ends in code bloat and a substantial reduction of performance the test below has been performed on a INTEL 4770K at fixed freq of 3.495GHz using gcc version 4.9.0 20130630 (experimental) [trunk revision 200570] (GCC) the easiest is just to download scimark2 compile and run as mkdir scimark2TMP cd scimark2TMP wget http://math.nist.gov/scimark2/scimark2_1c.zip . unzip scimark2_1c.zip gcc -v gcc -Ofast -march=corei7-avx *.c -lm ./a.out 5 | grep Sparse matmult ./a.out -large 5 | grep Sparse matmult gcc -Ofast -march=corei7-avx -mavx2 -mfma *.c -lm ./a.out 5 | grep Sparse matmult ./a.out -large 5 | grep Sparse matmult gcc -Ofast -march=corei7-avx -S SparseCompRow.c -o SparseCompRow_avx.s gcc -Ofast -march=corei7-avx -mavx2 -mfma -S SparseCompRow.c -o SparseCompRow_avx2.s wc SparseCompRow_avx.s wc SparseCompRow_avx2.s my results gcc version 4.9.0 20130630 (experimental) [trunk revision 200570] (GCC) Sparse matmult Mflops: 2245.34(N=1000, nz=5000) Sparse matmult Mflops: 2030.24(N=10, nz=100) Sparse matmult Mflops: 1842.84(N=1000, nz=5000) Sparse matmult Mflops: 1754.18(N=10, nz=100) 113 269 2156 SparseCompRow_avx.s 289 778 5910 SparseCompRow_avx2.s
[Bug middle-end/57786] Waste work in distribute_notes()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57786 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-03 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Confirmed, thanks for spotting it.
[Bug middle-end/57786] Waste work in distribute_notes()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57786 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Taking care of it.
[Bug c++/57793] [4.7/4.8/4.9 Regression] ICE wiith bitfields in get_bit_range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57793 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-03 Summary|Cross-Compiler Templates|[4.7/4.8/4.9 Regression] |and Bitfields Ask to Report |ICE wiith bitfields in |Problem |get_bit_range Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- I can confirm this on x86_64-linux -m32, no need for a cross-compiler. I doubt however that it's a C++ front-end issue.
[Bug c++/57794] using keyword for function alias doesn't work with plus suffix return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57794 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-07-03 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- I'm not at all convinced this is legal code. Can you please attach a *self-contained* snippet?
[Bug tree-optimization/50789] Gather vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50789 --- Comment #13 from vincenzo Innocente vincenzo.innocente at cern dot ch --- I just submitted a specific bug-report as PR57796
[Bug c++/57794] using keyword for function alias doesn't work with plus suffix return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57794 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- It's not valid code, [] introduces a lambda expression, not a function type, but a lambda expression must have a body. Maybe you mean: using to_lower_fn_ptr = auto (input_base_type, const std::locale) - input_base_type; which compiles fine.
[Bug tree-optimization/57796] AVX2 gather vectorization: code bloat and reduction of performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||kyukhin at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- The gather vectorization has been written without access to hw and perhaps some tuning might be needed. But I don't have enough info how it should be tuned, what the exact costs are.
[Bug c++/56037] Spurious syntax error triggered before ambiguity resolution of type-id
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56037
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
Reduced:
struct T
{
T(int, int);
};
int main()
{
static const int zero = 0;
(T(int(zero), int(zero)));
}
[Bug c++/12333] [DR 272] Explicit call to MyClass::~MyClass() not allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12333 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #15 from Paolo Carlini paolo.carlini at oracle dot com --- Looking into this.
[Bug fortran/57785] [4.7/4.8/4.9 Regression] DOT_PRODUCT error with constant complex array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57785 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Known to work||4.4.3 Summary|DOT_PRODUCT error with |[4.7/4.8/4.9 Regression] |constant complex array |DOT_PRODUCT error with ||constant complex array Known to fail||4.5.3, 4.7.3, 4.9.0 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Patch: http://gcc.gnu.org/ml/fortran/2013-07/msg4.html (It's a regression since GCC 4.5 [r148243, which added compile-time simplification]. However, GCC 4.5 and 4.6 are no longer maintained.)
[Bug other/57797] New: configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 Bug ID: 57797 Summary: configure --enable-languages=c builds libstdc++-v3 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: earnie at users dot sourceforge.net When specifying --enable-languages=c the libstdc++-v3 directory is being configured and built. I had to remove the directory from the source to prevent the build. Here is the full set of configure options: --prefix=/mingw --enable-languages=c --disable-sjlj-exceptions --with-dwarf2 --enable-shared --disable-win32-registry --disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs --host=i686-pc-mingw32 --target=i686-pc-mingw32 --build=i686-pc-mingw32 --disable-multilib --without-pic --with-gnu-ld --with-gnu-as --without-readline --disable-libstdcxx --enable-lto --enable-multilib --enable-multiarch --disable-tls --enable-threads --disable-cxx --enable-assembly --enable-fft --disable-nls --disable-rpath
[Bug c++/57775] default argument for template parameter error for friend definition in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57775 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com --- The problem still exists for gcc 4.9.0 20130616 (experimental). It sounds a bit familiar to me, though.
[Bug fortran/57798] New: Incorrect handling of sum over first dimension of a product of automatic arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57798 Bug ID: 57798 Summary: Incorrect handling of sum over first dimension of a product of automatic arrays Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: stephan.kramer at imperial dot ac.uk The test code below results in a segfault evaluating the sum() in the print statement. This is compiling with gfortran 4.8.1 (4.8.1-4ubuntu1 on Ubuntu Saucy) without any flags. If bounds checking is switched on (-fbounds-check) I get a bounds violation error with a random number reported for one of the bounds: Fortran runtime error: Dimension 1 of array 'func' has extent 2 instead of 4196256 Is this possibly related to the optimisation requested in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36841 ? program test implicit none call sub(2, 11) contains function func(m, n) integer, intent(in):: m,n real, dimension(m, n):: func func = 0.0 end function func subroutine sub(m, n) integer, intent(in):: m, n real, dimension(m,n):: y y = 0.0 print *, sum(y*func(m,n), dim=1) end subroutine sub end program test
[Bug bootstrap/57797] configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Component|other |bootstrap --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Earnie from comment #0) --disable-build-poststage1-with-cxx You know this doesn't work for GCC 4.8, right?
[Bug fortran/57798] [4.8/4.9 Regression] Incorrect handling of sum over first dimension of a product of automatic arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57798 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-03 Summary|Incorrect handling of sum |[4.8/4.9 Regression] |over first dimension of a |Incorrect handling of sum |product of automatic arrays |over first dimension of a ||product of automatic arrays Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed. It appeared between revision 190090 (2012-08-02: OK) and 190271 (2012-08-09: wrong bounds). Valgrind reports ==70092== Invalid write of size 4 ==70092==at 0x10DD1: func.1887 (pr57798.f90:12) ==70092==by 0x10C32: sub.1867 (pr57798.f90:21) ==70092==by 0x10D2F: MAIN__ (pr57798.f90:4) ==70092==by 0x10E1A: main (pr57798.f90:4) ==70092== Address 0x100440480 is 0 bytes inside a block of size 1 alloc'd ==70092==at 0x100012679: malloc (vg_replace_malloc.c:266) ==70092==by 0x10C0B: sub.1867 (pr57798.f90:21) ==70092==by 0x10D2F: MAIN__ (pr57798.f90:4) ==70092==by 0x10E1A: main (pr57798.f90:4)
[Bug target/57363] IBM long double: adding NaN and number raises inexact exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57363 --- Comment #2 from Adhemerval Zanella azanella at linux dot vnet.ibm.com --- You are correct and I meant in my first comment QNaN for the NaN work. And I believe the patch is still correct: for IBM long double SNaN will be represented by first double being the NaN (the second double is ignored) and the first sum (z = a + c) will trigger exception if any.
[Bug target/57777] [4.7/4.8/4.9 Regression] Python module fails compilation with -march=core-avx2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #9 from Julian Ospald julian.ospald at googlemail dot com --- patch tested with gcc-4.9.0_alpha20130505, works as well
[Bug middle-end/55030] [4.8 Regression]: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os (et al)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55030 --- Comment #19 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Eric Botcazou from comment #18) Let's just reapply r192676 on the mainline. We just need to make sure that the failures on i686 don't reappear. Done now less than half a year later! (Just r192676, no dse.c or cselib.c changes, leaving that to interested parties.)
[Bug java/57799] New: ICE in jcf-parse.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57799
Bug ID: 57799
Summary: ICE in jcf-parse.c
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
Assignee: unassigned at gcc dot gnu.org
Reporter: hearn at google dot com
Whilst compiling a JAR containing the following snippet of code, I get a
segfault that looks like this:
#0 0x00535541 in rewrite_reflection_indexes (arg=0x7fffd5f0) at
../../gcc-4.8.1/gcc/java/jcf-parse.c:754
#1 0x0050c7d7 in make_class_data (type=0x75f82dc8) at
../../gcc-4.8.1/gcc/java/class.c:2193
#2 0x0050cbb1 in finish_class () at
../../gcc-4.8.1/gcc/java/class.c:2255
#3 0x0053946b in parse_class_file () at
../../gcc-4.8.1/gcc/java/jcf-parse.c:1661
#4 0x0053a37a in parse_zip_file_entries () at
../../gcc-4.8.1/gcc/java/jcf-parse.c:2101
#5 0x00539dd0 in java_parse_file () at
../../gcc-4.8.1/gcc/java/jcf-parse.c:1931
#6 0x008e60b7 in compile_file () at ../../gcc-4.8.1/gcc/toplev.c:543
#7 0x008e7fed in do_compile () at ../../gcc-4.8.1/gcc/toplev.c:1864
#8 0x008e8158 in toplev_main (argc=22, argv=0x7fffdd18) at
../../gcc-4.8.1/gcc/toplev.c:1940
#9 0x00e9b620 in main (argc=22, argv=0x7fffdd18) at
../../gcc-4.8.1/gcc/main.c:36
I debugged it a bit, the offending class looks like this:
public class ProtobufParserMessageType extends MessageLite {
public interface ListenerMessageType extends MessageLite {
public void messageReceived(ProtobufParserMessageType handler,
MessageType msg);
public void connectionOpen(ProtobufParserMessageType handler);
public void connectionClosed(ProtobufParserMessageType handler);
}
}
The crashing class is the inner ProtobufParser$Listener.class file.
I can send a complete JAR to someone privately if you'd like to debug this
further. I tried compiling the ProtobufParser$Listener.class file independently
like this:
gcj -c -o x ProtobufParser\$Listener.class
and no crash :(
[Bug fortran/57800] New: Waste work in gfc_match_call()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57800 Bug ID: 57800 Summary: Waste work in gfc_match_call() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu The problem appears in revision 200588 in version 4.9. In method gfc_match_call() in gcc/fortran/match.c, the loop on line 4189 should break immediately after i is set to 1. All the iterations after i set to 1 do not perform any useful work, at best they just set i again to 1.
[Bug fortran/57801] New: Waste work in resolve_variable()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57801 Bug ID: 57801 Summary: Waste work in resolve_variable() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu The problem appears in revision 200588 in version 4.9. In method resolve_variable() in gcc/fortran/resolve.c, the loop on line 4908 should break immediately after seen is set to true. All the iterations after seen set to true do not perform any useful work, at best they just set seen again to true.
[Bug fortran/57802] New: Waste work in set_loop_bounds()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57802 Bug ID: 57802 Summary: Waste work in set_loop_bounds() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu The problem appears in revision 200588 in version 4.9. In method set_loop_bounds() in gcc/fortran/trans-array.c, the loop on line 4456 should break immediately after nonoptional_arr is set to true. All the iterations after nonoptional_arr set to true do not perform any useful work, at best they just set nonoptional_arr again to true.
[Bug target/57748] ICE on ARM with -mfloat-abi=softfp -mfpu=neo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 philb at gnu dot org changed: What|Removed |Added CC||philb at gnu dot org --- Comment #4 from philb at gnu dot org --- I was able to get Khem's testcase to provoke a crash at: 4761 gcc_assert (TREE_CODE (offset) == INTEGER_CST); Apparently OFFSET is: plus_expr 0x76380d48 type integer_type 0x76c6 sizetype public unsigned SI size integer_cst 0x76c5c080 constant 32 unit size integer_cst 0x76c5c0a0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x76c6 precision 32 min integer_cst 0x76c5c0c0 0 max integer_cst 0x76c4b000 4294967295 arg 0 mult_expr 0x76380d20 type integer_type 0x76c6 sizetype arg 0 nop_expr 0x76381b80 type integer_type 0x76c6 sizetype arg 0 ssa_name 0x76374900 type integer_type 0x76c605e8 int var var_decl 0x7637a428 jdef_stmt j_22 = PHI 0(4), j_31(7) version 22 arg 1 integer_cst 0x76c5c600 constant 16 arg 1 integer_cst 0x76c5c120 type integer_type 0x76c6 sizetype constant 8
[Bug middle-end/57803] New: Waste work in gfc_build_dummy_array_decl()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57803 Bug ID: 57803 Summary: Waste work in gfc_build_dummy_array_decl() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu The problem appears in revision 200588 in version 4.9. In method gfc_build_dummy_array_decl() in gcc/fortran/trans-decl.c, the loop on line 978 should break immediately after packed is set to PACKED_PARTIAL. All the iterations after packed set to PACKED_PARTIAL do not perform any useful work, at best they just set packed again to PACKED_PARTIAL.
[Bug fortran/57804] New: Waste work in gfc_trans_transfer()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57804 Bug ID: 57804 Summary: Waste work in gfc_trans_transfer() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu The problem appears in revision 200588 in version 4.9. In method gfc_trans_transfer() in gcc/fortran/trans-io.c, the loop on line 2261 should break immediately after seen_vector is set to true. All the iterations after seen_vector set to true do not perform any useful work, at best they just set seen_vector again to true.
[Bug middle-end/57805] New: Waste work in write_roots()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57805 Bug ID: 57805 Summary: Waste work in write_roots() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu The problem appears in revision 200588 in version 4.9. In method write_roots() in gcc/gengtype.c, the loop on line 4682 should break immediately after skip_p is set to 1. All the iterations after skip_p set to 1 do not perform any useful work, at best they just set skip_p again to 1.
[Bug middle-end/57806] New: Waste work in propagate_nothrow()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57806 Bug ID: 57806 Summary: Waste work in propagate_nothrow() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu The problem appears in revision 200588 in version 4.9. In method propagate_nothrow() in gcc/ipa-pure-const.c, the loop on line 1432 should break immediately after can_throw is set to true. All the iterations after can_throw set to true do not perform any useful work, at best they just set can_throw again to true.
[Bug target/57807] New: Compile failure with __builtin_ia32_unpcklpd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57807
Bug ID: 57807
Summary: Compile failure with __builtin_ia32_unpcklpd
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jleahy+gcc at gmail dot com
The following code sample will not compile when -masm=intel is set:
(eg. gcc -masm=intel -c foo.c)
typedef double __v2df __attribute__((__vector_size__(16)));
typedef double __m128d __attribute__((__vector_size__(16), __may_alias__));
__m128d _mm_unpacklo_pd(__m128d __A, __m128d __B) {
return (__m128d)__builtin_ia32_unpcklpd((__v2df)__A, (__v2df)__B);
}
It generates movhpd xmm0, XMMWORD PTR [rbp-32], which should be movhpd xmm0,
QWORD PTR [rbp-32].
[Bug libstdc++/57808] New: operators == and != for regex_token_iterator need to be const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57808 Bug ID: 57808 Summary: operators == and != for regex_token_iterator need to be const Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: chasonr at newsguy dot com In libstdc++-v3/include/bits/regex.h, the methods operator== and operator!= for regex_token_iterator are not declared const. This is not consistent with the C++11 standard, section 28.12.2, which specifies these operators to be declared const.
[Bug libstdc++/57808] operators == and != for regex_token_iterator need to be const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57808 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-03 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- operator* and operator- too. Let's do the change, certainly cannot hurt, but a lot more is still needed.
[Bug middle-end/57809] New: Waste work in omega_eliminate_red()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57809 Bug ID: 57809 Summary: Waste work in omega_eliminate_red() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu The problem appears in revision 200588 in version 4.9. In method omega_eliminate_red() in gcc/omega.c, the loop on line 2592 should break immediately after red_found is set to 1. All the iterations after red_found set to 1 do not perform any useful work, at best they just set red_found again to 1. There are three more similar problems in the same file gcc/omega.c: 1. omega_problem_has_red_equations(): the loop on line 4854 should break immediately after result is set to true. 2. omega_problem_has_red_equations(): the loop on line 4907 should break immediately after result is set to true. 3. omega_query_variable(): the loop on line 5252 should break immediately after coupled is set to true.
[Bug rtl-optimization/57810] New: Waste work in validate_const_int()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57810 Bug ID: 57810 Summary: Waste work in validate_const_int() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu The problem appears in revision 200588 in version 4.9. In method validate_const_int() in gcc/read-rtl.c, the loop on line 804 should break immediately after valid is set to 0. All the iterations after valid set to 0 do not perform any useful work, at best they just set valid again to 0.
[Bug middle-end/57809] Waste work in omega_eliminate_red()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57809 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- I think you mean wasted
[Bug middle-end/57811] New: Waste work in find_reloads()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811 Bug ID: 57811 Summary: Waste work in find_reloads() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu The problem appears in revision 200588 in version 4.9. In method find_reloads() in gcc/reload.c, the loop on line 3324 should break immediately after badop is set to 1. All the iterations after badop set to 1 do not perform any useful work, at best they just set badop again to 1. Similar problem also appears in the same method find_reloads() in line 4641. The loop should break immediately after ok is set to 0.
[Bug rtl-optimization/57812] New: Waste work in computed_jump_p()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57812 Bug ID: 57812 Summary: Waste work in computed_jump_p() Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pchang9 at cs dot wisc.edu CC: nistor1 at illinois dot edu The problem appears in revision 200588 in version 4.9. In method computed_jump_p() in gcc/rtlanal.c, the loop on line 2801 should break immediately after has_use_labelref is set to 1. All the iterations after has_use_labelref set to 1 do not perform any useful work, at best they just set has_use_labelref again to 1.
[Bug libstdc++/57779] vector insert fails to diagnose iterators pointing into *this in debug mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57779 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||frs.dumont at gmail dot com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Maybe Francois is interested.
[Bug c++/12567] [Core/253] g++ fails to recognize ill-formed-ness of initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12567 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |SUSPENDED Summary|g++ fails to recognize |[Core/253] g++ fails to |ill-formed-ness of |recognize ill-formed-ness |initializers|of initializers --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- It seems to me that we are not rejecting these snippets because we are implementing the tentative resolution of DR Core/253: /* If default-initialization leaves part of TYPE uninitialized, returns a DECL for the field or TYPE itself (DR 253). */ tree default_init_uninitialized_part (tree type)
[Bug bootstrap/57797] configure --enable-languages=c builds libstdc++-v3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57797 --- Comment #2 from Earnie earnie at users dot sourceforge.net --- (In reply to Jonathan Wakely from comment #1) (In reply to Earnie from comment #0) --disable-build-poststage1-with-cxx You know this doesn't work for GCC 4.8, right? No, I wasn't aware of it. I copied it from a previous 4.7.2 build via ``gcc -v''. But that shouldn't cause the issue. I notice in the target folder i686-pc-mingw32/libgcc/config.log file that --enable-languages is modified to include c++ and lto. Why would that happen?
[Bug fortran/57800] Wasted work in gfc_match_call()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57800 --- Comment #1 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30433 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30433action=edit Suggested patch
[Bug fortran/57801] Wasted work in resolve_variable()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57801 --- Comment #1 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30434 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30434action=edit Suggested patch
[Bug fortran/57802] Wasted work in set_loop_bounds()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57802 --- Comment #1 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30435 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30435action=edit Suggested patch
[Bug fortran/57803] Wasted work in gfc_build_dummy_array_decl()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57803 --- Comment #1 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30436 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30436action=edit Suggested patch
[Bug fortran/57804] Waste work in gfc_trans_transfer()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57804 --- Comment #1 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30437 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30437action=edit Suggested patch
[Bug middle-end/57805] Wasted work in write_roots()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57805 --- Comment #1 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30438 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30438action=edit Suggested patch
[Bug middle-end/57806] Wasted work in propagate_nothrow()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57806 --- Comment #1 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30439 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30439action=edit Suggested patch
[Bug rtl-optimization/57810] Wasted work in validate_const_int()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57810 --- Comment #1 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30440 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30440action=edit Suggested patch
[Bug rtl-optimization/57812] Wasted work in computed_jump_p()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57812 --- Comment #1 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30441 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30441action=edit Suggested patch
[Bug c++/57771] g++ misinterprets in static_cast
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57771 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jul 3 20:20:30 2013 New Revision: 200647 URL: http://gcc.gnu.org/viewcvs?rev=200647root=gccview=rev Log: PR c++/57771 * parser.c (cp_parser_postfix_expression) case RID_STATCAST Temporarily set parser-greater_than_is_operator_p for cp_parser_expression and restore from saved value afterwards. * g++.dg/template/arg9.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/arg9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog Author: jakub Date: Wed Jul 3 20:22:16 2013 New Revision: 200648 URL: http://gcc.gnu.org/viewcvs?rev=200648root=gccview=rev Log: PR c++/57771 * parser.c (cp_parser_postfix_expression) case RID_STATCAST Temporarily set parser-greater_than_is_operator_p for cp_parser_expression and restore from saved value afterwards. * g++.dg/template/arg9.C: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/template/arg9.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/parser.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug middle-end/57811] Wasted work in find_reloads()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811 --- Comment #1 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30442 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30442action=edit Suggested patch for loop at line 3324
[Bug target/57777] [4.7 Regression] Python module fails compilation with -march=core-avx2 -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] Python |Python module fails |module fails compilation |compilation with|with -march=core-avx2 -O3 |-march=core-avx2 -O3 | --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Jul 3 20:23:38 2013 New Revision: 200649 URL: http://gcc.gnu.org/viewcvs?rev=200649root=gccview=rev Log: PR target/5 * config/i386/predicates.md (vsib_address_operand): Disallow SYMBOL_REF or LABEL_REF in parts.disp if TARGET_64BIT flag_pic. * gcc.target/i386/pr5.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr5.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/predicates.md trunk/gcc/testsuite/ChangeLog Author: jakub Date: Wed Jul 3 20:24:19 2013 New Revision: 200650 URL: http://gcc.gnu.org/viewcvs?rev=200650root=gccview=rev Log: PR target/5 * config/i386/predicates.md (vsib_address_operand): Disallow SYMBOL_REF or LABEL_REF in parts.disp if TARGET_64BIT flag_pic. * gcc.target/i386/pr5.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr5.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/i386/predicates.md branches/gcc-4_8-branch/gcc/testsuite/ChangeLog Fixed for 4.8.2+ so far.
[Bug rtl-optimization/57812] Wasted work in computed_jump_p()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57812 --- Comment #2 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30443 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30443action=edit Suggested patch
[Bug middle-end/57811] Wasted work in find_reloads()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811 --- Comment #2 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30444 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30444action=edit Suggested patch for loop at line 3324
[Bug middle-end/57811] Wasted work in find_reloads()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57811 --- Comment #3 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30445 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30445action=edit Suggested patch for loop at line 4641
[Bug middle-end/57809] Wasted work in omega_eliminate_red()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57809 --- Comment #2 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30446 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30446action=edit Suggested patch for loop at line 2594
[Bug middle-end/57809] Wasted work in omega_eliminate_red()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57809 --- Comment #3 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30447 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30447action=edit Suggested patch for loop at line 4856
[Bug middle-end/57809] Wasted work in omega_eliminate_red()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57809 --- Comment #4 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30448 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30448action=edit Suggested patch for loop at line 4907
[Bug middle-end/57809] Wasted work in omega_eliminate_red()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57809 --- Comment #5 from Po-Chun Chang pchang9 at cs dot wisc.edu --- Created attachment 30449 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30449action=edit Suggested patch for loop at line 5252
[Bug c/57813] New: Change of global variable ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57813
Bug ID: 57813
Summary: Change of global variable ignored
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.oertwig at gmail dot com
Target: avr51
Created attachment 30450
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30450action=edit
Source code relating to the problem
Hi, I assume this to be a bug in how the compiler optimizes its code.
Unfortunately, I don't know enough about how the gcc works to narrow down the
source of the problem.
If it's me (or my code), please tell me what I am doing wrong.
Basically I have a function operating on a global variable. This function calls
another function which changes this global variable. But the changed value is
not used by the calling function afterwards.
Task * Task_getNextReady()
{
uint8_t priority;
if (taskInfo.ready[0]) priority = 0;
else if (taskInfo.ready[1]) priority = 1;
else if (taskInfo.ready[2]) priority = 2;
else if (taskInfo.ready[3]) priority = 3;
else if (taskInfo.ready[4]) priority = 4;
else if (taskInfo.ready[5]) priority = 5;
else if (taskInfo.ready[6]) priority = 6;
else priority = 7;
// Before call to function: taskInfo.ready[priority] == task6
// After call to function: taskInfo.ready[priority] == task7
// Return value = 10
taskInfo.ready[priority]-wakeTime = Task_enforceTimeslice(priority);
// Changed task6-wakeTime = 10
// Unchanged task7-wakeTime
// Return value is task7, which is correct.
return taskInfo.ready[priority];
}
I guess i could solve this by making the variable volatile, but I don't think
that this would be correct.
[Bug c/57813] Change of global variable ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57813 --- Comment #1 from Daniel Oertwig daniel.oertwig at gmail dot com --- Created attachment 30451 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30451action=edit Disassembly of the relating parts (from *.elf file, i.e. after linking)
[Bug c/57813] Change of global variable ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57813 --- Comment #2 from Daniel Oertwig daniel.oertwig at gmail dot com --- Oh, I am compiling with: CFLAGS := CFLAGS += -Os CFLAGS += -funsigned-char CFLAGS += -funsigned-bitfields CFLAGS += -fpack-struct CFLAGS += -fshort-enums CFLAGS += -ffreestanding CFLAGS += -Wall -Wextra CFLAGS += -Wstrict-prototypes CFLAGS += -Wundef CFLAGS += -Wsign-compare CFLAGS += -std=gnu99 #-std=c99 CFLAGS += -g3 -gdwarf-2 -pg CFLAGS += -fstack-usage LDFLAGS := LDFLAGS += -Wl,--relax using avr-gcc. There are no warnings.
[Bug c/57813] Change of global variable ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57813 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- taskInfo.ready[priority]-wakeTime = Task_enforceTimeslice(priority); This is the same as: (*taskInfo.ready[priority]).wakeTime = Task_enforceTimeslice(priority); Which means either the compiler can read the value of taskInfo.ready[priority] before or after the function call to Task_enforceTimeslice because there is no sequence point between them.
[Bug fortran/48244] iso-c-binding support missing on NetBSD (with patch)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48244 Kai-Uwe Eckhardt kuehro at gmx dot de changed: What|Removed |Added Attachment #23752|0 |1 is obsolete|| --- Comment #3 from Kai-Uwe Eckhardt kuehro at gmx dot de --- Created attachment 30452 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30452action=edit Add netbsd-stdint.h to config.gcc for gcc-4.9
[Bug fortran/48244] iso-c-binding support missing on NetBSD (with patch)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48244 --- Comment #4 from Kai-Uwe Eckhardt kuehro at gmx dot de --- I have updated the patch for snapshot 4.9-20130630. If Gerald Pfeifer agrees to create a copy of freebsd-stdint.h and to keep the copyright line as is, then this could be done easily by someone with commit right.
[Bug c/57813] Change of global variable ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57813
Daniel Oertwig daniel.oertwig at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #4 from Daniel Oertwig daniel.oertwig at gmail dot com ---
Task * Task_getNextReady()
{
uint8_t priority;
if (taskInfo.ready[0]) priority = 0;
else if (taskInfo.ready[1]) priority = 1;
else if (taskInfo.ready[2]) priority = 2;
else if (taskInfo.ready[3]) priority = 3;
else if (taskInfo.ready[4]) priority = 4;
else if (taskInfo.ready[5]) priority = 5;
else if (taskInfo.ready[6]) priority = 6;
else priority = 7;
time_t delay = Task_enforceTimeslice(priority);
Task * next = taskInfo.ready[priority];
next-wakeTime = delay;
return next;
}
This code solves the issue, using the correct value of the global variable.
Please tell me if I am wrong, but I think this code should be equivalent to the
original code.
(Task_enforceTimeslice is not declared as pure, I checked just to be sure)
[Bug c/57813] Change of global variable ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57813 --- Comment #5 from Daniel Oertwig daniel.oertwig at gmail dot com --- (In reply to Andrew Pinski from comment #3) taskInfo.ready[priority]-wakeTime = Task_enforceTimeslice(priority); This is the same as: (*taskInfo.ready[priority]).wakeTime = Task_enforceTimeslice(priority); Which means either the compiler can read the value of taskInfo.ready[priority] before or after the function call to Task_enforceTimeslice because there is no sequence point between them. Shouldn't the compiler recognize that enforceTimeslice is altering the global variable?
[Bug c/57813] Change of global variable ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57813 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Daniel Oertwig from comment #5) (In reply to Andrew Pinski from comment #3) taskInfo.ready[priority]-wakeTime = Task_enforceTimeslice(priority); This is the same as: (*taskInfo.ready[priority]).wakeTime = Task_enforceTimeslice(priority); Which means either the compiler can read the value of taskInfo.ready[priority] before or after the function call to Task_enforceTimeslice because there is no sequence point between them. Shouldn't the compiler recognize that enforceTimeslice is altering the global variable? No because without sequence point the left hand side or right hand side can be done first.
[Bug c/57813] Change of global variable ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57813 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Daniel Oertwig from comment #5) (In reply to Andrew Pinski from comment #3) taskInfo.ready[priority]-wakeTime = Task_enforceTimeslice(priority); This is the same as: (*taskInfo.ready[priority]).wakeTime = Task_enforceTimeslice(priority); Which means either the compiler can read the value of taskInfo.ready[priority] before or after the function call to Task_enforceTimeslice because there is no sequence point between them. Shouldn't the compiler recognize that enforceTimeslice is altering the global variable? The GCC code that could warn about this does not look within functions being called, so GCC does not know what enforeTimeslice is doing. Implementing this would require a substantial amount of work, and the current devs have their hands pretty full. Perhaps cppcheck or clang-analyzer can detect this case, but I wouldn't be surprised if they can't.
[Bug middle-end/57809] Wasted work in omega_eliminate_red()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57809 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Po-Chun Chang from comment #5) Created attachment 30449 [details] Suggested patch for loop at line 5252 Thanks for your patches. If you want to contribute to GCC, perhaps it would be better if you became an official contributor. Please see: http://gcc.gnu.org/contribute.html
[Bug c++/57793] [4.7/4.8/4.9 Regression] ICE with bitfields in get_bit_range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57793 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com --- I can confirm this as well restricted (only when using -m32) on my 64-bit mingw system, tested with gcc 4.9.0 20130616 (experimental)
[Bug target/57814] New: gcc.target/powerpc/pr46728-* test failures for eabi targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57814 Bug ID: 57814 Summary: gcc.target/powerpc/pr46728-* test failures for eabi targets Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: janis at gcc dot gnu.org CC: wschmidt at gcc dot gnu.org Target: powerpc-none-eabi, powerpc-none-eabispe Several of the tests added for PR46728 fail for powerpc-none-eabi and powerpc-none-eabispe. The tests all use -mpowerpc-gpopt; is that option expected to work for those targets? If not I can add directives to skip tests using that option for powerpc-*-eabi*; if it should work then I'll provide further information about test failures and internal compiler errors (segfaults). My testing has been for GCC mainline and the 4.8 branch. It would be nice if the compiler complained when -mpowerpc-gpopt is used with incompatible targets, but that idea was shot down in PR24913.
[Bug target/57814] gcc.target/powerpc/pr46728-* test failures for eabi targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57814 --- Comment #1 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Wed, 3 Jul 2013, janis at gcc dot gnu.org wrote: Several of the tests added for PR46728 fail for powerpc-none-eabi and powerpc-none-eabispe. The tests all use -mpowerpc-gpopt; is that option expected to work for those targets? If not I can add directives to skip tests using that option for powerpc-*-eabi*; if it should work then I'll provide further information about test failures and internal compiler errors (segfaults). If the compiler ICEs, that's a bug, whether or not the option is expected to work for the given target. So even if the tests are disabled, a bug should remain open in Bugzilla for the ICEs as long as those are unfixed.
[Bug c/57813] Change of global variable ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57813 --- Comment #8 from Daniel Oertwig daniel.oertwig at gmail dot com --- Ok, so: Is this behaviour part of the language or a bug in gcc? I could not find any documentation specifying that a sequence point should be inbetween the (side-effect) evaluation of the function call and the (value) evaluation of the assignment.
[Bug c/57813] Change of global variable ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57813 --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Daniel Oertwig from comment #8) Ok, so: Is this behaviour part of the language or a bug in gcc? I could not find any documentation specifying that a sequence point should be inbetween the (side-effect) evaluation of the function call and the (value) evaluation of the assignment. http://c-faq.com/expr/seqpoints.html http://en.wikipedia.org/wiki/Sequence_point
[Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
sgunderson at bigfoot dot com changed:
What|Removed |Added
CC||sgunderson at bigfoot dot com
--- Comment #6 from sgunderson at bigfoot dot com ---
Without knowing anything about the GCC internals here, I could perhaps also
point out that GCC should know that these have limited range. As a trivial
example:
int foo(int x)
{
int z = __builtin_ctz(x);
if (z 2000) {
return 1;
} else {
return 0;
}
}
There's no way this function can return anything but 0, and VRP should probably
be taught that. (I wonder if this would fix the unneccessary sign extension
too?)
[Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776 --- Comment #7 from sgunderson at bigfoot dot com --- Wait, sorry, someone's already pointed that out. Ignore me, then... I can at least confirm it still happens with GCC 4.8.1.
[Bug c++/57815] New: [c++11] Error spew on misspelled initializer lists
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57815
Bug ID: 57815
Summary: [c++11] Error spew on misspelled initializer lists
Product: gcc
Version: 4.7.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
[This is fixed in trunk. If the stable branch policy means it can't get
backported, then so be it. I'm filing the bug because this issue is *really*
annoying.]
This erroneous code:
// Adding 'struct misspelled {int a, bc[2];};' makes this compile
void func() {
misspelled object{1, {2, 3}};
}
Seems to throw the parser into an awful state. The 4.7 branch says:
brace_problem.cc: In function ‘void func()’:
brace_problem.cc:4:3: error: ‘misspelled’ was not declared in this scope
brace_problem.cc:4:14: error: expected ‘;’ before ‘object’
brace_problem.cc:5:1: error: expected ‘}’ at end of input
This isn't so bad in a program this short, but in a bigger program I'm getting
multiple pages of errors scattered around the file, so finding the actual
problem is a needle-in-a-haystack problem. If the offending code is inside a
class definition, then a bunch of the bogus errors are *before* the correct
one.
Trunk from today gets this right:
brace_problem.cc: In function ‘void func()’:
brace_problem.cc:4:3: error: ‘misspelled’ was not declared in this scope
misspelled object{1, {2, 3}};
^
