[Bug fortran/57364] [4.8/4.9 Regression][OOP] ICE gfc_enforce_clean_symbol_state
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57364 --- Comment #6 from Tobias Burnus --- Author: burnus Date: Tue Jun 4 07:11:12 2013 New Revision: 199635 URL: http://gcc.gnu.org/viewcvs?rev=199635&root=gcc&view=rev Log: 2013-06-04 Tobias Burnus Backport from mainline 2013-05-22 Tobias Burnus PR fortran/57364 * resolve.c (get_temp_from_expr): Commit created sym. 2013-06-04 Tobias Burnus Backport from mainline 2013-05-22 Tobias Burnus PR fortran/57364 * gfortran.dg/defined_assignment_6.f90: New. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/defined_assignment_6.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/resolve.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/57364] [4.8/4.9 Regression][OOP] ICE gfc_enforce_clean_symbol_state
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57364 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Tobias Burnus --- FIXED on the trunk (for 4.9) and on the 4.8 branch.
[Bug c++/57419] Access control doesn't stop referring to a deleted function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57419 --- Comment #6 from Paolo Carlini --- No, rather different issues.
[Bug fortran/57522] New: [F03] ASSOCIATE construct creates array descriptor with incorrect stride for derived type array component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57522 Bug ID: 57522 Summary: [F03] ASSOCIATE construct creates array descriptor with incorrect stride for derived type array component Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: alan.briolat at gmail dot com Created attachment 30254 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30254&action=edit Code demonstrating the bug The attached code demonstrates a bug (reproducible on 4.6 to 4.9) where using ASSOCIATE to reference a derived type component in an array appears to have the wrong stride. The output is: 0 1 2 3 0 4 1 5 when it should be (and is under ifort): 0 1 2 3 0 1 2 3 This is probably related to bug 49636, but is a simpler case. It's also probably related to http://gcc.gnu.org/wiki/ArrayDescriptorUpdate (which I found via that bug). However, if the changes necessary to support this sort of reference are "future ABI-breaking work", then the current version really should warn/error rather than generating the wrong stride and silently doing the wrong thing.
[Bug regression/57473] FAIL: gcc.dg/tls/emutls-2.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57473 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Rainer Orth --- > Also fails on Solaris 9 with Sun as, will check if current mainline works > again. Both i386-pc-solaris2.9 and sparc-sun-solaris2.9 bootstraps have now completed and as of r199603, all emutls related failures are gone. Thanks. Rainer
[Bug target/47333] [4.8 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 Rainer Orth changed: What|Removed |Added Summary|[4.8/4.9 regression]|[4.8 regression] |g++.dg/lto/20091219 FAILs |g++.dg/lto/20091219 FAILs |on Solaris 2 with SUN as|on Solaris 2 with SUN as --- Comment #37 from Rainer Orth --- No longer a 4.9 regression, fixed by the patch for PR middle-end/57366. Unfortunately, that doesn't easily backport to the 4.8 branch since that lacks alias and alias_target in struct symtab_node_base: /vol/gcc/src/hg/gcc-4.8-branch/local/gcc/cgraphunit.c: In function 'void compile ()': /vol/gcc/src/hg/gcc-4.8-branch/local/gcc/cgraphunit.c:2050:22: error: 'struct sy mtab_node_base' has no member named 'alias' /vol/gcc/src/hg/gcc-4.8-branch/local/gcc/cgraphunit.c:2056:21: error: 'struct sy mtab_node_base' has no member named 'alias_target' /vol/gcc/src/hg/gcc-4.8-branch/local/gcc/cgraphunit.c:2056:49: error: 'struct sy mtab_node_base' has no member named 'alias_target' /vol/gcc/src/hg/gcc-4.8-branch/local/gcc/cgraphunit.c:2057:10: error: 'symtab_al ias_target' was not declared in this scope make[3]: *** [cgraphunit.o] Error 1 Rainer
[Bug fortran/57522] [F03] ASSOCIATE construct creates array descriptor with incorrect stride for derived type array component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57522 --- Comment #1 from Alan Briolat --- Created attachment 30255 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30255&action=edit Working "equivalent" code based on pointers For comparison, this attached code uses pointers to achieve the same thing and gets the correct result. What's so different between the array descriptors used for pointers and the array descriptors use for ASSOCIATE?
[Bug tree-optimization/57523] New: ICE in merge_assigned_reloads, at reload1.c:6062
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57523 Bug ID: 57523 Summary: ICE in merge_assigned_reloads, at reload1.c:6062 Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: chapter34 at yahoo dot com Created attachment 30256 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30256&action=edit preprocessed source While attempting to compile GCC 4.8.0 for Solaris 10 x86_64 using /usr/sfw/bin/gcc 3.4.3 as a bootstrap compiler and /usr/sfw/bin/gas 2.15 as assembler, I need the pre-requisite GMP library. Compiling GMP 5.1.1 as follows: ~/gmp-5.1.1$ export CC="/usr/sfw/bin/gcc -m64" ABI=64 ~/gmp-5.1.1$ ./configure --enable-cxx && gmake It fails on: ~gmp-5.1.1/mpn$ /usr/sfw/bin/gcc -v -save-temps -m64 -std=gnu99 -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_sbpi1_div_qr_sec -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 -c sbpi1_div_qr_sec.c -fPIC -DPIC -o .libs/sbpi1_div_qr_sec.o Reading specs from /ms/dist/sunos.5.10/PROJ/sfw/10.10/.exec/ia32.sunos.5.10/bin/../lib/gcc/i386-pc-solaris2.10/3.4.3/specs Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) /ms/dist/sunos.5.10/PROJ/sfw/10.10/.exec/ia32.sunos.5.10/bin/../libexec/gcc/i386-pc-solaris2.10/3.4.3/cc1 -E -quiet -v -I. -I.. -I.. -iprefix /ms/dist/sunos.5.10/PROJ/sfw/10.10/.exec/ia32.sunos.5.10/bin/../lib/gcc/i386-pc-solaris2.10/3.4.3/ -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_sbpi1_div_qr_sec -DPIC sbpi1_div_qr_sec.c -m64 -m64 -mtune=k8 -march=k8 -std=gnu99 -pedantic -fomit-frame-pointer -fPIC -O2 -o sbpi1_div_qr_sec.i ignoring nonexistent directory "/ms/dist/sunos.5.10/PROJ/sfw/10.10/.exec/ia32.sunos.5.10/bin/../lib/gcc/i386-pc-solaris2.10/3.4.3/../../../../i386-pc-solaris2.10/include" ignoring duplicate directory "/usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/include" ignoring nonexistent directory "/usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/../../../../i386-pc-solaris2.10/include" ignoring duplicate directory ".." #include "..." search starts here: #include <...> search starts here: . .. /ms/dist/sunos.5.10/PROJ/sfw/10.10/.exec/ia32.sunos.5.10/bin/../lib/gcc/i386-pc-solaris2.10/3.4.3/include /usr/local/include /usr/sfw/include /usr/include End of search list. /ms/dist/sunos.5.10/PROJ/sfw/10.10/.exec/ia32.sunos.5.10/bin/../libexec/gcc/i386-pc-solaris2.10/3.4.3/cc1 -fpreprocessed sbpi1_div_qr_sec.i -quiet -dumpbase sbpi1_div_qr_sec.c -m64 -m64 -mtune=k8 -march=k8 -auxbase-strip .libs/sbpi1_div_qr_sec.o -O2 -pedantic -std=gnu99 -version -fomit-frame-pointer -fPIC -o sbpi1_div_qr_sec.s GNU C version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) (i386-pc-solaris2.10) compiled by GNU C version 3.4.3 (csl-sol210-3_4-branch+sol_rpath). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 sbpi1_div_qr_sec.c: In function `__gmpn_sbpi1_div_qr_sec': sbpi1_div_qr_sec.c:151: internal compiler error: in merge_assigned_reloads, at reload1.c:6062 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. However, it compiles fine if I omit the -O2 flag.
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #23 from Tobias Burnus --- Author: burnus Date: Tue Jun 4 10:20:32 2013 New Revision: 199643 URL: http://gcc.gnu.org/viewcvs?rev=199643&root=gcc&view=rev Log: 2013-06-03 Tobias Burnus PR fortran/37336 * trans.h (gfc_build_final_call): Remove prototype. (gfc_add_finalizer_call): Add prototype. * trans-array.c (gfc_trans_dealloc_allocated): Support * finalization. (structure_alloc_comps): Update caller. (gfc_trans_deferred_array): Call finalizer. * trans-array.h (gfc_trans_dealloc_allocated): Update prototype. * trans-decl.c (gfc_trans_deferred_vars): Don't * deallocate/finalize variables of the main program. * trans-expr.c (gfc_conv_procedure_call): Support finalization. * trans-openmp.c (gfc_omp_clause_dtor, gfc_trans_omp_array_reduction): Update calls. * trans-stmt.c (gfc_trans_deallocate): Avoid double deallocation of alloc components. * trans.c (gfc_add_finalizer_call): New function. (gfc_deallocate_with_status, gfc_deallocate_scalar_with_status): Call it (gfc_build_final_call): Fix handling of scalar coarrays, move up in the file and make static. 2013-06-03 Tobias Burnus PR fortran/37336 * gfortran.dg/finalize_12.f90: New. * gfortran.dg/alloc_comp_basics_1.f90: Add BLOCK for end of scope finalization. * gfortran.dg/alloc_comp_constructor_1.f90: Ditto. * gfortran.dg/allocatable_scalar_9.f90: Ditto. * gfortran.dg/auto_dealloc_2.f90: Ditto. * gfortran.dg/class_19.f03: Ditto. * gfortran.dg/coarray_lib_alloc_1.f90: Ditto. * gfortran.dg/coarray_lib_alloc_2.f90: Ditto. * gfortran.dg/extends_14.f03: Ditto. * gfortran.dg/move_alloc_4.f90: Ditto. * gfortran.dg/typebound_proc_27.f03: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/finalize_12.f90 trunk/gcc/testsuite/gfortran.dg/finalize_13.f90 trunk/gcc/testsuite/gfortran.dg/finalize_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-array.h trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 trunk/gcc/testsuite/gfortran.dg/alloc_comp_constructor_1.f90 trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90 trunk/gcc/testsuite/gfortran.dg/auto_dealloc_2.f90 trunk/gcc/testsuite/gfortran.dg/class_19.f03 trunk/gcc/testsuite/gfortran.dg/coarray_lib_alloc_1.f90 trunk/gcc/testsuite/gfortran.dg/coarray_lib_alloc_2.f90 trunk/gcc/testsuite/gfortran.dg/extends_14.f03 trunk/gcc/testsuite/gfortran.dg/move_alloc_4.f90 trunk/gcc/testsuite/gfortran.dg/typebound_proc_27.f03
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 --- Comment #24 from Tobias Burnus --- The patch in comment 23 adds finalization support for allocatables (end of scope, intent(out), DEALLOCATE, MOVE_ALLOC). Thus, on the trunk (GCC 4.9), finalization is now finally supported :-) Note: There are additional cases for which finalization has to be done, e.g. for intent(out) of nonallocatable (patch: http://gcc.gnu.org/ml/fortran/2013-05/msg00135.html), end-of-scope of nonallocatables, intrinsic assignment, function results + array/structure constructors - after there use in expressions.
[Bug target/47333] [4.8 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 --- Comment #38 from Jan Hubicka --- > No longer a 4.9 regression, fixed by the patch for PR middle-end/57366. Good news. > > Unfortunately, that doesn't easily backport to the 4.8 branch since that lacks > alias and alias_target in struct symtab_node_base: I know. Weakrefs was quite broken in 4.8 (and anything earlier) and more so on non-weakref assemblers (even when you do not get ICE nor link error, you still get wrong references output so the final program will not work since it won't connect weakref with its target). I can backport the whole series of patches, but I would like to understand how important it is. Solaris libc is using weakrefs w/o weakref support in toolchain, or does the weakref come from some of GNU libraries in it? Honza
[Bug target/47333] [4.8 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 --- Comment #39 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #36 from Jan Hubicka --- > I am having problem to reproduce it on a cross compiler. I assume you have > non-plugin-enable LD setup, right? The failure happens with both Sun as/Sun ld (i.e. no plugin support) and Sun as/GNU ld 2.23.1 (i.e. with linker plugin support). > There is problem with chained weakrefs that ought to be fixed by the following > change: > Index: cgraphunit.c > === > --- cgraphunit.c(revision 199591) > +++ cgraphunit.c(working copy) > @@ -656,8 +656,11 @@ cgraph_process_same_body_aliases (void) > @@ -2018,7 +2021,7 @@ compile (void) >(DECL_ASSEMBLER_NAME (node->symbol.decl)) = 1; > TREE_CHAIN (DECL_ASSEMBLER_NAME (node->symbol.decl)) >= (node->symbol.alias_target ? node->symbol.alias_target > - : DECL_ASSEMBLER_NAME (symtab_alias_target > (node)->symbol.decl)); > + : DECL_ASSEMBLER_NAME (symtab_alias_ultimate_target > (node)->symbol.decl)); >} > #endif > > > I however do not see any chained weakrefs in the preprocessed file attached, > so > I am not quite convinced this can change anything. > > Can you, please, run it in debugger and take a look what is the assembler name > ultimate_target is called for and what is its CHAIN_DECL? I can try if this is still beneficial given that mainline seems to work fine. Rainer
[Bug tree-optimization/57521] [4.7/4.8/4.9 Regression] wrong code for expressions in loop at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57521 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Hmhm, mine.
[Bug tree-optimization/57359] wrong code for union access at -O3 on x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|RESOLVED|ASSIGNED Component|rtl-optimization|tree-optimization Resolution|INVALID |--- Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #11 from Richard Biener --- Note that the GIMPLE/RTL IL does not have all restrictions of C so even if the testcase is invalid C the generated GIMPLE IL may be valid and thus there may still be a bug in GCC. In particular the middle-end memory model does not require the effective type change to go through a union type. And indeed the bug is in store-motion which sinks *pll = a cross *pii = 0. Replace u with anonymous storage and use placement-new to properly construct a new type in it and get a valid C++ testcase that is miscompiled. -fno-tree-loop-im fixes it. I will have a look.
[Bug tree-optimization/57517] [4.7/4.8/4.9 Regression] internal compiler error: in eliminate_temp_copies, at tree-predcom.c:1913
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57517 Richard Biener changed: What|Removed |Added Known to work||4.4.7 Target Milestone|--- |4.7.4 Summary|internal compiler error: in |[4.7/4.8/4.9 Regression] |eliminate_temp_copies, at |internal compiler error: in |tree-predcom.c:1913 |eliminate_temp_copies, at ||tree-predcom.c:1913 Known to fail||4.5.4, 4.6.4, 4.7.2, 4.8.0, ||4.9.0
[Bug tree-optimization/57511] [4.8/4.9 Regression] Missing SCEV final value replacement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57511 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-06-04 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.8.2 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. I will have a look.
[Bug c++/57524] New: internal compiler error on dump translation unit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524 Bug ID: 57524 Summary: internal compiler error on dump translation unit Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: JamesMikeDuPont at googlemail dot com using the debian sid standard : GNU C++ (Debian 4.7.2-5) version 4.7.2 (x86_64-linux-gnu) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 warning: MPFR header version 3.1.0-p10 differs from library version 3.1.1-p2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiling boost spirit.qi code, Here is the one that creates the error. Invocation is : /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1plus -std=gnu++11 -fdump-translation-unit treedumpparse.ii the output is: (this is the last of the function print ) std::size_t boost::detail::variant::variant_hasher::operator()(const T&) const the error is : In file included from /usr/include/boost/variant/variant.hpp:35:0, from /usr/include/boost/spirit/home/support/info.hpp:14, from /usr/include/boost/spirit/home/qi/domain.hpp:16, from /usr/include/boost/spirit/home/qi/meta_compiler.hpp:15, from /usr/include/boost/spirit/home/qi/action/action.hpp:14, from /usr/include/boost/spirit/home/qi/action.hpp:14, from /usr/include/boost/spirit/home/qi.hpp:14, from /usr/include/boost/spirit/include/qi.hpp:16, from treedumpparse.cpp:6: /usr/include/boost/variant/detail/hash_variant.hpp:32:33: internal compiler error: in timevar_start, at timevar.c:344 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. This can be reproduced with this one include : #include "/usr/include/boost/variant/detail/hash_variant.hpp" I am trying to reduce the problem, but it is difficult.
[Bug middle-end/57484] 'std::numeric_limits< T >::signaling_NaN()' signaling-bit is incorrect for x86 32-bit.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57484 --- Comment #8 from Charles L. Wilcox --- FWIW, I tried this with g++ 4.8 on a 32-bit only system I have; it still produces erroneous sNaN values there: $ g++-4.8 -v Using built-in specs. COLLECT_GCC=g++-4.8 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.8/lto-wrapper Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.1-1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-i386 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-i386 --with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-targets=all --enable-multiarch --with-arch-32=i586 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.8.1 (Debian 4.8.1-1) $ g++-4.8 -Wall -Wextra test-signaling-nan.cpp $ ./a.out Signaling NaN for type "f" in hex is "7fe0". Signaling NaN's signaling-bit status for type "f" is set to "true". Quiet NaN for type "f" in hex is "7fc0". Quiet NaN's signaling-bit status for type "f" is set to "true". Signaling NaN for type "d" in hex is "7ffc". Signaling NaN's signaling-bit status for type "d" is set to "true". Quiet NaN for type "d" in hex is "7ff8". Quiet NaN's signaling-bit status for type "d" is set to "true".
[Bug other/57525] New: cc1.exe: fatal error: help-dummy: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57525 Bug ID: 57525 Summary: cc1.exe: fatal error: help-dummy: No such file or directory Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Host: i386-mingw32 Target: avr Build: i686-linux-gnu $ echo > trivial.c $ avr-gcc trivial.c -save-temps --help=optimizers cc1.exe: fatal error: help-dummy: No such file or directory This fatal error also occurs with other versions of GCC. Trigger is -save-temps together with --help= == configure == Configured with: ../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr --prefix=/local/gnu/install/gcc-4.7-mingw32 --host=i386-mingw32 --build=i686-linux-gnu --enable-languages=c,c++ --disable-nls --disable-shared --with-dwarf2 --with-avrlibc=yes Thread model: single gcc version 4.7.2 (GCC)
[Bug c++/57524] internal compiler error on dump translation unit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57524
--- Comment #1 from James Michael DuPont ---
I tried to reduce the input size but it is not producing any results.
namespace std {
typedef long unsigned int size_t;
};
namespace boost {
namespace detail {
struct is_static_visitor_tag { };
typedef void static_visitor_default_return;
}
template
class static_visitor: public detail::is_static_visitor_tag {
public:
typedef R result_type;
protected:
static_visitor() { }~static_visitor() { }
};}
namespace boost
{
template struct hash;
template void hash_combine(std::size_t& seed, T const& v);
template std::size_t hash_range(It, It);
template void hash_range(std::size_t&, It, It);
}
namespace boost {
namespace detail { namespace variant {
struct variant_hasher: public boost::static_visitor {
template
std::size_t operator()(T const& val) const {
using namespace boost;
hash hasher;
return hasher(val);
} };} }}
[Bug other/57482] [4.7.3][AVR] --help=optimizers reports a wrong list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57482
Georg-Johann Lay changed:
What|Removed |Added
Target|AVR ATmega128 |avr
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-06-04
CC||gjl at gcc dot gnu.org
Component|c |other
Ever confirmed|0 |1
Build|4.7.3 |
--- Comment #2 from Georg-Johann Lay ---
I can confirm this with 4.7.2 and the following source file
== foo.c ==
typedef enum { A, B } ab_t;
int a[sizeof (ab_t) == 2 ? 1 : -1];
== compile ==
$ avr-gcc foo.c
$ avr-gcc foo.c -Q --help=optimizers | grep short.enum
-fshort-enums [enabled]
== issues ==
1) foo.c compiles fine, thus enums are 2 byte per default.
This shows the output of --help=optimizers is not correct.
2) -f[no-]short-enums is not an optimization option;
it's an option affecting the ABI. Better / worse code
is just a side effect of respective ABI change.
3) The backend does not implement TARGET_DEFAULT_SHORT_ENUMS
thus the default shall be like with -fno-short-enums, cf.
target.def defines the hook default to hook_bool_void_false.
[Bug target/47333] [4.8 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 --- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #38 from Jan Hubicka --- >> Unfortunately, that doesn't easily backport to the 4.8 branch since that >> lacks >> alias and alias_target in struct symtab_node_base: > > I know. Weakrefs was quite broken in 4.8 (and anything earlier) and more so on > non-weakref assemblers (even when you do not get ICE nor link error, you still > get wrong references output so the final program will not work since it won't > connect weakref with its target). I see. At least all testcases passed in 4.7 both with and without weakref support in the assembler. > I can backport the whole series of patches, but I would like to understand how > important it is. Solaris libc is using weakrefs w/o weakref support in > toolchain, or does the weakref come from some of GNU libraries in it? The Solaris toolchain (as, ld) knows nothing about weakrefs, so far I've seen failures only in the gcc testsuite, no reports in the wild. Rainer
[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Pedro Alves changed: What|Removed |Added CC||palves at redhat dot com --- Comment #4 from Pedro Alves --- I believe the fix has been checked in, right?
[Bug tree-optimization/57358] segmentation fault with attribute(optimize(O0))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57358 --- Comment #1 from Nickolay Kolchin-Semyonov --- Reproducable with gcc-4.8.1. Using built-in specs. COLLECT_GCC=gcc-4.8.1 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /mnt/work/tmp/portage/sys-devel/gcc-4.8.1/work/gcc-4.8.1/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.1 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-cloog --disable-isl-version-check --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,go,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.1 p1.0, pie-0.5.6' Thread model: posix gcc version 4.8.1 (Gentoo 4.8.1 p1.0, pie-0.5.6) $ gcc-4.8.1 -O3 -c no-optimize.c no-optimize.c: In function ‘test_func’: no-optimize.c:7:1: internal compiler error: Segmentation fault } ^
[Bug target/57357] Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357 thutt at vmware dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #7 from thutt at vmware dot com --- (In reply to Andrew Pinski from comment #6) > (In reply to thutt from comment #5) > > Is there simple explanation for the difference in behavior? > > Is the preprocessed source the same? I bet glibc enables some inline > function at -O1. Yes, the cpp output is different. Because this produces different results for -O0 and -O1, I'm reopening because the compiler really shouldn't fail with one setting and succeed with another.
[Bug tree-optimization/57358] segmentation fault with attribute(optimize(O0))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57358
--- Comment #2 from Nickolay Kolchin-Semyonov ---
More simplified test variant:
struct t { void (*func)(void*); };
void test_func(struct t* a) __attribute__((optimize("O0")));
void test_func(struct t* a)
{
a->func(0);
}
P.S. If you compile this as C++ code, no segmentation fault would occure.
[Bug c++/57526] New: use of X before deduction of auto error for seemingly good code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57526
Bug ID: 57526
Summary: use of X before deduction of auto error for seemingly
good code
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: plasmahh at gmx dot net
Hi,
for the following code
template
struct A
{
void bar( ) { }
void foo( )
{
auto* this_ptr = this;
auto lc = [&]( )
{
this_ptr->bar();
};
lc();
}
};
int main(int argc, const char *argv[])
{
A a;
a.foo();
}
I get gcc 4.8.{0,1} error me out with:
auto.cxx:12:4: error: use of 'A::foo() [with T =
int]::__lambda0::__this_ptr' before deduction of 'auto'
this_ptr->bar();
which for one was not the case with gcc 4.7. There are two (strange) ways to
make it go away: Either make it be "auto" isntead of "auto*" or make A not
being a template. I also could not find anything in the standard that would
disallow this.
[Bug c++/57527] New: [C++11] Nested variadic templates cause internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57527
Bug ID: 57527
Summary: [C++11] Nested variadic templates cause internal
compiler error
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markus.mayr at outlook dot com
I do not know whether the following program is supposed to compile according to
the standard. I only know that it compiles using clang and that it causes an
internal compiler error. I use a variadic template constructor within a
variadic template class and expand both parameter packs simultaneously.
struct Z {};
template
struct X {};
template
struct Y
{
template
Y( X... xs )
{}
};
int main( int argc, char **argv )
{
X x;
Y y( x );
return 0;
}
Instantiating the constructor causes an internal compiler error:
t.cpp: In function 'int main(int, char**)':
t.cpp:16:25: internal compiler error: in unify, at cp/pt.c:16369
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
If x is replaced by a temporary, the code compiles, i.e. replacing main() by
int main( int argc, char **argv )
{
Y y( X x );
return 0;
}
compiles. Turning x into an rvalue reference, however, does not compile.
I added the code as an attachment. My compiler version is g++-4.7.2, but I am
currently compiling a more recent version of g++ (4.8.0) to test this. I tested
the code on Mac OS X and Debian GNU/Linux. As already mentioned, clang++ seems
to accept the code. As a side note, I would also be interested in a workaround
for enumerating arguments in a parameter pack provided that there might be
arguments of the same type in the pack.
I hope that this bug is new to you.
[Bug c++/57527] [C++11] Nested variadic templates cause internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57527 --- Comment #1 from markus.mayr at outlook dot com --- Created attachment 30257 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30257&action=edit Source code example.
[Bug c++/57526] [4.8/4.9 Regression] use of X before deduction of auto error for seemingly good code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57526 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-04 Known to work||4.6.3, 4.7.3 Summary|use of X before deduction |[4.8/4.9 Regression] use of |of auto error for seemingly |X before deduction of auto |good code |error for seemingly good ||code Ever confirmed|0 |1 Known to fail||4.8.0, 4.9.0
[Bug target/57506] [avr] Some devices are present twice in avr-mcus.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57506 --- Comment #1 from Georg-Johann Lay --- Created attachment 30258 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30258&action=edit Patch against avr-mcus.def Notice that some sources depend on the patch, e.g. documentation. Rerun "make avr-mcus" after applying this patch.
[Bug c++/57527] [C++11] Nested variadic templates cause internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57527 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-06-04 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Possibly a dup of Bug 54090 but fails at a different place
[Bug regression/57473] FAIL: gcc.dg/tls/emutls-2.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57473 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|4.9.0 |--- --- Comment #8 from ktkachov at gcc dot gnu.org --- Fixed on trunk.
[Bug target/47333] [4.8 regression] g++.dg/lto/20091219 FAILs on Solaris 2 with SUN as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 --- Comment #41 from Jan Hubicka --- > > I however do not see any chained weakrefs in the preprocessed file > > attached, so > > I am not quite convinced this can change anything. > > > > Can you, please, run it in debugger and take a look what is the assembler > > name > > ultimate_target is called for and what is its CHAIN_DECL? > > I can try if this is still beneficial given that mainline seems to work > fine. Just ignore this patch. I just tested and we can not chain weakrefs. I will check what patches has to go to 4.8 to fix the whole issue. I guess the silent miscopmilation is potentially dangerous, since it will just disable locking in LTO apps Honza > > Rainer > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug c++/57528] New: Missed warning for putting reference to temporary in class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57528
Bug ID: 57528
Summary: Missed warning for putting reference to temporary in
class member
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jewillco at osl dot iu.edu
It would be nice to have a warning on code such as:
struct b {
const int& r;
b(int r): r(r) {}
};
that is almost certainly unintended since it always binds a reference to a
temporary in a case where the reference outlives the temporary. "g++ (GCC)
4.9.0 20130519 (experimental)" does not warn on this code with -Wall -Wextra,
whether with -O2 or without. Uses of the struct b (including with a literal
number as constructor argument) do not produce warnings either.
[Bug middle-end/57529] New: Redundant masking of zero-extended values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57529
Bug ID: 57529
Summary: Redundant masking of zero-extended values
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jewillco at osl dot iu.edu
Using version "gcc (GCC) 4.9.0 20130519 (experimental)" with target
"x86_64-unknown-linux-gnu" and the flags "-Ofast -std=gnu99 -march=bdver1", the
following code:
#include
void foo(const uint16_t* restrict indexes, const uint64_t* restrict bits,
unsigned int* restrict sum, int count) {
for (int i = 0; i < count; ++i) {
unsigned int val = indexes[i];
if (bits[val / 64] & (1UL << (val % 64))) {sum[val] += 1;}
}
}
produces two shifts to implement the "val / 64" operation instead of one,
seemingly because the compiler is trying to mask val to 16 bits even though it
was loaded with movzwl and thus was already masked and zero-extended. Here is
the assembly for the function body:
testl %ecx, %ecx # count
movl%ecx, %r9d # count, count
jle .L8 #,
xorl%eax, %eax # ivtmp.5
.p2align 4,,10
.p2align 3
.L4:
movzwl (%rdi,%rax,2), %ecx # MEM[base: indexes_8(D), index:
ivtmp.5_52, step: 2, offset: 0B], D.2242
movq%rcx, %r8 # D.2242, D.2244
# Redundant masking operation:
salq$48, %r8#, D.2244
shrq$54, %r8#, D.2244
#
movq(%rsi,%r8,8), %r8 # *_16, D.2244
#
shrq%cl, %r8# D.2242, D.2244
andl$1, %r8d#, D.2244
#
je .L3 #,
#
movzwl %cx, %r8d # D.2242, D.2244
#
incl(%rdx,%r8,4)# *_25
.L3:
incq%rax# ivtmp.5
cmpl%eax, %r9d # ivtmp.5, count
jg .L4 #,
.L8:
rep; ret
The seemingly-unnecessary operation is marked with stars; a single shrq by 6
should do the unsigned division operation correctly, while two instructions are
used to both mask the value to 16 bits and shift it. The zero-extension inside
x's is also unnecessary (%rcx could have been used directly in the index
expression). On a somewhat unrelated issue, the code marked in +'s seems to be
sub-optimal as well, and could probably be replaced by a bt instruction (GCC
4.4.7 uses "btq" there using -O3 and the same -march flag).
[Bug fortran/57530] New: [OOP] Wrongly rejects type_pointer => class_target (which have identical declared type)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57530 Bug ID: 57530 Summary: [OOP] Wrongly rejects type_pointer => class_target (which have identical declared type) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: janus at gcc dot gnu.org Found in the examples to http://www.cambridge.org/rouson (-> ssdSource/chapter05/hermetic). According to comments, the original program is accepted by xlf2003 and nagf95. The following simplified code is accepted by Crayftn, ifort and pgf95, but rejected by gfortran with: ptr => tgt ! TYPE => CLASS 1 Error: Different types in pointer assignment at (1); attempted assignment of CLASS(t) to TYPE(t) >From F2008: "C714 (R733) If data-target is not unlimited polymorphic, data-pointer-object shall be type compatible (4.3.1.3) with it and the corresponding kind type parameters shall be equal." There (4.3.1.3): "A nonpolymorphic entity is type compatible only with entities of the same declared type. A polymorphic entity that is not an unlimited polymorphic entity is type compatible with entities of the same declared type or any of its extensions." In the example below, TYPE(t) and CLASS(t) have same declared type. module m type t end type t contains subroutine sub (tgt) class(t), target :: tgt type(t), pointer :: ptr ptr => tgt ! TYPE => CLASS end subroutine sub end module m
[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Yaakov (Cygwin Ports) changed: What|Removed |Added CC||yselkowitz at users dot sourceforg ||e.net --- Comment #5 from Yaakov (Cygwin Ports) --- An unfortunate (and presumably unintended) consequence of this commit was that libiberty.a is no longer installed by default when building binutils CVS HEAD either. As libbfd and libopcodes still require its symbols, and both are built static-only by default, this change renders those libraries unusable. AFAICS another step is needed in the top-level configury to pass --enable-install-libiberty when bfd/opcodes is being built.
[Bug other/56780] --disable-install-libiberty still installs libiberty.a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 --- Comment #6 from Yaakov (Cygwin Ports) --- Not only that, but even with --enable-install-libiberty, it's not being installed in CVS HEAD. Don't you need to remove the resetting of target_header_dir in libiberty/configure.ac:408 (and hence libiberty/configure:5510)?
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2 from Jason Merrill ---
The warning seems correct to me; within the scope of myenum (i.e. in the
initializers of other enumerators) the foo enumerator shadows the global foo.
typedef int foo;
enum class myenum
{
foo,
bar = foo // finds myenum::foo
};
If the order of the typedef and the enum is reversed, there is no warning
because there is no shadowing; in that case, if the foo enumerator had a
different name, the reference in the initializer of bar would just be an error.
[Bug c++/57527] [C++11] Nested variadic templates cause internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57527 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail. ||com --- Comment #3 from Daniel Krügler --- This problem still exists in gcc 4.9.0 20130519 (experimental). The corresponding error message here is: "main.cpp|15|required from here| main.cpp|15|internal compiler error: in unify, at cp/pt.c:16742"
[Bug target/57357] Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Andrew Pinski --- Since glibc controls the headers we (GCC) project cannot do anything. Why are you using -mno-sse on an user space application anyways?
[Bug rtl-optimization/57268] [4.9 Regression] c nested loops hang compiler in sched-deps.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57268 dinar at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from dinar at gcc dot gnu.org --- Fixed.
[Bug c/57531] New: lvalue required with comma operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57531
Bug ID: 57531
Summary: lvalue required with comma operator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vijunag at gmail dot com
Following expression cannot be compiled using gcc-4.7.2 where as the same
statement is perfectly acceptable by gcc version 4.4.5
(void) 0, a = b;
[vinag]$ ~/tools/bintools/linux-x86/gcc/201302221200/bin/i686-pc-linux-gnu-gcc
-v
Using built-in specs.
COLLECT_GCC=~/tools/bintools/linux-x86/gcc/201302221200/bin/i686-pc-linux-gnu-gcc-wrapped
COLLECT_LTO_WRAPPER=~/tools/bintools/linux-x86/gcc/201302221200/libexec/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../../gcc/configure --build=amd64-pc-linux-gnu
--host=amd64-pc-linux-gnu --target=i686-pc-linux-gnu --enable-languages=c,c++
--prefix=/ws/vinag-bgl/tools/bintools/linux-x86/gcc/201302221200
--enable-shared --with-headers=/tmp/201302221200/new_header/
--disable-libquadmath --disable-libgomp --disable-libssp --disable-libmudflap
--disable-libitm --with-fast-fixincludes --enable-threads --site=starent
--with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 4.7.2 (GCC)
Program:
vijay:/home/vijay]$ cat ternary.c
#include
int main()
{
int a;
(void )0, a = 4;
}
[vijay]i686-pc-linux-gnu-gcc lvalue.cpp -c
lvalue.cpp: In function ‘void lvalue_assignment()’:
lvalue.cpp:6:27: error: lvalue required as left operand of assignment
vijay:/home/vijay]$ gcc ternary.c -o ternary.c.out
vijay:/home/vijay]$ gcc -v
Using built-in specs.
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-multiarch
--enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu
--target=i686-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
[Bug c/57531] lvalue required with comma operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57531 vijay Nag changed: What|Removed |Added Severity|normal |critical
[Bug c++/57531] lvalue required with comma operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57531 Andrew Pinski changed: What|Removed |Added Severity|critical|normal --- Comment #1 from Andrew Pinski --- Your small testcase works for me both in 4.7.0 and 4.9.0 (20130422). Your lvalue.cpp does not correspond to your testcase your placed in the bug report either.
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment #3 from Manuel López-Ibáñez ---
(In reply to Jason Merrill from comment #2)
> The warning seems correct to me; within the scope of myenum (i.e. in the
> initializers of other enumerators) the foo enumerator shadows the global foo.
But the global foo is a type while myenum::foo is not a type. Is there any
context where they can be used interchangeably?
enum class myenum
{
bar = int
};
doesn't make sense.
[Bug c++/51908] [C++11] ICE in cp_parser_abort_tentative_parse with decltype and variable template arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51908 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini --- On it.
[Bug c++/57528] Missed warning for putting reference to temporary in class member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57528 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Jonathan Wakely --- This is the same as the example in Bug 49974 comment 2 and Bug 986 Comment 31
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776
--- Comment #4 from Jonathan Wakely ---
(In reply to Manuel López-Ibáñez from comment #3)
> But the global foo is a type while myenum::foo is not a type. Is there any
> context where they can be used interchangeably?
>
> enum class myenum
> {
> bar = int
> };
>
> doesn't make sense.
How about this:
typedef int foo;
enum class myenum
{
foo = 1,
bar = (foo)+1
};
What is the value of myenum::bar? Is it clear and unambiguous, or should there
be a warning?
[Bug target/57357] Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357
--- Comment #9 from thutt at vmware dot com ---
(In reply to Andrew Pinski from comment #8)
> Since glibc controls the headers we (GCC) project cannot do anything.
???
>From your standpoint of having cpp produce different output, I understand
your position that the gcc project cannot do anything.
If you look from the standpoint of the user of gcc, that position makes
little sense: changing the value of a compiler option should not cause
code to suddenly produce an error.
The problem doesn't lie in the header file, though it could be fixed there
with preprocessor work.
The problem really lies in the fact that the compiler is producing
an error message for a function that has been parsed, but has not been used:
extern __inline __attribute__ ((__gnu_inline__)) double
__NTH (wcstod (__const wchar_t *__restrict __nptr,
wchar_t **__restrict __endptr))
{ return __wcstod_internal (__nptr, __endptr, 0); }
>From the standpoint of the user, that particular issue
*is* addressable by the gcc team.
Course, that's from the standpoint of the user...
> Why are you using -mno-sse on an user space application anyways?
I volunteer to file defects against gcc because I have an open account,
but I can't speak to the reasoning behind each one that is provided to
me -- I just validate the information, and try to write up a good synopsis.
In this particular case, I think it was found during preliminary testing
before upgrading the compiler; it may have been a one-off by-hand program
to do some other testing, I don't really know... I can go back and ask if you
are really curious...
For the team that I work on, we don't want hardware-using FPU code generated,
mostly.
That was the genesis of the other sse-related ticket I recently filed.
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776
--- Comment #5 from Jonathan Wakely ---
A better example:
typedef unsigned char foo;
enum class myenum
{
foo,
bar = (foo)-1
};
Is the value -1L or 255?
If I rename myenum::foo to myenum::Foo the code silently changes meaning.
[Bug c++/55776] -Wshadow generates an incorrect warning with enum classes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55776 --- Comment #6 from Jonathan Wakely --- It also changes meaning if I reorder the declarations of myenum::foo and myenum::bar, which is exactly the sort of fragile code that deserves a warning.
