[Bug regression/56751] New: Can not confugure stage 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56751 Bug #: 56751 Summary: Can not confugure stage 2 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: maxim.prohore...@gmail.com For gcc 4.7.2 work fine. ../gcc-4.7.2/configure --prefix=/usr/local/gcc-4.7.2 --disable-multilib --enable-languages=c,c++ --without-ppl --without-cloog --with-mpfr=/usr/local/mpfr-3.0.1 --with-mpc=/usr/local/mpc-0.9 --with-gmp=/usr/local/gmp-5.0.2 For gcc 4.8.0 work wrong. ../gcc-4.8.0/configure --prefix=/home/prohorenko/usr/local/gcc-4.8.0 --disable-multilib --enable-languages=c,c++ --without-ppl --without-cloog --with-mpfr=/usr/local/mpfr-3.0.1 --with-mpc=/usr/local/mpc-0.9 --with-gmp=/usr/local/gmp-5.0.2 If set LD_LIBRARY_PATH=/usr/local/mpc-0.9/lib/:/usr/local/mpfr-3.0.1/lib/:/usr/local/gmp-5.0.2/lib/:$LD_LIBRARY_PATH Then work fine too.
[Bug c++/56734] Even simple exceptions cause a segmentation fault in my build of gcc on Solaris 10.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56734 --- Comment #3 from Marc Girod marc.girod at gmail dot com 2013-03-27 06:52:14 UTC --- OK. Good to know. I configured with GNU, hence there is something in the tool chain which results in the problem. Under the debugger, I get the segfault stepping into the call to 'get_global()' in libstdc++-v3/libsupc++/eh_globals.cc:63. I can find only one declaration of this get_global, and it is earlier in eh_globals.cc:50. Looking at the decorations in the symbols: gcc nm ./sparc-sun-solaris2.10/libstdc++-v3/libsupc++/eh_globals.o U _GLOBAL_OFFSET_TABLE_ d _ZL16__gthread_active b _ZZN12_GLOBAL__N_110get_globalEvE6global T __cxa_get_globals T __cxa_get_globals_fast W __sparc_get_pc_thunk.l7 U __tls_get_addr I wonder if there is a mismatch between the offering and the request? What symbols do you have, in the Sun configuration? Note that I was handed another gcc, compiled independently for the same platform, and which displays the same issue.
[Bug regression/56751] Can not confugure stage 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56751 Максим Прохоренко maxim.prohorenko at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Максим Прохоренко maxim.prohorenko at gmail dot com 2013-03-27 06:54:43 UTC --- Work ok
[Bug c++/56734] Even simple exceptions cause a segmentation fault in my build of gcc on Solaris 10.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56734 --- Comment #4 from Marc Girod marc.girod at gmail dot com 2013-03-27 07:00:33 UTC --- Sorry: the other compiler works once I set LD_LIBRARY_PATH to use its libstdc++.so.6 and libgcc_s.so.1
[Bug middle-end/56748] Bogus uninitialized warning with nested if condition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56748
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
CC||burnus at gcc dot gnu.org
Component|fortran |middle-end
Summary|STOP statement + array |Bogus uninitialized warning
|optional variable causes|with nested if condition
|bogus uninitialized warning |
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-27
08:26:31 UTC ---
First remark: Bogus uninitialized warnings can not always be prevented. - It is
a extremely complex problem, where a few false warnings (and many missed
warnings) are unavoidable. Still, one should do better.
If one looks at the dump (-fdump-tree-original, i.e. a C-like output of the
internal representation), one sees:
mysub (struct array1_integer(kind=4) restrict a,
struct array1_integer(kind=4) * b)
{
...
if (b != 0B (integer(kind=4)[0:] * restrict) b-data != 0B)
b.0 = (integer(kind=4)[0:D.1925] * restrict) b-data;
...
if (b != 0B (integer(kind=4)[0:] * restrict) b-data != 0B)
...
if (b != 0B (integer(kind=4)[0:] * restrict) b-data != 0B)
{
// Here are some run-time checks, enabled by -fcheck=all
}
...
parm.10.data = (void *) (*b.0)[0];
_gfortran_transfer_array_write (dt_parm.9, parm.10, 4, 0);
As all if conditions are the same, b.0 is never uninitialized. However,
nesting the same b != NULL seems to confuse the uninitialized diagnostic.
[Bug c++/54988] fpmath=sse target pragma causes inlining failure because of target specific option mismatch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54988 --- Comment #13 from Kai Koehne kai.koehne at digia dot com 2013-03-27 09:12:42 UTC --- The OOM problem is still there with gcc 4.8.0 on MinGW: Any #pragma optimize X will result in OOM for big files.
[Bug c++/56742] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
--- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2013-03-27 09:40:16
UTC ---
(In reply to comment #3)
(In reply to comment #2)
Hmm, yes indeed it is the -freorder-blocks option. One solution is to
disallow after reload for SEH-target to modify jumps.
That's an awfully big hammer. Perhaps it's possible to first analyze
what is actually happening in bbreorder that causes this bug?
Well, the issue is analyzed. The issue is that SEH is table-based EH, and so
after bb-reorder used labels for describing eh-regions are getting invalid.
If you take a look to the produces assembly for the example, you will notice
that easily.
I admit that the first patch is a bit too invasive, as it disables bb-reorder
in all cases. But in fact we need to disable it just if there is a
catch-region. A more improved variant is:
Index: i386.c
===
--- i386.c (Revision 197118)
+++ i386.c (Arbeitskopie)
@@ -3941,6 +3941,20 @@
register_pass (insert_vzeroupper_info);
}
+/* Implement TARGET_CANNOT_MODIFY_JUMPS_P. */
+static bool
+ix86_cannot_modify_jumps_p (void)
+{
+ if (TARGET_SEH reload_completed
+ cfun cfun-eh
+ cfun-eh-region_tree)
+return true;
+ return false;
+}
+
+#undef TARGET_CANNOT_MODIFY_JUMPS_P
+#define TARGET_CANNOT_MODIFY_JUMPS_P ix86_cannot_modify_jumps_p
+
/* Update register usage after having seen the compiler flags. */
static void
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Known to work||4.7.2 Keywords||memory-hog Last reconfirmed||2013-03-27 Ever Confirmed|0 |1 Summary|4.8 regression: increased |[4.8 regression] increased |memory usage when compiling |memory usage when compiling |C++ |C++ Target Milestone|--- |4.8.1 Known to fail||4.8.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 09:50:41 UTC --- Please provide preprocessed source of the file that shows this change in behavior. Also provide the options you used for compiling.
[Bug tree-optimization/56695] [4.9 Regression] ICE in expand_vec_cond_expr, at optabs.c:6751
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56695
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27
09:53:59 UTC ---
(In reply to comment #2)
In tree-vect-stmts.c:
if (!INTEGRAL_TYPE_P (TREE_TYPE (vectype)))
{
unsigned int prec = GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (vectype)));
tree cmp_type = build_nonstandard_integer_type (prec, 1);
vec_cmp_type = get_same_sized_vectype (cmp_type, vectype);
if (vec_cmp_type == NULL_TREE)
return false;
}
It doesn't check if vectype is signed, and anyway it explicitly asks for an
unsigned type. Changing those 2 things seems to help. I am away next week,
can't try a patch now.
vectype is the vector type of the COND_EXPR result - it should obviously
use the signedness of the scalar condition operands.
[Bug tree-optimization/56695] [4.9 Regression] ICE in expand_vec_cond_expr, at optabs.c:6751
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56695 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 09:57:41 UTC --- That said, it should look like, unconditionally(!) unsigned int prec = GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (vectype))); tree cmp_type = build_nonstandard_integer_type (prec, TYPE_UNSIGNED (TREE_OPERAND (cond_expr, 0))); vec_cmp_type = get_same_sized_vectype (cmp_type, vectype); if (vec_cmp_type == NULL_TREE) return false; whether the result is integral or not doesn't matter. You can still have foo_signed = uns1 uns2 ? bar_signed : bar2_signed;
[Bug c++/45282] wrong decltype result for .*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45282 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|gcc-bugs at gcc dot gnu.org | Known to work||4.8.1, 4.9.0 Resolution||FIXED --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-27 10:03:07 UTC --- Fixed mainline and 4.8.1.
[Bug c++/52597] [C++11] confusing diagnostics for invalid use of non-static member function in decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52597 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-27 10:06:30 UTC --- Fixed for 4.9.
[Bug tree-optimization/56695] [4.9 Regression] ICE in expand_vec_cond_expr, at optabs.c:6751
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56695
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27
10:08:02 UTC ---
(In reply to comment #9)
That said, it should look like, unconditionally(!)
unsigned int prec = GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (vectype)));
tree cmp_type = build_nonstandard_integer_type (prec,
TYPE_UNSIGNED (TREE_OPERAND (cond_expr, 0)));
vec_cmp_type = get_same_sized_vectype (cmp_type, vectype);
if (vec_cmp_type == NULL_TREE)
return false;
whether the result is integral or not doesn't matter. You can still have
foo_signed = uns1 uns2 ? bar_signed : bar2_signed;
Err, it's just the vector comparison result (boolean mask) type. So
if (!INTEGRAL_TYPE_P (TREE_TYPE (vectype))
|| !TYPE_UNSIGNED (TREE_TYPE (vectype)))
{
unsigned int prec = GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (vectype)));
tree cmp_type = build_nonstandard_integer_type (prec, 1);
vec_cmp_type = get_same_sized_vectype (cmp_type, vectype);
if (vec_cmp_type == NULL_TREE)
return false;
}
or simply unconditionally use an unsigned mask type:
unsigned int prec = GET_MODE_BITSIZE (TYPE_MODE (TREE_TYPE (vectype)));
tree cmp_type = build_nonstandard_integer_type (prec, 1);
vec_cmp_type = get_same_sized_vectype (cmp_type, vectype);
if (vec_cmp_type == NULL_TREE)
return false;
and remove the initialization of vec_cmp_type earlier.
[Bug tree-optimization/56695] [4.9 Regression] ICE in expand_vec_cond_expr, at optabs.c:6751
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56695 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 10:10:06 UTC --- And in tree-cfg.c:verify_gimple_comparison properly establish rules for the signedness of the vector comparison result.
[Bug c++/25466] typeid expression fails to throw bad_typeid according to 5.2.8p2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25466 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-27 10:13:29 UTC --- I'm having another look to this and apparently clang behaves like GCC. Jason, what do you think? Should we extend somehow build_typeid? I'm not sure. In case it would not be very hard, I think.
[Bug target/56734] Even simple exceptions cause a segmentation fault in my build of gcc on Solaris 10.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56734 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Component|c++ |target Resolution||DUPLICATE --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-27 10:22:44 UTC --- Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xff35af84 in __frame_dummy_init_array_entry () from /vobs/cello/cade_struct/lib/libstdc++.so.6 (gdb) bt #0 0xff35af84 in __frame_dummy_init_array_entry () from /vobs/cello/cade_struct/lib/libstdc++.so.6 #1 0xff2c8b48 in __cxxabiv1::__cxa_get_globals () at /proj/vobadm100/svn/gcc_4.7.2/libstdc++-v3/libsupc++/eh_globals.cc:63 #2 0xff2c7a10 in __cxxabiv1::__cxa_allocate_exception (thrown_size=135552) at /proj/vobadm100/svn/gcc_4.7.2/libstdc++-v3/libsupc++/eh_alloc.cc:132 #3 0x00010acc in ThrowException () at Core.cc:7 #4 0x00010a90 in main () at CoreTest.cc:4 This is a dup of PR target/55909 and might be related to PR binutils/15056: http://sourceware.org/bugzilla/show_bug.cgi?id=15056 which reports that TLS is broken for the SPARC in the 2.23.1 binutils release. You need to upgrade to the just released 2.23.2 release of binutils. *** This bug has been marked as a duplicate of bug 55909 ***
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||marc.girod at gmail dot com --- Comment #44 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-27 10:22:44 UTC --- *** Bug 56734 has been marked as a duplicate of this bug. ***
[Bug target/49423] [4.6/4.7/4.8/4.9 Regression] [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org, rearnsha at gcc ||dot gnu.org --- Comment #18 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-27 10:26:37 UTC --- I just posted a patch about it: http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00939.html
[Bug bootstrap/56752] New: GCC fails to bootstrap on Debian GNU/Linux 7.0 (wheezy) when x32 libraries aren't installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56752 Bug #: 56752 Summary: GCC fails to bootstrap on Debian GNU/Linux 7.0 (wheezy) when x32 libraries aren't installed Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: prosfil...@gmail.com Created attachment 29737 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29737 Last lines of compilation I ran CC=gcc-4.6 ../gcc-4.8.0/configure --prefix=/home/prosfilaes/bin/gcc-4.8.0/ --enable-languages=ada,c,c++,java,fortran and then make bootstrap It fails with In file included from /usr/include/stdio.h:28:0, from ../../../../gcc-4.8.0/libgcc/../gcc/tsystem.h:87, from ../../../../gcc-4.8.0/libgcc/libgcc2.c:27: /usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or directory #include bits/predefs.h ^ compilation terminated. make[5]: *** [_muldi3.o] Error 1 make[5]: Leaving directory `/home/prosfilaes/Program_Source/gcc-480-objdir/x86_64-unknown-linux-gnu/32/libgcc' (fuller log attached) Poking at it, this seems to be telling me that I don't have a 32-bit development package installed, which is true, but shouldn't it stop at configure and tell me that instead of erring out in the middle of compilation with an unhelpful error message?
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de 2013-03-27 10:36:48 UTC --- Hello GCC-Maintainers, what do you think? Should'nt this patch be in the 4.6.4 release?
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 10:39:00 UTC --- Author: rguenth Date: Wed Mar 27 10:38:29 2013 New Revision: 197158 URL: http://gcc.gnu.org/viewcvs?rev=197158root=gccview=rev Log: 2013-03-27 Richard Biener rguent...@suse.de PR tree-optimization/37021 * tree-vect-data-refs.c (vect_check_strided_load): Allow REALPART/IMAGPART_EXPRs around the supported refs. * tree-ssa-structalias.c (find_func_aliases): Assume that floating-point values are not used to transfer pointers. * gfortran.dg/vect/fast-math-pr37021.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/vect/fast-math-pr37021.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-structalias.c trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 10:40:40 UTC --- We now vectorize this testcase by means of using strided loads, relying on store motion turning the store to self(i) in the innermost look into a reduction (no support for vectorized strided stores).
[Bug bootstrap/56752] GCC fails to bootstrap on Debian GNU/Linux 7.0 (wheezy) when x32 libraries aren't installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56752 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 10:42:24 UTC --- No, that's the way it always has been.
[Bug tree-optimization/56695] [4.9 Regression] ICE in expand_vec_cond_expr, at optabs.c:6751
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56695 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |mpolacek at gcc dot gnu.org |gnu.org | --- Comment #12 from Marek Polacek mpolacek at gcc dot gnu.org 2013-03-27 10:52:06 UTC --- Let me try something.
[Bug bootstrap/56752] GCC fails to bootstrap on Debian GNU/Linux 7.0 (wheezy) when x32 libraries aren't installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56752 David Starner prosfilaes at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #2 from David Starner prosfilaes at gmail dot com 2013-03-27 10:55:02 UTC --- I don't understand how that's the way it always has been is an answer. If there's a library missing (especially one the installation instructions don't mention), it should tell you that, not fail in the middle with an obscure error message. That it has done in it in the past doesn't justify the behavior.
[Bug bootstrap/56752] GCC fails to bootstrap on Debian GNU/Linux 7.0 (wheezy) when x32 libraries aren't installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56752 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-27 11:00:16 UTC --- How do you propose to check that? You might not have a 32-bit compiler with which to test those headers during configuration, so it's not easy to test them until after we've bootstrapped a multilib compiler.
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 --- Comment #2 from Mathias Gaunard mathias at gaunard dot com 2013-03-27 11:04:08 UTC --- The preprocessed file is 7 megabytes, which exceeds what I can attach here. I do not think it is practical to reduce it with automatic tools. Would it be ok to provide it as-is? The flags used are -fno-strict-aliasing -Wall -Wno-unused -Wno-delete-non-virtual-dtor -mxop -fabi-version=4 -O2.-O2
[Bug bootstrap/56752] GCC fails to bootstrap on Debian GNU/Linux 7.0 (wheezy) when 32-bit libraries aren't installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56752 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-27 Summary|GCC fails to bootstrap on |GCC fails to bootstrap on |Debian GNU/Linux 7.0|Debian GNU/Linux 7.0 |(wheezy) when x32 libraries |(wheezy) when 32-bit |aren't installed|libraries aren't installed Ever Confirmed|0 |1 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-27 11:08:20 UTC --- Also this is nothing to do with x32, which is a different ABI, you just mean 32-bit. Confirming as a dcoumentation bug, http://gcc.gnu.org/install/specific.html#x86-64-x-x could mention that building a bi-arch compiler requires both 32-bit and 64-bit libc
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-27 11:09:28 UTC --- You can reduce it at least somewhat and then compress it with bzip2.
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-27 11:12:45 UTC --- You should be able to attach it if you compress it.
[Bug tree-optimization/56213] strided load vectorization is unnecessarily restricted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56213 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-27 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 11:12:56 UTC --- 2013-03-27 Richard Biener rguent...@suse.de PR tree-optimization/37021 * tree-vect-data-refs.c (vect_check_strided_load): Allow REALPART/IMAGPART_EXPRs around the supported refs. * tree-ssa-structalias.c (find_func_aliases): Assume that floating-point values are not used to transfer pointers. * gfortran.dg/vect/fast-math-pr37021.f90: New testcase. relaxes this a tiny bit.
[Bug tree-optimization/54939] Very poor vectorization of loops with complex arithmetic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Blocks||37021 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 11:19:49 UTC --- Confirmed. GCC vectorizes this using hybrid SLP - it unrolls the loop once to be able to vectorize two minus and two adds resulting from the complex multiplication. The PR is kind-of a duplicate of PR37021 where also a reduction and a variable stride is involved. So fixing this bug is required to more efficiently vectorize PR37021. Note that even this bug has multiple issues that need to be tackled. I happen to work on them.
[Bug rtl-optimization/56745] [4.8/4.9 Regression] ICE in merge_if_block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56745 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-03-27 11:20:58 UTC --- Started with http://gcc.gnu.org/r193098.
[Bug fortran/56650] Odd error messages with C_SIZEOF for valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56650 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-27 11:23:41 UTC --- Author: burnus Date: Wed Mar 27 10:45:58 2013 New Revision: 197159 URL: http://gcc.gnu.org/viewcvs?rev=197159root=gccview=rev Log: 2013-03-27 Tobias Burnus bur...@net-b.de PR fortran/56650 PR fortran/36437 * check.c (gfc_check_sizeof, gfc_check_c_sizeof, gfc_check_storage_size): Update checks. * intrinsic.texi (SIZEOF): Correct class. * intrinsic.h (gfc_simplify_sizeof, gfc_simplify_storage_size): New prototypes. * intrinsic.c (add_functions): Use them. * simplify.c (gfc_simplify_sizeof, gfc_simplify_storage_size): New functions. 2013-03-27 Tobias Burnus bur...@net-b.de PR fortran/56650 PR fortran/36437 * gfortran.dg/sizeof_2.f90: New. * gfortran.dg/sizeof_3.f90: New. * gfortran.dg/sizeof_proc.f90: Update dg-error. Added: trunk/gcc/testsuite/gfortran.dg/sizeof_2.f90 trunk/gcc/testsuite/gfortran.dg/sizeof_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/sizeof_proc.f90
[Bug fortran/56650] Odd error messages with C_SIZEOF for valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56650 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-27 11:23:55 UTC --- FIXED on the 4.9 trunk.
[Bug fortran/36437] Simplify argument to [c_]sizeof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36437 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-27 11:24:06 UTC --- Author: burnus Date: Wed Mar 27 10:45:58 2013 New Revision: 197159 URL: http://gcc.gnu.org/viewcvs?rev=197159root=gccview=rev Log: 2013-03-27 Tobias Burnus bur...@net-b.de PR fortran/56650 PR fortran/36437 * check.c (gfc_check_sizeof, gfc_check_c_sizeof, gfc_check_storage_size): Update checks. * intrinsic.texi (SIZEOF): Correct class. * intrinsic.h (gfc_simplify_sizeof, gfc_simplify_storage_size): New prototypes. * intrinsic.c (add_functions): Use them. * simplify.c (gfc_simplify_sizeof, gfc_simplify_storage_size): New functions. 2013-03-27 Tobias Burnus bur...@net-b.de PR fortran/56650 PR fortran/36437 * gfortran.dg/sizeof_2.f90: New. * gfortran.dg/sizeof_3.f90: New. * gfortran.dg/sizeof_proc.f90: Update dg-error. Added: trunk/gcc/testsuite/gfortran.dg/sizeof_2.f90 trunk/gcc/testsuite/gfortran.dg/sizeof_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/intrinsic.h trunk/gcc/fortran/intrinsic.texi trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/sizeof_proc.f90
[Bug tree-optimization/18438] vectorizer failed for vector matrix multiplication
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 11:27:31 UTC --- The issue is that we cannot use a vector v4sf store to opoints[i][0] as opoints[i][4] is not stored to. Such masked store (or interleaved store with gaps) is not supported by SLP.
[Bug fortran/36437] Simplify argument to [c_]sizeof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36437 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-27 11:29:51 UTC --- FIXED on the 4.9 trunk. There might be still bugs - especially for the ill-defined vendor extension SIZEOF, but possibly also for C_SIZEOF and STORAGE_SIZE, but most cases should be handled correctly (including rejecting arguments like TYPE(*)).
[Bug tree-optimization/21998] (cond ? result1 : result2) is vectorized, where equivalent if-syntax isn't (store)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21998 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 11:32:19 UTC --- Note that the concern is also that a1 may be mapped to a read-only segment, so introducing a store data-race may trap. That's probably out of the C99 language standards scope, but the middle-end has to care about this possibility.
[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #14 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 11:34:28 UTC --- Testcase is lost, the URL does no longer work. Can you please attach it here?
[Bug libstdc++/55979] [C++11] std::list range construction imposes unnecessary conversion constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55979 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-27 11:40:30 UTC --- Fixed 4.8.1 too.
[Bug tree-optimization/31079] 20% difference between ifort/gfortran, missed vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31079 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0 Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 11:44:56 UTC --- We vectorize the new testcase now (move the USE function to a separate TU to not optimize everything away...). At -O3 -ffast-math I see 4.6: 4.25s 4.7: 4.25s 4.8/trunk: 2.7s ifort 12.1 and -fast: 3.6s I conclude - fixed for 4.8.
[Bug rtl-optimization/31021] gfortran 20% slower than ifort on CP2K computational kernel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31021 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #15 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-27 11:47:12 UTC --- New URL: https://www.dropbox.com/s/g28kdvatrgeu6hm/extracted_collocate.tgz (contains nearly 2Mb of data needed to run the testcase). the difference between trunk and ifort has become smaller. I'm now seeing only 5% difference (on a different CPU). 3.50946712 vs. 3.354490 I adjusted in the Makefile the ifort option to use -xHost.
[Bug tree-optimization/34378] [autovectorize]: missed optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34378 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Blocks||49774 Resolution||FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 11:48:50 UTC --- Both loops are vectorized now, the one in test2 with a runtime check for alias though. Fixed. Link to restrict meta-bug.
[Bug middle-end/37150] basic-block vectorization misses some unrolled loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37150
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
Summary|vectorizer misses some |basic-block vectorization
|loops |misses some unrolled loops
--- Comment #14 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27
12:26:40 UTC ---
Confirmed - this should be handled by BB vectorization.
t.f90:1: note: === vect_analyze_slp ===
t.f90:1: note: Failed to SLP the basic block.
t.f90:1: note: not vectorized: failed to find SLP opportunities in basic block.
a smaller, but still sensible, testcase would be appreciated.
For now BB analysis stops at
coef_x = {};
because it cannot find a vector type for it. If we fix that we end up
with
t.f90:1: note: === vect_slp_analyze_data_ref_dependences ===
t.f90:1: note: can't determine dependence between coef_x[_2719] and coef_x
t.f90:1: note: not vectorized: unhandled data dependence in basic block.
because dependence analysis appearantly does not handle. If we fix that
we end up with
t.f90:1: note: can't determine dependence between coef_x[_2719] and coef_x[0]
t.f90:1: note: not vectorized: unhandled data dependence in basic block.
so the issue boils down to the fact that we first do all dependence checks
rather than look for SLP opportunities and only check dependences within
the basic-block region the SLP tree covers.
[Bug tree-optimization/38011] vectorizer ignores alignment, useless versioning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38011
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27
12:35:44 UTC ---
Not true - you aligned the pointer, not the data it points to. There isn't
a good way to do that with an aligned attribute, the closest you can get at
is with
typedef double aligned_double __attribute__((aligned (16)));
void assignMultiplyVec(aligned_double* restrict a, aligned_double* restrict b,
double coef, unsigned count)
{
for(unsigned i=0; icount; i++) {
a[i] = b[i]*coef;
}
}
but that has the issue that a[1] is not aligned but technically you
still say so (the issue is that the array has no gaps according to
the C standard but the alignment of the element type is bigger than
its size ...).
So instead we now have an assume_aligned builtin which you can use like
void assignMultiplyVec(double* restrict a_, const double * restrict b_,
double coef, unsigned count)
{
double* restrict a = __builtin_assume_aligned (a_, 16);
double* restrict b = __builtin_assume_aligned (b_, 16);
for(unsigned i=0; icount; i++) {
a[i] = b[i]*coef;
}
}
which does not have this issue.
[Bug middle-end/41115] Tree-vectorizer: VecCost tuning for X2: Without vectorization 30% faster
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41115 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 12:38:05 UTC --- It would be nice to see where we are today with respect to the cost model / vectorizing / not vectorizing.
[Bug target/56716] during gcc 4.8.0 build on Cygwin: bid128_fma.c:4460:1: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56716 Bernhard Reutner-Fischer aldot at gcc dot gnu.org changed: What|Removed |Added Target|i686-pc-cygwin |i686-pc-cygwin, ||x86_64-unknown-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-27 CC||aldot at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.9.0 --- Comment #1 from Bernhard Reutner-Fischer aldot at gcc dot gnu.org 2013-03-27 12:43:23 UTC --- same thing on current trunk @ targeting x86_64-unknown-linux-gnu: $ /scratch/obj.x86_64/gcc-4.9.orig/./gcc/xgcc -v Using built-in specs. COLLECT_GCC=/scratch/obj.x86_64/gcc-4.9.orig/./gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: ../../src/gcc-4.9.orig/configure -v --enable-languages=c,lto,fortran,c++,go LD=ld CFLAGS='-O2 -g3 -ggdb3 -fdump-ipa-all-all-all -fdump-tree-all-all-all -fdump-rtl-all-all' CXXFLAGS='-O2 -g3 -ggdb3 -fdump-ipa-all-all-all -fdump-tree-all-all-all -fdump-rtl-all-all' 'BOOT_CFLAGS=-O2 ' 'BOOT_CXXFLAGS=-O2 ' 'CFLAGS_FOR_TARGET=-Og -g3 -ggdb3 -fdump-ipa-all-all-all -fdump-tree-all-all-all -fdump-rtl-all-all' 'CXXFLAGS_FOR_TARGET=-Og -g3 -ggdb3 -fdump-ipa-all-all-all -fdump-tree-all-all-all -fdump-rtl-all-all' --prefix=/ --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix=-4.9.orig-HEAD --with-build-config='bootstrap-asan bootstrap-lto' --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-werror --enable-checking=yes --enable-debug -C --disable-intermodule --disable-libstdcxx-pch --disable-multilib --enable-bootstrap --enable-checking=release --with-cpu=native --with-tune=native --enable-plugin Thread model: posix gcc version 4.9.0 20130327 (experimental) [fixups revision 2e9f00a:a9591cc:d18af62e3808d9860cf2a36c41367b3b3e8e3fa9] (GCC) /scratch/obj.x86_64/gcc-4.9.orig/./gcc/xgcc -B/scratch/obj.x86_64/gcc-4.9.orig/./gcc/ -B//x86_64-unknown-linux-gnu/bin/ -B//x86_64-unknown-linux-gnu/lib/ -isystem //x86_64-unknown-linux-gnu/include -isystem //x86_64-unknown-linux-gnu/sys-include-Og -g3 -ggdb3 -fdump-ipa-all-all-all -fdump-tree-all-all-all -fdump-rtl-all-all -O2 -Og -g3 -ggdb3 -fdump-ipa-all-all-all -fdump-tree-all-all-all -fdump-rtl-all-all -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -I. -I. -I../.././gcc -I../../../../src/gcc-4.9.orig/libgcc -I../../../../src/gcc-4.9.orig/libgcc/. -I../../../../src/gcc-4.9.orig/libgcc/../gcc -I../../../../src/gcc-4.9.orig/libgcc/../include -I../../../../src/gcc-4.9.orig/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o bid128_fma.o -MT bid128_fma.o -MD -MP -MF bid128_fma.dep -c ../../../../src/gcc-4.9.orig/libgcc/config/libbid/bid128_fma.c ../../../../src/gcc-4.9.orig/libgcc/config/libbid/bid128_fma.c: In function ‘add_and_round’: ../../../../src/gcc-4.9.orig/libgcc/config/libbid/bid128_fma.c:4460:1: internal compiler error: Segmentation fault } ^ 0x9d8a50 crash_signal ../../../src/gcc-4.9.orig/gcc/toplev.c:332 0xb2572d perform_var_substitution ../../../src/gcc-4.9.orig/gcc/tree-ssa-structalias.c:2299 0xb2f97b solve_constraints ../../../src/gcc-4.9.orig/gcc/tree-ssa-structalias.c:6659 0xb2fd7b compute_points_to_sets ../../../src/gcc-4.9.orig/gcc/tree-ssa-structalias.c:6755 0xb30460 compute_may_aliases() ../../../src/gcc-4.9.orig/gcc/tree-ssa-structalias.c:6905 0x8fb395 execute_function_todo ../../../src/gcc-4.9.orig/gcc/passes.c:1941 0x8fa7b9 do_per_function ../../../src/gcc-4.9.orig/gcc/passes.c:1701 0x8fb444 execute_todo ../../../src/gcc-4.9.orig/gcc/passes.c:1996 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [bid128_fma.o] Error 1 make[3]: Leaving directory `/scratch/obj.x86_64/gcc-4.9.orig/x86_64-unknown-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2
[Bug tree-optimization/43434] Missed vectorization: not vectorized: data ref analysis: pointer incremented by a parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43434 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-27 Blocks||37021 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 12:45:02 UTC --- Confirmed. We for example have t.c:39: note: Build SLP failed: not grouped load _46 = *pix_1; as we fail to detect groups for _46 = *pix_1; _49 = MEM[(unsigned char *)pix_1 + 1B]; _52 = MEM[(unsigned char *)pix_1 + 2B]; ... as the step is not integral. That is, this is a strided-load SLP group. I am working on a patch for this. This is one reason why PR37021 is not vectorized in the best possible way.
[Bug lto/55102] The options -flto and -On do not behave as described in GCC docs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55102 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2013-03-27 12:47:04 UTC --- Doing IPA analysis at -O0 for LTO streaming won't really solve the fact that functions are not early optimized. I would vote for at least issuing a waning when LTOing -O0 objects into -On, n=1 LTO binary or simply declaring -O0 to be non-LTO only. But indeed, we probably should make analysis/summary streaming of all IPA passes so -fno-ipa-cp and such works as expected all the time. I have patch fot that somewhere already. We probably should lean the route of streaming the options used and honoring them rather than taking whatever is passed to linker...
[Bug libstdc++/56753] New: vector.size() always returns 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56753
Bug #: 56753
Summary: vector.size() always returns 0
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@oaktreepeak.com
Test code:
/*
* File: main.cpp
* Author: rbross
*
* Created on March 27, 2013, 8:16 AM
*/
#include cstdlib
#include vector
#include iostream
using namespace std;
typedef vectorvoid * BS_VECTOR;
/*
*
*/
int main(int argc, char** argv)
{
BS_VECTORvBS;
vBS.reserve(100);
cout Size vBS.size() Capacity vBS.capacity() endl;
vBS[10] = (void *) 0x4d3;
vBS[12] = (void *) 0x11d7;
cout Size vBS.size() Capacity vBS.capacity() endl;
cout vBS[10] vBS[10] endl;
cout vBS[12] vBS[12] endl;
return 0;
}
Output:
Size 0 Capacity 100
Size 0 Capacity 100
vBS[10] 0x4d3
vBS[12] 0x11d7
Note that accessing the
[Bug middle-end/37150] basic-block vectorization misses some unrolled loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37150 --- Comment #15 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2013-03-27 12:53:16 UTC --- Created attachment 29738 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29738 maybe smaller testcase version ? Attached is what I think is roughly the smallest kernel of this type that we have in the code. I checked this is at least partially vectorized with ifort, but not so with gfortran trunk. It is still not such a small testcase, I'm afraid.
[Bug middle-end/47298] -O3 destroys beautifully vectorized code obtained at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 13:02:05 UTC --- On trunk we now vectorize the loop and then unroll it from cunroll. 4.6 -O2 -funroll-loops -ftree-vectorize -ffast-math: 10.7s 4.6 -O3 -funroll-loops -ftree-vectorize -ffast-math: 8.3s 4.7 -O2 -funroll-loops -ftree-vectorize -ffast-math: 7.4s 4.7 -O3 -funroll-loops -ftree-vectorize -ffast-math: 8.5s 4.8 -O2 -funroll-loops -ftree-vectorize -ffast-math: 6.1s 4.8 -O3 -funroll-loops -ftree-vectorize -ffast-math: 6.5s with -march=native added (iCore5) 4.8 -O2 ... -march=native: 3.9s 4.8 -O3 ... -march=native: 4s Apart from very minor scheduling differences I see no difference in code generation on trunk -O2 vs. -O3. I'd say fixed without more details.
[Bug libstdc++/56753] vector.size() always returns 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56753 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-27 13:07:25 UTC --- This is clearly invalid. Try building with -D_GLIBCXX_DEBUG for details.
[Bug lto/55102] The options -flto and -On do not behave as described in GCC docs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55102 --- Comment #4 from rguenther at suse dot de rguenther at suse dot de 2013-03-27 13:09:18 UTC --- On Wed, 27 Mar 2013, hubicka at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55102 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org 2013-03-27 12:47:04 UTC --- Doing IPA analysis at -O0 for LTO streaming won't really solve the fact that functions are not early optimized. I would vote for at least issuing a waning when LTOing -O0 objects into -On, n=1 LTO binary or simply declaring -O0 to be non-LTO only. But indeed, we probably should make analysis/summary streaming of all IPA passes so -fno-ipa-cp and such works as expected all the time. I have patch fot that somewhere already. We probably should lean the route of streaming the options used and honoring them rather than taking whatever is passed to linker... Well, we _do_ stream them. The issue is that we need to formally define how to merge N sets of options from the N input files at WPA stage to M sets of options for the M LTRANS units (with eventually, but not necessarily, M == 1). Oh, and implement it, of course. At the moment the LTO driver (lto-wrapper.c) has a brief look at options because it creates options for the WPA stage (which shouldn't really care about the options passed ... in which case it could do the option processing from the TUs and eventually simply partition them into sets of TUs that have the same options). So - Honza, what about first making WPA ignore all flags? (all optimization and target flags) IPA pass processing should just unconditionally run and handle inputs which have the IPA sections present.
[Bug c++/47346] access control for nested type is ignored in class template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346
--- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2013-03-27
13:28:24 UTC ---
Even simpler:
class B { struct C {}; };
template class T struct A { B::C c; };
Aint a;
[Bug c++/56749] [4.8/4.9 Regression] weird interaction between scoped enum used as non-type template parameter and template lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56749 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.1
[Bug target/56716] during gcc 4.8.0 build on Cygwin: bid128_fma.c:4460:1: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56716 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 13:46:50 UTC --- Mine. I can only reproduce this with -fdump-tree-all-all though, so I doubt this is the original issue.
[Bug rtl-optimization/56742] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org Component|c++ |rtl-optimization --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2013-03-27 13:48:42 UTC --- I can't reproduce this on x86_64-unknown-linux-gnu. Is it a regression? Changing component to rtl-optimization.
[Bug libstdc++/56753] vector.size() always returns 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56753 --- Comment #2 from rb at oaktreepeak dot com 2013-03-27 14:05:11 UTC --- It appears that you are saying that you can not assign a value to a vector using the assignment operator[]? All the STL docs say that you can. Can you please elaborate?
[Bug libstdc++/56753] vector.size() always returns 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56753 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|major |normal --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-27 14:19:24 UTC --- (In reply to comment #0) vBS.reserve(100); Either you meant resize() here or you need to read how std::vector works. Thousands of people use libstdc++ every day, if you think something so basic doesn't work there's a very, very good chance the bug is in your code, not GCC. (In reply to comment #2) It appears that you are saying that you can not assign a value to a vector using the assignment operator[]? That's not an assignment operator. All the STL docs say that you can. No they don't.
[Bug libstdc++/55977] [C++11] vector range construction imposes unnecessary conversion constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55977 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-27 14:33:25 UTC --- std::vector and std::deque fixed for 4.8.1 too.
[Bug rtl-optimization/56742] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742 --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org 2013-03-27 14:43:24 UTC --- Well, this issue is related to SEH exceptions. So it is pretty clear, why you don't see it for linux. It is serious bug for 4.8 gcc. From user's perspective this is a regression. Technical it is a bug in bb-reorder for SEH. For 4.8 I think the above patch is the lowest invasive way to fix it. For trunk we might be able to use an approach as dw2 uses here. Not sure about later. I will discuss with Richard Henderson.
[Bug rtl-optimization/56742] [4.8 regression] Optimization bug lead to uncaught throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.1 Summary|Optimization bug lead to|[4.8 regression] |uncaught throw |Optimization bug lead to ||uncaught throw
[Bug target/56716] during gcc 4.8.0 build on Cygwin: bid128_fma.c:4460:1: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56716 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|rguenth at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-27 15:12:09 UTC --- Author: rguenth Date: Wed Mar 27 15:10:50 2013 New Revision: 197165 URL: http://gcc.gnu.org/viewcvs?rev=197165root=gccview=rev Log: 2013-03-27 Richard Biener rguent...@suse.de PR tree-optimization/56716 * tree-ssa-structalias.c (perform_var_substitution): Adjust dumping for ref nodes. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c Fixed the issue on trunk. Back to analysis.
[Bug libstdc++/56753] vector.size() always returns 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56753 --- Comment #4 from rb at oaktreepeak dot com 2013-03-27 15:17:14 UTC --- I have a team of guys here and I am not attempting to be argumentative. We are trying to understand your rather terse comments. Perhaps this isn't the official documentation (if there is such a thing), but even in the example opeartor[] is used to store values: http://www.cplusplus.com/reference/vector/vector/operator[] I am certainly willing to learn (we all are) if you could be a bit more descriptive.
[Bug libstdc++/56753] vector.size() always returns 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56753 --- Comment #5 from rb at oaktreepeak dot com 2013-03-27 15:29:40 UTC --- I understand what you are saying. You must actually assign empty buckets to get the size, even though storing and retrieving values will work correctly.
[Bug c++/56725] extra spaces in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-27 15:36:16 UTC --- Hi Manuel. I wanted to actually handle this per your indications and move on, but I don't understand why you check the return value of permerror: shouldn't we emit the inform anyway, either for an error or a warning?
[Bug c++/56746] [4.8 regression] increased memory usage when compiling C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 --- Comment #5 from Mathias Gaunard mathias at gaunard dot com 2013-03-27 16:41:16 UTC --- While trying to isolate the problem, I have observed that the problem does not occur if -save-temps is used. While using -save-temps does not change anything with GCC 4.7, using it does reduce memory usage significantly with GCC 4.8. Did something change with regards to the way temporary files are handled?
[Bug libstdc++/56753] vector.size() always returns 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56753 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-27 17:02:31 UTC --- (In reply to comment #4) Perhaps this isn't the official documentation (if there is such a thing), but even in the example opeartor[] is used to store values: http://www.cplusplus.com/reference/vector/vector/operator[] No, it's used to access existing values, not to add values to the container. Since the size of your vector is zero there are *no* existing values and it is undefined behaviour to call operator[], as documented at the bottom of that page. To change the size of the vector use resize() *not* reserve(), or add elements with push_back() or insert(). (In reply to comment #5) I understand what you are saying. You must actually assign empty buckets to get the size, even though storing and retrieving values will work correctly. Your program doesn't work correctly. You're mistaking it didn't show an obvious problem with it is working correctly. By accessing vBS[10] you are reading uninitialized bytes in memory, not a valid element of the vector (because the vector *has* no valid elements, it has size()==0 i.e. it is still empty.) Maybe you want to use std::mapint, void* instead, which will allow vBS[10] on an empty map and will add an entry with key 10. In any case, Bugzilla is not the place to learn C++.
[Bug libstdc++/56753] vector.size() always returns 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56753 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-27 17:03:56 UTC --- http://en.cppreference.com/w/cpp/container/vector/operator_at is a much better reference site than cplusplus.com, which is quite awful
[Bug c++/56725] extra spaces in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725 --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-03-27 17:43:02 UTC --- (In reply to comment #4) Hi Manuel. I wanted to actually handle this per your indications and move on, but I don't understand why you check the return value of permerror: shouldn't we emit the inform anyway, either for an error or a warning? permerrors can be totally hidden by using -fpermissive -w no? (I haven't actually tested it, so maybe I am wrong). If so, it would be weird to give the note.
[Bug plugins/56754] New: some missing plugin headers during installation in gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754 Bug #: 56754 Summary: some missing plugin headers during installation in gcc 4.8 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins AssignedTo: unassig...@gcc.gnu.org ReportedBy: pagee...@freemail.hu it used to be the case before 4.8 that the following files were made available to plugins: target.h target.def target-hooks-macros.h now it seems that at least for a x86_64-pc-linux-gnu target they no longer get installed. i tried to find the related commit but came up empty so i'm wondering if this is the result of an oversight or some policy change? manually installing these files gets things back to normal, but it'd be nice to know what to expect in the future or if it's a bug, fix it for 4.8.1 ;).
[Bug c++/56728] [4.8/4.9 Regression] ICE using constexpr initialization and arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56728 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug c++/56725] extra spaces in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-27 19:28:09 UTC --- I haven't tested anything so far, but stared a bit at the comment before permerror and figured tgat in case of plain error (vs warning) the function returns false thus the behavior would change. Besides that, empirically, I see around in the front end permerrors folliwed unconditionally by informs (actually that observation came first ;)
[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56737 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.3.4, 4.4.0 Keywords||wrong-code Last reconfirmed||2013-03-27 CC||burnus at gcc dot gnu.org, ||jvdelisle at gcc dot ||gnu.org Ever Confirmed|0 |1 Summary|Bizarre Hollerith edit |[4.6/4.7/4.8/4.9 |descriptor errors (valgrind |Regression] Wrong I/O |shows uninitialized value |result with format cache |in libgfortran) |for Hollerith strings Target Milestone|--- |4.6.4 Known to fail||4.5.3, 4.6.3, 4.7.2, 4.8.0, ||4.9.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-27 19:32:32 UTC --- Seems to be a regression in libgfortran. It works with gfortran 4.3 and 4.4, but fails with gfortran 4.5 to 4.9. (Compiling with 4.9 and running with libgfortran 4.3 works, i.e. the regression must be in libgfortran.) It works if one disables the format cache. If one adds some debugging output to write_constant_string, one sees that for the second call, the delimiter (f-u.string.p[-1]) is not 'H' - and the first 6H is also wrong. write_constant_string: len=1: f-u.string.p=' '- delim='H' write_constant_string: len=1: f-u.string.p=' '- delim='H' write_constant_string: len=1: f-u.string.p=' '- delim='H' write_constant_string: len=6: f-u.string.p='= '- delim='h' write_constant_string: len=6: f-u.string.p=' ='- delim='h' = end of level 1 = write_constant_string: len=1: f-u.string.p=' '- delim=' ' write_constant_string: len=1: f-u.string.p=' '- delim=' ' write_constant_string: len=1: f-u.string.p=' '- delim=' ' write_constant_string: len=6: f-u.string.p=' '- delim=' ' write_constant_string: len=6: f-u.string.p=' ='- delim=' ' end of level 1 )
[Bug other/56755] New: Global symbol demangling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56755 Bug #: 56755 Summary: Global symbol demangling Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: dungtq1...@gmail.com Hello, I encountered the following bug about global symbol demangling in c++filt versions 2.23 and 2.22. Could you please tell me how to fix it? c++filt _GLOBAL__sub_I__ZN4AMOS12ContigEdge_t5NCODEE _GLOBAL__sub_I__ZN4AMOS12ContigEdge_t5NCODEE c++filt --version GNU c++filt (GNU Binutils for Ubuntu) 2.23.1 Copyright 2012 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. Thanks, Bryan
[Bug other/56755] Global symbol demangling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56755 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2013-03-27 19:42:39 UTC --- c++filt is a part of binutils.
[Bug c++/56725] extra spaces in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-03-27 19:46:57 UTC --- (In reply to comment #6) I haven't tested anything so far, but stared a bit at the comment before permerror and figured tgat in case of plain error (vs warning) the function returns false thus the behavior would change. Besides that, empirically, I see around in the front end permerrors folliwed unconditionally by informs (actually that observation came first ;) manuel@gcc10:~$ ~/test1/195333/build/gcc/cc1plus test.cc int docall() test.cc:9:18: error: invalid conversion from ‘int (*)(int*)’ to ‘int (*)(double*)’ [-fpermissive] f); ^ test.cc:4:5: error: initializing argument 3 of ‘int callf(int, int, int (*)(double*))’ [-fpermissive] int callf (int, int, int (*)(double *)); ^ manuel@gcc10:~$ ~/test1/195333/build/gcc/cc1plus test.cc -fpermissive [..the same but two warnings..] manuel@gcc10:~$ ~/test1/195333/build/gcc/cc1plus test.cc -fpermissive -w [nothing] so if you change the second permerror to inform, and don't check the output of permerror and fn == true, then with -fpermissive -w you get: manuel@gcc10:~$ ~/test1/195333/build/gcc/cc1plus test.cc -fpermissive test.cc:4:5: note: initializing argument 3 of ‘int callf(int, int, int (*)(double*))’ int callf (int, int, int (*)(double *)); ^ which doesn't make much sense. I added a bool return value to permerror for this reason. error() doesn't return bool because you cannot silence it.
[Bug c++/56725] extra spaces in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-03-27 19:48:21 UTC --- (In reply to comment #7) manuel@gcc10:~$ ~/test1/195333/build/gcc/cc1plus test.cc -fpermissive test.cc:4:5: note: initializing argument 3 of ‘int callf(int, int, int (*)(double*))’ int callf (int, int, int (*)(double *)); ^ Typo! The command-line is actually: manuel@gcc10:~$ ~/test1/195333/build/gcc/cc1plus test.cc -fpermissive -w
[Bug c++/56725] extra spaces in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-27 19:52:57 UTC --- Ok, thanks! Thus, if I remember correctly that comment (true meaning warning), looks like we want everywhere if (!permerror...) inform(... right? Otherwise if I misremembering, we should anyway fix the existing permerror/inform sequences, right?
[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56737 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-27 20:24:11 UTC --- If one sets the breakpoint in _gfortrani_next_format, one gets for the original, non cached version: (gdb) p dtp-u.p.fmt.array.array[1].source $13 = 0x7fffdec6 1H ),6h= ,a 12,i4,6h =), ... For the second round, one gets: (gdb) p dtp-u.p.fmt.array.array[1].source $14 = 0x7fffdec6 ' ' repeats 26 times, =) \f Thus, the source string is not carried over.
[Bug c++/56725] extra spaces in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725 --- Comment #10 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-03-27 20:24:47 UTC --- No, true means something was reported (error or warning), false means that nothing was reported. The same as for pedwarn and warning. pedwarn also returns true for --pedantic-errors, even thought it gives an error then. So either: if (permerror(...)) inform(...) or permerror() inform() but I think the latter was frowned upon by the powers that be.
[Bug c++/56725] extra spaces in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-27 20:30:36 UTC --- Ok, thanks a lot again. Then however we have to tweak a bit that comment too (it only mentions warnings for true, instead means any diagnostics is actually reported (that's much better!))
[Bug c++/56725] extra spaces in error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725 --- Comment #12 from Manuel López-Ibáñez manu at gcc dot gnu.org 2013-03-27 20:37:05 UTC --- That was the intention, if the comment or the behaviour does not match this, then I did a mistake implementing it, and it is a bug in my opinion.
[Bug tree-optimization/56756] New: ICE: verify_ssa failed (definition in block n follows the use !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56756
Bug #: 56756
Summary: ICE: verify_ssa failed (definition in block n follows
the use !)
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: antoine.balest...@gmail.com
Using GCC 4.9.0 as of 20130327 :
$ cat ssa.c
int a, *b;
void f(void)
{
if(a)
{
int k;
for(a = 0; a 1; a++)
{
int **q;
f();
for(; **q; ++**q)
lbl:
if(a)
{
a = 0;
goto lbl;
}
b = k;
}
}
goto lbl;
}
$ xgcc -O1 -w ssa.c
ssa.c: In function ‘f’:
ssa.c:3:6: error: definition in block 12 follows the use
void f(void)
^
for SSA_NAME: _17 in statement:
# VUSE .MEM_21
D__lsm.5_2 = *_17;
ssa.c:3:6: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug other/56755] Global symbol demangling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56755 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-03-27 21:12:24 UTC --- (In reply to comment #1) c++filt is a part of binutils. It might be part of binutils but the mangler is part of libiberty whos official copy is part of GCC.
[Bug c++/56757] New: ICE in int_cst_value/get_non_default_template_args_count on invalid source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56757
Bug #: 56757
Summary: ICE in
int_cst_value/get_non_default_template_args_count on
invalid source
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
While doing creduce for something else, I noticed that current trunk (r197163)
dumped core on invalid reduction.
I then creduce'd the invalid to this gibberish:
/// --- cut ---
namespace std template class, class struct pair;
struct less struct _Select1st
}
template typename, typename, typename, typename, typename class _Rb_tree;
namespace std template typename _Key, typename _Compare = std:less,
typename _Alloc
class map
{
typedef _Key key_type
typedef std::pair value_type
typedef _Compare key_compare
typedef typename _Alloc::template rebind value_type ::other
_Pair_alloc_type
typedef _Rb_tree key_type, value_type, _Select1st,
key_compare, _Pair_alloc_type _Rep_type
typedef typename _Rep_type::iterator iterator
std::pair iterator, bool insert () return
/// --- cut ---
gdb -q cc1plus
(gdb) run pp1.ii 2 /dev/null
Program received signal SIGSEGV, Segmentation fault.
int_cst_value (x=0x0) at ../../gcc/tree.c:10248
10248 unsigned bits = TYPE_PRECISION (TREE_TYPE (x));
(gdb) bt
#0 int_cst_value (x=0x0) at ../../gcc/tree.c:10248
#1 0x005e2ce5 in get_non_default_template_args_count
(args=0x7605f800, flags=optimized out) at ../../gcc/cp/error.c:181
#2 0x005eaf99 in dump_template_argument_list
(args=args@entry=0x7605f800, flags=flags@entry=4) at
../../gcc/cp/error.c:190
#3 0x005e4e10 in dump_decl (t=optimized out, flags=optimized out)
at ../../gcc/cp/error.c:1135
#4 0x005eb689 in dump_typename (t=optimized out, flags=optimized
out) at ../../gcc/cp/error.c:571
#5 0x005eb695 in dump_typename (t=0x760643f0, flags=4) at
../../gcc/cp/error.c:567
#6 0x005eb35b in dump_template_parms (info=optimized out,
primary=optimized out, flags=4) at ../../gcc/cp/error.c:1647
#7 0x005eb65b in dump_typename (t=0x76064738, flags=4) at
../../gcc/cp/error.c:569
#8 0x005eb35b in dump_template_parms (info=optimized out,
primary=optimized out, flags=4) at ../../gcc/cp/error.c:1647
#9 0x005e3eb6 in dump_type_prefix (t=optimized out, flags=4) at
../../gcc/cp/error.c:783
#10 0x005ede8c in dump_function_decl (t=0x76052c00, flags=4) at
../../gcc/cp/error.c:1406
#11 0x005ef7b1 in decl_as_string (decl=0x76052c00, flags=4) at
../../gcc/cp/error.c:2607
#12 0x00696303 in cxx_printable_name_internal (decl=0x76052c00,
v=2, translate=optimized out) at ../../gcc/cp/tree.c:1879
#13 0x00a80473 in announce_function (decl=optimized out) at
../../gcc/toplev.c:228
#14 0x0053aae5 in start_preparsed_function (decl1=0x76052c00,
attrs=optimized out, flags=optimized out) at ../../gcc/cp/decl.c:13071
#15 0x005fe6cc in cp_parser_late_parsing_for_member
(member_function=0x76052c00, parser=0x760611b8) at
../../gcc/cp/parser.c:22419
#16 cp_parser_class_specifier_1 (parser=0x760611b8) at
../../gcc/cp/parser.c:18534
#17 cp_parser_class_specifier (parser=0x760611b8) at
../../gcc/cp/parser.c:18558
#18 cp_parser_type_specifier (parser=parser@entry=0x760611b8,
flags=flags@entry=1, decl_specs=decl_specs@entry=0x7fffd0f0,
is_declaration=is_declaration@entry=true,
declares_class_or_enum=declares_class_or_enum@entry=0x7fffd07c,
is_cv_qualifier=is_cv_qualifier@entry=0x7fffd07b) at
../../gcc/cp/parser.c:13641
#19 0x0061533a in cp_parser_decl_specifier_seq
(parser=parser@entry=0x760611b8, flags=flags@entry=1,
decl_specs=decl_specs@entry=0x7fffd0f0,
declares_class_or_enum=declares_class_or_enum@entry=0x7fffd0ec) at
../../gcc/cp/parser.c:10968
#20 0x006193a4 in cp_parser_single_declaration
(parser=parser@entry=0x760611b8, checks=checks@entry=0x0,
member_p=member_p@entry=false,
explicit_specialization_p=explicit_specialization_p@entry=false,
friend_p=friend_p@entry=0x7fffd1bf)
at ../../gcc/cp/parser.c:22014
#21 0x0061c153 in cp_parser_template_declaration_after_export
(parser=parser@entry=0x760611b8, member_p=optimized out) at
../../gcc/cp/parser.c:21899
#22 0x0061c9c0 in cp_parser_template_declaration
(parser=parser@entry=0x760611b8, member_p=member_p@entry=false) at
../../gcc/cp/parser.c:12190
#23 0x00623aaa in cp_parser_declaration
(parser=parser@entry=0x760611b8) at ../../gcc/cp/parser.c:10377
#24 0x0062268e in
[Bug c++/56757] ICE in int_cst_value/get_non_default_template_args_count on invalid source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56757 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.7.3 Keywords||ice-on-invalid-code Last reconfirmed||2013-03-27 CC||mpolacek at gcc dot gnu.org Ever Confirmed|0 |1 Target Milestone|--- |4.9.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2013-03-27 21:34:06 UTC --- Confirmed.
[Bug fortran/56758] New: Missing bounds check for explict-size arrays (+ character scalar storage association)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56758 Bug #: 56758 Summary: Missing bounds check for explict-size arrays (+ character scalar storage association) Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org NAG detects it and prints: Actual argument for dummy array X too small - 3 elements instead of 5 call foo([a,b,c], 5) call foo(abc, 5) contains subroutine foo(x,n) character :: x(n) end subroutine end For constant length, the compiler already does so at compile time: Warning: Actual argument contains too few elements for dummy argument 'x' (3/5)
[Bug regression/56738] [4.9 Regression] ICE in c-c++-common/torture/vshuf-v4di.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56738 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2013-03-27 23:45:01 UTC --- Bah... Index: df-scan.c === --- df-scan.c (revision 197180) +++ df-scan.c (working copy) @@ -1158,8 +1158,17 @@ df_insn_delete (rtx insn) In any case, we expect BB to be non-NULL at least up to register allocation, so disallow a non-NULL BB up to there. Not perfect but better than nothing... */ - + /* ??? bb can also be NULL if lower-subreg.c:resolve_simple_mov emits + an insn into a sequence and then does delete_insn on it. Not sure + if that makes sense, but for now it means this assert cannot work. + See PR56738. + Disable for now but revisit before the end of GCC 4.9 stage1. */ +#if 0 gcc_checking_assert (bb != NULL || reload_completed); +#else + if (bb == NULL) +return; +#endif df_grow_bb_info (df_scan); df_grow_reg_info ();
[Bug middle-end/56729] [4.9 Regression] ICE in df_insn_delete
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56729 --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2013-03-27 23:45:30 UTC --- Bah. Index: df-scan.c === --- df-scan.c (revision 197180) +++ df-scan.c (working copy) @@ -1158,8 +1158,17 @@ df_insn_delete (rtx insn) In any case, we expect BB to be non-NULL at least up to register allocation, so disallow a non-NULL BB up to there. Not perfect but better than nothing... */ - + /* ??? bb can also be NULL if lower-subreg.c:resolve_simple_mov emits + an insn into a sequence and then does delete_insn on it. Not sure + if that makes sense, but for now it means this assert cannot work. + See PR56738. + Disable for now but revisit before the end of GCC 4.9 stage1. */ +#if 0 gcc_checking_assert (bb != NULL || reload_completed); +#else + if (bb == NULL) +return; +#endif df_grow_bb_info (df_scan); df_grow_reg_info ();
[Bug middle-end/56759] New: result of __builtin_constant_p( ) is not constant enough for __builtin_choose_expr( )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56759
Bug #: 56759
Summary: result of __builtin_constant_p( ) is not constant
enough for __builtin_choose_expr( )
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc-bugzi...@codyps.com
Testcase:
---
static inline int x(int y)
{
return __builtin_choose_expr(__builtin_constant_p(y), 1, 0);
}
int foo(void)
{
return x(3);
}
---
$ i386-linux-gcc constant_not_constant.c -O3 -c
constant_not_constant.c: In function 'x':
constant_not_constant.c:4:9: error: first argument to '__builtin_choose_expr'
not a constant
return __builtin_choose_expr(__builtin_constant_p(y), 1, 0);
^
$ i386-linux-gcc -v
Using built-in specs.
COLLECT_GCC=i386-linux-gcc
COLLECT_LTO_WRAPPER=/home/cody/x-buildall/libexec/gcc/i386-linux/4.8.1/lto-wrapper
Target: i386-linux
Configured with: /home/cody/g/gcc/configure --target=i386-linux
--enable-targets=all --prefix=/home/cody/x-buildall --enable-languages=c
--without-headers --enable-sjlj-exceptions --with-system-libunwind
--disable-nls --disable-threads --disable-shared --disable-libmudflap
--disable-libssp --disable-libgomp --disable-decimal-float
--disable-libquadmath --enable-checking=release --disable-libatomic :
(reconfigured) /home/cody/g/gcc/configure --target=i386-linux
--enable-targets=all --prefix=/home/cody/x-buildall --enable-languages=c
--without-headers --enable-sjlj-exceptions --with-system-libunwind
--disable-nls --disable-threads --disable-shared --disable-libmudflap
--disable-libssp --disable-libgomp --disable-decimal-float
--disable-libquadmath --enable-checking=release --disable-libatomic :
(reconfigured) /home/cody/g/gcc/configure --target=i386-linux
--enable-targets=all --prefix=/home/cody/x-buildall --enable-languages=c
--without-headers --enable-sjlj-exceptions --with-system-libunwind
--disable-nls --disable-threads --disable-shared --disable-libmudflap
--disable-libssp --disable-libgomp --disable-decimal-float
--disable-libquadmath --enable-checking=release --disable-libatomic :
(reconfigured) /home/cody/g/gcc/configure --target=i386-linux
--enable-targets=all --prefix=/home/cody/x-buildall --enable-languages=c
--without-headers --enable-sjlj-exceptions --with-system-libunwind
--disable-nls --disable-threads --disable-shared --disable-libmudflap
--disable-libssp --disable-libgomp --disable-decimal-float
--disable-libquadmath --enable-checking=release --disable-libatomic
Thread model: single
gcc version 4.8.1 20130328 (prerelease) (GCC)
[Bug middle-end/56759] result of __builtin_constant_p( ) is not constant enough for __builtin_choose_expr( )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56759 --- Comment #1 from Cody P Schafer gcc-bugzilla at codyps dot com 2013-03-28 00:56:11 UTC --- This also affects my ubuntu gcc install: $ gcc constant_not_constant.c -O3 -c constant_not_constant.c: In function ‘x’: constant_not_constant.c:4:31: error: first argument to ‘__builtin_choose_expr’ not a constant $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56737
--- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-03-28
02:34:32 UTC ---
Note the comment at line 728 of format.c where we must disable format caching
when we encounter FMT_STRING. The problem is related to saving a pointer to a
string rather than the string itself. That pointer can go out of scope on
subsequent I/O operations so caching the format data will not work.
A similar thing happens with FMT_H. Try this not regression tested yet
Index: format.c
===
--- format.c(revision 196516)
+++ format.c(working copy)
@@ -807,6 +807,7 @@
goto data_desc;
case FMT_H:
+ saveit = false;
get_fnode (fmt, head, tail, FMT_STRING);
if (fmt-format_string_len 1)
{
@@ -984,6 +985,7 @@
break;
case FMT_H:
+ saveit = false;
if (repeat fmt-format_string_len)
{
fmt-error = bad_hollerith;
I get:
$ gfortran -g -o gfort_bug gfort_bug-2.f90 valgrind ./gfort_bug
==22746== Memcheck, a memory error detector
==22746== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==22746== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==22746== Command: ./gfort_bug
==22746==
fmt = ( 3(1H ),6h= ,a 12,i4,6h =)
title1= end of level
level =1
= end of level 1 =
fmt = ( 3(1H ),6h= ,a 12,i4,6h =)
title1= end of level
level =1
= end of level 1 =
==22746==
==22746== HEAP SUMMARY:
==22746== in use at exit: 0 bytes in 0 blocks
==22746== total heap usage: 29 allocs, 29 frees, 27,978 bytes allocated
==22746==
==22746== All heap blocks were freed -- no leaks are possible
==22746==
==22746== For counts of detected and suppressed errors, rerun with: -v
==22746== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
I see no burning need to cache these kinds of formats so just disable it.
[Bug plugins/56754] some missing plugin headers during installation in gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754 --- Comment #1 from Magnus Granberg zorry at gentoo dot org 2013-03-28 03:22:04 UTC --- Revision 188166 remove TARGET_H from GIMPLE_H. when TARGET_H did get remove from GIMPLE_H it don't get pass to IPA_PROP_H, so it can't get pass to PLUGIN_HEADERS.
