[Bug rtl-optimization/57131] [4.8/4.9 Regression] Wrong register assignment?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57131
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek 2013-05-01
07:39:41 UTC ---
Apparently went away with the http://gcc.gnu.org/r198432 fix, but it isn't
clear whether that change was meant to fix this or just made the bug latent.
Anyway, still reproduceable on the 4.8 branch.
What I'm seeing before that change is that extendsidi2_1 pattern with MEM
destination LRA chooses %ebx as (clobber (scratch:SI)) register, eventhough
%ebx
is live across that instruction (there is
(insn 14 74 68 2 (set (reg:SI 3 bx [orig:83 D.1395 ] [83])
(mem/v/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 72 [0x48])) [0 x4+0 S4 A64])) pr57131.c:11 85
{*movsi_internal}
(nil))
(insn 68 14 73 2 (set (reg:SI 3 bx [orig:83 D.1395 ] [83])
(reg:SI 3 bx [orig:83 D.1395 ] [83])) pr57131.c:11 85 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 3 bx [orig:83 D.1395 ] [83])
(nil)))
some insns before it and:
(insn 65 24 26 2 (set (reg:SI 5 di [orig:83 D.1395 ] [83])
(reg:SI 3 bx [orig:83 D.1395 ] [83])) pr57131.c:11 85 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 3 bx [orig:83 D.1395 ] [83])
(nil)))
some insns after it. Not sure if the noop move with REG_DEAD has anything to
do with that. Vlad, can you please have a look?
[Bug target/57097] [4.8 Regression] ICE: in find_hard_regno_for, at lra-assigns.c:561 with -O2 -fPIC -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57097 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Known to work||4.9.0 Summary|[4.8/4.9 Regression] ICE: |[4.8 Regression] ICE: in |in find_hard_regno_for, at |find_hard_regno_for, at |lra-assigns.c:561 with -O2 |lra-assigns.c:561 with -O2 |-fPIC -m32 |-fPIC -m32 Known to fail|4.9.0 | --- Comment #2 from Jakub Jelinek 2013-05-01 07:48:34 UTC --- Author: vmakarov Date: Mon Apr 29 19:42:20 2013 New Revision: 198432 URL: http://gcc.gnu.org/viewcvs?rev=198432&root=gcc&view=rev Log: 2013-04-29 Vladimir Makarov PR target/57097 * lra-constraints.c (process_alt_operands): Discourage a bit more using memory for pseudos. Print cost dump for alternatives. Modify cost values for conflicts with early clobbers. (curr_insn_transform): Spill pseudos reassigned to NO_REGS. 2013-04-29 Vladimir Makarov PR target/57097 * gcc.target/i386/pr57097.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr57097.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug c++/57132] New: spurious warning: division by zero [-Wdiv-by-zero] in if (m) res %=m;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57132
Bug #: 57132
Summary: spurious warning: division by zero [-Wdiv-by-zero] in
if (m) res %=m;
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
the following code is "copied" from line 131 of
libstdc++v3//include/bits/random.h
cat divzero.cc
using UI = unsigned int;
template
struct mod{
static UI calc(UI x) {
UI res = a*x;
if (m) res %=m;
return res;
}
};
#include
int main() {
std::cout << mod<3,2>::calc(7) << std::endl;
std::cout << mod<0,2>::calc(7) << std::endl;
};
pb-d-128-141-131-94:bugs48 innocent$ c++ -std=c++11 divzero.cc -Wall
divzero.cc: In instantiation of ‘static UI mod::calc(UI) [with unsigned
int m = 0u; unsigned int a = 2u; UI = unsigned int]’:
divzero.cc:16:27: required from here
divzero.cc:6:16: warning: division by zero [-Wdiv-by-zero]
if (m) res %=m;
^
pb-d-128-141-131-94:bugs48 innocent$ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin12.3.0/4.9.0/lto-wrapper
Target: x86_64-apple-darwin12.3.0
Configured with: ./configure --disable-multilib --disable-bootstrap
--enable-lto -disable-libitm --enable-languages=c,c++,fortran,lto --no-create
--no-recursion
Thread model: posix
gcc version 4.9.0 20130428 (experimental) [trunk revision 198366] (GCC)
[Bug c++/57092] [4.8/4.9 Regression] Using decltype of function pointer type to define a data member causes compiler crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57092 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.1 --- Comment #3 from Paolo Carlini 2013-05-01 09:24:35 UTC --- Fixed mainline and 4.8.1.
[Bug c++/57132] spurious warning: division by zero [-Wdiv-by-zero] in if (m) res %=m;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57132 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-05-01 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 2013-05-01 09:53:58 UTC --- Can be fixed like PR11586, a straightforward patchlet.
[Bug c++/53220] [4.7/4.8 Regression] g++ mis-compiles compound literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220
superaxioma at hotmail dot com changed:
What|Removed |Added
CC||superaxioma at hotmail dot
||com
--- Comment #20 from superaxioma at hotmail dot com 2013-05-01 09:54:43 UTC ---
(In reply to comment #18)
> #include
>
> void fn(int arr[])
> {
> for (int j = 0; j < 5; ++j)
> printf("%d: %d\n", j, arr[j]);
> }
>
> int main()
> {
> fn((int[]) { 41, 42, 43, 44, 45 } );
> return 0;
> }
>
> g++ -c t.cc
> t.cc: In function ‘int main()’:
> t.cc:11:37: error: taking address of temporary array
>fn((int[]) { 41, 42, 43, 44, 45 } );
I wrote some code which compiled perfectly using gcc 4.7. However, now I am
using gcc 4.8 and I am encountering exactly the problem mentioned by Paul. Will
this be solved or should I look for another solution to overcome this problem?
Any suggestions?
[Bug c++/57132] spurious warning: division by zero [-Wdiv-by-zero] in if (m) res %=m;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57132 --- Comment #2 from Paolo Carlini 2013-05-01 09:55:23 UTC --- I meant PR11856, of course ;)
[Bug target/55372] MIPS: Loading integer constants to floating-pointer registers generates suboptimal code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55372
--- Comment #1 from stevenbaker94 at rocketmail dot com 2013-05-01 10:16:56 UTC
---
This version handles negative numbers as well:
static inline float _fpos(const float f)
{
union {
float f;
uint32_t i;
} x;
x.f = f;
uint32_t r;
float f_out;
asm ("lui %0, %1"
: "=d" (r)
: "K" (x.i >> 16));
asm ("mtc1 %1, %0"
: "=f" (f_out)
: "d" (r));
return f_out;
}
static inline float _fneg(const float f)
{
union {
float f;
uint32_t i;
} x;
x.f = f;
uint32_t r;
float f_out;
asm ("lui %0, %1"
: "=d" (r)
: "K" (0x8000 ^ (x.i >> 16)));
asm ("mtc1 %1, %0"
: "=f" (f_out)
: "d" (r));
return f_out;
}
static inline float f(const float f)
{
return f >= 0 ? _fpos(f) : _fneg(-f);
}
Actually, it doesn't always discard fractional bits. It works for e.g. f(0.25)
as well, since the floating-point representation still only has 0s in the lower
16 bits.
[Bug c/57133] New: false const qualifier warning typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57133
Bug #: 57133
Summary: false const qualifier warning typedef
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: grpin...@gmail.com
typedef char *type;
void f(const type t)
{
}
int main(void)
{
const char *str = "string";
f(str);
return 0;
}
warning: passing argument 1 of 'f' discards 'const' qualifier from pointer
target type [enabled by default]
f(str);
^
note: expected 'type' but argument is of type 'const char *'
void f(const type t)
^
It is similar with gcc 4.5.3.
[Bug c/57133] false const qualifier warning typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57133
--- Comment #1 from Mikael Pettersson 2013-05-01
11:37:56 UTC ---
(In reply to comment #0)
> typedef char *type;
>
> void f(const type t)
> {
This doesn't do what you think it does. t is now a const variable of type
char*, not a variable of type const char*. Observe:
> cat pr57133.c
typedef char *type;
void f(const type t) { t = 0; }
void g(const type t) { *t = 0; }
> gcc -Wall -S pr57133.c
pr57133.c: In function 'f':
pr57133.c:2:1: error: assignment of read-only parameter 't'
The warning in your main() is correct.
[Bug c++/52282] [C++0x] ICE / confused by earlier errors with decltype/constexpr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52282 --- Comment #7 from Paolo Carlini 2013-05-01 11:48:38 UTC --- With the fix for c++/57092 the ICEs are gone.
[Bug c/57133] false const qualifier warning typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57133 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Jonathan Wakely 2013-05-01 12:04:36 UTC --- .
[Bug middle-end/57134] New: ICE with -mstrict-align and inline assembly on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134
Bug #: 57134
Summary: ICE with -mstrict-align and inline assembly on ppc64
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: an...@samba.org
Created attachment 29987
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29987
Testcase that ICE's with -mstrict-align on ppc64
The following testcase passes on a ppc64 4.7.2 build but fails on a 4.9.0
20130501 build:
# gcc -m64 -O2 -S -mstrict-align testcase.c
testcase.c: In function 'rb_remove_pages':
testcase.c:16:2: internal compiler error: in expand_asm_operands, at stmt.c:910
__asm__ __volatile__("# %0,%1" : "=r"(t) : "m"(v->counter));
^
0x10604437 expand_asm_operands
../../gcc/gcc/stmt.c:910
0x10604b3b expand_asm_stmt(gimple_statement_d*)
../../gcc/gcc/stmt.c:1151
0x1022f357 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:2154
0x1022f357 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:2309
0x10230b77 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:4143
0x10233f7b gimple_expand_cfg
../../gcc/gcc/cfgexpand.c:4662
Please submit a full bug report,
[Bug c/57133] false const qualifier warning typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57133
--- Comment #3 from grpintar at gmail dot com 2013-05-01 12:43:28 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > typedef char *type;
> >
> > void f(const type t)
> > {
>
> This doesn't do what you think it does. t is now a const variable of type
> char*, not a variable of type const char*. Observe:
>
> > cat pr57133.c
> typedef char *type;
> void f(const type t) { t = 0; }
> void g(const type t) { *t = 0; }
> > gcc -Wall -S pr57133.c
> pr57133.c: In function 'f':
> pr57133.c:2:1: error: assignment of read-only parameter 't'
>
> The warning in your main() is correct.
I see. Sorry.
[Bug bootstrap/57135] New: Missing buld intructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57135 Bug #: 57135 Summary: Missing buld intructions Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: nicklas.karls...@karlssonwang.se It took me quite a lot of time to figure out how to build a cross compiler. Some simple instructions like these http://www.ifp.illinois.edu/~nakazato/tips/xgcc.html would be great. In particular I missed the important rows "make all-gcc", "make install-gcc" and instead simply typed "make" as usual which seems to work but it does not. I guess others also spent a lot time to figure what is wrong or missing then actually they did not build everything in correct order. There should be some kind of note or warning somewhere. For example then running "make" it could print a message that a C library is assumed to available otherwise build it with a naked compiler before this step.
[Bug middle-end/57134] ICE with -mstrict-align and inline assembly on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-01 CC||amodra at gmail dot com Ever Confirmed|0 |1 --- Comment #1 from Alan Modra 2013-05-01 14:32:49 UTC --- I think the bug here is that we lose EXPAND_MEMORY when recursively calling expand_expr() for the inner part of a COMPONENT_REF.
[Bug c++/57136] New: Should redeclaration of class template with function pointer rather than function be an error?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57136 Bug #: 57136 Summary: Should redeclaration of class template with function pointer rather than function be an error? Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: kjw.c...@gmail.com 'g++ -std=c++11 -Wall' compiles this without complaint: template class A; template class A; template class B; template class B; clang++ issues an error for the redeclaration of class B, but not for the redeclaration of class A. I filed this as a bug at LLVM, where I was told that this is correct, and that the rule is, if I understood it correctly: If a template parameter depends on a previous template parameter, then it must be token-by-token equivalent in any redeclaration. I simply filing here for informative purposes. I have not attempted to confirm this in the C++11 specification.
[Bug c/57137] New: spurious "format string is not literal" when the format string is marked with __attribute__((format))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57137 Bug #: 57137 Summary: spurious "format string is not literal" when the format string is marked with __attribute__((format)) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: zbys...@in.waw.pl If the format string is marked as a printf format with an attribute format((printf(...)) on the wrapper function, then gcc should know that it's either a valid printf format, or will be warned about at the point where it is passed to the wrapper function, and shouldn't warn that the format string is not a literal. Attached example gives: unit.c: In function ‘unit_status_printf’: unit.c:6:9: warning: format not a string literal, argument types not checked [-Wformat-nonliteral] manager_status_printf(status, unit_status_msg_format, "xxx"); ^ It is possible to work around by placing #pragma GCC diagnostic ignored "-Wformat-nonliteral" before the function, but that feels like a kludge.
[Bug c/57137] spurious "format string is not literal" when the format string is marked with __attribute__((format))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57137 --- Comment #1 from Zbigniew Jędrzejewski-Szmek 2013-05-01 16:20:52 UTC --- Created attachment 29988 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29988 preprocessed example
[Bug c/57137] spurious "format string is not literal" when the format string is marked with __attribute__((format))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57137 --- Comment #2 from Zbigniew Jędrzejewski-Szmek 2013-05-01 16:22:08 UTC --- Forgot to specify gcc version: gcc-4.8.0-2.fc19.x86_64
[Bug c/57137] spurious "format string is not literal" when the format string is marked with __attribute__((format))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57137 --- Comment #3 from Zbigniew Jędrzejewski-Szmek 2013-05-01 16:24:32 UTC --- Created attachment 29989 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29989 minimal example
[Bug fortran/57129] [4.7/4.8/4.9 Regression] ICE (segfault) in check_extended_derived_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57129 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-01 Summary|ICE (segfault) in |[4.7/4.8/4.9 Regression] |check_extended_derived_type |ICE (segfault) in ||check_extended_derived_type Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2013-05-01 16:54:17 UTC --- Revision 181424 gives the following errors pr57129.f90:2.8: type t 1 Error: PROCEDURE attribute of 't' conflicts with DERIVED attribute at (1) pr57129.f90:3.5: end type t 1 Error: Expecting END SUBROUTINE statement at (1) pr57129.f90:4.18: type, extends(t) :: t2 1 Error: 't' in EXTENDS expression at (1) is not a derived type pr57129.f90:5.5: end type t2 1 Error: Expecting END SUBROUTINE statement at (1) revision 181425 gives the ICE.
[Bug rtl-optimization/56732] ICE in advance_target_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56732
--- Comment #6 from gretay at gcc dot gnu.org 2013-05-01 17:32:14 UTC ---
Thanks for the small testcase! There is indeed a problem with rtl epilogue
generated for naked functions. Here is a fix, testing in progress.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 464d91c..9d4a453 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -24067,7 +24067,8 @@ arm_expand_epilogue (bool really_return)
if (IS_NAKED (func_type)
|| (IS_VOLATILE (func_type) && TARGET_ABORT_NORETURN))
{
- emit_jump_insn (simple_return_rtx);
+ if (really_return)
+emit_jump_insn (simple_return_rtx);
return;
}
[Bug target/49146] segv from libgcc_s when raising an exception, or unwinding stack with backtrace with ms_abi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49146 Ariel Burton changed: What|Removed |Added Version|4.4.6 |4.8.0 --- Comment #3 from Ariel Burton 2013-05-01 17:47:39 UTC --- I found another case where taking a backtrace causes a SEGV. This time the error occurs when the unwinder attempts to deal with a frame that saves some of the xmm registers. The code in question is in the openmp (shared) library distributed with the intel compiler. The component at fault here is libgcc_s.so. The patch of 2011-05-24 fixed the SEGV, and returned a correct backtrace.
[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #6 from Bill Schmidt 2013-05-01 17:49:00 UTC --- I can't confirm this today, either. The test passes with r198500. Andreas, do you still see a problem with the current trunk?
[Bug bootstrap/57135] Missing buld intructions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57135 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski 2013-05-01 17:57:56 UTC --- http://gcc.gnu.org/simtest-howto.html
[Bug c/57137] spurious "format string is not literal" when the format string is marked with __attribute__((format))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57137 --- Comment #4 from Andrew Pinski 2013-05-01 18:00:31 UTC --- What options are you using when calling gcc?
[Bug c++/57138] New: ICE in instantiate_class_template with variadic templates, using declarations, save-temps and precompiled header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57138 Bug #: 57138 Summary: ICE in instantiate_class_template with variadic templates, using declarations, save-temps and precompiled header Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jmetca...@acm.org Created attachment 29990 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29990 Failing test case - test.cpp Getting a segmentation fault in some variadic template code. The bug seems very sensitive to small changes in input (e.g. removing a std::cout line causes the compile to succeed, or give a compile error without ICE). Managed to reduce it to a small test case, but removing further code (even unused code) causes the issue to go away, as does removing the (empty) precompiled header, or the -save-temps in the command line below. Command lines: g++ -Winvalid-pch -std=gnu++11 -I.. test.hpp -o test.hpp.gch g++ -Winvalid-pch -std=gnu++11 -I.. -save-temps -c test.cpp GCC Version: Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-languages=c,c++ --disable-checking --disable-multilib --disable-multiarch --disable-nls --enable-lto --enable-libstdcxx-time Thread model: posix gcc version 4.8.0 (GCC) Also tested with 4.7.2, which produces the same error for this test case, though is also sensitive to input and sometimes succeeds where 4.8 fails, or vice versa. Output from 4.8.0: g++ -Winvalid-pch -std=gnu++11 -I.. -save-temps -c test.cpp test.cpp: In instantiation of 'struct specify_some': test.cpp:46:20: required from here test.cpp:29:55: internal compiler error: Segmentation fault using type = Type; ^ 0x86943f crash_signal ../../gcc/toplev.c:332 0x508fd8 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11227 0x50c992 tsubst_template_args ../../gcc/cp/pt.c:9607 0x5091b8 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11465 0x50952d tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11107 0x50eb00 lookup_template_class_1 ../../gcc/cp/pt.c:7363 0x50eb00 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../gcc/cp/pt.c:7562 0x5090af tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11337 0x50816e tsubst_decl ../../gcc/cp/pt.c:10625 0x509694 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11081 0x507f73 tsubst_decl ../../gcc/cp/pt.c:10037 0x509694 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/cp/pt.c:11081 0x516817 instantiate_class_template_1 ../../gcc/cp/pt.c:8818 0x516817 instantiate_class_template(tree_node*) ../../gcc/cp/pt.c:9054 0x56241d complete_type(tree_node*) ../../gcc/cp/typeck.c:131 0x5624bd complete_type_or_maybe_complain(tree_node*, tree_node*, int) ../../gcc/cp/typeck.c:143 0x4ec949 xref_basetypes(tree_node*, tree_node*) ../../gcc/cp/decl.c:12105 0x543ef1 cp_parser_class_head ../../gcc/cp/parser.c:18895 0x543ef1 cp_parser_class_specifier_1 ../../gcc/cp/parser.c:18194 0x543ef1 cp_parser_class_specifier ../../gcc/cp/parser.c:18463 And from 4.7: test.cpp: In instantiation of 'struct specify_some': test.cpp:46:20: required from here test.cpp:44:33: internal compiler error: Segmentation fault Please excuse the slightly horrific use of variadic templates...
[Bug c++/57138] ICE in instantiate_class_template with variadic templates, using declarations, save-temps and precompiled header
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57138 --- Comment #1 from Jacob Metcalfe 2013-05-01 18:08:28 UTC --- Note test.hpp is empty, as mentioned in the previous post. Can't upload it because of this.
[Bug fortran/57042] ICE/Segfault with -fdump-parse-tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57042
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #1 from Thomas Koenig 2013-05-01
18:49:09 UTC ---
The problem is that compiler_options does not have
a valid length:
Program received signal SIGSEGV, Segmentation fault.
0x00523154 in show_typespec (ts=0x1621500) at
../../trunk/gcc/fortran/dump-parse-tree.c:113
113 show_expr (ts->u.cl->length);
(gdb) up
#1 0x005265fd in show_symbol (sym=0x16214e0) at
../../trunk/gcc/fortran/dump-parse-tree.c:841
841 show_typespec (&sym->ts);
(gdb) p sym->name
$5 = 0x76c77630 "compiler_options"
(gdb) p sym->ts
$6 = {type = BT_CHARACTER, kind = 1, u = {derived = 0x0, cl = 0x0, pad = 0},
interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN,
deferred = false}
[Bug fortran/57042] ICE/Segfault with -fdump-parse-tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57042 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-01 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2013-05-01 18:54:30 UTC --- Confirmed.
[Bug libstdc++/57139] New: std::tuple conversion constructor does the wrong checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57139
Bug #: 57139
Summary: std::tuple conversion constructor does the wrong
checks
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vpozdya...@gmail.com
As per Std 20.4.2.1/14, the "template tuple(const
tuple& u)" constructor should require "is_constructible". However, the implementation checks "is_convertible", which implies copy constructibility requirement for destination
types. As a result:
#include
#include
class A { };
class B { public: B( A const &a ) { } private: B( B const & ); };
static_assert( std::is_constructible< B, A const & >::value, "test" ); // OK
static_assert( std::is_convertible< A, B >::value, "test" ); // fail
static_assert( std::is_constructible< std::tuple, std::tuple >::value,
"test" ); // fail
[Bug fortran/57042] [4.7/4.8/4.9 Regression] ICE/Segfault with -fdump-parse-tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57042 Dominique d'Humieres changed: What|Removed |Added Summary|ICE/Segfault with |[4.7/4.8/4.9 Regression] |-fdump-parse-tree |ICE/Segfault with ||-fdump-parse-tree --- Comment #3 from Dominique d'Humieres 2013-05-01 19:08:41 UTC --- The ICE appeared between revisions 164285 (2010-09-14, no ICE) and 164728 (2010-09-29, ICE).
[Bug c++/53220] [4.7/4.8 Regression] g++ mis-compiles compound literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220 --- Comment #21 from Jason Merrill 2013-05-01 19:13:19 UTC --- (In reply to comment #20) > I wrote some code which compiled perfectly using gcc 4.7. However, now I am > using gcc 4.8 and I am encountering exactly the problem mentioned by Paul. > Will > this be solved or should I look for another solution to overcome this problem? > Any suggestions? You should probably adjust your code to avoid using array compound literals in C++.
[Bug c++/57132] spurious warning: division by zero [-Wdiv-by-zero] in if (m) res %=m;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57132 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Paolo Carlini 2013-05-01 19:20:24 UTC --- Fixed for 4.9.0.
[Bug fortran/57042] [4.7/4.8/4.9 Regression] ICE/Segfault with -fdump-parse-tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57042
--- Comment #4 from Thomas Koenig 2013-05-01
19:45:13 UTC ---
Other functions returning characters have a bogus
typespec:
ig25@linux-fd1f:~/Krempel/Dump> cat b.f90
program main
print *,adjustl(" a")
end
ig25@linux-fd1f:~/Krempel/Dump> gfortran -fdump-fortran-original b.f90
Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
procedure name = main
symtree: 'adjustl' || symbol: 'adjustl'
type spec : (REAL 4)
attributes: (PROCEDURE FUNCTION IMPLICIT-TYPE)
result: adjustl
symtree: 'main'|| symbol: 'main'
type spec : (UNKNOWN 0)
attributes: (PROGRAM PUBLIC SUBROUTINE)
code:
WRITE UNIT=6 FMT=-1
TRANSFER 'a '
DT_END
[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864 --- Comment #7 from Andreas Schwab 2013-05-01 20:07:45 UTC --- Still failing.
[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect "vectorized 1 loops" 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864 --- Comment #8 from Bill Schmidt 2013-05-01 20:13:35 UTC --- If possible, please check whether this began failing with r196872. That commit looks suspicious for at least one other test. I'm stabbing in the dark since I can't reproduce this one.
[Bug libstdc++/57139] std::tuple conversion constructor does the wrong checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57139 --- Comment #1 from Jonathan Wakely 2013-05-01 21:52:19 UTC --- That's what the Requires: clause says, but see also: Remark: This constructor shall not participate in overload resolution unless const Ui& is implicitly convertible to Ti for all i. is_constructible does not enforce implicit convertibility, we need an additional check, which is why we use is_convertible. The SFINAE constraint is there to implement the Remark, not the Requires clause (which is the user's responsibility to meet not the implementation's.) Also note that it only requires move constructibility, not necessarily copy constructibility. I thought the code was wrong too and changed those constraints with http://gcc.gnu.org/ml/libstdc++/2011-05/msg00126.html and then reverted it with http://gcc.gnu.org/ml/libstdc++/2011-05/msg00129.html I think there will be a paper in the next WG21 mailing addressing this topic.
[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56865 Bill Schmidt changed: What|Removed |Added CC||rguenth at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org --- Comment #2 from Bill Schmidt 2013-05-01 21:58:09 UTC --- I've reproduced this as well. Additionally, gcc.dg/vect/vect-96.c fails similarly. Both tests began failing at r196872: 2013-03-21 Richard Biener * tree-vect-data-refs.c (vect_update_interleaving_chain): Remove. (vect_insert_into_interleaving_chain): Likewise. (vect_drs_dependent_in_basic_block): Inline ... (vect_slp_analyze_data_ref_dependence): ... here. New function, split out from ... (vect_analyze_data_ref_dependence): ... here. Simplify. (vect_check_interleaving): Simplify. (vect_analyze_data_ref_dependences): Likewise. Split out ... (vect_slp_analyze_data_ref_dependences): ... this new function. (dr_group_sort_cmp): New function. (vect_analyze_data_ref_accesses): Compute data-reference groups here instead of in vect_analyze_data_ref_dependence. Use a more efficient algorithm. * tree-vect-slp.c (vect_slp_analyze_bb_1): Use vect_slp_analyze_data_ref_dependences. Call vect_analyze_data_ref_accesses earlier. * tree-vect-loop.c (vect_analyze_loop_2): Likewise. * tree-vectorizer.h (vect_analyze_data_ref_dependences): Adjust. (vect_slp_analyze_data_ref_dependences): New prototype. Richi, I think this commit was not intended to have any functional effect -- is that correct?
[Bug tree-optimization/54742] Switch elimination in FSM loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 --- Comment #9 from Steve Ellcey 2013-05-02 00:11:52 UTC --- See http://gcc.gnu.org/ml/gcc/2013-05/msg9.html for a dynamically loadable pass to do this optimization. It is not a finished product but it seems to work for coremark.
[Bug gcov-profile/57121] undefined reference to gcov_merge_init and gcov_merge_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57121 --- Comment #3 from Netra 2013-05-02 01:31:56 UTC --- Created attachment 29991 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29991 Makefile Andew, Please find the makefile atttached. Thanks.
[Bug gcov-profile/57121] undefined reference to gcov_merge_init and gcov_merge_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57121 --- Comment #4 from Andrew Pinski 2013-05-02 01:33:50 UTC --- (In reply to comment #3) > Created attachment 29991 [details] This tells me nothing about the link command.
[Bug gcov-profile/57121] undefined reference to gcov_merge_init and gcov_merge_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57121 --- Comment #5 from Andrew Pinski 2013-05-02 01:35:16 UTC --- Simple work around is to use -fprofile-generate instead of -lgcov and GCC knows what it should be linking against then.
[Bug gcov-profile/57121] undefined reference to gcov_merge_init and gcov_merge_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57121 --- Comment #6 from Netra 2013-05-02 01:40:13 UTC --- If I understand ur previous comments, instead of -lgcov i need to use -fprofile-generate in the following lines : LDFLAGS = $(DEBUGOPT) $(GCOV_CFLAGS) -fprofile-generate -fPIC -m32 -s -O -shared else LDEXEFLAGS = $(DEBUGOPT) -m32 -O LDFLAGS = $(DEBUGOPT) $(GCOV_CFLAGS) -fprofile-generate -lgcov -fPIC -m32 -O -shared endif made the same changes and given for compilation.
[Bug gcov-profile/57121] undefined reference to gcov_merge_init and gcov_merge_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57121 --- Comment #7 from Netra 2013-05-02 01:54:04 UTC --- Created attachment 29992 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29992 Makefile Andrew, I am still getting those errors after modifying the makefile. Please find the modified makefile attached. Thanks.
[Bug c/57137] spurious "format string is not literal" when the format string is marked with __attribute__((format))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57137 --- Comment #5 from Zbigniew Jędrzejewski-Szmek 2013-05-02 02:02:18 UTC --- (In reply to comment #4) > What options are you using when calling gcc? Ah, I had it copied but forgot to paste... gcc -pipe -Wall -Wextra -Wno-inline -Wundef -Wformat=2 -Wformat-security -Wformat-nonliteral -Wlogical-op -Wsign-compare -Wmissing-include-dirs -Wold-style-definition -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wstrict-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing=2 -Wwrite-strings -Wno-long-long -Wno-overlength-strings -Wno-unused-parameter -Wno-missing-field-initializers -Wno-unused-result -Werror=overflow -ffast-math -fno-common -fdiagnostics-show-option -fno-strict-aliasing -fvisibility=hidden -ffunction-sections -fdata-sections -fstack-protector --param=ssp-buffer-size=4 -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -pthread -O0 -g -c unit.c -save-temps or simpler: gcc -Wformat-nonliteral -Wformat=2 -c unit.c -save-temps
[Bug gcov-profile/57121] undefined reference to gcov_merge_init and gcov_merge_add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57121 --- Comment #8 from Netra 2013-05-02 02:20:37 UTC --- I have a question, are both the flags -fprofile-arcs -ftest-coverage required for the code coverage? or is this -ftest-coverage flag enough for code coverage?
[Bug rtl-optimization/57131] [4.8/4.9 Regression] Wrong register assignment?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57131
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment #3 from Vladimir Makarov 2013-05-02
03:03:34 UTC ---
(In reply to comment #2)
> Apparently went away with the http://gcc.gnu.org/r198432 fix, but it isn't
> clear whether that change was meant to fix this or just made the bug latent.
> Anyway, still reproduceable on the 4.8 branch.
> What I'm seeing before that change is that extendsidi2_1 pattern with MEM
> destination LRA chooses %ebx as (clobber (scratch:SI)) register, eventhough
> %ebx
> is live across that instruction (there is
> (insn 14 74 68 2 (set (reg:SI 3 bx [orig:83 D.1395 ] [83])
> (mem/v/c:SI (plus:SI (reg/f:SI 7 sp)
> (const_int 72 [0x48])) [0 x4+0 S4 A64])) pr57131.c:11 85
> {*movsi_internal}
> (nil))
> (insn 68 14 73 2 (set (reg:SI 3 bx [orig:83 D.1395 ] [83])
> (reg:SI 3 bx [orig:83 D.1395 ] [83])) pr57131.c:11 85
> {*movsi_internal}
> (expr_list:REG_DEAD (reg:SI 3 bx [orig:83 D.1395 ] [83])
> (nil)))
> some insns before it and:
> (insn 65 24 26 2 (set (reg:SI 5 di [orig:83 D.1395 ] [83])
> (reg:SI 3 bx [orig:83 D.1395 ] [83])) pr57131.c:11 85
> {*movsi_internal}
> (expr_list:REG_DEAD (reg:SI 3 bx [orig:83 D.1395 ] [83])
> (nil)))
> some insns after it. Not sure if the noop move with REG_DEAD has anything to
> do with that. Vlad, can you please have a look?
http://gcc.gnu.org/r198432 was a right solution for this bug. LRA don't pay
attention to NO_REGS pseudos during assignment although ebx was assigned to
NO_REGS r95 (which is reflected in reg_renumber).
At some points of LRA work reg notes can be invalid. LRA makes them up to date
after live subpass (lra-lives.c). It needs only correct live info on bb
borders.
So I'd close this PR.
[Bug target/57097] [4.8 Regression] ICE: in find_hard_regno_for, at lra-assigns.c:561 with -O2 -fPIC -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57097 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.8.1
[Bug rtl-optimization/57131] [4.8/4.9 Regression] Wrong register assignment?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57131 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Andrew Pinski 2013-05-02 03:16:35 UTC --- (In reply to comment #3) > So I'd close this PR. Done as a dup of bug 57097. *** This bug has been marked as a duplicate of bug 57097 ***
[Bug target/57097] [4.8 Regression] ICE: in find_hard_regno_for, at lra-assigns.c:561 with -O2 -fPIC -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57097 Andrew Pinski changed: What|Removed |Added CC||ishiura-compiler at ml dot ||kwansei.ac.jp --- Comment #3 from Andrew Pinski 2013-05-02 03:16:35 UTC --- *** Bug 57131 has been marked as a duplicate of this bug. ***
[Bug libstdc++/57139] std::tuple conversion constructor does the wrong checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57139 --- Comment #2 from vpozdyayev at gmail dot com 2013-05-02 05:22:57 UTC --- Good point. Sadly, is_convertible is not equivalent to implicit convertibility exactly due to that additional requirement (not sure if the latter is intentional, or an StdLib defect). Does the paper you mention address std::tuple or std::is_convertible?
[Bug target/57097] [4.8 Regression] ICE: in find_hard_regno_for, at lra-assigns.c:561 with -O2 -fPIC -m32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57097 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |vmakarov at gcc dot gnu.org |gnu.org |
[Bug rtl-optimization/57130] [4.8/4.9 Regression] Incorrect "and --> extract" conversion in combine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57130
--- Comment #2 from Jakub Jelinek 2013-05-02
06:58:38 UTC ---
Slightly more reduced testcase:
struct S { int a, b, c, d; } s[2] = { { 6, 8, -8, -5 }, { 0, 2, -1, 2 } };
__attribute__((noinline, noclone)) void
foo (struct S r)
{
static int cnt;
if (__builtin_memcmp (&r, &s[cnt++], sizeof r) != 0)
__builtin_abort ();
}
int
main ()
{
struct S r = { 6, 8, -8, -5 };
foo (r);
r = (struct S) { 0, 2, -1, 2 };
foo (r);
return 0;
}
