[Bug other/58996] [4.9 regression] build failure in libcilkrts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996 --- Comment #13 from Jakub Jelinek --- Why the aclocal.m4 removals? Also, while the rest of the HAVE_PTHREAD_AFFINITY_NP addition is one desirable step, I've said that it is not sufficient (but of course can be done incrementally). Why the source uses sched_getaffinity + gettid when it can use pthread_getaffinity_np which will do the same thing and be less Linux OS details dependent? The code as is will not handle > 1024 CPU systems, see PR57298.
[Bug c++/59838] New: ICE with an enum using an incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59838
Bug ID: 59838
Summary: ICE with an enum using an incomplete type
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ville.voutilainen at gmail dot com
Very simple test:
enum E { a, b = true ? 1 : ((E)a, 0) };
enumcrash.cpp:1:32: internal compiler error: Segmentation fault
enum E { a, b = true ? 1 : ((E)a, 0) };
^
0xb46faf crash_signal
../../gcc/toplev.c:336
0xd65d54 int_fits_type_p(tree_node const*, tree_node const*)
../../gcc/tree.c:8566
0x69b53b ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/cp/cvt.c:756
0x6992e7 cp_build_c_cast(tree_node*, tree_node*, int)
../../gcc/cp/typeck.c:7130
0x6565ef cp_parser_binary_expression
../../gcc/cp/parser.c:7874
0x656ae1 cp_parser_assignment_expression
../../gcc/cp/parser.c:8112
0x658a74 cp_parser_expression
../../gcc/cp/parser.c:8274
0x64fe0f cp_parser_primary_expression
../../gcc/cp/parser.c:4279
0x65288a cp_parser_postfix_expression
../../gcc/cp/parser.c:5969
0x655948 cp_parser_unary_expression
../../gcc/cp/parser.c:7170
0x6565ef cp_parser_binary_expression
../../gcc/cp/parser.c:7874
0x656ae1 cp_parser_assignment_expression
../../gcc/cp/parser.c:8112
0x656dc3 cp_parser_assignment_expression
../../gcc/cp/parser.c:8162
0x656dc3 cp_parser_question_colon_clause
../../gcc/cp/parser.c:8073
0x656dc3 cp_parser_assignment_expression
../../gcc/cp/parser.c:8116
0x656f43 cp_parser_assignment_expression
../../gcc/cp/parser.c:8162
0x656f43 cp_parser_constant_expression
../../gcc/cp/parser.c:8372
0x65fe12 cp_parser_enumerator_definition
../../gcc/cp/parser.c:15634
0x65fe12 cp_parser_enumerator_list
../../gcc/cp/parser.c:15581
0x65fe12 cp_parser_enum_specifier
../../gcc/cp/parser.c:15507
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug bootstrap/56601] OpenBSD lto-plugin fails to use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56601
--- Comment #5 from m...@waldemar-brodkorb.de ---
Hi,
following change fixed it for me:
diff -Nur gcc-4.7.3.orig/gcc/config.host gcc-4.7.3/gcc/config.host
--- gcc-4.7.3.orig/gcc/config.host Tue Oct 18 08:14:14 2011
+++ gcc-4.7.3/gcc/config.host Tue Jan 7 04:33:29 2014
@@ -292,6 +292,9 @@
out_host_hook_obj=host-solaris.o
host_xmake_file="${host_xmake_file} x-solaris"
;;
+ *-*-openbsd*)
+host_lto_plugin_soname=liblto_plugin.so.0.0
+;;
*-*-linux*)
out_host_hook_obj=host-linux.o
host_xmake_file="${host_xmake_file} x-linux"
[Bug other/58996] [4.9 regression] build failure in libcilkrts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996 --- Comment #12 from Paul H. Hargrove --- Balaji, Reading the patch it looks sufficient. I will test when I have a chance, but cannot guess how soon that may be, -Paul
[Bug c/59801] GCC does not warn on unused global variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59801 --- Comment #6 from Zhendong Su --- > *** This bug has been marked as a duplicate of bug 57258 *** Andrew, I'm confused. The two are different, right? 57258 is about a possible extra warning, and this one is about a missing warning. What did I miss? Thanks.
[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 --- Comment #4 from Igor Zamyatin --- That would be great, thanks in advance!
[Bug tree-optimization/59597] [4.9 Regression] Performance degradation on Coremark after r205074
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59597 --- Comment #3 from Jeffrey A. Law --- This test is certainly exhibiting one of the problematical behaviours I was concerned about and had noted during the development of the FSM optimization code. Specifically, we might have a block where we can trivially thread all the incoming edges to specific outgoing edges. A great example might look like: ;; basic block 13, loop depth 2 ;;pred: 11 ;;12 # crc_205 = PHI # carry_206 = PHI <0(11), 1(12)> crc_207 = crc_205 >> 1; if (carry_206 != 0) goto ; else goto ; ;;succ: 14 ;;15 Of course, the threading code detects this and registers the appropriate jump threads. Where things go bad is BB13 may be on other jump threading paths. For example, this: Registering jump thread: (9, 11) incoming edge; (11, 13) joiner; (13, 15) normal; This will result in BB11 and BB13 being cloned. This doesn't really buy us anything. It's not clear if that's the cause of the slowdown or not, but it's clearly wasteful. Somewhere around here I've got some code to detect this kind of situation and do something more sensible. I've got to find it, update it and see if it improves things.
[Bug c/59801] GCC does not warn on unused global variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59801 --- Comment #5 from Andrew Pinski --- This change was done on purpose. See the patch and thread at http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00847.html
[Bug c/59801] GCC does not warn on unused global variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59801 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #4 from Andrew Pinski --- *** This bug has been marked as a duplicate of bug 57258 ***
[Bug c/57258] unused variable warning is emitted for volatile variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57258 Andrew Pinski changed: What|Removed |Added CC||chengniansun at gmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 59801 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/46507] std::get and devirtualization on non-automatic variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507 --- Comment #8 from Jan Hubicka --- Hmm, also if there is anything in standard that prevents user to pass object of type A by reference to type B (where A is not derived from B) then we can get the type info from type of parameter t.
[Bug tree-optimization/46507] std::get and devirtualization on non-automatic variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2014-01-16
CC||hubicka at gcc dot gnu.org,
||rguenther at suse dot de
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #7 from Jan Hubicka ---
OK, GIMPLE representation is pre-inlining as follows:
void arg_tuple_test(const std::pair&) (const struct pair & t)
{
const struct type & _2;
const struct type & _3;
int (*__vtbl_ptr_type) () * _5;
int (*__vtbl_ptr_type) () _6;
:
_2 = std::get<0ul, A, A> (t_1(D));
_3 = _2;
_5 = _3->_vptr.A;
_6 = *_5;
OBJ_TYPE_REF(_6;(const struct A)_3->0) (_3);
return;
}
Here I do not think we can devirtualize, because std::get can return a derived
type in general.
After inlining we get:
void arg_tuple_test(const std::pair&) (const struct pair & t)
{
int (*__vtbl_ptr_type) () * _3;
int (*__vtbl_ptr_type) () _4;
const struct A & _6;
:
_6 = &t_1(D)->first;
_3 = MEM[(const struct type *)t_1(D)]._vptr.A;
_4 = *_3;
OBJ_TYPE_REF(_4;(const struct A)_6->0) (_6); [tail call]
return;
}
Here we look all the way to figuring out that the object comes as parameter of
arg_tuple_test and give up on this point.
I think GIMPLE typing rules does not really allow us to take the type from
COMPONENT_REF in statement defining _6, so it seems we completely lose track of
the type info here. (and it indeed looks like a common case)
Richard?
[Bug c/59801] GCC does not warn on unused global variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59801
Zhendong Su changed:
What|Removed |Added
CC||su at cs dot ucdavis.edu
--- Comment #3 from Zhendong Su ---
For the given code, it does seem make sense to issue a warning (whether or not
"volatile" is used) because this is likely a bug in the code.
$ gcc-trunk -Wunused-variable small.c
$ clang-trunk -Wunused-variable small.c
small.c:1:21: warning: unused variable 'a' [-Wunused-variable]
static volatile int a;
^
1 warning generated.
$ cat small.c
static volatile int a;
int
main ()
{
return 0;
}
--
This also seems to be a missed optimization opportunity:
$ gcc-trunk -O3 -S small.c
$ cat small.s
.file"small.c"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.section.text.startup,"ax",@progbits
.LHOTB0:
.p2align 4,,15
.globlmain
.typemain, @function
main:
.LFB0:
.cfi_startproc
xorl%eax, %eax
ret
.cfi_endproc
.LFE0:
.sizemain, .-main
.section.text.unlikely
.LCOLDE0:
.section.text.startup
.LHOTE0:
.locala
.comma,4,4
.ident"GCC: (GNU) 4.9.0 20140115 (experimental) [trunk revision
206638]"
.section.note.GNU-stack,"",@progbits
[Bug other/58996] [4.9 regression] build failure in libcilkrts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996 Jeffrey A. Law changed: What|Removed |Added Priority|P1 |P4 CC||law at redhat dot com --- Comment #11 from Jeffrey A. Law --- I hacked up a RHL 8 system far enough to try and build os-unix.c. I can confirm that I got the error in this bug report and that it compiled successfully after your patch Balaji. Other issues get in the way of doing a full build/test, but RHL8 is so old that we should commit and move on :-) I certainly don't believe this should be a P1 regression.
[Bug target/59837] New: [ARM] ICE when building linux-linaro-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59837 Bug ID: 59837 Summary: [ARM] ICE when building linux-linaro-tracking Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zhenqiang.chen at linaro dot org Created attachment 31849 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31849&action=edit testcase arm-linux-gnueabi-gcc neon.c -Os -fno-omit-frame-pointer -mapcs -mabi=aapcs-linux -mfloat-abi=softfp -mfpu=neon -g -S -marm neon.c: In function ‘raid6_neon4_gen_syndrome_real’: neon.c:79:1: internal compiler error: in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1090 Root cause: When expanding epilogue, REG_CFA_ADJUST_CFA NOTE is added to handle dwarf info issue for shrink-wrap. But for TARGET_APCS_FRAME, shrink-wrap is disabled. And not all dwarf info in arm_expand_epilogue_apcs_frame are correctly updated. arm_emit_vfp_multi_reg_pop is called by both arm_expand_epilogue_apcs_frame and arm_expand_epilogue. So we should not add the NOTE in arm_emit_vfp_multi_reg_pop if shrink-wrap is not enabled.
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 --- Comment #11 from Yukhin Kirill --- (In reply to Uroš Bizjak from comment #10) > (In reply to Uroš Bizjak from comment #9) > > > This is not a good ChangeLog entry. You should say somethin along > > > > * gcc.target/i386/sse-14.c: Update constant avx512erintrin.h tests. > > * gcc.target/i386/sse-14.c: Update constants for avx512erintrin.h tests. Agree, not good. Fixed.
[Bug target/59826] ICE caused by mishandling PLD rtx on ARM cortex-m4 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59826 --- Comment #1 from Terry Guo --- As discussed in http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00875.html, the root cause should be incorrect insn type of preload instruction. 4.8 assigns alu type attribute to preload insn which causes other optimization passes think it can cause data dependence between alu->load/store. The trunk gcc with patch http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00322.html, correctly assign load1 insn type to preload instruction, which avoids the check of data dependence between alu->load/store, thereby no such issue. So the best way to fix this issue in 4.8 is to back port the patch to assign the proper insn type attribute.
[Bug libfortran/48925] Code cleanup in write_float.def
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48925 --- Comment #3 from Jerry DeLisle --- Lets first fix the known bugs so we have a good baseline. Then we can reorganize the code with little impact And with with additional test cases fro those bug fixes, we minimize our probability of regressions.
[Bug libfortran/59836] Wrong outputs with rounding formats for some values.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 --- Comment #1 from Jerry DeLisle --- I will also test your patches and review and commit for you if you need. Please let me know. I knew you were close to the solution on this one. Great job!
[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763 Uroš Bizjak changed: What|Removed |Added Attachment #30412|0 |1 is obsolete|| --- Comment #17 from Uroš Bizjak --- Created attachment 31848 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31848&action=edit Corresponding .gcda file for r206638 Updated .gcda file, compiled with a crosscompiler from x86_64-linux-gnu: $ /ssd/uros/gcc-build-alpha/gcc/cc1 -O2 -freorder-blocks-and-partition -fprofile-use -mexplicit-relocs -fpreprocessed -quiet comp-goto-1.i comp-goto-1.c: In function ‘simulator_kernel’: comp-goto-1.c:122:1: error: EDGE_CROSSING missing across section boundary comp-goto-1.c:122:1: error: EDGE_CROSSING missing across section boundary comp-goto-1.c:122:1: error: EDGE_CROSSING missing across section boundary comp-goto-1.c:122:1: error: EDGE_CROSSING missing across section boundary comp-goto-1.c:122:1: error: EDGE_CROSSING missing across section boundary comp-goto-1.c:122:1: internal compiler error: verify_flow_info failed 0x5f3343 verify_flow_info() /home/uros/gcc-svn/trunk/gcc/cfghooks.c:260 0x89cf46 split_all_insns() /home/uros/gcc-svn/trunk/gcc/recog.c:2955 0x89cfb2 rest_of_handle_split_after_reload /home/uros/gcc-svn/trunk/gcc/recog.c:3889 0x89cfb2 execute /home/uros/gcc-svn/trunk/gcc/recog.c:3918 Please submit a full bug report,
[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774
--- Comment #11 from Dominique d'Humieres ---
I have opened pr59836 for the wrong outputs in comments 0 and 9 with a patch
which fixes them plus others I have found while debugging. This new patch does
not require the kludge in comment 9. I repost the patch fixing the issue of
this PR, i.e., the inconsistent rounding, without the patch for pr59771:
--- ../_clean/libgfortran/io/write_float.def2014-01-04 15:51:53.0
+0100
+++ libgfortran/io/write_float.def2014-01-15 23:33:51.0 +0100
@@ -1018,13 +1018,14 @@ output_float_FMT_G_ ## x (st_parameter_d
int d = f->u.real.d;\
int w = f->u.real.w;\
fnode newf;\
- GFC_REAL_ ## x rexp_d, r = 0.5;\
+ GFC_REAL_ ## x rexp_d, r = 0.5, r_sc;\
int low, high, mid;\
int ubound, lbound;\
char *p, pad = ' ';\
int save_scale_factor, nb = 0;\
bool result;\
int nprinted, precision;\
+ volatile GFC_REAL_ ## x temp;\
\
save_scale_factor = dtp->u.p.scale_factor;\
\
@@ -1043,8 +1044,10 @@ output_float_FMT_G_ ## x (st_parameter_d
break;\
}\
\
- rexp_d = calculate_exp_ ## x (-d);\
- if ((m > 0.0 && ((m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >=
1.0)))\
+ rexp_d = calculate_exp_ ## x (d);\
+ r_sc = (1 - r / rexp_d);\
+ temp = 0.1 * r_sc;\
+ if ((m > 0.0 && ((m < temp) || (r >= (rexp_d - m\
|| ((m == 0.0) && !(compile_options.allow_std\
& (GFC_STD_F2003 | GFC_STD_F2008\
{ \
@@ -1066,10 +1069,9 @@ output_float_FMT_G_ ## x (st_parameter_d
\
while (low <= high)\
{ \
- volatile GFC_REAL_ ## x temp;\
mid = (low + high) / 2;\
\
- temp = (calculate_exp_ ## x (mid - 1) * (1 - r * rexp_d));\
+ temp = (calculate_exp_ ## x (mid - 1) * r_sc);\
\
if (m < temp)\
{ \
Besides some cleaning, it computes '0.1 - 0.1 * r * rexp_d' through a volatile
'temp', as it is done later, and computes 'rexp_d * (m + r) >= 1.0' as r >=
(rexp_d - m) (Note that the new rexp_d=10**d and is the inverse of the old
one).
The reason of the second change is that 'r' is 0.0, 0.5, or 1.0, i.e., stored
without rounding, as well as the new rexp_d (at least for small values of 'd',
d<11 for real(4)). So the threshold will trigger only when 'regxp_d-m' is close
to one, i.e., when the difference will lose accuracy and not be affected by
rounding.
I have collected all (most of) the tests in pr48906, pr59771, and pr59836 in a
single file and with the patch there is no differences between the output with
-m32 or -m64. The patch retested cleanly also.
[Bug rtl-optimization/59835] [4.9 Regression] gcc.target/i386/sse-23.c/gcc.target/i386/sse-24.c timeout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59835 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-15 CC||vmakarov at redhat dot com Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It is caused by r206636.
[Bug c/59820] alpha: incorrect optimisation with -mcpu=ev4 and -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59820
Uroš Bizjak changed:
What|Removed |Added
CC||rth at gcc dot gnu.org,
||ubizjak at gmail dot com
--- Comment #2 from Uroš Bizjak ---
You should use this:
--cut here--
# define TLS_LD(x)\
({ void *__result;\
register void *__gp asm ("$29");\
asm ("lda %0, " #x "(%1) !tlsldm" : "=r" (__result) : "r" (__gp));\
__result = __tls_get_addr (__result);\
asm ("lda %0, " #x "(%0) !dtprel" : "+r" (__result));\
__result; })
--cut here--
Adding rth to CC.
[Bug libfortran/59836] New: Wrong outputs with rounding formats for some values.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836
Bug ID: 59836
Summary: Wrong outputs with rounding formats for some values.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: jvdelisle at gcc dot gnu.org
This is a split off pr59774 comment 9. The code
print "(ru,g45.3)", 891.1
print "(rd,g45.3)", -891.1
end
compiled with trunk (r206559) gives the output
9.
-9.
I have also found that the code
print '(RU,F2.0)', 0.6
print '(RD,F3.0)', -0.6
end
gives
7.
-7.
Both problems occur because the Fw.d format is not properly handled when d==0.
The following patch fixes both problems
--- ../_clean/libgfortran/io/write_float.def2014-01-04 15:51:53.0
+0100
+++ libgfortran/io/write_float.def2014-01-15 22:22:17.0 +0100
@@ -373,7 +373,7 @@ output_float (st_parameter_dt *dtp, cons
updown:
rchar = '0';
- if (w > 0 && d == 0 && p == 0)
+ if (ft != FMT_F && nbefore == 0 && w > 0 && d == 0 && p == 0)
nbefore = 1;
/* Scan for trailing zeros to see if we really need to round it. */
for(i = nbefore + nafter; i < ndigits; i++)
@@ -386,13 +386,14 @@ output_float (st_parameter_dt *dtp, cons
do_rnd:
if (nbefore + nafter == 0)
+/* Handle the case Fw.0 and value < 1.0 */
{
ndigits = 0;
if (nzero_real == d && digits[0] >= rchar)
{
/* We rounded to zero but shouldn't have */
- nzero--;
- nafter = 1;
+ nbefore = 1;
+ digits--;
digits[0] = '1';
ndigits = 1;
}
The first patch handles the first problem by restricting the test to the E*
formats and the second one fixes the way Fw.0 handles values < 1.0 (yes, I have
seen the formatting issue for the line digits--. I'll fix it when I'll submit
the patch).
AFAICT the line nzero--; does not seem necessary, but I don't know why.
With the patch the first test gives
892.
-892.
and the second
1.
-1.
and I did not see any regression when retesting with it.
[Bug middle-end/59609] [4.9 Regression] LRA generates bad code for libgcc function udivmoddi4 on thumb1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59609 Vladimir Makarov changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #4 from Vladimir Makarov --- LRA should not generated output reload for a jump inns. It is definitely a bug. I'll hope to fix it tomorrow.
[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- (In reply to Uroš Bizjak from comment #15) > (In reply to Steven Bosscher from comment #14) > > Lots of hot/cold partitioning fixes have been committed in the past > > few weeks. Uros, so you still see this bug with a recent trunk? > > I still see the failure with trunk revision 206059 [1]. > > [1] http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg01719.html Could you please upload a new *.i/*.gcda combo, so it can be debugged on more recent trunk?
[Bug c/59820] alpha: incorrect optimisation with -mcpu=ev4 and -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59820 --- Comment #1 from Uroš Bizjak --- (In reply to Michael Cree from comment #0) > Created attachment 31837 [details] > Test code exhibiting problem > > Compiling the attached test (which is a cut down version of a test from > glibc test suite) on an Alpha with -mcpu=ev4 at optimisation -O2 leads > to a segmentation fault when the test is run. Output is: > > $ gcc -mcpu=ev4 -O2 -o gcc-optim-test gcc-optim-test.c > $ ./gcc-optim-test > set bar to 1 (LE) > Segmentation fault > > Compiling at lower optimisation works correctly, e.g.: > > $ gcc -mcpu=ev4 -O1 -o gcc-optim-test gcc-optim-test.c > $ ./gcc-optim-test > set bar to 1 (LE) > get sum of foo and bar (LD) = 1 > > Compiling for more advanced Alpha CPU works correctly, even at -O2, e.g.: > > $ gcc -mcpu=ev5 -O2 -o gcc-optim-test gcc-optim-test.c > $ ./gcc-optim-test > set bar to 1 (LE) > get sum of foo and bar (LD) = 1 > > Bug is seen on all versions of gcc tested ranging from gcc-4.4 upto gcc-4.8 > from Debian, and gcc git master at commit eb5d7331da45b675e (SVN trunk > 206563). > > Running the failing version under gdb: > > $ gcc -g -mcpu=ev4 -O2 -o gcc-optim-test gcc-optim-test.c > $ gdb ./gcc-optim-test > (gdb) run > Starting program: /home/mjc/test/./gcc-optim-test > set bar to 1 (LE) > > Program received signal SIGSEGV, Segmentation fault. > 0x0201545c in __tls_get_addr () from /lib/ld-linux.so.2 > (gdb) bt full > #0 0x0201545c in __tls_get_addr () from /lib/ld-linux.so.2 > No symbol table info available. > #1 0x000125a4 in do_test () at gcc-optim-test.c:44 > __result = 0x2031230 > result = 0 > ap = > bp = > #2 main () at gcc-optim-test.c:63 > No locals. > > (gdb) disass > Dump of assembler code for function __tls_get_addr: >0x02015420 <+0>: ldahgp,2(t12) >0x02015424 <+4>: lda gp,27728(gp) >0x02015428 <+8>: lda sp,-32(sp) >0x0201542c <+12>: rduniq >0x02015430 <+16>: clr a1 >0x02015434 <+20>: ldq t0,-28776(gp) >0x02015438 <+24>: stq s0,8(sp) >0x0201543c <+28>: mov a0,s0 >0x02015440 <+32>: ldq a0,0(v0) >0x02015444 <+36>: stq s1,16(sp) >0x02015448 <+40>: mov v0,s1 >0x0201544c <+44>: stq ra,0(sp) >0x02015450 <+48>: ldq t1,0(a0) >0x02015454 <+52>: cmpeq t1,t0,t0 >0x02015458 <+56>: beq t0,0x2015494 <__tls_get_addr+116> > => 0x0201545c <+60>: ldq a2,0(s0) > > (gdb) info registers > v0 0x2030b10 2199023454992 > t0 0x11 > t1 0x11 > t2 0x29 41 > t3 0x2025ff0 2199023411184 > t4 0x72616220646e6120 8241976684328149280 > t5 0x6f660029444c2820 8027103563073988640 > t6 0x61206f6f6620666f 6998716345179203183 > t7 0x6120 6998593820933750784 > s0 0x1200185d84831938008 > s1 0x2030b10 2199023454992 > s2 0x1201383884833117064 > s3 0x00 > s4 0x120143d904833164688 > s5 0x1201453304833170224 > fp 0x00 > a0 0x2031230 2199023456816 > a1 0x00 > a2 0x00 > a3 0x21c8798 2199025125272 > a4 0x -1 > a5 0x00 > t8 0x28 40 > t9 0x20b7280 2199024005760 > t100x11 17 > t110x400 1024 > ra 0x125a44831839652 > t120x2015420 2199023342624 > at 0x7c8ad2d8 2089472728 > gp 0x203c070 0x203c070 > sp 0x11f8cd5c00x11f8cd5c0 > pc 0x201545c 0x201545c <__tls_get_addr+60> > (gdb) print (long)*0x1200185d8 > Cannot access memory at address 0x1200185d8 > > So it would appear that the argument passed to __tls_get_addr() was not > a valid address. Because TLS_LD is defined in a wrong way. ldah $29,0($26) !gpdisp!9 .setmacro # 44 "gcc-optim-test.c" 1 lda $16, foo($gp) !tlsldm # 0 "" 2 .setnomacro lda $29,0($29) !gpdisp!9 ldq $27,__tls_get_addr($29) !literal!10 jsr $26,($27),__tls_get_addr!lituse_jsr!10 Please note how !gpdisp!9 gets emitted after !tlsldm load. Moving "lda $29,0($29)" (and corresponding bar related insn) in front of !tlsldm load fixes the ICE.
[Bug other/59834] [4.9 Regression] g++.dg/cilk-plus/CK/catch_exc.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59834 --- Comment #2 from H.J. Lu --- (In reply to Balaji V. Iyer from comment #1) > Hi H. J., >I am not able to reproduce it in my SUSE machine. I tried both -m64 and > -m32. > Please configure GCC with --with-arch=corei7 --with-cpu=corei7.
[Bug rtl-optimization/59835] New: [4.9 Regression] gcc.target/i386/sse-23.c/gcc.target/i386/sse-24.c timeout
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59835 Bug ID: 59835 Summary: [4.9 Regression] gcc.target/i386/sse-23.c/gcc.target/i386/sse-24.c timeout Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com On Linux/x86-64, revision 206638 gave WARNING: program timed out. FAIL: gcc.target/i386/sse-23.c (test for excess errors) WARNING: program timed out. FAIL: gcc.target/i386/sse-24.c (test for excess errors) cc1 takes huge amount of memory. Revision 206630 is OK.
[Bug tree-optimization/59336] [4.9 Regression] definition in block 317 does not dominate use in block 316
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |WORKSFORME --- Comment #6 from Jeffrey A. Law --- The failure modes look different than the bugs fixed by 206599 (58921, 59006). It's unclear if the problem has just gone latent or was fixed. I'm going to close, but if it reappears, don't hesitate to reopen this bug.
[Bug target/59787] [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Richard Earnshaw --- fixed
[Bug other/59834] [4.9 Regression] g++.dg/cilk-plus/CK/catch_exc.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59834 --- Comment #1 from Balaji V. Iyer --- Hi H. J., I am not able to reproduce it in my SUSE machine. I tried both -m64 and -m32. Thanks, Balaji V. Iyer.
[Bug debug/54694] [4.7/4.8 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694 Richard Henderson changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] |internal compiler error: in |internal compiler error: in |dwarf2out_frame_debug_expr, |dwarf2out_frame_debug_expr, |at dwarf2out.c:2387 |at dwarf2out.c:2387 Known to fail|4.9.0 | --- Comment #18 from Richard Henderson --- Fixed for 4.9.
[Bug tree-optimization/59387] [4.9 Regression] wrong code (hangs) at -Os on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59387 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #11 from Jeffrey A. Law --- Fixed by jakub's commit.
[Bug debug/54694] [4.7/4.8/4.9 Regression] internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2387
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54694 --- Comment #17 from Richard Henderson --- Author: rth Date: Wed Jan 15 21:41:03 2014 New Revision: 206647 URL: http://gcc.gnu.org/viewcvs?rev=206647&root=gcc&view=rev Log: PR debug/54694 Diagnose frame_pointer_required vs fixed hfp Added: trunk/gcc/testsuite/gcc.target/i386/pr54694.c Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c trunk/gcc/reginfo.c trunk/gcc/rtl.h
[Bug target/59787] [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787 --- Comment #5 from Renlin Li --- (In reply to Richard Earnshaw from comment #4) > Is this fixed now? Yes, and the patch has already been committed
[Bug ipa/59775] [4.9 Regression] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59775 --- Comment #12 from Jan Hubicka --- OK, thanks for testing. I posted the patch. How far do we get with libreoffice and LTO now? (I need to move my compilation setup to new machine, it is on my TODO to get some statistic about devirtualization there - or any other app that does virtual inheritance)
[Bug other/59834] New: [4.9 Regression] g++.dg/cilk-plus/CK/catch_exc.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59834 Bug ID: 59834 Summary: [4.9 Regression] g++.dg/cilk-plus/CK/catch_exc.cc Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: bviyer at gmail dot com On Linux/x86, revision 206641 gave FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -g -O2 -fcilkplus execution test FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -O1 -fcilkplus execution test FAIL: g++.dg/cilk-plus/CK/catch_exc.cc -O3 -fcilkplus execution test
[Bug c++/59752] Stack overflow on simple testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59752 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Markus Trippelsdorf --- Fixed by r206639.
[Bug c++/59659] large zero-initialized std::array compile time excessive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59659 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #10 from Jason Merrill --- Fixed for 4.9.
[Bug ipa/59831] ice in cgraph_speculative_call_info with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59831
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-01-15
CC||hubicka at gcc dot gnu.org,
||trippels at gcc dot gnu.org
Component|c |ipa
Target Milestone|--- |4.9.0
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
Confirmed.
markus@x4 /tmp % cat test.ii
class A {};
class B {
public:
A &operator[](int);
};
class C : B {
public:
virtual int m_fn1() { return 0; }
A &operator[](int p1) {
int a;
a = m_fn1();
static_cast(__builtin_expect(a, 0) ?: 0);
return B::operator[](p1);
}
};
C b;
int *e;
static void sort(C &p1, C &p2) {
for (int i=0;; i++) {
A c, d = p2[0];
p1[0] = c;
p2[0] = d;
}
}
void lookupSourceDone() { b[0]; }
void update_sources() {
if (e) {
C f;
sort(f, b);
}
}
markus@x4 /tmp % g++ -c -O3 test.ii
test.ii: In function ‘A& C::operator[].constprop()’:
test.ii:9:6: internal compiler error: in cgraph_speculative_call_info, at
cgraph.c:1197
A &operator[](int p1) {
^
Please submit a full bug report,
[Bug target/59787] [ARM] mmx-2.c causes ICE when GCC is configured for cortex-a5/vfpv3-d16-fp16
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787 Richard Earnshaw changed: What|Removed |Added Target||arm --- Comment #4 from Richard Earnshaw --- Is this fixed now?
[Bug target/59833] New: ARM soft-float extendsfdf2 fails to quiet signaling NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59833 Bug ID: 59833 Summary: ARM soft-float extendsfdf2 fails to quiet signaling NaN Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org Target: arm*-*-* The ARM soft-float aeabi_f2d / extendsfdf2 converts a signaling NaN to another signaling NaN, when it should quiet it. This causes the glibc math/basic-test to fail: Failure: double x = (double) (float) sNaN, !issignaling
[Bug other/58996] [4.9 regression] build failure in libcilkrts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996 --- Comment #10 from Balaji V. Iyer --- Hi Paul and Jakub, I have attached a patch above (called "Possible Fix"). Does it work for you? Thanks, Balaji V. Iyer.
[Bug other/58996] [4.9 regression] build failure in libcilkrts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996 --- Comment #9 from Balaji V. Iyer --- Created attachment 31847 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31847&action=edit Possible fix
[Bug c++/49718] please allow no_instrument_function attribute in class member definition/declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49718 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Fixed by recent trunk commit.
[Bug c++/49718] please allow no_instrument_function attribute in class member definition/declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49718 --- Comment #3 from Jeffrey A. Law --- Author: law Date: Wed Jan 15 19:37:35 2014 New Revision: 206643 URL: http://gcc.gnu.org/viewcvs?rev=206643&root=gcc&view=rev Log: PR c++/49718 * c-common.c (handle_no_instrument_function_attribute): Allow no_instrument_function attribute in class member definition/declaration. PR c++/49718 * g++.dg/pr49718.C: New test. Added: trunk/gcc/testsuite/g++.dg/pr49718.C Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug c++/59659] large zero-initialized std::array compile time excessive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59659 --- Comment #9 from Jason Merrill --- Author: jason Date: Wed Jan 15 19:10:09 2014 New Revision: 206639 URL: http://gcc.gnu.org/viewcvs?rev=206639&root=gcc&view=rev Log: PR c++/59659 * typeck2.c (massage_init_elt): New. (process_init_constructor_record) (process_init_constructor_union): Use it. (process_init_constructor_array): Use it. Use RANGE_EXPR. (split_nonconstant_init_1): Handle it. * semantics.c (cxx_eval_vec_init_1): Use force_rvalue. Added: trunk/gcc/testsuite/g++.dg/opt/value-init1.C trunk/gcc/testsuite/g++.dg/opt/value-init2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/cp/typeck2.c
[Bug target/58675] ICE in rs6000_secondary_reload_inner:15460, type = store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675 Pat Haugen changed: What|Removed |Added Attachment #30973|0 |1 is obsolete|| --- Comment #2 from Pat Haugen --- Created attachment 31846 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31846&action=edit New test 177.mesa still fails to build, new reduced testcase attached. [pthaugen@igoo pr58675]$ /home/pthaugen/install/gcc/trunk/bin/gcc -c -m64 -O1 -mcpu=power8 triangle-2.c rs6000_secondary_reload_inner:16294, type = store (parallel [ (set (mem/c:SF (plus:DI (plus:DI (reg/f:DI 1 1) (const_int 65536 [0x1])) (const_int -30176 [0x8a20])) [0 %sfp+35360 S4 A32]) (reg:SF 32 0)) (clobber (reg:DI 9 9)) ]) triangle-2.c: In function ‘lambda_textured_triangle’: triangle-2.c:452:1: internal compiler error: in rs6000_secondary_reload_fail, at config/rs6000/rs6000.c:16121 } ^ 0x109c2bf7 rs6000_secondary_reload_fail /home/pthaugen/src/gcc/trunk/gcc/gcc/config/rs6000/rs6000.c:16121 0x109f5957 rs6000_secondary_reload_inner(rtx_def*, rtx_def*, rtx_def*, bool) /home/pthaugen/src/gcc/trunk/gcc/gcc/config/rs6000/rs6000.c:16148 0x10ac908b gen_reload_sf_di_store(rtx_def*, rtx_def*, rtx_def*) /home/pthaugen/src/gcc/trunk/gcc/gcc/config/rs6000/vector.md:197 0x1063cf0b insn_gen_fn::operator()(rtx_def*, rtx_def*, rtx_def*) const /home/pthaugen/src/gcc/trunk/gcc/gcc/recog.h:285 0x1063cf0b emit_output_reload_insns /home/pthaugen/src/gcc/trunk/gcc/gcc/reload1.c:7758 0x1063cf0b do_output_reload ...
[Bug tree-optimization/59747] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59747 --- Comment #10 from Jeffrey A. Law --- Author: law Date: Wed Jan 15 18:13:52 2014 New Revision: 206638 URL: http://gcc.gnu.org/viewcvs?rev=206638&root=gcc&view=rev Log: PR tree-optimization/59747 * ree.c (find_and_remove_re): Properly handle case where a second eliminated extension requires widening a copy created for elimination of a prior extension. (combine_set_extension): Ensure that the number of hard regs needed for a destination register does not change when we widen it. PR tree-optimization/59747 * gcc.c-torture/execute/pr59747.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr59747.c Modified: trunk/gcc/ChangeLog trunk/gcc/ree.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/59747] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59747 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Jeffrey A. Law --- Fixed on trunk.
[Bug rtl-optimization/59511] [4.9 Regression] FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa with -mtune=corei7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59511 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed, thanks.
[Bug rtl-optimization/59511] [4.9 Regression] FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa with -mtune=corei7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59511 --- Comment #4 from Vladimir Makarov --- Author: vmakarov Date: Wed Jan 15 17:32:47 2014 New Revision: 206636 URL: http://gcc.gnu.org/viewcvs?rev=206636&root=gcc&view=rev Log: 2014-01-15 Vladimir Makarov PR rtl-optimization/59511 * ira.c (ira_init_register_move_cost): Use memory costs for some cases of register move cost calculations. * lra-constraints.c (lra_constraints): Use REG_FREQ_FROM_BB instead of BB frequency. * lra-coalesce.c (move_freq_compare_func, lra_coalesce): Ditto. * lra-assigns.c (find_hard_regno_for): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c trunk/gcc/lra-assigns.c trunk/gcc/lra-coalesce.c trunk/gcc/lra-constraints.c
[Bug c++/59832] New: [c++11][4.8, 4.9] ICE in reshape_init_class with initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
Bug ID: 59832
Summary: [c++11][4.8, 4.9] ICE in reshape_init_class with
initializer list
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref b/12545403
/// -- cut ---
struct A
{
struct B
{
int aa;
int bb;
};
B cc;
};
void Fn1 (const A &);
void
Fn2 ()
{
Fn1 ( { { bb: 0 } });
}
/// -- cut ---
Using trunk:
g++ (GCC) 4.9.0 20140110 (experimental)
g++ -c -g -std=c++11 t.ii
t.ii: In function ‘void Fn2()’:
t.ii:16:22: internal compiler error: in reshape_init_class, at cp/decl.c:5267
Fn1 ( { { bb: 0 } });
^
0x56de5d reshape_init_class
../../gcc/cp/decl.c:5267
0x56de5d reshape_init_r
../../gcc/cp/decl.c:5493
0x56d026 reshape_init(tree_node*, tree_node*, int)
../../gcc/cp/decl.c:5537
0x55364f build_aggr_conv
../../gcc/cp/call.c:885
0x55364f implicit_conversion
../../gcc/cp/call.c:1757
0x5587d6 can_convert_arg(tree_node*, tree_node*, tree_node*, int, int)
../../gcc/cp/call.c:8948
0x5536e5 build_aggr_conv
../../gcc/cp/call.c:910
0x5536e5 implicit_conversion
../../gcc/cp/call.c:1757
0x554041 reference_binding
../../gcc/cp/call.c:1464
0x552e5c implicit_conversion
../../gcc/cp/call.c:1698
0x555112 add_function_candidate
../../gcc/cp/call.c:2002
0x551836 add_candidates
../../gcc/cp/call.c:5094
0x558b82 perform_overload_resolution
../../gcc/cp/call.c:3819
0x55f68a build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/cp/call.c:3896
0x6d9711 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2281
0x65c73e cp_parser_postfix_expression
../../gcc/cp/parser.c:6171
0x65f418 cp_parser_unary_expression
../../gcc/cp/parser.c:7177
0x6600af cp_parser_binary_expression
../../gcc/cp/parser.c:7881
0x6605a1 cp_parser_assignment_expression
../../gcc/cp/parser.c:8119
0x662534 cp_parser_expression
../../gcc/cp/parser.c:8281
Please submit a full bug report,
Without -std=c++11, same crash after warning:
g++ -c -g t.ii
t.ii: In function ‘void Fn2()’:
t.ii:16:7: warning: extended initializer lists only available with -std=c++11
or -std=gnu++11 [enabled by default]
Fn1 ( { { bb: 0 } });
^
t.ii:16:22: warning: extended initializer lists only available with -std=c++11
or -std=gnu++11 [enabled by default]
Fn1 ( { { bb: 0 } });
^
t.ii:16:22: internal compiler error: in reshape_init_class, at cp/decl.c:5267
0x56de5d reshape_init_class
../../gcc/cp/decl.c:5267
...
[Bug target/59794] [4.7/4.8 Regression] i386 backend fails to detect MMX/SSE/AVX ABI changes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59794 --- Comment #10 from hjl at gcc dot gnu.org --- Author: hjl Date: Wed Jan 15 17:08:38 2014 New Revision: 206634 URL: http://gcc.gnu.org/viewcvs?rev=206634&root=gcc&view=rev Log: Silence vector ABI change warnings for x86 PR target/59794 * c-c++-common/convert-vec-1.c: Also prune ABI change for Linux/x86. * g++.dg/cpp0x/constexpr-53094-2.C: Likewise. * g++.dg/ext/attribute-test-1.C: Likewise. * g++.dg/ext/attribute-test-2.C: Likewise. * g++.dg/ext/attribute-test-3.C: Likewise. * g++.dg/ext/attribute-test-4.C: Likewise. * g++.dg/ext/pr56790-1.C: Likewise. * g++.dg/torture/pr38565.C: Likewise. * gcc.dg/pr53060.c: Likewise. * c-c++-common/scal-to-vec2.c: Add -msse2 for x86. * c-c++-common/vector-compare-2.c: Likewise. * gcc.dg/Wstrict-aliasing-bogus-ref-all-2.c: Likewise. * g++.dg/conversion/simd1.C: Add -msse2 for x86. Adjust dg-message line number. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/convert-vec-1.c trunk/gcc/testsuite/c-c++-common/scal-to-vec2.c trunk/gcc/testsuite/c-c++-common/vector-compare-2.c trunk/gcc/testsuite/g++.dg/conversion/simd1.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-53094-2.C trunk/gcc/testsuite/g++.dg/ext/attribute-test-1.C trunk/gcc/testsuite/g++.dg/ext/attribute-test-2.C trunk/gcc/testsuite/g++.dg/ext/attribute-test-3.C trunk/gcc/testsuite/g++.dg/ext/attribute-test-4.C trunk/gcc/testsuite/g++.dg/ext/pr56790-1.C trunk/gcc/testsuite/g++.dg/torture/pr38565.C trunk/gcc/testsuite/gcc.dg/Wstrict-aliasing-bogus-ref-all-2.c trunk/gcc/testsuite/gcc.dg/pr53060.c
[Bug libstdc++/59712] unordered_map : clang fails with "member access into incomplete type"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59712 François Dumont changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from François Dumont --- We now assert the method on the type exposing it which is completely defined at this moment.
[Bug c/59831] New: ice in cgraph_speculative_call_info with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59831 Bug ID: 59831 Summary: ice in cgraph_speculative_call_info with -O3 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 31845 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31845&action=edit gzipped C++ source code I just compiled the attached code with gcc trunk 20140115 on a x86_64 box with flag -O3 and it said In file included from StringA.h:32:0, from file.h:33, from file.C:33: VarArray.h: In function ‘T& VarArray::operator[](int) [with T = string]’: VarArray.h:123:8: internal compiler error: in cgraph_speculative_call_info, at cgraph.c:1197 0x82cdfb cgraph_speculative_call_info(cgraph_edge*, cgraph_edge*&, cgraph_edge*&, ipa_ref*&) ../../src/trunk/gcc/cgraph.c:1197 0x82cf5f cgraph_resolve_speculation(cgraph_edge*, tree_node*) ../../src/trunk/gcc/cgraph.c:1224 0x831030 cgraph_make_edge_direct(cgraph_edge*, cgraph_node*) ../../src/trunk/gcc/cgraph.c:1286 0x83123f cgraph_set_call_stmt(cgraph_edge*, gimple_statement_base*, bool) ../../src/trunk/gcc/cgraph.c:825 0x831281 cgraph_set_call_stmt(cgraph_edge*, gimple_statement_base*, bool) ../../src/trunk/gcc/cgraph.c:802 This looks different to bug # 58477 to me.
[Bug c++/59821] __builtin_LINE and __builtin_FILE for new'd objects is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59821
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
For the calls this just happens to work completely by accident, nothing else.
I mean, the default argument expression obviously has location_t from where it
has been defined, i.e. the function/method/ctor definition. The reason why in
the first case you get the locus of the call is that gimplify_arg sets the
location_t of the arguments to that, but only on the toplevel expression.
Now, in the new case the C++ FE adds an TARGET_EXPR around the default argument
and so during the gimplification it is no longer toplevel expression in the
argument, so gimplify_arg doesn't adjust it.
If you write:
struct Foo
{
int line;
Foo (int line = __builtin_LINE () + 1) : line (line) {}
};
int
main ()
{
if (Foo().line != (new Foo)->line)
__builtin_abort ();
}
then it will be in both cases the location of the Foo ctor, because the
argument will not be __builtin_LINE() CALL_EXPR as toplevel.
So, IMHO if you want a different behavior, you shouldn't leave this to the
gimplifier, but explicitly change it in the FE. Say in convert_default_arg or
functions it calls change EXPR_LOCATION of all CALL_EXPRs to the 3 problematic
builtins (I'd argue that only those and nothing else, the expressions really
have locus of where the default argument has been defined and it is desirable
to use that for diagnostic purposes etc.). convert_default_arg already walks
the expression several times through break_out_target_exprs, so if we e.g.
wanted to
avoid the cost of walking it once again, break_out_target_exprs could have a
flag to tweak location_t of __builtin_{LINE,FILE,FUNCTION}. Jason, thoughts on
this? In any case this needs to be documented. What about other default
locations? Say if e.g. NSDMI contains __builtin_LINE () call, do we want to
get a value of where the NSDMI is defined, or where the object is constructed?
[Bug c++/59739] missed optimization: attribute ((pure)) could be honored more often
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739 --- Comment #1 from Jörg Richter --- clang seems to optimize all cases.
[Bug libstdc++/59830] std::packaged_task throws exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59830 --- Comment #1 from Jonathan Wakely --- relies on mutexes and condition variables so you need to compile and link with -pthread
[Bug libstdc++/59830] New: std::packaged_task throws exception
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59830
Bug ID: 59830
Summary: std::packaged_task throws exception
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: b17c0de at gmail dot com
user@domain:~/work/test$ uname -a
Linux domain 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux
user@domain:~/work/test$ g++ --version
g++ (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
user@domain:~/work/test$ cat fut.cc
#include
#include
int main()
{
std::packaged_task task([]() { return 42; });
std::future result = task.get_future();
task();
std::cout << "task_lambda:\t" << result.get() << '\n';
}
user@domain:~/work/test$ g++ -std=c++11 -g fut.cc
user@domain:~/work/test$ ./a.out
terminate called after throwing an instance of 'std::system_error'
what(): Unknown error 18446744073709551615
Abgebrochen
[Bug c++/59829] New: Calling vector::data() occurs undefined behavior when the vector is empty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59829
Bug ID: 59829
Summary: Calling vector::data() occurs undefined behavior when
the vector is empty
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lin90162 at gmail dot com
When vector is empty, calling vector::data() occurs undefined behavior by
dereferencing NULL.
The implementation of vector::data() and vector::front() in libstdc++ are below
/// BEGIN OF CODE
reference
front()
{ return *begin(); }
const_reference
front() const
{ return *begin(); }
data() _GLIBCXX_NOEXCEPT
{ return std::__addressof(front()); }
data() _GLIBCXX_NOEXCEPT
{ return std::__addressof(front()); }
/// END OF CODE
Here, when vector is empty, begin() is called, then begin() returns NULL and it
is dereferenced.
N3337 23.3.6.4 says "Returns: A pointer such that [data(),data() + size()) is a
valid range. For a non-empty vector, data() == &front()".
It means that calling vector::data() is well-defined even if vector is empty.
As additional information, libc++ implementation of vector::data() can be
called safely when vector is empty.
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 --- Comment #9 from Uroš Bizjak --- (In reply to Kirill Yukhin from comment #7) > Author: kyukhin > Date: Wed Jan 15 12:01:08 2014 > New Revision: 206629 > > URL: http://gcc.gnu.org/viewcvs?rev=206629&root=gcc&view=rev > Log: > PR target/59808 > * gcc.target/i386/sse-12.c: Add `-mavx512[cd, er, pf]' options. > * gcc.target/i386/sse-14.c: Fix PR59808. This is not a good ChangeLog entry. You should say somethin along * gcc.target/i386/sse-14.c: Update constant avx512erintrin.h tests.
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 --- Comment #10 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #9) > This is not a good ChangeLog entry. You should say somethin along > > * gcc.target/i386/sse-14.c: Update constant avx512erintrin.h tests. * gcc.target/i386/sse-14.c: Update constants for avx512erintrin.h tests.
[Bug c++/59742] compilation failed for package ‘RcppEigen’
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59742 --- Comment #6 from patrikdinnetz --- Probably not./Patrik -"redi at gcc dot gnu.org" skrev: -Till: Patrik Dinnétz/Personal/Sodertorn@Sodertorn Från: "redi at gcc dot gnu.org" Datum: 01/15/2014 10:04FM Ärende: [Bug c++/59742] compilation failed for package ‘RcppEigen’ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59742 Jonathan Wakely changed: What |Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jonathan Wakely --- Not a GCC bug then. -- You are receiving this mail because: You reported the bug.
[Bug rtl-optimization/42175] Slow compile and much memory use at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42175 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.9.0 Resolution|--- |FIXED --- Comment #9 from Richard Biener --- GCC 4.9 will use about 800MB at -O1 and combiner: 2.92 ( 4%) usr 0.02 ( 1%) sys 2.77 ( 4%) wall 56720 kB ( 4%) ggc integrated RA : 4.87 ( 7%) usr 0.06 ( 3%) sys 4.87 ( 7%) wall 138947 kB ( 9%) ggc LRA non-specific: 2.45 ( 4%) usr 0.03 ( 1%) sys 2.49 ( 4%) wall 22036 kB ( 1%) ggc TOTAL : 66.46 at -O2 memory usage stays the same but df reaching defs: 7.16 ( 7%) usr 0.01 ( 0%) sys 6.93 ( 7%) wall 0 kB ( 0%) ggc df live regs: 6.87 ( 7%) usr 0.04 ( 1%) sys 6.86 ( 7%) wall 0 kB ( 0%) ggc df live&initialized regs: 4.05 ( 4%) usr 0.00 ( 0%) sys 4.19 ( 4%) wall 0 kB ( 0%) ggc combiner: 3.17 ( 3%) usr 0.04 ( 1%) sys 3.10 ( 3%) wall 61821 kB ( 3%) ggc integrated RA : 5.77 ( 6%) usr 0.06 ( 2%) sys 5.95 ( 6%) wall 139550 kB ( 7%) ggc LRA non-specific: 2.49 ( 3%) usr 0.02 ( 1%) sys 2.48 ( 2%) wall 21955 kB ( 1%) ggc TOTAL : 97.65 2.67 100.30 1881806 kB I'd say FIXED. Yay.
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #53 from Richard Biener --- With the PR59802 and PR38518 fixes on trunk I see for the 2nd testcase at -O2 PRE : 19.23 (35%) usr 0.01 ( 1%) sys 19.22 (34%) wall 1421 kB ( 0%) ggc combiner: 13.24 (24%) usr 0.14 (19%) sys 13.37 (24%) wall 402488 kB (73%) ggc integrated RA : 9.28 (17%) usr 0.35 (47%) sys 9.65 (17%) wall 26707 kB ( 5%) ggc TOTAL : 55.56 0.7456.34 550215 kB compared to the 4.8 branch: tree loop invariant motion: 17.29 (22%) usr PRE : 24.25 (31%) usr combiner: 12.52 (16%) usr 0.14 (17%) sys 12.66 (16%) wall 402491 kB (74%) ggc integrated RA : 7.96 (10%) usr 0.32 (38%) sys 8.25 (11%) wall 26420 kB ( 5%) ggc TOTAL : 77.53 0.8478.53 542544 kB so it's an improvement (tree LIM is off the radar completely, RTL PRE is improved a bit - looking at it now).
[Bug tree-optimization/59822] [4.9 Regression] ice in compute_live_loop_exits with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59822 --- Comment #3 from Richard Biener --- Author: rguenth Date: Wed Jan 15 15:13:08 2014 New Revision: 206630 URL: http://gcc.gnu.org/viewcvs?rev=206630&root=gcc&view=rev Log: 2014-01-15 Richard Biener PR tree-optimization/59822 * tree-vect-stmts.c (hoist_defs_of_uses): New function. (vectorizable_load): Use it to hoist defs of uses of invariant loads out of the loop. * g++.dg/torture/pr59822.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr59822.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/59822] [4.9 Regression] ice in compute_live_loop_exits with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59822 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug rtl-optimization/59477] [4.8/4.9 Regression] ICE: in assign_by_spills, at lra-assigns.c:1281 with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59477 --- Comment #7 from Jakub Jelinek --- Created attachment 31844 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31844&action=edit gcc49-pr59477.patch Untested fix.
[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58245 Anthony G. Basile changed: What|Removed |Added CC||basile at opensource dot dyc.edu --- Comment #8 from Anthony G. Basile --- Gentoo's hardened toolchain is stumbling on this bug and its a blocker for us to get musl + gentoo working nicely. Has there been any movement on it?
[Bug target/59828] Broken assembly on ppc* with two -mcpu= options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59828 Jakub Jelinek changed: What|Removed |Added CC||amodra at gcc dot gnu.org, ||dje at gcc dot gnu.org Target Milestone|--- |4.8.3
[Bug target/59828] New: Broken assembly on ppc* with two -mcpu= options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59828
Bug ID: 59828
Summary: Broken assembly on ppc* with two -mcpu= options
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
gcc -m32 -O2 -mcpu=750 -mcpu=power7 -c test.c
results in assembler complaining:
Error: junk at end of line: `1'
While the last -mcpu= option wins for compilation flags, when determining gas
options to be passed to the assembler rs6000.h uses a sequence matching each
-mcpu= individually, and -mcpu=750 is handled there after -mcpu=power7 and thus
overrides the power7 ISA in as flags with 750 ISA flags.
Don't know the *.opt stuff enough if there is a way even for the -mcpu= etc.
options to cancel all previous occurences with different strings from matching,
if not, perhaps at least the list in rs6000.h should be sorted such that at
least in most cases assembler flags that are superset of others are before
flags for the subsets.
typedef struct
{
int channels;
void *codec_setup;
} vorbis_info;
typedef struct vorbis_dsp_state
{
vorbis_info *vi;
float **pcm;
long W;
void *backend_state;
} vorbis_dsp_state;
typedef struct vorbis_block
{
float **pcm;
} vorbis_block;
typedef struct private_state
{
int window[2];
} private_state;
typedef struct highlevel_byblocktype
{
long blocksizes[2];
int halfrate_flag;
} codec_setup_info;
extern float *_vorbis_window_get (int n);
void
vorbis_synthesis_blockin (vorbis_dsp_state * v, vorbis_block * vb)
{
vorbis_info *vi = v->vi;
codec_setup_info *ci = vi->codec_setup;
private_state *b = v->backend_state;
int hs = ci->halfrate_flag;
int i, j;
int n = ci->blocksizes[v->W] >> (hs + 1);
int n0 = ci->blocksizes[0] >> (hs + 1);
int n1 = ci->blocksizes[1] >> (hs + 1);
int thisCenter = 0, prevCenter = 0;
for (j = 0; j < vi->channels; j++)
{
float *w = _vorbis_window_get (b->window[1] - hs);
float *pcm = v->pcm[j] + prevCenter;
float *p = vb->pcm[j];
for (i = 0; i < n1; i++)
pcm[i] = pcm[i] * w[n1 - i - 1] + p[i] * w[i];
float *w2 = _vorbis_window_get (b->window[0] - hs);
float *pcm2 = v->pcm[j] + prevCenter;
float *p2 = vb->pcm[j] + n1 / 2 - n0 / 2;
for (i = 0; i < n0; i++)
pcm2[i] = pcm2[i] * w2[n0 - i - 1] + p2[i] * w2[i];
for (; i < n1 / 2 + n0 / 2; i++)
pcm2[i] = p2[i];
float *pcm3 = v->pcm[j] + thisCenter;
float *p3 = vb->pcm[j] + n;
for (i = 0; i < n; i++)
pcm3[i] = p3[i];
}
}
[Bug target/59773] Mixing pointers to different memory spaces shows no warning (gcc for AVR)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59773 Georg-Johann Lay changed: What|Removed |Added Target||avr Priority|P3 |P5 Status|UNCONFIRMED |RESOLVED Component|c |target Resolution|--- |INVALID Severity|major |normal --- Comment #1 from Georg-Johann Lay --- Please use the -Waddr-space-convert option available for avr-gcc, cf. PR56263 available in 4.8.0 and newer. Because PR56263 is neither a documentation fix nor a bug, it won't be backported to 4.7 according to GCC's porting pilicies.
[Bug rtl-optimization/38518] Excessive compile time with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38518 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- Mine.
[Bug rtl-optimization/59811] [4.8/4.9 Regression] Huge increase in memory usage and compile time in combine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59811 --- Comment #2 from Richard Biener --- No clear offender in combine. Points at if_then_else_cond (14% of combine time). LRA slowness is calls to find_hard_regno_for, 93% of lra_assign ().
[Bug middle-end/59827] [4.7/4.8/4.9 Regression] ICE on array with incomplete element type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59827 Marek Polacek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Known to work||4.6.3 Keywords||ice-on-invalid-code Last reconfirmed||2014-01-15 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |4.7.4 Known to fail||4.7.4, 4.8.3, 4.9.0 --- Comment #1 from Marek Polacek --- I have a patch.
[Bug middle-end/59827] New: [4.7/4.8/4.9 Regression] ICE on array with incomplete element type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59827
Bug ID: 59827
Summary: [4.7/4.8/4.9 Regression] ICE on array with incomplete
element type
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
int
foo (int p[2][])
{
return p[0][0];
}
void
bar (void)
{
int p[2][1];
foo (p);
}
$ ./cc1 -quiet zz.c
zz.c:2:10: error: array type has incomplete element type
foo (int p[2][])
^
zz.c: In function ‘bar’:
zz.c:11:3: error: type of formal parameter 1 is incomplete
foo (p);
^
zz.c:8:1: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:81
bar (void)
^
0xfb8b22 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/marek/src/gcc/gcc/tree.c:9243
0x56bd16 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/marek/src/gcc/gcc/tree.h:2832
0x9455e2 useless_type_conversion_p(tree_node*, tree_node*)
/home/marek/src/gcc/gcc/gimple-expr.c:81
0x732bc8 types_compatible_p
/home/marek/src/gcc/gcc/gimple-expr.h:65
0x73a350 gimple_check_call_args
/home/marek/src/gcc/gcc/cgraph.c:3039
0x73a7a1 gimple_check_call_matching_types(gimple_statement_base*, tree_node*,
bool)
/home/marek/src/gcc/gcc/cgraph.c:3089
0x734bbd cgraph_create_edge_1
/home/marek/src/gcc/gcc/cgraph.c:894
0x734ca2 cgraph_create_edge(cgraph_node*, cgraph_node*, gimple_statement_base*,
long, int)
/home/marek/src/gcc/gcc/cgraph.c:916
0x73bd85 build_cgraph_edges
/home/marek/src/gcc/gcc/cgraphbuild.c:337
0x73c12a execute
/home/marek/src/gcc/gcc/cgraphbuild.c:409
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug c/59825] [4.9 Regression] Many cilkplus test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59825 Jakub Jelinek changed: What|Removed |Added CC||bviyer at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- That is known, I've said that explicitly in the patch submission that AN is broken and will need to be fixed.
[Bug c/59825] [4.9 Regression] Many cilkplus test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59825 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-15 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It is caused by r206620.
[Bug tree-optimization/59747] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu in 64-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59747 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #9 from Markus Trippelsdorf --- *** Bug 59824 has been marked as a duplicate of this bug. ***
[Bug middle-end/59824] [4.9 Regression] r206418 miscompiles ffmpeg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59824 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #5) > Can you try the PR59747 fix > http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00703.html first? Thanks Jakub. The patch fixes the issue. So dup of PR59747. *** This bug has been marked as a duplicate of bug 59747 ***
[Bug target/59788] Mixing libc and libgcc_s unwinders on 64-bit Solaris 10+/x86 breaks EH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59788 --- Comment #2 from Rainer Orth --- Created attachment 31843 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31843&action=edit initial patch The attached initial patch works fine and fixes the testcase from the PR, but is unacceptable as is. Initially, I attempted to force direct binding to the libgcc_s unwinder by linking with a special mapfile if linking with -lgcc_s. This doesn't work since libtool builds shared libraries with -shared -nostdlib, adding -lgcc_s itself. The second attempt (attached) instead uses that mapfile when -shared is passed. When libtool adds -lgcc_s -lc -lgcc_s itself, it usually `optimizes' this into -lc -lgcc_s. When direct binding is in effect due to the mapfile, we achieve exactly what this patch intends to avoid, namely binding to the partial unwinder in amd64 libc. This can be avoided by patching libtool to disable this optimization on *solaris2*, which this patch does. While this works fine for the gcc runtime libraries, as can be observed with elfdump -y, gcc 4.9 cannot be released with this patch included: even if the libtool (ltmain.sh actually) patch were accepted upstream, every package built with libtool will contain an old copy without that change, causing the breakage this patch is designed to avoid. While the optimization can be avoided by invoking libtool with --preserve-dup-deps, this seem unacceptable, as would requiring users to run libtoolize from a hypothetical new libtool release with the ltmain.sh patch.
[Bug middle-end/59824] [4.9 Regression] r206418 miscompiles ffmpeg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59824 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Can you try the PR59747 fix http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00703.html first?
[Bug middle-end/59824] [4.9 Regression] r206418 miscompiles ffmpeg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59824 --- Comment #4 from Markus Trippelsdorf --- Created attachment 31842 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31842&action=edit -S output bad
[Bug middle-end/59824] [4.9 Regression] r206418 miscompiles ffmpeg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59824 --- Comment #3 from Markus Trippelsdorf --- Created attachment 31841 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31841&action=edit -S output good
[Bug rtl-optimization/59802] excessive compile time in RTL optimizers (loop unswitching, CPROP)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59802 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/59822] [4.9 Regression] ice in compute_live_loop_exits with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59822
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
typedef struct rtvec_def *rtvec;
enum machine_mode { VOIDmode };
struct rtvec_def { void *elem[1]; };
extern void *const_tiny_rtx[2];
void
ix86_build_const_vector (enum machine_mode mode, bool vect,
void *value, rtvec v, int n_elt)
{
int i;
for (i = 1; i < n_elt; ++i)
((v)->elem[i]) = vect ? value : (const_tiny_rtx[(int) (mode)]);
}
I will have a look.
[Bug target/59826] New: ICE caused by mishandling PLD rtx on ARM cortex-m4 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59826
Bug ID: 59826
Summary: ICE caused by mishandling PLD rtx on ARM cortex-m4
target
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: terry.guo at arm dot com
Created attachment 31840
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31840&action=edit
case to reproduce the ICE
When use upstream 4.8 gcc to compile attached case with command:
"arm-none-eabi-gcc -mthumb -fprefetch-loop-arrays crash.c -O2 -S
-mcpu=cortex-m4", we will get ICE:
crash.c: In function 'genxScrubText':
crash.c:32:1: internal compiler error: in reg_overlap_mentioned_p, at
rtlanal.c:1469
}
^
The option -fprefetch-loop-arrays causes gcc to generate rtx for ARM PLD
instruction like:
(insn 99 100 105 10 (prefetch (plus:SI (reg/v/f:SI 3 r3 [orig:143 last ] [143])
(const_int 34 [0x22]))
(const_int 0 [0])
(const_int 3 [0x3])) 343 {prefetch}
(nil))
When check data dependencies between this rtx and others, gcc mishandles it as
a normal SET rtx and thus end up with ICE.
Trunk gcc hasn't such issue due to code improvement at
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00533.html.
[Bug middle-end/59824] [4.9 Regression] r206418 miscompiles ffmpeg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59824 --- Comment #2 from Markus Trippelsdorf --- gcc --save-temps -g -I. -I./ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DHAVE_AV_CONFIG_H -std=c99 -fomit-frame-pointer -fPIC -pthread -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL -g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wno-maybe-uninitialized -MMD -MF libavcodec/mpeg4video.d -MT libavcodec/mpeg4video.o -c -o libavcodec/mpeg4video.o libavcodec/mpeg4video.c
[Bug c/59825] New: [4.9 Regression] Many cilkplus test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59825 Bug ID: 59825 Summary: [4.9 Regression] Many cilkplus test failures Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com On Linux/x86, revision 206621 gave: FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -fcilkplus -g -O0 -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -fcilkplus -g -O0 -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -fcilkplus -O2 -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -fcilkplus -O2 -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -fcilkplus -O3 -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -fcilkplus -O3 -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -fcilkplus -std=c99 (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -fcilkplus -std=c99 (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -fcilkplus (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -g -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -g -fcilkplus (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -g -O2 -ftree-vectorize -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -g -O2 -ftree-vectorize -fcilkplus (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -O1 -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -O1 -fcilkplus (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -O2 -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -O2 -fcilkplus (test for excess errors) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -O3 -fcilkplus (internal compiler error) FAIL: c-c++-common/cilk-plus/AN/rank_mismatch2.c -O3 -fcilkplus (test for excess errors) Revision 206615 is OK.
[Bug rtl-optimization/59811] [4.8/4.9 Regression] Huge increase in memory usage and compile time with gfortran 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59811 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.7.3 Keywords||compile-time-hog Last reconfirmed||2014-01-15 Component|fortran |rtl-optimization Ever confirmed|0 |1 Summary|Huge increase in memory |[4.8/4.9 Regression] Huge |usage and compile time with |increase in memory usage |gfortran 4.8|and compile time with ||gfortran 4.8 Target Milestone|--- |4.8.3 Known to fail||4.8.2, 4.9.0 --- Comment #1 from Richard Biener --- Confirmed. At -O2 I see for 4.8 alias stmt walking : 4.90 ( 8%) usr 0.02 ( 3%) sys 5.05 ( 8%) wall 0 kB ( 0%) ggc tree copy propagation : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 513 kB ( 0%) ggc combiner: 45.94 (71%) usr 0.57 (83%) sys 46.57 (71%) wall 1612812 kB (96%) ggc integrated RA : 0.59 ( 1%) usr 0.01 ( 1%) sys 0.58 ( 1%) wall 12481 kB ( 1%) ggc LRA hard reg assignment : 7.53 (12%) usr 0.03 ( 4%) sys 7.56 (11%) wall 0 kB ( 0%) ggc TOTAL : 65.03 0.6965.92 1681500 kB and for 4.7 alias stmt walking : 2.77 (28%) usr 0.02 (17%) sys 2.80 (28%) wall 0 kB ( 0%) ggc tree copy propagation : 1.64 (17%) usr 0.01 ( 8%) sys 1.67 (17%) wall 513 kB ( 1%) ggc integrated RA : 0.66 ( 7%) usr 0.02 (17%) sys 0.68 ( 7%) wall 6295 kB (10%) ggc reload : 0.45 ( 5%) usr 0.01 ( 8%) sys 0.46 ( 5%) wall 1593 kB ( 3%) ggc reload CSE regs : 0.74 ( 7%) usr 0.00 ( 0%) sys 0.75 ( 7%) wall 1103 kB ( 2%) ggc TOTAL : 9.87 0.1210.01 61922 kB the combiner slowdown and the LRA thing are worth investigating. I suppose the generated code differs quite a bit ;) It's a very large function with some very large basic-block(s). Current trunk behaves comparable to GCC 4.8.
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug testsuite/59808] [4.9 Regression] r206596 caused: FAIL: gcc.target/i386/sse-14.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59808 --- Comment #7 from Kirill Yukhin --- Author: kyukhin Date: Wed Jan 15 12:01:08 2014 New Revision: 206629 URL: http://gcc.gnu.org/viewcvs?rev=206629&root=gcc&view=rev Log: PR target/59808 * gcc.target/i386/sse-12.c: Add `-mavx512[cd, er, pf]' options. * gcc.target/i386/sse-14.c: Fix PR59808. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/sse-12.c trunk/gcc/testsuite/gcc.target/i386/sse-14.c
[Bug middle-end/59812] Missing aggressive loop optimization warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59812 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-15 Component|c |middle-end Version|unknown |4.9.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed.
[Bug tree-optimization/59817] ICE in extract_affine_chrec with -O2 -ftree-loop-linear
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59817
Richard Biener changed:
What|Removed |Added
Target|powerpc64-linux |
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-01-15
Ever confirmed|0 |1
Known to fail||4.8.2, 4.9.0
--- Comment #1 from Richard Biener ---
Also on x86_64. The CHREC is
{-(unsigned long) stride.2_13, +, (unsigned long) stride.2_13 + 1}_1
also fails on the 4.8 branch for me at least.
[Bug middle-end/59824] [4.9 Regression] r206418 miscompiles ffmpeg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59824 --- Comment #1 from Markus Trippelsdorf --- Created attachment 31839 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31839&action=edit miscompiled proprocessed file
[Bug middle-end/59824] New: [4.9 Regression] r206418 miscompiles ffmpeg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59824
Bug ID: 59824
Summary: [4.9 Regression] r206418 miscompiles ffmpeg
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Starting with r206418 ffmpeg gets miscompiled:
% mplayer movie.avi
...
Program received signal SIGSEGV, Segmentation fault.
ff_mpeg4_set_one_direct_mv (i=0, my=0, mx=0, s=0x5588e180) at
libavcodec/mpeg4video.c:111
111 s->mv[0][i][1] = s->direct_scale_mv[0][p_my + tab_bias] + my;
(gdb) bt
#0 ff_mpeg4_set_one_direct_mv (i=0, my=0, mx=0, s=0x5588e180) at
libavcodec/mpeg4video.c:111
#1 ff_mpeg4_set_direct_mv (s=s@entry=0x5588e180, mx=mx@entry=0, my=0) at
libavcodec/mpeg4video.c:172
#2 0x767e5f33 in mpeg4_decode_mb (s=0x5588e180,
block=0x55aa65c0) at libavcodec/mpeg4videodec.c:1580
#3 0x76655a44 in decode_slice (s=s@entry=0x5588e180) at
libavcodec/h263dec.c:238
#4 0x7665 in ff_h263_decode_frame (avctx=0x55887c80,
data=0x558879e0, got_frame=0x7fffcfd4, avpkt=) at
libavcodec/h263dec.c:587
#5 0x768ff5be in avcodec_decode_video2 (avctx=0x55887c80,
picture=0x558879e0, got_picture_ptr=0x7fffcfd4, avpkt=0x7fffd000)
at libavcodec/utils.c:2123
#6 0x556b061a in decode ()
#7 0x556012e4 in decode_video ()
#8 0x555a8a3d in update_video ()
#9 0x5559c494 in main ()
(gdb)
It looks like the following function (from libavcodec/mpeg4video.c) gets
miscompiled:
90 static inline void ff_mpeg4_set_one_direct_mv(MpegEncContext *s, int mx,
91 int my, int i)
92 {
93 int xy = s->block_index[i];
94 uint16_t time_pp = s->pp_time;
95 uint16_t time_pb = s->pb_time;
96 int p_mx, p_my;
97
98 p_mx = s->next_picture.motion_val[0][xy][0];
99 if ((unsigned)(p_mx + tab_bias) < tab_size) {
100 s->mv[0][i][0] = s->direct_scale_mv[0][p_mx + tab_bias] + mx;
101 s->mv[1][i][0] = mx ? s->mv[0][i][0] - p_mx
102 : s->direct_scale_mv[1][p_mx + tab_bias];
103 } else {
104 s->mv[0][i][0] = p_mx * time_pb / time_pp + mx;
105 s->mv[1][i][0] = mx ? s->mv[0][i][0] - p_mx
106 : p_mx * (time_pb - time_pp) / time_pp;
107 }
108 p_my = s->next_picture.motion_val[0][xy][1];
109 if ((unsigned)(p_my + tab_bias) < tab_size) {
110 s->mv[0][i][1] = s->direct_scale_mv[0][p_my + tab_bias] + my;
111 s->mv[1][i][1] = my ? s->mv[0][i][1] - p_my
112 : s->direct_scale_mv[1][p_my + tab_bias];
113 } else {
114 s->mv[0][i][1] = p_my * time_pb / time_pp + my;
115 s->mv[1][i][1] = my ? s->mv[0][i][1] - p_my
116 : p_my * (time_pb - time_pp) / time_pp;
117 }
118 }
When I put an "__attribute__ ((optimize(0)))" above it, ffmpeg no longer
crashes.
I will attach the proprocessed file.
[Bug c++/59818] [4.9 regression] Bogus error: call of overloaded .... is ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59818 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Known to work||4.8.2 Version|unknown |4.9.0 Blocks||23055 Target Milestone|--- |4.9.0
[Bug c++/59821] __builtin_LINE and __builtin_FILE for new'd objects is wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59821
Richard Biener changed:
What|Removed |Added
Keywords||wrong-debug
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-01-15
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
[t.C : 12:3] Foo::Foo ([t.C : 12] &D.2242, 12);
[t.C : 12:42] try
{
[t.C : 12:3] D.2247 = D.2242.line;
[t.C : 12:3] D.2244 = 5;
[t.C : 12:3] D.2243 = operator new (4);
[t.C : 12:3] try
{
[t.C : 12:3] Foo::Foo (D.2243, D.2244);
looks like location info is broken for the new case.
