[Bug target/44073] x86 constants could be unduplicated
--- Comment #5 from astrange at ithinksw dot com 2010-08-08 06:39 --- That commit doesn't reverse cleanly anymore, and I'm not sure how to update it. I don't have any pre-2005 gccs at the moment to test with. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44073
[Bug fortran/43954] [4.4 regression] gfortran does not support -Wp, -MD for *.F
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2010-08-08 05:29 --- Closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug middle-end/45229] gcc.c-torture/execute/20000412-4.c ICEs with -fgraphite-identity
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-08-08 03:54 --- Looking through the remaining ICEs with -fgraphite-identity, the majority seems to fall into this category. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45229
[Bug middle-end/45231] New: gcc.c-torture/compile/941014-2.c ICEs with -fgraphite-identity
Current gcc trunk with the proposed graphite merge (http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00080.html) still ICEs the compiler when the gcc.c-torture/compile/941014-2.c testcase is compiled with -fgraphite-identity. The error appears as... gcc-4 -O3 -fomit-frame-pointer -w -c -m32 -fgraphite-identity -o 941014-2.o 941014-2.c 941014-2.c: In function f: 941014-2.c:2:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. and backtraces in gdb as... gdb /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/cc1 GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May 5 04:36:56 UTC 2010) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries . done (gdb) r -fpreprocessed 941014-2.i -fPIC -quiet -dumpbase 941014-2.c -mmacosx-version-min=10.6.4 -m32 -mtune=generic -auxbase-strip 941014-2.o -O3 -w -version -fomit-frame-pointer -fgraphite-identity -o 941014-2.s Starting program: /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/cc1 -fpreprocessed 941014-2.i -fPIC -quiet -dumpbase 941014-2.c -mmacosx-version-min=10.6.4 -m32 -mtune=generic -auxbase-strip 941014-2.o -O3 -w -version -fomit-frame-pointer -fgraphite-identity -o 941014-2.s Reading symbols for shared libraries .. done GNU C (GCC) version 4.6.0 20100807 (experimental) (x86_64-apple-darwin10.4.0) compiled by GNU C version 4.6.0 20100807 (experimental), GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 4.6.0 20100807 (experimental) (x86_64-apple-darwin10.4.0) compiled by GNU C version 4.6.0 20100807 (experimental), GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 51323d20c79050973b53377b407f3f68 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0061 gsi_for_stmt (stmt=0x141de9de0) at gimple.h:245 245 return (!(bb->flags & BB_RTL) && bb->il.gimple) ? bb->il.gimple->seq : NULL; (gdb) bt #0 gsi_for_stmt (stmt=0x141de9de0) at gimple.h:245 #1 0x0001004b5d7e in insert_out_of_ssa_copy (res=0x141e0bd38, var=, after_stmt=0x141de9de0) at ../../gcc-4.6-20100807/gcc/graphite-sese-to-poly.c:2130 #2 0x0001004b6630 in rewrite_phi_out_of_ssa (psi=0x7fff5fbfeae0) at ../../gcc-4.6-20100807/gcc/graphite-sese-to-poly.c:2328 #3 0x0001004bc499 in rewrite_reductions_out_of_ssa (scop=) at ../../gcc-4.6-20100807/gcc/graphite-sese-to-poly.c:2403 #4 0x00010049563d in graphite_transform_loops () at ../../gcc-4.6-20100807/gcc/graphite.c:290 #5 0x00010074121a in graphite_transforms () at ../../gcc-4.6-20100807/gcc/tree-ssa-loop.c:296 #6 0x000100582786 in execute_one_pass (pass=0x100c74260) at ../../gcc-4.6-20100807/gcc/passes.c:1567 #7 0x000100582a5d in execute_pass_list (pass=0x100c74260) at ../../gcc-4.6-20100807/gcc/passes.c:1622 #8 0x000100582a6f in execute_pass_list (pass=0x100c742c0) at ../../gcc-4.6-20100807/gcc/passes.c:1623 #9 0x000100582a6f in execute_pass_list (pass=0x100c74560) at ../../gcc-4.6-20100807/gcc/passes.c:1623 #10 0x000100582a6f in execute_pass_list (pass=0x100c73700) at ../../gcc-4.6-20100807/gcc/passes.c:1623 #11 0x0001006af1fc in tree_rest_of_compilation (fndecl=0x141e19000) at ../../gcc-4.6-20100807/gcc/tree-optimize.c:452 #12 0x0001008819fd in cgraph_expand_function (node=0x141e1d000) at ../../gcc-4.6-20100807/gcc/cgraphunit.c:1643 #13 0x000100884caa in cgraph_optimize () at ../../gcc-4.6-20100807/gcc/cgraphunit.c:1722 #14 0x00010088533a in cgraph_finalize_compilation_unit () at ../../gcc-4.6-20100807/gcc/cgraphunit.c:1185 #15 0x00010001cf05 in c_write_global_declarations () at ../../gcc-4.6-20100807/gcc/c-decl.c:9698 #16 0x00010064145e in toplev_main (argc=19, argv=0x7fff5fbfef68) at ../../gcc-4.6-20100807/gcc/toplev.c:983 #17 0x00011914 in start () -- Summary: gcc.c-torture/compile/941014-2.c ICEs with -fgraphite- identity Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-app
[Bug libstdc++/45226] the difference of fstream's open() in different GCC version
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-08 02:17 ---
(In reply to comment #2)
> Thank you,yeah,the code is not a self-contained testcase.I copile it with
> another codes which not show here.
Yes, but we don't want to see a useless chunk of your program, it doesn't help
anyone. You could have reduced the code to this and it would show the same
problem:
#include
void f()
{
std::ofstream txt_stream;
txt_stream.open("foo", "w");
}
Your example is full of unrelated code that has nothing to do with the problem.
> The main problem is open() function.For
> calling open() of GCC 3.4.6,what can I do in may code and how to update my
> code
> to ISO C++.Could please you give me specific example.Thank you in advance.
As I said, the second argument to ofstream::open is openmode
e.g.
txt_stream.open("foo", std::ios::out);
Please consult a C++ book or reference for more details.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45226
[Bug libstdc++/45226] the difference of fstream's open() in different GCC version
--- Comment #2 from china dot wenli dot wang at gmail dot com 2010-08-08 02:08 --- (In reply to comment #1) > 1) GCC 3.4.6 is ancient and no longer supported. > > 2) Your code is not a self-contained testcase, so noone can compile it. > > 3) std::ofstream::open does not take a string as the second parameter, it > takes > a bitmask of type std::ios:openmode. You need to update your code to ISO C++. > Mr Wakely, Thank you,yeah,the code is not a self-contained testcase.I copile it with another codes which not show here.The main problem is open() function.For calling open() of GCC 3.4.6,what can I do in may code and how to update my code to ISO C++.Could please you give me specific example.Thank you in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45226
[Bug fortran/43954] [4.4 regression] gfortran does not support -Wp, -MD for *.F
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2010-08-08 01:59 --- Subject: Bug 43954 Author: jvdelisle Date: Sun Aug 8 01:59:15 2010 New Revision: 162990 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162990 Log: 2010-08-07 Daniel Franke PR fortran/31588 PR fortran/43954 Backport from mainline: * gfortranspec.c (lang_specific_driver): Removed deprecation warning for -M. * lang.opt: Add options -M, -MM, -MD, -MMD, -MF, -MG, -MP, -MT, -MQ. * lang-specs.h (CPP_FORWARD_OPTIONS): Add -M* options. * cpp.h (gfc_cpp_makedep): New. (gfc_cpp_add_dep): New. (gfc_cpp_add_target): New. * cpp.c (gfc_cpp_option): Add deps* members. (gfc_cpp_makedep): New. (gfc_cpp_add_dep): New. (gfc_cpp_add_target): New. (gfc_cpp_init_options): Initialize new options. (gfc_cpp_handle_option): Handle new options. (gfc_cpp_post_options): Map new options to libcpp-options. (gfc_cpp_init): Handle deferred -MQ and -MT options. (gfc_cpp_done): If requested, write dependencies to file. * module.c (gfc_dump_module): Add a module filename as target. * scanner.c (open_included_file): New parameter system; add the included file as dependency. (gfc_open_included_file): Add the included file as dependency. (gfc_open_intrinsic_module): Likewise. * invoke.texi: Removed deprecation warning for -M. * gfortran.texi: Removed Makefile-dependencies project. Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/cpp.c branches/gcc-4_4-branch/gcc/fortran/cpp.h branches/gcc-4_4-branch/gcc/fortran/gfortran.texi branches/gcc-4_4-branch/gcc/fortran/gfortranspec.c branches/gcc-4_4-branch/gcc/fortran/invoke.texi branches/gcc-4_4-branch/gcc/fortran/lang-specs.h branches/gcc-4_4-branch/gcc/fortran/lang.opt branches/gcc-4_4-branch/gcc/fortran/module.c branches/gcc-4_4-branch/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2010-08-08 01:59 --- Subject: Bug 31588 Author: jvdelisle Date: Sun Aug 8 01:59:15 2010 New Revision: 162990 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162990 Log: 2010-08-07 Daniel Franke PR fortran/31588 PR fortran/43954 Backport from mainline: * gfortranspec.c (lang_specific_driver): Removed deprecation warning for -M. * lang.opt: Add options -M, -MM, -MD, -MMD, -MF, -MG, -MP, -MT, -MQ. * lang-specs.h (CPP_FORWARD_OPTIONS): Add -M* options. * cpp.h (gfc_cpp_makedep): New. (gfc_cpp_add_dep): New. (gfc_cpp_add_target): New. * cpp.c (gfc_cpp_option): Add deps* members. (gfc_cpp_makedep): New. (gfc_cpp_add_dep): New. (gfc_cpp_add_target): New. (gfc_cpp_init_options): Initialize new options. (gfc_cpp_handle_option): Handle new options. (gfc_cpp_post_options): Map new options to libcpp-options. (gfc_cpp_init): Handle deferred -MQ and -MT options. (gfc_cpp_done): If requested, write dependencies to file. * module.c (gfc_dump_module): Add a module filename as target. * scanner.c (open_included_file): New parameter system; add the included file as dependency. (gfc_open_included_file): Add the included file as dependency. (gfc_open_intrinsic_module): Likewise. * invoke.texi: Removed deprecation warning for -M. * gfortran.texi: Removed Makefile-dependencies project. Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/cpp.c branches/gcc-4_4-branch/gcc/fortran/cpp.h branches/gcc-4_4-branch/gcc/fortran/gfortran.texi branches/gcc-4_4-branch/gcc/fortran/gfortranspec.c branches/gcc-4_4-branch/gcc/fortran/invoke.texi branches/gcc-4_4-branch/gcc/fortran/lang-specs.h branches/gcc-4_4-branch/gcc/fortran/lang.opt branches/gcc-4_4-branch/gcc/fortran/module.c branches/gcc-4_4-branch/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug middle-end/45230] gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-identity
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-08-08 01:56 --- Created an attachment (id=21435) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21435&action=view) gdb log stepping from sese.c:534 breakpoint until crash -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45230
[Bug middle-end/45230] New: gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-identity
Current gcc trunk with the proposed graphite merge
(http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00080.html) still ICEs the
compiler when the gcc.c-torture/execute/strncmp-1.c testcase is compiled with
-fgraphite-identity. The error appears as...
gcc-4 strncmp-1.c -w -Os -lm -m32 -fgraphite-identity -o strncmp-1.x7
strncmp-1.c: In function main:
strncmp-1.c:44:1: internal compiler error: in rename_uses, at sese.c:534
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
The ICE doesn't backtrace in gdb...
gdb /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/cc1
GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May 5 04:36:56 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries . done
(gdb) r -fpreprocessed strncmp-1.i -fPIC -quiet -dumpbase strncmp-1.c
-mmacosx-version-min=10.6.4 -m32 -mtune=generic -auxbase strncmp-1 -Os -w
-version -fgraphite-identity -o strncmp-1.s
Starting program:
/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/cc1 -fpreprocessed
strncmp-1.i -fPIC -quiet -dumpbase strncmp-1.c -mmacosx-version-min=10.6.4 -m32
-mtune=generic -auxbase strncmp-1 -Os -w -version -fgraphite-identity -o
strncmp-1.s
Reading symbols for shared libraries .. done
GNU C (GCC) version 4.6.0 20100807 (experimental) (x86_64-apple-darwin10.4.0)
compiled by GNU C version 4.6.0 20100807 (experimental), GMP version
4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.6.0 20100807 (experimental) (x86_64-apple-darwin10.4.0)
compiled by GNU C version 4.6.0 20100807 (experimental), GMP version
4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 51323d20c79050973b53377b407f3f68
strncmp-1.c: In function main:
strncmp-1.c:44:1: internal compiler error: in rename_uses, at sese.c:534
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Program exited with code 04.
(gdb) bt
No stack.
A log stepping from the sese.c:534 breakpoint up to the crash is attached.
--
Summary: gcc.c-torture/execute/strncmp-1.c ICEs with -fgraphite-
identity
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: howarth at nitro dot med dot uc dot edu
GCC build triplet: x86_64-apple-darwin10
GCC host triplet: x86_64-apple-darwin10
GCC target triplet: x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45230
[Bug tree-optimization/45220] [4.6 Regression] libjava/libltdl/ltdl.c:1272:1: internal compiler error: Segmenta
--- Comment #2 from danglin at gcc dot gnu dot org 2010-08-08 01:00 --- Introduced in revision 162842. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Target Milestone|4.6.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45220
[Bug middle-end/45229] gcc.c-torture/execute/20000412-4.c ICEs with -fgraphite-identity
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-08-07 23:41 --- Another apparent example of the same ICE is since in... FAIL: gfortran.dg/bounds_check_strlen_8.f90 -O2 (internal compiler error) which fails as... gfortran bounds_check_strlen_8.f90 -O2 -fbounds-check -fgraphite-identity -m32 -o ./bounds_check_strlen_8.exe bounds_check_strlen_8.f90: In function s1: bounds_check_strlen_8.f90:26:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. and backtraces as... gdb /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/f951 GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May 5 04:36:56 UTC 2010) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries . done (gdb) r bounds_check_strlen_8.f90 -fPIC -quiet -dumpbase bounds_check_strlen_8.f90 -mmacosx-version-min=10.6.4 -m32 -mtune=generic -auxbase bounds_check_strlen_8 -O2 -version -fbounds-check -fgraphite-identity -fintrinsic-modules-path /sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/finclude -o bounds_check_strlen_8.s Starting program: /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/f951 bounds_check_strlen_8.f90 -fPIC -quiet -dumpbase bounds_check_strlen_8.f90 -mmacosx-version-min=10.6.4 -m32 -mtune=generic -auxbase bounds_check_strlen_8 -O2 -version -fbounds-check -fgraphite-identity -fintrinsic-modules-path /sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/finclude -o bounds_check_strlen_8.s Reading symbols for shared libraries .. done GNU Fortran (GCC) version 4.6.0 20100807 (experimental) (x86_64-apple-darwin10.4.0) compiled by GNU C version 4.6.0 20100807 (experimental), GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU Fortran (GCC) version 4.6.0 20100807 (experimental) (x86_64-apple-darwin10.4.0) compiled by GNU C version 4.6.0 20100807 (experimental), GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x is_gimple_reg (t=0x0) at ../../gcc-4.6-20100807/gcc/gimple.c:2861 2861 if (TREE_CODE (t) == SSA_NAME) (gdb) bt #0 is_gimple_reg (t=0x0) at ../../gcc-4.6-20100807/gcc/gimple.c:2861 #1 0x00010050c489 in rewrite_cross_bb_scalar_deps_out_of_ssa (scop=) at ../../gcc-4.6-20100807/gcc/graphite-sese-to-poly.c:2468 #2 0x0001004e4ce5 in graphite_transform_loops () at ../../gcc-4.6-20100807/gcc/graphite.c:291 #3 0x0001007908ba in graphite_transforms () at ../../gcc-4.6-20100807/gcc/tree-ssa-loop.c:296 #4 0x0001005d1e26 in execute_one_pass (pass=0x100cde360) at ../../gcc-4.6-20100807/gcc/passes.c:1567 #5 0x0001005d20fd in execute_pass_list (pass=0x100cde360) at ../../gcc-4.6-20100807/gcc/passes.c:1622 #6 0x0001005d210f in execute_pass_list (pass=0x100cde3c0) at ../../gcc-4.6-20100807/gcc/passes.c:1623 #7 0x0001005d210f in execute_pass_list (pass=0x100cde660) at ../../gcc-4.6-20100807/gcc/passes.c:1623 #8 0x0001005d210f in execute_pass_list (pass=0x100cdd800) at ../../gcc-4.6-20100807/gcc/passes.c:1623 #9 0x0001006fe89c in tree_rest_of_compilation (fndecl=0x141ef3600) at ../../gcc-4.6-20100807/gcc/tree-optimize.c:452 #10 0x0001008d109d in cgraph_expand_function (node=0x141ef7158) at ../../gcc-4.6-20100807/gcc/cgraphunit.c:1643 #11 0x0001008d434a in cgraph_optimize () at ../../gcc-4.6-20100807/gcc/cgraphunit.c:1722 #12 0x0001008d49da in cgraph_finalize_compilation_unit () at ../../gcc-4.6-20100807/gcc/cgraphunit.c:1185 #13 0x00010055f7c6 in write_global_declarations () at ../../gcc-4.6-20100807/gcc/langhooks.c:310 #14 0x000100690afe in toplev_main (argc=19, argv=0x7fff5fbfee80) at ../../gcc-4.6-20100807/gcc/toplev.c:983 #15 0x000117c4 in start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45229
[Bug middle-end/45229] New: gcc.c-torture/execute/20000412-4.c ICEs with -fgraphite-identity
Current gcc trunk with the proposed graphite merge (http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00080.html) still ICEs the compiler when the gcc.c-torture/execute/2412-4.c testcase is compiled with -fgraphite-identity. The error appears as... gcc-4 2412-4.c -w -O2 -fgraphite-identity -lm -o 2412-4.x2 2412-4.c: In function main: 2412-4.c:17:7: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. and backtraces as... gdb /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/cc1 GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May 5 04:36:56 UTC 2010) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries . done (gdb) r -quiet -v -D__DYNAMIC__ 2412-4.c -fPIC -quiet -dumpbase 2412-4.c -mmacosx-version-min=10.6.4 -mtune=generic -auxbase 2412-4 -O2 -w -version -fgraphite-identity -o /var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccuOxnFJ.s Starting program: /sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/cc1 -quiet -v -D__DYNAMIC__ 2412-4.c -fPIC -quiet -dumpbase 2412-4.c -mmacosx-version-min=10.6.4 -mtune=generic -auxbase 2412-4 -O2 -w -version -fgraphite-identity -o /var/folders/1C/1CdoNxmNFHyOIjNBLNuJhTM/-Tmp-//ccuOxnFJ.s Reading symbols for shared libraries .. done GNU C (GCC) version 4.6.0 20100807 (experimental) (x86_64-apple-darwin10.4.0) compiled by GNU C version 4.6.0 20100807 (experimental), GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/../../../../x86_64-apple-darwin10.4.0/include" #include "..." search starts here: #include <...> search starts here: /sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/include /sw/lib/gcc4.6/include /sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin10.4.0/4.6.0/include-fixed /usr/include /System/Library/Frameworks /Library/Frameworks End of search list. GNU C (GCC) version 4.6.0 20100807 (experimental) (x86_64-apple-darwin10.4.0) compiled by GNU C version 4.6.0 20100807 (experimental), GMP version 4.3.2, MPFR version 2.4.2-p3, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 51323d20c79050973b53377b407f3f68 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x is_gimple_reg (t=0x0) at ../../gcc-4.6-20100807/gcc/gimple.c:2861 2861 if (TREE_CODE (t) == SSA_NAME) (gdb) bt #0 is_gimple_reg (t=0x0) at ../../gcc-4.6-20100807/gcc/gimple.c:2861 #1 0x0001004bcde9 in rewrite_cross_bb_scalar_deps_out_of_ssa (scop=) at ../../gcc-4.6-20100807/gcc/graphite-sese-to-poly.c:2468 #2 0x000100495645 in graphite_transform_loops () at ../../gcc-4.6-20100807/gcc/graphite.c:291 #3 0x00010074121a in graphite_transforms () at ../../gcc-4.6-20100807/gcc/tree-ssa-loop.c:296 #4 0x000100582786 in execute_one_pass (pass=0x100c74260) at ../../gcc-4.6-20100807/gcc/passes.c:1567 #5 0x000100582a5d in execute_pass_list (pass=0x100c74260) at ../../gcc-4.6-20100807/gcc/passes.c:1622 #6 0x000100582a6f in execute_pass_list (pass=0x100c742c0) at ../../gcc-4.6-20100807/gcc/passes.c:1623 #7 0x000100582a6f in execute_pass_list (pass=0x100c74560) at ../../gcc-4.6-20100807/gcc/passes.c:1623 #8 0x000100582a6f in execute_pass_list (pass=0x100c73700) at ../../gcc-4.6-20100807/gcc/passes.c:1623 #9 0x0001006af1fc in tree_rest_of_compilation (fndecl=0x141e2b000) at ../../gcc-4.6-20100807/gcc/tree-optimize.c:452 #10 0x0001008819fd in cgraph_expand_function (node=0x141e2a158) at ../../gcc-4.6-20100807/gcc/cgraphunit.c:1643 #11 0x000100884caa in cgraph_optimize () at ../../gcc-4.6-20100807/gcc/cgraphunit.c:1722 #12 0x00010088533a in cgraph_finalize_compilation_unit () at ../../gcc-4.6-20100807/gcc/cgraphunit.c:1185 #13 0x00010001cf05 in c_write_global_declarations () at ../../gcc-4.6-20100807/gcc/c-decl.c:9698 #14 0x00010064145e in toplev_main (argc=19, argv=0x7fff5fbfef28) at ../../gcc-4.6-20100807/gcc/toplev.c:983 #15 0x00011914 in start () (gdb) -- Summary: gcc.c-torture/execute/2412-4.c ICEs with -fgraphite- identity Product: gcc Version: 4.6.0
[Bug libstdc++/45228] [C++0x] Can't copy-construct "tuple" from "const tuple" rvalue
--- Comment #2 from paolo dot carlini at oracle dot com 2010-08-07 22:19
---
Our std::tuple still needs work, but I see am inconsistency here between the
variadic and the non variadic case which I don't understand, irrespective of
library details. Consider the following reduced testcase: it outputs *only*
"Two (m)", no "Two (2)". It seems pretty obvious to me that the constructor
"Two", which takes *individual elements*, certainly should never be involved,
but it is, in the variadic case only.
Jason can you have a look? Thanks in advance!
///
#include
template
struct tuple_m
{
tuple_m() { }
explicit
tuple_m(const Types&...)
{ std::cout << "One (m)\n"; }
template
explicit
tuple_m(UTypes&&...)
{ std::cout << "Two (m)\n"; }
tuple_m(const tuple_m&)
{ std::cout << "Three (m)\n"; }
tuple_m(tuple_m&&)
{ std::cout << "Four (m)\n"; }
template
tuple_m(const tuple_m&)
{ std::cout << "Five (m)\n"; }
template
tuple_m(tuple_m&&)
{ std::cout << "Six (m)\n"; }
};
template
struct tuple_2
{
tuple_2() { }
explicit
tuple_2(const T1&, const T2&)
{ std::cout << "One (2)\n"; }
template
explicit
tuple_2(UT1&&, UT2&&)
{ std::cout << "Two (2)\n"; }
tuple_2(const tuple_2&)
{ std::cout << "Three (2)\n"; }
tuple_2(tuple_2&&)
{ std::cout << "Four (2)\n"; }
template
tuple_2(const tuple_2&)
{ std::cout << "Five (2)\n"; }
template
tuple_2(tuple_2&&)
{ std::cout << "Six (2)\n"; }
};
typedef tuple_2 tuple_2_type;
typedef tuple_m tuple_m_type;
const tuple_2_type f2() { return tuple_2_type(); }
const tuple_m_type fm() { return tuple_m_type(); }
int main()
{
tuple_2_type test_2(f2());
tuple_m_type test_m(fm());
}
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
CC||paolo dot carlini at oracle
||dot com, jason at gcc dot
||gnu dot org
Summary|Can't copy-construct|[C++0x] Can't copy-construct
|"tuple" from |"tuple" from
|"const tuple" |"const tuple"
|rvalue |rvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45228
[Bug target/44581] [4.5/4.6 Regression] internal compiler error: in simplify_subreg
--- Comment #4 from danglin at gcc dot gnu dot org 2010-08-07 22:04 --- Appears to be fixed on trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44581
[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division
--- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-07 21:36 --- Subject: Re: [4.4/4.5/4.6 regression] wrong code for complex division > So the following should fix this. Can you bootstrap/test this? Testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-08-07 21:16
---
Ok, I see when gimplifying the call that we mark it for NRV because while
x doesn't have it's address taken it's value-expr has and we didn't replace
it at that point but we check
4262 else if (!is_gimple_non_addressable (*to_p))
4271use_target = true;
so I think this is a bug that it doesn't mark the original parameter
decl as address-taken which happens here (function.c:gimplify_parameters):
/* If PARM was addressable, move that flag over
to the local copy, as its address will be taken,
not the PARMs. */
if (TREE_ADDRESSABLE (parm))
{
TREE_ADDRESSABLE (parm) = 0;
TREE_ADDRESSABLE (local) = 1;
}
We should defer clearing the param addressable flag to update_address_taken.
So the following should fix this. Can you bootstrap/test this?
Index: gcc/function.c
===
--- gcc/function.c (revision 162781)
+++ gcc/function.c (working copy)
@@ -3423,12 +3423,10 @@ gimplify_parameters (void)
DECL_IGNORED_P (local) = 0;
/* If PARM was addressable, move that flag over
to the local copy, as its address will be taken,
-not the PARMs. */
+not the PARMs. Keep the parms address taken
+as we'll query that flag during gimplification. */
if (TREE_ADDRESSABLE (parm))
- {
- TREE_ADDRESSABLE (parm) = 0;
- TREE_ADDRESSABLE (local) = 1;
- }
+ TREE_ADDRESSABLE (local) = 1;
}
else
{
(patch to the 4.5 branch, but should apply to the trunk as well).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug fortran/42526] bogus truncation warning for default-initialized character components
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-08-07 21:10 --- Yes, fixed. I will make a test case out of this with the -Wall so we do not regress. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-07 21:10:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42526
[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-07 21:04 --- Subject: Re: [4.4/4.5/4.6 regression] wrong code for complex division > On i?86-linux I see > > : > g (x); > D.24518 = 1.0e+0; > x = std::operator/ (&D.24518, &x); > g (x); > > so no return-slot optimization. So I guess it has something to do with > the callee-copy thing of the x argument to this function. Building a cross > ... On hppa-linux, I see at -O0 x.1 = x; g (x.1); D.24646 = 1.0e+0; x.1 = std::operator/ (&D.24646, &x.1); [return slot optimization] g (x.1); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-07 21:00 --- Subject: Re: [4.4/4.5/4.6 regression] wrong code for complex division > Btw, does this only happen at -O0? If you adjust the testcase like No, it also fails at -O2 where the entire computation is inline. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-07 20:57 --- Subject: Re: [4.4/4.5/4.6 regression] wrong code for complex division > ;; x.1 = std::operator/ (&D.24646, &x.1); [return slot optimization] > > Isn't this fixed on trunk since > > 2010-07-26 Richard Guenther > > PR tree-optimization/43784 > * tree-nrv.c (dest_safe_for_nrv_p): It's not safe to NRV > if the destination is used by the call. Still present on trunk today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-08-07 20:40 --- On i?86-linux I see : g (x); D.24518 = 1.0e+0; x = std::operator/ (&D.24518, &x); g (x); so no return-slot optimization. So I guess it has something to do with the callee-copy thing of the x argument to this function. Building a cross ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-07 20:39 ---
Btw, does this only happen at -O0? If you adjust the testcase like
#include
#include
void __attribute__((noinline))
g(std::complex x)
{
std::cout << x << std::endl;
}
void __attribute__((noinline))
f(std::complex x)
{
g (x);
x = 1.0 / x;
g (x);
}
int main()
{
f(2.0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-07 20:36 --- The argument should have prevented return slot optimization here. ;; x.1 = std::operator/ (&D.24646, &x.1); [return slot optimization] Isn't this fixed on trunk since 2010-07-26 Richard Guenther PR tree-optimization/43784 * tree-nrv.c (dest_safe_for_nrv_p): It's not safe to NRV if the destination is used by the call. ? Well, I'll have a look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug target/45213] "suffix or operands invalid for `push'" triggered by optimisations on x86_64
--- Comment #8 from uros at gcc dot gnu dot org 2010-08-07 20:32 --- Subject: Bug 45213 Author: uros Date: Sat Aug 7 20:32:30 2010 New Revision: 162983 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162983 Log: PR target/45213 * config/i386/i386.c (ix86_print_operand): Handle 'q' operand modifier to output 32bit SFmode immediate as 8 byte sign extended value. testsuite/ChangeLog: PR target/45213 * gcc.target/i386/pr45213.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr45213.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45213
[Bug target/45063] [4.6 Regression] ICE: Segmentation fault (cc1) compiling matmul_i1.c
--- Comment #19 from danglin at gcc dot gnu dot org 2010-08-07 20:26 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45063
[Bug libstdc++/45228] Can't copy-construct "tuple" from "const tuple" rvalue
--- Comment #1 from jorrit at jorrit dot de 2010-08-07 20:24 --- I also reported this to Debian: http://bugs.debian.org/592153 -- jorrit at jorrit dot de changed: What|Removed |Added CC||jorrit at jorrit dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45228
[Bug libstdc++/45228] New: Can't copy-construct "tuple" from "const tuple" rvalue
The following program fails to compile:
==
#include
typedef std::tuple Tuple;
//typedef std::tuple Tuple;
Tuple A() { return Tuple(); }
const Tuple B() { return Tuple(); }
int main()
{
Tuple test(B());
//Tuple test(A());
}
==
The program compiles successfully when A() is used instead of B() to
initialize the "test", or when a two-element tuple is used instead of a
three-element tuple.
This has happened with an svn snapshot of of g++-4.6 (Debians gcc-snapshot
version 20100702-1) and with g++-4.4 (Debians g++-4.4 version 4.4.4-7).
The compiler output is
==
export PATH=/usr/lib/gcc-snapshot/bin:$PATH && cd
~/src/dune2/dune-pdelab/dune/pdelab/test && g++ --version && g++ --std=c++0x
-O0 -Wall tupletest.cc -o tupletest
g++ (Debian 20100702-1) 4.6.0 20100702 (experimental) [trunk revision 161740]
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
In file included from tupletest.cc:1:0:
/usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:
In constructor 'std::_Head_base<_Idx, _Head, false>::_Head_base(_UHead&&) [with
_UHead = const std::tuple, unsigned int _Idx = 0u, _Head =
int]':
/usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:161:38:
instantiated from 'std::_Tuple_impl<_Idx, _Head, _Tail
...>::_Tuple_impl(_UHead&&, _UTail&& ...) [with _UHead = const std::tuple, _UTail = {}, unsigned int _Idx = 0u, _Head = int, _Tail = {int,
int}]'
/usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:239:54:
instantiated from 'std::tuple< >::tuple(_UElements&&
...) [with _UElements = {const std::tuple}, _Elements = {int,
int, int}]'
tupletest.cc:11:17: instantiated from here
/usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/4.6.0/../../../../include/c++/4.6.0/tuple:94:42:
error: cannot convert 'const std::tuple' to 'int' in
initialization
==
--
Summary: Can't copy-construct "tuple" from "const
tuple" rvalue
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jorrit at jorrit dot de
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45228
[Bug c++/45201] ICE: stack overflow
--- Comment #6 from mr dot chr dot schmidt at online dot de 2010-08-07 20:01 --- Created an attachment (id=21434) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21434&action=view) gdb backtrace -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
[Bug c++/45201] ICE: stack overflow
--- Comment #5 from mr dot chr dot schmidt at online dot de 2010-08-07 20:00 --- Created an attachment (id=21433) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21433&action=view) cc1plus invocation commands -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-07 19:59 --- Subject: Re: [4.4/4.5/4.6 regression] wrong code for complex division Attached .ii. --- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2010-08-07 19:59 --- Created an attachment (id=21432) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21432&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug c++/45201] ICE: stack overflow
--- Comment #4 from mr dot chr dot schmidt at online dot de 2010-08-07 19:58 --- I am able to reproduce this stack overflow with other source files as well - even somtimes when compiling without "-g" . -- mr dot chr dot schmidt at online dot de changed: What|Removed |Added Summary|ICE: stack overflow during |ICE: stack overflow |debug information generation| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division
--- Comment #3 from danglin at gcc dot gnu dot org 2010-08-07 19:58 --- Richard do you know what's wrong? I think the issue is the return slot optimization. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug tree-optimization/44632] [4.4/4.5/4.6 regression] wrong code for complex division
--- Comment #2 from danglin at gcc dot gnu dot org 2010-08-07 19:52 ---
With slightly modified test,
#include
#include
void g(std::complex x)
{
std::cout << x << std::endl;
}
void f(std::complex x)
{
g (x);
x = 1.0 / x;
g (x);
}
int main()
{
f(2.0);
}
it appears RTL is wrong at expansion:
;; x.1 = std::operator/ (&D.24646, &x.1); [return slot optimization]
(insn 18 17 19 (set (reg:SI 102)
(plus:SI (reg/f:SI 90 virtual-stack-vars)
(const_int 8 [0x8]))) test.cxx:12 -1
(nil))
(insn 19 18 20 (set (reg:SI 103)
(plus:SI (reg/f:SI 90 virtual-stack-vars)
(const_int 8 [0x8]))) test.cxx:12 -1
(nil))
(insn 20 19 21 (set (reg:SI 28 %r28)
(reg:SI 103)) test.cxx:12 -1
(nil))
(insn 21 20 22 (set (reg:SI 26 %r26)
(reg/f:SI 90 virtual-stack-vars)) test.cxx:12 -1
(nil))
(insn 22 21 23 (set (reg:SI 25 %r25)
(reg:SI 102)) test.cxx:12 -1
(nil))
(call_insn 23 22 0 (parallel [
(call (mem:SI (symbol_ref/v/i:SI
("@_ZStdvIdESt7complexIT_ERKS1_RKS2_") [flags 0x1] ) [0 S4 A32])
(const_int 16 [0x10]))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (const_int 0 [0]))
]) test.cxx:12 -1
(nil)
(expr_list:REG_DEP_TRUE (use (reg:SI 25 %r25))
(expr_list:REG_DEP_TRUE (use (reg:SI 26 %r26))
(expr_list:REG_DEP_TRUE (use (reg:SI 28 %r28))
(nil)
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Component|target |tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug target/44632] [4.4/4.5/4.6 regression] wrong code for complex division
--- Comment #1 from danglin at gcc dot gnu dot org 2010-08-07 19:32 ---
Starting program: /home/dave/gnu/gcc-4.6/objdir/gcc/testsuite/g++/test
(2,0)
Breakpoint 2, 0x000109f8 in f (x=...) at test.cxx:12
12 x = 1.0 / x;
(gdb) step
std::operator/ (_...@0xc0246388, __y=...)
at /home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/complex:429
429 complex<_Tp> __r = __x;
(gdb) p &__y
$15 = (const std::complex *) 0xc0246390
(gdb) p &__r
$16 = (std::complex *) 0xc0246390
(gdb) p __y
$17 = (const std::complex &) @0xc0246390: {_M_value = 2 + 0 * I}
(gdb) p __r
$18 = {_M_value = 2 + 0 * I}
(gdb) step
std::complex::complex (this=0xc0246390, __r=1, __i=0)
at /home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/complex:1172
1172__real__ _M_value = __r;
(gdb)
1173__imag__ _M_value = __i;
(gdb)
1174 }
(gdb)
std::operator/ (_...@0xc0246388, __y=...)
at /home/dave/gnu/gcc/objdir/hppa-linux/libstdc++-v3/include/complex:430
430 __r /= __y;
(gdb) p __y
$19 = (const std::complex &) @0xc0246390: {_M_value = 1 + 0 * I}
(gdb) p __r
$20 = {_M_value = 1 + 0 * I}
The problem is __r and __y share the same location.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug target/44632] [4.4/4.5/4.6 regression] wrong code for complex division
-- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-07 19:13:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44632
[Bug tree-optimization/45219] [4.6 Regression] ICE: SIGSEGV in dominated_by_p (dominance.c:973) with -O2 -fprofile-generate
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-07 18:46 --- It is caused by revision 162842: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00053.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45219
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #8 from dominiq at lps dot ens dot fr 2010-08-07 18:31 --- With trunk the ICE is a "Segmentation fault" and the backtrace is #0 0x0001417aee0b in __gmpz_sub () #1 0x0001000e1c8f in transfer_array_component (expr=0x141f04300, cm=0x141915170, where=0x141915ca8) at ../../work/gcc/fortran/trans-io.c:1933 #2 0x0001000e20c9 in transfer_expr (se=0x7fff5fbfd450, ts=, addr_expr=, code=0x141915c90) at ../../work/gcc/fortran/trans-io.c:2094 #3 0x0001000e6346 in gfc_trans_transfer (code=) at ../../work/gcc/fortran/trans-io.c:2230 #4 0x0001000a87d8 in trans_code (code=0x141915c90, cond=0x1418453b8) at ../../work/gcc/fortran/trans.c:1281 #5 0x0001000e409f in build_dt (function=0x141ef1a00, code=0x141915ed0) at ../../work/gcc/fortran/trans-io.c:1800 #6 0x0001000a8818 in trans_code (code=0x141915ed0, cond=0x0) at ../../work/gcc/fortran/trans.c:1253 #7 0x0001000c6ca2 in gfc_generate_function_code (ns=) at ../../work/gcc/fortran/trans-decl.c:4495 #8 0x0001000a9103 in gfc_generate_module_code (ns=) at ../../work/gcc/fortran/trans.c:1412 #9 0x00010006af31 in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4395 #10 0x0001000a3abc in gfc_be_parse_file (set_yydebug=) at ../../work/gcc/fortran/f95-lang.c:241 #11 0x0001006924da in toplev_main (argc=2, argv=0x7fff5fbfd9d8) at ../../work/gcc/toplev.c:971 #12 0x00010c84 in start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/43954] [4.4 regression] gfortran does not support -Wp, -MD for *.F
--- Comment #19 from jvdelisle at verizon dot net 2010-08-07 18:25 --- Subject: Re: [4.4 regression] gfortran does not support -Wp, -MD for *.F > Thanks a lot! > > Only if you could please also apply the -4.4 version. *Please* > > The rationale for this is that 4.4 will be the default compiler in the > next upcoming Debian stable. Will do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug fortran/43954] [4.4 regression] gfortran does not support -Wp, -MD for *.F
--- Comment #18 from kirr at landau dot phys dot spbu dot ru 2010-08-07 18:21 --- Subject: Re: [4.3/4.4 regression] gfortran does not support -Wp, -MD for *.F On Sat, Aug 07, 2010 at 04:52:14PM -, jvdelisle at gcc dot gnu dot org wrote: > --- Comment #16 from jvdelisle at gcc dot gnu dot org 2010-08-07 16:52 > --- > Subject: Bug 43954 > > Author: jvdelisle > Date: Sat Aug 7 16:51:55 2010 > New Revision: 162980 > > URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162980 > Log: > 2010-08-07 Daniel Franke > > 2010-06-13 Daniel Franke > > PR fortran/31588 > PR fortran/43954 > Backport from mainline: ... Thanks a lot! Only if you could please also apply the -4.4 version. *Please* The rationale for this is that 4.4 will be the default compiler in the next upcoming Debian stable. Thanks, Kirill -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug fortran/43954] [4.4 regression] gfortran does not support -Wp, -MD for *.F
--- Comment #17 from mikael at gcc dot gnu dot org 2010-08-07 18:18 --- (In reply to comment #14) > Thanks again. But why 4.3? It's 4.4 and 4.5 which need fixing. 4.3 is > ok. Am I misunderstanding something? Sorry, my mistake. Changed accordingly (and according to the fix committed by Jerry). -- mikael at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4 regression]|[4.4 regression] gfortran |gfortran does not support - |does not support -Wp, -MD |Wp, -MD for *.F|for *.F Target Milestone|4.3.6 |4.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug c++/45226] the difference of fstream's open() in different GCC version
--- Comment #1 from redi at gcc dot gnu dot org 2010-08-07 18:15 --- 1) GCC 3.4.6 is ancient and no longer supported. 2) Your code is not a self-contained testcase, so noone can compile it. 3) std::ofstream::open does not take a string as the second parameter, it takes a bitmask of type std::ios:openmode. You need to update your code to ISO C++. -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45226
[Bug bootstrap/45118] No rule to make target `.deps/affinity.Plo'
--- Comment #3 from danglin at gcc dot gnu dot org 2010-08-07 17:42 --- I have been unable to duplicate in several subsequent builds. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45118
[Bug c++/45221] missed optimization with multiple bases and casting
--- Comment #10 from navin dot kumar at gmail dot com 2010-08-07 17:27 --- Richard, correct references in C++ cannot bind to NULL. So gcc should derive non-NULL-ness when the argument is a reference. It seems to correctly do this in the case of foo3 and fooB, but fails to do so for foo1 and fooA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug fortran/41859] ICE on invalid expression involving DT with pointer components in I/O
--- Comment #7 from dominiq at lps dot ens dot fr 2010-08-07 17:07 --- > I was getting back to this and noticed that we no longer ICE on the original > test case. ... Still gives an ICE on x86_64-apple-darwin10.4.0 revision 162979. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41859
[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2010-08-07 16:52 --- Subject: Bug 31588 Author: jvdelisle Date: Sat Aug 7 16:51:55 2010 New Revision: 162980 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162980 Log: 2010-08-07 Daniel Franke 2010-06-13 Daniel Franke PR fortran/31588 PR fortran/43954 Backport from mainline: * gfortranspec.c (lang_specific_driver): Removed deprecation warning for -M. * lang.opt: Add options -M, -MM, -MD, -MMD, -MF, -MG, -MP, -MT, -MQ. * lang-specs.h (CPP_FORWARD_OPTIONS): Add -M* options. * cpp.h (gfc_cpp_makedep): New. (gfc_cpp_add_dep): New. (gfc_cpp_add_target): New. * cpp.c (gfc_cpp_option): Add deps* members. (gfc_cpp_makedep): New. (gfc_cpp_add_dep): New. (gfc_cpp_add_target): New. (gfc_cpp_init_options): Initialize new options. (gfc_cpp_handle_option): Handle new options. (gfc_cpp_post_options): Map new options to libcpp-options. (gfc_cpp_init): Handle deferred -MQ and -MT options. (gfc_cpp_done): If requested, write dependencies to file. * module.c (gfc_dump_module): Add a module filename as target. * scanner.c (open_included_file): New parameter system; add the included file as dependency. (gfc_open_included_file): Add the included file as dependency. (gfc_open_intrinsic_module): Likewise. * invoke.texi: Removed deprecation warning for -M. * gfortran.texi: Removed Makefile-dependencies project. Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/cpp.c branches/gcc-4_5-branch/gcc/fortran/cpp.h branches/gcc-4_5-branch/gcc/fortran/gfortran.texi branches/gcc-4_5-branch/gcc/fortran/gfortranspec.c branches/gcc-4_5-branch/gcc/fortran/invoke.texi branches/gcc-4_5-branch/gcc/fortran/lang-specs.h branches/gcc-4_5-branch/gcc/fortran/lang.opt branches/gcc-4_5-branch/gcc/fortran/module.c branches/gcc-4_5-branch/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588
[Bug fortran/43954] [4.3/4.4 regression] gfortran does not support -Wp, -MD for *.F
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2010-08-07 16:52 --- Subject: Bug 43954 Author: jvdelisle Date: Sat Aug 7 16:51:55 2010 New Revision: 162980 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162980 Log: 2010-08-07 Daniel Franke 2010-06-13 Daniel Franke PR fortran/31588 PR fortran/43954 Backport from mainline: * gfortranspec.c (lang_specific_driver): Removed deprecation warning for -M. * lang.opt: Add options -M, -MM, -MD, -MMD, -MF, -MG, -MP, -MT, -MQ. * lang-specs.h (CPP_FORWARD_OPTIONS): Add -M* options. * cpp.h (gfc_cpp_makedep): New. (gfc_cpp_add_dep): New. (gfc_cpp_add_target): New. * cpp.c (gfc_cpp_option): Add deps* members. (gfc_cpp_makedep): New. (gfc_cpp_add_dep): New. (gfc_cpp_add_target): New. (gfc_cpp_init_options): Initialize new options. (gfc_cpp_handle_option): Handle new options. (gfc_cpp_post_options): Map new options to libcpp-options. (gfc_cpp_init): Handle deferred -MQ and -MT options. (gfc_cpp_done): If requested, write dependencies to file. * module.c (gfc_dump_module): Add a module filename as target. * scanner.c (open_included_file): New parameter system; add the included file as dependency. (gfc_open_included_file): Add the included file as dependency. (gfc_open_intrinsic_module): Likewise. * invoke.texi: Removed deprecation warning for -M. * gfortran.texi: Removed Makefile-dependencies project. Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/cpp.c branches/gcc-4_5-branch/gcc/fortran/cpp.h branches/gcc-4_5-branch/gcc/fortran/gfortran.texi branches/gcc-4_5-branch/gcc/fortran/gfortranspec.c branches/gcc-4_5-branch/gcc/fortran/invoke.texi branches/gcc-4_5-branch/gcc/fortran/lang-specs.h branches/gcc-4_5-branch/gcc/fortran/lang.opt branches/gcc-4_5-branch/gcc/fortran/module.c branches/gcc-4_5-branch/gcc/fortran/scanner.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug preprocessor/45227] New: libcpp Makefile does not enable instrumentation
I noticed this while doing a coverage enabled build. The libcpp Makefile doesn't enable the coverage options unlike the code in gcc/* I think it also does not enable coverage for make profiled-bootstrap This likely gives some compiler performance away. -- Summary: libcpp Makefile does not enable instrumentation Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andi-gcc at firstfloor dot org GCC host triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45227
[Bug libstdc++/44475] bunch of warnings of "second definition" on osf
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-07 16:32 --- Ok... -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44475
[Bug c++/45221] missed optimization with multiple bases and casting
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-08-07 16:27 --- (In reply to comment #7) > Richard, if you can't derive non-NULL-ness from X& y = *x, how do foo3 and > fooB > avoid the null check? For both cases the C++ frontend do not emit the NULL check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug c++/45221] missed optimization with multiple bases and casting
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-08-07 16:25 ---
Which means that if the language guarantees that for
Base2* fooA(Derived* x)
{
Base2& y = *x;
return &y;
}
x being a null pointer invokes undefined behavior (because references can't
bind to nothing(?)) then the frontend should emit not
< !=
0B ? &NON_LVALUE_EXPR ->D.1702 : 0B);>>;
but instead
<->D.1702;>>;
CCing Jason.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug c++/45221] missed optimization with multiple bases and casting
--- Comment #7 from navin dot kumar at gmail dot com 2010-08-07 16:22 --- Richard, if you can't derive non-NULL-ness from X& y = *x, how do foo3 and fooB avoid the null check? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug c++/45221] missed optimization with multiple bases and casting
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-08-07 16:19 --- (In reply to comment #5) > Hi Richard, > > Your explanation doesn't explain why foo1 would emit poorer assembly than > foo3. > > Or for that matter why fooA would emit poorer assembly than fooB. > > In the case of foo1, foo3, fooA, and fooB, dereferencing occurs first, before > casting. Yet only foo3 and fooB generate optimal assembly (so gcc is clearly > "capable" of outputting the desired asm). This is all at -O3, where > "-fdelete-null-pointer-checks" is already enabled. X* x; X& = *x; is not considered a dereference - internally it is just a pointer assignment we can't derive non-NULL-ness from. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug fortran/43954] [4.3/4.4 regression] gfortran does not support -Wp, -MD for *.F
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2010-08-07 15:43 --- I have the patch for backport to 4.5 applied to my local 4.5 branch and I am regression testing now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug rtl-optimization/45223] RTL PRE GCSE pass hoists trapping insn out of loop
--- Comment #5 from ubizjak at gmail dot com 2010-08-07 15:27 --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00553.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||08/msg00553.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45223
[Bug c++/45221] missed optimization with multiple bases and casting
--- Comment #5 from navin dot kumar at gmail dot com 2010-08-07 15:25 --- Hi Richard, Your explanation doesn't explain why foo1 would emit poorer assembly than foo3. Or for that matter why fooA would emit poorer assembly than fooB. In the case of foo1, foo3, fooA, and fooB, dereferencing occurs first, before casting. Yet only foo3 and fooB generate optimal assembly (so gcc is clearly "capable" of outputting the desired asm). This is all at -O3, where "-fdelete-null-pointer-checks" is already enabled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug preprocessor/33919] __BASE_FILE__ does not expand correctly when included from the command line
--- Comment #4 from truedfx at gentoo dot org 2010-08-07 14:34 --- I'm having this problem too, and it's still happening with GCC 4.5. The ml message suggests that this may be hard to fix, but it looks surprisingly easy: instead of tracing back via INCLUDED_FROM, simply look at pfile->main_file which already contains the right file name. It just needs an accessor function because _cpp_file's definition is kept internal. I have a patch that does this, but I'm only posting a description, because this way it'll be very easy to recreate it, and I still don't have to deal with any copyright paperwork :) -- truedfx at gentoo dot org changed: What|Removed |Added CC||truedfx at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33919
[Bug bootstrap/45174] Make fails in zlib
--- Comment #18 from rwild at gcc dot gnu dot org 2010-08-07 14:29 --- Please do the following for me in your toplevel build directory, thanks: tar cvf config-logs.tar `find . -name config.log -o -name config.cache` gzip config-logs.tar and attach the tarball to this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174
[Bug bootstrap/41818] Error building cross compiler caused by changing LD_LIBRARY_PATH environment variable in Makefile
--- Comment #13 from rwild at gcc dot gnu dot org 2010-08-07 14:18 --- (In reply to comment #11) > I encountered that issue with gcc 4.3.4 on the following target: > mips-unknown-linux-uclibc. I'm currently confirming with gcc 4.3.5. If it > still > happen, would it be worth pulling to the 4.3 branch ? Can you please confirm that the patch from comment #8 fixes the issue for you on the 4.3 (and maybe also 4.4) branch? I'd propose the backport on gcc-patches then. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41818
[Bug c++/45225] gcc accepts ill-formed template code combining Variadic Templates and Partial specialization
--- Comment #4 from boostcpp at gmail dot com 2010-08-07 14:17 ---
It doesn't compile the following code which I think well-formed.
#include
template < typename ... Types >
class Foo ;
template <
template < typename ... > class ... Types,
typename ... Params
>
class Foo< Types< Params... > ... >
{ } ;
int main()
{
Foo< std::tuple, std::tuple > a ;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45225
[Bug fortran/44235] array temporary with high upper bound
--- Comment #8 from dominiq at lps dot ens dot fr 2010-08-07 13:40 --- > the only unnecessary temporary still created with current trunk is your first > example. Again it is because the lower bound of the section is that or the array, but if increase it I see pr44235_1_db.f90:22.14: a(4:19:3) = a(7:nu:3) 1 Warning: Creating array temporary at (1) pr44235_1_db.f90:23.14: a(4:19:3) = a(nl:23:3) 1 Warning: Creating array temporary at (1) with a clean trunk that disappear with the patch in comment #5 > I am more in favor of changing the upper bound to its actual value, > probably during resolution. I agree, it's what I tried to say in comment #4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44235
[Bug fortran/43954] [4.3/4.4 regression] gfortran does not support -Wp, -MD for *.F
--- Comment #14 from kirr at landau dot phys dot spbu dot ru 2010-08-07 13:27 --- Subject: Re: [4.3/4.4 regression] gfortran does not support -Wp, -MD for *.F On Sat, Aug 07, 2010 at 11:25:26AM -, mikael at gcc dot gnu dot org wrote: > --- Comment #13 from mikael at gcc dot gnu dot org 2010-08-07 11:25 > --- > (In reply to comment #12) > > Could someone please suggest me what I'm maybe doing wrong? > Nothing wrong. Just ping the patch from time to time ;-). I see, thanks. > I've set the target milestone to 4.3.6, so that it may get more attention. Thanks again. But why 4.3? It's 4.4 and 4.5 which need fixing. 4.3 is ok. Am I misunderstanding something? Thanks, Kirill -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug c++/45226] New: the difference of fstream's open() in different GCC version
Dear gnu experts,
I have a question on the GCC version.The followed code is ran succesfully under
one version of GCC,but fail when I use gcc3.4.6.The code is:
#include
int set_output()
{
std::ofstream txt_stream;
char txt_stream_file[400];
int status=0;
strcpy(txt_stream_file,"plots/");
strcat(txt_stream_file,"results_");
strcat(txt_stream_file,galdef.galdef_ID);
strcat(txt_stream_file,"_");
strcat(txt_stream_file,workstring1);
strcat(txt_stream_file,"_");
strcat(txt_stream_file,workstring2);
if(galplotdef.convolve_EGRET==0)
strcat(txt_stream_file,"_unconv_" );
if(galplotdef.convolve_EGRET!=0)
strcat(txt_stream_file,"_conv_");
strcat(txt_stream_file,galplotdef.psfile_tag);
strcat(txt_stream_file,".txt");
cout< >::open(char[400], const
char[2])'
/usr/lib/gcc/i386-redhat-linux/3.4.6/../../../../include/c++/3.4.6/fstream:695:
note: candidates are: void std::basic_ofstream<_CharT, _Traits>::open(const
char*, std::_Ios_Openmode) [with _CharT = char, _Traits =
std::char_traits]
I translated char txt_stream_file[400] to const char *file,but fail,could
please you tell me how to solve it.Thank you very much.
wl ang
th7,August,2010
--
Summary: the difference of fstream's open() in different GCC
version
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: china dot wenli dot wang at gmail dot com
GCC host triplet: redhat linux enterprise4.8(gnu/gcc3.4.6)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45226
[Bug c++/45225] gcc accepts ill-formed template code combining Variadic Templates and Partial specialization
--- Comment #3 from boostcpp at gmail dot com 2010-08-07 12:25 --- Come to think of it, It just use primary template. If I don't write the difinition of primary template, gcc issues error. template < typename ... Types > class Foo ; But still, I think this template keyword usage in partial specialization is ill-formed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45225
[Bug c++/45225] gcc accepts ill-formed template code combining Variadic Templates and Partial specialization
--- Comment #2 from boostcpp at gmail dot com 2010-08-07 12:18 ---
My bad. Never mind.
(In reply to comment #1)
> I also noticed gcc accept this code.
> Should I create separate bug report?
>
> template < typename ... Types >
> class Foo { };
>
> // Params is template parameter.
> template < typename ... Types, typename Params >
> class Foo< typename template Types < Params > ... >
> { } ;
>
> int main()
> {
> // gcc accepts this.
> // actually tuple must take exactly one template argument.
> Foo< std::tuple, std::tuple > a ;
> }
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45225
[Bug c++/45225] gcc accepts ill-formed template code combining Variadic Templates and Partial specialization
--- Comment #1 from boostcpp at gmail dot com 2010-08-07 12:18 ---
I also noticed gcc accept this code.
Should I create separate bug report?
template < typename ... Types >
class Foo { };
// Params is template parameter.
template < typename ... Types, typename Params >
class Foo< typename template Types < Params > ... >
{ } ;
int main()
{
// gcc accepts this.
// actually tuple must take exactly one template argument.
Foo< std::tuple, std::tuple > a ;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45225
[Bug c++/45225] New: gcc accepts ill-formed template code combining Variadic Templates and Partial specialization
gcc accepts following code.
Basically, this code specify template arguments to ordinary template parameter
pack(i.e. non template template parameter pack).
// given this primary template
template < typename ... Types >
class Foo { } ;
// gcc accepts this parcial specialization
// If I use template keyword.
template < typename ... Types, typename ... Params >
class Foo< template Types < Params... > ... >
{ } ;
// gcc also accepts this. the difference is position of template keyword.
template < typename ... Types, typename ... Params >
class Foo< Types template < Params... > ... >
{ } ;
This must be ill-formed.
The template keyword for the typename-specifier is for nested-name-specifier.
Types is not.
Types is not a template template parameter pack, yet it takes template
arguments if I use broken typename-specifier-like syntax.
When I found this, I wanted to write class template Foo which can be
instantiated like this:
Foo<
std::tuple,
std::tuple,
std::tuple
> foo ;
It accepts any number of std::tuple types(or whatever class templates) with
each std::tuple take any number of template arguments in any type.
The obvious implementation of this is using template template parameter pack in
partial specialization.
template < typename ... Types >
class Foo { };
template <
template < typename ... > class ... Types,
typename ... Params
>
class Foo< Types< Params... > ... >
{ } ;
But I happened to write above ordinary template parameter pack version.
And found this bug.
--
Summary: gcc accepts ill-formed template code combining Variadic
Templates and Partial specialization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boostcpp at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45225
[Bug fortran/45143] [F2008,corrig1] Endless loop with unlimited edit descriptor
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-08-07 12:10 --- Subject: Bug 45143 Author: jvdelisle Date: Sat Aug 7 12:10:25 2010 New Revision: 162979 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162979 Log: 2010-08-07 Jerry DeLisle PR libfortran/45143 * gfortran.dg/fmt_error_11.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_error_11.f03 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45143
[Bug fortran/45143] [F2008,corrig1] Endless loop with unlimited edit descriptor
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-08-07 12:03 --- Subject: Bug 45143 Author: jvdelisle Date: Sat Aug 7 12:03:23 2010 New Revision: 162978 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162978 Log: 2010-08-07 Jerry DeLisle PR libfortran/45143 * io/format.c: Remove fnode storage structure definitions, moving these to format.h. (parse_format_list): Add check for data descriptors, taking care of nested formats. Adjust calling parameters to pass a check flag. (parse_format): Likewise. * io/format.h: Add structures moved from format.c. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/format.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45143
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #9 from mikpe at it dot uu dot se 2010-08-07 11:59 --- (In reply to comment #8) > As of r162787 bootstrap goes a bit further then fails on compare in > stage3-bubble: > > Comparing stages 2 and 3 > warning: gcc/cc1-checksum.o differs > Bootstrap comparison failure! > gcc/tree-vect-data-refs.o differs > make[2]: *** [compare] Error 1 > make[2]: Leaving directory `/home/guerby/build' > make[1]: *** [stage3-bubble] Error 2 > make[1]: Leaving directory `/home/guerby/build' > make: *** [bootstrap] Error 2 > > Let me know if I should open a new report. That's the now fixed PR45162. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug libgcj/1456] wait(timeout) always throws exception
--- Comment #5 from china dot wenli dot wang at gmail dot com 2010-08-07 11:38 --- gfgdsgfsg -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1456
[Bug rtl-optimization/45223] RTL PRE GCSE pass hoists trapping insn out of loop
--- Comment #4 from ubizjak at gmail dot com 2010-08-07 11:26 --- (In reply to comment #3) > Patch of comment #1 loops obviously OK to me. We shouldn't want to move > trapping insns in any case that I can think of. OK, will post patch to gcc-patches after regression test. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-08-07 10:57:54 |2010-08-07 11:26:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45223
[Bug fortran/43954] [4.3/4.4 regression] gfortran does not support -Wp, -MD for *.F
--- Comment #13 from mikael at gcc dot gnu dot org 2010-08-07 11:25 --- (In reply to comment #12) > Could someone please suggest me what I'm maybe doing wrong? Nothing wrong. Just ping the patch from time to time ;-). I've set the target milestone to 4.3.6, so that it may get more attention. -- mikael at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-07 11:25:25 date|| Summary|gfortran-4.4 does not |[4.3/4.4 regression] |support -Wp, -MD for *.F |gfortran does not support - |(4.3 -> 4.4 regression, |Wp, -MD for *.F |needed for auto-| |dependencies) | Target Milestone|--- |4.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug fortran/44235] array temporary with high upper bound
--- Comment #7 from tkoenig at gcc dot gnu dot org 2010-08-07 11:17 --- (In reply to comment #6) Hi Dominique, > It turns out that the test in comment #0 was not fixed by the patch in comment > #5, but by revision 162966. However with the slight change > > a(4:23:3) = a(4:22:3) > > a temporary is still created. The patch in comment #5 avoid temporaries in > situations such as > > a(4:19:3) = a(7:22:3) > a(4:20:3) = a(7:22:3) > a(4:19:3) = a(7:23:3) > nl = 4 > nu = 20 > a(1:16:3) = a(4:nu:3) > a(1:16:3) = a(nl:20:3) > > but not for > > a(1:16:3) = a(nl:nu:3) the only unnecessary temporary still created with current trunk is your first example. I am more in favor of changing the upper bound to its actual value, probably during resolution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44235
[Bug rtl-optimization/45223] RTL PRE GCSE pass hoists trapping insn out of loop
--- Comment #3 from steven at gcc dot gnu dot org 2010-08-07 10:57 --- Patch of comment #1 loops obviously OK to me. We shouldn't want to move trapping insns in any case that I can think of. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-07 10:57:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45223
[Bug fortran/43954] gfortran-4.4 does not support -Wp, -MD for *.F (4.3 -> 4.4 regression, needed for auto-dependencies)
--- Comment #12 from kirr at landau dot phys dot spbu dot ru 2010-08-07 10:49 --- Could someone please suggest me what I'm maybe doing wrong? Because I posted backported patches twice (first time on the mailing list) and there is always silence on gcc side... And as it is now, -4.4 and -4.5 are left in regressed state compared to -4.3, and the fix is only applied to -4.6 . Thanks, Kirill P.S. and as to the workaround described in comment5 - it does not fully qualify, becase for example calling cpp directly does not define predefined __GFORTRAN__, and I'm sure there are other corner-case when cpp'ing by hand differs from preprocessing from-under gfortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43954
[Bug tree-optimization/45219] [4.6 Regression] ICE: SIGSEGV in dominated_by_p (dominance.c:973) with -O2 -fprofile-generate
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-07 10:44 --- Confirmed. (gdb) call debug_gimple_stmt ($1) .MEM_15 = PHI <.MEM_19 Program received signal SIGSEGV, Segmentation fault. 0x08384621 in gimple_phi_arg_edge (gs=0xb77611b0, i=0) at /home/richard/src/trunk/gcc/tree-flow-inline.h:479 479 return EDGE_PRED (gimple_bb (gs), i); Immediate uses are hosed before DSE. And partial inlining is the cause. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-07 10:44:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45219
[Bug tree-optimization/45219] [4.6 Regression] ICE: SIGSEGV in dominated_by_p (dominance.c:973) with -O2 -fprofile-generate
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45219
[Bug tree-optimization/45220] [4.6 Regression] libjava/libltdl/ltdl.c:1272:1: internal compiler error: Segmenta
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45220
[Bug c++/45221] missed optimization with multiple bases and casting
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-08-07 10:37 --- I don't see what the bug is here - this is a feature of the C++ standard, we can't really "optimize" anything here. 5.2.9/8 ... The null pointer value is converted to the null pointer value of the destination type. In the case of foo3 'y' is not a pointer so that special case does not apply. The only thing we can do is excercise knowledge of undefined behavior as you dereference the resulting pointer in foo1 and foo2 and thus the behavior is undefined if that would be a null pointer. The FE hands us ;; Function int foo2(Base2*) (null) ;; enabled by -tree-original return = (x != 0B ? (struct Derived *) x + -4 : 0B)->data; and we arrive with : if (x_2(D) != 0B) goto ; else goto ; : iftmp.1_3 = x_2(D) + -4; goto ; : iftmp.1_4 = 0; : # iftmp.1_1 = PHI D.1726_5 = iftmp.1_1->data; which we could for example (with -fdelete-null-pointer-checks, where no objects at address zero can exist), optimize during phiprop if we insert undefined values as loads from NULL. We could also value-number loads based on NULL to VN_TOP which would optimize the case during PRE. Much less fragile is when the code gets inlined into a context where we know that x isn't a NULL pointer. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug c/45204] gcc doesn't report aliasing problems in -isystem includes
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-08-07 10:24 --- See comment #7, this is a feature, not a bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45204
[Bug middle-end/45182] [4.6 regression] Failed to build SPEC CPU 2000/2006
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-08-07 10:22 --- *** Bug 45224 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||moonshine at kapsi dot fi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45182
[Bug middle-end/45224] internal compiler error: in trunc_int_for_mode, at explow.c:57
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-07 10:22 --- *** This bug has been marked as a duplicate of 45182 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45224
[Bug middle-end/45224] internal compiler error: in trunc_int_for_mode, at explow.c:57
--- Comment #1 from moonshine at kapsi dot fi 2010-08-07 09:53 --- Created an attachment (id=21431) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21431&action=view) delta-reduced testcase This works on 4.4.4 and fails on trunk, I will test on 4.5 branch as well but have to build it first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45224
[Bug middle-end/45224] New: internal compiler error: in trunc_int_for_mode, at explow.c:57
gcc -O3 -c ice-min.i ice-min.i:168:39: warning: 'struct vdrive_s' declared inside parameter list [enabled by default] ice-min.i:168:39: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] ice-min.i: In function 'drive_snapshot_read_module': ice-min.i:212:7: warning: assignment makes pointer from integer without a cast [enabled by default] ice-min.i: In function 'drive_snapshot_write_module': ice-min.i:203:1: internal compiler error: in trunc_int_for_mode, at explow.c:57 -- Summary: internal compiler error: in trunc_int_for_mode, at explow.c:57 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: moonshine at kapsi dot fi GCC host triplet: x86_64-unknown-linux GCC target triplet: x86_64-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45224
[Bug fortran/44235] array temporary with high upper bound
--- Comment #6 from dominiq at lps dot ens dot fr 2010-08-07 09:01 --- It turns out that the test in comment #0 was not fixed by the patch in comment #5, but by revision 162966. However with the slight change a(4:23:3) = a(4:22:3) a temporary is still created. The patch in comment #5 avoid temporaries in situations such as a(4:19:3) = a(7:22:3) a(4:20:3) = a(7:22:3) a(4:19:3) = a(7:23:3) nl = 4 nu = 20 a(1:16:3) = a(4:nu:3) a(1:16:3) = a(nl:20:3) but not for a(1:16:3) = a(nl:nu:3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44235
[Bug rtl-optimization/45223] RTL PRE GCSE pass hoists trapping insn out of loop
--- Comment #2 from ubizjak at gmail dot com 2010-08-07 08:40 ---
Ugh, with a bit changed testcase:
--cut here--
extern void exit (int);
extern void abort (void);
volatile float a = 1;
volatile float b = 0;
volatile int x = 2;
volatile signed int r = 8;
void __attribute__((noinline))
foo (void)
{
exit (0);
}
int
main (void)
{
float si1 = a;
float si2 = b;
int i;
for (i = 0; i < 100; ++i) {
foo ();
if (x == 8)
i++;
r += i + (int) (si1 / si2);
}
abort ();
}
--cut here--
-O2 on x86_64-pc-linux-gnu:
main:
pushq %rbx
xorl%ebx, %ebx
subq$16, %rsp
movss a(%rip), %xmm0
movss %xmm0, 12(%rsp)
movss b(%rip), %xmm0
movss 12(%rsp), %xmm1
> divss %xmm0, %xmm1
movss %xmm1, 12(%rsp)
.L4:
callfoo
...
I hope that Ariane-5 is safe [1] ;)
[1] http://en.wikipedia.org/wiki/Ariane_5_Flight_501
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45223
[Bug rtl-optimization/45223] RTL PRE GCSE pass hoists trapping insn out of loop
--- Comment #1 from ubizjak at gmail dot com 2010-08-07 08:33 --- Following patch fixes this problem: Index: gcse.c === --- gcse.c (revision 162975) +++ gcse.c (working copy) @@ -1693,7 +1693,7 @@ compute_hash_table_work (struct hash_tab /* The next pass builds the hash table. */ FOR_BB_INSNS (current_bb, insn) - if (INSN_P (insn)) + if (INSN_P (insn) && !may_trap_p (PATTERN (insn))) hash_scan_insn (insn, table); } main: push $sp, $r6 push $sp, $r7 push $sp, $r8 push $sp, $r9 push $sp, $r10 push $sp, $r11 dec$sp, 28 lda.l $r0, a sto.l -28($fp), $r0 lda.l $r11, b xor$r6, $r6 ldi.l $r10, foo ldi.l $r8, 8 ldi.l $r7, 99 jmpa .L4 .L3: lda.l $r1, r ldo.l $r0, -28($fp) mod.l $r0, $r11 add.l $r0, $r1 add.l $r0, $r6 sta.l r, $r0 inc$r6, 1 cmp$r6, $r7 bgt .L7 .L4: jsr$r10 lda.l $r0, x cmp$r0, $r8 bne .L3 inc$r6, 1 lda.l $r1, r ldo.l $r0, -28($fp) > mod.l $r0, $r11 add.l $r0, $r1 add.l $r0, $r6 sta.l r, $r0 inc$r6, 1 cmp$r6, $r7 ble .L4 .L7: jsra abort In a general case, I guess that if it can be proved that denominator can't be zero we can still hoist mod.l out of the loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45223
[Bug tree-optimization/38819] [4.3 Regression] trapping expression wrongly hoisted out of loop
--- Comment #23 from ubizjak at gmail dot com 2010-08-07 08:26 --- (In reply to comment #21) > > The problem is that this is hard to fix without pessimizing the common case. > > The rtl gcse pre issue should be tracked by a different bugzilla report. Follow up at PR45223. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38819
[Bug rtl-optimization/45223] New: RTL PRE GCSE pass hoists trapping insn out of loop
This is a follow-up from PR38819 which partially fixes this problem. The problem remains in RTL optimization passes, and can be triggered on targets that implement modulo instruction in the hardware (i.e. moxie-elf). The testcase from PR38819 compiles with -O2 to: main: push $sp, $r6 push $sp, $r7 push $sp, $r8 push $sp, $r9 push $sp, $r10 push $sp, $r11 dec$sp, 24 lda.l $r7, a lda.l $r0, b xor$r6, $r6 ldi.l $r11, foo > mod.l $r7, $r0 ldi.l $r10, 8 ldi.l $r8, 99 jmpa .L4 .L3: ... Since b is initialized to zero, mod.l instruction traps. -- Summary: RTL PRE GCSE pass hoists trapping insn out of loop Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ubizjak at gmail dot com GCC target triplet: moxie-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45223
[Bug bootstrap/45222] internal compiler error: in ix86_expand_epilogue
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-08-07 07:09 --- *** This bug has been marked as a duplicate of 45206 *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45222
[Bug bootstrap/45206] [4.6 regression] ICE in ix86_expand_epilogue compiling libgcc
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-08-07 07:09 --- *** Bug 45222 has been marked as a duplicate of this bug. *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206
