[Bug target/60207] Wrong TFmode check in construct_container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60207 --- Comment #1 from Uroš Bizjak --- (In reply to H.J. Lu from comment #0) > But we didn't remove mode == TFmode check in construct_container. This check is benign. classify_argument will return: case TFmode: classes[0] = X86_64_SSE_CLASS; classes[1] = X86_64_SSEUP_CLASS; return 2; and the check in construct_container is: if (n == 2 && regclass[0] == X86_64_INTEGER_CLASS && regclass[1] == X86_64_INTEGER_CLASS && (mode == CDImode || mode == TImode || mode == TFmode) && intreg[0] + 1 == intreg[1]) return gen_rtx_REG (mode, intreg[0]); The above condition never triggers due to regclass checks. So, you can remove TFmode check without harm. The patch is pre-approved for mainline and release branches.
[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 Richard Biener changed: What|Removed |Added CC|richard.guenther at gmail dot com |rguenth at gcc dot gnu.org, ||stevenb.gcc at gmail dot com --- Comment #27 from Richard Biener --- Yeah, not sure how non-cc0 targets avoid this situation. I wonder if there is a suitable pre-reload pass to do such reloading (I'm not sure teaching reload to do that is the best idea ...)
[Bug tree-optimization/60183] [4.7/4.8/4.9 Regression] phiprop creates invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60183 --- Comment #5 from Richard Biener --- Author: rguenth Date: Sat Feb 15 09:54:52 2014 New Revision: 207797 URL: http://gcc.gnu.org/viewcvs?rev=207797&root=gcc&view=rev Log: 2014-02-15 Richard Biener PR tree-optimization/60183 * tree-ssa-phiprop.c (propagate_with_phi): Avoid speculating loads. (tree_ssa_phiprop): Calculate and free post-dominators. * gcc.dg/torture/pr60183.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr60183.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-phiprop.c
[Bug middle-end/60092] posix_memalign not recognized to derive alias and alignment info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60092 --- Comment #24 from Richard Biener --- As the standard doesn't specify that the value is undefined upon error and it only specifies its contents upon successfull completion it implicitely says that it retains the previous value on error. I'd say xfail/skip this on solaris11 and report a bug to them.
[Bug target/57935] ICE in rs6000_secondary_reload_inner:15181, type = load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57935 --- Comment #2 from Alan Modra --- Author: amodra Date: Sat Feb 15 10:49:55 2014 New Revision: 207798 URL: http://gcc.gnu.org/viewcvs?rev=207798&root=gcc&view=rev Log: PR target/58675 PR target/57935 * config/rs6000/rs6000.c (rs6000_secondary_reload_inner): Use find_replacement on parts of insn rtl that might be reloaded. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug target/58675] ICE in rs6000_secondary_reload_inner:15460, type = store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675 --- Comment #6 from Alan Modra --- Author: amodra Date: Sat Feb 15 10:49:55 2014 New Revision: 207798 URL: http://gcc.gnu.org/viewcvs?rev=207798&root=gcc&view=rev Log: PR target/58675 PR target/57935 * config/rs6000/rs6000.c (rs6000_secondary_reload_inner): Use find_replacement on parts of insn rtl that might be reloaded. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug target/58675] ICE in rs6000_secondary_reload_inner:15460, type = store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Alan Modra --- Fixed
[Bug c++/60210] New: segfault when trying to use a const template using
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60210
Bug ID: 60210
Summary: segfault when trying to use a const template using
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: florent.hivert at lri dot fr
Created attachment 32143
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32143&action=edit
preprocessed code
The following code triggers a segfault:
template struct S {};
template using constS = const S;
template void FOO(constS a) {}
If const is removed the problem disappear. Follows the full log. I also got the
same problem with various version of g++.
g++ -v -save-temps -Wall -Wextra -std=c++11 bug3.cpp -o bug3
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8
--enable-ssp --disable-libssp --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--program-suffix=-4.8 --enable-linux-futex --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11' '-o'
'bug3' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib64/gcc/x86_64-suse-linux/4.8/cc1plus -E -quiet -v -D_GNU_SOURCE
bug3.cpp -mtune=generic -march=x86-64 -std=c++11 -Wall -Wextra -fpch-preprocess
-o bug3.ii
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.8
/usr/include/c++/4.8/x86_64-suse-linux
/usr/include/c++/4.8/backward
/usr/lib64/gcc/x86_64-suse-linux/4.8/include
/usr/local/include
/usr/lib64/gcc/x86_64-suse-linux/4.8/include-fixed
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11' '-o'
'bug3' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib64/gcc/x86_64-suse-linux/4.8/cc1plus -fpreprocessed bug3.ii -quiet
-dumpbase bug3.cpp -mtune=generic -march=x86-64 -auxbase bug3 -Wall -Wextra
-std=c++11 -version -o bug3.s
GNU C++ (SUSE Linux) version 4.8.1 20130909 [gcc-4_8-branch revision 202388]
(x86_64-suse-linux)
compiled by GNU C version 4.8.1 20130909 [gcc-4_8-branch revision
202388], GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (SUSE Linux) version 4.8.1 20130909 [gcc-4_8-branch revision 202388]
(x86_64-suse-linux)
compiled by GNU C version 4.8.1 20130909 [gcc-4_8-branch revision
202388], GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8f4f3cbd488ac89b0f495172228a1742
bug3.cpp:3:40: internal compiler error: Segmentation fault
template void FOO(constS a) {}
[Bug target/59814] powerpc64le ICE with -O2 -mpower8 -ffast-math
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59814 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Target Milestone|--- |4.9.0 --- Comment #2 from Alan Modra --- Fix by rev 206668 *** This bug has been marked as a duplicate of bug 59844 ***
[Bug target/59844] Powerpc64le cannot bootstrap with -O3/-mcpu=power8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59844 Alan Modra changed: What|Removed |Added CC||anton at samba dot org --- Comment #5 from Alan Modra --- *** Bug 59814 has been marked as a duplicate of this bug. ***
[Bug fortran/59599] Compiler internal error on intrinsic ichar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59599 --- Comment #8 from Mikael Morin --- Author: mikael Date: Sat Feb 15 11:48:41 2014 New Revision: 207799 URL: http://gcc.gnu.org/viewcvs?rev=207799&root=gcc&view=rev Log: fortran/ PR fortran/59599 * trans-intrinsic.c (gfc_conv_intrinsic_ichar): Calculate the number of arguments. testsuite/ PR fortran/59599 * gfortran.dg/ichar_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/ichar_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60211] New: ICE with #pragma GCC ivdep and for-loop on global scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60211
Bug ID: 60211
Summary: ICE with #pragma GCC ivdep and for-loop on global
scope
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet triggers an ICE on trunk:
=
void foo()
{}
int i;
#pragma GCC ivdep
for (i = 0; i < 2; ++i)
;
}
=
bug.cc:6:5: internal compiler error: in add_stmt, at cp/semantics.c:391
;
^
0x7268a8 add_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:391
0x6d0457 cp_parser_iteration_statement
../../gcc/gcc/cp/parser.c:10516
0x6a7600 cp_parser_pragma
../../gcc/gcc/cp/parser.c:31461
0x6d2c51 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10864
0x6d44ba cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d44ba c_parse_file()
../../gcc/gcc/cp/parser.c:31536
0x7f3823 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
Declaring the variable within the for-loop produces a different stack trace:
=
void foo()
{}
#pragma GCC ivdep
for (int i = 0; i < 2; ++i)
;
}
=
bug.cc:4:12: internal compiler error: tree check: expected tree that contains
'decl with visibility' structure, have 'parm_decl' in start_decl, at
cp/decl.c:4572
for (int i = 0; i < 2; ++i)
^
0xdc0f24 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.c:9364
0x5ee658 contains_struct_check
../../gcc/gcc/tree.h:2823
0x5ee658 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4572
0x6c7efe cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16680
0x6c9989 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11205
0x6d02bd cp_parser_for_init_statement
../../gcc/gcc/cp/parser.c:10558
0x6d02bd cp_parser_for
../../gcc/gcc/cp/parser.c:10038
0x6d02bd cp_parser_iteration_statement
../../gcc/gcc/cp/parser.c:10505
0x6a7600 cp_parser_pragma
../../gcc/gcc/cp/parser.c:31461
0x6d2c51 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10864
0x6d44ba cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d44ba c_parse_file()
../../gcc/gcc/cp/parser.c:31536
0x7f3823 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
[Bug c++/60212] New: no warning for unused variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60212
Bug ID: 60212
Summary: no warning for unused variables
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ali.baharev at gmail dot com
Created attachment 32144
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32144&action=edit
source file needed to reproduce the bug report
After reading the documentation, I would expect a warning that x is unused, and
both clang and msvc gives a warning too.
g++ -fwhole-program -O3 -std=c++11 -Wall -Wextra -Wunused warn.cpp
struct S { int array[1024]; };
int main() {
const S a{{0}};
S x(a);
}
In my opinion, it is NOT a duplicate of:
No unused warning for variables of non-trivial types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203
I see no reason for tagging S with attribute warn_unused; the compiler should
be able to verify unused S variables even without it.
[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #28 from Steven Bosscher --- (In reply to Jeffrey A. Law from comment #24) > One could argue that the CFG building code could be tweaked so that a > cc0-setter is never considered the end of a block. The CFG is built too early (on gimple) to know what may end up a cc0 setter. It'd take more than a few CFG fixup hacks after expanding to RTL to get the cc0-setter and cc0-consumer back together in the same basic block. How did this work (i.e. what did the CFG look like) before tree-ssa, e.g. in gcc 3.4?
[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 --- Comment #29 from Andreas Schwab --- In gcc <= 4.6 I'm unable to tell the compiler to consider the fp compare trapping even with -ftrapping-math.
[Bug c++/60213] New: Weird crash when delete an object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60213 Bug ID: 60213 Summary: Weird crash when delete an object Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hubert.vansteenhuyse at freecode dot be
[Bug c++/60213] Weird crash when delete an object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60213
--- Comment #1 from hubert.vansteenhuyse at freecode dot be ---
struct A {
A *a[2];
A() { a[0] = 0; a[1] = 0; }
~A(){ if(a[0]) delete a[0]; if(a[1]) delete a[1];
}
void main(){
A *a = new A();
a->a[0] = new A();
a->a[1] = new A();
delete a; //<<< crash, because adress of a == address of a.a[0] :(
}
[Bug libfortran/59774] [4.8 Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #17 from Jerry DeLisle --- Author: jvdelisle Date: Sat Feb 15 15:48:48 2014 New Revision: 207801 URL: http://gcc.gnu.org/viewcvs?rev=207801&root=gcc&view=rev Log: 2014-02-15 Jerry DeLisle Dominique d'Humieres Backport from mainline PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * io/write_float.def (output_float): Fix wrong handling of the Fw.0 format. (output_float_FMT_G_): Fixes rounding issues with -m32. Modified: branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/write_float.def
[Bug libfortran/59836] [4.7/4.8 Regression] Wrong outputs with rounding formats for some values.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 --- Comment #12 from Jerry DeLisle --- Author: jvdelisle Date: Sat Feb 15 15:48:48 2014 New Revision: 207801 URL: http://gcc.gnu.org/viewcvs?rev=207801&root=gcc&view=rev Log: 2014-02-15 Jerry DeLisle Dominique d'Humieres Backport from mainline PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * io/write_float.def (output_float): Fix wrong handling of the Fw.0 format. (output_float_FMT_G_): Fixes rounding issues with -m32. Modified: branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/write_float.def
[Bug libfortran/59771] Cleanup handling of Gw.0 and Gw.0Ee format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59771 --- Comment #4 from Jerry DeLisle --- Author: jvdelisle Date: Sat Feb 15 15:48:48 2014 New Revision: 207801 URL: http://gcc.gnu.org/viewcvs?rev=207801&root=gcc&view=rev Log: 2014-02-15 Jerry DeLisle Dominique d'Humieres Backport from mainline PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * io/write_float.def (output_float): Fix wrong handling of the Fw.0 format. (output_float_FMT_G_): Fixes rounding issues with -m32. Modified: branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/write_float.def
[Bug c++/60213] Weird crash when delete an object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60213
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2014-02-15
Ever confirmed|0 |1
--- Comment #2 from Marc Glisse ---
Your example is bogus: { and } don't match, main must return int, etc. If I fix
it so it compiles, I don't see any crash.
[Bug libfortran/59771] Cleanup handling of Gw.0 and Gw.0Ee format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59771 --- Comment #5 from Jerry DeLisle --- Author: jvdelisle Date: Sat Feb 15 15:57:35 2014 New Revision: 207802 URL: http://gcc.gnu.org/viewcvs?rev=207802&root=gcc&view=rev Log: 2014-02-15 Jerry DeLisle Dominique d'Humieres Backport from mainline PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * gfortran.dg/fmt_g_1.f90: New test. * gfortran.dg/round_3.f08: New cases added. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/fmt_g_1.f90 Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/round_3.f08
[Bug libfortran/59836] [4.7/4.8 Regression] Wrong outputs with rounding formats for some values.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 --- Comment #13 from Jerry DeLisle --- Author: jvdelisle Date: Sat Feb 15 15:57:35 2014 New Revision: 207802 URL: http://gcc.gnu.org/viewcvs?rev=207802&root=gcc&view=rev Log: 2014-02-15 Jerry DeLisle Dominique d'Humieres Backport from mainline PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * gfortran.dg/fmt_g_1.f90: New test. * gfortran.dg/round_3.f08: New cases added. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/fmt_g_1.f90 Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/round_3.f08
[Bug libfortran/59774] [4.8 Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #18 from Jerry DeLisle --- Author: jvdelisle Date: Sat Feb 15 15:57:35 2014 New Revision: 207802 URL: http://gcc.gnu.org/viewcvs?rev=207802&root=gcc&view=rev Log: 2014-02-15 Jerry DeLisle Dominique d'Humieres Backport from mainline PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * gfortran.dg/fmt_g_1.f90: New test. * gfortran.dg/round_3.f08: New cases added. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/fmt_g_1.f90 Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/round_3.f08
[Bug web/60208] Please highlight that mudflap support is removed in GCC 4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60208 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Manuel López-Ibáñez --- Note added. If you have more suggestions about editing the wiki, please provide the wikitext. The wiki is restricted to avoid spam. If you intend to edit the wiki frequently, ask in g...@gcc.gnu.org to become an Editor.
[Bug libfortran/59836] [4.7/4.8 Regression] Wrong outputs with rounding formats for some values.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 --- Comment #14 from Jerry DeLisle --- Author: jvdelisle Date: Sat Feb 15 16:53:07 2014 New Revision: 207803 URL: http://gcc.gnu.org/viewcvs?rev=207803&root=gcc&view=rev Log: 2014-02-15 Jerry DeLisle Dominique d'Humieres Backport from mainline PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * io/write_float.def (output_float): Fix wrong handling of the Fw.0 format. (output_float_FMT_G_): Fixes rounding issues with -m32. Modified: branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/io/write_float.def
[Bug libfortran/59771] Cleanup handling of Gw.0 and Gw.0Ee format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59771 --- Comment #6 from Jerry DeLisle --- Author: jvdelisle Date: Sat Feb 15 16:53:07 2014 New Revision: 207803 URL: http://gcc.gnu.org/viewcvs?rev=207803&root=gcc&view=rev Log: 2014-02-15 Jerry DeLisle Dominique d'Humieres Backport from mainline PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * io/write_float.def (output_float): Fix wrong handling of the Fw.0 format. (output_float_FMT_G_): Fixes rounding issues with -m32. Modified: branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/io/write_float.def
[Bug libfortran/59774] [4.8 Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #19 from Jerry DeLisle --- Author: jvdelisle Date: Sat Feb 15 16:53:07 2014 New Revision: 207803 URL: http://gcc.gnu.org/viewcvs?rev=207803&root=gcc&view=rev Log: 2014-02-15 Jerry DeLisle Dominique d'Humieres Backport from mainline PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * io/write_float.def (output_float): Fix wrong handling of the Fw.0 format. (output_float_FMT_G_): Fixes rounding issues with -m32. Modified: branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/io/write_float.def
[Bug libfortran/59774] [4.8 Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #20 from Jerry DeLisle --- Author: jvdelisle Date: Sat Feb 15 16:55:19 2014 New Revision: 207804 URL: http://gcc.gnu.org/viewcvs?rev=207804&root=gcc&view=rev Log: 2014-02-15 Jerry DeLisle Dominique d'Humieres Backport from mainline PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * gfortran.dg/fmt_g_1.f90: New test. * gfortran.dg/round_3.f08: New cases added. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/fmt_g_1.f90 Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/round_3.f08
[Bug libfortran/59836] [4.7/4.8 Regression] Wrong outputs with rounding formats for some values.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 --- Comment #15 from Jerry DeLisle --- Author: jvdelisle Date: Sat Feb 15 16:55:19 2014 New Revision: 207804 URL: http://gcc.gnu.org/viewcvs?rev=207804&root=gcc&view=rev Log: 2014-02-15 Jerry DeLisle Dominique d'Humieres Backport from mainline PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * gfortran.dg/fmt_g_1.f90: New test. * gfortran.dg/round_3.f08: New cases added. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/fmt_g_1.f90 Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/round_3.f08
[Bug libfortran/59771] Cleanup handling of Gw.0 and Gw.0Ee format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59771 --- Comment #7 from Jerry DeLisle --- Author: jvdelisle Date: Sat Feb 15 16:55:19 2014 New Revision: 207804 URL: http://gcc.gnu.org/viewcvs?rev=207804&root=gcc&view=rev Log: 2014-02-15 Jerry DeLisle Dominique d'Humieres Backport from mainline PR libfortran/59771 PR libfortran/59774 PR libfortran/59836 * gfortran.dg/fmt_g_1.f90: New test. * gfortran.dg/round_3.f08: New cases added. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/fmt_g_1.f90 Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/round_3.f08
[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60191 --- Comment #2 from janus at gcc dot gnu.org --- The function "make_real" is not invoked directly, but through the type-bound "a%real", which is called three times in the test case. Does the failure occur already at the first one (i.e. line 67)? Can you give a reduced test case? The type-bound call is transformed into a procedure-pointer-component call, i.e. "a._vptr->real (&a)". Do all the proc_ptr_comp_* test cases work on ARMv7? Does the failure only happen with trunk or also with earlier versions?
[Bug libfortran/59836] [4.7/4.8 Regression] Wrong outputs with rounding formats for some values.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59836 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Jerry DeLisle --- Fixed on 4.8 and 4.7, closing
[Bug libfortran/59771] Cleanup handling of Gw.0 and Gw.0Ee format
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59771 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jerry DeLisle --- Fixed on 4.8 and 4.7. Closing
[Bug libfortran/59774] [4.8 Regression] Inconsistent rounding between -m32 and -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #21 from Jerry DeLisle --- Fixed on 4.8 and 4.7. Closing
[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 --- Comment #30 from rguenther at suse dot de --- On February 15, 2014 3:22:54 PM GMT+01:00, "sch...@linux-m68k.org" wrote: >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847 > >--- Comment #29 from Andreas Schwab --- >In gcc <= 4.6 I'm unable to tell the compiler to consider the fp >compare >trapping even with -ftrapping-math. And before the rev. Cited we failed to create eh edges / info. And if we'd have eh edges out of the gimple_cond then we'd generate wrong unwind info. Spilling cc0 by rematerializing the compare seems to be the only way out. Unless the target can avoid iceing. Cc0 should be live on the fallthru edge - so what _is_ exactly the problem we are facing?
[Bug middle-end/60214] New: Variables with same DECL_ASSEMBLER_NAME are treated as different variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60214
Bug ID: 60214
Summary: Variables with same DECL_ASSEMBLER_NAME are treated as
different variables
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: johannespfau at gmail dot com
This bug was first found in GDC, the D frontend for GCC, but it's also
reproducable with GCC. Consider the following test case:
int test9_1 asm ("test_эльфийские_письмена_9") = 0;
extern int test9_1_e asm ("test_эльфийские_письмена_9");
int main()
{
test9_1 = 42;
return test9_1_e == 42;
}
compile on ARM with 'gcc -O2 test.c' and run the test program. It returns '0',
indicating test9_1_e is not 42. It works on ARM without optimization and on
x86_64 with or without optimization. I'm not sure if this is ARM specific or
only specific to architectures with section anchors. 'gcc -O2 test.c
-fno-section-anchors' works as expected.
What happens is that the first store to test9_1 is moved after the read from
test9_1_e.
I guess it's suspicious that test9_1_e is read directly from
test_эльфийские_письмена_9 but the store to test9_1 evolves a section anchor.
Here's the relevant generated ASM:
ldrr2, .L2
ldrr3, .L2+4
ldrr0, [r2]
movr2, #42
subsr1, r0, r2
rsbsr0, r1, #0
adcsr0, r0, r1
strr2, [r3]
bxlr
[...]
.wordtest_эльфийские_письмена_9
.word.LANCHOR0
[...]
.LANCHOR0 = . + 0
.typetest_эльфийские_письмена_9, %object
.sizetest_эльфийские_письмена_9, 4
test_эльфийские_письмена_9:
.space4
In case the C code is invalid / unspecified please advise how we could get the
desired behaviour for the GDC frontend. Currently we emit the VAR_DECLS in the
same way as without the 'asm ("test_эльфийские_письмена_9")' part except we set
DECL_ASSEMBLER_NAME accordingly.
[Bug middle-end/60214] Variables with same DECL_ASSEMBLER_NAME are treated as different variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60214 --- Comment #1 from Johannes Pfau --- Sorry, I forgot to add that this only happens if the test9_1 variable has got an initializer. However this is almost always the case for GDC/D as we have default initialization.
[Bug c++/60213] Weird crash when delete an object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60213
--- Comment #3 from hubert.vansteenhuyse at freecode dot be ---
(In reply to Marc Glisse from comment #2)
> Your example is bogus: { and } don't match, main must return int, etc. If I
> fix it so it compiles, I don't see any crash.
Of course it is, the example is merely a pseudo code to make clear what
happened.
In any case GDB reported a double deletion of the same address in similar code.
Don't worry about it, if someone else ever reports it then it might be worth to
take a closer look to it.
Thx.
[Bug c++/60213] Weird crash when delete an object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60213 --- Comment #4 from Marc Glisse --- (In reply to hubert.vansteenhuyse from comment #3) > Of course it is, the example is merely a pseudo code to make clear what > happened. That's my point, pseudo-code is useless, if we can't reproduce the issue it doesn't make it clear at all what is going on. Compiler bugs (in case this is one) often have unpredictable symptoms. > Don't worry about it, if someone else ever reports it then it might be worth > to take a closer look to it. But we will have no idea that it is related. If you can post a valid, self-contained example that exhibits the issue (preferably with a supported version of gcc, so at least 4.7), that would be helpful. Otherwise I'll just close the PR.
[Bug c++/60215] New: [4.9 Regression] ICE with invalid bit-field size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60215
Bug ID: 60215
Summary: [4.9 Regression] ICE with invalid bit-field size
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-std=c++11") triggers an
ICE on trunk:
==
struct A
{
void foo();
int i : foo;
};
==
bug.cc:4:11: error: width of bit-field 'i' has non-integral type ''
int i : foo;
^
bug.cc:4:11: internal compiler error: in cxx_eval_constant_expression, at
cp/semantics.c:9679
0x73dfc0 cxx_eval_constant_expression
../../gcc/gcc/cp/semantics.c:9679
0x7410d5 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/semantics.c:9807
0x6597ac check_bitfield_decl
../../gcc/gcc/cp/class.c:3250
0x6597ac check_field_decls
../../gcc/gcc/cp/class.c:3619
0x67002b check_bases_and_members
../../gcc/gcc/cp/class.c:5511
0x675221 finish_struct_1(tree_node*)
../../gcc/gcc/cp/class.c:6484
0x677574 finish_struct(tree_node*, tree_node*)
../../gcc/gcc/cp/class.c:6801
0x6a97ba cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19218
0x6a97ba cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19437
0x6a97ba cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14302
0x6c2ba0 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11547
0x6c9799 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11137
0x6acc63 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6d3f12 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d2c08 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6d44aa cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d44aa c_parse_file()
../../gcc/gcc/cp/parser.c:31536
0x7f3813 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
[Bug c++/60215] [4.9 Regression] ICE with invalid bit-field size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60215 Volker Reichelt changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Known to work||4.7.0, 4.8.0 Target Milestone|--- |4.9.0 Known to fail||4.9.0
[Bug c++/60216] New: [4.8/4.9 Regression] [c++11] Trouble with deleted template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60216
Bug ID: 60216
Summary: [4.8/4.9 Regression] [c++11] Trouble with deleted
template functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: accepts-invalid, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-std=c++11") triggers an
ICE since GCC 4.8.1:
struct A
{
template A(T) = delete;
};
template<> A::A(int) {}
A a(0);
bug.cc:8:6: error: use of deleted function 'A::A(T) [with T = int]'
A a(0);
^
bug.cc:8:6: internal compiler error: in maybe_explain_implicit_delete, at
cp/method.c:1422
0x7177c2 maybe_explain_implicit_delete(tree_node*)
../../gcc/gcc/cp/method.c:1422
0x6871f8 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:4656
0x5b1349 build_over_call
../../gcc/gcc/cp/call.c:7188
0x5b3d0a build_new_method_call_1
../../gcc/gcc/cp/call.c:7887
0x5b3d0a build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:7957
0x5b4d79 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7513
0x7080e9 expand_default_init
../../gcc/gcc/cp/init.c:1677
0x7080e9 expand_aggr_init_1
../../gcc/gcc/cp/init.c:1778
0x70adf3 build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/init.c:1529
0x5c7454 build_aggr_init_full_exprs
../../gcc/gcc/cp/decl.c:5591
0x5c7454 check_initializer
../../gcc/gcc/cp/decl.c:5727
0x5d99fc cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6396
0x6c81bd cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16815
0x6c9979 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11205
0x6acc63 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6d3f12 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d2c08 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6d44aa cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d44aa c_parse_file()
../../gcc/gcc/cp/parser.c:31536
0x7f3813 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
A similar testcase is wrongly accepted since GCC 4.8.1:
struct A
{
template void foo(T) = delete;
};
template<> void A::foo(int) {}
void bar()
{
A().foo(0);
}
[Bug c++/60216] [4.8/4.9 Regression] [c++11] Trouble with deleted template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60216 Volker Reichelt changed: What|Removed |Added Known to work||4.8.0 Target Milestone|--- |4.8.4 Known to fail||4.8.1, 4.8.2, 4.9.0
[Bug c++/60218] New: [c++11] ICE using __bases for broken class hierarchy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60218
Bug ID: 60218
Summary: [c++11] ICE using __bases for broken class hierarchy
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: error-recovery, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-std=c++11") triggers
an ICE since GCC 4.7.0 (when __bases was introduced):
==
template struct A {};
template struct B
{
typedef A<__bases(T)...> C;
};
struct X {};
struct Y : X* {};
B b;
==
bug.cc:9:13: error: expected '{' before '*' token
struct Y : X* {};
^
bug.cc:9:15: error: expected unqualified-id before '{' token
struct Y : X* {};
^
bug.cc:9:15: error: invalid type in declaration before '{' token
bug.cc: In instantiation of 'struct B':
bug.cc:11:6: required from here
bug.cc:5:28: internal compiler error: Segmentation fault
typedef A<__bases(T)...> C;
^
0xba53bf crash_signal
../../gcc/gcc/toplev.c:337
0x7214a0 tree_check
../../gcc/gcc/tree.h:2708
0x7214a0 dfs_calculate_bases_pre
../../gcc/gcc/cp/semantics.c:3696
0x71c30e dfs_walk_all(tree_node*, tree_node* (*)(tree_node*, void*), tree_node*
(*)(tree_node*, void*), void*)
../../gcc/gcc/cp/search.c:1583
0x721c08 calculate_bases_helper
../../gcc/gcc/cp/semantics.c:3718
0x73a427 calculate_bases(tree_node*)
../../gcc/gcc/cp/semantics.c:3748
0x618da3 tsubst_pack_expansion
../../gcc/gcc/cp/pt.c:9558
0x628eb2 tsubst_template_args
../../gcc/gcc/cp/pt.c:9792
0x628cf5 tsubst_template_args
../../gcc/gcc/cp/pt.c:9810
0x6296a3 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:10025
0x61ba41 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11436
0x62dbde tsubst_decl
../../gcc/gcc/cp/pt.c:10908
0x61beef tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11357
0x64a39a instantiate_class_template_1
../../gcc/gcc/cp/pt.c:9010
0x64a39a instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9274
0x6db9c3 complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:134
0x5c4f88 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:4719
0x5edeb7 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4682
0x6c7eee cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16680
0x6c9979 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11205
Please submit a full bug report, [etc.]
[Bug c++/60217] New: Numerous ICEs involving wrong usage of __bases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60217
Bug ID: 60217
Summary: Numerous ICEs involving wrong usage of __bases
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
One note up front: The testcases below involving __bases can be compiled
in C++98 mode. But, since __bases yields a parameter pack, shouldn't its
use only be allowed in C++11 mode - or at least trigger a warning in
C++98 mode?
The following invalid code snippet triggers an ICE since GCC 4.7.0
(when __bases was introduced):
==
template struct A
{
typedef A<__bases(int)> B;
};
==
bug.cc:3:25: internal compiler error: tree check: expected tree that contains
'typed' structure, have 'bases' in
any_template_arguments_need_structural_equality_p, at cp/pt.c:20994
typedef A<__bases(int)> B;
^
0xdc0f94 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.c:9364
0x626497 contains_struct_check
../../gcc/gcc/tree.h:2823
0x626497 any_template_arguments_need_structural_equality_p
../../gcc/gcc/cp/pt.c:20994
0x626497 lookup_template_class_1
../../gcc/gcc/cp/pt.c:7553
0x626497 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/gcc/cp/pt.c:7725
0x72dcb2 finish_template_type(tree_node*, tree_node*, int)
../../gcc/gcc/cp/semantics.c:2953
0x6c2068 cp_parser_template_id
../../gcc/gcc/cp/parser.c:13440
0x6c2388 cp_parser_class_name
../../gcc/gcc/cp/parser.c:19074
0x6b3bb9 cp_parser_qualifying_entity
../../gcc/gcc/cp/parser.c:5524
0x6b3bb9 cp_parser_nested_name_specifier_opt
../../gcc/gcc/cp/parser.c:5249
0x6cba67 cp_parser_simple_type_specifier
../../gcc/gcc/cp/parser.c:14638
0x6a948d cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14380
0x6c2ba0 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11547
0x6a5fb3 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20121
0x6a9724 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:19976
0x6a9724 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19210
0x6a9724 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19437
0x6a9724 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14302
0x6c2ba0 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11547
0x6c8883 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:23039
Please submit a full bug report, [etc.]
With an even shorter testcase one can trigger a different ICE:
==
template struct A
{
typedef __bases(int) B;
};
==
bug.cc:3:24: internal compiler error: tree check: expected tree that contains
'common' structure, have 'bases' in set_underlying_type, at
c-family/c-common.c:11445
typedef __bases(int) B;
^
0xdc0f94 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.c:9364
0x7e1c54 contains_struct_check
../../gcc/gcc/tree.h:2823
0x7e1c54 set_underlying_type(tree_node*)
../../gcc/gcc/c-family/c-common.c:11445
0x686426 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/gcc/cp/decl2.c:898
0x6a611f cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20429
0x6a9724 cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:19976
0x6a9724 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19210
0x6a9724 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19437
0x6a9724 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14302
0x6c2ba0 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11547
0x6c8883 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:23039
0x6c8d64 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:22915
0x6d4119 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10947
0x6d2c08 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6d44aa cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d44aa c_parse_file()
../../gcc/gcc/cp/parser.c:31536
0x7f3813 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1060
Please submit a full bug report, [etc.]
The last testcase only crashes trunk:
==
template struct A
{
typedef A<__bases(int) = int> B;
};
==
bug.cc:3:24: internal compiler error: tree check: expected tree that contains
'typed'
[Bug c++/60219] New: [4.8/4.9 Regression] [c++11] ICE invalid use of variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60219
Bug ID: 60219
Summary: [4.8/4.9 Regression] [c++11] ICE invalid use of
variadic template
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: diagnostic, ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-std=c++11") triggers
an ICE since GCC 4.8.0:
=
template void foo();
void bar()
{
foo<0>;
}
=
bug.cc: In function 'void bar()':
bug.cc:5:9: internal compiler error: tree check: accessed elt 3 of tree_vec
with 2 elts in coerce_template_parms, at cp/pt.c:6857
foo<0>;
^
0xdca805 tree_vec_elt_check_failed(int, int, char const*, int, char const*)
../../gcc/gcc/tree.c:9377
0x61aa12 tree_vec_elt_check
../../gcc/gcc/tree.h:2899
0x61aa12 coerce_template_parms
../../gcc/gcc/cp/pt.c:6857
0x633577 resolve_nondeduced_context(tree_node*)
../../gcc/gcc/cp/pt.c:16561
0x6f9907 convert_to_void(tree_node*, impl_conv_void, int)
../../gcc/gcc/cp/cvt.c:1244
0x726d8a finish_expr_stmt(tree_node*)
../../gcc/gcc/cp/semantics.c:684
0x6ae3e8 cp_parser_statement
../../gcc/gcc/cp/parser.c:9473
0x6af1b9 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9745
0x6af326 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9699
0x6c34fb cp_parser_function_body
../../gcc/gcc/cp/parser.c:18641
0x6c34fb cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18677
0x6c7842 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22792
0x6c86e1 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22704
0x6c86e1 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16585
0x6c9979 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11205
0x6acc63 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11086
0x6d3f12 cp_parser_declaration
../../gcc/gcc/cp/parser.c:10983
0x6d2c08 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10869
0x6d44aa cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4014
0x6d44aa c_parse_file()
../../gcc/gcc/cp/parser.c:31536
Please submit a full bug report, [etc.]
If I actually try to call foo<0>, I get a broken diagnostic ending in a colon:
==
template void foo();
void bar()
{
foo<0>();
}
==
bug.cc: In function 'void bar()':
bug.cc:5:10: error: no matching function for call to 'foo()'
foo<0>();
^
bug.cc:5:10: note: candidate is:
bug.cc:1:33: note: template > void foo()
template void foo();
^
bug.cc:1:33: note: template argument deduction/substitution failed:
Why?
[Bug c++/60219] [4.8/4.9 Regression] [c++11] ICE invalid use of variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60219 Volker Reichelt changed: What|Removed |Added Known to work||4.7.0 Target Milestone|--- |4.8.4 Known to fail||4.8.0, 4.9.0
[Bug c/60220] New: Vectorization : simple loop : fails to vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60220
Bug ID: 60220
Summary: Vectorization : simple loop : fails to vectorize
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: harmeeksingh at gmail dot com
#include
#include
#define FALSE ((char )0)
struct test
{
int*copy;
};
typedef struct test test;
void
foo(test *__restrict c, unsigned int a, unsigned int num)
{
unsigned int cnt;
for (cnt = 0; cnt < num ; cnt++)
c->copy[cnt] = FALSE;
for (cnt = 0; cnt < num ; cnt++)
printf("%u \n", c->copy[cnt]);
}
$ gcc -ggdb -O6 -march=native -pipe -fno-strict-aliasing -funroll-all-loops
-fpeel-loops -unroll-loops --param max-unroll-times=4 -ffast-math -fpeel-loops
-fwrapv -fPIC -pthread -rdynamic -DCLS=64 -mfpmath=sse -mmmx -msse -msse2
-msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -ftree-vectorize
-ftree-vectorizer-verbose=7 -fgraphite-identity -falign-functions=4
-falign-loops=4 -falign-jumps=4 -fexpensive-optimizations
-frerun-cse-after-loop -frerun-loop-opt -finline-functions -o /tmp/x.o -c
/tmp/x.c
Analyzing loop at /tmp/x.c:18
18: not vectorized: loop contains function calls or data references that cannot
be analyzed
Analyzing loop at /tmp/x.c:16
16: not vectorized: data ref analysis failed *D.2523_9 = 0;
16: not vectorized: data ref analysis failed *D.2523_9 = 0;
/tmp/x.c:13: note: vectorized 0 loops in function.
Gcc - version
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.7.2 20120921 (Red Hat 4.7.2-2) (GCC)
[Bug target/60203] Support long double/_Decimal128 direct move on power8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60203 --- Comment #3 from Michael Meissner --- Author: meissner Date: Sun Feb 16 03:08:03 2014 New Revision: 207808 URL: http://gcc.gnu.org/viewcvs?rev=207808&root=gcc&view=rev Log: [gcc] 2014-02-15 Michael Meissner PR target/60203 * config/rs6000/rs6000.md (rreg): Add TFmode, TDmode constraints. (mov_internal, TFmode/TDmode): Split TFmode/TDmode moves into 64-bit and 32-bit moves. On 64-bit moves, add support for using direct move instructions on ISA 2.07. Also adjust instruction length for 64-bit. (mov_64bit, TFmode/TDmode): Likewise. (mov_32bit, TFmode/TDmode): Likewise. [gcc/testsuite] 2014-02-15 Michael Meissner PR target/60203 * gcc.target/powerpc/pr60203.c: New testsuite. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr60203.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog
[Bug target/60203] Support long double/_Decimal128 direct move on power8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60203 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Michael Meissner --- Fixed in subversion id 207808.
[Bug target/60203] Support long double/_Decimal128 direct move on power8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60203 --- Comment #5 from Michael Meissner --- Author: meissner Date: Sun Feb 16 03:19:11 2014 New Revision: 207809 URL: http://gcc.gnu.org/viewcvs?rev=207809&root=gcc&view=rev Log: [gcc] 2014-02-15 Michael Meissner PR target/60203 * config/rs6000/rs6000.md (rreg): Add TFmode, TDmode constraints. (mov_internal, TFmode/TDmode): Split TFmode/TDmode moves into 64-bit and 32-bit moves. On 64-bit moves, add support for using direct move instructions on ISA 2.07. Also adjust instruction length for 64-bit. (mov_64bit, TFmode/TDmode): Likewise. (mov_32bit, TFmode/TDmode): Likewise. [gcc/testsuite] 2014-02-15 Michael Meissner PR target/60203 * gcc.target/powerpc/pr60203.c: New testsuite. Added: branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/pr60203.c - copied unchanged from r207808, trunk/gcc/testsuite/gcc.target/powerpc/pr60203.c Modified: branches/ibm/gcc-4_8-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.md branches/ibm/gcc-4_8-branch/gcc/testsuite/ChangeLog.ibm
[Bug c/60221] New: gcc -fexceptions generates unnecessary cleanup code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60221
Bug ID: 60221
Summary: gcc -fexceptions generates unnecessary cleanup code
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: redlizard at redlizard dot nl
> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/tmp/gcc-4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.2/configure --prefix=/tmp/gcc-4.8.2
--enable-languages=c,c++
Thread model: posix
gcc version 4.8.2 (GCC)
> cat test.c
void bar(void);
void foo(void)
{
struct { int x; } y;
bar();
}
When compiled with `gcc -fexceptions -O0 -c test.c`, the above code generates
cleanup code for stack unwinding purposes, referencing __gcc_personality_v0;
this necessitates linking with shared-libgcc.
I am not sure this is really a bug, but versions of gcc older than 4.7 do not
generate cleanup code for this example; neither does gcc 4.8 when the local
variable is replaced by `int y;`. Moreover, according to the gcc documentation,
there are "several situations" (I have been unable to find more a detailed
specification) in which linking with shared-libgcc is necessary, which includes
code throwing or catching exceptions, but should -- as far as I can see --
*not* include c code just passing through exceptions.
Tested on x86_64-unknown-linux-gnu, x86_64-unknown-linux-gnu -m32, and
i386-pc-solaris2.11, using gcc 4.7.1, 4.7.3, and 4.8.2. gcc 4.6.4 and earlier
tested versions are not affected. I have been unable to test gcc 4.7.0.
[Bug c/60220] Vectorization : simple loop : fails to vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60220 --- Comment #1 from Andrew Pinski --- In GCC 4.9 (maybe even in 4.8), the loop is converted into memset by the time the vectorizer gets around to the code.
[Bug middle-end/60221] gcc -fexceptions generates unnecessary cleanup code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60221 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|c |middle-end --- Comment #1 from Andrew Pinski --- Still fails as of: .ident"GCC: (GNU) 4.9.0 20131110 (experimental) [trunk revision 204654]" I thought I saw a dup of this bug. It is just a missed optimization at -O0 which was introduced by the addition of the CLOBBERing of local non-scalars.
[Bug lto/56088] [4.8/4.9 Regression] LTO error: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088 Yuxuan Shui changed: What|Removed |Added CC||yshuiv7 at gmail dot com --- Comment #11 from Yuxuan Shui --- This is still reproducible in GCC 4.8.2 on Gentoo when compiling packages like findutils.
[Bug lto/56088] [4.8/4.9 Regression] LTO error: error: inlining failed in call to always_inline ‘vswprintf’: recursive inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56088 Václav Zeman changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #12 from Václav Zeman --- (In reply to Yuxuan Shui from comment #11) > This is still reproducible in GCC 4.8.2 on Gentoo when compiling packages > like findutils. I am reopening this then.
[Bug fortran/52651] Fortran testsuite ICEs with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52651 Bug 52651 depends on bug 45586, which changed state. Bug 45586 Summary: [4.8 Regression] ICE non-trivial conversion at assignment http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Joost VandeVondele changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #103 from Joost VandeVondele --- (In reply to rguent...@suse.de from comment #102) > On February 8, 2014 1:47:14 PM GMT+01:00, "pault at gcc dot gnu.org" > >> Fixed on trunk. > I don't intend to backport this. Thus fixed for 4.9 & won't fix for earlier branches. Thanks!
