[Bug target/52568] suboptimal __builtin_shuffle on cycles with AVX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52568 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-16 07:40:13 UTC --- Should be fixed on the trunk. For -mavx2 we now generate vpermpd, for -mavx vpermilpd + vperm2f128 + vblendpd.
[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594 --- Comment #2 from Jos de Kloe kloedej at knmi dot nl 2012-03-16 08:28:11 UTC --- Thanks for your answer. Using stop 0 or stop 1 would indeed be a way around, but the awkward thing is that I do have some requirements to produce different values for the exit status for different error conditions. So using stop 1 everywhere is no solution for me. Anyway, this bug is just a feature request, so it is up to you developers to decide if you want to implement this or not.
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2012-03-16 08:44:50 UTC --- (In reply to comment #6) Thanks for looking at this. The first step is to run readelf --debug=line FILE to make sure that the line number information is recorded correctly. Which of course it probably is. If you have trouble parsing the --debug=line output, try --debug=decodedline. The place that Go is reading that information is libgo/go/debug/dwarf/line.go. Most likely something is going wrong in the way that it gathers the information, but I don't know what. Something happens at line 48 (is_stmt is briefly toggled and Discriminator is set): Special opcode 9: advance Address by 0 to 0x120004dd8 and Line by 4 to 47 Special opcode 76: advance Address by 20 to 0x120004dec and Line by 1 to 48 Special opcode 18: advance Address by 4 to 0x120004df0 and Line by -1 to 47 Special opcode 20: advance Address by 4 to 0x120004df4 and Line by 1 to 48 Extended opcode 4: set Discriminator to 2 Set is_stmt to 0 Special opcode 33: advance Address by 8 to 0x120004dfc and Line by 0 to 48 Extended opcode 4: set Discriminator to 2 Set is_stmt to 1 Special opcode 118: advance Address by 32 to 0x120004e1c and Line by 1 to 49 Extended opcode 4: set Discriminator to 2 Special opcode 18: advance Address by 4 to 0x120004e20 and Line by -1 to 48 Extended opcode 4: set Discriminator to 2 Special opcode 20: advance Address by 4 to 0x120004e24 and Line by 1 to 49 Extended opcode 4: set Discriminator to 2 Special opcode 116: advance Address by 32 to 0x120004e44 and Line by -1 to 48 Also --debug=decodedline says: log_test.go 47 0x120004dd8 log_test.go 48 0x120004dec log_test.go 47 0x120004df0 log_test.go 48 0x120004df4 UNKNOWN: length 2 log_test.go 48 0x120004dfc UNKNOWN: length 2 log_test.go 49 0x120004e1c It is probably this UNKNOWN that disturbs decoding.
[Bug c++/52596] [4.7/4.8 Regression] [C++11] internal compiler error: in lvalue_kind, at cp/tree.c:153
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52596 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Summary|[4.7 Regression] [C++11]|[4.7/4.8 Regression] |internal compiler error: in |[C++11] internal compiler |lvalue_kind, at |error: in lvalue_kind, at |cp/tree.c:153 |cp/tree.c:153 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-16 08:46:23 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=174499
[Bug c++/52597] [C++11] missing diagnostics for invalid use of non-static member function in decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52597 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-16 08:59:29 UTC --- With 4.7.0 you get t.cc:4:16: error: decltype cannot resolve address of overloaded function t.cc: In member function ‘void A::bar1()’: t.cc:6:49: error: decltype cannot resolve address of overloaded function t.cc:6:52: error: invalid type in declaration before ‘;’ token t.cc: In member function ‘void A::bar2()’: t.cc:9:43: error: decltype cannot resolve address of overloaded function t.cc:9:46: error: invalid type in declaration before ‘;’ token t.cc: At global scope: t.cc:14:25: error: decltype cannot resolve address of overloaded function t.cc:14:28: error: invalid type in declaration before ‘;’ token
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-16 09:55:26 UTC --- I've found that this failure on Solaris --- FAIL: net.TestMulticastListener (0.00 seconds) sockoptip.go:67: First ListenMulticastUDP failed: setsockopt: Invalid argument is caused by Solaris using sockoptip_linux.go, which passes an int to setsockopt for IP_MULTICAST_LOOP, where Solaris expects and unsigned char. I'm fixing this by using a new sockoptip_solaris.go which does this right. I'm now running into --- FAIL: net.TestMulticastListener (0.00 seconds) sockoptip.go:118: 224.0.0.254:12345 not found in RIB still looking what's going on here. And the pollServer WaitFD: select: Bad file number errors here and in net/http and net/http/httputil remain. Rainer
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||bkoz at redhat dot com --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-16 10:00:38 UTC --- To be clear: the way the thing is supposed to work, **only** basic_string should be special, because **only** the extern template for basic_string are guarded by #if _GLIBCXX_EXTERN_TEMPLATE 0 instead of #if _GLIBCXX_EXTERN_TEMPLATE. If something special is happening elsewhere then it's an unintended bug. Now, if something got broken lately, like those sed, I have no idea, certainly I didn't change that. But, please post and discuss the issue and tentative fixes on the libstdc++ mailing list, not here. Benjamin, any idea about those sed?
[Bug c++/52599] New: illegal constexpr constructor declaration make g++ assert instead of returning an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52599 Bug #: 52599 Summary: illegal constexpr constructor declaration make g++ assert instead of returning an error Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mickael.gu...@st.com Created attachment 26902 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26902 This test make g++ to assert when compiling attach file with 'g++ -std=c++0x test.cpp' compiler assert in build_constexpr_constructor_member_initializers function from cp/semantics.c. g++ should instead return an error since construct is illegal.
[Bug c++/52599] ICE on illegal constexpr constructor declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52599 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-03-16 Summary|illegal constexpr |ICE on illegal constexpr |constructor declaration |constructor declaration |make g++ assert instead of | |returning an error | Ever Confirmed|0 |1
[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540 --- Comment #15 from Pawel Sikora pluto at agmk dot net 2012-03-16 10:27:53 UTC --- (In reply to comment #14) Now, if something got broken lately, like those sed, I have no idea, certainly I didn't change that. But, please post and discuss the issue and tentative fixes on the libstdc++ mailing list, not here. ok, sent: http://gcc.gnu.org/ml/libstdc++/2012-03/msg00103.html
[Bug c++/52599] ICE on illegal constexpr constructor declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52599 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|mickael.guene at st dot com |jason at gcc dot gnu.org --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-16 10:39:42 UTC --- Actually, the gcc_assert triggering is that in build_data_member_initialization: t is a TRY_BLOCK (of course) at that point. Not sure at the moment if we should diagnose the issue here or earlier. Maybe Jason has tips..
[Bug target/52593] Builtin sqrt on x86 is not correctly rounded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52593 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||i?86-*-* Status|WAITING |NEW Version|unknown |4.6.4 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-16 10:53:12 UTC --- Confirmed. I think sqrt is special (compared to sin, cos, etc.) because it's one of the core IEEE arithmetic functions. I suppose correct rounding is only ensured for 80bit long double. It will of course be an unexpected performance drop for most people with no additional benefit as the libm implementation is wrong as well :/
[Bug c/52600] New: OpenMP: declaration as structured block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52600
Bug #: 52600
Summary: OpenMP: declaration as structured block
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: openmp, rejects-valid
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Found at
http://openmp.org/forum/viewtopic.php?f=10t=1329sid=58cf62c9cbfc7fee81768f053e079615
... and there believed to be valid. GCC rejects the following:
#pragma omp task
int x = foo();
with
error: expected expression before ‘int’
While the following, syntactically identical (?), is accepted:
#pragma omp task
{ int x = foo(); }
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-03-16 11:03:28 UTC --- I'm now running into --- FAIL: net.TestMulticastListener (0.00 seconds) sockoptip.go:118: 224.0.0.254:12345 not found in RIB still looking what's going on here. And the No wonder this doesn't work: the code ultimately calls interfaceMulticastAddrTable, but Solaris uses interface_stub.go, and none of the other implementations are remotely usable. I concoct something using the SIOCGLIFNUM and SIOCGLIFCONF ioctls. Rainer
[Bug go/52583] Several new go testsuite failues on Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52583 --- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-03-16 11:05:33 UTC --- (In reply to comment #8) I'm now running into --- FAIL: net.TestMulticastListener (0.00 seconds) sockoptip.go:118: 224.0.0.254:12345 not found in RIB still looking what's going on here. And the Please see [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00639.html
[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-16 11:13:17 UTC --- (In reply to comment #2) Thanks for your answer. Using stop 0 or stop 1 would indeed be a way around I am lost. With GCC 4.6 and an explicit -fbacktrace, I *do* get a backtrace for any nonzero integer/exit status in STOP/ERROR STOP. (And none for zero.) In GCC 4.7 and 4.8 (which have -fbacktrace already implicitly), I *do* *not* get a backtrace for STOP/ERROR STOP, independent whether the integer is nonzero or not. Anyway, this bug is just a feature request, so it is up to you developers to decide if you want to implement this or not. I still believe that GCC 4.7 and 4.8 handle it - by default - as you would like. (Cf. http://gcc.gnu.org/wiki/GFortranBinaries ; if you are under Linux, your distribution will likely have some 4.7 packages available - either in some special branch or in their development version, cf. also http://gcc.gnu.org/wiki/GFortranDistros)
[Bug fortran/52594] no traceback expected for explicit fortran stop command combined with -fbacktrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52594 --- Comment #4 from Jos de Kloe kloedej at knmi dot nl 2012-03-16 11:36:48 UTC --- I am lost. The way around that I mentioned was for gcc 4.7+ (so I cannot test this right away, but will upgrade as soon as it is feasible for me). Anyway, thanks for your thoughts.
[Bug middle-end/48814] [4.5/4.6/4.7/4.8 Regression] Incorrect scalar increment result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-16 11:48:54 UTC --- Author: rguenth Date: Fri Mar 16 11:48:48 2012 New Revision: 185465 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185465 Log: 2012-03-16 Richard Guenther rguent...@suse.de Kai Tietz kti...@redhat.com PR middle-end/48814 * gimplify.c (gimplify_self_mod_expr): Evaluate postfix side-effects completely in the pre-queue and use a temporary for the result. * gcc.c-torture/execute/pr48814-1.c: New test. * gcc.c-torture/execute/pr48814-2.c: New test. * gcc.dg/tree-ssa/assign-1.c: New test. * gcc.dg/tree-ssa/assign-2.c: New test. * gcc.dg/tree-ssa/assign-3.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr48814-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr48814-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/assign-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/assign-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/assign-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/48814] [4.5/4.6/4.7 Regression] Incorrect scalar increment result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48814 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0 Resolution||FIXED Target Milestone|4.5.4 |4.8.0 Summary|[4.5/4.6/4.7/4.8|[4.5/4.6/4.7 Regression] |Regression] Incorrect |Incorrect scalar increment |scalar increment result |result Known to fail||4.7.1 --- Comment #13 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-16 11:49:39 UTC --- Fixed. Deliberately not backporting.
[Bug middle-end/52584] Fails to constant fold vector upper/lower half BIT_FIELD_REFs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52584 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-16 Ever Confirmed|0 |1
[Bug bootstrap/52601] New: Gcc build fails at Making all in tools with find: bad option -path and find: path-list predicate-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52601 Bug #: 52601 Summary: Gcc build fails at Making all in tools with find: bad option -path and find: path-list predicate-list Classification: Unclassified Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: critical Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: birender.si...@hotmail.com Machine Details: 1) uname -a SunOS slimsol9t4 5.9 Generic_122300-30 sun4u sparc SUNW,Sun-Fire-V240 2) isainfo -kv 64-bit sparcv9 kernel modules 3) ./config.guess sparc-sun-solaris2.9 Downloaded gcc-4.4.4.tar.gz, gmp-4.1.tar and mpfr-2.4.0.tar. configured, make and make install the gmp and mpfr successfully but received error while executing the make command for gcc-4.4.4 echo $LD_LIBRARY_PATH /usr/bin:/usr/local/lib:/usr/ccs/lib:/els/install/gcc-3.4.5/lib:/els/install/jdk1.6.0_16/jre/lib/sparc/:/els/install/jdk1.6.0_16/jre/lib/sparc/client:/els/install/staf/lib:/els/install/staf/lib/JSTAF.zip:/els/install/staf/lib/JSTAF.jar:/els/install/staf/services/STAFHTTP.jar:/els/install/staf/lib/java12:/usr/openwin/lib echo $PATH /els/install/jdk1.6.0_16/bin/:/els/install/gcc-3.4.5/bin:/els/install/staf/bin:/els/install/staf/services/STAFHTTP.jar:/usr/local/bin:/usr/ccs/bin:/usr/sbin:/usr/bin:/usr/ccs/bin:/usr/openwin/bin:/usr/dt/bin:/usr/platform/SUNW,Sun-Fire-V240/sbin:/opt/sun/bin:/opt/VRTS/bin:/etc/vx/bin:/opt/SUNWexplo/bin:/opt/SUNWsneep/bin Configured gcc with following command: ../../biru/gcc444/gcc-4.4.4/configure --prefix=/els/install/biru/local/gcc --build=sparc-sun-solaris2.9 --with-gmp=/els/install/biru/local/gmp --with-mpfr=/els/install/biru/local/mpfr and then executed: make Below are the error message received: make[6]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava/classpath/scripts' Making all in tools make[6]: Entering directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava/classpath/tools' Makefile:841: warning: overriding commands for target `gjdoc' Makefile:776: warning: ignoring old commands for target `gjdoc' find ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/external/asm -name '*.java' -print asm.lst find ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/gnu/classpath/tools \ ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/com/sun/javadoc \ ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/com/sun/tools/doclets \ ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/com/sun/tools/javadoc \ ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/com/sun/tools/javac \ ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/com/sun/tools/javah \ ../../../../../../../biru//gcc444/gcc-4.4.4/libjava/classpath/tools/sun/rmi/rmic \ -path '*gnu/classpath/tools/gjdoc' pattern -prune -o -path '*gnu/classpath/tools/doclets' pattern -prune -o GtternJDOC_EX = -path '*gnu/classpath/tools/gjdoc' pattern -prune -o -path '*gnu/classpath/tools/taglets' pattern -prune -o -path '*com/sun/javadoc' pattern -prune -o -path '*com/sun/tools/doclets' pattern -prune -o -path '*com/sun/tools/javadoc' pattern -prune -o \ -name '*.java' -print classes.lst find: bad option -path find: path-list predicate-list make[6]: *** [tools.zip] Error 1 make[6]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava/classpath/tools' make[6]: Entering directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava/classpath' true DO=all multi-do # make make[6]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava/classpath' make[5]: *** [all-recursive] Error 1 make[5]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava/classpath' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/sparcv9/libjava' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libjava' make[2]: *** [all-multi] Error 2 make[2]: Leaving directory `/els/install/gccbuild/gcc4/sparc-sun-solaris2.9/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/els/install/gccbuild/gcc4' make: *** [all] Error 2 Thanks, -Biru
[Bug middle-end/34212] spurious warning: value computed is not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34212 --- Comment #14 from Jonathan Liu net147 at gmail dot com 2012-03-16 13:38:18 UTC --- Created attachment 26903 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26903 Test case This test case gives a spurious 'warning: value computed is not used [-Wunused-value]' message when compiled with -Wall.
[Bug bootstrap/52601] Gcc build fails at Making all in tools with find: bad option -path and find: path-list predicate-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52601 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-16 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-16 13:38:21 UTC --- GCC 4.4.x are no longer supported. I suggest you try GCC 4.6.x and follow the install instructions for Solaris 2 closely.
[Bug c/52602] New: false compilation warning of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52602
Bug #: 52602
Summary: false compilation warning of uninitialized variable
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: asmwarr...@gmail.com
Hi, when building gdb, I found a false warning, the code is below:
static void
print_one_vtable (struct gdbarch *gdbarch, struct value *value,
int max_voffset,
struct value_print_options *opts)
{
int i;
struct type *type = check_typedef (value_type (value));
struct value *vtable;
CORE_ADDR vt_addr;
vtable = gnuv3_get_vtable (gdbarch, type,
value_address (value)
+ value_embedded_offset (value));
vt_addr = value_address (value_field (vtable,
vtable_field_virtual_functions));
printf_filtered (_(vtable for '%s' @ %s (subobject @ %s):\n),
TYPE_SAFE_NAME (type),
paddress (gdbarch, vt_addr),
paddress (gdbarch, (value_address (value)
+ value_embedded_offset (value;
for (i = 0; i = max_voffset; ++i)
{
struct value *vfn;
CORE_ADDR addr;
volatile struct gdb_exception ex;
printf_filtered ([%d]: , i);
vfn = value_subscript (value_field (vtable,
vtable_field_virtual_functions),
i);
if (gdbarch_vtable_function_descriptors (gdbarch))
vfn = value_addr (vfn);
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
addr = value_as_address (vfn);
}
if (ex.reason 0)
printf_filtered (_(error: %s), ex.message);
else
print_function_pointer_address (gdbarch, addr, gdb_stdout,
opts-addressprint);
printf_filtered (\n);
}
}
in GDB's source: gnu-v3-abi.c, the warning is:
.../../gdb/gdb/gnu-v3-abi.c: In function 'print_one_vtable.isra.2':
.../../gdb/gdb/gnu-v3-abi.c:892:33: error: 'addr' may be used uninitialized in
this function [-Werror=uninitialized]
and the bug is workaround by this patch:
http://sourceware.org/ml/gdb-cvs/2012-03/msg00203.html
Simply use: CORE_ADDR addr = 0;
Yuanhui Zhang
[Bug c/52602] false compilation warning of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52602 --- Comment #1 from asmwarrior asmwarrior at gmail dot com 2012-03-16 14:06:08 UTC --- BTW: here is the discussion in gdb's patch mail list. http://sourceware.org/ml/gdb-patches/2012-03/msg00585.html
[Bug target/52593] Builtin sqrt on x86 is not correctly rounded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52593 --- Comment #6 from Rich Felker bugdal at aerifal dot cx 2012-03-16 14:23:09 UTC --- The 387 FPU ensures correct rounding for the currently selected precision mode, which per the ABI is always extended precision. As for the usefulness of fixing this, I found the bug while working on my correct sqrt implementation in musl libc, because despite the existence of a correct version of the function, I was still getting wrong results. It turned out gcc was replacing it with a buggy builtin. I don't think glibc gets it wrong anyway is a reason not to fix the problem, especially now that glibc seems to be under new maintainership and actually fixing longstanding WONTFIX bugs. Folks who just care about speed and want to throw correctness away should already be using -ffast-math and similar. Actually since this bug is rounding-related, perhaps it would suffice to make -frounding-math turn off the builtin sqrt when using 387 math...?
[Bug middle-end/52584] Fails to constant fold vector upper/lower half BIT_FIELD_REFs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52584 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-16 14:49:11 UTC --- Author: rguenth Date: Fri Mar 16 14:49:05 2012 New Revision: 185468 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185468 Log: 2012-03-16 Richard Guenther rguent...@suse.de PR middle-end/52584 * fold-const.c (fold_ternary_loc): Fold vector typed BIT_FIELD_REFs of vector constants and constructors. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c
[Bug middle-end/52603] New: Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52603 Bug #: 52603 Summary: Test failures in gcc.dg/vect: vectorizing unaligned access Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: greta.yo...@arm.com CC: rguent...@suse.de Target: arm-none-eabi The patch for PR52571 causes the testsuite failures on arm in gcc.dg/vect tests related to vectorizing unaligned access. FAIL: gcc.dg/vect/vect-109.c scan-tree-dump-times vect Vectorizing an unaligned access 3 FAIL: gcc.dg/vect/vect-13.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-17.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-18.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-19.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-2-big-array.c scan-tree-dump-times vect Vectorizing an unaligned acce FAIL: gcc.dg/vect/vect-2.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-20.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-21.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-22.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-27.c scan-tree-dump-times vect Alignment of access forced using peeli FAIL: gcc.dg/vect/vect-29.c scan-tree-dump-times vect Alignment of access forced using peeli FAIL: gcc.dg/vect/vect-3.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-4.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-5.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-56.c scan-tree-dump-times vect Vectorizing an unaligned access 1 FAIL: gcc.dg/vect/vect-58.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-60.c scan-tree-dump-times vect Vectorizing an unaligned access 1 FAIL: gcc.dg/vect/vect-7.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-72.c scan-tree-dump-times vect Alignment of access forced using peeli FAIL: gcc.dg/vect/vect-73-big-array.c scan-tree-dump-times vect Vectorizing an unaligned acc FAIL: gcc.dg/vect/vect-73.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-77-global.c scan-tree-dump-times vect Vectorizing an unaligned access FAIL: gcc.dg/vect/vect-78-global.c scan-tree-dump-times vect Vectorizing an unaligned access FAIL: gcc.dg/vect/vect-86.c scan-tree-dump-times vect Alignment of access forced using peeli FAIL: gcc.dg/vect/vect-92.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-97-big-array.c scan-tree-dump-times vect Vectorizing an unaligned acc FAIL: gcc.dg/vect/vect-97.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-all-big-array.c scan-tree-dump-times vect Alignment of access forced FAIL: gcc.dg/vect/vect-all.c scan-tree-dump-times vect Alignment of access forced using peel FAIL: gcc.dg/vect/vect-multitypes-1.c scan-tree-dump-times vect Vectorizing an unaligned acc FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect Alignment of access forced u FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect Vectorizing an unaligned acc FAIL: gcc.dg/vect/vect-peel-3.c scan-tree-dump-times vect Vectorizing an unaligned access 1 FAIL: gcc.dg/vect/vect-peel-4.c scan-tree-dump-times vect Vectorizing an unaligned access 1 FAIL: gcc.dg/vect/vect-peel-4.c scan-tree-dump-times vect Alignment of access forced using p FAIL: gcc.dg/vect/slp-25.c scan-tree-dump-times vect Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/slp-25.c scan-tree-dump-times vect Alignment of access forced using peelin XFAIL-XPASS: XPASS: gcc.dg/vect/vect-60.c scan-tree-dump-times vect Vectorizing an unaligned access 2 XPASS: gcc.dg/vect/vect-56.c scan-tree-dump-times vect Vectorizing an unaligned access 2 XPASS: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect Alignment of access forced Trunk r185380 http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00972.html Configured with --target=arm-eabi --with-cpu=cortex-a9 --with-float=softfp --with-fpu=neon
[Bug libstdc++/52604] New: mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604 Bug #: 52604 Summary: mt allocator crashes on multi-threaded Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: laurent.alfo...@st.com Created attachment 26904 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26904 Testcase to reproduce There's a problem with mt_allocator when using multi-threads. see example attached (g++ -lpthread). At exit time, - the __freelist destructor is called. which does a __gthread_key_delete(_M_key). - and then afterwards, the std::list destructor is called. This finally have for effect to use that thread key with gthread_setspecific. Valgrind reports : = ==5212== Invalid read of size 8 ==5212==at 0x4CA009D: __gnu_cxx::__pooltrue::_M_get_thread_id() (in ../gcc-4.6.3/lib64/libstdc++.so.6.0.16) ==5212==by 0x4CA0173: __gnu_cxx::__pooltrue::_M_reclaim_block(char*, unsigned long) (in ../gcc-4.6.3/lib64/libstdc++.so.6.0.16) ==5212==by 0x401989: __gnu_cxx::__mt_allocstd::_List_nodestd::string, __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ::deallocate(std::_List_nodestd::string*, unsigned long) (in /tmp/a.out) ==5212==by 0x401847: std::_List_basestd::string, __gnu_cxx::__mt_allocstd::string, __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ::_M_put_node(std::_List_nodestd::string*) (in /tmp/a.out) ==5212==by 0x40168C: std::_List_basestd::string, __gnu_cxx::__mt_allocstd::string, __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ::_M_clear() (in /tmp/a.out) ==5212==by 0x40151A: std::_List_basestd::string, __gnu_cxx::__mt_allocstd::string, __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ::~_List_base() (in /tmp/a.out) ==5212==by 0x401BB1: std::liststd::string, __gnu_cxx::__mt_allocstd::string, __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true ::~list() (in /tmp/a.out) ==5212==by 0x3814E30C94: exit (in /lib64/tls/libc-2.3.4.so) ==5212==by 0x3814E1C411: (below main) (in /lib64/tls/libc-2.3.4.so) ==5212== Address 0x5b5ce88 is 24 bytes inside a block of size 65,536 free'd ==5212==at 0x4A077EC: operator delete(void*) (vg_replace_malloc.c:457) ==5212==by 0x3814E30C94: exit (in /lib64/tls/libc-2.3.4.so) ==5212==by 0x3814E1C411: (below main) (in /lib64/tls/libc-2.3.4.so) = I ve seen a quite close bug report (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309), that is already fixed in 4.0.0. This apparently leaded to re-write a part of mt_allocate (Jakub Jelinek). But this was not sufficient for the current bug report i m reporting. Thanks in advance. Laurent Alfonsi
[Bug libstdc++/52604] mt allocator crashes on multi-threaded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52604
--- Comment #1 from Laurent Aflonsi laurent.alfonsi at st dot com 2012-03-16
15:25:23 UTC ---
I would propose to fix as follows :
- Set the _M_Key=NULL when calling the freelist desctuctor.
- Testing the NULL Key before using it with setspecific.
see patch below :
===
--- libstdc++-v3/src/mt_allocator.cc(revision 2486)
+++ libstdc++-v3/src/mt_allocator.cc(working copy)
@@ -47,6 +47,7 @@
if (_M_thread_freelist_array)
{
__gthread_key_delete(_M_key);
+ _M_key = NULL;
::operator delete(static_castvoid*(_M_thread_freelist_array));
}
}
@@ -639,7 +640,8 @@
}
}
- __gthread_setspecific(freelist._M_key, (void*)_M_id);
+ if (freelist._M_key)
+ __gthread_setspecific(freelist._M_key, (void*)_M_id);
}
return _M_id = _M_options._M_max_threads ? 0 : _M_id;
}
===
Let me know what you think
Thanks very much
Laurent Alfonsi
[Bug c/52602] false compilation warning of uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52602 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-03-16 CC||manu at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-16 15:32:04 UTC --- I know it is a pain in the ass to generate a (minimal) preprocessed testcase, but this report is not very useful without it: http://gcc.gnu.org/bugs/ There are at least as many explanations for this as bugs are listed for PR24639.
[Bug lto/52605] New: LTO -g ICE when looking up context of VMTs of classes defined within functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52605 Bug #: 52605 Summary: LTO -g ICE when looking up context of VMTs of classes defined within functions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: jamb...@gcc.gnu.org Host: x86_64-linux-gnu Target: x86_64-linux-gnu Created attachment 26905 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26905 Testcase When compiling the attached testcase with -flto and -g, I get the following ICE: lto1: internal compiler error: tree check: expected tree that contains ‘decl minimal’ structure, have ‘record_type’ in lookup_decl_die, at dwarf2out.c:5118 This is the same problem I first encountered when LTOing Firefox and which I reported in the mailing list a while ago (http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00551.html) but this testcase is close to minimal. The reason why we do not hit this wrong use of decl_function_context without LTO is that the function dwarf2out_decl is never called on VMTs when not doing LTO.
[Bug tree-optimization/52571] vectorizer changes alignment of common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52571 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-16 16:48:38 UTC --- Author: rguenth Date: Fri Mar 16 16:48:31 2012 New Revision: 185474 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185474 Log: 2012-03-16 Richard Guenther rguent...@suse.de PR tree-optimization/52603 * tree-vect-data-refs.c (vect_can_force_dr_alignment_p): Clarify comment. Revert 2012-03-14 Richard Guenther rguent...@suse.de PR tree-optimization/52571 * tree-vect-data-refs.c (vect_compute_data_ref_alignment): Move flag_section_anchors check ... (vect_can_force_dr_alignment_p): ... here. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug middle-end/52603] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52603 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-16 16:48:38 UTC --- Author: rguenth Date: Fri Mar 16 16:48:31 2012 New Revision: 185474 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185474 Log: 2012-03-16 Richard Guenther rguent...@suse.de PR tree-optimization/52603 * tree-vect-data-refs.c (vect_can_force_dr_alignment_p): Clarify comment. Revert 2012-03-14 Richard Guenther rguent...@suse.de PR tree-optimization/52571 * tree-vect-data-refs.c (vect_compute_data_ref_alignment): Move flag_section_anchors check ... (vect_can_force_dr_alignment_p): ... here. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug middle-end/52603] Test failures in gcc.dg/vect: vectorizing unaligned access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52603 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-16 16:48:58 UTC --- Fixed.
[Bug middle-end/52584] Fails to constant fold vector upper/lower half BIT_FIELD_REFs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52584 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-03-16 16:54:43 UTC --- Fixed.
[Bug middle-end/51752] trans-mem: publication safety violated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51752 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Aldy Hernandez aldyh at gcc dot gnu.org 2012-03-16 18:44:53 UTC --- The committed patch on trunk and on the 4.7 branch resolves all the known issues. I can't come up with any more reproducible testcases for publication safety. If we find any, let's open a new PR naming the offending pass.
[Bug fortran/52606] New: Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 Bug #: 52606 Summary: Confusing diagnostics for long identifiers Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: anl...@gmx.de Excessively long identifiers can produce quite confusing diagnostics. Perhaps error recovery could be improved. Example: module gfcbug118 implicit none interface foo module procedure very_long_identifier_beyond_31char end interface contains subroutine very_long_identifier_beyond_31char () end subroutine very_long_identifier_beyond_31char end module gfcbug118 % gfc gfcbug118.f90 -std=f95 gfcbug118.f90:4.54: module procedure very_long_identifier_beyond_31char 1 Error: Name at (1) is too long gfcbug118.f90:7.45: subroutine very_long_identifier_beyond_31char () 1 Error: Name at (1) is too long gfcbug118.f90:8.5: end subroutine very_long_identifier_beyond_31char 1 Error: Expecting END MODULE statement at (1) gfcbug118.f90:9.20: end module gfcbug118 1 Error: Fortran 2008: CONTAINS statement without FUNCTION or SUBROUTINE statement at (1) % gfc gfcbug118.f90 -fmax-identifier-length=31 gfcbug118.f90:4.54: module procedure very_long_identifier_beyond_31char 1 Error: Name at (1) is too long gfcbug118.f90:7.45: subroutine very_long_identifier_beyond_31char () 1 Error: Name at (1) is too long gfcbug118.f90:8.5: end subroutine very_long_identifier_beyond_31char 1 Error: Expecting END MODULE statement at (1)
[Bug c++/52521] [C++11] user defined literals and order of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521
Andy Webber andy at aligature dot com changed:
What|Removed |Added
CC||andy at aligature dot com
--- Comment #6 from Andy Webber andy at aligature dot com 2012-03-16 19:23:18
UTC ---
I've been playing around with a gcc 4.7.0 RC2 build and it seems like the user
defined literals might not be working at all now.
Building:
#include iostream
#include cstdlib
constexpr long double operator _degrees(long double d)
{
return d * 0.0175;
}
int main()
{
long double pi = 180_degrees;
std::cout pi std::endl;
}
Result:
literal.cpp: In function ‘int main()’:
literal.cpp:11:21: error: unable to find numeric literal operator ‘operator
_degrees’
[Bug c++/33101] Bad C++ error on invalid code: anonymous has incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101
Keith Thompson Keith.S.Thompson at gmail dot com changed:
What|Removed |Added
CC||Keith.S.Thompson at gmail
||dot com
--- Comment #10 from Keith Thompson Keith.S.Thompson at gmail dot com
2012-03-16 19:26:45 UTC ---
This came up in a question on stackoverflow.com:
http://stackoverflow.com/q/9742135/827263
I believe the code is valid. Here's a simpler test case:
typedef void VOID;
int main(VOID) { }
which g++ 4.5.2 rejects with the following:
void_test.cpp:2:10: error: ‘anonymous’ has incomplete type
void_test.cpp:2:14: error: invalid use of ‘VOID’
Quoting N3290, a draft of the 2011 ISO C++ standard, section 8.3.5 [dcl.fct]:
The parameter-declaration-clause determines the arguments that can
be specified, and their processing, when the function is called.
[ ... ] If the parameter-declaration-clause is empty, the function
takes no arguments. The parameter list (void) is equivalent to
the empty parameter list. Except for this special case, void
shall not be a parameter type (though types derived from void,
such as void*, can).
Earlier versions of the standard have similar or identical wording.
The last sentence implies that void here is being used as a type
name, not as some special-case syntactic use of the keyword. I believe
the phrase special case is meant to exclude declarations like
void foo(void, int);
or
void bar(void param);
not to prohibit the use of a typedef. Since a typedef creates an
*alias* for an existing type, the name VOID should be usable as a
replacement for void whenever it's used as a type name.
Note that the syntax for a parameter-declaration does not refer
specifically to the void keyword; rather, void is valid in that
context because it's a type name.
Practically speaking, the purpose of allowing void as a parameter
declaration is for compatibility with C. Quoting the latest draft
of the C standard, N1570 6.7.6.3p10:
The special case of an unnamed parameter of type void as the only
item in the list specifies that the function has no parameters.
It refers to the *type* void, not the keyword, implying that a
typedef is acceptable in this context -- and gcc 4.5.2 accepts the
above program without complaint when compiling it as C.
I agree that the C++ standard's wording is ambiguous, and *could*
be read as requiring the keyword void, but I believe the intent
is to permit a typedef. (And if you want to argue that the use of
a typedef is silly, I agree completely.)
I believe that the resolution of DR 577:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#577
confirms this. The resolution, as of August, 2011, suggests changing
the wording to refer to the *type* void rather than the keyword.
(That change doesn't appear in the N3270 draft; I don't know whether
it appears in the final ISO C++ 2011 standard.)
At the very least, since there is (unfortunately) real-world code that
depends on this, I suggest changing it from a fatal error to a warning,
though I think removing the diagnostic altogether would be better.
[Bug c++/33101] Bad C++ error on invalid code: anonymous has incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101 --- Comment #11 from Keith Thompson Keith.S.Thompson at gmail dot com 2012-03-16 19:30:17 UTC --- And since the C++ code is valid, the title of this bug should be changed.
[Bug c++/52521] [C++11] user defined literals and order of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521
--- Comment #7 from Marc Glisse marc.glisse at normalesup dot org 2012-03-16
19:39:14 UTC ---
(In reply to comment #6)
constexpr long double operator _degrees(long double d)
{
return d * 0.0175;
}
int main()
{
long double pi = 180_degrees;
std::cout pi std::endl;
}
There is no dot in 180, so it is looking for an unsigned long long overload
(which you could provide). 180._degrees works.
[Bug c++/52521] [C++11] user defined literals and order of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521
--- Comment #8 from Andy Webber andy at aligature dot com 2012-03-16 20:06:52
UTC ---
Ah, that fixes it. It could be good to update the release notes to match.
Thanks to Ed Smith-Rowland, G++ now implements C++11 user-defined literals.
// Not actually a good approximation. :)
constexpr long double operator _degrees (long double d) { return d * 0.0175;
}
long double pi = 180_degrees;
long double pi = 180.0_degrees;
[Bug c++/33101] [DR 577] Bad C++ error on invalid code: anonymous has incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Summary|Bad C++ error on invalid|[DR 577] Bad C++ error on |code: anonymous has |invalid code: anonymous |incomplete type |has incomplete type --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-16 20:17:02 UTC --- (In reply to comment #10) I believe that the resolution of DR 577: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#577 confirms this. The resolution, as of August, 2011, suggests changing the wording to refer to the *type* void rather than the keyword. (That change doesn't appear in the N3270 draft; I don't know whether it appears in the final ISO C++ 2011 standard.) It doesn't, the DR says [Voted into the WP at the February, 2012 meeting.] i.e. after the 2011 standard. At the very least, since there is (unfortunately) real-world code that depends on this, I suggest changing it from a fatal error to a warning, though I think removing the diagnostic altogether would be better. Since GCC, Clang and EDG all reject it today I'm surprised such real-world code hasn't been changed already.
[Bug c++/33101] [DR 577] allow typedefs for void in empty parameter list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords|diagnostic |rejects-valid Summary|[DR 577] Bad C++ error on |[DR 577] allow typedefs for |invalid code: anonymous |void in empty parameter |has incomplete type |list --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-16 20:37:33 UTC --- (In reply to comment #10) I agree that the C++ standard's wording is ambiguous, and *could* be read as requiring the keyword void, but I believe the intent is to permit a typedef. (And if you want to argue that the use of a typedef is silly, I agree completely.) I believe that the resolution of DR 577: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#577 confirms this. No, that issue confirms quite clearly that before that change (which only happened last month and is not part of C++98, C++03 or C++11) the code was definitely invalid: The C99 formulation allows typedefs for void, while C++ (and C90) accept only the keyword itself in this role. The language was not ambiguous and the intent wasn't clarified by DR 577, the rule was changed so previously invalid code is now valid. Subject and keywords changed to match the new status.
[Bug target/52474] Regression: AVR-GCC: arithmetics produce completely wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52474 --- Comment #8 from wwieser at gmx dot de 2012-03-16 20:44:54 UTC --- @Georg-Johann Lay: Thank you very much for that quick response. Obviously, the toolchain you use comes with bad patches. I agree.
[Bug c++/52521] [C++11] user defined literals and order of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-16 20:50:14 UTC --- What in the release notes should be updated? The standard says that for 180_degrees the compiler should try to call operator _degrees (180ULL) (if operator _degrees (unsigned long long) exists), or operator _degrees (180) (if operator _degrees (const char *) exists), or operator _degrees '1', '8', '0' () (if literal operator template exists). So your testcase is invalid.
[Bug c++/52521] [C++11] user defined literals and order of declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-16 20:52:47 UTC --- Ah, sorry, you're right, fixed up gcc-4.7/changes.html.
[Bug libstdc++/52476] [DR 518] Unordered multimap reorders equivalent elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52476 --- Comment #5 from François Dumont fdumont at gcc dot gnu.org 2012-03-16 21:03:24 UTC --- Author: fdumont Date: Fri Mar 16 21:03:15 2012 New Revision: 185476 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185476 Log: 2012-03-15 François Dumont fdum...@gcc.gnu.org PR libstdc++/52476 * include/bits/hashtable.h (_Hashtable::_M_rehash_aux): Add. (_Hashtable::_M_rehash): Use the latter. * testsuite/23_containers/unordered_multimap/insert/52476.cc: New. * testsuite/23_containers/unordered_multiset/insert/52476.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/52476.cc trunk/libstdc++-v3/testsuite/23_containers/unordered_multiset/insert/52476.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable.h
[Bug c++/33101] [DR 577] allow typedefs for void in empty parameter list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101 --- Comment #14 from Keith Thompson Keith.S.Thompson at gmail dot com 2012-03-16 21:41:18 UTC --- On re-reading DR 577, I agree that it implies the current standard says that only (void) is allowed, and in particular that a typedef is not. I might have interpreted it differently myself, but I defer to the committee. (I thought perhaps that the change had been made between N3290 and the released standard, but apparently that's not the case.) The fact that C90 required the keyword further weakens my previous argument. So the diagnostic is necessary, but I'd still suggest that a warning would be more appropriate, and would still meet the current standard's requirements. (I should mention that I have no need for this myself; I don't even take advantage of the permission to use (void) rather than ().)
[Bug c++/33101] [DR 577] allow typedefs for void in empty parameter list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33101 --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-16 21:46:05 UTC --- (In reply to comment #14) (I thought perhaps that the change had been made between N3290 and the released standard, but apparently that's not the case.) See the text in bold at the top of the issues list: Issues with DR and WP status are NOT part of the International Standard for C++. The fact that C90 required the keyword further weakens my previous argument. So the diagnostic is necessary, but I'd still suggest that a warning would be more appropriate, and would still meet the current standard's requirements. The current standard is C++11, that change is only in the current *draft* and that's not a standard. (I should mention that I have no need for this myself; I don't even take advantage of the permission to use (void) rather than ().) Good, it's an abomination!
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-03-16 CC||steven at gcc dot gnu.org Ever Confirmed|0 |1
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606
--- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2012-03-16
23:18:26 UTC ---
Someting as trivial as the following would perhaps already help (not tested):
Index: match.c
===
--- match.c(revision 185477)
+++ match.c(working copy)
@@ -546,8 +546,8 @@ gfc_match_name (char *buffer)
if (i gfc_option.max_identifier_length)
{
- gfc_error (Name at %C is too long);
- return MATCH_ERROR;
+ gfc_error_now (Name at %C is too long);
+ goto too_long_or_done;
}
old_loc = gfc_current_locus;
@@ -555,6 +555,7 @@ gfc_match_name (char *buffer)
}
while (ISALNUM (c) || c == '_' || (gfc_option.flag_dollar_ok c == '$'));
+too_long_or_done:
if (c == '$' !gfc_option.flag_dollar_ok)
{
gfc_error (Invalid character '$' at %C. Use -fdollar-ok to allow it
Ideally, we'd just accept long identifiers, but the maximum name length is
hard-coded (GFC_MAX_SYMBOL_LEN) and already way too large. I want to change
this to string pointers (probably using a string pool, maybe the GCC common
implementation, TBD).
[Bug c/31893] Please provide an inout attribute for function parameters.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31893 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-16 23:22:35 UTC --- (In reply to comment #5) There is no support for this in the middle-end anyway. Not even for Fortran. And with GCC 4.7.0, there is, and FORTRAN is using it. See PR43665 and http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00895.html but there is no external interface exposing this functionality in C/C++. That thread includes some suggestions. If you are still interested, you could try to submit a patch implementing some of the suggestions.
[Bug c/52283] error: case label does not reduce to an integer constant for constant folded cast expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52283 --- Comment #25 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-03-16 23:26:08 UTC --- (In reply to comment #24) I think you need to add a Changelog and submit it to gcc-patches. Both 4.6.3 and 4.7.0 are about to be released, so you may need to wait until they are (or not, I am not following closely the current status) OK, do you have an entry that comes with your patch (stmt,c and convert.c) ? Feel free to write whatever you like in the ChangeLog. I'll submit the whole thing to gcc-patches. Thanks!
[Bug middle-end/45579] Re-enable IPA-CP for fn spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45579 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||steven at gcc dot gnu.org
[Bug tree-optimization/38401] TreeSSA-PRE load after store missed optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW CC||ramana at gcc dot gnu.org --- Comment #26 from Steven Bosscher steven at gcc dot gnu.org 2012-03-16 23:53:14 UTC --- (In reply to comment #25) (In reply to comment #24) Unfortunately, there is still no word from the FSF on what they did with our Copyright Assignment. As already mentioned in PR 38785, I've posted the patch here: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00250.html It is also integrated in the milepost-branch. I am not working on this, but Ramana is working on partial-partial PRE and may be interested in porting over that patch from comment #25.
[Bug middle-end/41004] missed merge of basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41004 --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2012-03-16 23:59:41 UTC --- Ehm, why does tree tail-merge not run at -Os? It's a size optimization, after all!
[Bug other/52438] [4.7 Regression] Some files still GPLv2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52438 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Summary|Some files still GPLv2 |[4.7 Regression] Some files ||still GPLv2 --- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2012-03-17 00:02:43 UTC --- Regression -- well for some definition of regression anyway, namely releasing code with two different licenses -- to bring on radar for RMs.
[Bug rtl-optimization/33828] Issues with code hoisting implementation in gcse.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33828 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #15 from Steven Bosscher steven at gcc dot gnu.org 2012-03-17 00:04:49 UTC --- Issues mentioned here are solved (at least, sufficiently so for me).
[Bug middle-end/43631] var-tracking inserts notes with non-NULL BLOCK_FOR_INSN in between basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43631 --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-03-17 00:05:48 UTC --- (In reply to comment #3) Jakub, please do not forget about this one for stage1 GCC 4.7. Jakub, please do not forget about this one for stage1 GCC 4.8.
[Bug target/52607] New: v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
Bug #: 52607
Summary: v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
Hello,
this is really just a follow-up to PR52568. The permutations {0,2,1,3} and
{1,3,0,2} can be realized with a very similar technique.
Starting from 0123:
vpermilpd+vperm2f128-3210
vblendpd(0123,3210)-0213
or:
vpermilpd-1032
vperm2f128-2301
vblendpd(1032,2301)-1302
I am not sure if there is a nice way to generalize this or if the function
expand_vec_perm_vperm2f128_vblend should be cloned a few times and slightly
modified.
(these permutations are less important to me than 1230 was)
[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #1 from Marc Glisse marc.glisse at normalesup dot org 2012-03-17
01:05:57 UTC ---
Note that {1,2,0,3} seems harder, I need one extra vpermilpd. Actually, it
looks like every v4df shuffle can be realized as a vblendpd of a vpermilpd and
a vpermilpd+vperm2f128. For v8sf, it also seems true but may require the
version of vpermilps that takes its controls from a register/memory.
[Bug fortran/52606] Confusing diagnostics for long identifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org 2012-03-17 04:57:55 UTC --- (In reply to comment #1) Ideally, we'd just accept long identifiers, but the maximum name length is hard-coded (GFC_MAX_SYMBOL_LEN) and already way too large. I want to change this to string pointers (probably using a string pool, maybe the GCC common implementation, TBD). The OP used -std=f95, the max identifier is 31. gfortran's behavior is already ideal in that she correctly reports an error. If the OP finds the run-on diagnostics confusing, then OP should use -fmax-errors=1.
