[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #4 from Marc Glisse glisse at gcc dot gnu.org 2013-04-25 06:19:35
UTC ---
(In reply to comment #0)
Now suppose the following function:
void g(A a)
{
a.p();
}
Which overload should GCC call? This is my request for clarification. I
couldn't find anything specific in the standard that would help explain one
way
or the other.
Intuitively, it would be the rvalue overload, but gcc calls the lvalue
overload
instead.
As you note in a further comment, a named rvalue reference acts as an lvalue.
Making it:
std::move(a).p();
Does not help.
It does for me...
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org 2013-04-25 06:34:03 UTC --- (In reply to comment #4) (In reply to comment #0) Making it: std::move(a).p(); Does not help. It does for me... Note that I only tested 4.9, it could be something missing in the backport.
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #6 from Thiago Macieira thiago at kde dot org 2013-04-25 06:51:33
UTC ---
void f(A a)
{
std::move(a).p();
}
_Z1fO1A:
.cfi_startproc
jmp _ZNR1A1pEv@PLT #
.cfi_endproc
Then this looks like a bug in 4.8.1.
But then are we in agreement that a.p() in that function above should call the
lvalue-ref overload? It does make the feature sligthly less useful for me. It
would require writing:
return std::move(std::move(std::move(std::move(QString(%1 %2 %3 %4)
.arg(42))
.arg(47))
.arg(-42))
.arg(-47));
[Bug c++/57066] New: std::logb(-inf) returns wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57066 Bug #: 57066 Summary: std::logb(-inf) returns wrong value Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: bolero.murak...@gmail.com auto inf = std::numeric_limitsdouble::infinity(); std::cout std::logb(-inf) std::endl; -inf is output. it is wrong. std::logb(-inf) should returns +inf. F.9.3.11 The logb functions - logb(±∞) returns +∞.
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #7 from Marc Glisse glisse at gcc dot gnu.org 2013-04-25 07:08:07
UTC ---
(In reply to comment #6)
void f(A a)
{
std::move(a).p();
}
_Z1fO1A:
.cfi_startproc
jmp _ZNR1A1pEv@PLT #
.cfi_endproc
Then this looks like a bug in 4.8.1.
Indeed, I get s/R/O/ with 4.9.
But then are we in agreement that a.p() in that function above should call the
lvalue-ref overload?
Yes.
It does make the feature sligthly less useful for me. It
would require writing:
return std::move(std::move(std::move(std::move(QString(%1 %2 %3 %4)
.arg(42))
.arg(47))
.arg(-42))
.arg(-47));
Why? You are not naming those return values, so they are still rvalues and will
use the overload. (not sure why Qstring doesn't provide a mutating interface
for arg)
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064
--- Comment #8 from Thiago Macieira thiago at kde dot org 2013-04-25 07:13:44
UTC ---
Hmm... this might be an effect of the same bug. Can you try this on 4.9?
struct A {
A p() const ;
A p() ;
};
void f()
{
A().p().p();
}
I get:
leaq15(%rsp), %rdi #, tmp60
call_ZNO1A1pEv@PLT #
movq%rax, %rdi # D.69575,
call_ZNKR1A1pEv@PLT #
Is this second call supposed to be to R? If it's to O, it's exactly what I need
to make the feature useful.
[Bug c++/57063] Valid static_cast from data member to rvalue reference fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063
--- Comment #2 from Nikolka tsoae at mail dot ru 2013-04-25 07:19:20 UTC ---
The alias is added for convenience - we can quickly test handling of different
types so. It seems that there is no problem with class types and function
types, the error arises when T is a scalar type or an array type:
#include string
template class T
struct X
{
T f()
{
return static_castT (value);
}
T value;
};
enum E {};
template class Xint;
template class XE;
template class Xstd::string;
template class Xint();
template class Xint[1];
test.cpp: In instantiation of ‘T XT::f() [with T = int]’:
test.cpp:15:20: required from here
test.cpp:8:43: error: cannot bind ‘int’ lvalue to ‘int’
return static_castT (value);
^
test.cpp: In instantiation of ‘T XT::f() [with T = E]’:
test.cpp:16:20: required from here
test.cpp:8:43: error: cannot bind ‘E’ lvalue to ‘E’
test.cpp: In instantiation of ‘T XT::f() [with T = int [1]]’:
test.cpp:19:20: required from here
test.cpp:8:43: error: cannot bind ‘int [1]’ lvalue to ‘int ()[1]’
[Bug target/57017] «Error: expecting string instruction after `rep'» in code w/o inline assembly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57017 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-25 07:27:18 UTC --- Not a bug in gcc then.
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064 --- Comment #9 from Marc Glisse glisse at gcc dot gnu.org 2013-04-25 07:28:01 UTC --- (In reply to comment #8) Is this second call supposed to be to R? If it's to O, it's exactly what I need to make the feature useful. It is O.
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064 --- Comment #10 from Thiago Macieira thiago at kde dot org 2013-04-25 07:34:21 UTC --- Great! That changes everything. Now I can provide a mutating arg() overload. I'll just need some #ifdef and build magic to add the R, O overloads without removing the nil overloads that already exist (binary compatibility). It would have been nicer if the lvalue ref overload didn't get extra decoration.
[Bug rtl-optimization/57003] [4.8/4.9 Regression] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-25 07:51:48 UTC --- Ah, so the issue is related to the fact that %rdi/%rsi aren't call clobbered in ms_abi, but are call clobbered in the sysv abi. The CALL_INSN pattern has clobbers for rsi/rdi, but copyprop_hardreg_forward_1 processes those early, perhaps then the CALL_INSN_FUNCTION_USAGE changes something and relies on regs_invalidated_by_call processing to invalidate whatever is necessary.
[Bug target/57052] missed optimization with rotate and mask
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57052 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from Alan Modra amodra at gmail dot com 2013-04-25 07:57:39 UTC --- http://gcc.gnu.org/ml/gcc-cvs/2013-04/msg00982.html
[Bug c++/57066] [4.7/4.8/4.9 Regression] std::logb(-inf) returns wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57066
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||4.1.3
Keywords||wrong-code
Last reconfirmed||2013-04-25
Ever Confirmed|0 |1
Summary|std::logb(-inf) returns |[4.7/4.8/4.9 Regression]
|wrong value |std::logb(-inf) returns
||wrong value
Target Milestone|--- |4.7.4
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-04-25
08:05:04 UTC ---
/* Fold a call to builtin logb/ilogb. */
static tree
fold_builtin_logb (location_t loc, tree arg, tree rettype)
{
...
switch (value-cl)
{
case rvc_nan:
case rvc_inf:
/* If arg is Inf or NaN and we're logb, return it. */
if (TREE_CODE (rettype) == REAL_TYPE)
return fold_convert_loc (loc, rettype, arg);
is wrong for -inf. Folding introduced in 2007 thus a regression.
[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 |WAITING --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-04-25 08:06:47 UTC --- (In reply to comment #4) (In reply to comment #3) 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. I get the same error, and merging revision 197165 from trunk into my working-directory for gcc-4_8-branch revision 198253 did not fix the error on my system. This error occured during one of the stages while building gcc, revision 198065, checked out from svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch for MinGW32, Windows 7 Pro 64-bit SP1. The error also occurs with revisions 198027 and 198253 -- that is, the error has been occuring with revisions for at least these past 7 days. The error persists after I merged revision 197165 from trunk into my working-directory for gcc-4_8-branch revision 198253. That's expected as the issue I fixed on trunk was not present on the 4.8 branch. Which is why I didn't close this bug. But as I cannot reproduce it I rely on others for investigation. Can you please provide a backtrace from the crash?
[Bug target/57057] Bad optimization on x86 for minps and maxps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57057 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-25 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-04-25 08:14:23 UTC --- That it's fixed with -O1 is because the different MINPS invocations are CSEd and only the first one is carried out. The issue here is that MINPS is not commutative, but the SMIN RTX code is specified as being commutative. Which means with !flag_finite_math_only the x86 backend has to use an UNSPEC to expand __builtin_ia32_minps and friends.
[Bug middle-end/57055] Incorrect CFG after transactional memory passes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57055 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-25 Blocks||56982 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-04-25 08:17:07 UTC --- I think we should handle it like any other returns-twice, that is, TM should split the block properly (and either call notice_special_calls or set -calls_setjmp). TM can still handle edge creation itself because it knows where abnormal transfer can originate from.
[Bug rtl-optimization/57067] New: Missing control flow edges for setjmp/longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067 Bug #: 57067 Summary: Missing control flow edges for setjmp/longjmp Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: kreb...@gcc.gnu.org The fix for PR56982 adds abnormal control flow edges from function calls to a setjmp call in the same function. Unfortunately these edges do not survive until RTL so that the RTL passes might still do the wrong thing. The edges are removed in gimple_expand_cfg: /* At the moment not all abnormal edges match the RTL representation. It is safe to remove them here as find_many_sub_basic_blocks will rediscover them. In the future we should get this fixed properly. */ if ((e-flags EDGE_ABNORMAL) !(e-flags EDGE_SIBCALL)) remove_edge (e); else ei_next (ei); find_many_sub_basic_blocks needs a fix to add them back as well. I don't have a testcase for GCC head. The testcase I have fails only with GCC 4.4: http://gcc.gnu.org/ml/gcc/2013-04/msg00237.html In this case the RTL scheduler pass generates broken code due to the missing control flow info. I think this could potentially happen with GCC head as well.
[Bug c++/57063] Valid static_cast from data member to rvalue reference fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-25 08:34:30 UTC --- In general, testcases must be minimal, otherwise, eg, you start wondering (as I did) whether the bug is in the code handling alias declarations.
[Bug c++/57068] New: gcc prints warning ref-qualifiers only available with -std=c++0x or -std=gnu++0x for operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57068 Bug #: 57068 Summary: gcc prints warning ref-qualifiers only available with -std=c++0x or -std=gnu++0x for operator Classification: Unclassified Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: kai.koe...@digia.com Created attachment 29934 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29934 minimal test file demonstrating the problem gcc from 4.8 svn branch prints an incorrect warning about ref-qualifiers only available with -std=c++0x or -std=gnu++0x for a line like if (bool(windowState() Enum1) == true) where the is actually an operator for the class returned by windowState(). Attached code demonstrates the problem. I didn't have this problem with gcc 4.8.0.
[Bug c++/57068] gcc prints warning ref-qualifiers only available with -std=c++0x or -std=gnu++0x for operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57068 Kai Koehne kai.koehne at digia dot com changed: What|Removed |Added Attachment #29934|0 |1 is obsolete|| --- Comment #1 from Kai Koehne kai.koehne at digia dot com 2013-04-25 08:41:01 UTC --- Created attachment 29935 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29935 minimal test case demonstrating the problem Added test case that actually compiles :)
[Bug c++/57066] [4.7/4.8/4.9 Regression] std::logb(-inf) returns wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57066 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-25 08:41:28 UTC --- Note that at least -O is needed + -std=c++11. With -O0 it correctly prints inf.
[Bug c++/57068] [4.8/4.9 Regression] gcc prints warning ref-qualifiers only available with -std=c++0x or -std=gnu++0x for operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57068 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-25 CC|kai.koehne at digia dot com | Summary|gcc prints warning |[4.8/4.9 Regression] gcc |ref-qualifiers only|prints warning |available with -std=c++0x |ref-qualifiers only |or -std=gnu++0x for|available with -std=c++0x |operator |or -std=gnu++0x for ||operator Ever Confirmed|0 |1
[Bug libstdc++/57065] incorrect default allocator template for debug and profile unordered_map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57065 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-25 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.9.0 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-25 09:12:47 UTC --- Mine.
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2013-04-25 09:16:12 UTC --- (In reply to comment #4) Patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01464.html . The patch doesn't work. With 4.9-20130421 + the patch I get: /tmp/objdir/./prev-gcc/xg++ -B/tmp/objdir/./prev-gcc/ -B/tmp/install49/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/tmp/objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tmp/objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/tmp/objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/tmp/gcc-4.9-20130421/libstdc++-v3/libsupc++ -L/tmp/objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -DIN_GCC_FRONTEND -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -Ifortran -I/tmp/gcc-4.9-20130421/gcc -I/tmp/gcc-4.9-20130421/gcc/fortran -I/tmp/gcc-4.9-20130421/gcc/../include -I/tmp/gcc-4.9-20130421/gcc/../libcpp/include -I/home/mikpe/pkgs/linux-x86_64/gmp-5.1.1/include -I/home/mikpe/pkgs/linux-x86_64/mpfr-3.1.2/include -I/home/mikpe/pkgs/linux-x86_64/mpc-1.0.1/include -I/tmp/gcc-4.9-20130421/gcc/../libdecnumber -I/tmp/gcc-4.9-20130421/gcc/../libdecnumber/bid -I../libdecnumber -I/tmp/gcc-4.9-20130421/gcc/../libbacktrace /tmp/gcc-4.9-20130421/gcc/fortran/module.c -o fortran/module.o /tmp/gcc-4.9-20130421/gcc/fortran/module.c:78:18: fatal error: zlib.h: No such file or directory #include zlib.h Note the absence of any -I directive to pick up the internal zlib. Zlib was built however, and e.g. lto-compress managed to pick it up: /tmp/objdir/./prev-gcc/xg++ -B/tmp/objdir/./prev-gcc/ ...-I/tmp/gcc-4.9-20130421/gcc/../zlib ... /tmp/gcc-4.9-20130421/gcc/lto-compress.c -o lto-compress.o
[Bug rtl-optimization/57067] Missing control flow edges for setjmp/longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-25 CC||matz at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-04-25 09:17:03 UTC --- I suppose more selectively removing edges would be best. Eventually this is done to cater for expansions of builtin calls to non-calls? Then maybe those edges should be removed later, _after_ builtin expansion and find_many_sub_basic_blocks?
[Bug libstdc++/57065] incorrect default allocator template for debug and profile unordered_map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57065 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-25 09:44:37 UTC --- Fixed.
[Bug rtl-optimization/57003] [4.8/4.9 Regression] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003 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 #19 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-25 09:54:20 UTC --- Created attachment 29936 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29936 gcc49-pr57003.patch Untested fix. While we kill_clobbered_value early, for SET in CALL_INSN_FUNCTION_USAGE we add a value equivalence. In standard x86_64 ABI %rdi is invalidated by the call and present in the hard reg set to invalidate, so it is removed again, and perhaps if there is some target where the first argument is passed in non-call-clobbered register, the equivalence is correct. So, what the patch does is in this case apply the clobbers again. Bernd, does this look reasonable to you as the author of those changes?
[Bug libstdc++/57049] std::swap does self move assignment, which is illegal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57049 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-04-25 09:55:47 UTC --- Here are two different things to consider: 1) The standard library specification of basic_string's move-assignment operator currently requires that it works for self-assignment: quote 21 Effects: If *this and str are not the same object, modifies *this as shown in Table 71. [...] 22 If *this and str are the same object, the member has no effect. /quote This might or might not change, depending on the outcome of LWG issue http://cplusplus.github.io/LWG/lwg-active.html#2063 2) The generic swap template from utility imposes requirements on the argument types and describes what it does (which can only rely on the requirements). So if you call swap with the same argument value and if for these argument values the move-assignment is undefined behaviour, you get what you are asking for. There is no single evidence that swap would be even allowed to prevent swapping for identical arguments, because the semantics are specified clearly to exchange the two values.
[Bug libstdc++/57065] incorrect default allocator template for debug and profile unordered_map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57065 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-25 10:01:40 UTC --- Good catch, thanks, Kenny
[Bug rtl-optimization/56957] [4.9 regression] ICE in add_insn_after, at emit-rtl.c:3783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56957 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Attachment #29886|0 |1 is obsolete|| --- Comment #9 from Andrey Belevantsev abel at gcc dot gnu.org 2013-04-25 10:03:38 UTC --- Created attachment 29937 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29937 new patch Actually, on more thought I couldn't recall why did we need all the insn_emitted and EXPR_WAS_CHANGED stuff (that was 5 years ago). The code should decide whether do we need to move the scheduling insn from below and leave the same UID or we need to emit the new insn with the new UID. The current code says that the insn needs to have the same UID as the above resulting expression, we shouldn't create any extra stuff (renaming copies, speculative checks) at the place of the original insn, and the insn itself should not be changed while it was being propagated up to the place of scheduling. However, for the last two cases (new insns created, scheduling insn changed) the UIDs will not match, as the insn pattern would be changed while moving up, so their check doesn't add anything new to the UID check. And indeed, the attached patch that only checks for UIDs passes all the tests for me. I will discuss this more with Alexander and will commit after additional testing on x86_64 as appropriate.
[Bug libstdc++/57065] incorrect default allocator template for debug and profile unordered_map
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57065 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-25 10:06:24 UTC --- Note that the www.cplusplus.com documentation has unordered_multiset wrong ;)
[Bug rtl-optimization/57003] [4.8/4.9 Regression] gcc-4.8.0 breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003 --- Comment #20 from Bernd Schmidt bernds at gcc dot gnu.org 2013-04-25 10:12:12 UTC --- Patch is OK, thanks Jakub - you were too fast for me on this one.
[Bug tree-optimization/57066] [4.7/4.8/4.9 Regression] std::logb(-inf) returns wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57066 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Component|c++ |tree-optimization AssignedTo|unassigned at gcc dot |mpolacek at gcc dot gnu.org |gnu.org | --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-25 10:26:57 UTC --- I may have a fix.
[Bug c++/56971] GCC claims a friend function to be overloaded, but it isn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56971 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-04-25 10:55:08 UTC --- For gcc 4.9.0 20130421 (experimental) this gives me an ICE: main.cpp|8|internal compiler error: canonical types differ for identical types bP and bFriendP|
[Bug c++/56976] using braces to initialize a reference forces copy construction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56976 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-04-25 11:04:31 UTC --- It seems to me as if you are observing the core language issue http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1604
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2013-04/msg01464.htm |atches/2013-04/msg01517.htm |l |l --- Comment #6 from Janne Blomqvist jb at gcc dot gnu.org 2013-04-25 11:04:42 UTC --- Updated patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01517.html
[Bug c++/56971] [4.9 Regression] GCC claims a friend function to be overloaded, but it isn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56971 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-25 Summary|GCC claims a friend |[4.9 Regression] GCC claims |function to be overloaded, |a friend function to be |but it isn't|overloaded, but it isn't Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-25 11:20:33 UTC --- ICE confirmed with trunk, which is a regression: ice.c: In instantiation of 'struct brp': ice.c:16:11: required from here ice.c:8:17: internal compiler error: canonical types differ for identical types bP and bFriendP friend void f(bFriendP from); ^ 0x64861b comptypes ../../gcc-4.9/gcc/cp/typeck.c:1395 0x64861b comptypes ../../gcc-4.9/gcc/cp/typeck.c:1369 0x649b33 compparms(tree_node const*, tree_node const*) ../../gcc-4.9/gcc/cp/typeck.c:1501 0x54526b decls_match(tree_node*, tree_node*) ../../gcc-4.9/gcc/cp/decl.c:1026 0x545cc4 duplicate_decls(tree_node*, tree_node*, bool) ../../gcc-4.9/gcc/cp/decl.c:1241 0x6e9801 push_overloaded_decl_1 ../../gcc-4.9/gcc/cp/name-lookup.c:2288 0x6e9801 push_overloaded_decl ../../gcc-4.9/gcc/cp/name-lookup.c:2383 0x6eb1ed pushdecl_maybe_friend_1 ../../gcc-4.9/gcc/cp/name-lookup.c:885 0x6eb1ed pushdecl_maybe_friend(tree_node*, bool) ../../gcc-4.9/gcc/cp/name-lookup.c:1219 0x6eca79 pushdecl_with_scope_1 ../../gcc-4.9/gcc/cp/name-lookup.c:2206 0x6ed7ab pushdecl_with_scope(tree_node*, cp_binding_level*, bool) ../../gcc-4.9/gcc/cp/name-lookup.c:2220 0x6ed86d pushdecl_namespace_level(tree_node*, bool) ../../gcc-4.9/gcc/cp/name-lookup.c:3761 0x5b9e69 tsubst_friend_function ../../gcc-4.9/gcc/cp/pt.c:8137 0x5bb493 instantiate_class_template_1 ../../gcc-4.9/gcc/cp/pt.c:8997 0x5bb493 instantiate_class_template(tree_node*) ../../gcc-4.9/gcc/cp/pt.c:9081 0x6439bb complete_type ../../gcc-4.9/gcc/cp/typeck.c:131 0x6439bb complete_type ../../gcc-4.9/gcc/cp/typeck.c:105 0x534f27 start_decl_1(tree_node*, bool) ../../gcc-4.9/gcc/cp/decl.c:4666 0x558990 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) ../../gcc-4.9/gcc/cp/decl.c:4629 0x618430 cp_parser_init_declarator ../../gcc-4.9/gcc/cp/parser.c:16138 4.6, 4.7 and 4.8 reject it, which is better than an ICE but possibly still wrong.
[Bug c++/51747] [C++11] cannot call defaulted copy constructor using list-initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-25 11:30:48 UTC --- This is http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3539.html#1467
[Bug tree-optimization/57066] [4.7/4.8/4.9 Regression] std::logb(-inf) returns wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57066 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-25 11:47:34 UTC --- I wonder if std::logb(-NaN) should also return +NaN.
[Bug other/57069] New: cmake compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57069
Bug #: 57069
Summary: cmake compilation error
Classification: Unclassified
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: aleksan...@hotelavalon.eu
[ 69%] Building CXX object Source/CMakeFiles/CMakeLib.dir/cmMakefile.cxx.o
{standard input}: Assembler messages:
{standard input}:43707: Error: undefined symbol `.LLSDATT4168' in operation
{standard input}:43710: Error: undefined symbol `.LLSDACSE4168' in operation
c++: Internal error: Killed: 9 (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
*** [Source/CMakeFiles/CMakeLib.dir/cmGlobalGenerator.cxx.o] Error code 1
1 error
*** [Source/CMakeFiles/CMakeLib.dir/all] Error code 2
1 error
*** [all] Error code 2
1 error
*** [do-build] Error code 1
Stop in /usr/ports/devel/cmake.
Result of: # gcc -v
Using built-in specs.
Target: amd64-undermydesk-freebsd
Configured with: FreeBSD/amd64 system compiler
Thread model: posix
gcc version 4.2.1 20070831 patched [FreeBSD]
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #22 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-25 12:42:45 UTC --- Created attachment 29938 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29938 FE patch for namelist read with type extension (+ test case) Regarding the support of type extension: This patch uses in the front end a + instead of a % to denote a type extension, i.e. type%parent%var becomes type+parent%var in the call to st_set_nml_var. Then, libgfortran has the required information - the actual implementation is still pending.
[Bug other/57069] cmake compilation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57069 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2013-04-25 12:47:24 UTC --- Someone forcefully killed cc1plus, and the assembler error is just due to the incomplete input. Does FreeBSD have an OOM killer like Linux?
[Bug tree-optimization/57066] [4.7/4.8/4.9 Regression] std::logb(-inf) returns wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57066 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-25 13:43:39 UTC --- (In reply to comment #4) I wonder if std::logb(-NaN) should also return +NaN. It turned out that in NaN's case it doesn't matter.
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2013-04-25 13:50:47 UTC --- (In reply to comment #6) Updated patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01517.html This one works. Thanks.
[Bug c++/57063] Valid static_cast from data member to rvalue reference fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063
--- Comment #4 from Nikolka tsoae at mail dot ru 2013-04-25 13:51:21 UTC ---
It looks like the root of the issue is that static_cast produces an expression
with wrong value category sometimes.
#include iostream
#include type_traits
#define PRINT_VALUE(...) \
std::cout #__VA_ARGS__ = __VA_ARGS__ std::endl
template class T
struct X
{
void f()
{
PRINT_VALUE(std::is_lvalue_reference
decltype(static_castT (value)){});
PRINT_VALUE(std::is_rvalue_reference
decltype(static_castT (value)){});
std::cout std::endl;
}
T value;
};
struct A {};
int main()
{
Xint{0}.f();
XA{A()}.f();
}
When T = int, static_castT (value) is wrongfully treated as an lvalue. In
the first example the compiler thinks that we want to return lvalue of type int
by rvalue reference int , which would be invalid.
[Bug preprocessor/56686] gcc cannot find include header file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56686 --- Comment #7 from lostdj at gmail dot com 2013-04-25 14:09:41 UTC --- Created attachment 29939 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29939 testcase It's funny that I just wanted to report almost identical issue. Can't believe no one had encountered this before. MinGW, GCC 4.7.0. Attached test case is a bit different from author's original, yet similar: inc1.h: No such file or directory If you change one include path in makefile from -I./ to -I., everything compiles without errors. From gcc -v with -I./: #include ... search starts here: #include ... search starts here: ./inc d:\bin\mingw\bin\../lib/gcc/mingw32/4.7.0/include d:\bin\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include d:\bin\mingw\bin\../lib/gcc/mingw32/4.7.0/include-fixed And -I.: #include ... search starts here: #include ... search starts here: ./inc . d:\bin\mingw\bin\../lib/gcc/mingw32/4.7.0/include d:\bin\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include d:\bin\mingw\bin\../lib/gcc/mingw32/4.7.0/include-fixed *** Aaand on Linux with GCC 4.4.6 everything is fine. No errors. -v -I./: #include ... search starts here: #include ... search starts here: ./inc/ ./ /usr/local/include /usr/lib/gcc/i686-redhat-linux/4.4.6/include /usr/include -v -I.: #include ... search starts here: #include ... search starts here: ./inc/ . /usr/local/include /usr/lib/gcc/i686-redhat-linux/4.4.6/include /usr/include *** So whom is to blame: GCC or MinGW?
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-04-25 AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.1 Ever Confirmed|0 |1 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org 2013-04-25 14:42:43 UTC --- Yep, this is a bug in 4.8.1 that was fixed in 4.9 by my follow-on change * call.c (add_function_candidate): Take the address of 'this' here. (build_over_call): And here. (build_new_method_call_1, build_op_call_1): Not here. (build_user_type_conversion_1): Or here. (add_candidates): Adjust. that I thought was too risky for the branch. I'll fix this differently on the branch.
[Bug rtl-optimization/57067] Missing control flow edges for setjmp/longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067 --- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-04-25 14:46:09 UTC --- (In reply to comment #1) I suppose more selectively removing edges would be best. Eventually this is done to cater for expansions of builtin calls to non-calls? Then maybe those edges should be removed later, _after_ builtin expansion and find_many_sub_basic_blocks? Wouldn't it be better to keep all the edges and fix the fallout from the RTL passes? Do you remember any example where this currently fails? I've verified with GCC 4.4 that dropping the edge removal code from cfgexpand.c together with a backport of the PR56982 patch fixes the actual problem.
[Bug rtl-optimization/57067] Missing control flow edges for setjmp/longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067 --- Comment #3 from rguenther at suse dot de rguenther at suse dot de 2013-04-25 15:11:00 UTC --- On Thu, 25 Apr 2013, krebbel at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067 --- Comment #2 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-04-25 14:46:09 UTC --- (In reply to comment #1) I suppose more selectively removing edges would be best. Eventually this is done to cater for expansions of builtin calls to non-calls? Then maybe those edges should be removed later, _after_ builtin expansion and find_many_sub_basic_blocks? Wouldn't it be better to keep all the edges and fix the fallout from the RTL passes? Yes, we should be able to prune them when expansion sees that is necessary. Do you remember any example where this currently fails? Not sure. Run bootstrap testing?
[Bug target/57054] Compilation with -O3 passes, with -O2 fails (ARM/NEON)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57054 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Target||arm Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-25 Ever Confirmed|0 |1 --- Comment #4 from Richard Earnshaw rearnsha at gcc dot gnu.org 2013-04-25 15:40:00 UTC --- Andrew is right. Nevertheless, we shouldn't ICE after such an error.
[Bug target/57002] ARM back end has extra entries in attribute interrupt array.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57002 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Target|ARM |arm Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-25 Host|Any | Ever Confirmed|0 |1 Build|Any | --- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org 2013-04-25 15:47:22 UTC --- Been like that since December 2000. http://gcc.gnu.org/ml/gcc-patches/2000-12/msg00460.html
[Bug tree-optimization/57066] [4.7/4.8/4.9 Regression] std::logb(-inf) returns wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57066 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-25 15:52:16 UTC --- Author: mpolacek Date: Thu Apr 25 15:51:57 2013 New Revision: 198308 URL: http://gcc.gnu.org/viewcvs?rev=198308root=gccview=rev Log: PR tree-optimization/57066 * builtins.c (fold_builtin_logb): Return +Inf for -Inf. * gcc.dg/torture/builtin-logb-1.c: Adjust testcase. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/builtin-logb-1.c
[Bug tree-optimization/57066] [4.7/4.8/4.9 Regression] std::logb(-inf) returns wrong value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57066 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-25 15:52:45 UTC --- Fixed on trunk so far, will backport to 4.7/4.8 later on.
[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #11 from Martin Jambor jamborm at gcc dot gnu.org 2013-04-25 17:27:00 UTC --- (In reply to comment #8) Martin, for 4.9 we can probably turn call to NULL into builtin_trap or builtin_unreachable (not sure if the second is fine, but it would result in better code). I wonder however from where the non-NULL constants are comming? Isn't it some bug in ipa-prop that picks complete garbage? That may be possible wrong code issue... I will commit patch tomorrow morning. Honza I have looked at all 11 occurrences of these discovered calls to non-functions and traced these values in the dumped jump functions and it all seemed legitimate and fine. Moreover, I have looked at actual IL of functions where the value was passed in aggregate jump functions and it turned out the aggregate was a C++ member pointers where one field is overloaded and can hold either a pointer to a non-virtual method or an index to VMT if the method is virtual. So yes, I'm in favor of turning the calls into builtin_trap or builtin_unreachable. Not sure which one. How do I get their call graph nodes?
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Jason Merrill jason at gcc dot gnu.org 2013-04-25 17:50:25 UTC --- Fixed.
[Bug c++/56859] alignas() fails in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56859 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.1 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-04-25 17:50:52 UTC --- Fixed.
[Bug c++/50261] [C++0x] ICE on brace-initialize an array member
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50261 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution||FIXED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.1 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-04-25 17:51:35 UTC --- Fixed for 4.8.1.
[Bug fortran/57071] New: Optimize (-1)**k to 1 - 2 * mod(K, 2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57071 Bug #: 57071 Summary: Optimize (-1)**k to 1 - 2 * mod(K, 2) Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: tkoe...@gcc.gnu.org Motivated by https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/60jYF5XEY3c The code (k is an integer): (-1)**k and (-1.0)**k can be rather common in numeric code. The former is converted into _gfortran_pow_i4_i4 (-1, *k); the latter is __builtin_powif (-1.0e+0, *k); However, for (-1)**k, the result is simply 1 is k is even and -1 if it is odd, or in other words: 1 - 2 * mod(K, 2) integer function f(k) f = (-1)**k ! Or: (-1.0)**k end
[Bug c++/57072] New: bogus is used uninitialized warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57072
Bug #: 57072
Summary: bogus is used uninitialized warning
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google ref: b/8700048
Test:
struct A {
~A() __attribute__((noreturn));
A stream();
template typename T void operator(T);
};
struct C {
enum State { S1, S2 };
static bool Fn(State s) {
switch (s) {
case S2: A().stream() s;
}
}
};
void TestFn()
{
for (int i = 0; i 2; ++i) {
C::Fn ? (void) 0 : A().stream() ;
C::Fn(static_castC::State(i));
}
}
Using g++ (GCC) 4.9.0 20130412 (experimental) (r197936):
g++ -c -Wuninitialized -O2 -fno-tree-vrp t.cc
t.cc: In function ‘void TestFn()’:
t.cc:16:6: warning: ‘s’ is used uninitialized in this function
[-Wuninitialized]
void TestFn()
^
This warning doesn't trigger on 4_7-branch, but a slightly less reduced test
case does, so it's likely not a recent regression.
[Bug middle-end/57073] New: __builtin_powif (-1.0, k) should be optimized to 1.0 - 2.0 * (K%2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57073 Bug #: 57073 Summary: __builtin_powif (-1.0, k) should be optimized to 1.0 - 2.0 * (K%2) Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org Motivated by PR57071. In numerical code, it is not unlike to find code of the form (-1.0) raised to the power of k, in Fortran: (-1.0)**k. That translates into: __builtin_powif (-1.0e+0, k) which stays that way even with -O3. Expected: It gets optimized to 1.0 - 2.0 * (K%2) Fortran test case: real function f(k) integer, value :: k f = (-1.0)**k end
[Bug fortran/57071] Optimize (-1)**k to 1 - 2 * mod(K, 2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57071 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-25 18:06:08 UTC --- See also PR 57073 for the related middle-end bug report.
[Bug target/45359] poor -march=native choices for VIA C7 Esther processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359 linuxball at netscape dot net changed: What|Removed |Added CC||linuxball at netscape dot ||net --- Comment #6 from linuxball at netscape dot net 2013-04-25 19:07:45 UTC --- I reconfirm this bug using gcc 4.6.3-1ubuntu5 in Ubuntu 12.04 to compile stuff optimized for VIA C7-D Esther processor. Still the same issue: Using -march=native 1) still chooses -march=pentium-m -mtune=generic (ignoring the sse3 capability) 2) will not detect the L1 and L2 cache parameters IMHO, the centaur2.patch suggested by Dzianis Kahanovich is a good fix. Why hasn't it found its way into the official gcc? Best regards and thanks to Dzianis for his contribution linuxball
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 --- Comment #8 from Janne Blomqvist jb at gcc dot gnu.org 2013-04-25 19:19:05 UTC --- Author: jb Date: Thu Apr 25 19:16:46 2013 New Revision: 198318 URL: http://gcc.gnu.org/viewcvs?rev=198318root=gccview=rev Log: PR 57028 Bootstrap regression wrt zlib. 2013-04-25 Janne Blomqvist j...@gcc.gnu.org PR bootstrap/57028 * Make-lang.in (f951): Link in ZLIB. (CFLAGS-fortran/module.o): Add zlib include directory. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/Make-lang.in
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 --- Comment #9 from Janne Blomqvist jb at gcc dot gnu.org 2013-04-25 19:19:59 UTC --- (In reply to comment #7) (In reply to comment #6) Updated patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01517.html This one works. Thanks. Thanks for the confirmation. Committed as obvious.
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #10 from Janne Blomqvist jb at gcc dot gnu.org 2013-04-25 19:20:40 UTC --- Ugh, sorry for the email spam, closing for real this time..
[Bug libgcj/57074] New: gcc-4.8.0 libgcj regression on 32bit Power architecture
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074 Bug #: 57074 Summary: gcc-4.8.0 libgcj regression on 32bit Power architecture Classification: Unclassified Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: libgcj AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@us.ibm.com GCC Revision 186687 has been identified as causing a regression in PowerC 32-bit libgcj: http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=186687 I've verified that this fails with upstream GCC: ryanarn@bns:~ /home/bergner/gcc/install/gcc-fsf-4_8-java32/bin//gkeytool -import -alias `basename 99.pem .pem` -keystore cacerts -storepass '' -file 99.pem Exception in thread main java.lang.NoClassDefFoundError: gnu.classpath.tools.keytool.Main at java.lang.Class.initializeClass(libgcj.so.14) Caused by: java.lang.IllegalMonitorStateException: current thread not owner at java.lang.Object.notifyAll(libgcj.so.14) at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.14) at java.lang.ClassLoader.loadClass(libgcj.so.14) at java.lang.ClassLoader.loadClass(libgcj.so.14) at java.lang.Class.initializeClass(libgcj.so.14) If this wasn't failing it would be reporting: ryanarn@bns:~ ryanarn@bns:~ /home/bergner/gcc/install/gcc-fsf-4_8-java/bin/gkeytool -import -alias `basename 99.pem .pem` -keystore cacerts -storepass '' -file 99.pem keytool error: java.security.InvalidParameterException: File object [99.pem] MUST be an existing readable file /home/bergner/gcc/install/gcc-fsf-4_8-java/bin/gkeytool -import -alias `basename 99.pem .pem` -keystore cacerts -storepass '' -file 99.pem keytool error: java.security.InvalidParameterException: File object [99.pem] MUST be an existing readable file I'm able to trap on the catch, but trying to capture the throw or identify the state of the GCJ locking mechanisms when the problem happens has proven problematic. Turning on logging and lock debugging might help, but there's a lot going on in the state initialization. Here's a back trace: Breakpoint 8, _Jv_Linker::wait_for_state (klass=klass@entry=0x10020018 gnu::classpath::tools::keytool::Main::class$, state=state@entry=9) at ../../../libjava/link.cc:2086 2086throw exc; $8 = In the wait_for_state catch. klass: 0x10020018 (gdb) bt #0 _Jv_Linker::wait_for_state (klass=klass@entry=0x10020018 gnu::classpath::tools::keytool::Main::class$, state=state@entry=9) at ../../../libjava/link.cc:2086 #1 0x0e2c2aec in java::lang::Class::initializeClass (this=0x10020018 gnu::classpath::tools::keytool::Main::class$) at ../../../libjava/java/lang/natClass.cc:728 #2 0x0e2c39b4 in _Jv_InitClass (klass=optimized out) at ../../../libjava/java/lang/Class.h:742 #3 0x0fe3eabc in gnu.classpath.tools.keytool.Main.main(java.lang.String[])void (args=@f7d4ad50) at ../../../../../libjava/classpath/tools/gnu/classpath/tools/keytool/Main.java:137 #4 0x0e2b63c0 in gnu::java::lang::MainThread::call_main (this=this@entry=0xf7ce7f60) at ../../../libjava/gnu/java/lang/natMainThread.cc:54 #5 0x0e33f3dc in gnu.java.lang.MainThread.run()void (this=@f7ce7f60) at /usr/src/debug/gcc-4.8.0-20130412/libjava/gnu/java/lang/MainThread.java:106 #6 0x0e2cce88 in _Jv_ThreadRun (thread=0xf7ce7f60) at ../../../libjava/java/lang/natThread.cc:335 #7 0x0e26e6fc in _Jv_RunMain (vm_args=vm_args@entry=0x0, klass=optimized out, name=name@entry=0x0, argc=optimized out, argv=optimized out, is_jar=optimized out) at ../../../libjava/prims.cc:1790 #8 0x0e26e944 in _Jv_RunMain (klass=optimized out, name=name@entry=0x0, argc=optimized out, argv=optimized out, is_jar=is_jar@entry=false) at ../../../libjava/prims.cc:1815 #9 0x0e26e9a0 in JvRunMain (klass=optimized out, argc=optimized out, argv=optimized out) at ../../../libjava/prims.cc:1821 #10 0x0d1c17f4 in generic_start_main (main=0x14c0 main, argc=10, ubp_av=0xfffef6f4, auxvec=0xfffef774, init=optimized out, rtld_fini=optimized out, stack_end=optimized out, fini=optimized out) at ../csu/libc-start.c:258 #11 0x0d1c1990 in __libc_start_main (argc=optimized out, ubp_av=optimized out, ubp_ev=optimized out, auxvec=optimized out, rtld_fini=optimized out, stinfo=optimized out, stack_on_entry=optimized out) at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:91 #12 0x in ?? ()
[Bug c/57075] New: verify_flow_info failed: control flow in the middle of basic block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57075 Bug #: 57075 Summary: verify_flow_info failed: control flow in the middle of basic block Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 29942 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29942 C source code I just tried to compile the package jam-2.5-14 on gcc-4.9 trunk dated 20130425 on an AMD x86_64 box. The compiler said execunix.c: In function 'execcmd': execunix.c:322:1: error: control flow in the middle of basic block 10 } ^ execunix.c:322:1: error: control flow in the middle of basic block 10 execunix.c:322:1: error: control flow in the middle of basic block 10 execunix.c:322:1: internal compiler error: verify_flow_info failed 0x5f9ae1 verify_flow_info() ../../src/trunk/gcc/cfghooks.c:260 0x91dec4 cleanup_tree_cfg_noloop ../../src/trunk/gcc/tree-cfgcleanup.c:693 0x91dec4 cleanup_tree_cfg() ../../src/trunk/gcc/tree-cfgcleanup.c:742 0x84be64 execute_function_todo ../../src/trunk/gcc/passes.c:1921 0x84c7e7 execute_todo ../../src/trunk/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. Preprocessed source code attached. Flag -O2 required.
[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265 --- Comment #12 from Jan Hubicka hubicka at ucw dot cz 2013-04-25 20:52:39 UTC --- So yes, I'm in favor of turning the calls into builtin_trap or builtin_unreachable. Not sure which one. How do I get their call graph nodes? cgraph_get_create_node (builtin_decl_implicit (BUILT_IN_UNREACHABLE), 0); Honza
[Bug bootstrap/57076] New: @ in the src directory name causes failure while building of gcc.info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57076 Bug #: 57076 Summary: @ in the src directory name causes failure while building of gcc.info Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: pins...@gcc.gnu.org While doing a build where the src directory name contains a @, the build fails: makeinfo --split-size=500 --no-split -I . -I /var/lib/jenkins/workspace/BuildToolchainMIPS@2/toolchain/scripts/../src/gcc/doc \ -I /var/lib/jenkins/workspace/BuildToolchainMIPS@2/toolchain/scripts/../src/gcc/doc/include -o doc/gcc.info /var/lib/jenkins/workspace/BuildToolchainMIPS@2/toolchain/scripts/../src/gcc/doc/gcc.texi; \ fi /var/lib/jenkins/workspace/BuildToolchainMIPS@2/toolchain/scripts/../src/gcc/doc//invoke.texi:1445: Unknown command `2/toolchain/scripts/../src/gcc'. /var/lib/jenkins/workspace/BuildToolchainMIPS@2/toolchain/scripts/../src/gcc/doc//invoke.texi:1444: @include `/var/lib/jenkins/workspace/BuildToolchainMIPS/../libiberty/at-file.texi': No such file or directory. I don't think there is anything that can be done on the GCC side though.
[Bug bootstrap/57077] New: [4.9 Regression] LTO bootstrap failure with profiledbootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57077 Bug #: 57077 Summary: [4.9 Regression] LTO bootstrap failure with profiledbootstrap Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: tejohn...@google.com Revision 197595: http://gcc.gnu.org/ml/gcc-cvs/2013-04/msg00303.html caused LTO bootstrap failure with profiledbootstrap on Linux/x86-64: lto1: internal compiler error: in check_probability, at basic-block.h:941 0x9adcde check_probability /export/project/git/gcc-regression/gcc/gcc/basic-block.h:941 0x9adcde apply_probability /export/project/git/gcc-regression/gcc/gcc/basic-block.h:960 0x9adcde merge_profile_summaries /export/project/git/gcc-regression/gcc/gcc/lto-cgraph.c:1423 0x9adcde input_symtab() /export/project/git/gcc-regression/gcc/gcc/lto-cgraph.c:1469 0x53c3f1 read_cgraph_and_symbols /export/project/git/gcc-regression/gcc/gcc/lto/lto.c:3010 0x53c3f1 lto_main() /export/project/git/gcc-regression/gcc/gcc/lto/lto.c:3375 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. lto-wrapper: /export/project/git/gcc-regression-bootstrap/master/197595/bld/./prev-gcc/xg++ returned 1 exit status /usr/local/x86_64-unknown-linux-gnu/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status make[3]: *** [build/genhooks] Error 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 --- Comment #6 from Greg gccbugzi...@tru-traffic.com 2013-04-25 22:32:13 UTC --- Can you please provide a backtrace from the crash? I'll be happy to provide a backtrace from the crash. It will take a day or so, as I'm such a novice that I don't yet know how to create a backtrace. In the meantime, here's a new development: The build that crashed was launched using make BOOT_CFLAGS='-O' bootstrap Thinking that I'd need to remove the BOOT_CFLAGS='-O' in order to create a backtrace, I rebuilt using simply make bootstrap Only this time, the bootstrap built to successful completion -- no crash. This used revision 198253 with no changes (that is, I'd first reverted from my working-directory the revision 197165 merged from trunk). Any tips for a novice on how to create a backtrace from the crashed build?
[Bug c++/57078] New: Unhelpful -Wunused-variable warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57078
Bug #: 57078
Summary: Unhelpful -Wunused-variable warning
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Test:
namespace Foo {
extern const char Name[]; // line 2
}
int main()
{
using Foo::Name; // trigger, line 7
return 0;
}
Using g++ (GCC) 4.9.0 20130412 (experimental):
g++ -c t.cc -Wall
t.cc: In function ‘int main()’:
t.cc:2:21: warning: unused variable ‘Foo::Name’ [-Wunused-variable]
extern const char Name[];
^
This is quite poor: line 2 that is reported is in some header file, and there
is *nothing* wrong there.
Line 7 may be in a different header file, or in a .cc file, and it is line 7
that triggers the warning; but it is not mentioned in the warning itself.
[Bug target/57056] Missed optimization of finite finite builtin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57056 Steven Fuerst svfuerst at gmail dot com changed: What|Removed |Added CC||svfuerst at gmail dot com --- Comment #2 from Steven Fuerst svfuerst at gmail dot com 2013-04-26 01:23:24 UTC --- If you use the pextrw instruction, then you can avoid the shift, saving an instruction. i.e. Something like: pextrw $0x3, %xmm0, %rax and $0x7ff0, %ax sub $0x7ff0, %ax sbb %eax, %eax retq
[Bug c++/57064] [clarification requested] Which overload with ref-qualifier should be called?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57064 --- Comment #13 from Marc Glisse glisse at gcc dot gnu.org 2013-04-26 05:05:48 UTC --- Note for Thiago: please be aware of the risks of returning an rvalue reference, as opposed to just a value. The following codes will fail at runtime: Qstring const a=QString(%1 %2 %3 %4).arg(42).arg(47).arg(-42).arg(-47); Qstring b=QString(%1 %2 %3 %4).arg(42).arg(47).arg(-42).arg(-47); for(char c : QString(%1 %2 %3 %4).arg(42).arg(47).arg(-42).arg(-47))...
