[Bug fortran/57894] New: min/max required actual argument missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57894 Bug ID: 57894 Summary: min/max required actual argument missing Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com ! required MIN/MAX actual argument associated with A2 is missing ! Exactly one actual argument shall be associated with each nonoptional dummy argument ! gfortran should reject this code i=min(a1=1,a3=2) ! a1 and a2 are nonoptional, a3 is optional i=max(a1=1,a3=2) ! a1 and a2 are nonoptional, a3 is optional end This is one is minor, but it should be fixed one day, just to adhere to the standard.
[Bug fortran/54070] Wrong code with allocatable deferred-length (array) function results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070 Vittorio Zecca zeccav at gmail dot com changed: What|Removed |Added CC||zeccav at gmail dot com --- Comment #4 from Vittorio Zecca zeccav at gmail dot com --- The following duplicates the ICE in gimplify_var_or_parm_decl: SUBROUTINE sub (n) INTEGER, INTENT(IN) :: n CHARACTER(LEN=n) :: s ASSOCIATE (mio = s) END ASSOCIATE END
[Bug fortran/52669] No warning in unused private variable in modules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52669 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Author: tkoenig Date: Sun Jul 14 19:16:56 2013 New Revision: 200950 URL: http://gcc.gnu.org/viewcvs?rev=200950root=gccview=rev Log: 2013-07-14 Thomas Koenig tkoe...@gcc.gnu.org Tobias Burnus bur...@gcc.gnu.org PR fortran/52669 * trans-decl.c (gfc_finish_var_decl): Move setting of PRIVATE for a module variable if the module has a private default or -fmodule-private is given to... (gfc_create_module_variable): here. Optionally warn about private module variable which is not used. 2013-07-14 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/52669 * fortran.dg/module_variable_1.f90: New test. * fortran.dg/module_variable_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/module_variable_1.f90 trunk/gcc/testsuite/gfortran.dg/module_variable_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/57895] New: Segmentation fault in gfc_restore_last_undo_checkpoint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57895 Bug ID: 57895 Summary: Segmentation fault in gfc_restore_last_undo_checkpoint Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Created attachment 30503 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30503action=edit Old dusty Fortran file The attached old dusty Fortran produces a Segmentation fault in gfc_restore_last_undo_checkpoint. Compiles fine with -fdollar-ok
[Bug fortran/57893] Crash for allocatable character string during compilation.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57893 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Known to work||4.8.1, 4.9.0 Resolution|--- |WONTFIX Known to fail||4.6.3, 4.7.3 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Unfortunately, the support of deferred-length character strings (len=:) is not yet perfect in gfortran; however, quite some progress has been made for GCC 4.8, which can also compile your example. Try GCC 4.8 or the currently being developed GCC 4.9 (trunk); see http://gcc.gnu.org/wiki/GFortranBinaries for some ways to obtain a binary and for a description how to compile GCC yourself. As it is no regression, the fix won't be backported to GCC 4.7 - and GCC 4.6 is no longer maintained.
[Bug c/57896] New: ICE in in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Bug ID: 57896 Summary: ICE in in expand_expr_real_2 Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Created attachment 30504 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30504action=edit C code causing an ICE in expand_expr_real_2 The attached code causes an ICE in in expand_expr_real_2, This is from testsuite/gcc.target/vperm-v4si-2.c The ICE is maybe due to wrong index at cfgexpand.c:4329 I put gcc_assert ((int) ((enum tree_code) (t)-base.code) sizeof_tree_code_type); before if (IS_TYPE_OR_DECL_P (t)) and I got the backtrace in the bottom of the attached file. I defined sizeof_tree_code_type in tree.h and tree.c const int sizeof_tree_code_type=sizeof(tree_code_type); I am sorry I was not able to produce a shorter test case.
[Bug fortran/44353] rejects legal fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44353 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Vittorio Zecca from comment #7) I believe this has been fixed with gfortran 4.8.1 Looks like. I think it was fixed by the commit for PR54958.
[Bug fortran/50376] pure procedure allows assignment to iterator variable in array constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50376 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- I believe this has been fixed in GCC 4.8 by the patch for PR54958. Close as FIXED.
[Bug c++/57897] New: pragma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 Bug ID: 57897 Summary: pragma Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dongsheng.song at gmail dot com Due to Bug 57848, I must build gcc 4.9 with '--with-arch=corei7', then the cross compiler building success. But when I use the cross compiler to build native compiler, it failed with: x86_64-w64-mingw32-g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/home/cauchy/vcs/svn/gcc/trunk/gcc -I/home/cauchy/vcs/svn/gcc/trunk/gcc/. -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./gmp -I/home/cauchy/vcs/svn/gcc/trunk/gmp -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpc/src -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid -I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./isl/include -I/home/cauchy/vcs/svn/gcc/trunk/isl/include -I. -I. -I/home/cauchy/vcs/svn/gcc/trunk/gcc -I/home/cauchy/vcs/svn/gcc/trunk/gcc/. -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./gmp -I/home/cauchy/vcs/svn/gcc/trunk/gmp -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpc/src -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid -I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./isl/include -I/home/cauchy/vcs/svn/gcc/trunk/isl/include \ /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/host-mingw32.c In file included from /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/x86intrin.h:39:0, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/winnt.h:1369, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/windef.h:139, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/windows.h:69, from /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/host-mingw32.c:29: /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/ammintrin.h:35:27: sorry, unimplemented: -mno-fentry isn't compatible with SEH #pragma GCC target(sse4a) ^ make[2]: *** [host-mingw32.o] Error 1 make[2]: Leaving directory `/home/cauchy/obj/native/gcc-4.9-win64/gcc/gcc' make[1]: *** [install-strip-gcc] Error 2 make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.9-win64/gcc' make: *** [install-strip] Error 2 From http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html -fasynchronous-unwind-tables Generate unwind table in DWARF 2 format, if supported by target machine. There maybe something wrong, why when I use SEH, the gcc build script use '-fasynchronous-unwind-tables' ? $ cat x.c #pragma GCC target(sse4a) $ x86_64-w64-mingw32-g++ -c -fasynchronous-unwind-tables x.c x.c:1:27: sorry, unimplemented: -mno-fentry isn't compatible with SEH #pragma GCC target(sse4a) ^ $ x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/home/cauchy/cross/x86_64-windows-gcc48/libexec/gcc/x86_64-w64-mingw32/4.8.2/lto-wrapper Target: x86_64-w64-mingw32 Configured with: /home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/configure --prefix=/home/cauchy/cross/x86_64-windows-gcc48 --with-sysroot=/home/cauchy/cross/x86_64-windows-gcc48 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-w64-mingw32 --disable-multilib --disable-nls --enable-checking=release --enable-languages=c,c++,fortran --with-arch=core2 --with-tune=generic Thread model: win32 gcc version 4.8.2 20130712 (prerelease) (GCC)
[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 --- Comment #1 from Dongsheng Song dongsheng.song at gmail dot com --- $ ~/cross/x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=/home/cauchy/cross/x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/home/cauchy/cross/x86_64-windows-gcc49/libexec/gcc/x86_64-w64-mingw32/4.9.0/lto-wrapper Target: x86_64-w64-mingw32 Configured with: /home/cauchy/vcs/svn/gcc/trunk/configure --prefix=/home/cauchy/cross/x86_64-windows-gcc49 --with-sysroot=/home/cauchy/cross/x86_64-windows-gcc49 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-w64-mingw32 --disable-multilib --disable-nls --enable-checking=release --enable-languages=c,c++,fortran --with-arch=corei7 --with-tune=generic Thread model: win32 gcc version 4.9.0 20130714 (experimental) (GCC) $ cat x.c #pragma GCC target(sse4a) $ ~/cross/x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ -c -fasynchronous-unwind-tables x.c x.c:1:27: sorry, unimplemented: -mno-fentry isn't compatible with SEH #pragma GCC target(sse4a) ^
[Bug fortran/57894] min/max required actual argument missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57894 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org --- Created attachment 30505 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30505action=edit Untested draft patch Confirmed. Actually, the label is completely unhandled: abc= is accepted as well as multiple times the same label.
[Bug fortran/57894] min/max required actual argument missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57894 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid, ||diagnostic, patch Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-15 Ever confirmed|0 |1
[Bug libstdc++/57898] New: std::bind incompatible with ref-qualified ptmf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57898
Bug ID: 57898
Summary: std::bind incompatible with ref-qualified ptmf
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: potswa at mac dot com
#include functional
struct s { void f() ; };
s *p;
auto b = std::bind( s::f, p );
Resulting error:
error: forming reference to qualified function type ‘void() ’
The original case produced an overload resolution failure for std::bind, with a
complaint like no known conversion for argument 1 from void(t::*)(arg) to
void(t::*)(arg), i.e. it's having trouble binding the ptmf reference.
However I have isolated that problem. It seems there may an underlying issue in
the compiler though.
[Bug c++/57899] New: bind/function with data member: infinite recursion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57899
Bug ID: 57899
Summary: bind/function with data member: infinite recursion
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jpr at essi dot fr
The following program fails to compile with gcc-4.8.1 in C++11 mode:
#include cassert
#include string
#include map
#include list
#include algorithm
#include functional
using namespace std;
using namespace std::placeholders;
int main()
{
mapstring, int table = {{0123456789012345, 0}};
//listpairstring, int table = {{0123456789012345, 0}};
functionstring(const pairconst string, int) get_first =
bind(pairconst string, int::first, _1);
auto it = find_if(table.begin(), table.end(),
bind(greatersize_t(),
bind(string::length, bind(get_first, _1)),
5));
assert(it != table.end());
return 0;
}
Here is the result of compiling:
--
prospero% g++ -v -save-temps -std=c++11 -Wall -g -I../include
-ftemplate-depth=1 a.cpp 21
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/jpr/LOCAL/test/gcc-4.8.1/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/user/jpr/home/LOCAL/test/gcc-4.8.1
--with-local-prefix=/user/jpr/home/LOCAL/test/gcc-4.8.1 --enable-threads
--enable-languages=ada,c,c++,fortran,objc,obj-c++,go,java
--with-gmp-lib=/usr/lib64 --with-mpfr-lib=/usr/lib64 --with-mpc-lib=/usr/lib64
Thread model: posix
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-g' '-I'
'../include' '-ftemplate-depth=1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/cc1plus
-E -quiet -v -I ../include -iprefix
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/
-D_GNU_SOURCE a.cpp -mtune=generic -march=x86-64 -std=c++11 -Wall
-ftemplate-depth=1 -g -fworking-directory -fpch-preprocess -o a.ii
ignoring nonexistent directory
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../x86_64-unknown-linux-gnu/include
ignoring duplicate directory
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1
ignoring duplicate directory
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/x86_64-unknown-linux-gnu
ignoring duplicate directory
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/backward
ignoring duplicate directory
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include
ignoring duplicate directory
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include-fixed
ignoring nonexistent directory
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/../../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
../include
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/x86_64-unknown-linux-gnu
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/../../../../include/c++/4.8.1/backward
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.1/include-fixed
/user/jpr/home/LOCAL/test/gcc-4.8.1/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-g' '-I'
'../include' '-ftemplate-depth=1' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/home/jpr/LOCAL/test/gcc-4.8.1/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/cc1plus
-fpreprocessed a.ii -quiet -dumpbase a.cpp -mtune=generic -march=x86-64
-auxbase a -g -Wall -std=c++11 -version -ftemplate-depth=1 -o a.s
GNU C++ (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 5.0.2, MPFR version 3.1.0, MPC
version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.8.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.8.1, GMP version 5.0.2, MPFR version 3.1.0, MPC
version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f1ad4865ded0b3f0e4317ac2d8456db9
In file included from
[Bug fortran/49138] Add /usr/include/fortran/{,gcc-version} to the file/module search path
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- See also: - http://fedoraproject.org/wiki/PackagingDrafts/FortranLibraries (from 2008) - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714730 + http://lists.debian.org/debian-science/2013/07/msg00012.html
[Bug c/57896] ICE in in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se --- I can reproduce the ICE with gcc-4.8.1 and gcc-4.8-20130711 on x86_64-linux, using options -O0 -m64. At higher optimization levels or with -m32 the ICE doesn't occur. gcc-4.9-20130714 doesn't ICE.
[Bug fortran/57895] Segmentation fault in gfc_restore_last_undo_checkpoint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57895
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic,
||ice-on-invalid-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-07-15
CC||burnus at gcc dot gnu.org
Known to work||4.1.2
Ever confirmed|0 |1
Known to fail||4.3.4, 4.5.3, 4.6.3, 4.7.3,
||4.8.1, 4.9.0
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org ---
That's a regression. GCC 4.1 gives:
Error: Syntax error in COMMON statement at (1)
due to the '$' (and exits without failure). But GCC 4.3 and later segfault.
I think one should apply the following patch to give a good error message
(instead of none). However, it does not prevent the segfault.
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -557,6 +557,6 @@ gfc_match_name (char *buffer)
if (c == '$' !gfc_option.flag_dollar_ok)
{
- gfc_error (Invalid character '$' at %C. Use -fdollar-ok to allow it
-as an extension);
+ gfc_error_now (Invalid character '$' at %C. Use -fdollar-ok to allow it
+as an extension);
return MATCH_ERROR;
}
[Bug libstdc++/57898] std::bind incompatible with ref-qualified ptmf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57898 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-07-15 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I think the problem is simply that I haven't checked in support for ref-qualifiers to mem_fn. I have a patch in my git repo.
[Bug fortran/57895] Segmentation fault in gfc_restore_last_undo_checkpoint
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57895 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin mikael at gcc dot gnu.org --- gfc_restore_last_undo_checkpoint seems to take care of the cleanup, so we don't need to do it in gfc_match_common. The following fixes the segfault. --- a/match.c +++ b/match.c @@ -4520,10 +4520,6 @@ syntax: gfc_syntax_error (ST_COMMON); cleanup: - if (old_blank_common) -old_blank_common-common_next = NULL; - else -gfc_current_ns-blank_common.head = NULL; gfc_free_array_spec (as); return MATCH_ERROR; }
[Bug libstdc++/57899] bind/function with data member: infinite recursion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57899 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-15 Component|c++ |libstdc++ Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- N.B. you can simplify bind(pairconst string, int::first, _1); to: mem_fn(pairconst string, int::first); although that doesn't fix the problem.
[Bug libstdc++/57899] bind/function with data member: infinite recursion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57899
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
Reduced slightly:
#include string
#include functional
using namespace std;
using namespace std::placeholders;
int main()
{
pairstring, int table = {0123456789012345, 0};
auto get_first = mem_fn(pairstring, int::first);
auto it = bind(greatersize_t(), bind(string::length, bind(get_first,
_1)), 5);
it(table);
}
[Bug c/57896] ICE in in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se --- The ICE was fixed for 4.9/trunk by Marc Glisse's Property for vector lowering patch in r196890, originally described here: http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00421.html Backporting r196890 to current 4.8 branch fixes the ICE there too, but that may or may not be the appropriate fix. Author CC:d.
[Bug c/57896] ICE in in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-07-15 Ever confirmed|0 |1 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Mikael Pettersson from comment #2) The ICE was fixed for 4.9/trunk by Marc Glisse's Property for vector lowering patch in r196890, originally described here: http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00421.html Really? Ah, right, I moved a pass in that patch, that's probably what matters. Backporting r196890 to current 4.8 branch fixes the ICE there too, but that may or may not be the appropriate fix. Author CC:d. I doubt that backporting the whole thing makes sense. If moving the pass really helps, that part maybe... But we first need to understand what is going on, the patch is likely just hiding the real bug.
[Bug driver/44080] Call GNU ld with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44080 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- (I hesitated between invalid and wontfix, doesn't really matter) Patch was posted at http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00473.html , improved by Jakub http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00478.html , accepted, but then Ian and Michael both argued against the patch, so I'll consider it rejected.
[Bug c/57896] ICE in in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org --- Created attachment 30506 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30506action=edit Slightly reduced testcase The bug disappears if we remove some unused typedefs, or the preprocessor line indications, or... valgrind doesn't report anything though. I have no idea what kind of corruption is going on.
[Bug libstdc++/57885] unordered_map find slower in 4.8.1 than 4.7.3 with integer key
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885
--- Comment #3 from Jim Hand jhand at austin dot rr.com ---
As a simplification, I tried compiling the following code with gcc-4.6.3 into
assembly with gcc-4.6.3 and 4.8.1:
#include unordered_map
bool contains(std::unordered_mapint, int a) {
return a.find(5) != a.end();
}
gcc-4.6.3 generates the following assembly:
.LFB574:
.cfi_startproc
movq8(%rdi), %rcx
movq16(%rdi), %rdi
xorl%edx, %edx
movl$5, %eax
divq%rdi
xorl%eax, %eax
movq(%rcx,%rdi,8), %rsi
movq(%rcx,%rdx,8), %rdx
testq%rdx, %rdx
jne.L6
jmp.L2
.p2align 4,,10
.p2align 3
.L11:
movq8(%rdx), %rdx
testq%rdx, %rdx
je.L10
.L6:
cmpl$5, (%rdx)
jne.L11
cmpq%rdx, %rsi
setne%al
.L2:
rep
ret
.p2align 4,,10
.p2align 3
.L10:
xorl%eax, %eax
ret
.cfi_endproc
gcc-4.8.1 generates the following assembly:
.LFB1323:
.cfi_startproc
movq8(%rdi), %r8
xorl%edx, %edx
movl$5, %eax
divq%r8
movq(%rdi), %rax
movq(%rax,%rdx,8), %rax
movq%rdx, %r9
testq%rax, %rax
je.L7
movq(%rax), %rcx
movl8(%rcx), %esi
.p2align 4,,10
.p2align 3
.L3:
cmpl$5, %esi
je.L5
movq(%rcx), %rcx
testq%rcx, %rcx
je.L7
movl8(%rcx), %esi
xorl%edx, %edx
movslq%esi, %rax
divq%r8
cmpq%rdx, %r9
je.L3
.L7:
xorl%eax, %eax
ret
.p2align 4,,10
.p2align 3
.L5:
movl$1, %eax
ret
.cfi_endproc
In the gcc-4.8.1 code, I see two divq instructions that I think are coming from
line 345 of _Mod_range_hashing in bits/hashtable_policy.h:
343 result_type
344 operator()(first_argument_type __num, second_argument_type __den)
const
345 { return __num % __den; }
I would think that the hash function only needs to be called once for this
function, but I could be misinterpreting the assembly output. It does look to
me like the 4.8 output is doing a lot more than the 4.6.3 output, but I'll
leave it for you to explore.
[Bug bootstrap/57900] New: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900 Bug ID: 57900 Summary: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: woodard at redhat dot com This is an easy problem to solve and there are a couple of ways to solve it. The underlying problem is that I don't have one of the glibc-devel packages installed or I can build with --disable-multilib However, I would argue that autoconf/configure should have picked this up in much the same way that it picks up the fact that GMP, MPFR and MPC may be missing and prints out: configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+. Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify their locations. Source code for these libraries can be found at their respective hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/. See also http://gcc.gnu.org/install/prerequisites.html for additional info. If you obtained GMP, MPFR and/or MPC from a vendor distribution package, make sure that you have installed both the libraries and the header files. They may be located in separate packages. --- error text --- /home/ben/Work/gcc/host-x86_64-unknown-linux-gnu/gcc/xgcc -B/home/ben/Work/gcc/host-x86_64-unknown-linux-gnu/gcc/ -B/home/ben/Work/gcc-test/x86_64-unknown-linux-gnu/bin/ -B/home/ben/Work/gcc-test/x86_64-unknown-linux-gnu/lib/ -isystem /home/ben/Work/gcc-test/x86_64-unknown-linux-gnu/include -isystem /home/ben/Work/gcc-test/x86_64-unknown-linux-gnu/sys-include-g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -I. -I. -I../../../host-x86_64-unknown-linux-gnu/gcc -I../../.././libgcc -I../../.././libgcc/. -I../../.././libgcc/../gcc -I../../.././libgcc/../include -I../../.././libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _gcov.o -MT _gcov.o -MD -MP -MF _gcov.dep -DL_gcov -c ../../.././libgcc/libgcov.c In file included from /usr/include/features.h:399:0, from /usr/include/stdio.h:27, from ../../.././libgcc/../gcc/tsystem.h:87, from ../../.././libgcc/libgcov.c:27: /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory # include gnu/stubs-32.h ^ compilation terminated. make[5]: *** [_gcov.o] Error 1 make[5]: Leaving directory `/home/ben/Work/gcc/x86_64-unknown-linux-gnu/32/libgcc' make[4]: *** [multi-do] Error 1 make[4]: Leaving directory `/home/ben/Work/gcc/x86_64-unknown-linux-gnu/libgcc' make[3]: *** [all-multi] Error 2 make[3]: *** Waiting for unfinished jobs make[3]: Leaving directory `/home/ben/Work/gcc/x86_64-unknown-linux-gnu/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/home/ben/Work/gcc' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/ben/Work/gcc' make: *** [bootstrap] Error 2
[Bug bootstrap/57900] /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900 Ben Woodard woodard at redhat dot com changed: What|Removed |Added Severity|minor |trivial
[Bug bootstrap/57900] /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|trivial |enhancement --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- It is hard to figure out if you have the 32bit libraries/headers installed as the host compiler might not be able to compile 32bits but the newly compiled compiler can.
[Bug bootstrap/57900] /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900 --- Comment #2 from Andreas Schwab sch...@linux-m68k.org --- It's the target compiler that matters, so this check must be performed in the target libraries.
[Bug bootstrap/57900] /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57900 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- See the long thread starting at http://gcc.gnu.org/ml/gcc/2013-07/msg00075.html If it's easy to solve I'm sure a patch would be welcomed :)
[Bug c++/57901] New: [C++11][constexpr] Cannot call-by-value such that class has non-trivial (constexpr) move constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57901
Bug ID: 57901
Summary: [C++11][constexpr] Cannot call-by-value such that
class has non-trivial (constexpr) move constructor
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bolero.murakami at gmail dot com
Code:
//
struct Z {
Z() = default;
Z(Z const) = default;
constexpr Z(Z) {} /* non-trivial (constexpr) move ctor */
};
templatetypename T
constexpr int fn0(T v) { return 0; }
templatetypename T
constexpr int fn (T v) { return fn0(v); }
constexpr auto t0 = fn0(Z()); // OK!
constexpr auto t = fn (Z()); // error! (GCC 4.8.1, -std=c++11)
//
Error message:
in constexpr expansion of ‘fnZ(Z())’
error: ‘v’ is not a constant expression
constexpr auto t = fn(Z());
^
Class Z is literal type.
However, compilation error when it is call-by-value(more than once).
I tested this code in gcc-4.7.3, is passed.
The problem is reproduced in gcc-4.8.0, gcc-4.8.1
[Bug fortran/52669] No warning in unused private variable in modules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52669 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org --- Tobias, thanks for posting the commit message. Fixed, closing.
[Bug libstdc++/56166] std::string::clear() can throw despite being marked noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166 Tolga fasdfasdas at gmail dot com changed: What|Removed |Added CC||fasdfasdas at gmail dot com --- Comment #7 from Tolga fasdfasdas at gmail dot com --- I can confirm this on g++ 4.8.1. I think I can also confirm that it is about reference counting, thanks to this report, I was able to work around it though.
[Bug libstdc++/56166] std::string::clear() can throw despite being marked noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166 --- Comment #8 from Tolga fasdfasdas at gmail dot com --- Correction, removing the copy, therefore reference counting effect, feels like has decreased the error but I found out std::string::clear() still throws std::length_error, although I use no reference.
[Bug ada/57902] New: Bugbox in Ada 95 mode, at ada/gcc-interface/decl.c:342
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57902 Bug ID: 57902 Summary: Bugbox in Ada 95 mode, at ada/gcc-interface/decl.c:342 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Host: amd64-debian-linux-gnu Target: amd64-debian-linux-gnu Build: amd64-debian-linux-gnu Created attachment 30507 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30507action=edit bugbox.ada Steps to reproduce (with trunk as of 2013-07-15, on Debian amd64): gnatchop bugbox.ada /opt/gcc-trunk/bin/gcc -gnat95 -c dnslogger-multi_whois.adb I have not made any attempts yet at reducing the test case.
[Bug fortran/47425] Array constructor with type-spec: Fails with more complicated length type expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47425 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Another example. Note in particular the case n==0. The following program should print: :: a:d:f ab:de:fg abc:de :fgh It does so with ifort (and except for n==0 also with crayftn). However, with gfortran one gets at compile time: error: size of variable 'A.1' is too large subroutine test(n) integer :: n print '(3(a::))', [ character(len=n) :: abc, de, fghijkl ] end subroutine call test(0) call test(1) call test(2) call test(3) end
[Bug libstdc++/56166] std::string::clear() can throw despite being marked noexcept
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56166 --- Comment #9 from Tolga fasdfasdas at gmail dot com --- It was a bug in my code that called clear from one thread while other inserts something. Yet, it throws.
[Bug libstdc++/57885] unordered_map find slower in 4.8.1 than 4.7.3 with integer key
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57885 --- Comment #4 from Jim Hand jhand at austin dot rr.com --- I compiled 4.9.0-20130714 today and ran the same tests. Here are the results for the lookup loops with the times for each compiler: 4.6.3: 11536 microseconds 4.7.3: 12150 microseconds (5.3% slower than 4.6.3) 4.8.2: 14810 microseconds (28.3% slower than 4.6.3) 4.9.0-20130714 15365 microseconds (33.1% slower than 4.6.3) I took a look at the assembly for the return a.find(5) != a.end(); code for 4.9 and it looks very similar to the 4.8 assembly, but contains two extra instructions at the beginning of the function: testq%r8, %r8 je.L8 I guess those two instructions explain the the slightly worse behavior for 4.9.0 than 4.8.2.
[Bug c/57896] ICE in in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57896 --- Comment #5 from Vittorio Zecca zeccav at gmail dot com --- Trying your vastly reduced test case, 152 lines vs 3057 of my original test case, I am getting an ICE in convert_move, at expr.c:452. The following is my backtrace: command-line: In function ‘__get_cpuid_max’: command-line:1:1: internal compiler error: in convert_move, at expr.c:452 0x62ee1b convert_move(rtx_def*, rtx_def*, int) ../../gcc-4.8.1/gcc/expr.c:451 0x62f098 convert_modes(machine_mode, machine_mode, rtx_def*, int) ../../gcc-4.8.1/gcc/expr.c:781 0x9939dd ix86_legitimize_address ../../gcc-4.8.1/gcc/config/i386/i386.c:13276 0x619880 memory_address_addr_space(machine_mode, rtx_def*, unsigned char) ../../gcc-4.8.1/gcc/explow.c:461 0x60b5a4 change_address_1 ../../gcc-4.8.1/gcc/emit-rtl.c:2021 0x671808 assign_parm_setup_stack ../../gcc-4.8.1/gcc/function.c:3234 0x671808 assign_parms ../../gcc-4.8.1/gcc/function.c:3416 0x67355f expand_function_start(tree_node*) ../../gcc-4.8.1/gcc/function.c:4824 0x58ac99 gimple_expand_cfg ../../gcc-4.8.1/gcc/cfgexpand.c:4552 Adding option -m32 I get ICE in ix86_expand_prologue, at config/i386/i386.c:10559
[Bug target/57717] error: unrecognizable insn compiling ./strtod_l.c from glibc on powerpc-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57717
--- Comment #6 from Khem Raj raj.khem at gmail dot com ---
here is another case which fails before suggested patch and also after the
patch
void foo()
{
double a[2];
double b = 3.1L / 2;
}
Here is result below after applying the patch in comment #3
$ ./gcc/cc1 ~/a.c
foo
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups *free_inline_summary
emutls whole-programAssembling functions:
foo
/homes/kraj/a.c: In function 'foo':
/homes/kraj/a.c:6:1: internal compiler error: in change_address_1, at
emit-rtl.c:1955
}
^
0x5d7dd0 change_address_1
../../gcc/gcc/emit-rtl.c:1955
0x5dad82 adjust_address_1(rtx_def*, machine_mode, long, int, int, int, long)
../../gcc/gcc/emit-rtl.c:2087
0x61ac98 alter_subreg(rtx_def**, bool)
../../gcc/gcc/final.c:3062
0x61aed9 cleanup_subreg_operands(rtx_def*)
../../gcc/gcc/final.c:3008
0x7e80b6 reload(rtx_def*, int)
../../gcc/gcc/reload1.c:1240
0x70227b do_reload
../../gcc/gcc/ira.c:4701
0x70227b rest_of_handle_reload
../../gcc/gcc/ira.c:4801
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741 --- Comment #19 from Sebastian Pop spop at gcc dot gnu.org --- Default: tile_size = 32 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 -v ./a.out 176.42500110.2399826 and then with a trivial patch that replaces that default constant 32 with the param that we already have in -floop-block we can see that there is not much impact of the tile size: gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=51 ./a.out 173.49000110.2399826 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=10 ./a.out 175.32499910.2399826 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=20 ./a.out 173.9110.2399826 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=30 ./a.out 177.07499910.2399826 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=40 ./a.out 173.77500110.2399826 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=50 ./a.out 176.96500010.2399826 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=60 ./a.out 176.7810.2399826 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=70 ./a.out 176.12500010.2399826 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=80 ./a.out 175.55000110.2399826 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=90 ./a.out 184.63500210.2399826 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=100 ./a.out 187.30500110.2399826 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=110 ./a.out 187.99000110.2399826 gfortran -ffast-math -O3 -floop-nest-optimize t.f90 --param loop-block-tile-size=120 ./a.out 188.1310.2399826
[Bug tree-optimization/14741] graphite with loop blocking and interchanging doesn't optimize a matrix multiplication loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741 --- Comment #20 from Sebastian Pop spop at gcc dot gnu.org --- -floop-nest-optimize does not have a cost model and so it blocks all loop nests. These two stmts are blocked: A=0.1D0 B=0.1D0 This other stmt is not blocked: C(I,J)=C(I,J)+A(I,K)*B(K,J) The only thing we can get from the dump file for this stmt is: number of SCoPs: 0 most likely scop detection did not like something in that loop nest.
