[Bug fortran/52916] [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52916 --- Comment #6 from Tobias Burnus 2012-04-15 05:52:58 UTC --- Author: burnus Date: Sun Apr 15 05:52:51 2012 New Revision: 186464 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186464 Log: 2012-04-14 Tobias Burnus PR fortran/52916 PR fortran/40973 * gfortran.h (symbol_attribute): Add public_used. * interface.c (check_sym_interfaces, check_uop_interfaces, gfc_check_interfaces): Set it. * resolve.c (resolve_typebound_procedure): Ditto. * trans-decl.c (build_function_decl): Use it. 2012-04-14 Tobias Burnus PR fortran/52916 PR fortran/40973 * gfortran.dg/public_private_module_3.f90: New. * gfortran.dg/public_private_module_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/public_private_module_3.f90 trunk/gcc/testsuite/gfortran.dg/public_private_module_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/40973] Mark PRIVATE module functions as STATIC to faciliate optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40973 --- Comment #6 from Tobias Burnus 2012-04-15 05:52:58 UTC --- Author: burnus Date: Sun Apr 15 05:52:51 2012 New Revision: 186464 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186464 Log: 2012-04-14 Tobias Burnus PR fortran/52916 PR fortran/40973 * gfortran.h (symbol_attribute): Add public_used. * interface.c (check_sym_interfaces, check_uop_interfaces, gfc_check_interfaces): Set it. * resolve.c (resolve_typebound_procedure): Ditto. * trans-decl.c (build_function_decl): Use it. 2012-04-14 Tobias Burnus PR fortran/52916 PR fortran/40973 * gfortran.dg/public_private_module_3.f90: New. * gfortran.dg/public_private_module_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/public_private_module_3.f90 trunk/gcc/testsuite/gfortran.dg/public_private_module_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/interface.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug c/52991] New: attribute packed broken on mingw32?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 Bug #: 52991 Summary: attribute packed broken on mingw32? Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: sher...@netfarm.it I've switched form mingw gcc 4.6.2 to 4.7.0 and I've noticed that attribute packed does not work anymore as expected, simple testcase: #include #include #include typedef struct st_tag { uint16_t head __attribute__ ((packed)); uint8_t type; uint16_t flags __attribute__ ((packed)); } st; int main(void) { st x; printf("Structure packing got %u offset, expected 3\n", (unsigned)((char*)&x.flags - (char*)&x)); return 0; } the generated asm is: movl$4, 4(%esp) movl$LC0, (%esp) call_printf the value is 3 in gcc 4.6.2 Using built-in specs. COLLECT_GCC=c:\mingw\bin\gcc-4.7.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.7.0/lto-wrapper.exe Target: i686-pc-mingw32 Configured with: ../gcc-4.7.0/configure --prefix=/mingw --disable-bootstrap --enable-lto --with-pkgversion=Sherpya --with-bugurl=http://oss.netfarm.it/ --target=i686-pc-mingw32 --enable-targets=i686-pc-mingw32 --with-tune=generic --with-cpu=i686 --disable-win32-registry --disable-shared --program-suffix=-4.7 --enable-version-specific-runtime-libs --enable-languages=c,c++ --disable-werror --enable-threads=win32 --with-dwarf2 --disable-nls Thread model: win32 gcc version 4.7.0 (Sherpya) I don't think save-temps output may be relevant
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #11 from davidxl 2012-04-15 04:09:53 UTC --- (In reply to comment #7) > > > are against it). I don't think there is any GCC contributor that is paid > > > to > > > improve GCC's diagnostics (am I wrong?). > > > > Right, but partially because it is a hard thing to do improve and the ROI is > > low. > > It is not *technically* hard. Anyone that knows C and a bit of C++ can fix > hundreds (if you know C++ well and have a some experience with the C++ parser, > you can probably fix thousands of bugs on your own, each fix taking no more > than a couple of hours of debugging and few minutes of programming). However, > it is time-consuming because of all the bureaucracy: copyright assignment, > setting up the environment, bootstrapping+testing, patch submission, patch > review, communication delays, style nits, changelogs nits, and updating the > testsuite. That is why even current contributors often don't bother with > one-liners, because all the associated tasks can make a one minute change > require days of effort. For many compiler hobbyists, the bureaucratic issues you mentioned don't exist yet before they start hacking on GCC FE. If the learning curve is steep and the interfaces are obscure, GCC will be less appealing to them. There is a difference between 'can do' and 'want to do'. > > > > This is very different from Clang, > > > where Chris obviously cares a great deal about Clang's diagnostics, and it > > > seems to be supported by a team in Apple (and in Google?). > > > > Yes, and in Google, but do you know why? Because it is easy to improve their > > diagnostics and benefit can be quickly seen. > > But why is it easy? For example, the C++ FE, although I don't like many of its > design decisions, is quite easy to hack. > Clang can be used to do lots of interesting stuff -- such as source code indexing (for semantic based code search), complicated automatic code refactoring etc. The Clang's design makes it possible because 1) source location information is well preserved; 2) information about macros are preserved; 3) there is no on the fly constant folding etc. > And I don't think this is the reason. GCC is obviously easy to hack for their > current developers, but they focus on different things than the Clang/LLVM > developers. The whole attitude is quite different, for better or worse, and in > terms of popularity, the LLVM crowd wins (of course, the GCC crowd may say > that > this is not a popularity contest, but if you want to attract new developers, > who now have a choice, then it is). > > > > However, there are a lot of them, and getting > > > patches reviewed and accepted requires herculean amounts of perseverance. > > > But > > > probably you can share with me more about your (or Googlers) thoughts on > > > the > > > latter, since you have the experience of submitting the same project to > > > both > > > LLVM and GCC. > > > > Infrastructure makes a big difference here -- see more about this below. > > Indeed, but my point is that moving to C++ does little (in my opinion) to fix > the infrastructure issues in GCC: dejagnu is awful, the wiki is unmaintained, > patch submission is a pain, patch review is a bottleneck, no automatic style > checks, useless obligatory changelogs, no marketing, poor documentation for > beginners, poor coordination with other projects (binutils, gdb, glibc), etc. > (and, worse, the expectation that new/non-paid contributors should take care > of > fixing these issues). > > > > > > > Nothing of the above gets fixed by switching to C++ or by having a clearly > > > defined AST... > > > > I think they are clearly related. > > In any case, I hope you are right, and the move to C++ helps. I imagine that > it > can help to attract more corporate contributors, who don't have to bother with > legal paperwork and are paid to do also boring bits. For sporadic and/or > non-paid contributors, there are other bigger issues to solve. Moving to C++ itself won't do anything useful -- it is the new design as a result of moving to C++ that will make a difference. David
[Bug libstdc++/52699] infinite loop generated with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52699 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Paolo Carlini 2012-04-15 02:15:17 UTC --- Fixed 4.7.1 and mainline.
[Bug libstdc++/52699] infinite loop generated with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52699 --- Comment #9 from paolo at gcc dot gnu.org 2012-04-15 02:14:45 UTC --- Author: paolo Date: Sun Apr 15 02:14:39 2012 New Revision: 186461 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186461 Log: 2012-04-14 Paolo Carlini PR libstdc++/52699 * include/bits/random.tcc (independent_bits_engine<>::operator()()) Avoid various overflows; use common_type on result_type and _RandomNumberEngine::result_type; avoid floating point computations; other smaller tweaks. * include/bits/random.tcc (uniform_int_distribution<>::operator()) Use common_type; assume _UniformRandomNumberGenerator::result_type unsigned; tidy. * include/bits/stl_algobase.h (__lg(unsigned), __lg(unsigned long), __lg(unsigned long long)): Add. Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/random.tcc branches/gcc-4_7-branch/libstdc++-v3/include/bits/stl_algobase.h
[Bug libstdc++/52699] infinite loop generated with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52699 --- Comment #8 from paolo at gcc dot gnu.org 2012-04-14 22:33:27 UTC --- Author: paolo Date: Sat Apr 14 22:33:22 2012 New Revision: 186456 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186456 Log: 2012-04-14 Paolo Carlini PR libstdc++/52699 * include/bits/random.tcc (independent_bits_engine<>::operator()()) Avoid various overflows; use common_type on result_type and _RandomNumberEngine::result_type; avoid floating point computations; other smaller tweaks. * include/bits/random.tcc (uniform_int_distribution<>::operator()) Use common_type; assume _UniformRandomNumberGenerator::result_type unsigned; tidy. * include/bits/stl_algobase.h (__lg(unsigned), __lg(unsigned long), __lg(unsigned long long)): Add. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/random.tcc trunk/libstdc++-v3/include/bits/stl_algobase.h
[Bug target/52990] New: bootstrap ia64 cross-compiler gcc (static C-only) includes a broken libgcc.a due to libunwind dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52990 Bug #: 52990 Summary: bootstrap ia64 cross-compiler gcc (static C-only) includes a broken libgcc.a due to libunwind dependencies Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: vap...@gentoo.org CC: toolch...@gentoo.org Target: ia64-linux-gnu when building up a cross-compiler for ia64, we do: - install binutils - install kernel/C-library headers - build a static C-only gcc compiler - install glibc - try to link a static ELF -> failure this is due to libgcc on ia64 being dependent on libunwind symbols. when shared libs are disabled, the libgcc.a ends up referring to __libunwind_xxx symbols which aren't provided in the non-shared case. specifically, we have: - ia64 forces t-unwind in config.gcc which adds -DUSE_LIBUNWIND_EXCEPTIONS - gcc/unwind-compat.c has a bunch of extern __libunwind_xxx decls - libgcc/Makefile.in adds unwind-compat.o to libgcc.a when enable_shared!=yes - gcc/config/ia64/unwind-ia64.c defines __libunwind_xxx aliases when SHARED - unwind-ia64.o is only added to libunwind.{a,so} and never libgcc.a so, the end libgcc.a gets unwind-compat.o which refers to __libunwind_xxx, but doesn't get unwind-ia64.o which could possibly define them, and even if it did, the aliases aren't enabled for static objects. looks like we could fix this in the t-glibc-libunwind file, when enable_shared is disabled, add the ia64 unwind objects to libgcc.a. additionally, have unwind-ia64.c key off of not just SHARED but also STATIC_ONLY for declaring the symbols, and have the t-glibc-unwind file build unwind-ia64.o with that.
[Bug c++/52637] [4.7/4.8 regression] ICE producing debug info for c++11 code using local class as template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52637 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.6.3 Keywords||ice-on-valid-code Last reconfirmed||2012-04-14 CC||jason at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Depends on||51650 Ever Confirmed|0 |1 Summary|ICE producing debug info|[4.7/4.8 regression] ICE |for c++11 code using|producing debug info for |templates/decltype/lambda |c++11 code using local ||class as template argument --- Comment #1 from Jason Merrill 2012-04-14 21:22:53 UTC --- Neither decltype nor lambda are needed for this bug, just use of a local type as a template parameter: template struct C { }; template void f(V v) { struct B {}; C c; } template void g(T t) { struct A { } a; f (a); } struct D { void h() { g(0); } }; This seems to be a result of the fix for PR 51650; we want to emit debug info about C, so B ends up on the limbo list. When we walk the limbo list we decide to emit f, so A ends up on the limbo list. But it gets added to the beginning, so the list walk never sees it, and when we get around to emitting the debug info for f it can't find the A to refer to, and ICEs. Before the patch for 51650 we didn't try to emit f to be context for B.
[Bug other/52989] New: Installation error on OS X (arm-eabi) cross-compiler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52989 Bug #: 52989 Summary: Installation error on OS X (arm-eabi) cross-compiler Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: eblot...@gmail.com While builing/installating GCC: the "make install" command fails to install two generated files - "linux-crt0" - on OS X host, while building a cross-compiler version for ARM-EABI target. The message error looks like the following: "install: /usr/local/homebrew/Cellar/gcc-arm-eabi/4.7.0/arm-eabi/lib/fpu/linux-crt0.o: No such file or directory" although sometimes "make" simply exits with an "Error 2" error message and no further info. I already encountered a similar issue with GCC 4.6.3, never with previous versions (4.6.0, 4.6.1 and 4.6.2 are ok) using the very same "configure" option switches on the very same host. With 4.6.3 however, there was no usable error message, so I give up trying to understand the issue. It seems that with 4.7.0, I can obtain a usable error message from the installation stage. On my system, the following directories are not created at installation stage, which in turn triggers the installation failure as "make install" attempts to copy the built linux-crt0.o files into non-existent destination directories: * /gcc-arm-eabi/4.7.0/arm-eabi/lib/fpu * /gcc-arm-eabi/4.7.0/arm-eabi/lib/fpu/interwork A simple workaround exists: creating the missing destination directories and restarting "make install" enables the installation stage to complete successfully. Host: Mac Book Pro Late 2008, Core 2 Duo 8 GiB, Lion 10.7.3 w/ 64 bits kernel $> uname -a Darwin arguel.eire 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64 $> echo $SHELL /bin/bash $> echo $BASH_VERSION 3.2.48(1)-release configure:4034: /usr/bin/llvm-gcc --version >&5 i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) configure:4034: /usr/bin/llvm-gcc -v >&5 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~22/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~22/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) Target: arm-eabi (not the linux EABI variant) Configure option switches: $ ../configure --prefix=/usr/local/homebrew/Cellar/gcc-arm-eabi/4.7.0 --target=arm-eabi --enable-shared --with-gnu-as --with-gnu-ld --with-newlib --enable-softfloat --disable-bigendian --disable-fpu --disable-underscore --enable-multilibs --with-float=soft --enable-interwork --enable-lto --enable-plugin --with-multilib-list=interwork --with-abi=aapcs --enable-languages=c,c++ --with-gmp=/usr/local/homebrew/Cellar/gmp/5.0.4 --with-mpfr=/usr/local/homebrew/Cellar/mpfr/3.1.0 --with-mpc=/usr/local/homebrew/Cellar/libmpc/0.9 --with-ppl=/usr/local/homebrew/Cellar/ppl/0.11.2 --with-cloog=/usr/local/homebrew/Cellar/cloog/0.17.0 --enable-cloog-backend=isl --disable-cloog-version-check --with-libelf=/usr/local/homebrew/Cellar/libelf/0.8.13 --with-gxx-include-dir=/usr/local/homebrew/Cellar/gcc-arm-eabi/4.7.0/arm-eabi/include --disable-debug --disable-__cxa_atexit Note: destination directory tree /usr/local/homebrew/* is R/W for the current user. /usr/local/homebrew/Cellar/gcc-arm-eabi/4.7.0 did not exist before building GCC. Let me know if you need more information
[Bug middle-end/38299] internal error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38299 --- Comment #8 from David O'Shea 2012-04-14 17:58:31 UTC --- (In reply to comment #7) Spoke too soon. Things just compiled slower and it took longer to get to the same failure, I was fooled.As it is, you have to fall all the way back to the -O option, and then add in -fXXX options from the -O2 list. The problematic item is in one of: -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec And appears to be either or both of: -fschedule-insns or -fschedule-insns2 The -O2 items below were removed because ARM-ELF 3.2.1 does not understand them: (They are newer -O2 items as documented in newer GCC man page). -fcrossjumping -finline-small-functions -fipa-sra -freorder-functions -fstrict-overflow -ftree-switch-conversion -ftree-pre -ftree-vrp -findirect-inlining I'm getting success with the below. This turns of instruction reordering optimizations=speed (but still uses common subexpression elimination = size). CXXFLAGS= -g -O -fgcse -fgcse-lm -fthread-jumps -falign-functions -falign-jumps -falign-loops -falign-labels -fcaller-saves -fcse-follow-jumps -fcse-skip-blocks -fdelete-null-pointer-checks -fexpensive-optimizations -foptimize-sibling-calls -fpeephole2 -fregmove -freorder-blocks -frerun-cse-after-loop -fstrict-aliasing
[Bug c++/52988] std::async not executed on function returning nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52988 --- Comment #3 from Jonathan Wakely 2012-04-14 17:40:18 UTC --- Slightly reduced testcase without #include using namespace std; nullptr_t returns_nullptr_t() { __builtin_puts("returns_nullptr_t"); return nullptr; } int returns_int() { __builtin_puts("returns_int"); return 22; } int main() { future fnp = async(returns_nullptr_t); //fnp.wait(); // The workaround. fnp.get(); future fi = async(returns_int); fi.get(); return 0; }
[Bug c++/52988] std::async not executed on function returning nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52988 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code CC||jason at gcc dot gnu.org Component|libstdc++ |c++ Known to fail||4.6.3, 4.8.0 --- Comment #2 from Jonathan Wakely 2012-04-14 17:29:52 UTC --- Jason, could ou take a look at this please? This looks like a G++ issue, doing something weird when nullptr_t is involved. Possibly assuming that since all nullptr_t values are the same there's no point calling a function to get one and it's valid to just return nullptr immediately. future::get() produces this: _Res std::future<_Res>::get() [with _Res = int] (struct future * const this) { struct __basic_future * D.117159; int D.117160; struct __basic_future * D.117161; struct _Result & D.117162; int & D.117163; type & D.117164; struct _Reset __reset; try { D.117159 = &this->D.52581; std::__basic_future::_Reset::_Reset (&__reset, D.117159); try { D.117161 = &this->D.52581; D.117162 = std::__basic_future::_M_get_result (D.117161); D.117163 = std::__future_base::_Result::_M_value (D.117162); D.117164 = std::move (D.117163); D.117160 = *D.117164; return D.117160; } finally { std::__basic_future::_Reset::~_Reset (&__reset); } } finally { __reset = {CLOBBER}; } } But even though they're generated from the same template future::get() looks like this, with no call to _M_get_result() before returning: _Res std::future<_Res>::get() [with _Res = std::nullptr_t] (struct future * const this) { struct __basic_future * D.117150; <<< Unknown tree: nullptr_type >>> D.117151; struct _Reset __reset; try { D.117150 = &this->D.52293; std::__basic_future::_Reset::_Reset (&__reset, D.117150); try { D.117151 = 0; return D.117151; } finally { std::__basic_future::_Reset::~_Reset (&__reset); } } finally { __reset = {CLOBBER}; } }
[Bug libstdc++/52988] std::async not executed on function returning nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52988 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-14 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely 2012-04-14 17:06:21 UTC --- strange ... I'm looking into it
[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976 --- Comment #8 from William J. Schmidt 2012-04-14 16:54:02 UTC --- Patch bootstraps and passes regressions; all SPEC tests build cleanly. Will submit today to gcc-patches.
[Bug middle-end/38299] internal error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38299 David O'Shea changed: What|Removed |Added CC||david.oshea at emulex dot ||com --- Comment #7 from David O'Shea 2012-04-14 16:51:46 UTC --- In playing with the -O2 and -O flags, it would appear to be that the -fgcse subflag of the -O2 flags causes the failure. So you can substitute the following and get the compiler to build the library -O2 -no-gcse. This builds a less great (no Global Common Subexpression Elimination) library, but it builds on 3.2.1... The result is a larger library, but at least it builds.
[Bug libstdc++/52988] New: std::async not executed on function returning nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52988 Bug #: 52988 Summary: std::async not executed on function returning nullptr_t Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: surfinthe...@yahoo.com Created attachment 27157 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27157 Sample code demonstrating bug and workaround. Given a function which returns a nullptr_t, the following appears to not call the function: future fnp = async(returns_nullptr_t); fnp.get(); For a function which returns an int, the behavior is as expected. A workaround is to call fnp.wait() before fnp.get(). In that case, the function is indeed called (and its side-effects are observed). The attached file demonstrates the bug clearly. When executed, one should see the output: returns_nullptr_t returns_int but only the second line shows. If the workaround is applied, then both lines show.
[Bug c++/52987] New: bogus expected ; before for undeclared type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52987 Bug #: 52987 Summary: bogus expected ; before for undeclared type Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: m...@gcc.gnu.org void foo(void) { x var; } manuel@gcc12:~/test2$ ~/trunk/186353/build/gcc/cc1plus ~/notdeclared.c void foo() /home/manuel/notdeclared.c:2:3: error: ‘x’ was not declared in this scope x var; ^ /home/manuel/notdeclared.c:2:5: error: expected ‘;’ before ‘var’ x var; ^ manuel@gcc12:~/test2$ clang ~/notdeclared.c /home/manuel/notdeclared.c:2:3: error: use of undeclared identifier 'x' x var; ^ 1 error generated. The "expected ";" before "var"" is bogus. The following patch removes it in this case: --- gcc/cp/parser.c (revision 186353) +++ gcc/cp/parser.c (working copy) @@ -5589,13 +5589,19 @@ cp_parser_postfix_expression (cp_parser while (true) { if (idk == CP_ID_KIND_UNQUALIFIED && TREE_CODE (postfix_expression) == IDENTIFIER_NODE && cp_lexer_next_token_is_not (parser->lexer, CPP_OPEN_PAREN)) - /* It is not a Koenig lookup function call. */ - postfix_expression - = unqualified_name_lookup_error (postfix_expression); + { + /* It is not a Koenig lookup function call. */ + postfix_expression = + unqualified_name_lookup_error (postfix_expression); + /* It is better to skip the rest and return here, because at +this point we don't know what this statement is. */ + cp_parser_skip_to_end_of_statement (parser); + return error_mark_node; + } /* Peek at the next token. */ token = cp_lexer_peek_token (parser->lexer); switch (token->type) Unfortunately, undeclared names can occur in many places besides statements, so it fails for things like: int foo(x var) { } I couldn't figure out how tell the context where we are called. :-(
[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976 William J. Schmidt changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #7 from William J. Schmidt 2012-04-14 15:11:43 UTC --- *** Bug 52980 has been marked as a duplicate of this bug. ***
[Bug middle-end/52980] [4.8 Regression] Many benchmarks in SPEC CPU 2000/2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52980 William J. Schmidt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #5 from William J. Schmidt 2012-04-14 15:11:43 UTC --- After further investigation, I'm indeed marking this as a duplicate of PR52976. Further information on fixes may be found there. *** This bug has been marked as a duplicate of bug 52976 ***
[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52976 --- Comment #6 from William J. Schmidt 2012-04-14 15:05:37 UTC --- The following patch fixes both reduced test cases and appears to fix the SPEC problems in PR52980 as well. Bootstrap/regression test in progress, and will then do a complete set of SPEC builds to be sure. The second problem involved a subtlety in the rank order of operands. When introducing the calls to __builtin_powi, I needed to fiddle with the resulting operand rank to ensure uses of the call result appear after the call. Dominique, please let me know whether this cleans up all your polyhedron tests without introducing new failures. Thanks! Index: gcc/tree-ssa-reassoc.c === --- gcc/tree-ssa-reassoc.c(revision 186393) +++ gcc/tree-ssa-reassoc.c(working copy) @@ -544,6 +544,28 @@ add_repeat_to_ops_vec (VEC(operand_entry_t, heap) reassociate_stats.pows_encountered++; } +/* Add an operand entry to *OPS for the tree operand OP, giving the + new entry a larger rank than any other operand already in *OPS. */ + +static void +add_to_ops_vec_max_rank (VEC(operand_entry_t, heap) **ops, tree op) +{ + operand_entry_t oe = (operand_entry_t) pool_alloc (operand_entry_pool); + operand_entry_t oe1; + unsigned i; + unsigned max_rank = 0; + + FOR_EACH_VEC_ELT (operand_entry_t, *ops, i, oe1) +if (oe1->rank > max_rank) + max_rank = oe1->rank; + + oe->op = op; + oe->rank = max_rank + 1; + oe->id = next_operand_entry_id++; + oe->count = 1; + VEC_safe_push (operand_entry_t, heap, *ops, oe); +} + /* Return true if STMT is reassociable operation containing a binary operation with tree code CODE, and is inside LOOP. */ @@ -1200,6 +1222,7 @@ undistribute_ops_list (enum tree_code opcode, dcode = gimple_assign_rhs_code (oe1def); if ((dcode != MULT_EXPR && dcode != RDIV_EXPR) + || oe1->count != 1 || !is_reassociable_op (oe1def, dcode, loop)) continue; @@ -1243,6 +1266,8 @@ undistribute_ops_list (enum tree_code opcode, oecount c; void **slot; size_t idx; + if (oe1->count != 1) +continue; c.oecode = oecode; c.cnt = 1; c.id = next_oecount_id++; @@ -1311,7 +1336,7 @@ undistribute_ops_list (enum tree_code opcode, FOR_EACH_VEC_ELT (operand_entry_t, subops[i], j, oe1) { - if (oe1->op == c->op) + if (oe1->op == c->op && oe1->count == 1) { SET_BIT (candidates2, i); ++nr_candidates2; @@ -3275,8 +3300,10 @@ attempt_builtin_powi (gimple stmt, VEC(operand_ent gsi_insert_before (&gsi, pow_stmt, GSI_SAME_STMT); } - /* Append the result of this iteration to the ops vector. */ - add_to_ops_vec (ops, iter_result); + /* Append the result of this iteration to the ops vector. + Give it a rank higher than all other ranks in the ops vector + so that all uses of it will be forced to come after it. */ + add_to_ops_vec_max_rank (ops, iter_result); /* Decrement the occurrence count of each element in the product by the count found above, and remove this many copies of each
[Bug c/52986] x86_64 GCC 4.7.0 can't compile x86 GCC 4.6.2; gtype-desc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52986 Markus Trippelsdorf changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #1 from Markus Trippelsdorf 2012-04-14 14:01:33 UTC --- Already fixed; dup of Bug 51969.
[Bug c/52986] New: x86_64 GCC 4.7.0 can't compile x86 GCC 4.6.2; gtype-desc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52986 Bug #: 52986 Summary: x86_64 GCC 4.7.0 can't compile x86 GCC 4.6.2; gtype-desc.c Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: kallis...@unixzen.com Original bug report: http://dev.haiku-os.org/ticket/8470 Failure: gcc -c -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/home/kallisti5/Projects/buildtools/gcc/gcc -I/home/kallisti5/Projects/buildtools/gcc/gcc/. -I/home/kallisti5/Projects/buildtools/gcc/gcc/../include -I/home/kallisti5/Projects/buildtools/gcc/gcc/../libcpp/include -I/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./gmp -I/home/kallisti5/Projects/buildtools/gcc/gmp -I/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/./mpfr -I/home/kallisti5/Projects/buildtools/gcc/mpfr -I/home/kallisti5/Projects/buildtools/gcc/mpc/src -I/home/kallisti5/Projects/buildtools/gcc/gcc/../libdecnumber -I/home/kallisti5/Projects/buildtools/gcc/gcc/../libdecnumber/dpd -I../libdecnumber/home/kallisti5/Projects/buildtools/gcc/gcc/haifa-sched.c -o haifa-sched.o gtype-desc.c:8868:18: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:8987:36: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9071:31: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9092:31: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9099:31: error: subscripted value is neither array nor pointer nor vector gtype-desc.c:9106:31: error: subscripted value is neither array nor pointer nor vector make[2]: *** [gtype-desc.o] Error 1 make[2]: *** Waiting for unfinished jobs rm cpp.pod gcc.pod fsf-funding.pod make[2]: Leaving directory `/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/kallisti5/Projects/haiku/generated/cross-tools-build/gcc' make: *** [all] Error 2 ERROR: Building gcc failed. Environment: kallisti5@eris ~ :) $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/src/gcc-4.7-20120407/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-multilib --disable-libssp --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-checking=release Thread model: posix gcc version 4.7.0 20120407 (prerelease) (GCC)
[Bug libstdc++/52839] [4.7/4.8 Regression] double free or corruption running tr1/.../default_weaktoshared.exe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839 --- Comment #31 from Alan Modra 2012-04-14 13:24:48 UTC --- Author: amodra Date: Sat Apr 14 13:24:43 2012 New Revision: 186453 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186453 Log: PR libstdc++/52839 * acinclude.m4 (_GLIBCXX_ATOMIC_BUILTINS): Do not depend on glibcxx_cv_atomic_long_long. * configure: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #10 from Jonathan Wakely 2012-04-14 13:16:18 UTC --- (In reply to comment #9) > (In reply to comment #8) > Thanks for sharing this. This broadens my perception of the issues > contributors > have with GCC. That said, it should be possible right now to use a C++ wrapper > around tree, and use that in the C++ FE (and require C++ to bootstrap the C++ > FE). What do you think about that? I think that would help me, I don't know about others. This is probably more suitable for the mailing list not bugzilla but it would certainly help me if a tree is a FIELD_DECL then pass in a field_decl wrapper around a tree, if it's a TREE_LIST pass in a tree_list wrapper around a tree. Then functions/accessors that work on a TREE_LIST could be overloaded to work on the wrapper, so you can use the original accessor on the raw tree if you know what you're doing, or the type-safe overload on the wrapper which will only compile if it's a valid operation. But that wouldn't work when a function parameter is a tree that could be either one type or another. That would either require the function to be refactored to take two parameters, or some other way to have a wrapper that could be more than one thing e.g. make the wrapper a template parameterised on by an enum bitmask template struct tree_wrapper { tree t; explicit tree_wrapper(tree t) : t(t) { gcc_checking_assert ( code() & C ); } tree_code code() const { return TREE_CODE (t); } }; typedef tree_wrapper tree_list; typedef tree_wrapper target_expr; typedef tree_wrapper constructor; // etc. void f( tree_list list ); void g( target_expr expr ); void h( tree_wrapper tree ) { if (tree.code() == TREE_LIST) f( tree_list(tree.t) ); else g( target_expr(tree.t) ); } > Well, the wiki is just a minor example, but it is awfully slow, nobody has > administrator login (I can access as Daniel Berlin and ban users, but little > more), and it is a unsupported version with known security issues. Ah yes, I see what you mean now.
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #9 from Manuel López-Ibáñez 2012-04-14 12:42:53 UTC --- (In reply to comment #8) > (In reply to comment #7) > > It is not *technically* hard. Anyone that knows C and a bit of C++ can fix > > hundreds (if you know C++ well and have a some experience with the C++ > > parser, > > There's the problem. I know C++ very well but don't know the front end well > enough to work on it, and don't have time to learn it. My main problem is > that > everything is a void* so I have no idea what I can do with a given tree or > what > type it is, so I just try something, it compiles (because there's no type > checking) so I run it then debug an ICE and continue by trial and error. > That's not productive. The bottleneck is not the bureaucracy for me. Thanks for sharing this. This broadens my perception of the issues contributors have with GCC. That said, it should be possible right now to use a C++ wrapper around tree, and use that in the C++ FE (and require C++ to bootstrap the C++ FE). What do you think about that? > > Indeed, but my point is that moving to C++ does little (in my opinion) to > > fix > > the infrastructure issues in GCC: dejagnu is awful, the wiki is > > unmaintained, > > Why should the wiki be maintained? If people want to add to it they can, why > should there be a maintainer? Well, the wiki is just a minor example, but it is awfully slow, nobody has administrator login (I can access as Daniel Berlin and ban users, but little more), and it is a unsupported version with known security issues.
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #8 from Jonathan Wakely 2012-04-14 12:24:47 UTC --- (In reply to comment #7) > It is not *technically* hard. Anyone that knows C and a bit of C++ can fix > hundreds (if you know C++ well and have a some experience with the C++ parser, There's the problem. I know C++ very well but don't know the front end well enough to work on it, and don't have time to learn it. My main problem is that everything is a void* so I have no idea what I can do with a given tree or what type it is, so I just try something, it compiles (because there's no type checking) so I run it then debug an ICE and continue by trial and error. That's not productive. The bottleneck is not the bureaucracy for me. > Indeed, but my point is that moving to C++ does little (in my opinion) to fix > the infrastructure issues in GCC: dejagnu is awful, the wiki is unmaintained, Why should the wiki be maintained? If people want to add to it they can, why should there be a maintainer?
[Bug c++/52957] Missing suggestions on '=' and '==' confusion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52957 --- Comment #7 from Manuel López-Ibáñez 2012-04-14 12:10:13 UTC --- > > are against it). I don't think there is any GCC contributor that is paid to > > improve GCC's diagnostics (am I wrong?). > > Right, but partially because it is a hard thing to do improve and the ROI is > low. It is not *technically* hard. Anyone that knows C and a bit of C++ can fix hundreds (if you know C++ well and have a some experience with the C++ parser, you can probably fix thousands of bugs on your own, each fix taking no more than a couple of hours of debugging and few minutes of programming). However, it is time-consuming because of all the bureaucracy: copyright assignment, setting up the environment, bootstrapping+testing, patch submission, patch review, communication delays, style nits, changelogs nits, and updating the testsuite. That is why even current contributors often don't bother with one-liners, because all the associated tasks can make a one minute change require days of effort. > > This is very different from Clang, > > where Chris obviously cares a great deal about Clang's diagnostics, and it > > seems to be supported by a team in Apple (and in Google?). > > Yes, and in Google, but do you know why? Because it is easy to improve their > diagnostics and benefit can be quickly seen. But why is it easy? For example, the C++ FE, although I don't like many of its design decisions, is quite easy to hack. And I don't think this is the reason. GCC is obviously easy to hack for their current developers, but they focus on different things than the Clang/LLVM developers. The whole attitude is quite different, for better or worse, and in terms of popularity, the LLVM crowd wins (of course, the GCC crowd may say that this is not a popularity contest, but if you want to attract new developers, who now have a choice, then it is). > > However, there are a lot of them, and getting > > patches reviewed and accepted requires herculean amounts of perseverance. > > But > > probably you can share with me more about your (or Googlers) thoughts on the > > latter, since you have the experience of submitting the same project to both > > LLVM and GCC. > > Infrastructure makes a big difference here -- see more about this below. Indeed, but my point is that moving to C++ does little (in my opinion) to fix the infrastructure issues in GCC: dejagnu is awful, the wiki is unmaintained, patch submission is a pain, patch review is a bottleneck, no automatic style checks, useless obligatory changelogs, no marketing, poor documentation for beginners, poor coordination with other projects (binutils, gdb, glibc), etc. (and, worse, the expectation that new/non-paid contributors should take care of fixing these issues). > > > > Nothing of the above gets fixed by switching to C++ or by having a clearly > > defined AST... > > I think they are clearly related. In any case, I hope you are right, and the move to C++ helps. I imagine that it can help to attract more corporate contributors, who don't have to bother with legal paperwork and are paid to do also boring bits. For sporadic and/or non-paid contributors, there are other bigger issues to solve.
[Bug fortran/52673] implement -fheap-arrays in gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52673 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-14 CC||tkoenig at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Thomas Koenig 2012-04-14 11:36:57 UTC --- Confirmed, would be a good idea.
[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025 Jonathan Wakely changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #8 from Jonathan Wakely 2012-04-14 11:01:59 UTC --- Yep, thanks, Marc.
[Bug middle-end/52985] New: Postincrement not applied after indexing ternary array expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52985 Bug #: 52985 Summary: Postincrement not applied after indexing ternary array expression Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: w...@benfold.com Created attachment 27156 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27156 Preprocessed source [Component=middle-end was a guess, apologies if it's wrong.] The code below prints an infinite series of zeros, as if the iterator is never incremented. The problem goes away if: * the ternary expression is replaced by either tableA or tableB * 'flag' is set to true * the iterator increment is performed in a separate statement * the vector and iterators are replaced with an array and (int *) * tableA and tableB are replaced by vectors. If the result of the array indexing is actually used, e.g. printed to cerr, then results are the same at -O1 and above, but I see a segfault with -O0. #include #include int main (int argc, char *argv[]) { std::vector v(1); int tableA[] = { 0 }; int tableB[] = { 0 }; bool flag = false; for (std::vector::const_iterator it = v.begin(); it != v.end();) { (flag ? tableA : tableB)[*it++]; std::cerr << (it - v.begin()) << "\n"; } return 0; }
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #50 from Manuel López-Ibáñez 2012-04-14 10:53:25 UTC --- (In reply to comment #49) > Created attachment 27155 [details] > fix overload carets > > The patch that I am currently bootstrapping. I made a small change to the > output. It looks like this now: It bootstraps but, of course, there are a lot of failures. This one: > note: candidates are: I can remove in prune.exp but this: > note: candidate expects 0 arguments, 1 provided We probably want to match in messages. I am pretty sure there is a way to add a new { dg-notes-2 "note1" "note2" } which passes a regexp such as "[^\n]*note1[^\n]*\n[^\n]*note2[^\n]*" to process-message, but my Tcl foo is not strong enough.
[Bug c++/52978] Inherit from Template with specified type and override virtual function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52978 --- Comment #6 from Benedikt Schmidt 2012-04-14 08:37:00 UTC --- Now it is clear, even to me. My personal conclusion from this is: Prefer T const& instead of const T&. Thank you, Benedikt Schmidt
[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025 Marc Glisse changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #7 from Marc Glisse 2012-04-14 07:07:05 UTC --- Link changed now that it has been voted into the working paper: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1288 should it be un-suspended?