[Bug c/66598] With -O3 gcc incorrectly assumes aligned SSE instructions (e.g. movapd) can be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- I can reproduce the SEGV with current gcc-6, 5, and 4.9, but not with 4.8 or 4.7. Dropping from -O3 to -O2 also prevents the SEGV.
[Bug target/66611] New: SH: ICE on -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66611
Bug ID: 66611
Summary: SH: ICE on -O2
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ysato at users dot sourceforge.jp
Target Milestone: ---
Created attachment 35819
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35819&action=edit
problem source code
$ LANG=C sh-unknown-linux-gcc -O2 -mb -m2 w83627ehf.c
w83627ehf.c: In function 'show_caseopen':
w83627ehf.c:24361:1: error: insn does not satisfy its constraints:
}
^
(insn 118 95 119 2 (set (reg:SI 1 r1)
(sign_extend:SI (mem:QI (plus:SI (reg/f:SI 8 r8 [175])
(const_int 12 [0xc])) [0 MEM[(struct
sensor_device_attribute_2 *)attr_6(D)].index+0 S1 A32]))) w83627ehf.c:24359 232
{*extendqisi2_compact_mem_disp}
(nil))
w83627ehf.c:24361:1: internal compiler error: in extract_constrain_insn, at
recog.c:2221
0x94aed8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/rtl-error.c:109
0x94aeff _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/rtl-error.c:120
0x9155f7 extract_constrain_insn(rtx_insn*)
../../gcc/recog.c:2221
0x918f86 copyprop_hardreg_forward_1
../../gcc/regcprop.c:800
0x919bed execute
../../gcc/regcprop.c:1290
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug target/65803] blackfin: internal compiler error: segment fault linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65803
--- Comment #3 from Chen Gang ---
It is about JUMP_LABEL, gcc should set the JUMP_LABEL before use it. If we set
the label as soon as it is generated, it can build the issue code successfully.
diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
index dc24ed5..b8c9567 100644
--- a/gcc/config/bfin/bfin.c
+++ b/gcc/config/bfin/bfin.c
@@ -3777,7 +3777,8 @@ hwloop_optimize (hwloop_info loop)
}
else
{
- emit_jump_insn (gen_jump (label));
+ rtx_insn * ret = emit_jump_insn (gen_jump (label));
+ JUMP_LABEL(ret) = label;
seq_end = emit_barrier ();
}
}
So we can say, it must be the direct cause (but may be not the root cause). I
shall continue analyzing: "why gcc did not set JUMP_LABEL before using it".
Welcome any others' ideas, suggestions and completions.
Thanks.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #18 from John Paul Adrian Glaubitz --- (In reply to Kazumoto Kojima from comment #17) > Which version of mpfr/gmp is used for compilers? mpfr has self > test and you could run it with "make check" in its build directory. You seem to be on to something here as, in fact, mpfr had problems previously when built with "make check" [1]: PASS: tcheck PASS: tisnan ../../test-driver: line 107: 5759 Segmentation fault "$@" > $log_file 2>&1 FAIL: texceptions PASS: tset_exp I have to admit that I recently disabled checks during builds on some buildds to speed up the build process and this may have triggered the whole dilemma. Assuming that mpfr would be the origin of this, would this also explain the segmentation faults in the recently compiled systemd package? Because apparently the systemd binaries crash because gcc has produced broken code here. Could it be possible that the compiler made some float calculation which gave a weird result, embedded that into systemd which in turns segfaults? Adrian > [1] > http://buildd.debian-ports.org/status/fetch.php?pkg=mpfr4&arch=sh4&ver=3.1.2-3&stamp=1425025691
[Bug tree-optimization/66610] Compound assignments prevent value-numbering optimization with unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66610 --- Comment #2 from David Malcolm --- Created attachment 35820 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35820&action=edit A less minimal example FWIW, here's a less minimal example, better showing what the code was doing (interpreter values were a union plus a type code). As in the previous example, fre2 is able to do this optimization of the copy of arr[1] to arr[0] when doing the copy field-wise: Replaced arr_6(D)->union_field.int_field with i_1 in all uses of _10 = arr_6(D)->union_field.int_field; Replaced arr_6(D)->type_code with 0 in all uses of _13 = arr_6(D)->type_code; turning the loop body into: : arr_6(D)->union_field.int_field = i_1; arr_6(D)->type_code = 0; MEM[(struct value *)arr_6(D) + 16B].union_field.int_field = i_1; MEM[(struct value *)arr_6(D) + 16B].type_code = 0; i_15 = i_1 + 1; allowing the loop to later be optimized away by cddce2.
[Bug target/65803] blackfin: internal compiler error: segment fault linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65803
--- Comment #4 from Chen Gang ---
Reference to gccint.pdf Page 268 for jump_isn, we know that JUMP_LABLE() must
be defined after optimization completed. In our case, we are just doing
optimization, and is almost finished, so we need set JUMP_LABLE() after emit
jump_insn.
The related diff is bellow:
diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c
index dc24ed5..0297b59 100644
--- a/gcc/config/bfin/bfin.c
+++ b/gcc/config/bfin/bfin.c
@@ -3777,7 +3777,10 @@ hwloop_optimize (hwloop_info loop)
}
else
{
- emit_jump_insn (gen_jump (label));
+ rtx_insn * ret = emit_jump_insn (gen_jump (label));
+
+ JUMP_LABEL(ret) = label;
+ LABEL_NUSES (label)++;
seq_end = emit_barrier ();
}
}
[Bug tree-optimization/66612] New: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612 Bug ID: 66612 Summary: [6 regrssion] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: amker at gcc dot gnu.org Blocks: 62173 Target Milestone: --- Target: powerpc64-*-* $ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.target/powerpc/20050830-1.c -O2 -S -m64 -o 20050830-1.s $ grep -c bdn 20050830-1.s 0 5fe66b3cf4fd9c8c68cea43aa1cf42eaa76d is the first bad commit commit 5fe66b3cf4fd9c8c68cea43aa1cf42eaa76d Author: amker Date: Tue Jun 2 03:33:35 2015 + git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@224009 138bc75d-0d04-0410-961f-82ee72b054a4 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62173 [Bug 62173] [5/6 Regression] 64bit Arch can't ivopt while 32bit Arch can
[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66612 Andreas Schwab changed: What|Removed |Added Target Milestone|--- |6.0 Summary|[6 regrssion] FAIL: |[6 regression] FAIL: |gcc.target/powerpc/20050830 |gcc.target/powerpc/20050830 |-1.c scan-assembler bdn |-1.c scan-assembler bdn
[Bug web/66104] svn co https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66104 --- Comment #2 from Jonathan Wakely --- Have you tried using a different svn client?
[Bug web/66104] svn co https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66104 --- Comment #3 from Jonathan Wakely --- Hmm, I get: svn: E000110: Error retrieving REPORT: Connection timed out
[Bug c++/66602] std::tuple bug when constructed with temporary empty object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66602 Jonathan Wakely changed: What|Removed |Added Status|WAITING |NEW Known to work||5.1.1, 6.0 Version|unknown |5.1.0 Known to fail||5.1.0 --- Comment #4 from Jonathan Wakely --- It also seems to be fixed in 5.1.1
[Bug web/66104] svn co https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66104 --- Comment #4 from Thomas Schweikle --- I've tried at least * subversion 1.7.x * subversion 1.8.x * the jenkins internal svn-client all behave the same.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #19 from Kazumoto Kojima --- (In reply to John Paul Adrian Glaubitz from comment #18) > You seem to be on to something here as, in fact, mpfr had problems > previously when built with "make check" [1]: I see many segfaults and bus errors in [1]. Clearly this mpfr is problematic to use in compiler. It might show some other problem of the compiler which was used to build mpfr, though I have no experience for such failures. Anyway your current mpfr looks broken and should be replaced with the sane one. > Assuming that mpfr would be the origin of this, would this also explain the > segmentation faults in the recently compiled systemd package? Because > apparently the systemd binaries crash because gcc has produced broken code > here. Could it be possible that the compiler made some float calculation > which gave a weird result, embedded that into systemd which in turns > segfaults? There is too little information to say something and there are many possibilities, I think.
[Bug c/66613] New: error in evaluationg cexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66613
Bug ID: 66613
Summary: error in evaluationg cexp
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ka_bena at yahoo dot fr
Target Milestone: ---
#include
#include
#include
int main(void)
{
printf( "\n");
printf("/**/\n");
printf( "\n");
printf( "SECTION 1 \n");
printf( "\n");
printf( " _Complex float zF = 1.F + 2.Fi ;\n");
_Complex float zF = 1.F + 2.Fi ;
printf( " crealf(cexpf(zF)) = %f \n" , crealf(cexpf(zF))) ;
printf( " cimagf(cexpf(zF)) = %f \n" , cimagf(cexpf(zF))) ;
printf( "\n");
printf( " _Complex double zD = 1.D + 2.Di ;\n");
_Complex double zD = 1.D + 2.Di ;
printf( " creal(cexp(zD))= %E \n" , creal(cexp(zD))) ;
printf( " cimag(cexp(zD))= %E \n" , cimag(cexp(zD))) ;
printf( " creal(cexp(1.D + 2.Di))= %f \n" , creal(cexp(1.D + 2.Di))) ;
printf( " cimag(cexp(1.D + 2.Di))= %f \n" , cimag(cexp(1.D + 2.Di))) ;
printf( "\n");
printf( " _Complex long double zL= 1.L + 2.Li\n");
_Complex long double zL = 1.L + 2.Li ;
printf( " creall(cexpl(zL)) = %lE \n" , creall(cexpl(zL))) ;
printf( " cimagl(cexpl(zL)) = %lE \n" , cimagl(cexpl(zL))) ;
printf( " creall(cexpl(1.L + 2.Li)) = %lf \n" , creall(cexpl(1.L + 2.Li)))
;
printf( " cimagl(cexpl(1.L + 2.Li)) = %lf \n" , cimagl(cexpl(1.L + 2.Li)))
;
printf( "\n");
printf( " __complex128 zQ= 1.Q + 2.Qi\n");
__complex128 zQ = 1.Q + 2.Qi ;
printf( " crealq(cexpq(zQ)) = %lf \n" , (long
double)crealq(cexpq(zQ))) ;
printf( " cimagq(cexpq(zQ)) = %lf \n" , (long
double)cimagq(cexpq(zQ))) ;
printf( "\n");
printf("/**/\n");
printf( "\n");
printf( "SECTION 2 \n");
printf( "\n");
float alfa = 1.f / 3.f ;
printf(" alfa = %-100.80f \n" , alfa) ;
printf(" sizeof(alfa))= %u\n" , sizeof(alfa)) ;
printf(" 1.f/3.f = %-100.80f \n" , 1.f/3.f) ;
printf(" sizeof(1.f/3.f)) = %u\n" , sizeof(1.f/3.f)) ;
printf( "\n");
printf("/**/\n");
printf( "\n");
return 0;
}
//-- Capture Output --
//> "E:\PAPA\test_gcc\C99\RUN_C\run_C99.bat" main_error_gcc481
//
//D:\gfortran\include>E:\PAPA\test_gcc\exe\main_error_gcc481_C99.exe
//
///**/
//
//SECTION 1
//
// _Complex float zF = 1.F + 2.Fi ;
// crealf(cexpf(zF)) = -1.131204
// cimagf(cexpf(zF)) = 2.471727
//
// _Complex double zD = 1.D + 2.Di ;
// creal(cexp(zD))= -3.730751E-144
// cimag(cexp(zD))= 6.752940E+268
// creal(cexp(1.D + 2.Di))= -1.131204
// cimag(cexp(1.D + 2.Di))= 2.471727
//
// _Complex long double zL= 1.L + 2.Li
// creall(cexpl(zL)) = -0.00E+000
// cimagl(cexpl(zL)) = 1.291636E+1644
// creall(cexpl(1.L + 2.Li)) = -1.131204
// cimagl(cexpl(1.L + 2.Li)) = 2.471727
//
// __complex128 zQ= 1.Q + 2.Qi
// crealq(cexpq(zQ)) = -1.131204
// cimagq(cexpq(zQ)) = 2.471727
//
///**/
//
//SECTION 2
//
// alfa =
0.333432674407958984375000
// sizeof(alfa))= 4
// 1.f/3.f =
0.1482961625624739099293947219848632812500
// sizeof(1.f/3.f)) = 4
//
///**/
//
//
//> Terminated with exit code 0.
[Bug target/66611] SH: ICE on -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66611 Oleg Endo changed: What|Removed |Added CC||kkojima at gcc dot gnu.org, ||olegendo at gcc dot gnu.org --- Comment #1 from Oleg Endo --- Basically, this is the same issure as PR 66358. Thanks for the additional test case.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #20 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #16) > ... > 763a3c: 03 61 mov r0,r1 > 763a3e: 00 e3 mov #0,r3 > 763a40: 16 62 mov.l @r1+,r2 > 763a42: 3c 22 cmp/str r3,r2 > 763a44: fc 8b bf 763a40 > ... That's a code snippet of the builtin strlen which has been added in 4.9... I'm curious... Kaz, when bootstrapping the native 4.9 on sh4-linux, did you use the 4.9 native compiler to build mpfr, mpc, gmp libraries? They might indeed be silently miscompiled due to some unknown hidden bug.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #21 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #20) > I'm curious... Kaz, when bootstrapping the native 4.9 on sh4-linux, did you > use the 4.9 native compiler to build mpfr, mpc, gmp libraries? They might > indeed be silently miscompiled due to some unknown hidden bug. No, I use always 'system' compiler to build these libraries. In this case, 4.6.3 is my native system compiler.
[Bug c/66598] With -O3 gcc incorrectly assumes aligned SSE instructions (e.g. movapd) can be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66598 --- Comment #2 from Mikael Pettersson --- Started with r197189.
[Bug fortran/66605] -Wunused-parameter causes internal compiler error with gfortran 5.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66605
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-06-20
CC||manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Manuel López-Ibáñez ---
The problem is that
0x6b9191 gfc_generate_function_code(gfc_namespace*)
/home/manuel/test1/pristine/gcc/fortran/trans-decl.c:6021
invokes code that may generate warnings from the middle-end (like
-Wunused-parameter), however, gfc_diagnostics_finish has not been called yet.
I don't know the Fortran FE well enough to decide whether
gfc_diagnostics_finish should be called earlier (or are fortran diagnostics
expected after this point?), or we should special case this call by using
something like:
Index: error.c
===
--- error.c (revision 224467)
+++ error.c (working copy)
@@ -1461,21 +1461,27 @@ gfc_errors_to_warnings (bool f)
{
warnings_not_errors = f;
}
void
-gfc_diagnostics_init (void)
+gfc_diagnostics_defaults (void)
{
diagnostic_starter (global_dc) = gfc_diagnostic_starter;
diagnostic_finalizer (global_dc) = gfc_diagnostic_finalizer;
diagnostic_format_decoder (global_dc) = gfc_format_decoder;
global_dc->caret_chars[0] = '1';
global_dc->caret_chars[1] = '2';
+}
+
+void
+gfc_diagnostics_init (void)
+{
pp_warning_buffer = new (XNEW (output_buffer)) output_buffer ();
pp_warning_buffer->flush_p = false;
pp_error_buffer = &(error_buffer.buffer);
pp_error_buffer->flush_p = false;
+ gfc_diagnostics_defaults ();
}
void
gfc_diagnostics_finish (void)
{
Index: trans-decl.c
===
--- trans-decl.c(revision 224467)
+++ trans-decl.c(working copy)
@@ -6016,11 +6016,15 @@ gfc_generate_function_code (gfc_namespac
the cgraph node for this function. */
if (!has_coarray_vars || flag_coarray != GFC_FCOARRAY_LIB)
(void) cgraph_node::create (fndecl);
}
else
-cgraph_node::finalize_function (fndecl, true);
+{
+ gfc_diagnostics_finish ();
+ cgraph_node::finalize_function (fndecl, true);
+ gfc_diagnostics_defaults ();
+}
gfc_trans_use_stmts (ns);
gfc_traverse_ns (ns, gfc_emit_parameter_debug_info);
if (sym->attr.is_main_program)
[Bug web/66104] svn co https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66104 --- Comment #5 from Thomas Schweikle --- Looks like you are using subversion 1.6.11 (r934486) for your server. The error is known. An upgrade would solve it. https://mail-archives.apache.org/mod_mbox/subversion-users/201307.mbox/%3c503643e3cdb1b140a24214c3484dce8c01689...@hwde-muc-ma-1.de.hyperwave.com%3E The server seems to respond with an incomplete XML document structure. Closing tags may be missing or not nested correctly: Missing: something EOD Incorrect nesting: Clients choke on these. In our case: the server isn't closing an open tag. Some clients respond with the error I gave. Some tell "Connection timed out" waiting on the closing tag. To successfully checkout sources we would have to find a client not choking on such malformed XML-Documents. I'am sure there are some around, but not at most halfway up to date distros. And it wouldn't make sense to install an old quite outdated subversion client if the recommended server version ist 1.8.13, the older supported version is 1.7.20 and your servers version ist at outdated unsupported 1.6.11 if the subverrsion website is correct: https://subversion.apache.org/download/ I think you might be best of upgrading your server to the latest available, recommended version.
[Bug web/66104] svn co https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66104 --- Comment #6 from Thomas Schweikle --- Looks like you are using subversion 1.6.11 (r934486) for your server. The error is known. An upgrade would solve it. https://mail-archives.apache.org/mod_mbox/subversion-users/201307.mbox/%3c503643e3cdb1b140a24214c3484dce8c01689...@hwde-muc-ma-1.de.hyperwave.com%3E The server seems to respond with an incomplete XML document structure. Closing tags may be missing or not nested correctly: Missing: something EOD Incorrect nesting: Clients choke on these. In our case: the server isn't closing an open tag. Some clients respond with the error I gave. Some tell "Connection timed out" waiting on the closing tag. To successfully checkout sources we would have to find a client not choking on such malformed XML-Documents. I'am sure there are some around, but not at most halfway up to date distros. And it wouldn't make sense to install an old quite outdated subversion client if the recommended server version ist 1.8.13, the older supported version is 1.7.20 and your servers version ist at outdated unsupported 1.6.11 if the subverrsion website is correct: https://subversion.apache.org/download/ I think you might be best of upgrading your server to the latest available, recommended version.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #22 from John Paul Adrian Glaubitz --- (In reply to Oleg Endo from comment #20) > (In reply to John Paul Adrian Glaubitz from comment #16) > > ... > > 763a3c: 03 61 mov r0,r1 > > 763a3e: 00 e3 mov #0,r3 > > 763a40: 16 62 mov.l @r1+,r2 > > 763a42: 3c 22 cmp/str r3,r2 > > 763a44: fc 8b bf 763a40 > > ... > > That's a code snippet of the builtin strlen which has been added in 4.9... That's strange. As Kaz has observed correctly, gcc always seems to segfault when it comes to float arithmetics as I posted in #7. Provided that you're right, how would a bug in strlen this explain that gcc always segfaults when it needs to do float arithmetics? Hmm. I will do some further testing with a downgraded libmpfr.
[Bug web/66104] svn co https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66104 --- Comment #7 from Thomas Schweikle --- If it wouldn't be possible to migrate up to 1.7.x or 1.8.x. 1.6.23 is the last version packaged of the 1.6-stream.
[Bug web/66104] svn co https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66104 --- Comment #8 from joseph at codesourcery dot com --- I think the server is using the standard subversion package from RHEL 6, not a local build.
[Bug rtl-optimization/66614] New: LRA might fail to eliminate dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66614
Bug ID: 66614
Summary: LRA might fail to eliminate dead code
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Hi,
I have GCC compiled with this local patch in rtx_addr_can_trap_p_1
that should print a warning, when invalid frame offsets are encounterd:
Index: rtlanal.c
===
--- rtlanal.c (revision 224708)
+++ rtlanal.c (working copy)
@@ -41,6 +41,7 @@ along with GCC; see the file COPYING3. If not see
#include "emit-rtl.h" /* FIXME: Can go away once crtl is moved to rtl.h. */
#include "addresses.h"
#include "rtl-iter.h"
+#include "tree-pass.h"
/* Forward declarations */
static void set_of_1 (rtx, const_rtx, void *);
@@ -430,7 +431,20 @@ rtx_addr_can_trap_p_1 (const_rtx x, HOST_WIDE_INT
if (FRAME_GROWS_DOWNWARD)
{
if (adj_offset < frame_offset || adj_offset + size - 1 >= 0)
- return 1;
+ {
+ HOST_WIDE_INT high_bound = STARTING_FRAME_OFFSET;
+ HOST_WIDE_INT low_bound = high_bound - get_frame_size ();
+ fprintf (stderr, "*** %s can trap: function=%s, pass=%s"
+ ", offset=%" PRId64 ", size=%" PRId64
+ ", low_bound=%" PRId64 ", high_bound=%"
PRId64 "\n",
+ x == frame_pointer_rtx ? "frame"
+ : x == hard_frame_pointer_rtx ? "fp"
+ : x == stack_pointer_rtx ? "sp" : "argp",
+ IDENTIFIER_POINTER (DECL_NAME
(current_function_decl)),
+ current_pass->name,
+ offset, size, low_bound, high_bound);
+ return 1;
+ }
}
else
{
That should not happen in ordinary code, like GCC itself.
BUT it does happen really often, when I boot-strap GCC it happens
almost 3.000 times alone in pass 2.
All these events happen in the reload pass.
As an example I debugged at builtins.c which emits 4 suspicious intructions:
*** frame can trap: function=fold_builtin_cbrt, pass=reload, offset=56, size=8,
low_bound=-64, high_bound=0
*** frame can trap: function=fold_builtin_cbrt, pass=reload, offset=48, size=8,
low_bound=-64, high_bound=0
*** frame can trap: function=fold_builtin_cbrt, pass=reload, offset=40, size=8,
low_bound=-64, high_bound=0
*** frame can trap: function=fold_builtin_cbrt, pass=reload, offset=32, size=8,
low_bound=-64, high_bound=0
I get this call stack:
#0 rtx_addr_can_trap_p_1 (x=0x76ecb348, offset=56, size=8, mode=DImode,
unaligned_mems=false) at ../../gcc-trunk/gcc/rtlanal.c:446
#1 0x00fc3fff in rtx_addr_can_trap_p_1 (x=0x740d9bb8, offset=0,
size=8, mode=DImode, unaligned_mems=false)
at ../../gcc-trunk/gcc/rtlanal.c:481
#2 0x00fc845b in may_trap_p_1 (x=0x740d9bd0, flags=0) at
../../gcc-trunk/gcc/rtlanal.c:2542
#3 0x00fc86b0 in may_trap_p_1 (x=0x72d07a08, flags=0) at
../../gcc-trunk/gcc/rtlanal.c:2620
#4 0x00fc8763 in may_trap_p (x=0x72d07a08) at
../../gcc-trunk/gcc/rtlanal.c:2639
#5 0x00e9e851 in process_bb_lives (bb=0x72c66478,
curr_point=@0x7fffd904: 123, dead_insn_p=true) at
../../gcc-trunk/gcc/lra-lives.c:697
#6 0x00ea0740 in lra_create_live_ranges_1 (all_p=true,
dead_insn_p=true) at ../../gcc-trunk/gcc/lra-lives.c:1261
#7 0x00ea0a22 in lra_create_live_ranges (all_p=true, dead_insn_p=true)
at ../../gcc-trunk/gcc/lra-lives.c:1326
#8 0x00e7d7f9 in lra (f=0x0) at ../../gcc-trunk/gcc/lra.c:2308
#9 0x00e272cb in do_reload () at ../../gcc-trunk/gcc/ira.c:5400
#10 0x00e27679 in (anonymous namespace)::pass_reload::execute
(this=0x2685070) at ../../gcc-trunk/gcc/ira.c:5571
#11 0x00f3c397 in execute_one_pass (pass=0x2685070) at
../../gcc-trunk/gcc/passes.c:2356
#12 0x00f3c5e1 in execute_pass_list_1 (pass=0x2685070) at
../../gcc-trunk/gcc/passes.c:2409
#13 0x00f3c612 in execute_pass_list_1 (pass=0x2683ff0) at
../../gcc-trunk/gcc/passes.c:2410
#14 0x00f3c64f in execute_pass_list (fn=0x7389ae70, pass=0x2680db0)
at ../../gcc-trunk/gcc/passes.c:2420
#15 0x00b10878 in cgraph_node::expand (this=0x73898310) at
../../gcc-trunk/gcc/cgraphunit.c:1934
#16 0x00b10ea9 in expand_all_functions () at
../../gcc-trunk/gcc/cgraphunit.c:2070
#17 0x00b119c0 in symbol_table::compile (this=0x76ecf0a8) at
../../gcc-trunk/gcc/cgraphunit.c:2423
#18 0x00b11bd4 in symbol_table::finalize_compilation_unit
(this=0x76ecf0a8) at ../../gcc-trunk/gcc/cgraphunit.c:2510
#19 0x0103c5
[Bug web/66104] svn co https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66104 --- Comment #9 from Thomas Schweikle --- You are right. I did not know it was RedHat/CentOS/OracleLinux/ScientificLinux. They all use this outdated svn-server. I'd checked against our own running svn-server: same error with newer subversion clients. There is a repository available holding newer subversion servers for RedHat derived distros: HowTo: http://tecadmin.net/install-subversion-1-8-on-centos-rhel/ Repo-GPG-Key: http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco I'll have a look at what to take care of migrating up to 1.8.13 from 1.6.11 tomorrow.
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #23 from John Paul Adrian Glaubitz --- It seems that Kaz was right. Downgrading libmpfr fixes the issue for me: glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ gcc wmfire.c -o wmfire.o $(pkg-config --cflags gdk-2.0) $(pkg-config --cflags libgtop-2.0) wmfire.c: In function ‘do_help’: wmfire.c:770:62: error: ‘VERSION’ undeclared (first use in this function) fprintf(stderr, "\nWmfire - Flaming Monitor Dock V %s\n\n", VERSION); ^ wmfire.c:770:62: note: each undeclared identifier is reported only once for each function it appears in glaubitz@tirpitz:~/debian/segfault-test/wmfire-1.2.4/src$ Adrian
[Bug target/66563] [4.9 Regression] ICE (segmentation fault) on sh4-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66563 --- Comment #24 from John Paul Adrian Glaubitz --- (In reply to John Paul Adrian Glaubitz from comment #23) > It seems that Kaz was right. Downgrading libmpfr fixes the issue for me: In order to test whether this problem is actually a result of a miscompilation bug in gcc, I suggest building mpfr from source with a current gcc-4.9 and then run "make check" and see if the segfaults reproduce on native hardware.
