[Bug fortran/56575] [4.6 Regression] An invalid OO code causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56575 --- Comment #8 from Paul Thomas pault at gcc dot gnu.org 2013-03-13 06:36:10 UTC --- Author: pault Date: Wed Mar 13 06:36:02 2013 New Revision: 196628 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196628 Log: 2013-03-13 Paul Thomas pa...@gcc.gnu.org PR fortran/56575 * expr.c (gfc_default_initializer): Check that a class declared type has any components. * resolve.c (resolve_fl_derived0): On failing the test for C437 set the type to BT_UNKNOWN to prevent repeat error messages. 2013-03-13 Paul Thomas pa...@gcc.gnu.org PR fortran/56575 * gfortran.dg/class_56.f90: New test. Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/expr.c branches/gcc-4_6-branch/gcc/fortran/resolve.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/56575] [4.6 Regression] An invalid OO code causes ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56575 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #9 from Paul Thomas pault at gcc dot gnu.org 2013-03-13 06:37:00 UTC --- Fixed on 4.6, 4.7 and 4.8. Thanks for the report. Paul
[Bug target/56263] [avr] Provide strict address-space checking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56263
--- Comment #8 from demiurg_spb at freemail dot ru 2013-03-13 06:46:40 UTC ---
(In reply to comment #7)
Sorry? I don't understand you last remark. Are you saying it is trivial to
implement in the avr backend?
No. Implementation is hard work.
I mean that if we take (typeof(lhs)==typeof(rhs)) axiom in initialization and
assignment: we have no logical problem at all.
Before implementing it, you'll have to specify it. What should do this code?
const __flash char* f (int i)
{
const __flash char *p = Hallo + i;
return p;
}
Yes it's not trivial... But it should be equal to next cases:
const __flash char* f (int i)
{
const __flash char *p = Hallo; // flash str
return p[i];
}
const __flash char* f (int i)
{
return Hallo + i; // flash str
}
const __flash char* f (int i)
{
return Hallo[i]; // flash str
}
[Bug libstdc++/56609] New: [C++11] Several type traits give incorrect results for std::nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56609 Bug #: 56609 Summary: [C++11] Several type traits give incorrect results for std::nullptr_t Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: daniel.krueg...@googlemail.com The following code is rejected when compiled with gcc 4.8.0 20130310 (experimental) or with gcc 4.7.2 using the flags -Wall -std=c++11 -pedantic //-- #include type_traits typedef decltype(nullptr) np_t; static_assert(std::is_scalarnp_t::value, ); static_assert(!std::is_classnp_t::value, ); static_assert(std::is_fundamentalnp_t::value, ); // #7 static_assert(!std::is_compoundnp_t::value, ); // #8 //-- 7|error: static assertion failed: | 8|error: static assertion failed: | According to 3.9 p9 std::nullptr_t is a scalar type, I also read 3.9.1 p10 that it is a fundamental type. This is confirmed by 3.9.2 not listing anything that can be applied to std::nullptr_t. I think the code should be accepted.
[Bug c++/56607] [4.8 regression] GCC fails to warn on division by zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56607 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-13 Component|c |c++ CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever Confirmed|0 |1 Target Milestone|--- |4.8.0
[Bug c++/56607] [4.8 regression] GCC fails to warn on division by zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56607 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-13 08:35:26 UTC --- Created attachment 29660 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29660 gcc48-pr56607.patch For the C++ warning regression, here is an untested fix, but wonder if we shouldn't defer it for 4.8.1.
[Bug bootstrap/56593] LTO profiledbootstrap fails for Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56593 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-03-13 08:53:29 UTC --- (In reply to comment #2) The ICE in output_die is a known issue: when LTO puts nested and parent functions in different partitions, implicit assumptions made in dwarf2out.c are no longer valid and DIEs end up with no parent. We use this patch internally: * dwarf2out.c (fixup_limbo_list): New function extracted from... In LTO mode, iterate until the list is fully drained. (dwarf2out_finish): ...here. Call it both after regular processing and after the call to resolve_addr in LTO mode. lto/ * lto.c (lto_register_var_decl_in_symtab): Do not change the assembler name in LTRANS mode. to make -g sort of work in LTO mode. The other issue is new I think. Btw, I agree with you that restricting partitioning of nested functions would be arbitrary. As of the above - did you figure out which construct confuses dwarf2out.c? We might as well strip that confusing information during streaming (much like we do with almost all abstract origins).
[Bug bootstrap/56593] LTO profiledbootstrap fails for Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56593 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-13 09:05:34 UTC --- But if you strip that info away, you'll never get correct DWARF debug info for the nested function, I believe you'll never get it whenever you put the nested functions in a different partition from the containing function. Because the nested function must be a child of the parent's DW_TAG_subprogram, if you have it in different partition, it can't be.
[Bug tree-optimization/56608] [4.7/4.8 Regression] SLP seems to produce incorrect value with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56608 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Known to work||4.6.4 Keywords||wrong-code Last reconfirmed||2013-03-13 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Summary|SLP seems to produce|[4.7/4.8 Regression] SLP |incorrect value with|seems to produce incorrect |-ffast-math |value with -ffast-math Target Milestone|--- |4.7.3 Known to fail||4.7.3, 4.8.0 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-03-13 09:08:04 UTC --- Confirmed. Note we also generate non-optimal code in that we keep both the vectorized and non-vectorized paths: _81 = (int) _80; uf_15(D)-autoCropHeight = _81; ... _84 = (double) _81; _85 = _83 / _84; if (aspectRatio_20 _85) goto bb 9; else goto bb 10; bb 9: _86 = _84 * aspectRatio_20; _87 = _86 + 5.0e-1; _88 = __builtin_ifloor (_87); and vectorized: vect_p.26_224 = uf_15(D)-rotatedHeight; MEM[(struct ufraw_data *)vect_p.26_224] = vect_var_.22_217; instead of re-loading the scalars from the vector. That is, when looking for scalar stores we start the SLP instance from we fail to verify that no uses of the scalars in the instance remain after vectorization. Or if they remain, we fail to replace them with vector extracts. Not sure yet what's the wrong code issue (nothing obvious yet, still investigating).
[Bug tree-optimization/56610] New: IPA(-CP) clone materialization fails to cleanup the CFG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56610
Bug #: 56610
Summary: IPA(-CP) clone materialization fails to cleanup the
CFG
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: hubi...@gcc.gnu.org
__attribute__((noinline)) static int
foo (int x)
{
int i = 1;
if (x 1)
do
bar (i);
while (++i != x);
}
void
baz (void)
{
foo (1);
foo (1);
foo (1);
}
We can see a
if (1 == 0)
survive for a long time. When IPA-CP get's the chance to look at the
clones body in ipcp_transform_function there is nothing that changes
the CFG and thus it doesn't queue a cfg-cleanup to fix up the above
(which is created by clone materialization itself).
Now we can just unconditionally schedule a cfg-cleanup after IPA-CP,
but really all those todos should queue up for all IPA transforms
(including fixup-cfg, which should be a IPA transform-only pass in the
IPA pipeline).
[Bug libstdc++/56609] [C++11] Several type traits give incorrect results for std::nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56609
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2013-03-13
AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot
|gnu.org |com
Ever Confirmed|0 |1
--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-13
09:46:50 UTC ---
Seems straightforward enough to be fixable in 4.8.0 too. Does this patchlet
cover all the issues you can see?
Index: type_traits
===
--- type_traits (revision 196609)
+++ type_traits (working copy)
@@ -444,7 +444,7 @@
/// is_fundamental
templatetypename _Tp
struct is_fundamental
-: public __or_is_arithmetic_Tp, is_void_Tp::type
+: public __or_is_arithmetic_Tp, is_void_Tp,
__is_nullptr_t_Tp::type
{ };
/// is_object
[Bug plugins/45078] config/vxworks-dummy.h not installed as a plugin header on some archs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45078 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-13 09:48:01 UTC --- Author: jakub Date: Wed Mar 13 09:47:41 2013 New Revision: 196629 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196629 Log: PR plugins/45078 * config.gcc: On arm, mips, sh and sparc add vxworks-dummy.h to tm_file. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc
[Bug c++/56607] [4.8 regression] GCC fails to warn on division by zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56607 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Target Milestone|4.8.0 |4.8.1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-13 09:50:12 UTC --- Let's defer it.
[Bug middle-end/54896] optimization slowness on large basic blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54896 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2013-03-13 09:53:06 UTC --- (In reply to comment #8) With r196576 on x86_64 (gcc17): at -O1: alias stmt walking : 30.99 (36%) usr reload CSE regs : 18.94 (22%) usr CSE : 14.94 (17%) usr tree DSE: 9.32 (11%) usr at -O2: alias stmt walking : 46.65 (30%) usr reload CSE regs : 37.92 (25%) usr CSE 2 : 29.09 (19%) usr CSE : 15.02 (10%) usr at -O3: tree slp vectorization : 129.79 (61%) usr alias stmt walking : 46.52 (22%) usr I have patches for the SLP vectorization part, queued for 4.9.
[Bug libstdc++/56609] [C++11] Several type traits give incorrect results for std::nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56609 --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-03-13 09:55:33 UTC --- (In reply to comment #1) Seems straightforward enough to be fixable in 4.8.0 too. Does this patchlet cover all the issues you can see? Thanks Paolo! I cannot test this from here, but this fix is what I would have thought of as well.
[Bug libstdc++/56609] [C++11] Several type traits give incorrect results for std::nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56609 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-13 09:58:29 UTC --- Thanks. Let's go ahead then and resolve this specific issue as you filed it. The fix should be very safe because std::is_fundamental is not used anywhere as an implementation detail.
[Bug bootstrap/56593] LTO profiledbootstrap fails for Ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56593 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org 2013-03-13 09:59:29 UTC --- (In reply to comment #8) But if you strip that info away, you'll never get correct DWARF debug info for the nested function, I believe you'll never get it whenever you put the nested functions in a different partition from the containing function. Because the nested function must be a child of the parent's DW_TAG_subprogram, if you have it in different partition, it can't be. Well, I see no good reason to ship end emit both parent and child to every LTRANS unit where either one may be inlined / cloned. As Eric says debug info is quite useless with optimization for nested functions I'd rather strip the info than ICEing (or hacking around the ICE in dwarf2out.c). For LTO / early debug we'd want to emit debug for both together. I still envision sth like emitting a complete dwarf unit at compile-time for each TU, without debug info for the actual code, and ship references to those throughout WPA / LTRANS, where in LTRANS we only emit debug info for the actual code, refering to the abstract info emitted at compile-time. Not sure how those references can end up working - eventually we'd need to merge the dwarf trees at final link time for that, or eventually cross-dwarf section relocations are possible ...
[Bug c++/56611] New: [C++11] Template instanciation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 Bug #: 56611 Summary: [C++11] Template instanciation failure with variadic arguments and template aliases Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: antoine...@gmail.com The attached code fails to compile because of failed template instanciation / type matching, but seems correct, compiles with clang, and can be made to compile with gcc with minor modifications (see code comments). Problem statement: RFunc(int, int) need result2int, int but the compiler does not seem able to instanciate result2int, int. If result2int, int is explicitly instanciated, the code compiles. Also if template alias result2 is replaced with a typedef in a class (result1) the code compiles. __ gcc 4.7.2 configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-2ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --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.7 --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
[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #29657|0 |1 is obsolete|| --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-13 10:36:14 UTC --- Created attachment 29661 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29661 gcc48-pr53265.patch Updated patch as per IRC discussions. Still need to look at longbranch2.C and do_1.f90, then test it.
[Bug plugins/45078] config/vxworks-dummy.h not installed as a plugin header on some archs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45078 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Known to fail|| --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-13 10:42:04 UTC --- Should be fixed now for 4.8+.
[Bug tree-optimization/56608] [4.7/4.8 Regression] SLP seems to produce incorrect value with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56608 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-03-13 10:43:23 UTC --- Ick. SLP replaces scale_51 = sqrt (_50); with scale_51 = 0.0; but has not eliminated all uses of it. I have a simple fix, but really I see no reason why DCE should not be able to remove the scalar calls given /* We only handle functions that do not read or clobber memory -- i.e. const or novops ones. */ if (!(gimple_call_flags (call) (ECF_CONST | ECF_NOVOPS))) return NULL_TREE;
[Bug tree-optimization/56612] New: basic-block vectorization does not replace all scalar uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56612 Bug #: 56612 Summary: basic-block vectorization does not replace all scalar uses Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org When vectorizing stmts in a basic-block we do not verify that the SLP instance covers all uses of the definitions the stmts in the SLP tree. This can easily result in both the scalar and vectorized set of stmts being kept live and executed. See PR56608 for an example (trivial re-use of the SLP roots stored values).
[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265
--- Comment #24 from Richard Biener rguenth at gcc dot gnu.org 2013-03-13
11:00:11 UTC ---
(In reply to comment #23)
Created attachment 29661 [details]
gcc48-pr53265.patch
Updated patch as per IRC discussions. Still need to look at longbranch2.C and
do_1.f90, then test it.
Looks good. Few comments:
+ number_of_latch_executions (loop);
add a comment what side-effect you are interested in.
+
+ /* If we know the exact number of iterations of this loop avoid all the
+ work below and most importantly do not break code with undefined
+ behavior by recording smaller maximum number of iterations. */
+ if (loop-nb_iterations
+ TREE_CODE (loop-nb_iterations) == INTEGER_CST
+ loop-any_upper_bound
+ loop-nb_iterations_upper_bound.ucmp
+ (tree_to_double_int (loop-nb_iterations)) 0)
+loop-nb_iterations_upper_bound = tree_to_double_int
(loop-nb_iterations);
We don't avoid any work, so adjust the comment. I'd also simply do:
/* If we know the exact number of iterations record that as the
upper bound as well. This avoids breaking code with undefined
behavior by eventually recording a smaller maximum. */
if (loop-nb_iterations
TREE_CODE (loop-nb_iterations) == INTEGER_CST)
{
loop-any_upper_bound = true;
loop-nb_iterations_upper_bound = tree_to_double_int
(loop-nb_iterations);
}
that's always correct.
[Bug c++/56611] [C++11] Template instanciation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-03-13 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-13 11:00:51 UTC --- The attachment is missing.
[Bug c++/56611] [C++11] Template instanciation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 --- Comment #2 from Antoine Poliakov antoinep92 at gmail dot com 2013-03-13 11:09:19 UTC --- Created attachment 29662 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29662 g++ -std=c++11 -Wall -Wextra -c gcc-test.cpp
[Bug tree-optimization/56612] basic-block vectorization does not replace all scalar uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56612 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-13 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-13 11:09:55 UTC --- Choice is to either not vectorize or replace remaining scalar uses with vector extracts.
[Bug c++/56611] [C++11] Template instantiation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 --- Comment #3 from Antoine Poliakov antoinep92 at gmail dot com 2013-03-13 11:12:25 UTC --- (In reply to comment #1) The attachment is missing. Thanks! I got an error on first upload, but I thought it was ok - sorry.
[Bug c++/56611] [C++11] Template instantiation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-13 11:14:08 UTC --- This works in mainline and isn't a regression. I guess we can add the testcase to be safe and close the issue.
[Bug libstdc++/56609] [C++11] Several type traits give incorrect results for std::nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56609 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2013-03-13 11:16:05 UTC --- Author: paolo Date: Wed Mar 13 11:15:45 2013 New Revision: 196630 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196630 Log: 2013-03-13 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/56609 * include/std/type_traits (is_fundamental): Add std::nullptr_t. * testsuite/20_util/is_fundamental/value.cc: Extend. * testsuite/20_util/is_compound/value.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/type_traits trunk/libstdc++-v3/testsuite/20_util/is_compound/value.cc trunk/libstdc++-v3/testsuite/20_util/is_fundamental/value.cc
[Bug libstdc++/56609] [C++11] Several type traits give incorrect results for std::nullptr_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56609 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-13 11:21:10 UTC --- Done.
[Bug c++/56611] [C++11] Template instantiation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2013-03-13 11:44:47 UTC --- Author: paolo Date: Wed Mar 13 11:44:32 2013 New Revision: 196631 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196631 Log: 2013-03-13 Paolo Carlini paolo.carl...@oracle.com PR c++/56611 * g++.dg/cpp0x/alias-decl-32.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-32.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/56611] [C++11] Template instantiation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0 Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-13 11:47:28 UTC --- Done.
[Bug c++/56611] [C++11] Template instantiation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 --- Comment #7 from Antoine Poliakov antoinep92 at gmail dot com 2013-03-13 12:15:30 UTC --- Thanks. You can remove struct result1 (lines 11-15 in alias-decl-32.C) from the test-case, it's not necessary (I would have done it but it's a very minor edit and I don't have commit right).
[Bug tree-optimization/56608] [4.7/4.8 Regression] SLP seems to produce incorrect value with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56608 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-03-13 12:15:22 UTC --- Author: rguenth Date: Wed Mar 13 12:15:06 2013 New Revision: 196632 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196632 Log: 2013-03-13 Richard Biener rguent...@suse.de PR tree-optimization/56608 * tree-vect-slp.c (vect_schedule_slp): Do not remove scalar calls when vectorizing basic-blocks. * gcc.dg/vect/fast-math-bb-slp-call-3.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/fast-math-bb-slp-call-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug c++/56611] [C++11] Template instantiation failure with variadic arguments and template aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56611 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-13 12:31:38 UTC --- Done, thanks (in the future, please void DOS-style CRs in the testcases)
[Bug tree-optimization/56608] [4.7 Regression] SLP seems to produce incorrect value with -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56608 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Summary|[4.7/4.8 Regression] SLP|[4.7 Regression] SLP seems |seems to produce incorrect |to produce incorrect value |value with -ffast-math |with -ffast-math Known to fail|4.8.0 | --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-03-13 13:16:23 UTC --- Fixed for trunk for now.
[Bug libstdc++/56613] New: [4.8 Regression] map::operator[](key_type) fails with custom allocator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56613
Bug #: 56613
Summary: [4.8 Regression] map::operator[](key_type) fails
with custom allocator
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
This program is valid in C++03 and C++11 but can't be compiled with trunk using
-std=c++11
#include map
templatetypename T
struct alloc
{
typedef T value_type;
typedef T* pointer;
typedef const T* const_pointer;
typedef T reference;
typedef const T const_reference;
typedef unsigned size_type;
typedef int difference_type;
templatetypename U
struct rebind {
typedef allocU other;
};
alloc() { }
templatetypename U
alloc(const allocU) { }
pointer allocate(size_type n, const void* = 0) { return
std::allocatorT().allocate(n); }
void deallocate(pointer p, size_type n) { std::allocatorT().deallocate(p,
n); }
size_type max_size() const { return -1; }
void construct(pointer p, const T t) { new ((void*) p) T(t); }
void destroy(pointer p) { p-~T(); }
};
templatetypename T, typename U
bool operator==(allocT, allocU) { return true; }
templatetypename T, typename U
bool operator!=(allocT, allocU) { return false; }
int main()
{
std::mapint, int, std::lessint, allocint m;
m[1];
}
$ g++-4.8 -std=c++11 map.cc
In file included from /home/redi/gcc/4.x/include/c++/4.8.0/map:60:0,
from map.cc:1:
/home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_tree.h: In instantiation of
'std::_Rb_tree_node_Val* std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare,
_Alloc::_M_create_node(_Args ...) [with _Args = {const
std::piecewise_construct_t, std::tupleint, std::tuple}; _Key = int; _Val
= std::pairconst int, int; _KeyOfValue = std::_Select1ststd::pairconst int,
int ; _Compare = std::lessint; _Alloc = allocstd::pairconst int, int ;
std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare, _Alloc::_Link_type =
std::_Rb_tree_nodestd::pairconst int, int *]':
/home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_tree.h:1662:64: required from
'std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare, _Alloc::iterator
std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare,
_Alloc::_M_emplace_hint_unique(std::_Rb_tree_Key, _Val, _KeyOfValue,
_Compare, _Alloc::const_iterator, _Args ...) [with _Args = {const
std::piecewise_construct_t, std::tupleint, std::tuple}; _Key = int; _Val
= std::pairconst int, int; _KeyOfValue = std::_Select1ststd::pairconst int,
int ; _Compare = std::lessint; _Alloc = allocstd::pairconst int, int ;
std::_Rb_tree_Key, _Val, _KeyOfValue, _Compare, _Alloc::iterator =
std::_Rb_tree_iteratorstd::pairconst int, int ; std::_Rb_tree_Key, _Val,
_KeyOfValue, _Compare, _Alloc::const_iterator =
std::_Rb_tree_const_iteratorstd::pairconst int, int ]'
/home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_map.h:484:8: required from
'std::map_Key, _Tp, _Compare, _Alloc::mapped_type std::map_Key, _Tp,
_Compare, _Alloc::operator[](std::map_Key, _Tp, _Compare,
_Alloc::key_type) [with _Key = int; _Tp = int; _Compare = std::lessint;
_Alloc = allocint; std::map_Key, _Tp, _Compare, _Alloc::mapped_type = int;
std::map_Key, _Tp, _Compare, _Alloc::key_type = int]'
map.cc:41:8: required from here
/home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_tree.h:403:8: error: no matching
function for call to 'allocstd::_Rb_tree_nodestd::pairconst int, int
::construct(std::_Rb_tree_nodestd::pairconst int, int *, const
std::piecewise_construct_t, std::tupleint, std::tuple)'
_M_get_Node_allocator().construct(__tmp,
^
/home/redi/gcc/4.x/include/c++/4.8.0/bits/stl_tree.h:403:8: note: candidate is:
map.cc:28:10: note: void allocT::construct(allocT::pointer, const T) [with
T = std::_Rb_tree_nodestd::pairconst int, int ; allocT::pointer =
std::_Rb_tree_nodestd::pairconst int, int *]
void construct(pointer p, const T t) { new ((void*) p) T(t); }
^
map.cc:28:10: note: candidate expects 2 arguments, 4 provided
The problem is that stl_map.h uses piecewise construction for the pair object,
which calls alloc::construct with four arguments, incorrectly assuming that all
allocators in C++11 have a variadic construct() member.
It's easily fixed by changing the C++11 version of _M_create_node to use
allocator_traits::construct:
std::allocator_traits_Node_allocator::
construct(_M_get_Node_allocator(), __tmp,
std::forward_Args(__args)...);
(For 4.9 I was going to make all the RB-trees allocator-aware, but this
regression needs to be fixed for 4.8 without the rest of the allocator
[Bug libstdc++/56613] [4.8 Regression] map::operator[](key_type) fails with custom allocator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56613
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-13
13:35:14 UTC ---
Oops, the program isn't quite valid C++03, I forgot these members of the
allocator:
pointer address(reference x) const throw() { return x; }
const_pointer address(const_reference x) const throw() { return x; }
That doesn't affect the issue though.
[Bug target/55947] non constant memory models lose HLE qualifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947
--- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2013-03-13
13:49:10 UTC ---
It was pointed out to me that atomic triggers this with, when compiled with no
optimization. For HLE wrong hints would be generated.
bool test_and_set(memory_order __m = memory_order_seq_cst) noexcept
{
return __atomic_test_and_set (_M_i, __m);
}
bool foo(std::atomic_flag fl) {
return fl.test_and_set(std::memory_order_relaxed);
}
[Bug target/55948] __atomic_clear / __atomic_store_n ignore HLE_RELEASE flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55948 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Andi Kleen andi-gcc at firstfloor dot org 2013-03-13 13:53:33 UTC --- patch was checked in some time ago
[Bug target/55947] non constant memory models lose HLE qualifiers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55947 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-13 14:15:51 UTC --- Not wrong, if the code isn't inlined and thus the model is variable, HLE hints will be ignored and seq_cst model will be used. If you want something else, even for -O0, just use inline with __attribute__((always_inline)) to ensure it is inlined.
[Bug fortran/56596] Invalid read of size 4 gfortran.dg/class_array_7.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56596 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2013-03-13 14:17:40 UTC --- Reduced test case: program main implicit none type :: base_type integer :: i end type type, extends(base_type) :: extended_type integer :: j end type class(base_type), dimension(:), allocatable :: a type(extended_type), dimension(1:2) :: tmp allocate (extended_type :: a(2)) tmp%i=a%i end I think the problem is in the allocate statement: a._data.data = (void * restrict) __builtin_malloc (8); The allocation size seems to be independent of whether one allocates with base_type or extended type.
[Bug c++/56607] [4.8 regression] GCC fails to warn on division by zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56607 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-03-13 14:18:34 UTC --- The patch is OK for 4.8.1.
[Bug debug/56307] FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra Created a debug-only replacement for s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56307 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-13 14:33:07 UTC --- Ah yes, I forgot that all of -fvar-tracking is disabled for non-dwarf debug. Yeah, passing -fvar-tracking -fvar-tracking-assignments in dg-options is desirable for that test. The test isn't -O3, so not even on ia64 sel-sched will be on by default.
[Bug c++/56346] FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56346 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Attachment #29638|0 |1 is obsolete|| --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2013-03-13 14:41:54 UTC --- Created attachment 29663 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29663 patch 2 That's odd, the change seems unlikely to have changed the flow analysis. But anyway, this patch always initializes addr. Better?
[Bug c++/56614] New: [4.7/4.8 Regression] error: default argument 'std::vectorE(std::initializer_listE{((const E*)( ._0)), 1u}, (*(const std::allocatorE*)( std::allocatorE())))' uses local v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56614
Bug #: 56614
Summary: [4.7/4.8 Regression] error: default argument
'std::vectorE(std::initializer_listE{((const E*)(
._0)), 1u}, (*(const std::allocatorE*)(
std::allocatorE(' uses local variable '._0'
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
#include initializer_list
namespace std
{
templatetypename T
struct allocator
{ };
templatetypename T, typename Alloc = std::allocatorT
struct vector
{
vector(std::initializer_listT, const Alloc = Alloc()) { }
};
}
void func() { }
enum E { ee };
struct C
{
templatetypename T
C(T, std::vectorE = std::vectorE({ ee }))
{ }
};
struct G
{
void gen()
{
C c(func);
}
};
$ g++ -std=c++11 err.cc
err.cc: In constructor 'C::C(T, std::vectorE) [with T = void (*)()]':
err.cc:31:18: error: default argument
'std::vectorE(std::initializer_listE{((const E*)( ._0)), 1u}, (*(const
std::allocatorE*)( std::allocatorE(' uses local variable '._0'
C c(func);
^
[Bug c++/56346] FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56346 --- Comment #7 from dave.anglin at bell dot net 2013-03-13 15:23:11 UTC --- On 3/13/2013 10:42 AM, jason at gcc dot gnu.org wrote: That's odd, the change seems unlikely to have changed the flow analysis. But anyway, this patch always initializes addr. Better? I hacked the original patch to avoid the error. Change fixed the test failures, so approach looks good. Will test new patch.
[Bug middle-end/56524] [4.8 Regression] Compiler ICE when compiling with -mips16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56524 --- Comment #13 from clm at gcc dot gnu.org 2013-03-13 15:38:37 UTC --- Author: clm Date: Wed Mar 13 15:37:36 2013 New Revision: 196635 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196635 Log: 2013-03-13 Catherine Moore c...@codesourcery.com Merge from Mainline: 2013-03-09 Richard Sandiford rdsandif...@googlemail.com PR middle-end/56524 Added: branches/clm-micromips/gcc/testsuite/gcc.target/mips/pr56524.c Modified: branches/clm-micromips/gcc/ChangeLog branches/clm-micromips/gcc/c-family/ChangeLog branches/clm-micromips/gcc/c-family/c-common.c branches/clm-micromips/gcc/function.c branches/clm-micromips/gcc/function.h branches/clm-micromips/gcc/optabs.c branches/clm-micromips/gcc/tree.h
[Bug fortran/56581] Segfault when reading source file which starts with a byte-order mark (-cpp works)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581 --- Comment #9 from Walt Brainerd walt.brainerd at gmail dot com 2013-03-13 16:12:35 UTC --- Thanks for sending me this. Maybe I did after all provide something that will help you. On Tue, Mar 12, 2013 at 3:05 PM, tkoenig at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56581 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code, ||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed|2013-03-10 00:00:00 |2013-03-12 Ever Confirmed|0 |1 --- Comment #8 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-03-12 22:05:12 UTC --- We try to support this, but apparently it doesn't work (see line 2015 and following of scanner.c). Same thing happens for 4.6 and 4.7. Valgrind tells me ==11226== Memcheck, a memory error detector ==11226== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==11226== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info ==11226== Command: /home/ig25/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/f951 ice.f ==11226== ==11226== Invalid write of size 4 ==11226==at 0x580400: load_line(_IO_FILE*, unsigned int**, int*, int const*) (scanner.c:1646) ==11226==by 0x5811C3: load_file(char const*, char const*, bool) (scanner.c:2009) ==11226==by 0x582F82: gfc_new_file() (scanner.c:2120) ==11226==by 0x5A1DA7: gfc_init() (f95-lang.c:224) ==11226==by 0x94F286: toplev_main(int, char**) (toplev.c:1700) ==11226==by 0x5A38454: (below main) (in /lib64/libc-2.15.so) ==11226== Address 0x5ea3e30 is 0 bytes after a block of size 288 alloc'd ==11226==at 0x4C292B8: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11226==by 0xE54110: xcalloc (xmalloc.c:162) ==11226==by 0x58155E: load_file(char const*, char const*, bool) (scanner.c:2030) ==11226==by 0x582F82: gfc_new_file() (scanner.c:2120) ==11226==by 0x5A1DA7: gfc_init() (f95-lang.c:224) ==11226==by 0x94F286: toplev_main(int, char**) (toplev.c:1700) ==11226==by 0x5A38454: (below main) (in /lib64/libc-2.15.so) -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug.
[Bug c++/56614] [4.7/4.8 Regression] error: default argument 'std::vectorE(std::initializer_listE{((const E*)( ._0)), 1u}, (*(const std::allocatorE*)( std::allocatorE())))' uses local variab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56614 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-13 Target Milestone|--- |4.7.3 Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-13 16:47:56 UTC --- Confirmed.
[Bug c++/56614] [4.7/4.8 Regression] error: default argument 'std::vectorE(std::initializer_listE{((const E*)( ._0)), 1u}, (*(const std::allocatorE*)( std::allocatorE())))' uses local variab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56614
--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-13
17:29:02 UTC ---
A few details can be removed from the testcase:
#include initializer_list
struct vector
{
vector(std::initializer_listint);
};
void func();
struct C
{
templatetypename T
C(T, vector = vector({}));
};
C c(func);
[Bug c++/56614] [4.7/4.8 Regression] error: default argument 'std::vectorE(std::initializer_listE{((const E*)( ._0)), 1u}, (*(const std::allocatorE*)( std::allocatorE())))' uses local variab
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56614 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-13 17:36:27 UTC --- Ah, thanks. I reduced it from 300KLOC and apparently stopped too soon :)
[Bug target/49880] SuperH: ICE when -m4 is used with -mdiv=call-div1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49880 --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org 2013-03-13 18:09:16 UTC --- Author: olegendo Date: Wed Mar 13 18:09:10 2013 New Revision: 196636 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196636 Log: PR target/49880 * config/sh/sh.opt (FPU_SINGLE_ONLY): New mask. (musermode): Convert to Var(TARGET_USERMODE). * config/sh/sh.h (SELECT_SH2A_SINGLE_ONLY, SELECT_SH4_SINGLE_ONLY, MASK_ARCH): Add MASK_FPU_SINGLE_ONLY. * config/sh/sh.c (sh_option_override): Use TARGET_FPU_DOUBLE || TARGET_FPU_SINGLE_ONLY for call-fp case. * config/sh/sh.md (udivsi3_i1, divsi3_i1): Remove ! TARGET_SH4 condition. (udivsi3_i4, divsi3_i4): Use TARGET_FPU_DOUBLE condition instead of TARGET_SH4. (udivsi3_i4_single, divsi3_i4_single): Use TARGET_FPU_SINGLE_ONLY || TARGET_FPU_DOUBLE instead of TARGET_HARD_SH4. PR target/49880 * config/sh/lib1funcs.S (sdivsi3_i4, udivsi3_i4): Enable for SH2A. (sdivsi3, udivsi3): Remove SH4 check and always compile these functions. PR target/49880 * gcc.target/sh/pr49880-1.c: New. * gcc.target/sh/pr49880-2.c: New. * gcc.target/sh/pr49880-3.c: New. * gcc.target/sh/pr49880-4.c: New. * gcc.target/sh/pr49880-5.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr49880-1.c trunk/gcc/testsuite/gcc.target/sh/pr49880-2.c trunk/gcc/testsuite/gcc.target/sh/pr49880-3.c trunk/gcc/testsuite/gcc.target/sh/pr49880-4.c trunk/gcc/testsuite/gcc.target/sh/pr49880-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.h trunk/gcc/config/sh/sh.md trunk/gcc/config/sh/sh.opt trunk/gcc/testsuite/ChangeLog trunk/libgcc/ChangeLog trunk/libgcc/config/sh/lib1funcs.S
[Bug target/55295] [SH] Add support for fipr instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295 --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org 2013-03-13 18:21:37 UTC --- (In reply to comment #5) This is another reason for adding a new ABI, BTW. Just for the record, I've opened a new PR 56592 for this.
[Bug target/56446] Generate one fewer relocation when calling a checked weakref function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56446 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7/4.8 Regression]|Generate one fewer |Generate one fewer |relocation when calling a |relocation when calling a |checked weakref function |checked weakref function| Severity|normal |enhancement --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2013-03-13 19:51:52 UTC --- Given comments #5 and #7, this probably should not be marked as a regression, but rather as an enhancement. Is it possible to tell if the called symbol is in the same module if compiling with LTO?
[Bug target/38134] [4.6/4.7/4.8 Regression] speed regression with many loop invariants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134 --- Comment #21 from Steven Bosscher steven at gcc dot gnu.org 2013-03-13 20:09:42 UTC --- (In reply to comment #20) Ok, the goal would be to have all !targetm.legitimate_constant_p () constants assigned to a pseudo (and in GIMPLE to an SSA name). I'm not sure this would be a very useful thing to do. What is a legitimate constant for one insn may be non-legit for another. You may end up doing more harm than good...
[Bug target/43052] [4.7/4.8 Regression] Inline memcmp is *much* slower than glibc's, no longer expanded inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052 --- Comment #23 from Steven Bosscher steven at gcc dot gnu.org 2013-03-13 20:13:32 UTC --- Honza, ping?
[Bug rtl-optimization/21182] [4.6/4.7/4.8 Regression] gcc can use registers but uses stack instead
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21182 --- Comment #12 from Steven Bosscher steven at gcc dot gnu.org 2013-03-13 20:37:23 UTC --- Curious to hear whether -fschedule-insns -fsched-pressure helps. At least from the %esp and %ebp counts, it looks hopeful: $ ./cc1 -quiet -m32 -O2 t.c -DNAIL_REGS -o t.s.NAIL $ ./cc1 -quiet -m32 -O2 t.c -UNAIL_REGS -o t.s $ ./cc1 -quiet -m32 -O2 t.c -UNAIL_REGS -o t.s.sched_pres \ -fschedule-insns -fsched-pressure $ egrep -c '%ebp|%esp' t.s* t.s:366 t.s.NAIL:305 t.s.sched_pres:277 $ grep ident t.s .ident GCC: (GNU) 4.8.0 20130313 (experimental) [trunk revision 196638] It is unfortunate that nobody has put in the resources yet to make options like -fschedule-insns -fsched-pressure the default for x86.
[Bug tree-optimization/45685] [4.6/4.7/4.8 Regression] missed conditional move opportunity in loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45685 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #24 from Steven Bosscher steven at gcc dot gnu.org 2013-03-13 20:45:30 UTC --- (In reply to comment #19) I did some runtime testing on this shortly after 4.7 stage1 opened; the net result was actually a regression. I didn't delve into why due to time constraints. Without analysis as to why the patch regressed spec, I wouldn't be comfortable suggesting it for any stage. Still looks like an interesting approach, tho'. Do you plan to have a look at this for GCC 4.9?
[Bug target/48308] [4.6 Regression] crosscompiling to arm fails with assembler: can't resolve '.LC4' {.rodata.str1.1 section} - '.LPIC4' {*UND* section}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
Keywords||patch
Last reconfirmed|2011-03-29 15:23:12 |2013-03-07 12:46:35
Known to work||4.7.2, 4.8.0
Summary|[4.6/4.7/4.8 Regression]|[4.6 Regression]
|crosscompiling to arm fails |crosscompiling to arm fails
|with assembler: can't |with assembler: can't
|resolve '.LC4' |resolve '.LC4'
|{.rodata.str1.1 section} - |{.rodata.str1.1 section} -
|'.LPIC4' {*UND* section}|'.LPIC4' {*UND* section}
Known to fail|4.7.0 |
--- Comment #25 from Steven Bosscher steven at gcc dot gnu.org 2013-03-13
20:55:12 UTC ---
http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00666.html and follow-ups
claim to have fixed this for GCC 4.7 and GCC 4.8.
Ramana, you should take care of the bug reports assigned to you. Also,
you should have added a test case.
http://gcc.gnu.org/PR56561#c4 has a patch for GCC 4.6.
[Bug pending/55996] [meta-bug] GCC 4.9 pending patches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55996 --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2013-03-13 22:34:37 UTC --- Fix for DSE causing combine compile time and memory explosion: http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00379.html (rationale) http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00441.html (corrected patch) Make gcse.c respect -fno-gcse-lm: http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00386.html (already approved)
[Bug libstdc++/56613] [4.8 Regression] map::operator[](key_type) fails with custom allocator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56613 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-14 AssignedTo|unassigned at gcc dot |redi at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-14 01:43:53 UTC --- Created attachment 29664 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29664 fix the bug by using allocator_traits
