[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59727 --- Comment #8 from Jerry DeLisle --- The patch committed as shown in comment #42 of pr38199 appears to fix this one incidentally. Regarding comment 5, I am still not sure the code is valid, but I do agree there is no reason to give an error either. I will be looking at a few other issues related to this and will close the PR when we are confident there is not something else lurking here. See also PR58324
[Bug tree-optimization/60454] [4.7/4.8 Regression] Code mistakenly detected as doing bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454 Thomas Preud'homme changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Thomas Preud'homme --- As mentionned by Jakub Jelinek, fixed in trunk
[Bug libfortran/59727] [4.7/4.8/4.9 Regression] reading from character string returns end of file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59727 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #7 from Jerry DeLisle --- I will have a look at it this one as well.
[Bug fortran/58324] Bogus END-of-line error with list-directed I/O of file without trailing sequential record marker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58324 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle --- I just got rid of the eat_line call for internal units. I did not notice this PR until after committing the patch for pr38199. If I remove eat_line altogether I get regressions on file list_read tests. I will investigate further.
[Bug libfortran/38199] [4.7/4.8/4.9 Regression] missed optimization: I/O performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38199 --- Comment #42 from Jerry DeLisle --- Author: jvdelisle Date: Thu Mar 13 05:06:57 2014 New Revision: 208528 URL: http://gcc.gnu.org/viewcvs?rev=208528&root=gcc&view=rev Log: 2014-03-12 Jerry DeLisle PR libfortran/38199 * io/read.c (read_decimal): Quickly skip spaces to avoid calls to next_char. * io/unit.c (is_trim_ok): New helper function to check various conditions to see if its OK to trim the internal unit string. (get_internal_unit): Use LEN_TRIM to shorten selected internal unit strings for optimizing READ. Enable this optimization for formatted READ. * io/list_read.c (finish_list_read): Don't call eat_line for internal units. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c trunk/libgfortran/io/read.c trunk/libgfortran/io/unit.c
[Bug target/58622] With -fomit-frame-pointer, A64 does not generate post-decrement stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58622 Kugan changed: What|Removed |Added CC||kuganv at linaro dot org --- Comment #2 from Kugan --- Created attachment 32342 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32342&action=edit Proposed RFC patch Proposed RFC patch - In the process rgression testing.
[Bug rtl-optimization/57425] [4.8 Regression] RTL alias analysis unprepared to handle stack slot sharing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57425 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #12 from Bill Schmidt --- (In reply to Eric Botcazou from comment #5) > > Note that I only recently fixed a wrong alias query from using > > true_dependence to anti_dependence. Similar issues may exist elsewhere. > > That would point to cselib_invalidate_mem then. It uses > canon_true_dependence but here we have an anti-dependence (WAR). I believe I've run into this problem in 4.8 as well when compiling some code for powerpc64le-linux-gnu (so for now that is on ibm/gcc-4_8-branch). At least I'm seeing invalid commoning involving memory references in cselib, and the problem doesn't reproduce on trunk. Does anyone have a patch in progress for backporting this fix to 4.8?
[Bug c++/60513] False positive "division by zero" warning in unreachable code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60513 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 4210. *** This bug has been marked as a duplicate of bug 4210 ***
[Bug middle-end/4210] should not warning with dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 Andrew Pinski changed: What|Removed |Added CC||xzfcpw+gcc at gmail dot com --- Comment #23 from Andrew Pinski --- *** Bug 60513 has been marked as a duplicate of this bug. ***
[Bug c++/60513] New: False positive "division by zero" warning in unreachable code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60513
Bug ID: 60513
Summary: False positive "division by zero" warning in
unreachable code
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xzfcpw+gcc at gmail dot com
$ cat 12.cpp
int main()
{
constexpr int i = 0;
int j = 20;
if(i)
if(j % i)
/* ... */;
}
$ g++ -std=c++11 12.cpp
12.cpp: In function ‘int main()’:
12.cpp:6:10: warning: division by zero [-Wdiv-by-zero]
if(j % i)
^
[Bug tree-optimization/59779] [4.9 Regression] FAIL: gcc.dg/autopar/outer-1.c scan-tree-dump-times parloops "parallelizing outer loop"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59779 --- Comment #3 from dave.anglin at bell dot net --- On 12-Mar-14, at 9:55 AM, jakub at gcc dot gnu.org wrote: > Can't reproduce this with a cross-compiler to hppa-unknown-linux on > current > trunk: Could this be a HOST_WIDE_INT issue? I see this for 32-bit builds on both hpux and linux, but not on 64-bit builds. Dave -- John David Anglindave.ang...@bell.net
[Bug tree-optimization/48316] missed CSE / reassoc with array offsets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48316
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #1 from davidxl ---
int a[8][8];
int foo(int i)
{
return a[i][3] + a[i+1][3] + a[i+2][3];
}
ICC generates:
movslq%edi, %rdi#5.1
shlq $5, %rdi #6.10
movl 12+a(%rdi), %eax #6.10
addl 44+a(%rdi), %eax #6.20
addl 76+a(%rdi), %eax
GCC can not CSE the common code for address arithmetic:
leal1(%rdi), %eax
movslq %edi, %rdx
addl$2, %edi
cltq
movslq %edi, %rdi
salq$5, %rdx
salq$5, %rax
salq$5, %rdi
movla+12(%rax), %eax
addla+12(%rdx), %eax
addla+12(%rdi), %eax
ret
[Bug libstdc++/59392] crash on throw from "unexpected exception" handler with ARM EABI unwinder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392 roland at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from roland at gnu dot org --- Fixed on trunk and 4.8.
[Bug libstdc++/59392] crash on throw from "unexpected exception" handler with ARM EABI unwinder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392
--- Comment #5 from roland at gcc dot gnu.org ---
Author: roland
Date: Wed Mar 12 22:44:09 2014
New Revision: 208520
URL: http://gcc.gnu.org/viewcvs?rev=208520&root=gcc&view=rev
Log:
PR libstdc++/59392: Fix ARM EABI uncaught throw from unexpected exception
handler
libstdc++-v3/
PR libstdc++/59392
* libsupc++/eh_call.cc (__cxa_call_unexpected): Call __do_catch with
the address of a null pointer, not with a null pointer to pointer.
Copy comment for this case from eh_personality.cc:__cxa_call_unexpected.
* testsuite/18_support/bad_exception/59392.cc: New file.
Added:
branches/gcc-4_8-branch/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
(with props)
Modified:
branches/gcc-4_8-branch/libstdc++-v3/ChangeLog
branches/gcc-4_8-branch/libstdc++-v3/libsupc++/eh_call.cc
Propchange:
branches/gcc-4_8-branch/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
('svn:eol-style' added)
[Bug libstdc++/59392] crash on throw from "unexpected exception" handler with ARM EABI unwinder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392
--- Comment #4 from roland at gcc dot gnu.org ---
Author: roland
Date: Wed Mar 12 22:42:13 2014
New Revision: 208519
URL: http://gcc.gnu.org/viewcvs?rev=208519&root=gcc&view=rev
Log:
PR libstdc++/59392: Fix ARM EABI uncaught throw from unexpected exception
handler
libstdc++-v3/
PR libstdc++/59392
* libsupc++/eh_call.cc (__cxa_call_unexpected): Call __do_catch with
the address of a null pointer, not with a null pointer to pointer.
Copy comment for this case from eh_personality.cc:__cxa_call_unexpected.
* testsuite/18_support/bad_exception/59392.cc: New file.
Added:
trunk/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc (with
props)
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/eh_call.cc
Propchange: trunk/libstdc++-v3/testsuite/18_support/bad_exception/59392.cc
('svn:eol-style' added)
[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
--- Comment #5 from H.J. Lu ---
Another problem:
[hjl@gnu-6 gcc]$ cat /tmp/c.i
static __thread char ccc;
void* __cxa_get_globals()
{
return &ccc;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S -O2 -fPIC /tmp/c.i
[hjl@gnu-6 gcc]$ cat /tmp/c.i
static __thread char ccc;
void* __cxa_get_globals()
{
return &ccc;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -S -O2 -fPIC /tmp/c.i -m32
[hjl@gnu-6 gcc]$ cat c.s
.file"c.i"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl__cxa_get_globals
.type__cxa_get_globals, @function
__cxa_get_globals:
.LFB0:
.cfi_startproc
pushl%ebx
.cfi_def_cfa_offset 8
.cfi_offset 3, -8
call__x86.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
subl$8, %esp
.cfi_def_cfa_offset 16
addl$8, %esp
.cfi_def_cfa_offset 8
lealccc@tlsgd(,%ebx,1), %eax
call___tls_get_addr@PLT
popl%ebx
.cfi_restore 3
.cfi_def_cfa_offset 4
ret
.cfi_endproc
.LFE0:
.size__cxa_get_globals, .-__cxa_get_globals
sched2 doesn't know
(insn:TI 15 25 13 2 (parallel [
(set (reg:SI 0 ax [86])
(unspec:SI [
(reg:SI 3 bx)
(symbol_ref:SI ("ccc") [flags 0x1a] )
(symbol_ref:SI ("___tls_get_addr"))
] UNSPEC_TLS_GD))
(clobber (reg:SI 1 dx [88]))
(clobber (reg:SI 2 cx [89]))
(clobber (reg:CC 17 flags))
]) /tmp/c.i:5 772 {*tls_global_dynamic_32_gnu}
(expr_list:REG_DEAD (reg:SI 3 bx)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 2 cx [89])
(expr_list:REG_UNUSED (reg:SI 1 dx [88])
(expr_list:REG_EQUIV (unspec:SI [
(reg:SI 3 bx)
(symbol_ref:SI ("ccc") [flags 0x1a] )
(symbol_ref:SI ("___tls_get_addr"))
] UNSPEC_TLS_GD)
(nil)))
is a function call and move stack adjustment cross it.
[Bug libstdc++/60270] [C++1y] std::quoted is too eager to clear the string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60270 Jonathan Wakely changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-12 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Approved patch: http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01275.html
[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #4 from H.J. Lu --- Created attachment 32341 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32341&action=edit A patch This patch sets ix86_tls_descriptor_calls_expanded_in_cfun after reload is complete and checks it for stack boundary in ix86_frame_pointer_required.
[Bug libstdc++/59392] crash on throw from "unexpected exception" handler with ARM EABI unwinder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392 Jonathan Wakely changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-12 Ever confirmed|0 |1 --- Comment #3 from Jonathan Wakely --- The posted patch is OK, approved for trunk and 4.8
[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 --- Comment #4 from Marc Glisse --- (In reply to Evan Teran from comment #3) > Any unsupported feature would do. All the core features are at least partially supported, only some ABI-breaking library changes have been postponed. > A quick read of that page shows a pretty good solution. Has any word towards > implementing its recommendations been done? I don't think so. Feel free to start. Defining a bunch of macros seems like a nice and easy way to start contributing to gcc ;-)
[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 --- Comment #3 from Evan Teran --- @Andrew, I hadn't seen that they were supported, I stand corrected. However that particular feature was for example purposes. Any unsupported feature would do. @Marc, A quick read of that page shows a pretty good solution. Has any word towards implementing its recommendations been done? Thanks for the *very* quick response.
[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 --- Comment #2 from Andrew Pinski --- >So while GCC doesn't support C++11 attributes yet Wrong, it does support them, in fact for a while now.
[Bug c++/60512] would be useful if gcc implemented __has_feature similary to clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 --- Comment #1 from Marc Glisse --- http://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations
[Bug c++/60512] New: would be useful if gcc implemented __has_feature similary to clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512 Bug ID: 60512 Summary: would be useful if gcc implemented __has_feature similary to clang Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eteran at alum dot rit.edu I was recently thinking about how GCC sets __cplusplus to 201103L when -std=c++11 yet doesn't (and may not ever) fully support every single corner case of c++11. I agree with the notion that __cplusplus == 201103L is a statement of intent, not 100% conformance. But how should developers write code that attempts to use features which aren't necessarily implemented yet, but may be in the near future or other compilers. It occurred to me that the ideal solution may not be to test __cplusplus at all, but instead to test for specific features. I find that that clang's approach to this seems to hit the sweet spot. I'm sure the GCC folk are aware of the feature, but I'll reiterate for reference. In clang: "[This] function-like macro take a single identifier argument that is the name of a feature. __has_feature evaluates to 1 if the feature is both supported by Clang and standardized in the current language standard or 0 if not" So while GCC doesn't support C++11 attributes yet, we could still code for it today wrapping it like so. #if __has_feature(cxx_attributes) #endif if it also supported the __has_feature (and family) suite of macros. Perhaps this macro is mostly of interest to library writers and not a huge deal to most developers, but I believe that it would be a tool that is *very* useful when it turns out that you do need it.
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #32 from David Kredba --- 208516
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #31 from David Kredba --- Calligra-2.8.0 is now affected too with revision /var/tmp/portage/app-office/calligra-2.8.0/temp/ccAMiINB.ltrans1.ltrans.o: In function `operator<': /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/sheets/Condition.h:170: undefined reference to `Calligra::Sheets::qHash(Calligra::Sheets::Conditions const&)' /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/sheets/Condition.h:170: undefined reference to `Calligra::Sheets::qHash(Calligra::Sheets::Conditions const&)' /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/sheets/Condition.h:170: undefined reference to `Calligra::Sheets::qHash(Calligra::Sheets::Conditions const&)' /var/tmp/portage/app-office/calligra-2.8.0/temp/ccAMiINB.ltrans1.ltrans.o: In function `qMapLessThanKey': /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/sheets/Condition.h:170: undefined reference to `Calligra::Sheets::qHash(Calligra::Sheets::Conditions const&)' /var/tmp/portage/app-office/calligra-2.8.0/temp/ccAMiINB.ltrans1.ltrans.o: In function `operator<': /var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/sheets/Condition.h:170: undefined reference to `Calligra::Sheets::qHash(Calligra::Sheets::Conditions const&)' /var/tmp/portage/app-office/calligra-2.8.0/temp/ccAMiINB.ltrans1.ltrans.o:/var/tmp/portage/app-office/calligra-2.8.0/work/calligra-2.8.0/sheets/Condition.h:170: more undefined references to `Calligra::Sheets::qHash(Calligra::Sheets::Conditions const&)' follow collect2: error: ld returned 1 exit status sheets/CMakeFiles/calligrasheetscommon.dir/build.make:3104: recipe for target 'lib/libcalligrasheetscommon.so.13.0.0' failed
[Bug c++/60511] New: [C++1y][N3652] Missing extended constexpr function support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60511
Bug ID: 60511
Summary: [C++1y][N3652] Missing extended constexpr function
support
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.kruegler at googlemail dot com
gcc 4.9.0 20140309 (experimental) compiled with the flags
-std=c++1y -Wall -pedantic
rejects:
//--
template
struct L
{
T t;
constexpr L(const T& t) : t(t) {}
constexpr const T& value() const & { return t; }
constexpr T& value() & { return t; }
};
template
constexpr T twice(const T& t) {
L l(t);
l.value() *= 2;
return l.value();
}
int main() {
constexpr int i = twice(12);
static_assert(i == 24, "");
}
//--
prog.cc:7:16: error: 'constexpr T& L::value() const &' cannot be overloaded
constexpr T& value() & { return t; }
^
prog.cc:6:22: error: with 'constexpr const T& L::value() const &'
constexpr const T& value() const & { return t; } ^
prog.cc: In instantiation of 'constexpr T twice(const T&) [with T = int]':
prog.cc:18:29: required from here
prog.cc:13:13: error: assignment of read-only location 'l.L::value()'
l.value() *= 2;
^
prog.cc:15:1: error: body of constexpr function 'constexpr T twice(const T&)
[with T =
int]' not a return-statement
}
^
prog.cc: In function 'int main()':
prog.cc:18:29: error: 'constexpr T twice(const T&) [with T = int]' called in a
constant expression
constexpr int i = twice(12);
^
prog.cc:11:13: note: 'constexpr T twice(const T&) [with T = int]' is not usable
as
a constexpr function because:
constexpr T twice(const T& t) {
^
The compiler seems currently not apply the extended C++14 constexpr rules as of
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3652.html
1) constexpr makes non-static member functions automatically const member
functions
2) constexpr functions require a single return statement
3) constexpr functions reject mutable operations
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438 --- Comment #34 from Jakub Jelinek --- (In reply to Richard Henderson from comment #33) > It sounds like inhibiting this stack combining would affect more > 32-bit code than I'd like. > > I don't like the idea of REG_ARGS_SIZE_DELTA. The reason I went > with absolute values in the first place for REG_ARGS_SIZE is that > there were too many places where "deltas" matched up, but absolute > values did not. And so we'd wind up cross-jumping illegally. > > I wonder if the best fix is to change the patterns not to rely on > ix86_force_to_memory and ix86_free_from_memory, but instead have a > memory operand to clobber right from the start. No fighting with > dwarf2 or unwind info after the fact at all. > > I'll whip that up today and see what it looks like. Perhaps. In this particular case I think it the r in a m,?r constraints, just removing the ?r option probably would have done the job.
[Bug debug/60438] [4.9 Regression] dwarf2cfi :2239 still assert,not the same cause as PR 59575
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60438 --- Comment #33 from Richard Henderson --- It sounds like inhibiting this stack combining would affect more 32-bit code than I'd like. I don't like the idea of REG_ARGS_SIZE_DELTA. The reason I went with absolute values in the first place for REG_ARGS_SIZE is that there were too many places where "deltas" matched up, but absolute values did not. And so we'd wind up cross-jumping illegally. I wonder if the best fix is to change the patterns not to rely on ix86_force_to_memory and ix86_free_from_memory, but instead have a memory operand to clobber right from the start. No fighting with dwarf2 or unwind info after the fact at all. I'll whip that up today and see what it looks like.
[Bug fortran/60507] Passing function call into procedure argument not caught
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60507
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||accepts-invalid
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
Summary|Passing real expression |Passing function call into
|into procedure argument not |procedure argument not
|caught |caught
--- Comment #2 from janus at gcc dot gnu.org ---
This helps (not regtested yet):
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c(revision 208455)
+++ gcc/fortran/interface.c(working copy)
@@ -2741,7 +2741,12 @@ compare_actual_formal (gfc_actual_arglist **ap, gf
/* Satisfy F03:12.4.1.3 by ensuring that a procedure actual argument is
provided for a procedure formal argument. */
if (f->sym->attr.flavor == FL_PROCEDURE
- && gfc_expr_attr (a->expr).flavor != FL_PROCEDURE)
+ && !((a->expr->expr_type == EXPR_VARIABLE
+&& (a->expr->symtree->n.sym->attr.flavor == FL_PROCEDURE
+|| a->expr->symtree->n.sym->attr.proc_pointer))
+ || (a->expr->expr_type == EXPR_FUNCTION
+ && a->expr->symtree->n.sym->result->attr.proc_pointer)
+ || gfc_is_proc_ptr_comp (a->expr)))
{
if (where)
gfc_error ("Expected a procedure for argument '%s' at %L",
[Bug middle-end/60419] [4.8/4.9 Regression] ICE Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60419 Jakub Jelinek changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Honza or Martin, can you please have a look? The #c5 testcase should be reproduceable with a cross to powerpc64-linux.
[Bug tree-optimization/60196] [4.8 Regression] Incorrect compilation with -fwrapv and -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60196 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-12 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.3 Summary|Incorrect compilation with |[4.8 Regression] Incorrect |-fwrapv and |compilation with -fwrapv |-ftree-vectorize|and -ftree-vectorize Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Started with r185437 and fixed again with r202663 (both testcases).
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #31 from H.J. Lu --- (In reply to Jakub Jelinek from comment #29) > Created attachment 32338 [details] > gcc49-pr60418.patch > > New version of the patch, going to bootstrap/regtest it momentarily. H.J., > could you please check if this also fixes the gromacs -mx32 issue? Yes, it works with -mx32. Thanks.
[Bug middle-end/58479] [4.8/4.9 Regression] slow var-tracking on x86_64-linux at -O1 (and above) with -g, but checking disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 Summary|[4.9 Regression] slow |[4.8/4.9 Regression] slow |var-tracking on |var-tracking on |x86_64-linux at -O1 (and|x86_64-linux at -O1 (and |above) with -g, but |above) with -g, but |checking disabled |checking disabled --- Comment #6 from Jakub Jelinek --- BTW, I don't see any significant slowdown from r155360 when this regressed on compile time (for different reasons). It has been slow until r187052, with r187053 it returned roughly at previous speed, then r195015 started emitting the debug stmts and compile time went up again. But, if I compare 4.8 branch (--enable-checking=yes,rtl) from r208337 with current trunk (--enable-checking=yes,rtl), trunk is a few % faster even. So, IMHO this isn't a P1 regression as it hasn't really regressed recently (and while during development of 4.8 it has been for certain period fast again, it hasn't been "fixed" in any released compiler after 4.4.x).
[Bug tree-optimization/60510] SLP blocks loop vectorization (with reduction)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60510 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-12 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed on 4.7.4, 4.8.3 and trunk r208512. > When `+x(i)` removed, vectorization passes. The same if 'x(i)*y(i)+x(i)' is replaced with 'x(i)*(1.0+y(i))' (work-around).
[Bug rtl-optimization/57189] [4.9 Regression] Vector register is spilled for vector extract pattern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57189 Jakub Jelinek changed: What|Removed |Added Priority|P1 |P2 CC||vmakarov at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- IMHO not worth P1 status. Would be nice if Vlad could have a look eventually though.
[Bug tree-optimization/60196] Incorrect compilation with -fwrapv and -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60196
--- Comment #1 from Роман Донченко ---
Here's another reproducer for what looks like the same problem:
#include
static const short a[8] = {1,1,1,1,1,1,1,1};
static const unsigned char b[8] = {0,0,0,0,0,0,0,0};
static int foo()
{
int sum = 0, i;
for (i = 0; i < 8; ++i)
sum += a[i] * b[i];
return sum;
}
int main()
{
printf("%d\n", foo());
return 0;
}
The correct result is 0, but compiling with -O1 -ftree-vectorize yields 8. I
looked at the disassembly, and it just sums the elements of a, b is not used at
all.
For this one, adding -fwrapv actually fixes it, but I don't think there are any
overflows here.
[Bug tree-optimization/59124] [4.8/4.9 Regression] Wrong warnings "array subscript is above array bounds"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Both testcases regressed with r192538.
[Bug tree-optimization/60510] New: SLP blocks loop vectorization (with reduction)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60510 Bug ID: 60510 Summary: SLP blocks loop vectorization (with reduction) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kirill.yukhin at intel dot com Hello, This case is not vectorized: $ cat f2.f subroutine foo(a,x,y,n) implicit none integer n,i real*8 y(n),x(n),a do i=1,n a=a+x(i)*y(i)+x(i) enddo return end When `+x(i)` removed, vectorization passes. Compilation: ./build-x86_64-linux/gcc/gfortran -B./build-x86_64-linux/gcc -S -Ofast -mavx2 f2.f -fno-unroll-loops -fdump-tree-vect-all vect report says: f2.f:7:0: note: type of def: 3. f2.f:7:0: note: vect_is_simple_use: operand _13 f2.f:7:0: note: def_stmt: _13 = _12 + prephitmp_32; f2.f:7:0: note: type of def: 3. f2.f:7:0: note: Build SLP for # VUSE <.MEM_2> _12 = *x_11(D)[_10]; f2.f:7:0: note: Build SLP failed: not grouped load # VUSE <.MEM_2> _12 = *x_11(D)[_10];
[Bug testsuite/59308] [4.9 Regression] gcc.dg/tree-ssa/ssa-ifcombine-ccmp-[1456] tests fail on arm cortex-a5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59308 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Assuming this is fixed, please reopen if not with details where it fails and what.
[Bug tree-optimization/59779] [4.9 Regression] FAIL: gcc.dg/autopar/outer-1.c scan-tree-dump-times parloops "parallelizing outer loop"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59779 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Can't reproduce this with a cross-compiler to hppa-unknown-linux on current trunk: ./cc1 -O2 -quiet -ftree-parallelize-loops=4 -fdump-tree-parloops-details -fdump-tree-optimized outer-1.c -nostdinc; grep 'parallelizing outer loop' outer-1.c.112t.parloops; grep loopfn outer-1.c.169t.optimized parallelizing outer loop 9 __builtin_GOMP_parallel (parloop._loopfn.0, &.paral_data_store.8, 4, 0); ;; Function parloop._loopfn.0 (parloop._loopfn.0, funcdef_no=2, decl_uid=1447, symbol_order=3) parloop._loopfn.0 (void * .paral_data_param)
[Bug fortran/60507] Passing real expression into procedure argument not caught
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60507 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-12 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org --- Confirmed. With print *, f(1.) one gets the correct error: print *, f(1.) 1 Error: Expected a procedure for argument 'fun' at (1)
[Bug fortran/58880] [4.9 Regression] [OOP] ICE on valid with FINAL function and type extension
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58880 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug fortran/60495] [4.9 Regression] ICE: in fold_convert_loc, at fold-const.c:1994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60495 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/60495] [4.9 Regression] ICE: in fold_convert_loc, at fold-const.c:1994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60495 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Indeed, it started with r200954.
[Bug rtl-optimization/60501] [4.9 regression] LRA emits add patterns which might clobber cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60501 --- Comment #6 from Andreas Krebbel --- (In reply to Jakub Jelinek from comment #5) > (In reply to Andreas Krebbel from comment #2) > > Bootstrap with -mzarch -m31 -march=zEC12 as defaults passed. 108 testsuite > > fails got fixed. > > So are you going to apply it? I've started bootstraps also on s390x and x86_64. I'll post the patch after these complete successfully.
[Bug rtl-optimization/60508] [4.8/4.9 Regression] internal compiler error: in lra_set_insn_recog_data, at lra.c:1082
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60508 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #30 from Jakub Jelinek --- The #c29 patch now passed bootstrap/regtest on x86_64-linux and i686-linux. So, if it also fixes 435.gromacs on -mx32, I'll submit it to gcc-patches.
[Bug rtl-optimization/60508] [4.8/4.9 Regression] internal compiler error: in lra_set_insn_recog_data, at lra.c:1082
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60508 Jakub Jelinek changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org Target Milestone|--- |4.8.3 Summary|internal compiler error: in |[4.8/4.9 Regression] |lra_set_insn_recog_data, at |internal compiler error: in |lra.c:1082 |lra_set_insn_recog_data, at ||lra.c:1082 --- Comment #2 from Jakub Jelinek --- Started to ICE with r195902: pr60508.c: In function ‘fn1’: pr60508.c:29:1: error: unrecognizable insn: (insn 95 94 88 3 (set (reg/v:QI 4 si [orig:84 i ] [84]) (subreg:QI (subreg:SI (reg:DI 2 cx [126]) 0) 0)) pr60508.c:14 -1 (nil)) pr60508.c:29:1: internal compiler error: in extract_insn, at recog.c:2164 On 4.8 branch with release checking the ICE is: pr60508.c:29:1: internal compiler error: in subreg_get_info, at rtlanal.c:3278 Starting with r206023 it is: pr60508.c:29:1: internal compiler error: in lra_set_insn_recog_data, at lra.c:1081 rather than ICE about unrecognizable insn.
[Bug rtl-optimization/60501] [4.9 regression] LRA emits add patterns which might clobber cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60501 Jakub Jelinek changed: What|Removed |Added Severity|critical|major
[Bug rtl-optimization/60501] [4.9 regression] LRA emits add patterns which might clobber cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60501 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- (In reply to Andreas Krebbel from comment #2) > Bootstrap with -mzarch -m31 -march=zEC12 as defaults passed. 108 testsuite > fails got fixed. So are you going to apply it?
[Bug tree-optimization/60454] [4.7/4.8 Regression] Code mistakenly detected as doing bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] Code |Code mistakenly detected as |mistakenly detected as |doing bswap |doing bswap --- Comment #7 from Jakub Jelinek --- I've applied the patch so that this should now be fixed on the trunk.
[Bug rtl-optimization/60508] internal compiler error: in lra_set_insn_recog_data, at lra.c:1082
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60508
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-12
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Cleaned up testcase:
int a = 1, g, h = 1, d, e, *f;
char b;
static int c[] = { 0, 0 };
void fn2 (void);
void
fn1 (short x, int l)
{
lab:
{
int k, m[0];
long j = h ? 0 : 0 / 0;
unsigned char n = j;
unsigned char i = x >= 0 ? n : n >> x;
g = i;
for (;;)
{
if (a)
goto lab;
while (d)
{
e = b = c[l];
fn2 ();
}
int o = m[0];
f = &k;
}
}
}
m[0] is undefined behavior of course, but with the above global variables
unchanged and x >= 0 argument the function should be just endless loop without
triggering undefined behavior.
[Bug fortran/60509] New: Passing an array of derived type gives wrong boundaries when using 'class'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60509 Bug ID: 60509 Summary: Passing an array of derived type gives wrong boundaries when using 'class' Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.vogt at fulguritus dot com Created attachment 32340 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32340&action=edit Sample code When passing an array of derived type variables to a procedure, I get wrong the wrong results from lbound and ubound when the array is declared as class(myType). Using type(myType) is working as expected. An example is attached. I'm using: gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20131212/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
[Bug target/60264] ARM ICE in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1090
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60264 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from chrbr at gcc dot gnu.org --- on trunk #208511
[Bug target/60264] ARM ICE in dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1090
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60264 --- Comment #1 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Wed Mar 12 11:31:19 2014 New Revision: 208511 URL: http://gcc.gnu.org/viewcvs?rev=208511&root=gcc&view=rev Log: 2014-03-12 Christian Bruel PR target/60264 * config/arm/arm.c (arm_emit_vfp_multi_reg_pop): Emit a REG_CFA_DEF_CFA note. (arm_expand_epilogue_apcs_frame): call arm_add_cfa_adjust_cfa_note. (arm_unwind_emit): Allow REG_CFA_DEF_CFA. Added: trunk/gcc/testsuite/gcc.target/arm/pr60264.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/60508] New: internal compiler error: in lra_set_insn_recog_data, at lra.c:1082
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60508 Bug ID: 60508 Summary: internal compiler error: in lra_set_insn_recog_data, at lra.c:1082 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: eugeni.stepanov at gmail dot com Created attachment 32339 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32339&action=edit source code At r208400, GCC is failing with internal compiler error on the attached source generated with csmith. $ gcc -O -S z.c -w z.c: In function ‘fn1’: z.c:33:1: internal compiler error: in lra_set_insn_recog_data, at lra.c:1082 } ^ 0x8aa962 lra_set_insn_recog_data(rtx_def*) ../../gcc/lra.c:1080 0x8ab4cf lra_get_insn_recog_data ../../gcc/lra-int.h:464 0x8ab4cf lra_update_insn_regno_info ../../gcc/lra.c:1749 0x8ab4cf lra_update_insn_regno_info ../../gcc/lra.c:1740 0x8ab6b1 lra_push_insn_1 ../../gcc/lra.c:1802 0x8ab6b1 lra_push_insn(rtx_def*) ../../gcc/lra.c:1810 0x8ab89c push_insns ../../gcc/lra.c:1853 0x8abc65 lra_process_new_insns(rtx_def*, rtx_def*, rtx_def*, char const*) ../../gcc/lra.c:1898 0x8b9df6 curr_insn_transform ../../gcc/lra-constraints.c:3689 0x8bbb84 lra_constraints(bool) ../../gcc/lra-constraints.c:4157 0x8ac4d3 lra(_IO_FILE*) ../../gcc/lra.c:2340 0x86af0e do_reload ../../gcc/ira.c:5457 0x86af0e rest_of_handle_reload ../../gcc/ira.c:5598 0x86af0e execute ../../gcc/ira.c:5627
[Bug middle-end/60482] Loop optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482 --- Comment #7 from Yvan Roux --- Thanks for the quick fix Jakub.
[Bug target/58424] [ARM]gcc.target/arm/pr42575.c failed on arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58424 --- Comment #2 from bin.cheng --- Yes, It works for below combination of options: -mthumb -mcpu=cortex-m4 -mthumb/-marm -march=armv7-a/-mcpu=cortex-a7 But still happens for: -mthumb -mcpu=cortex-m3 -mthumb/-marm -mcpu=cortex-a7/-mcpu=cortex-a12/-mcpu=cortex-a9/-mcpu=cortex-a15 Maybe it has something to do with the rtx cost. I will look into it later.
[Bug regression/60363] [4.9 Regression]: logical_op_short_circuit, gcc.dg/tree-ssa/ssa-dom-thread-4.c scan-tree-dump-times dom1 "Threaded" 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60363 --- Comment #7 from bin.cheng --- The problem has nothing to do with VRP, and might be a missed opportunity of jump threading. The dump after VRP but before jump threading at the end of VRP is like: ... : goto ; ... : # kill_elt_3 = PHI if (b_elt_11(D) != 0B) goto ; else goto ; : if (kill_elt_3 != 0B) goto ; else goto ; : goto ; ... : # changed_19 = PHI # kill_elt_18 = PHI : # changed_1 = PHI # kill_elt_4 = PHI if (a_elt_9(D) != 0B) goto ; else goto ; There is jump threading path like: Registering jump thread: (21, 7) incoming edge; (7, 8) joiner; (8, 22) normal; After jump threading, the dump is like: : # kill_elt_2 = PHI if (kill_elt_2 != 0B) goto ; else goto ; : goto ; ... : # changed_19 = PHI # kill_elt_18 = PHI : # changed_1 = PHI # kill_elt_4 = PHI if (a_elt_9(D) != 0B) goto ; else goto ; ... : goto ; : # kill_elt_41 = PHI <0B(21)> if (b_elt_11(D) != 0B) goto ; else goto ; During jump threading process, GCC updates phi node in destination basic block like "kill_elt_18 = PHI <". Because bb27 is duplicated from bb7, the phi argument "kill_elt_3(27)" is copied directly from "kill_elt_3(7)". Although "kill_elt_3 == 0" holds when coming from edge , gcc doesn't know this fact. At last, cfgcleanup tries to remove forwarder block bb26, but it can't make it because the phi arguments from edge and edge doesn't match. I am thinking maybe jump threading can back trace the threading path and try to add phi argument for edge with the value(0) of kill_elt_3 (i.e., "0(27)"). The value is available along the jump threading path.
[Bug middle-end/60482] Loop optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/60502] [4.8 Regression] ICE reassociation and vector types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60502 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Known to work||4.9.0 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[4.8/4.9 Regression] ICE|[4.8 Regression] ICE |reassociation and vector|reassociation and vector |types. |types. Known to fail||4.8.2 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/60454] [4.7/4.8/4.9 Regression] Code mistakenly detected as doing bswap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60454 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Wed Mar 12 10:15:29 2014 New Revision: 208509 URL: http://gcc.gnu.org/viewcvs?rev=208509&root=gcc&view=rev Log: PR tree-optimization/60454 * tree-ssa-math-opts.c (find_bswap_1): Fix bswap detection. * gcc.c-torture/execute/pr60454.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr60454.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c
[Bug rtl-optimization/60501] [4.9 regression] LRA emits add patterns which might clobber cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60501 --- Comment #4 from Andreas Krebbel --- (In reply to Richard Biener from comment #1) > Do you have a testcase? I've tried for a while to reduce one but failed. Only under rare circumstances GCC seems to be able to reuse the cc from the first compare at all. With only slightly modifying the testcase the second compare stayed and the result was ok.
[Bug rtl-optimization/60501] [4.9 regression] LRA emits add patterns which might clobber cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60501 --- Comment #3 from Andreas Krebbel --- (In reply to Andreas Krebbel from comment #0) ... > no lra: > 4982a6: eb e6 00 01 00 df sllk%r14,%r6,1 ... > lra: > 49823e: eb 9e 00 01 00 df sllk%r9,%r14,1 <-- cc set ... Correction: cc is actually set by a compare directly before the sllk. sllk itself does not set cc.
[Bug tree-optimization/60505] Warning caused by GCC vectorizer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60505 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Why would out[num] = ovec[num/2]; imply num < 16? The loop implies num <= 16, and out[num] = ovec[num/2]; just implies num >= 0 && num <= 31.
[Bug ada/60504] [4.9 regression] many Ada testsuite regressions with gcc-4.9-20140309 on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60504 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug tree-optimization/60502] [4.8/4.9 Regression] ICE reassociation and vector types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60502 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Wed Mar 12 09:21:59 2014 New Revision: 208507 URL: http://gcc.gnu.org/viewcvs?rev=208507&root=gcc&view=rev Log: PR tree-optimization/60502 * tree-ssa-reassoc.c (eliminate_not_pairs): Use build_all_ones_cst instead of build_low_bits_mask. * gcc.c-torture/compile/pr60502.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr60502.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-reassoc.c
[Bug tree-optimization/60505] Warning caused by GCC vectorizer.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60505 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-12 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed for the warning. Note that 'out[num] = ovec[num/2];' at the end means that num < 16(!) and thus the vectorized loop is never entered (which means we likely warn for in practice dead code).
[Bug middle-end/60482] Loop optimization regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60482 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Wed Mar 12 09:15:08 2014 New Revision: 208506 URL: http://gcc.gnu.org/viewcvs?rev=208506&root=gcc&view=rev Log: PR middle-end/60482 * tree-vrp.c (register_edge_assert_for_1): Don't add assert if there are multiple uses, but op doesn't live on E edge. * tree-cfg.c (assert_unreachable_fallthru_edge_p): Also ignore clobber stmts before __builtin_unreachable. * gcc.dg/vect/pr60482.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr60482.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-vrp.c
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #29 from Jakub Jelinek --- Created attachment 32338 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32338&action=edit gcc49-pr60418.patch New version of the patch, going to bootstrap/regtest it momentarily. H.J., could you please check if this also fixes the gromacs -mx32 issue?
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #28 from rguenther at suse dot de --- On Tue, 11 Mar 2014, hjl.tools at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 > > --- Comment #26 from H.J. Lu --- > This patch avoids removing preheader when optimizing since > preheader will be added back later even if it is removed: > > diff --git a/gcc/tree-cfgcleanup.c b/gcc/tree-cfgcleanup.c > index 926d300..af5b24b 100644 > --- a/gcc/tree-cfgcleanup.c > +++ b/gcc/tree-cfgcleanup.c > @@ -328,7 +328,10 @@ tree_forwarder_block_p (basic_block bb, bool phi_wanted) > (LOOPS_MAY_HAVE_MULTIPLE_LATCHES)); >} > else if (bb->loop_father == loop_outer (dest->loop_father)) > - return !loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS); > + /* Preserve preheader when optimizing since it will be added > + back later. */ > + return !(optimize > + || loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)); > /* Always preserve other edges into loop headers that are > not simple latches or preheaders. */ > return false; HJ, these patches don't make sense - this patch will regress the testcase the code above was introduced for.
[Bug middle-end/60418] [4.9 Regression] 435.gromacs in SPEC CPU 2006 is miscompiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60418 --- Comment #27 from Jakub Jelinek --- basic_block bbb = gimple_bb (SSA_NAME_DEF_STMT (oea->op)); in the patch contains a pasto, which I guess can explain most if not all the -fcompare-debug failures. That said, thinking more about it, there still could be -fcompare-debug differences, because debug stmts also get uids and sometimes when inserting stmts the previous stmt uid is used, sometimes next stmt uid, so we probably should use reassoc_stmt_dominates_stmt_p.
[Bug fortran/60507] New: Passing real expression into procedure argument not caught
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60507 Bug ID: 60507 Summary: Passing real expression into procedure argument not caught Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com This compiles fine with the trunk and crashes at runtime: print *, f(g(x)) contains real function f(fun) procedure(g) :: fun f = fun(1.) end real function g(x) real, intent(in) :: x end end Similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25147
