[Bug fortran/56872] New: Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 Bug #: 56872 Summary: Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: towns...@astro.wisc.edu The attached code gives the incorrect results when compiled with -ffrontend-optimize (either explicitly, or via use of one of the -O flags). Correct behavior: $ gfortran -o sum_bug sum_bug.f90 $ ./sum_bug 1. 1000.0 1001.0 Incorrect behavior (i): $ gfortran -O2 -o sum_bug sum_bug.f90 $ ./sum_bug 1. 1000.0 1.0005E-03 Incorrect behavior (ii): $ gfortran -ffrontend-optimize -o sum_bug sum_bug.f90 $ ./sum_bug 1. 1000.0 Infinity gfortran -v gives: Using built-in specs. COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper Target: x86_64-apple-darwin11.4.2 Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0' --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk --with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.9.0 20130404 (experimental) (GCC)
[Bug fortran/56872] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 --- Comment #1 from Rich Townsend townsend at astro dot wisc.edu 2013-04-08 06:02:42 UTC --- Created attachment 29821 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29821 Test program to reproduce the error
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #23 from Kostya Serebryany kcc at gcc dot gnu.org 2013-04-08 06:32:45 UTC --- (In reply to comment #22) Has this been resolved in the final 4.8.0 (r196952)? I checked some changes and they seems to be in. I have a number (100) C++/C packages (incl. boost 1.51.00) compiled w/o address sanitizer and I am only enabling it for the main software using all these packages. Yet compilation fails of the main software segflaut from David, please provide more info on the segfault. E.g. run with env. var. ASAN_OPTIONS=verbosity=1 and also disassemble the failing instruction in gdb. I suspect that the non-instrumented code runs before __asan_init_v1 and then calls instrumented code. This will never work. You need to make sure that __asan_init_v1 is called before any instrumented code. One way: put this function into the preinint array; this is automatically done if you use -static-libasan; you can do it manually in your main module. Another way: instrument everything.
[Bug objc/56870] @catch handler broken with SEH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56870 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC|js-gcc at webkeks dot org |ktietz at gcc dot gnu.org --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2013-04-08 06:47:46 UTC --- (In reply to comment #1) Why was this lowered to normal? This is a regression, code that worked fine with GCC 4.7 now just crashes. It makes ObjC code that uses exceptions unusable, as it only crashes. Because ObjC is not a release blocking language, and windows is not a primary platform. That doesn't mean it won't be fixed, that depends on whether someone is volunteering to fix this, just like for any other bug report.
[Bug objc/56870] @catch handler broken with SEH
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56870 --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org 2013-04-08 06:51:58 UTC --- Hmm, this bug looks like a duplicate of PR/56742 Could you test if provided patch in PR/56742 fixes your issue?
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-08 06:56:30 UTC --- One way: put this function into the preinint array; this is automatically done if you use -static-libasan; That is actually done whenever the binary is linked with -fsanitize=address, no matter whether -static-libasan is used also or not. Just readelf -d binary | grep PREINIT to verify.
[Bug tree-optimization/48642] ICE: in omega_add_zero_eq, at omega.h:259 with -O -fcheck-data-deps --param omega-max-eqs=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48642 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-08 CC||mpolacek at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.8.0, 4.9.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-08 07:20:56 UTC --- Confirmed (all active branches).
[Bug tree-optimization/48482] ICE: in omega_alloc_problem, at omega.c:5498 with -fcheck-data-deps --param omega-max-vars=1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48482 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-08 CC||mpolacek at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.8.0, 4.9.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-08 07:22:12 UTC --- Confirmed (all active branches).
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2013-04-08 07:38:26 UTC --- (In reply to comment #2) I can't test this because I have no access to alpha hardware. The testsuite results [1] are OK. [1] http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg00797.html
[Bug rtl-optimization/48182] ICE: SIGSEGV in try_crossjump_to_edge (cfgcleanup.c:1703) with --param min-crossjump-insns=0 on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48182 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-08 07:46:04 UTC --- Author: mpolacek Date: Mon Apr 8 07:44:33 2013 New Revision: 197564 URL: http://gcc.gnu.org/viewcvs?rev=197564root=gccview=rev Log: PR rtl-optimization/48182 * params.def (PARAM_MIN_CROSSJUMP_INSNS): Increase the minimum value to 1. Modified: trunk/gcc/ChangeLog trunk/gcc/params.def
[Bug rtl-optimization/48182] ICE: SIGSEGV in try_crossjump_to_edge (cfgcleanup.c:1703) with --param min-crossjump-insns=0 on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48182 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-08 07:48:25 UTC --- Author: mpolacek Date: Mon Apr 8 07:47:21 2013 New Revision: 197565 URL: http://gcc.gnu.org/viewcvs?rev=197565root=gccview=rev Log: PR rtl-optimization/48182 * params.def (PARAM_MIN_CROSSJUMP_INSNS): Increase the minimum value to 1. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/params.def
[Bug rtl-optimization/48182] ICE: SIGSEGV in try_crossjump_to_edge (cfgcleanup.c:1703) with --param min-crossjump-insns=0 on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48182 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-08 07:48:39 UTC --- Fixed.
[Bug tree-optimization/48443] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprefetch-loop-arrays --param l2-cache-size=0 and setjmp()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48443 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-08 07:53:43 UTC --- Still happens, but only with 4.6.4. And the branch will be closed soon, so I'm not sure whether this one will be fixed...
[Bug inline-asm/43998] inline assembler: can't set clobbering for input register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43998 Ilya Lesokhin ilya.lesokhin at gmail dot com changed: What|Removed |Added CC||ilya.lesokhin at gmail dot ||com --- Comment #13 from Ilya Lesokhin ilya.lesokhin at gmail dot com 2013-04-08 08:04:28 UTC --- Andrew Pinski said: Use an output register that says it clobbers that register. This indeed works for normal inline assembler, but it doesn't work for asm goto which currently doesn't have outputs. maybe the Bug should be reopened for newer versions of GCC?
[Bug c++/56871] [c++11] Specialization of constexpr Templated Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56871 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-08 Ever Confirmed|0 |1
[Bug preprocessor/47047] Support for path translation in __FILE__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47047 --- Comment #6 from Joerg Sonnenberger joerg at netbsd dot org 2013-04-08 08:11:45 UTC --- Nothing has changed. It likely needs updates to apply to GCC 4.8+, but the general functionality is still desirable, IMO.
[Bug fortran/56261] [OOP] seg fault call procedure pointer on polymorphic array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56261 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-08 08:11:44 UTC --- (See also thread ending with http://gcc.gnu.org/ml/fortran/2013-04/msg00048.html) Regarding comment 1, using procedure( ), pointer :: f = ff as well as something like external :: ggg procedure(ff), pointer :: f = ggg is invalid as ff has a class dummy argument, which mandates an explicit interface (F2008, 12.4.2.2, (2)(a); cf. comment 6) and Fortran 2008 demands: If the characteristics of the pointer object or the pointer target are such that an explicit interface is required, both the pointer object and the pointer target shall have an explicit interface. (para 4 of 7.2.2.4 Procedure pointer assignment) [Those aren't constraints, hence, the compiler is not required to diagnose it - nor can it do so in general. However, if the explicit interface of ff is available, as comment 1, it can. Thus, a diagnostic would be nice.]
[Bug middle-end/48579] ICE: verify_flow_info: too many outgoing branch edges from bb 3 with asm goto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48579 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-08 08:13:19 UTC --- Not an ICE anymore.
[Bug middle-end/56113] out of memory when compiling a function with many goto labels (50k )
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56113 --- Comment #33 from Richard Biener rguenth at gcc dot gnu.org 2013-04-08 08:37:22 UTC --- (In reply to comment #32) Hi, guys I have a couple of questions regarding the case. i) What is the current status of the fix? is this fixed or still open? It's still open, there are bits that can be still improved. ii) If it is fixed, - how many nodes now it can scale? No idea, you have to try. It depends on the amount of compile-time/memory you have available. - What version of gcc comes with the patch/fix applied? GCC 4.8.0 contains some fixes that should help -O1 requirements. GCC 4.9 will contain further fixes. Thanks a lot for your help! /Kangkook
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/56871] [c++11] Specialization of constexpr Templated Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56871 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-08 09:33:39 UTC --- Seems easy.
[Bug tree-optimization/48762] valgrind: Invalid read/write of size 8 in cse_main with -O --param max-cse-path-length=0 on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48762 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-08 CC||mpolacek at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-08 10:43:29 UTC --- Confirmed. Looking into it.
[Bug middle-end/56848] [4.7 Regression] ICE (segfault) with the 4.7.3 release candidate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56848 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-04-08 11:07:22 UTC --- Fixed.
[Bug c/56851] Segmentation Error using -O3 optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56851 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-04-08 11:07:55 UTC --- Dup. *** This bug has been marked as a duplicate of bug 55964 ***
[Bug tree-optimization/55964] [4.7 Regression] Segmentation fault with -O -ftree-loop-distribution -funswitch-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55964 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||john at jbeidl dot com --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org 2013-04-08 11:07:55 UTC --- *** Bug 56851 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/56854] [4.9 Regression] error: non-decl/MEM_REF LHS in clobber statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56854 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|c++ |tree-optimization Target Milestone|--- |4.9.0 Summary|error: non-decl/MEM_REF LHS |[4.9 Regression] error: |in clobber statement|non-decl/MEM_REF LHS in ||clobber statement --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-04-08 11:09:28 UTC --- It's very likely forwprop that does this. We should probably disallow any forwprop into CLOBBER lhs. CCP will do everything that is allowed.
[Bug target/56863] cmpnltpd recognition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56863 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-08 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-04-08 11:10:31 UTC --- Confirmed.
[Bug c++/56869] [4.7 Regression] ICE (segfault) Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56869 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-04-08 Target Milestone|--- |4.7.3 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-04-08 11:14:25 UTC --- works for me on the 4.7 branch (x86_64-linux) with preprocessed source from using 4.7.2. So it might be triggered by a libstdc++ change? Can you attach preprocessed source?
[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect Vectorizing an unaligned access 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56865 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/56864] [4.9 regression] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vect vectorized 1 loops 0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56864 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug libffi/56033] FAIL: libffi.call/cls_struct_va1.c on powerpc-*-* and sparc-sun-solaris2* with -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56033
Andreas Krebbel krebbel at gcc dot gnu.org changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comment #5 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-04-08
11:19:16 UTC ---
Confirmed for s390x.
Looks like an endianess issue to me. In cls_struct_va1.c the void pointer to
the return value is cast to an int pointer before writing to it:
static void
test_fn (ffi_cif* cif __UNUSED__, void* resp,
void** args, void* userdata __UNUSED__)
{
...
* (int*) resp = 42;
}
But the pointer later on is expected to point to a register size value.
There are also testcases which do it differently (e.g. closure_fn0.c). They
cast the pointer to the return value to ffi_arg* before accessing it. ffi_arg
is defined to be a register size type. From the documentation I cannot tell
which one is supposed to be correct.
static void
closure_test_fn0(ffi_cif* cif __UNUSED__, void* resp, void** args,
void* userdata)
{
*(ffi_arg*)resp = ...
}
Btw. for both examples the return type is defined as ffi_type_sint in
ffi_prep_cif
[Bug c++/56869] [4.7 Regression] ICE (segfault) Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56869 --- Comment #3 from Matthias Klose doko at gcc dot gnu.org 2013-04-08 11:19:50 UTC --- Created attachment 29822 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29822 preprocessed source
[Bug c++/56869] [4.7 Regression] ICE (segfault) Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56869 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever Confirmed|1 |0
[Bug libffi/56033] FAIL: libffi.call/cls_struct_va1.c on powerpc-*-* and sparc-sun-solaris2* with -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56033
--- Comment #6 from Andreas Krebbel krebbel at gcc dot gnu.org 2013-04-08
11:24:22 UTC ---
Just noticed the example in libffi documentation which suggests that casting to
the return type pointer should work:
/* Acts like puts with the file given at time of enclosure. */
void puts_binding(ffi_cif *cif, unsigned int *ret, void* args[],
FILE *stream)
@{
*ret = fputs(*(char **)args[0], stream);
@}
[Bug fortran/56872] [4.8/4.9 Regression] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-04-08 CC||Joost.VandeVondele at mat ||dot ethz.ch Known to work||4.7.2 Summary|Incorrect SUM evaluation, |[4.8/4.9 Regression] |involving implied-do loop, |Incorrect SUM evaluation, |with -ffrontend-optimize|involving implied-do loop, ||with -ffrontend-optimize Ever Confirmed|0 |1 Known to fail||4.8.0, 4.9.0
[Bug tree-optimization/56873] New: vector shift lowered to scalars
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56873
Bug #: 56873
Summary: vector shift lowered to scalars
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu
#define SIZE 32
typedef long long veci __attribute__((vector_size(SIZE)));
veci f(veci a, veci b){
return ab;
}
Compiling this with -O3 -mxop, the vector lowering pass gives scalar
operations. However, if SIZE is either 16 or 64, I get vector shifts of size
16.
[Bug other/55274] gcc build hangs on HP-UX 11.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55274 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2013-04-08 11:41:47 UTC --- Should be fixed with this commit: http://gcc.gnu.org/ml/gcc-cvs/2013-04/msg00283.html Don't know why the normal commit messages aren't showing up.
[Bug c++/56874] New: Argument deduction failure with lambda and default template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56874
Bug #: 56874
Summary: Argument deduction failure with lambda and default
template argument
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
CC: ja...@gcc.gnu.org
I believe the following code, based on the std::function implementation in
libstdc++, should compile:
templatetypename T
T declval();
templatetypename T
struct function
{
templatetypename F, typename = decltype(declvalF() ())
function(F)
{ }
};
struct V {
typedef int value_type;
};
template typename C
void map(C, functiontypename C::value_type)
{
}
int main()
{
V v;
map(v, []() { });
}
f.cc: In function 'int main()':
f.cc:24:18: error: no matching function for call to 'map(V,
main()::__lambda0)'
map(v, []() { });
^
f.cc:24:18: note: candidate is:
f.cc:17:6: note: templateclass C void map(C, functiontypename
C::value_type)
void map(C, functiontypename C::value_type)
^
f.cc:17:6: note: template argument deduction/substitution failed:
f.cc:24:18: note: 'main()::__lambda0' is not derived from 'functiontypename
C::value_type'
map(v, []() { });
^
This modified version compiles OK, but whether we say functionint or
functiontypename C::value_type should not affect deduction of F from the
lambda:
templatetypename T
T declval();
templatetypename T
struct function
{
templatetypename F, typename = decltype(declvalF() ())
function(F)
{ }
};
struct V {
typedef int value_type;
};
template typename C
void map(C, functionint)
{
}
int main()
{
V v;
map(v, []() { });
}
[Bug target/56875] New: vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875
Bug #: 56875
Summary: vax target miscompiles short negative constants for
64bit values
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@netbsd.org
Created attachment 29823
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29823
Use the D format specifie for ashqs second arg
The documentation for VAX operand formatting codes says:
D64-bit immediate operand
and:
/* The purpose of D is to get around a quirk or bug in vax assembler
whereby -1 in a 64-bit immediate operand means 0x,
which is not a 64-bit minus one. */
However, the ashq instruction patters do not use this properly.
This small test program triggers it:
#include stdio.h
#include inttypes.h
int main(int argc, char **argv)
{
size_t i;
uint64_t v, nv;
for (i = 0; i 16; i++) {
v = ~(uint64_t)0 i;
nv = ~v;
printf(%zu: mask %08llx not %08llx\n, i, v, nv);
}
return 0;
}
The relevant line from assembly:
ashq %r6,$-1,%r2
which is misinterpreted by the assembler, so dissasembly is:
10637: 79 56 8f ff ashq r6,$0x,r2
1063b: ff ff ff 00
1063f: 00 00 00 52
The attached patch fixes it.
[Bug tree-optimization/48762] valgrind: Invalid read/write of size 8 in cse_main with -O --param max-cse-path-length=0 on basic code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48762 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Version|4.7.0 |4.8.1 AssignedTo|unassigned at gcc dot |mpolacek at gcc dot gnu.org |gnu.org | --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org 2013-04-08 12:09:17 UTC --- Patch posted.
[Bug fortran/56867] Missing temporary with string array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56867 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-08 12:17:16 UTC --- gfortran seems to be in good company. I get 23cd 2334 33yz using gfortran 4.1, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9. But also using NAG, pathf95 and pgf95. While g95, sunf95, crayftn and ifort have the correct result: 23cd 2334 23yz The issue (or at least the fix) could be related to PR47674, where also no temporary is generated for a substring. (That code could be handled without temporary, but using a temporary is probably the simplest. In any case, alias analysis fails as well.)
[Bug c++/56874] Argument deduction failure with lambda and default template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56874 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-08 12:21:29 UTC --- Possibly a dup of PR 52072 (and PR 53446)
[Bug c++/56874] Argument deduction failure due to non-deduced context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56874
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Summary|Argument deduction failure |Argument deduction failure
|with lambda and default |due to non-deduced context
|template argument |
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-08
13:01:44 UTC ---
Reduced to remove the lambda and default template argument:
templatetypename T
struct function
{
function(int)
{ }
};
struct V {
typedef int value_type;
};
template typename C
void map(C, functiontypename C::value_type)
{
}
int main()
{
V v;
map(v, 1);
}
[Bug c++/34949] Dead code in empty destructors.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution||FIXED
--- Comment #32 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-08
13:50:42 UTC ---
Author: jakub
Date: Mon Apr 8 13:46:00 2013
New Revision: 197580
URL: http://gcc.gnu.org/viewcvs?rev=197580root=gccview=rev
Log:
PR c++/34949
PR c++/50243
* tree-eh.c (optimize_clobbers): Only remove clobbers if bb doesn't
contain anything but clobbers, at most one __builtin_stack_restore,
optionally debug stmts and final resx, and if it has at least one
incoming EH edge. Don't check for SSA_NAME on LHS of a clobber.
(sink_clobbers): Don't check for SSA_NAME on LHS of a clobber.
Instead of moving clobbers with MEM_REF LHS with SSA_NAME address
which isn't defaut definition, remove them.
(unsplit_eh, cleanup_empty_eh): Use single_{pred,succ}_{p,edge}
instead of EDGE_COUNT comparisons or EDGE_{PRED,SUCC}.
* tree-ssa-ccp.c (execute_fold_all_builtins): Remove clobbers
with MEM_REF LHS with SSA_NAME address.
* g++.dg/opt/vt3.C: New test.
* g++.dg/opt/vt4.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/opt/vt3.C
trunk/gcc/testsuite/g++.dg/opt/vt4.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c
trunk/gcc/tree-ssa-ccp.c
[Bug c++/50243] vtable for pure abstract class (interface) shouldn't be emitted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50243
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-08
13:51:07 UTC ---
Author: jakub
Date: Mon Apr 8 13:46:00 2013
New Revision: 197580
URL: http://gcc.gnu.org/viewcvs?rev=197580root=gccview=rev
Log:
PR c++/34949
PR c++/50243
* tree-eh.c (optimize_clobbers): Only remove clobbers if bb doesn't
contain anything but clobbers, at most one __builtin_stack_restore,
optionally debug stmts and final resx, and if it has at least one
incoming EH edge. Don't check for SSA_NAME on LHS of a clobber.
(sink_clobbers): Don't check for SSA_NAME on LHS of a clobber.
Instead of moving clobbers with MEM_REF LHS with SSA_NAME address
which isn't defaut definition, remove them.
(unsplit_eh, cleanup_empty_eh): Use single_{pred,succ}_{p,edge}
instead of EDGE_COUNT comparisons or EDGE_{PRED,SUCC}.
* tree-ssa-ccp.c (execute_fold_all_builtins): Remove clobbers
with MEM_REF LHS with SSA_NAME address.
* g++.dg/opt/vt3.C: New test.
* g++.dg/opt/vt4.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/opt/vt3.C
trunk/gcc/testsuite/g++.dg/opt/vt4.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-eh.c
trunk/gcc/tree-ssa-ccp.c
[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56812 --- Comment #12 from Yuri Rumyantsev ysrumyan at gmail dot com 2013-04-08 14:03:45 UTC --- Richard, We found out another issue related to your fix (r196872), namely for the attached test-case t1.c function vect_gen_niters_for_prolog_loop() uses non-invariant pointer (v1) for calculation of #iterations for prolog but before your fix it uses invariant pointer (x) for doing it and all these evaluations can be hoised out of outermost loop: before your fix bb 6: niters.3_17 = (unsigned int) len_7; vect_px.4_4 = x_24(D); _119 = (unsigned long) vect_px.4_4; _118 = _119 31; _117 = _118 2; _116 = -_117; _115 = (unsigned int) _116; _114 = _115 7; prolog_loop_niters.5_52 = MIN_EXPR niters.3_17, _114; after your fix bb 6: niters.3_17 = (unsigned int) len_7; vect_pv1.4_4 = v1_16; _119 = (unsigned long) vect_pv1.4_4; It leads to 7% performance regression on 482.sphinx3 from spec2006 (since #itertaions of outer loop is much more greater (4096) then #iteration of inner loop (13)). This can be reproduced with following options: -O3 -funroll-loops -ffast-math -march=corei7 -mavx
[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56812 --- Comment #13 from Yuri Rumyantsev ysrumyan at gmail dot com 2013-04-08 14:05:26 UTC --- Created attachment 29824 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29824 testcase The following optins were used to compile on x86: -O3 -funroll-loops -ffast-math -march=corei7 -mavx
[Bug fortran/56872] [4.8/4.9 Regression] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-04-08 14:07:07 UTC --- Revision 195140 (2013-01-14) is OK; revision 195192 (2013-01-15) is not. Usual suspect is revision 195179.
[Bug tree-optimization/56854] [4.9 Regression] error: non-decl/MEM_REF LHS in clobber statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56854
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-04-08
14:15:17 UTC ---
So like this?
Reducing testcase now...
--- tree-ssa-forwprop.c.jj12013-02-25 23:51:21.0 +0100
+++ tree-ssa-forwprop.c2013-04-08 16:12:37.908611768 +0200
@@ -826,7 +826,11 @@ forward_propagate_addr_expr_1 (tree name
integer_zerop (TREE_OPERAND (lhs, 1))
useless_type_conversion_p
(TREE_TYPE (TREE_OPERAND (def_rhs, 0)),
- TREE_TYPE (gimple_assign_rhs1 (use_stmt
+ TREE_TYPE (gimple_assign_rhs1 (use_stmt)))
+ /* Don't forward anything into clobber stmts if it would result
+ in the lhs no longer being a MEM_REF. */
+(!gimple_clobber_p (use_stmt)
+ || TREE_CODE (TREE_OPERAND (def_rhs, 0)) == MEM_REF))
{
tree *def_rhs_basep = TREE_OPERAND (def_rhs, 0);
tree new_offset, new_base, saved, new_lhs;
[Bug rtl-optimization/56876] New: Combine does not invent new moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56876
Bug #: 56876
Summary: Combine does not invent new moves
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu
Hello,
I am looking at this testcase:
typedef unsigned long long vec __attribute__((vector_size(16)));
vec g;
vec f1(vec a, vec b){
return ~ab;
}
vec f2(vec a, vec b){
return ~gb;
}
which compiles to:
f1:
pandn%xmm1, %xmm0
f2:
pcmpeqd%xmm0, %xmm0
pxorg(%rip), %xmm0
pand%xmm1, %xmm0
whereas I would like to get, like I do with the _mm_andnot_si128 builtin:
movdqag(%rip), %xmm0
pandn%xmm1, %xmm0
It seems that combine cannot match the pandn pattern because the first argument
is a memory load and not a register. In this case, it would be better if it
emitted a move to put it in a register so it can match, instead of giving up. I
don't know if there is a good way to characterize such situations where an
extra move is worth it.
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #5 from Richard Henderson rth at gcc dot gnu.org 2013-04-08 14:35:03 UTC --- They did used to exist during mach_reorg; they used to exist at rtl creation time. You cannot simply delete the code either, that produces wrong-code wrt fp exceptions. Of course, we've got wrong-code now, regressed from the last rtl exception rewrite. Uros, testing ev68 wouldn't even have executed this code. This is intended for ev4 and ev5, without the precise fp exceptions in ev6. You can test this code for ICEs on an ev68 host if you don't actually configure alphaev68-*-*, but you won't see any potential runtime failures either way. I briefly looked at what one would have to do with the current state of rtl exceptions, and I'm thinking that it might be easier to split out the trap shadow handling from machine_reorg and use the pass manager to insert a new pass after we've re-converted to eh region notes.
[Bug lto/56877] New: When using LTO and linking statically, coredumps contain unusable stack trace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56877 Bug #: 56877 Summary: When using LTO and linking statically, coredumps contain unusable stack trace Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: sp...@psybear.com Enabling LTO causes coredumps generated by programs which were statically linked to have unusable backtraces. Attached an example usecase: Linking statically, no LTO: $ gcc -static bt.c -o bt $ ./bt $ gdb bt core... (gdb) bt #0 0x00440179 in raise () #1 0x00405ea8 in abort () #2 0x00401754 in __assert_fail_base () #3 0x004017ae in __assert_fail () #4 0x00400f94 in main () Linking statically, with LTO: $ gcc -static -flto bt.c -o bt $ ./bt $ gdb bt core... (gdb) bt #0 0x0043f9c9 in raise () #1 0x00405428 in abort () #2 0x0020 in ?? () #3 0x in ?? () Adding -g or enabling other optimizations do not seem to change anything. Versions used: gcc (GCC) 4.8.0 GNU gdb (GDB) 7.5.1
[Bug lto/56877] When using LTO and linking statically, coredumps contain unusable stack trace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56877 --- Comment #1 from Dror Levin spatz at psybear dot com 2013-04-08 14:54:42 UTC --- Created attachment 29825 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29825 Simple program that generates coredump (using assert(0))
[Bug c++/56874] Argument deduction failure due to non-deduced context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56874 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-04-08 14:55:54 UTC --- I agree, it looks like bug 52072 to me.
[Bug tree-optimization/56854] [4.9 Regression] error: non-decl/MEM_REF LHS in clobber statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56854
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-04-08
15:03:19 UTC ---
(In reply to comment #3)
So like this?
Reducing testcase now...
--- tree-ssa-forwprop.c.jj12013-02-25 23:51:21.0 +0100
+++ tree-ssa-forwprop.c2013-04-08 16:12:37.908611768 +0200
@@ -826,7 +826,11 @@ forward_propagate_addr_expr_1 (tree name
integer_zerop (TREE_OPERAND (lhs, 1))
useless_type_conversion_p
(TREE_TYPE (TREE_OPERAND (def_rhs, 0)),
- TREE_TYPE (gimple_assign_rhs1 (use_stmt
+ TREE_TYPE (gimple_assign_rhs1 (use_stmt)))
+ /* Don't forward anything into clobber stmts if it would result
+ in the lhs no longer being a MEM_REF. */
+(!gimple_clobber_p (use_stmt)
+ || TREE_CODE (TREE_OPERAND (def_rhs, 0)) == MEM_REF))
{
tree *def_rhs_basep = TREE_OPERAND (def_rhs, 0);
tree new_offset, new_base, saved, new_lhs;
Yes.
[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56812 --- Comment #14 from Richard Biener rguenth at gcc dot gnu.org 2013-04-08 15:04:10 UTC --- (In reply to comment #13) Created attachment 29824 [details] testcase The following optins were used to compile on x86: -O3 -funroll-loops -ffast-math -march=corei7 -mavx Can you open a new bugreport for this please?
[Bug lto/56877] When using LTO and linking statically, coredumps contain unusable stack trace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56877 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-04-08 Ever Confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-04-08 15:08:20 UTC --- Seems to work for me, both with and without -g. I'm running on x86_64-linux with binutils 2.23.1 and use GNU ld. rguenther@murzim:/tmp gcc-4.8 -o t bt.c -static -flto rguenther@murzim:/tmp rm core rguenther@murzim:/tmp ./t t: bt.c:13: main: Assertion `0' failed. Aborted (core dumped) rguenther@murzim:/tmp gdb ./t core GNU gdb (GDB) SUSE (7.5.50.20130215-88.1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-suse-linux. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /tmp/t...done. [New LWP 25418] Core was generated by `./t'. Program terminated with signal 6, Aborted. #0 0x0043b675 in raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x0043b675 in raise (sig=optimized out) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x0040660b in abort () at abort.c:93 #2 0x00401a5e in __assert_fail_base (fmt=optimized out, assertion=0x483609 0, file=0x483604 bt.c, line=13, function=optimized out) at assert.c:96 #3 0x00401ace in __assert_fail (assertion=0x483609 0, file=0x483604 bt.c, line=13, function=0x48360b __PRETTY_FUNCTION__.1856.2391.2391 main) at assert.c:105 #4 0x004011c4 in main () (gdb) please specify more details to reproduce this bug.
[Bug tree-optimization/55524] If fnma exists but not fms, convert_mult_to_fma should prefer to former over the latter.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55524 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #3 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2013-04-08 15:13:09 UTC --- A patch has been submitted: http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00456.html
[Bug c++/56869] [4.6/4.7 Regression] ICE (segfault) Error reporting routines re-entered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56869 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery Status|UNCONFIRMED |NEW Known to work|4.6.3, 4.7.2|4.5.2 Target Milestone|4.7.3 |4.6.4 Summary|[4.7 Regression] ICE|[4.6/4.7 Regression] ICE |(segfault) Error reporting |(segfault) Error reporting |routines re-entered |routines re-entered Ever Confirmed|0 |1 Known to fail||4.6.0, 4.6.3, 4.7.0 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-04-08 15:13:57 UTC --- Also fails with GCC 4.7.0 GCC 4.6 ICEs for me with in dependent_type_p, at cp/pt.c:18136 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (confused by earlier errors) 4.5 seems to work. Factoring in libstdc++ changes the point of the regression.
[Bug target/56564] movdqa on possibly-8-byte-aligned struct with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org 2013-04-08 15:22:21 UTC --- Mine.
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2013-04-08 15:32:47 UTC --- (In reply to comment #5) They did used to exist during mach_reorg; they used to exist at rtl creation time. You cannot simply delete the code either, that produces wrong-code wrt fp exceptions. Of course, we've got wrong-code now, regressed from the last rtl exception rewrite. Do you recall when that was? Must have been long, long ago... I've tried to find where it happened, and the rewrite was done before at least r43893 (Tue Jul 10 10:38:10 2001 UTC (11 years, 9 months ago). Does that mean alpha ev4 and ev5 fp exceptions have been broken for maybe 12 years? If that's really the case then I'd say the proper way forward is to remove support for those alpha variants as they're obviously not used and/or tested by anyone...
[Bug lto/56877] When using LTO and linking statically, coredumps contain unusable stack trace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56877 --- Comment #3 from Dror Levin spatz at psybear dot com 2013-04-08 15:36:11 UTC --- Using: - binutils 2.23.2, GNU ld - glibc 2.17 - x86_64, linux 3.8 - Arch linux Anything else that may be relevant?
[Bug tree-optimization/56878] New: Issue with candidate choice in vect_gen_niters_for_prolog_loop.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56878 Bug #: 56878 Summary: Issue with candidate choice in vect_gen_niters_for_prolog_loop. Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ysrum...@gmail.com We found out 7% performance drop on 482.sphinx3 from spec2006 for -march=corei7 -mavx which apeeared after fix r196872. The problem can be reproduced with the attached testcase. Function vect_gen_niters_for_prolog_loop() uses (after r196872) non-invariant pointer (v1) for calculation of #iterations for prolog but before it uses invariant pointer (x) for doing it and all these evaluations can be hoised out of outer loop: before fix bb 6: niters.3_17 = (unsigned int) len_7; vect_px.4_4 = x_24(D); _119 = (unsigned long) vect_px.4_4; _118 = _119 31; _117 = _118 2; _116 = -_117; _115 = (unsigned int) _116; _114 = _115 7; prolog_loop_niters.5_52 = MIN_EXPR niters.3_17, _114; Note that all these assignments can be hoisted out of loop. after fix bb 6: niters.3_17 = (unsigned int) len_7; vect_pv1.4_4 = v1_16; _119 = (unsigned long) vect_pv1.4_4; where v1 is not loop invariant. If trip count for outer loop is huge and trip count for inner loop is small such code motion can affect on performance dramatically. To reproduce compile attached test on x86 with the following options: -O3 -funroll-loops -ffast-math -march=corei7 -mavx
[Bug tree-optimization/56878] Issue with candidate choice in vect_gen_niters_for_prolog_loop.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56878 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com 2013-04-08 15:47:05 UTC --- Created attachment 29826 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29826 testcase Need to be compiled on x86 with the following options: -O3 -funroll-loops -ffast-math -march=corei7 -mavx
[Bug tree-optimization/56812] Simple loop is not SLP-vectorized after r196872
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56812 --- Comment #15 from Yuri Rumyantsev ysrumyan at gmail dot com 2013-04-08 15:48:45 UTC --- New bug has been opened for it: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56878
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #7 from Richard Henderson rth at gcc dot gnu.org 2013-04-08 15:52:13 UTC --- (In reply to comment #6) Do you recall when that was? Must have been long, long ago... I've tried to find where it happened, and the rewrite was done before at least r43893 (Tue Jul 10 10:38:10 2001 UTC (11 years, 9 months ago). I would have said it was much more recent than that, but I just checked gcc 4.2 and you're right that we'd already switched away from these notes somewhere prior to 2009. Does that mean alpha ev4 and ev5 fp exceptions have been broken for maybe 12 years? If that's really the case then I'd say the proper way forward is to remove support for those alpha variants as they're obviously not used and/or tested by anyone... It's not as bad as all that. It's only the extremely uncommon case of throwing a c++ exception in response to an fp exception, with a handler in the same function. My guess is that no one at all does this, and so the wrong-code is somewhat theoretical. Normal fp code without c++ exceptions is working fine. Which is why I would not suggest writing new eh code for this, but instead moving the existing code to later in the pass list where merely adding an insn is good enough to have the insn included in the region.
[Bug c/52773] internal error: in replace_pseudos_in, at reload1.c:577
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773 --- Comment #3 from Alan Hourihane alanh at fairlite dot co.uk 2013-04-08 15:52:47 UTC --- I can't build 4.7.2 on an m68k box because of this one.
[Bug target/56876] Combine does not invent new moves
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56876 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|rtl-optimization|target --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-04-08 15:53:40 UTC --- This sounds more like a target issue where prereload instructions are too strict.
[Bug fortran/56872] [4.8/4.9 Regression] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org Target Milestone|--- |4.8.1 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-08 16:07:22 UTC --- (In reply to comment #2) Revision 195140 (2013-01-14) is OK; revision 195192 (2013-01-15) is not. Usual suspect is revision 195179. That's for PR 55806, http://gcc.gnu.org/r195179
[Bug c++/56879] New: -Weffc++ warns about non-virtual base class destructor even if it is protected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56879 Bug #: 56879 Summary: -Weffc++ warns about non-virtual base class destructor even if it is protected Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ayurc...@gmail.com Created attachment 29827 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29827 test source code and compiler output Protected destructor means that the class can't be deleted polymorphically, so this warning is unnecessary. Together with -Werror it becomes a pain.
[Bug fortran/56872] [4.8/4.9 Regression] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-08 16:39:10 UTC --- Front-end optimization generates for print *,SUM([(s**(REAL(k-1)/REAL(m-1)),k=1,m)]) the code: D.1918 = s; D.1919 = __builtin_powf (D.1918, (((real(kind=4)) (k + -1) / (real(kind=4)) (m + -1; Completely ignoring that k is a loop variable, which is not even set.
[Bug c/56880] New: R_X86_64_COPY bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56880
Bug #: 56880
Summary: R_X86_64_COPY bug
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: fredrickprasha...@gmail.com
A struct with zero length array is defined in a shared library as a global
data.
A binary links with this shared library and accesses the struct.
Because of copy relocation semantics, the binary linking with that
library sees(correctly) only the portion of the struct without the
zero length array.
We understand that it is due to the wrong or apparent size calculation
of the struct by GCC and using copy relocation semantics to resolve this
shared symbol is causing this problem.
We saw this bug also on ARM with R_ARM_COPY.
test_misc.h:
#ifndef __TEST_MISC_H__
#define __TEST_MISC_H__
struct test_array {
int array_len;
int array[];
};
void print_array(struct test_array *);
#endif
test_lib.c:
#include test_misc.h
#include stdio.h
struct test_array test_dynamic = {
6,
{1, 2, 3, 4, 5, 6},
};
void
print_array(struct test_array *a) {
int i;
for (i = 0; ia-array_len; i++) {
printf(%d\n, a-array[i]);
}
}
test_misc.c:
#include test_misc.h
extern struct test_array test_dynamic;
int
main() {
print_array(test_dynamic);
return 0;
}
Makefile:
all: test_misc.bin
test_misc.bin: test_misc.o libtest.so
cc test_misc.o libtest.so -o test_misc.bin
libtest.so: test_lib.o
cc -shared -Wl,-soname,libtest.so -o libtest.so test_lib.o
test_lib.o: test_lib.c
cc -fPIC -o test_lib.o -c test_lib.c
.PHONY: clean
clean:
rm -rf test_misc.bin
rm -rf libtest.so
rm -rf *.o
$ LD_LIBRARY_PATH=. ./test_misc.bin
0
0
0
0
0
0
This seems to be a bug in GCC:
.globl test_dynamic
.data
.align 4
.type test_dynamic, @object
.size test_dynamic, 4
test_dynamic:
.long 6
.long 1
.long 2
.long 3
.long 4
.long 5
.long 6
[Bug other/56881] New: Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881 Bug #: 56881 Summary: Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: devs...@moreofthesa.me.uk Created attachment 29828 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29828 Source which triggers the problem at -O2 We (Unvanquished devs) have found what looks like an optimisation bug in gcc 4.8.0. The ‘offending’ code is this (lines 60 to 62 of src/tools/lcc/cpp/hideset.c): hs1 = (Hideset)domalloc(len*sizeof(Hideset)); memmove(hs1, nhs, len*sizeof(Hideset)); hidesets[nhidesets] = hs1; The allocation succeeds (domalloc is a malloc wrapper), the memmove is fine, but hs1 somehow becomes NULL. So next time this function is called, there's a NULL pointer which gets dereferenced a few lines above. Putting a function call in between the first two lines above works around the problem, as does swapping the latter two lines (as is done in https://github.com/Unvanquished/Unvanquished/commit/9157ac0d3668fc059ce001620bbfa45ccf66c8df). Pre-processed source is attached. I'm able to cause the problem with -Os, -O2 or -O3 but not -O0 or -O; I can try enabling or disabling specific optimisations. I'm using stock gcc-4.8 4.8.0-2 (Debian experimental), but another of us, an Arch user, is using core/gcc 4.8.0-1 (base-devel) and is seeing the same problem (which is why I'm reporting it here rather than in the Debian BTS). Architecture is amd64 in both cases.
[Bug c/56880] R_X86_64_COPY bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56880 --- Comment #1 from Fredrick fredrickprashanth at gmail dot com 2013-04-08 16:51:06 UTC --- Another related bug would be that, we tried to disable copy relocation using -z nocopyreloc. The binary crashed with SEGV. ./test_misc.bin: Symbol `test_dynamic' causes overflow in R_X86_64_32 relocation Segmentation fault (core dumped) -Fredrick
[Bug c/52773] internal error: in replace_pseudos_in, at reload1.c:577
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-04-08 17:11:50 UTC --- The ICE still occurs with gcc 4.6-20130405, 4.7-20130406, 4.8-20130404, and 4.9-20130407.
[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 pdande1 at dow dot com changed: What|Removed |Added CC||pdande1 at dow dot com --- Comment #1 from pdande1 at dow dot com 2013-04-08 17:13:19 UTC --- program characterconversions integer :: i=123 character(len=*) :: s write(s,*) i print *,s end program I am getting the below error while executing the above program (gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)) Error: Entity with assumed character length must be a dummy argument or a PARAMETER| ||=== Build finished: 1 errors, 0 warnings (0 minutes, 0 seconds) ===|
[Bug c++/56879] -Weffc++ warns about non-virtual base class destructor even if it is protected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56879 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Attachment #29827|application/octet-stream|text/plain mime type|| --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-08 17:15:59 UTC --- Comment on attachment 29827 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29827 test source code and compiler output The solution is simple: don't use -Weffc++, it's deeply flawed. Using it with -Werror is just ridiculous. It's much better to use -Wdelete-non-virtual-dtor than -Weffc++ There are lots of known issues with -Weffc++ and noone has been motivated to fix them, see e.g. PR 22395 comment 5 and PR 16166 comment 3 for some discussion related to this warning.
[Bug c++/56874] Argument deduction failure due to non-deduced context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56874 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-08 17:22:29 UTC --- Yes, I thought it was different but after reducing it I'm sure it's the same. *** This bug has been marked as a duplicate of bug 52072 ***
[Bug c++/52072] Several non-deduced contexts not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52072 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2013-04-08 17:22:29 UTC --- *** Bug 56874 has been marked as a duplicate of this bug. ***
[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 --- Comment #2 from Harald Anlauf anlauf at gmx dot de 2013-04-08 17:29:03 UTC --- (In reply to comment #1) program characterconversions integer :: i=123 character(len=*) :: s write(s,*) i print *,s end program I am getting the below error while executing the above program (gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)) Error: Entity with assumed character length must be a dummy argument or a PARAMETER| ||=== Build finished: 1 errors, 0 warnings (0 minutes, 0 seconds) ===| Your example has nothing to do with the original PR. It is also invalid code: you must not use assumed character length (i.e. len=*) in a main program.
[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 --- Comment #3 from pdande1 at dow dot com 2013-04-08 17:41:45 UTC --- (In reply to comment #2) (In reply to comment #1) program characterconversions integer :: i=123 character(len=*) :: s write(s,*) i print *,s end program I am getting the below error while executing the above program (gcc version 4.8.0 20130302 (experimental) [trunk revision 196403] (GCC)) Error: Entity with assumed character length must be a dummy argument or a PARAMETER| ||=== Build finished: 1 errors, 0 warnings (0 minutes, 0 seconds) ===| Your example has nothing to do with the original PR. It is also invalid code: you must not use assumed character length (i.e. len=*) in a main program. Hi Harald, I am newbie to fortran, Can you please explain me in detail with an example. Thanks in advance
[Bug c++/56871] [c++11] Specialization of constexpr Templated Function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56871 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-04-08 18:10:20 UTC --- Fixed for 4.9.0.
[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 --- Comment #4 from Harald Anlauf anlauf at gmx dot de 2013-04-08 18:16:06 UTC --- (In reply to comment #3) I am newbie to fortran, Can you please explain me in detail with an example. Thanks in advance Replace character(len=*) :: s in your code by e.g. character(len=20) :: s Then it will compile work. This is a general Fortran issue and has nothing to do with gfortran. Note: the bugzilla should not be used to learn about Fortran. Use a textbook about Fortran or the newsgroup comp.lang.fortran which you can access via google groups.
[Bug fortran/56872] [4.8/4.9 Regression] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | --- Comment #5 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-04-08 18:25:45 UTC --- I have a patch.
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #8 from Steven Bosscher steven at gcc dot gnu.org 2013-04-08 18:43:25 UTC --- (In reply to comment #7) (In reply to comment #6) Do you recall when that was? Must have been long, long ago... I've tried to find where it happened, and the rewrite was done before at least r43893 (Tue Jul 10 10:38:10 2001 UTC (11 years, 9 months ago). I would have said it was much more recent than that, but I just checked gcc 4.2 and you're right that we'd already switched away from these notes somewhere prior to 2009. Does that mean alpha ev4 and ev5 fp exceptions have been broken for maybe 12 years? If that's really the case then I'd say the proper way forward is to remove support for those alpha variants as they're obviously not used and/or tested by anyone... It's not as bad as all that. It's only the extremely uncommon case of throwing a c++ exception in response to an fp exception, with a handler in the same function. My guess is that no one at all does this, and so the wrong-code is somewhat theoretical. Normal fp code without c++ exceptions is working fine. Which is why I would not suggest writing new eh code for this, but instead moving the existing code to later in the pass list where merely adding an insn is good enough to have the insn included in the region. I really don't like that idea. As it is, these notes are already de facto alpha specific. The only references to these notes: Emitters: except.c: note = emit_note_before (NOTE_INSN_EH_REGION_BEG, except.c: note = emit_note_after (NOTE_INSN_EH_REGION_END, except.c: note = emit_note_before (NOTE_INSN_EH_REGION_BEG, except.c: note = emit_note_after (NOTE_INSN_EH_REGION_END, except.c: note = emit_note_before (NOTE_INSN_EH_REGION_BEG, iter); except.c: note = emit_note_after (NOTE_INSN_EH_REGION_END, last_action_insn); Printers / doc: print-rtl.c: case NOTE_INSN_EH_REGION_BEG: print-rtl.c: case NOTE_INSN_EH_REGION_END: sched-vis.c: case NOTE_INSN_EH_REGION_BEG: sched-vis.c: case NOTE_INSN_EH_REGION_END: insn-notes.def:INSN_NOTE (EH_REGION_BEG) insn-notes.def:INSN_NOTE (EH_REGION_END) doc/rtl.texi:@findex NOTE_INSN_EH_REGION_BEG doc/rtl.texi:@findex NOTE_INSN_EH_REGION_END doc/rtl.texi:@item NOTE_INSN_EH_REGION_BEG doc/rtl.texi:@itemx NOTE_INSN_EH_REGION_END Actual uses of the notes: final.c:case NOTE_INSN_EH_REGION_BEG: final.c:case NOTE_INSN_EH_REGION_END: config/alpha/alpha.c: case NOTE_INSN_EH_REGION_BEG: config/alpha/alpha.c: case NOTE_INSN_EH_REGION_END: FWIW my r43893 reference is based on inspection of toplev.c around that time. See e.g.: http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/toplev.c?revision=43872view=markup Just before integrate (RTL inlining!) there is a call on line 2801 to convert_from_eh_region_ranges () to come from INSN_NOTE based regions to REG_NOTE based regions. Just before shorten_branches, on line 3742, the INSN_NOTE representation is restored via convert_to_eh_region_ranges. The machine-dependent reorg pass runs before it, see line 3689. Continuing the archaeology a bit with svn blame -r43872 toplev.c: 40924 rth /* Convert from NOTE_INSN_EH_REGION style notes, and do other 40924 rthsorts of eh initialization. Delay this until after the 40924 rthinitial rtl dump so that we can see the original nesting. */ 40924 rth convert_from_eh_region_ranges (); and: 40924 rth 40924 rth convert_to_eh_region_ranges (); The commit log for http://gcc.gnu.org/r40924 (Mar 28 2001) is: IA-64 ABI Exception Handling. The part of alpha EH that depends on the notes must have been been broken since than, more than 12 years. Without anyone noticing... I really, really wouldn't like to keep this code in alpha alive, and with it these REG_EH_REGION notes, for barely (if at all) used ages-old alpha targets...
[Bug c/56882] New: ICE: when compiling gegl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56882 Bug #: 56882 Summary: ICE: when compiling gegl Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: xperie...@interia.pl Created attachment 29829 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29829 preprocessed file I'm using gentoo on AMD64 machine Pilediver core A10-4600M processor, when compiling gegl 0.2.0 I got, I was compiling it from time to time with older versions of gcc and that same set of CFLAGS, sometimes with problems or not, but that was the first time to ICE in compiler: gegl-processor.c: In function 'gegl_processor_get_property': gegl-processor.c:223:1: internal compiler error: Segmentation fault gegl_processor_get_property (GObject*gobject, - CFLAGS=-O3 -mtune=native -march=native -fomit-frame-pointer -pipe -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity -floop-parallelize-all -flto -fuse-linker-plugin -fPIC - ICE will not happen when I strip graphite flags - Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.8.0/work/gcc-4.8.0/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-isl-version-check --with-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.0/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.0 p1.1, pie-0.5.5' Thread model: posix gcc version 4.8.0 (Gentoo 4.8.0 p1.1, pie-0.5.5)
[Bug c++/56879] -Weffc++ warns about non-virtual base class destructor even if it is protected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56879 --- Comment #2 from alex ayurchen at gmail dot com 2013-04-08 19:06:47 UTC --- (In reply to comment #1) Comment on attachment 29827 [details] test source code and compiler output The solution is simple: don't use -Weffc++, it's deeply flawed. Using it with -Werror is just ridiculous. It's much better to use -Wdelete-non-virtual-dtor than -Weffc++ It is not what we've been using it for (-Wdelete-non-virtual-dtor seems to be enabled by -Wall already). We'd like to keep other warnings that -Weffc++ generates: it worked nicely for us until this point. There are lots of known issues with -Weffc++ and noone has been motivated to fix them, see e.g. PR 22395 comment 5 and PR 16166 comment 3 for some discussion related to this warning. Too bad. This one could probably be a one-liner to just disable this warning since -Wnon-virtual-dtor is already enabled with -Weffc++ (and it does a better job). But noone has been motivated says it all. Anyway, thanks for the pointers.
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #9 from Richard Henderson rth at gcc dot gnu.org 2013-04-08 19:27:03 UTC --- (In reply to comment #8) The part of alpha EH that depends on the notes must have been been broken since than, more than 12 years. Without anyone noticing... Sure. Do you know any package that combines C++ EH with IEEE exceptions? I don't. In fact, I don't actually know of a package that wants to enable trapping fp math at all. I really, really wouldn't like to keep this code in alpha alive, and with it these REG_EH_REGION notes, for barely (if at all) used ages-old alpha targets... Do you believe that you're going to be able to delete the notes entirely, and that it's only Alpha that's keeping them alive? That's certainly not true, I assure you.
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #10 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2013-04-08 19:42:51 UTC --- Sure. Do you know any package that combines C++ EH with IEEE exceptions? I don't. In fact, I don't actually know of a package that wants to enable trapping fp math at all. I barely know a thing about EH, or IEEE exceptions, let alone a combination or two. I'm a doc^Wn aerospace engineer, not a computer scientist. Do you believe that you're going to be able to delete the notes entirely, and that it's only Alpha that's keeping them alive? That's certainly not true, I assure you. Removing the notes entirely is the goal eventually, but I'd settle for making them local to final.c for now. What besides alpha and final are keeping these notes alive? You've probably seen my grep results, and at least from passes.c there doesn't seem to be anything between pass_convert_to_eh_region_ranges and pass_final that would use the INSN_NOTEs: NEXT_PASS (pass_convert_to_eh_region_ranges); NEXT_PASS (pass_shorten_branches); NEXT_PASS (pass_set_nothrow_function_flags); NEXT_PASS (pass_dwarf2_frame); NEXT_PASS (pass_final); AFAIU the only code transformations done in these passes are in shorten_branches that shouldn't care whether it's dealing with the REG_EH_REGION notes or the NOTE_INSN_EH_REGION notes. But my U in AFAIU is obviously no-where near your U when it comes to EH, so if you can explain a bit, I'd really appreciate it! :-) (On the topic of notes: note to self, kill NOTE_EH_CONTEXT.)
[Bug lto/54095] Unnecessary static variable renaming
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54095 --- Comment #16 from Jan Hubicka hubicka at gcc dot gnu.org 2013-04-08 19:49:49 UTC --- Created attachment 29830 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29830 Complette patchet I am attaching patch to reduce renaming. It hits few can of worms, so I will decompose it into smaller pieces and submit
[Bug fortran/56872] [4.8/4.9 Regression] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-04-08 20:02:09 UTC --- Fixed on trunk and 4.8. Thanks a lot for the bug report, and sorry for the breakage.
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #11 from Richard Henderson rth at gcc dot gnu.org 2013-04-08 20:09:47 UTC --- (In reply to comment #10) Removing the notes entirely is the goal eventually, but I'd settle for making them local to final.c for now. Hmm. Well, assuming we want to fix this correctly, and not just define ev[45] as no longer completely supported, we just have to write new code to emit the trap insns into the proper EH region. There's an overlap in effort in finding the region boundaries, but probably not so much as to worry about. I.e. really just the one lookup call and a pointer comparison.
[Bug fortran/56872] [4.8/4.9 Regression] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-08 20:10:54 UTC --- Author: tkoenig Date: Mon Apr 8 19:36:43 2013 New Revision: 197610 URL: http://gcc.gnu.org/viewcvs?rev=197610root=gccview=rev Log: 2013-04-08 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/56782 * frontend-passes.c (callback_reduction): Dont't do any simplification if there is only a single element which has an iterator. 2013-04-08 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/56782 * gfortran.dg/array_constructor_44.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_44.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/56872] [4.8/4.9 Regression] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-08 20:11:12 UTC --- Author: tkoenig Date: Mon Apr 8 20:01:33 2013 New Revision: 197612 URL: http://gcc.gnu.org/viewcvs?rev=197612root=gccview=rev Log: 2013-04-08 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/56782 Backport from trunk. * frontend-passes.c (callback_reduction): Dont't do any simplification if there is only a single element which has an iterator. 2013-04-08 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/56782 Backport from trunk. * gfortran.dg/array_constructor_44.f90: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/array_constructor_44.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/frontend-passes.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/56872] [4.8/4.9 Regression] Incorrect SUM evaluation, involving implied-do loop, with -ffrontend-optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56872 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-08 20:12:37 UTC --- (In reply to comment #6) Fixed on trunk and 4.8. Thanks a lot for the bug report, and sorry for the breakage. Thanks for the patch, Thomas. But please remember to also copy the commit message from http://gcc.gnu.org/ml/gcc-cvs/current - as the automatic appending stopped working with the server upgrade.
[Bug fortran/56849] Missing compile-time shape check for RESHAPE assignments with an ORDER= attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56849 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-08 20:13:47 UTC --- Author: burnus Date: Sun Apr 7 08:41:17 2013 New Revision: 197550 URL: http://gcc.gnu.org/viewcvs?rev=197550root=gccview=rev Log: 2013-04-07 Tobias Burnus bur...@net-b.de PR fortran/56849 * iresolve.c (gfc_resolve_reshape): Set shape also with order=. 2013-04-07 Tobias Burnus bur...@net-b.de PR fortran/56849 * gfortran.dg/reshape_5.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/reshape_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/iresolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/56849] Missing compile-time shape check for RESHAPE assignments with an ORDER= attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56849 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2013-04-08 20:14:07 UTC --- FIXED on the 4.9 trunk.
[Bug fortran/56867] Missing temporary with string array assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56867 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-04-08 20:23:59 UTC --- I stumbled across this while looking at PR 30398, when I wanted to add some dependency checking to make call memcpy instead of memmove if there was no dependency. Look for an optimization, find a bug... I have been working on the idea to add an argument to gfc_trans_scalar_assign (which does not know about the gfc_expr*s any more) which indicates if there coul be a dependency, which could be checked via gfc_check_dependency and then passed to gfc_trans_string_copy. This kind of analysis could also be used in PR 56594 to create a temporary.
[Bug fortran/56594] Invalid read of size 1 for gfortran.dg/realloc_on_assign_5.f03
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56594 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-04-08 20:25:49 UTC --- Dup of PR 47674. *** This bug has been marked as a duplicate of bug 47674 ***
[Bug fortran/47674] gfortran.dg/realloc_on_assign_5.f03: Segfault at run time for deferred (allocatable) string length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added CC||dominiq at lps dot ens.fr --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org 2013-04-08 20:25:49 UTC --- *** Bug 56594 has been marked as a duplicate of this bug. ***
