[Bug tree-optimization/57343] [4.8/4.9 Regression] wrong code on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-05-21
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.8.1
Summary|wrong code on x86_64-linux |[4.8/4.9 Regression] wrong
|at -Os and above|code on x86_64-linux at -Os
||and above
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
Started with r193098 .
int c = 0;
int
main ()
{
int i, f = 1;
for (i = 0; i 5; i++)
{
--c;
unsigned char h = c * 100;
if (h == 0)
{
f = 0;
break;
}
}
if (f != 1)
__builtin_abort ();
return 0;
}
[Bug rtl-optimization/57347] [4.8/4.9 Regression] wrong code for bitfield on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57347
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-05-21
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.8.1
Summary|wrong code for bitfield on |[4.8/4.9 Regression] wrong
|x86_64-linux at -Os and |code for bitfield on
|above |x86_64-linux at -Os and
||above
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Started with r193298 .
struct S1 { int f0; int f1 : 10; int f2 : 13; };
int i;
int *j = i;
static void
foo (struct S1 s)
{
int *p;
int l[88];
int **pp = p;
*pp = l[1];
l[0] = 1;
*j = 1 s.f2;
}
int
main ()
{
struct S1 s = { 0, 0, 1 };
foo (s);
if (i != 1)
__builtin_abort ();
return 0;
}
[Bug target/57341] [4.8/4.9 Regression] wrong code on x86_64-linux at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-05-21
CC||jakub at gcc dot gnu.org
Target Milestone|--- |4.8.1
Summary|wrong code on x86_64-linux |[4.8/4.9 Regression] wrong
|at -O3 in 32-bit mode |code on x86_64-linux at -O3
||in 32-bit mode
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org ---
Started with r188667 . -m32 -O3 -msse is needed.
int a, d;
int *b = a, **c;
int
main ()
{
int e;
{
int f[4];
for (d = 0; d 4; d++)
f[d] = 1;
e = f[1];
}
int *g[28] = { };
*b = e;
c = g[0];
if (a != 1)
__builtin_abort ();
return 0;
}
[Bug fortran/57328] Missed optimization: Unable to vectorize Fortran min and max intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Bud Davis from comment #1) The floating point number makes it special in some way. My suspicion is that this is due to special handling for IEEE 754:2008, which requires that MAX (NaN, x) = MAX (x, NaN) = x MIN (NaN, x) = MIN (x, NaN) = x
[Bug c++/41933] [c++0x] lambdas and variadic templates don't work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41933
Akim Demaille akim.demaille at gmail dot com changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
--- Comment #9 from Akim Demaille akim.demaille at gmail dot com ---
Hi all,
For what it's worth, Wikipedia has a note about this G++ bug:
http://en.wikipedia.org/wiki/Variadic_template . Below, a test case that
passes with clang, but fails to compile with G++ 4.9.
#include iostream
struct pass
{
templatetypename ...T pass(T...) {}
};
template typename... T
void print(T... args)
{
pass{([]{ std::cout args std::endl; }(), 1)...};
}
int main()
{
print(1, 2, 3.4, '5');
}
$ g++-mp-4.9 -Wall var.cc -std=c++11
var.cc: In function 'void print(T ...)':
var.cc:11:54: error: expansion pattern '(lambda(), 1)' contains no argument
packs
pass{([]{ std::cout args std::endl; }(), 1)...};
^
var.cc: In instantiation of 'void print(T ...) [with T = {int, const char*,
double, char}]':
var.cc:16:25: required from here
var.cc:11:4: error: no matching function for call to
'pass::pass(brace-enclosed initializer list)'
pass{([]{ std::cout args std::endl; }(), 1)...};
^
var.cc:11:4: note: candidates are:
var.cc:5:27: note: templateclass ... T pass::pass(T ...)
templatetypename ...T pass(T...) {}
^
var.cc:5:27: note: template argument deduction/substitution failed:
var.cc:3:8: note: constexpr pass::pass(const pass)
struct pass
^
var.cc:3:8: note: no known conversion for argument 1 from 'type error' to
'const pass'
var.cc:3:8: note: constexpr pass::pass(pass)
var.cc:3:8: note: no known conversion for argument 1 from 'type error' to
'pass'
[Bug rtl-optimization/57321] [4.8/4.9 Regression] static function call miscompiled at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57321 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.8.1 Summary|static function call|[4.8/4.9 Regression] static |miscompiled at -Os and |function call miscompiled |above |at -Os and above --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Confirmed. Introduced with r193298, fixed on the trunk with r198540 and on the branch with r198737.
[Bug plugins/56754] some missing plugin headers during installation in gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754 Duncan Sands baldrick at gcc dot gnu.org changed: What|Removed |Added CC||baldrick at gcc dot gnu.org --- Comment #5 from Duncan Sands baldrick at gcc dot gnu.org --- Was there any feedback on this patch?
[Bug tree-optimization/57303] [4.7/4.8/4.9 Regression] struct miscompiled at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303
--- Comment #7 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 20 May 2013, glisse at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303
--- Comment #6 from Marc Glisse glisse at gcc dot gnu.org ---
I wonder if, in addition to fixing the sink pass, we should add an
optimization
like the following (it passes bootstrap+testsuite, but I am not so sure where
it should go and what it should look like exactly).
--- gimple-fold.c(revision 199093)
+++ gimple-fold.c(working copy)
@@ -1174,20 +1174,27 @@ fold_stmt_1 (gimple_stmt_iterator *gsi,
if ((commutative_tree_code (subcode)
|| commutative_ternary_tree_code (subcode))
tree_swap_operands_p (gimple_assign_rhs1 (stmt),
gimple_assign_rhs2 (stmt), false))
{
tree tem = gimple_assign_rhs1 (stmt);
gimple_assign_set_rhs1 (stmt, gimple_assign_rhs2 (stmt));
gimple_assign_set_rhs2 (stmt, tem);
changed = true;
}
+/* Remove *p = *p. */
+if (!inplace TREE_CODE_CLASS (subcode) == tcc_reference
+ operand_equal_p (lhs, gimple_assign_rhs1 (stmt), 0))
+ {
+gsi_remove (gsi, true);
+return true;
+ }
The obvious place would be dead store elimination. But beware that
the above, if not _literally_ being *p = *p can be changing the
effective type of the memory location and thus might be not dead
in terms of type-based aliasing rules (which basically means that
we need to do sth more clever than just removing the store).
[Bug middle-end/56988] ipa-cp incorrectly propagates a field of an aggregate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56988 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||dhazeghi at yahoo dot com --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- *** Bug 57321 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/57321] [4.8/4.9 Regression] static function call miscompiled at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57321 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Component|rtl-optimization|tree-optimization Resolution|FIXED |DUPLICATE --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue May 21 07:51:59 2013 New Revision: 199133 URL: http://gcc.gnu.org/viewcvs?rev=199133root=gccview=rev Log: PR tree-optimization/57321 * gcc.c-torture/execute/pr57321.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr57321.c Modified: trunk/gcc/testsuite/ChangeLog Author: jakub Date: Tue May 21 07:58:10 2013 New Revision: 199134 URL: http://gcc.gnu.org/viewcvs?rev=199134root=gccview=rev Log: PR tree-optimization/57321 * gcc.c-torture/execute/pr57321.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr57321.c Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog *** This bug has been marked as a duplicate of bug 56988 ***
[Bug tree-optimization/57349] New: ICE on 253.perlbmk with pgo after r198096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57349 Bug ID: 57349 Summary: ICE on 253.perlbmk with pgo after r198096 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: izamyatin at gmail dot com CC: rguenther at suse dot de Target: x86 Output: gcc -c -o perl.o -DSPEC_CPU2000_LP64 -DSPEC_CPU2000_LINUX_I386 -DSPEC_CPU2000_NEED_BOOL -DSPEC_CPU2000_GLIBC22-fprofile-use -O3 -ffast-math -funroll-loops perl.c Error from fdo_make_pass2 'specmake FDO=PASS2 build fdo_make_pass2.out 2 fdo_make_pass2.err': Unable to coalesce ssa_names 1 and 7 which are marked as MUST COALESCE. argc_1(ab) and argc_7(ab) perl.c: In function 'perl_parse': perl.c:630:1: internal compiler error: SSA corruption perl_parse(PerlInterpreter *sv_interp, void (*xsinit) (void), int argc, char **argv, char **env) ^ 0x9c56dd fail_abnormal_edge_coalesce ../../gcc/tree-ssa-coalesce.c:898 0x9c56dd coalesce_partitions ../../gcc/tree-ssa-coalesce.c:1200 0x9c56dd coalesce_ssa_name() ../../gcc/tree-ssa-coalesce.c:1337 0x97eaff remove_ssa_form ../../gcc/tree-outof-ssa.c:900 0x97eaff rewrite_out_of_ssa(ssaexpand*) ../../gcc/tree-outof-ssa.c:1133 0x5fdeca gimple_expand_cfg ../../gcc/cfgexpand.c:4541 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. specmake: *** [perl.o] Error 1 Issue seems related to http://gcc.gnu.org/ml/gcc/2013-05/msg00162.html. although I haven't managed to make reproducer so far
[Bug libstdc++/53631] [C++11] regex is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 Akim Demaille akim.demaille at gmail dot com changed: What|Removed |Added CC||akim.demaille at gmail dot com --- Comment #8 from Akim Demaille akim.demaille at gmail dot com --- Can't Boost people be asked if they'd donate their code? It is my understanding that it already happened, for instance for std::shared_ptr. Note that the current situation, imho, is very bad. Instead of a compile-time failure, we get something that behaves more or less randomly at runtime. This is really bad for GCC's karma, and shows in way too many StackOverflow questions for instance.
[Bug middle-end/57344] [4.8/4.9 Regression] wrong code with pragma pack(1) and -O1 on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57344 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-21 CC||jakub at gcc dot gnu.org Component|target |middle-end Target Milestone|--- |4.8.1 Summary|wrong code with pragma |[4.8/4.9 Regression] wrong |pack(1) and -O1 on x86 |code with pragma pack(1) ||and -O1 on x86 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Weird, bisect tells me this regressed with r186825, but that change wasn't a trunk change at all. *.optimized dump is the same, *.expand already looks buggy.
Could not open source file limits.h
Hi, I work at an engineering company. Here, we use a Linux host where are installed licenses of an engineering commercial software, called Abaqus. Abaqus has a make procedure, that makes executable programs using a user soubroutine source code, or the correspondent object file. Here, Abaqus makes use of icpc/ifort compiler to compile C/Fortran codes. So, I have an object file, and tried to 'make' it. The problem is that, apparently, during the make procedure, Abaqus needs to compile an internal source code, in C language, and icpc gives this error: /Could not open source file limits.h/ . Here goes a copy of the terminal: */ tm@master1:/data/users/tm abaqus make job=abqmain.o Abaqus JOB abqmain Begin Compiling User Post-Processing Program Fri 03 May 2013 02:47:38 PM CEST Compiling: /data/users/tm/main_6425.C icpc: Command line warning: ignoring option '-c'; no argument required /usr/include/limits.h(125): catastrophic error: could not open source file limits.h # include_next limits.h ^ compilation aborted for /data/users/tm/main_6425.C (code 4) Abaqus Error: Problem during compilation - /data/users/tm/main_6425.C The Abaqus Make execution procedure exited with errors/* According to the error message, the */usr/include/limits.h* file tries to include another *limits.h* file, but doesn't find it next in the search path. According to what I read, there should be another file at */usr/lib/gcc/*/*/include/limits.h*, and both really try to include each other. I searched for this other file, and what I found was */usr/lib64/gcc/x86_64-suse-linux/4.5/include-fixed/limits.h*. I am not experienced in C programming, so... From the commentaries in both limits.h files, I didn't understand firstly why icpc tries to include the limits.h file in gcc library. This is present at the */usr/include/limits.h*: #if defined __GNUC__ !defined _GCC_LIMITS_H_ /* `_GCC_LIMITS_H_' is what GCC's file defines. */ # include_next limits.h #endif If I am using icpc, why is *defined __GNUC__* true? Also, supposing it is right, why it doesn't find the other limits.h file? Thank you -- View this message in context: http://gcc.1065356.n5.nabble.com/Could-not-open-source-file-limits-h-tp939843.html Sent from the gcc - bugs mailing list archive at Nabble.com.
[Bug libstdc++/57336] [4.8/4.9 Regression] Cannot INVOKE a reference_wrapper around an abstract type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57336 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed. N.B. Daniel pointer out this was LWG 2017.
[Bug tree-optimization/57303] [4.7/4.8 Regression] struct miscompiled at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] struct |struct miscompiled at -O1 |miscompiled at -O1 and |and above |above --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue May 21 08:11:23 2013 New Revision: 199135 URL: http://gcc.gnu.org/viewcvs?rev=199135root=gccview=rev Log: 2013-05-21 Richard Biener rguent...@suse.de PR tree-optimization/57303 * tree-ssa-sink.c (statement_sink_location): Improve killing stmt detection and properly handle self-assignments. * gcc.dg/torture/pr57303.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr57303.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sink.c
Re: Could not open source file limits.h
This mailing list is for automated emails from our Bugzilla database, I suggest you send your mail to the gcc-help list instead.
[Bug libstdc++/57350] New: std::align missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350 Bug ID: 57350 Summary: std::align missing Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: potswa at mac dot com C++11 §20.6.5 [ptr.align] remains unimplemented. Several years ago I published what now appears to be a compliant implementation, but it was under the MIT license. Does that disqualify that code, or me, from submitting a patch? As pure, relatively agnostic pointer arithmetic it doesn't seem to fit into the other groups of functions specified for memory, which are implemented in various separate files.
[Bug libstdc++/53631] [C++11] regex is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 --- Comment #9 from Roger Leigh rleigh at debian dot org --- It would be better if regex did not exist at all until functional. If I do regular autoconf header checks, plus a check to make sure that the needed types can be instantiated, then these all succeed despite it being broken. I need to do additional tests on top of this to actually check if it's truly functional, and then fall back to boost::regex if not. No other standard library feature has (IME) needed such extra checking. Regards, Roger
[Bug libstdc++/57350] std::align missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350 --- Comment #1 from David Krauss potswa at mac dot com --- Oh, here's a link to my version: http://code.google.com/p/c-plus/source/browse/src/util.h#50
[Bug libstdc++/53631] [C++11] regex is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, we're well aware of all these problems. What I don't see is anyone proposing any useful solutions. If someone sends a patch to remove the regex header *without* removing exported symbols from libstdc++.so I'll happily review it, but I have other things to work on.
[Bug tree-optimization/57349] [4.9 Regression] ICE on 253.perlbmk with pgo after r198096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57349 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-05-21 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|ICE on 253.perlbmk with pgo |[4.9 Regression] ICE on |after r198096 |253.perlbmk with pgo after ||r198096 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I will have a look.
[Bug libstdc++/53631] [C++11] regex is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 --- Comment #11 from Akim Demaille akim.demaille at gmail dot com --- Sorry, I didn't mean to be harsh, and I did try to propose a solution. I can easily guess that there is no reason for it to be easy or even possible, but can't Boost people be asked if they'd contribute?
[Bug middle-end/57348] [TM] ICE for transaction expression in gimplify_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57348 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-21 Component|libitm |middle-end Summary|ICE for transaction |[TM] ICE for transaction |expression in gimplify_expr |expression in gimplify_expr Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug libstdc++/53631] [C++11] regex is unimplemented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- It's a possibility, but personally I have other things to work on.
[Bug rtl-optimization/57344] [4.7/4.8/4.9 Regression] wrong code with pragma pack(1) and -O1 on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57344 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |rtl-optimization Known to work||4.7.0 Target Milestone|4.8.1 |4.7.4 Summary|[4.8/4.9 Regression] wrong |[4.7/4.8/4.9 Regression] |code with pragma pack(1)|wrong code with pragma |and -O1 on x86 |pack(1) and -O1 on x86 Known to fail||4.7.1, 4.7.3, 4.8.0, 4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Bi-secting on the 4.7 branch should reveal the offending patch. Tree optimizers look good, so the issue is on the RTL or target side.
[Bug bootstrap/57340] [4.9 regression] stage2 miscompiles build/genconditions on armv5tel-linux-gnueabi breaking bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57340 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||armv5tel-linux-gnueabi Target Milestone|--- |4.9.0 Build||armv5tel-linux-gnueabi
[Bug tree-optimization/57337] [4.9 Regression] 416.gamess ICE on x86 after r199048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57337 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|416.gamess ICE on x86 after |[4.9 Regression] 416.gamess |r199048 |ICE on x86 after r199048
[Bug lto/57334] ICE: in input_gimple_stmt, at gimple-streamer-in.c:287
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I've seen this ICE before I think. else if (code == GIMPLE_LABEL) gcc_assert (emit_label_in_global_context_p (gimple_label_label (stmt)) || DECL_CONTEXT (gimple_label_label (stmt)) == fn-decl);
[Bug rtl-optimization/57344] [4.7/4.8/4.9 Regression] wrong code with pragma pack(1) and -O1 on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57344
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Yeah, the problem is definitely in store_split_bit_field.
One possible fix is:
--- gcc/expmed.c.jj2013-05-14 10:54:58.0 +0200
+++ gcc/expmed.c2013-05-21 10:54:59.707793889 +0200
@@ -1094,10 +1094,15 @@ store_split_bit_field (rtx op0, unsigned
thispos = (bitpos + bitsdone) % unit;
/* When region of bytes we can touch is restricted, decrease
- UNIT close to the end of the region as needed. */
+ UNIT close to the end of the region as needed.
+ Don't do this if op0 is a REG or SUBREG, there won't be any
+ data races on registers and the code assumes unit is
+ BITS_PER_WORD. */
if (bitregion_end
unit BITS_PER_UNIT
- bitpos + bitsdone - thispos + unit bitregion_end + 1)
+ bitpos + bitsdone - thispos + unit bitregion_end + 1
+ !REG_P (op0)
+ GET_CODE (op0) != SUBREG)
{
unit = unit / 2;
continue;
Another one I'm currently testing is just not assuming unit is BITS_PER_WORD in
the SUBREG/REG handling code, and another one a mixture of both.
I don't know if we can actually end up with a SUBREG of MEM, if yes, then the
above patch is wrong, because it could introduce a data race in that case. The
other fix on the other side might pessimize the case where we e.g. have a real
REG or SUBREG of some REG and store some bits in a first word and bitregion_end
tells us that we must not touch the last byte in the second word, but we need
to touch the rest. On REGs there should be no data races. So I'm probably
going with both changes together.
[Bug fortran/57328] Missed optimization: Unable to vectorize Fortran min and max intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Yes, you generally need -ffast-math here (or -ffinite-math-only at least).
[Bug tree-optimization/57326] Piecewise folding of operations on PHI nodes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57326 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-05-21 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. Something for tree-ssa-phiopt.c. PRE likely also computes this but does not transform (for some reason). Ah, it produces the first bit here translating _8 = _7 | _14 doesn't produce the desired result (too complex).
[Bug tree-optimization/57322] [4.9 Regression] Segfault at -O1 in build_and_add_sum
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57322 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c++/57319] [4.8 Regression]: bogus defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57319 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Target Milestone|--- |4.8.1
[Bug tree-optimization/57318] [4.9 Regression] optimizer takes several seconds on nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57318 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|optimizer takes several |[4.9 Regression] optimizer |seconds on nested loops |takes several seconds on ||nested loops --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- 4.8 compiles this to just main: .LFB0: .cfi_startproc movl$10, %eax movl$10, b(%rip) movl$10, a(%rip) movw%ax, u+4(%rip) ret
[Bug tree-optimization/57318] [4.9 Regression] optimizer takes several seconds on nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57318
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
BB: 5, after_exit: 0
size: 1 vol.0_11 ={v} v.f0;
Constant expression will be folded away.
obviously wrong. I have a patch.
[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.1 Summary|[4.8 regression] build |[4.8/4.9 regression] build |failure in libsanitizer |failure in libsanitizer
[Bug tree-optimization/57315] LTO and/or vectorizer performance regression on salsa20 core, 4.7-4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57315 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-* CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Please at least reproduce the core function as a separate compilable testcase here togehter with flags used for the build. Also please try to factor out LTO ...
[Bug tree-optimization/57330] [4.8/4.9 Regression] ICE: verify_gimple failed -O3 [tree-cfg.c:4792]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57330 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I'm having a look.
[Bug tree-optimization/57330] [4.8/4.9 Regression] ICE: verify_gimple failed -O3 [tree-cfg.c:4792]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57330 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- I have a simple patch.
[Bug tree-optimization/57343] [4.8/4.9 Regression] wrong code on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I'll have a look.
[Bug fortran/57328] Missed optimization: Unable to vectorize Fortran min and max intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) Yes, you generally need -ffast-math here (or -ffinite-math-only at least). SSE2 has an unord comparison instruction (aka isnan) though, so vectorizing the full version of min/max should still work, and be even more worth it than for the finite-only min/max... Maybe a target issue?
[Bug libstdc++/57350] std::align missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57350 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to David Krauss from comment #0) C++11 §20.6.5 [ptr.align] remains unimplemented. Several years ago I published what now appears to be a compliant implementation, but it was under the MIT license. Does that disqualify that code, or me, from submitting a patch? Not at all, nothing stops you (as the author) submitting it to the FSF under the GPL, but to accept it the FSF usually need a copyright asignment on file - do you have one?
[Bug fortran/57328] Missed optimization: Unable to vectorize Fortran min and max intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- But vectorization reorders the loop iterations, thus say if some value is sNaN, you'd get exceptions in different order. So, I'm afraid without -ffast-math you can vectorize this only if the user says that the order of iterations doesn't matter (say using OpenMP 4.0 #pragma omp simd or Cilk+ #pragma simd).
[Bug tree-optimization/57331] [4.9 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57331 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30150 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30150action=edit gcc49-pr57331.patch Untested fix.
[Bug rtl-optimization/57344] [4.7/4.8/4.9 Regression] wrong code with pragma pack(1) and -O1 on x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57344 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30151 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30151action=edit gcc49-pr57344.patch Untested fix.
[Bug debug/57351] New: ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 Bug ID: 57351 Summary: ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org CC: christian.bruel at st dot com Target: arm-none-eabi Created attachment 30152 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30152action=edit Preprocessed testcase Building newlib for arm-none-eabi fails after r199132 2013-05-21 Christian Bruel christian.br...@st.com * dwarf2out.c (multiple_reg_loc_descriptor): Use dbx_reg_number for spanning registers. LEAF_REG_REMAP is supported only for contiguous registers. Set register size out of the PARALLEL loop. with an ICE: $SRC/binutils/newlib/libc/stdlib/dtoa.c:862:1: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 } ^ 0x659a6e dbx_reg_number $SRC/gcc/gcc/dwarf2out.c:10507 0x6dc41c rest_of_handle_final $SRC/gcc/gcc/final.c:4393 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. I encounter the same ICE when trying to build libgfortran on arm-none-eabi. The attached testcase is reduced from there. I reproduced the ICE with flags -std=c99 -O2 -g on the testcase My cross compiler is configured with --with-fpu=neon-vfpv4 --with-float=hard --with-arch=armv7-a Thanks, Kyrill
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 chrbr at gcc dot gnu.org changed: What|Removed |Added CC||chrbr at gcc dot gnu.org --- Comment #1 from chrbr at gcc dot gnu.org --- looking at it
[Bug fortran/57328] Missed optimization: Unable to vectorize Fortran min and max intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization --- Comment #6 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #5) But vectorization reorders the loop iterations, thus say if some value is sNaN, you'd get exceptions in different order. So, I'm afraid without -ffast-math you can vectorize this only if the user says that the order of iterations doesn't matter (say using OpenMP 4.0 #pragma omp simd or Cilk+ #pragma simd). Ah, I was only thinking of quiet nans. -fno-signaling-nans should be enough though, no? (I checked and it doesn't help, which makes sense since it is the default) I think it is quite common to care about quiet nans but not use signaling nans.
[Bug lto/57289] [4.9 Regression] ICE during 454.calculix compilation with -O3 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57289 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-05/msg01147.htm ||l --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org --- Proposed fix submitted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01147.html
[Bug c++/57352] New: internal compiler error in cp_parser_abort_tentative_parse at cp/parser.c:22878
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57352
Bug ID: 57352
Summary: internal compiler error in
cp_parser_abort_tentative_parse at cp/parser.c:22878
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
gcc 4.7.2 crashes on the following code:
struct x
{
operator class {} ();
};
With error message:
13.cpp:3:21: internal compiler error: in cp_parser_abort_tentative_parse, at
cp/parser.c:22878
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/57341] [4.8/4.9 Regression] wrong code on x86_64-linux at -O3 in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||matz at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Seems validate_equiv_mem_from_store during update_equiv_regs calls true_dependence to find out if it is safe to use it as equiv, and true_dependence is called with x being (mem/c:SI (plus:SI (reg/f:SI 20 frame) (const_int -108 [0xff94])) [3 f+4 S4 A32]) and mem being (mem/c:BLK (reg:SI 64) [2 g+0 S112 A128]) and returns 0 because the alias sets weren't properly adjusted.
[Bug tree-optimization/57343] [4.8/4.9 Regression] wrong code on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu.org
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
The value C is equal to final - base, where final and base are the final and
initial value of the actual induction variable in the analysed loop. BNDS
bounds the value of this difference when computed in signed type with
unbounded range, while the computation of C is performed in an unsigned
type with the range matching the range of the type of the induction
variable.
In particular, BNDS.up contains an upper bound on C in the following cases:
-- if the iv must reach its final value without overflow, i.e., if
NO_OVERFLOW EXIT_MUST_BE_TAKEN is true, or
-- if final = base, which we know to hold when BNDS.below = 0. */
static void
number_of_iterations_ne_max (mpz_t bnd, bool no_overflow, tree c, tree s,
bounds *bnds, bool exit_must_be_taken)
{
double_int max;
mpz_t d;
bool bnds_u_valid = ((no_overflow exit_must_be_taken)
|| mpz_sgn (bnds-below) = 0);
for the case in question (IV of unsigned char type, base
((unsigned char) (c_lsm.4_12 + -1)) * 100 and step 100 (negated 156))
the bnds values (below 0, up 255 - full range of unsigned char) the
fact that the IV overflows cannot be simply ignored - and I don't see
how we can derive from below = 0 that final (which is zero!) is
= base.
We then fall to
if (multiple_of_p (TREE_TYPE (c), c, s))
{
/* If C is an exact multiple of S, then its value will be reached before
the induction variable overflows (unless the loop is exited in some
other way before). Note that the actual induction variable in the
loop (which ranges from base to final instead of from 0 to C) may
overflow, in which case BNDS.up will not be giving a correct upper
bound on C; thus, BNDS_U_VALID had to be computed in advance. */
no_overflow = true;
exit_must_be_taken = true;
which ends up with no_overflow = true and things going downhill from here.
Note that the original, non-negated bnds would _not_ have mpz_sgn (bnds-below)
= 0 (but -255):
/* Rearrange the terms so that we get inequality S * i C, with S
positive. Also cast everything to the unsigned type. If IV does
not overflow, BNDS bounds the value of C. Also, this is the
case if the computation |FINAL - IV-base| does not overflow, i.e.,
if BNDS-below in the result is nonnegative. */
if (tree_int_cst_sign_bit (iv-step))
{
s = fold_convert (niter_type,
fold_build1 (NEGATE_EXPR, type, iv-step));
c = fold_build2 (MINUS_EXPR, niter_type,
fold_convert (niter_type, iv-base),
fold_convert (niter_type, final));
bounds_negate (bnds);
Here |FINAL - IV-base| does overflow, but bounds_negate shadows this.
But even before that we have IVCANON remove the pointless exit
Removed pointless exit: if (i_11 = 4)
Added canonical iv to loop 1, 3 iterations.
then it adds back the canonical IV, but that's pointless in the next
analysis run done by cunroll and removed there.
The bogus upper bound is determined from local_pure_const via finite_loop_p ()
on the non-header-copied form and the estimate from the h == 0 test.
Analyzing # of iterations of loop 1
exit condition [(unsigned char) (c_6 + -1) * 100, + , 156] != 0
bounds on difference of bases: -255 ... 0
result:
# of iterations (((unsigned char) (c_6 + -1) * 100) /[ex] 4) * 41 63,
bounded by 2
In the end I think that number_of_iterations_ne_max does not properly
honor the case where for
if (multiple_of_p (TREE_TYPE (c), c, s))
{
/* If C is an exact multiple of S, then its value will be reached before
the induction variable overflows (unless the loop is exited in some
other way before). Note that the actual induction variable in the
loop (which ranges from base to final instead of from 0 to C) may
overflow, in which case BNDS.up will not be giving a correct upper
bound on C; thus, BNDS_U_VALID had to be computed in advance. */
no_overflow = true;
that multiply overflows. At least the IV does not range from 0 to C
for (unsigned char) (c_6 + -1) * 100.
I have a hard time following the logic that this all is correct for
wrapping IVs ... that said,
Index: gcc/tree-ssa-loop-niter.c
===
--- gcc/tree-ssa-loop-niter.c (revision 199137)
+++ gcc/tree-ssa-loop-niter.c (working copy)
@@ -627,7 +627,7 @@ number_of_iterations_ne (tree type, affi
not overflow, BNDS bounds the value of C. Also, this is the
case
[Bug tree-optimization/57330] [4.8 Regression] ICE: verify_gimple failed -O3 [tree-cfg.c:4792]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57330 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.8/4.9 Regression] ICE: |[4.8 Regression] ICE: |verify_gimple failed -O3|verify_gimple failed -O3 |[tree-cfg.c:4792] |[tree-cfg.c:4792] Known to fail|4.9.0 | --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue May 21 11:56:57 2013 New Revision: 199139 URL: http://gcc.gnu.org/viewcvs?rev=199139root=gccview=rev Log: 2013-05-21 Richard Biener rguent...@suse.de PR tree-optimization/57330 * cgraph.c (cgraph_redirect_edge_call_stmt_to_callee): Properly preserve the call stmts fntype. * gcc.dg/torture/pr57330.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr57330.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/57318] [4.9 Regression] optimizer takes several seconds on nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57318 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue May 21 11:59:28 2013 New Revision: 199140 URL: http://gcc.gnu.org/viewcvs?rev=199140root=gccview=rev Log: 2013-05-21 Richard Biener rguent...@suse.de PR tree-optimization/57318 * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Do not estimate stmts with side-effects as likely eliminated. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivcanon.c Fixed - latent on the branch though.
[Bug tree-optimization/57343] [4.8/4.9 Regression] wrong code on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
Index: gcc/tree-ssa-loop-niter.c
===
--- gcc/tree-ssa-loop-niter.c (revision 199137)
+++ gcc/tree-ssa-loop-niter.c (working copy)
@@ -627,7 +627,7 @@ number_of_iterations_ne (tree type, affi
not overflow, BNDS bounds the value of C. Also, this is the
case if the computation |FINAL - IV-base| does not overflow, i.e.,
if BNDS-below in the result is nonnegative. */
- if (tree_int_cst_sign_bit (iv-step))
+ if (tree_int_cst_sgn (iv-step) == -1)
{
s = fold_convert (niter_type,
fold_build1 (NEGATE_EXPR, type, iv-step));
fixes the testcase (otherwise untested).
Doesn't work and fails bootstrap.
[Bug rtl-optimization/57347] [4.8/4.9 Regression] wrong code for bitfield on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57347 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- I don't find code in http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00460.html to handle bitfields, the comment talks about punting on them, but I couldn't find anything that would try to punt. ipa_load_from_parm_agg_1 seems to return just the bit offset (which is then compared to the offsets in aggval chain), but not the access bitsize (if aggval is guaranteed to contain values for all fields, then perhaps with bitsize it would be enough to look for all v where v-offset is in [offset, offset+bitsize) and combine all those values together - is v-value always constant?).
[Bug tree-optimization/57318] [4.9 Regression] optimizer takes several seconds on nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57318 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Richard Biener from comment #4) Fixed Thanks. Is the slowness of the sched2 pass tracked elsewhere? Or is that a normal speed for many volatile ops?
[Bug tree-optimization/57318] [4.9 Regression] optimizer takes several seconds on nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57318 --- Comment #6 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 21 May 2013, glisse at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57318 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Richard Biener from comment #4) Fixed Thanks. Is the slowness of the sched2 pass tracked elsewhere? Or is that a normal speed for many volatile ops? It's dependence computation, thus known.
[Bug libgcc/57353] New: unrecognizable insn in decLibrary.c, ICE in extract_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57353 Bug ID: 57353 Summary: unrecognizable insn in decLibrary.c, ICE in extract_insn Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: stigge at antcom dot de Created attachment 30153 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30153action=edit debug file from ICE Subject: unrecognizable insn in decLibrary.c, ICE in extract_insn Hi, on Debian's powerpcspe (i.e. powerpc e500v2, gnuspe), I encountered the following while building the latest gcc snapshot: ... /home/ernie/gcc-snapshot-20130509/build/./gcc/xgcc -B/home/ernie/gcc-snapshot-20130509/build/./gcc/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnuspe/bin/ -B/usr/lib/gcc-snapshot/powerpc-linux-gnuspe/lib/ -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnuspe/include -isystem /usr/lib/gcc-snapshot/powerpc-linux-gnuspe/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc -I../../../src/libgcc -I../../../src/libgcc/. -I../../../src/libgcc/../gcc -I../../../src/libgcc/../include -I../../../src/libgcc/../libdecnumber/dpd -I../../../src/libgcc/../libdecnumber -DHAVE_CC_TLS -o decDouble.o -MT decDouble.o -MD -MP -MF decDouble.dep -c ../../../src/libgcc/../libdecnumber/decDouble.c ../../../src/libgcc/../libdecnumber/decLibrary.c: In function 'isinfd64': ../../../src/libgcc/../libdecnumber/decLibrary.c:60:1: error: unrecognizable insn: } ^ (insn 2 4 3 2 (set (reg/v:DD 125 [ arg ]) (reg:DD 3 3 [ arg ])) ../../../src/libgcc/../libdecnumber/decLibrary.c:53 -1 (nil)) ../../../src/libgcc/../libdecnumber/decLibrary.c:60:1: internal compiler error: in extract_insn, at recog.c:2154 0x1086917f _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) ../../src/gcc/rtl-error.c:109 0x108691d3 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) ../../src/gcc/rtl-error.c:117 0x10801bd7 extract_insn(rtx_def*) ../../src/gcc/recog.c:2154 0x10573667 instantiate_virtual_regs_in_insn ../../src/gcc/function.c:1561 0x105752c3 instantiate_virtual_regs ../../src/gcc/function.c:1926 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See file:///usr/share/doc/gcc-snapshot/README.Bugs for instructions. Preprocessed source stored into /tmp/ccLwS90V.out file, please attach this to your bugreport. make[5]: *** [decLibrary.o] Error 1 make[5]: *** Waiting for unfinished jobs make[5]: Leaving directory `/home/ernie/gcc-snapshot-20130509/build/powerpc-linux-gnuspe/libgcc' make[4]: *** [all-stage1-target-libgcc] Error 2 make[4]: Leaving directory `/home/ernie/gcc-snapshot-20130509/build' ... Attaching the cited debug file ccLwS90V.out Thanks in advance, Roland
[Bug fortran/57354] New: Wrong run-time assignment of allocatable array of derived type with allocatable component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57354 Bug ID: 57354 Summary: Wrong run-time assignment of allocatable array of derived type with allocatable component Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com Created attachment 30154 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30154action=edit realloc.f90 source: type t integer,allocatable :: i end type type(t) :: e type(t), allocatable :: a(:) do i=1,100 e%i = i if (.not.allocated(a)) then a = [e] else a = [a, e] end if end do print *, (a(i)%i, i=1,size(a)) end gcc version 4.8.1 20130509 (prerelease) (GCC) expected result: 1,2..100 actual result: gfortran realloc.f90 ./a.out 323386243233856032338496323384323233836832338304 323382403233817632338112323380483233792032337856 323377923233772832337664323376003233753632337472 323380163233795232337232323371683233710432337040 323369763233740832337344323368163233675232336688 323366243233609632336032323359683233691232336512 323364483233638432336352323362883233622432335872 323361603233568032335248323348643233452832334240 323339523233388832333952323342403233452832334864 323352483233568032336160323358723233622432336288 323363523233638432336448323365123233691232335968 323360323233609632336624323366883233675232336816 323373443233740832336976323370403233710432337168 323372323233795232338016323374723233753632337600 323376643233772832337792323378563233792032338048 323381123233817632338240323383043233836832338432 323384963233856032338624 100 (the garbage differs on each run)
[Bug fortran/57354] Wrong run-time assignment of allocatable array of derived type with allocatable component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57354 --- Comment #1 from Vladimir Fuka vladimir.fuka at gmail dot com --- valgrind ./a.out ==17600== Memcheck, a memory error detector ==17600== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==17600== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==17600== Command: ./a.out ==17600== ==17600== Invalid read of size 4 ==17600==at 0x4012A0: MAIN__ (realloc.f90:15) ==17600==by 0x40159A: main (realloc.f90:22) ==17600== Address 0x5c4e4a0 is 0 bytes inside a block of size 4 free'd ==17600==at 0x4C2AF6C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==17600==by 0x401181: MAIN__ (realloc.f90:15) ==17600==by 0x40159A: main (realloc.f90:22) ==17600== 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 ==17600== ==17600== HEAP SUMMARY: ==17600== in use at exit: 0 bytes in 0 blocks ==17600== total heap usage: 5,372 allocs, 5,372 frees, 116,676 bytes allocated ==17600== ==17600== All heap blocks were freed -- no leaks are possible ==17600== ==17600== For counts of detected and suppressed errors, rerun with: -v ==17600== ERROR SUMMARY: 4950 errors from 1 contexts (suppressed: 2 from 2)
[Bug plugins/57355] New: -march=native ivy bridge i5 shows tuning for sandy bridge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57355 Bug ID: 57355 Summary: -march=native ivy bridge i5 shows tuning for sandy bridge Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: croutch at gmail dot com
[Bug plugins/56754] some missing plugin headers during installation in gcc 4.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754 --- Comment #6 from PaX Team pageexec at freemail dot hu --- (In reply to Duncan Sands from comment #5) Was there any feedback on this patch? sadly, no response so far (this bug is still UNCONFIRMED even), so it's probably not going to make 4.8.1.
[Bug target/57355] -march=native ivy bridge i5 shows tuning for sandy bridge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57355 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|plugins |target --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- ivy bridge is a sandy bridge with small improvements IIRC.
[Bug target/57355] -march=native ivy bridge i5 shows tuning for sandy bridge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57355
--- Comment #2 from croutch croutch at gmail dot com ---
I have a.
Intel Core i5 3570K 3,4Ghz (Ivy Bridge)
I use gentoo linux with gcc 4.7.3 and those settings.
CFLAGS=-march=native -O2 -pipe
CXXFLAGS=${CFLAGS}
MAKEOPTS=-j4
From manual.
core-avx-i = for ivy bridge
Intel Core CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
SSE4.2, AVX, AES, PCLMUL, FSGSBASE, RDRND and F16C instruction set support.
When i use this command i get this output.
$ gcc -c -Q -march=native --help=target | grep march
-march=corei7-avx
for sandy bridge?
And this command shows .
echo | gcc -march=native -v -E - 21 | grep cc1
/usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.1/cc1 -E -quiet -v - -march=corei7-avx
-mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma
-mno-fma4 -mno-xop
-mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt
-mrdrnd -mf16c -mfsgsbase --param l1-cache-size=32 --param
l1-cache-line-size=64 --param l2-cache-size=6144 -mtune=generic
I thougth CFLAGS=-march=native -O2 -pipe should enable most of this -
core-avx-i in gcc 4.7 with ivy bridge?? not for sandy bridge??
I found same problems in many linux forums.
Here are one with a included patch -
https://bbs.archlinux.org/viewtopic.php?id=156282
Link to patch https://github.com/crondog/misc-patches
[Bug target/57355] -march=native ivy bridge i5 shows tuning for sandy bridge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57355 --- Comment #3 from croutch croutch at gmail dot com --- Created attachment 30155 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30155action=edit gcc-native-ivy-detect This patch is not from me and not tested by me.
[Bug c++/57352] internal compiler error in cp_parser_abort_tentative_parse at cp/parser.c:22878
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57352 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Most likely related to PR51908
[Bug c/57356] New: gcc-4.8: SSE2 instructions generated with '-mno-sse2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57356
Bug ID: 57356
Summary: gcc-4.8: SSE2 instructions generated with '-mno-sse2'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
The following example shows a defect in gcc 4.8 when using the
'-mno-sse2' command line option: SSE2 instructions are still
generated.
Compile with:
gcc-4.8 -m64 -O1 -mno-sse2 -c -o /tmp/gungla.o /tmp/gungla.c
Sample Code:
typedef struct s128 {
char x[16];
} s128;
typedef struct wrapper {
s128 elem;
} wrapper;
void test2(s128 *);
void
test(wrapper **p, int *num)
{
int i;
s128 *a = (*p)-elem;
s128 b = *a;
for (i = 1; i *num; i++) {
test2(a);
if (i == 10) {
*a = b;
break;
}
}
if (p) {
*p = 0;
}
}
We have not been able to simplify this code any further.
Disassembly of section .text:
test:
0:41 56push %r14
2:41 55push %r13
4:41 54push %r12
6:55 push %rbp
7:53 push %rbx
8:48 83 ec 10 sub$0x10,%rsp
c:49 89 fe mov%rdi,%r14
f:48 89 f5 mov%rsi,%rbp
12:4c 8b 2f mov(%rdi),%r13
-- 15:f3 41 0f 6f 45 00movdqu 0x0(%r13),%xmm0
-- 1b:66 0f 7f 04 24 movdqa %xmm0,(%rsp)
20:83 3e 01 cmpl $0x1,(%rsi)
23:7f 32jg 57 test+0x57
25:eb 22jmp49 test+0x49
27:4c 89 e7 mov%r12,%rdi
2a:e8 00 00 00 00 callq 2f test+0x2f
2b: R_X86_64_PC32test2-0x4
2f:83 fb 0a cmp$0xa,%ebx
32:75 0djne41 test+0x41
34:66 0f 6f 0c 24 movdqa (%rsp),%xmm1
39:f3 41 0f 7f 4d 00movdqu %xmm1,0x0(%r13)
3f:eb 08jmp49 test+0x49
41:83 c3 01 add$0x1,%ebx
44:39 5d 00 cmp%ebx,0x0(%rbp)
47:7f dejg 27 test+0x27
49:4d 85 f6 test %r14,%r14
4c:74 1bje 69 test+0x69
4e:49 c7 06 00 00 00 00 movq $0x0,(%r14)
55:eb 12jmp69 test+0x69
57:4d 89 ec mov%r13,%r12
5a:4c 89 ef mov%r13,%rdi
5d:e8 00 00 00 00 callq 62 test+0x62
5e: R_X86_64_PC32test2-0x4
62:bb 01 00 00 00 mov$0x1,%ebx
67:eb d8jmp41 test+0x41
69:48 83 c4 10 add$0x10,%rsp
6d:5b pop%rbx
6e:5d pop%rbp
6f:41 5cpop%r12
71:41 5dpop%r13
73:41 5epop%r14
75:c3 retq
One oddity is that using '-mno-sse', the offending instructions are
not generated. (Maybe this implies that the instructions are simply
misclassified as SSE, rather than SSE2?)
gcc-4.7 does not exhibit the problem with the same code.
Can you folks please confirm, or refute, if gcc-4.7 suffers from the
same defect?
Possibly related to bug 46716.
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #2 from chrbr at gcc dot gnu.org --- Created attachment 30156 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30156action=edit patch
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #3 from chrbr at gcc dot gnu.org --- Under test.
[Bug c/57357] New: Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357
Bug ID: 57357
Summary: Error with '-mno-sse' and include wchar.h
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: thutt at vmware dot com
The following example shows a defect in gcc 4.8 when using the
'-mno-sse' command line option: an error is reported when including
wchar.h.
Compile with:
gcc-4.8 -m64 -O1 -mno-sse -c -o /tmp/gungla.o /tmp/gungla.c
Sample Code:
#include wchar.h
Sample Output:
In file included from /tmp/gungla.c:1:0:
/opt/gcc-4.8.0/lib/gcc/x86_64-linux5.0/4.8.0/include-fixed/wchar.h: In
function 'wcstod':
/opt/gcc-4.8.0/lib/gcc/x86_64-linux5.0/4.8.0/include-fixed/wchar.h:563:1:
error: SSE register return with SSE disabled
{ return __wcstod_internal (__nptr, __endptr, 0); }
^
[Bug rtl-optimization/57347] [4.8/4.9 Regression] wrong code for bitfield on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57347 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- Right, even though IPA-CP was intended to ignore bit-fields, this testcase shows there are quite good reasons to do so, but apparently I somehow lost or forgot to add the code to actually check for this. For 4.8 we do want to ignore bit-fields for sure. And I'd argue that we should do it on trunk too. Once we implement the plan to lower bit-fields early, jump functions will automatically start working on bit-fields too. Let me prepare a patch that adds the punting.
[Bug lto/57289] [4.9 Regression] ICE during 454.calculix compilation with -O3 -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57289 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Tue May 21 13:49:30 2013 New Revision: 199145 URL: http://gcc.gnu.org/viewcvs?rev=199145root=gccview=rev Log: 2013-05-21 Martin Jambor mjam...@suse.cz PR lto/57289 * ipa-prop.c (ipa_read_node_info): Process param_used and controlled_uses in the same order as when writing. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #4 from ktkachov at gcc dot gnu.org --- hmmm... now I'm getting a different ICE: internal compiler error: in arm_dbx_register_number, at config/arm/arm.c:25834 a gcc_unreachable () is reached. If I print out the regno argument to arm_dbx_register_number, it's 272 which seem to me like it could be reg number in DWARF numbering?
[Bug tree-optimization/57349] [4.9 Regression] ICE on 253.perlbmk with pgo after r198096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57349
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Reduced testcase, fails with -O -fbranch-probabilities
struct __jmp_buf_tag { };
typedef struct __jmp_buf_tag jmp_buf[1];
typedef struct cop COP;
typedef struct gv GV;
struct cop {
GV * cop_filegv;
};
struct jmpenv {
jmp_buf je_buf;
int je_ret;
};
typedef struct jmpenv JMPENV;
extern char * PL_origfilename;
extern COP * volatile PL_curcop ;
static void open_script() {
PL_curcop-cop_filegv = Perl_gv_fetchfile(PL_origfilename);
}
int perl_parse(char **argv) {
char *scriptname = ((void *)0);
char *validarg = ;
JMPENV cur_env;
int fdscript = -1;
cur_env.je_ret = _setjmp (((cur_env.je_buf)));
if (!scriptname) scriptname = argv[0];
open_script();
validate_suid(validarg, scriptname,fdscript);
}
[Bug tree-optimization/57303] [4.7/4.8 Regression] struct miscompiled at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57303
--- Comment #9 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #7)
On Mon, 20 May 2013, glisse at gcc dot gnu.org wrote:
+/* Remove *p = *p. */
+if (!inplace TREE_CODE_CLASS (subcode) == tcc_reference
+ operand_equal_p (lhs, gimple_assign_rhs1 (stmt), 0))
+ {
+gsi_remove (gsi, true);
+return true;
+ }
The obvious place would be dead store elimination. But beware that
the above, if not _literally_ being *p = *p can be changing the
effective type of the memory location and thus might be not dead
in terms of type-based aliasing rules (which basically means that
we need to do sth more clever than just removing the store).
So operand_equal_p on a tcc_reference is not enough? Aliasing is complicated, I
guess I'll open a PR about this optimization.
[Bug tree-optimization/53991] _mm_popcnt_u64 fails with -O3 -fgnu-tm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53991 --- Comment #7 from torvald at gcc dot gnu.org --- A piece of code is tm_pure if, roughly, it doesn't need any instrumentation (e.g., in contrast to memory loads/stores). In the test case, I suppose that the compiler detects that it is tm_pure, but we also allow programmers to declare it. Ideally, tm_pure should be a property of a region of code that is preserved across optimizations (but where we don't move code into or out of tm_pure regions). That may require too much implementation effort (but perhaps we could reuse the TM regions for that, as a no-TM region?) Alternatively, we could not automatically mark always_inline functions also as tm_pure, and warn if always_inline is also annotated as tm_pure by the programmer. Other thoughts?
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #5 from chrbr at gcc dot gnu.org --- If I print out the regno argument to arm_dbx_register_number, it's 272 which seem to me like it could be reg number in DWARF numbering? yes it is. strange, I can't see this new failure, with a full newlib build for --enable-languages=c,c++ \ --with-fpu=neon-vfpv4 --with-float=hard --with-arch=armv7-a could you please attach the preprocessed file ? thanks,
[Bug tree-optimization/57318] [4.9 Regression] optimizer takes several seconds on nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57318 --- Comment #7 from Jan Hubicka hubicka at ucw dot cz --- URL: http://gcc.gnu.org/viewcvs?rev=199140root=gccview=rev Log: 2013-05-21 Richard Biener rguent...@suse.de PR tree-optimization/57318 * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Do not estimate stmts with side-effects as likely eliminated. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivcanon.c Fixed - latent on the branch though. Hmm, this heuristic was sort of intended (inliner makes same trick) We anticipate that making the array stores explicit will enable SRA stuff. But since then I made inliner to asume the 50% probability of optimizing these away that works better. Did you measure runtime effect of this? (we will see in SPEC graph soon I guess) Honza
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #6 from ktkachov at gcc dot gnu.org --- (In reply to chrbr from comment #5) If I print out the regno argument to arm_dbx_register_number, it's 272 which seem to me like it could be reg number in DWARF numbering? yes it is. strange, I can't see this new failure, with a full newlib build for --enable-languages=c,c++ \ --with-fpu=neon-vfpv4 --with-float=hard --with-arch=armv7-a could you please attach the preprocessed file ? thanks, My apologies, the attachment I added in the bug report is reduced from newlib (I initially said it was from libgfortran). I'm getting the ICE in arm_dbx_register_number on the initial file I attached. On a side note, in your patch you say: - t = one_reg_loc_descriptor (REGNO (XVECEXP (regs, 0, i)), + reg = REGNO (XVECEXP (regs, 0, i)); + t = one_reg_loc_descriptor (DBX_REGISTER_NUMBER (reg), but reg is undeclared in this scope (changing it to unsigned reg = ... fixes it) which suggests to me there's some other changes? In your original patch you also moved the #ifdef LEAF_REG_MAP and associated definitions inside the if (regs == NULL_RTX) block...
[Bug fortran/57354] Wrong run-time assignment of allocatable array of derived type with allocatable component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57354 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Slightly reduced example. The problem seems to be if the LHS and the RHS are the same for one of the RHSlements: type t integer,allocatable :: i end type type(t) :: e type(t), allocatable :: a(:) e%i = 1 ! Realloc on assignment: OK a = [e] ! OK e%i = 2 ! OK a = [a, e] ! Wrong result print *, (a(i)%i,i=1,2) end
[Bug tree-optimization/57343] [4.8/4.9 Regression] wrong code on x86_64-linux at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343 --- Comment #6 from Zdenek Dvorak rakdver at gcc dot gnu.org --- I will have a look.
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #7 from chrbr at gcc dot gnu.org --- (In reply to ktkachov from comment #6) (In reply to chrbr from comment #5) If I print out the regno argument to arm_dbx_register_number, it's 272 which seem to me like it could be reg number in DWARF numbering? yes it is. strange, I can't see this new failure, with a full newlib build for --enable-languages=c,c++ \ --with-fpu=neon-vfpv4 --with-float=hard --with-arch=armv7-a could you please attach the preprocessed file ? thanks, My apologies, the attachment I added in the bug report is reduced from newlib (I initially said it was from libgfortran). I'm getting the ICE in arm_dbx_register_number on the initial file I attached. On a side note, in your patch you say: - t = one_reg_loc_descriptor (REGNO (XVECEXP (regs, 0, i)), + reg = REGNO (XVECEXP (regs, 0, i)); + t = one_reg_loc_descriptor (DBX_REGISTER_NUMBER (reg), but reg is undeclared in this scope (changing it to unsigned reg = ... fixes it) which suggests to me there's some other changes? In your original patch you also moved the #ifdef LEAF_REG_MAP and associated definitions inside the if (regs == NULL_RTX) block... OOPS ! I committed the wrong patch, I kept to good version locally. sorry about this I don't know what I messed in my sandbox. recommitting the first part now this now as approved. Will send the ARM part on the ML after the testsuite. thanks for catching it.
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #8 from ktkachov at gcc dot gnu.org --- (In reply to chrbr from comment #7) thanks for catching it. No problem, thanks for fixing :)
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #9 from chrbr at gcc dot gnu.org --- no, in fact, you confused me. The patch was committed correctly :-) On a side note, in your patch you say: - t = one_reg_loc_descriptor (REGNO (XVECEXP (regs, 0, i)), + reg = REGNO (XVECEXP (regs, 0, i)); + t = one_reg_loc_descriptor (DBX_REGISTER_NUMBER (reg), but reg is undeclared in this scope (changing it to unsigned reg = ... fixes it) which suggests to me there's some other changes? In your original patch you also moved the #ifdef LEAF_REG_MAP and associated definitions inside the if (regs == NULL_RTX) block... are you sure you have the good version of this file ? you should have t = one_reg_loc_descriptor (dbx_reg_number (XVECEXP (regs, 0, i)), so reg is not needed and doesn't need to be initialized. reg is set/used only in the /* Simple, contiguous registers. */ part. The original failing attachment now passes with the ARM patch. Will post after checking with the testsuite Regards,
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #10 from ktkachov at gcc dot gnu.org --- (In reply to chrbr from comment #9) no, in fact, you confused me. The patch was committed correctly :-) On a side note, in your patch you say: - t = one_reg_loc_descriptor (REGNO (XVECEXP (regs, 0, i)), + reg = REGNO (XVECEXP (regs, 0, i)); + t = one_reg_loc_descriptor (DBX_REGISTER_NUMBER (reg), but reg is undeclared in this scope (changing it to unsigned reg = ... fixes it) which suggests to me there's some other changes? In your original patch you also moved the #ifdef LEAF_REG_MAP and associated definitions inside the if (regs == NULL_RTX) block... are you sure you have the good version of this file ? you should have t = one_reg_loc_descriptor (dbx_reg_number (XVECEXP (regs, 0, i)), so reg is not needed and doesn't need to be initialized. reg is set/used only in the /* Simple, contiguous registers. */ part. The original failing attachment now passes with the ARM patch. Will post after checking with the testsuite In that post (comment 6) I was citing the patch you attached to this report, which says: - t = one_reg_loc_descriptor (REGNO (XVECEXP (regs, 0, i)), + reg = REGNO (XVECEXP (regs, 0, i)); + t = one_reg_loc_descriptor (DBX_REGISTER_NUMBER (reg), which doesn't apply to trunk cleanly because the trunk version was: t = one_reg_loc_descriptor (dbx_reg_number (XVECEXP (regs, 0, i)), like you said. Presumably that attached part should have been applied instead of your original patch? In any case, from what I understand you reproduced the arm.c ICE and confirmed that it's fixed with your (under test) ARM patch? Thanks, Kyrill In any case, if you have
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #11 from ktkachov at gcc dot gnu.org --- In any case, if you have Err... stray line. Ignor that.
[Bug tree-optimization/57358] New: segmentation fault with attribute(optimize(O0))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57358
Bug ID: 57358
Summary: segmentation fault with attribute(optimize(O0))
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nbkolchin at gmail dot com
Created attachment 30157
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30157action=edit
backtrace
The following code crashes GCC (gcc-4.8.0 -O2):
typedef void (*done)(void* arg);
struct t { done func; void* arg; };
static void test_func() __attribute__((optimize(O0)));
static void test_func(struct t* a)
{
a-func(a-arg);
}
Program received signal SIGSEGV, Segmentation fault.
walk_aliased_vdefs_1 (ref=ref@entry=0x7fffda70, vdef=0x0,
walker=0x6f5d90 mark_modified(ao_ref*, tree, void*), data=0x7fffda5f,
visited=0x7fffda28, cnt=0)
at /mnt/work/oktet/transas/sources/4.8/gcc/gcc/tree-ssa-alias.c:2196
2196 gimple def_stmt = SSA_NAME_DEF_STMT (vdef);
Backtrace from gdb attached.
Reproducable with custom GCC build and gentoo 4.8. No error in 4.7.
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #12 from chrbr at gcc dot gnu.org --- Comment on attachment 30156 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30156 patch Index: arm.c === --- arm.c (revision 199138) +++ arm.c (working copy) @@ -25860,10 +25860,10 @@ arm_dwarf_register_span (rtx rtl) return NULL_RTX; nregs = GET_MODE_SIZE (GET_MODE (rtl)) / 8; + gcc_assert (nregs != 1); p = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (nregs)); - regno = (regno - FIRST_VFP_REGNUM) / 2; for (i = 0; i nregs; i++) -XVECEXP (p, 0, i) = gen_rtx_REG (DImode, 256 + regno + i); +XVECEXP (p, 0, i) = gen_rtx_REG (DImode, regno + i); return p; }
[Bug tree-optimization/57331] [4.9 Regression] ICE: tree check: expected integer_type or enumeral_type or boolean_type or real_type or fixed_point_type, have pointer_type in int_fits_type_p, at tree.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57331 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue May 21 15:17:31 2013 New Revision: 199148 URL: http://gcc.gnu.org/viewcvs?rev=199148root=gccview=rev Log: PR tree-optimization/57331 * tree-vrp.c (simplify_cond_using_ranges): Don't optimize comparison of conversion from pointer type to integral type with integer. * gcc.c-torture/compile/pr57331.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr57331.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #13 from chrbr at gcc dot gnu.org --- Comment on attachment 30156 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30156 patch ndex: arm.c === --- arm.c(revision 199138) +++ arm.c(working copy) @@ -25860,10 +25860,9 @@ arm_dwarf_register_span (rtx rtl) return NULL_RTX; nregs = GET_MODE_SIZE (GET_MODE (rtl)) / 8; p = gen_rtx_PARALLEL (VOIDmode, rtvec_alloc (nregs)); - regno = (regno - FIRST_VFP_REGNUM) / 2; for (i = 0; i nregs; i++) -XVECEXP (p, 0, i) = gen_rtx_REG (DImode, 256 + regno + i); +XVECEXP (p, 0, i) = gen_rtx_REG (DImode, regno + i); return p; }
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #14 from chrbr at gcc dot gnu.org --- In that post (comment 6) I was citing the patch you attached to this report, which says: OK that's clear. Wrong attachment like you said. Presumably that attached part should have been applied instead of your original patch? no, applied patch was OK as approved. In any case, from what I understand you reproduced the arm.c ICE and confirmed that it's fixed with your (under test) ARM patch? yes, correct. Reproduced and fixed with the ARM patch posted in comment #13 p, sorry for the confusion.
[Bug target/57356] gcc-4.8: SSE2 instructions generated with '-mno-sse2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57356 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-05-21 Component|c |target Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Target Milestone|--- |4.7.4 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- There are many assumptions that x86 implies SSE2 throughout the target-dependant part of gcc. This one is simple to fix with following fix to movti insn pattern. --cut here-- Index: config/i386/i386.md === --- config/i386/i386.md (revision 199017) +++ config/i386/i386.md (working copy) @@ -1805,7 +1805,8 @@ (const_string V4SF) (match_test TARGET_AVX) (const_string TI) - (match_test optimize_function_for_size_p (cfun)) + (ior (not (match_test TARGET_SSE2)) + (match_test optimize_function_for_size_p (cfun))) (const_string V4SF) ] (const_string TI)))]) --cut here-- The 4.7 branch is also affected, 4.9 is not.
[Bug bootstrap/57340] [4.9 regression] stage2 miscompiles build/genconditions on armv5tel-linux-gnueabi breaking bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57340 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- I'll take a look. Ramana
[Bug debug/57351] ICE: internal compiler error: in dbx_reg_number, at dwarf2out.c:10507 on arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57351 --- Comment #15 from ktkachov at gcc dot gnu.org --- (In reply to chrbr from comment #14) In that post (comment 6) I was citing the patch you attached to this report, which says: OK that's clear. Wrong attachment like you said. Presumably that attached part should have been applied instead of your original patch? no, applied patch was OK as approved. In any case, from what I understand you reproduced the arm.c ICE and confirmed that it's fixed with your (under test) ARM patch? yes, correct. Reproduced and fixed with the ARM patch posted in comment #13 Cool, that patch fixes it for me as well. A build with newlib and fortran enabled succeeded. Running tests as well. Thanks, Kyrill
[Bug target/57357] Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-pc-linux-gnu Status|UNCONFIRMED |RESOLVED Component|c |target Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This is expected as you are disabling SSE and the function returns a double which is not valid with SSE disabled.
[Bug tree-optimization/57318] [4.9 Regression] optimizer takes several seconds on nested loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57318 --- Comment #8 from rguenther at suse dot de rguenther at suse dot de --- hubicka at ucw dot cz gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57318 --- Comment #7 from Jan Hubicka hubicka at ucw dot cz --- URL: http://gcc.gnu.org/viewcvs?rev=199140root=gccview=rev Log: 2013-05-21 Richard Biener rguent...@suse.de PR tree-optimization/57318 * tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Do not estimate stmts with side-effects as likely eliminated. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivcanon.c Fixed - latent on the branch though. Hmm, this heuristic was sort of intended (inliner makes same trick) We anticipate that making the array stores explicit will enable SRA stuff. But since then I made inliner to asume the 50% probability of optimizing these away that works better. Did you measure runtime effect of this? (we will see in SPEC graph soon I guess) This is about Volatile loads and stores. Honza
[Bug target/57357] Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357 --- Comment #2 from thutt at vmware dot com --- Can you please explain why it's invalid to return a double if SSE is disabled? SSE is an x86-specific hardware implementation and has nothing to do with language validity from my standpoint.
[Bug target/57357] Error with '-mno-sse' and include wchar.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57357 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to thutt from comment #2) Can you please explain why it's invalid to return a double if SSE is disabled? SSE is an x86-specific hardware implementation and has nothing to do with language validity from my standpoint. On x86_64 the ABI says doubles are returned (and passed) via the SSE registers.
