[Bug target/55194] h8300 ICE during conftest in libgcc dwarf2out:7605
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55194 --- Comment #2 from Joel Sherrill joel at gcc dot gnu.org 2012-11-04 06:20:02 UTC --- git bisect should help: [0e797c2e325bfe0676fc9b9e5baee01aefb164f5] /cp 2012-08-20 Paolo Carlini paolo.carl...@oracle.com [joel@baltimore gcc]$ git bisect good Bisecting: 1 revision left to test after this (roughly 1 step) [29b2949ccfc068c78899358ca40218f3518b00dd] PR rtl-optimization/54294 * fwprop.c (all_uses_available_at): Ignore debug insns in between def_insn and target_insn when checking whether the shortcut is possible. [joel@baltimore gcc]$ git bisect good Bisecting: 0 revisions left to test after this (roughly 0 steps) [2bf99680c2012de150798c933642aa4c82a85410] 2012-08-20 Tobias Burnus bur...@net-b.de
[Bug target/55194] h8300 ICE during conftest in libgcc dwarf2out:7605
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55194 --- Comment #3 from Joel Sherrill joel at gcc dot gnu.org 2012-11-04 06:22:22 UTC --- I added Jakub because I think this was the patch which broke it: Author: jakub jakub@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Mon Aug 20 18:56:49 2012 + PR rtl-optimization/54294 * fwprop.c (all_uses_available_at): Ignore debug insns in between def_insn and target_insn when checking whether the shortcut is possible.
[Bug bootstrap/52466] gcc-4.7.0-RC-20120302 fails to build for --target=lm32-rtems4.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52466 --- Comment #3 from Joel Sherrill joel at gcc dot gnu.org 2012-11-04 06:33:10 UTC --- Following up on my earlier message. Jon Beniston (original author) or Sebastien Bourdeauducq (current maintainer) ... please reply. This particular issue should be simple to the port maintainer. Also someone familiar with the exception model specification magic should be able to get this one addressed. Please.
[Bug go/55201] New: [4.8 regression] libgo.so: undefined reference to `__atomic_compare_exchange_8'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55201 Bug #: 55201 Summary: [4.8 regression] libgo.so: undefined reference to `__atomic_compare_exchange_8' Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: sch...@linux-m68k.org libgo needs to be linked against -latomic.
[Bug middle-end/55145] Different bits for long double constant depending ptr_mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55145 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Component|target |middle-end Summary|[4.8 Regression] [x32] |Different bits for long |-maddress-mode=long |double constant depending |miscompiles glibc |ptr_mode --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-11-04 08:11:01 UTC --- GCC i386 and GCC x86-64 generate different bits long double constant depending ptr_mode: [hjl@gnu-tools-1 tmp]$ cat y.c const long double pio2_hi = 1.5707963267948966192021943710788178805159986950457096099853515625L; [hjl@gnu-tools-1 tmp]$ /usr/gcc-4.7.3-32bit/bin/gcc -S y.c -o 32.s [hjl@gnu-tools-1 tmp]$ gcc -S y.c -o 64.s [hjl@gnu-tools-1 tmp]$ diff -up 64.s 32.s --- 64.s2012-11-04 01:06:52.492398183 -0700 +++ 32.s2012-11-04 01:06:47.685344002 -0700 @@ -3,11 +3,10 @@ .section.rodata .align 16 .typepio2_hi, @object -.sizepio2_hi, 16 +.sizepio2_hi, 12 pio2_hi: -.long560513588 -.long3373259426 +.long560513589 +.long-921707870 .long16383 -.long0 -.identGCC: (GNU) 4.7.2 20120921 (Red Hat 4.7.2-2) +.identGCC: (GNU) 4.7.3 20121024 (prerelease) .section.note.GNU-stack,,@progbits [hjl@gnu-tools-1 tmp]$ gcc -c 32.s 64.s [hjl@gnu-tools-1 tmp]$ objdump -s -j .rodata 32.o 32 [hjl@gnu-tools-1 tmp]$ objdump -s -j .rodata 64.o 64 [hjl@gnu-tools-1 tmp]$ diff -up 32 64 --- 322012-11-04 01:07:37.341913094 -0700 +++ 642012-11-04 01:07:42.192979572 -0700 @@ -1,5 +1,5 @@ -32.o: file format elf64-x86-64 +64.o: file format elf64-x86-64 Contents of section .rodata: - 35c26821 a2da0fc9 ff3f 5.h!.?.. + 34c26821 a2da0fc9 ff3f 4.h!.?.. [hjl@gnu-tools-1 tmp]$ Ignore padding, i386 GCC generates 35c26821 and x86-64 generates 34c26821.
[Bug driver/55202] New: Building a combined tree is broken for LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55202 Bug #: 55202 Summary: Building a combined tree is broken for LTO Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: pins...@gcc.gnu.org When you build with a combined tree and use -flto, the driver thinks the ld which is being used is ld-new which is not correct. The correct ld to be used here is really ld.
[Bug driver/55202] Building a combined tree is broken for LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55202 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-04 08:29:02 UTC --- Created attachment 28608 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28608 Patch which fixes the problem
[Bug driver/55202] Building a combined tree is broken for LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55202 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-04 AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-04 08:30:17 UTC --- Just recording this bug so I don't forget to submit this patch. I have ran into this twice now. Once when I was working on MIPS64 and now with AARCH64.
[Bug driver/55202] Building a combined tree is broken for LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55202 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-04 08:36:08 UTC --- [cannot find ld] -plugin /home/pinskia/src/toolchain-cavium/thunder-tools/bin/../libexec/gcc/aarch64-thunder-elf/4.8.0/liblto_plugin.so -plugin-opt=/home/pinskia/src/toolchain-cavium/thunder-tools/bin/../libexec/gcc/aarch64-thunder-elf/4.8.0/lto-wrapper -plugin-opt=-fresolution=/tmp/cc8Il24U.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -X /home/pinskia/src/toolchain-cavium/thunder-tools/bin/../lib/gcc/aarch64-thunder-elf/4.8.0/crti.o /home/pinskia/src/toolchain-cavium/thunder-tools/bin/../lib/gcc/aarch64-thunder-elf/4.8.0/crtbegin.o /home/pinskia/src/toolchain-cavium/thunder-tools/bin/../lib/gcc/aarch64-thunder-elf/4.8.0/../../../../aarch64-thunder-elf/lib/crt0.o -L/home/pinskia/src/toolchain-cavium/thunder-tools/bin/../lib/gcc/aarch64-thunder-elf/4.8.0 -L/home/pinskia/src/toolchain-cavium/thunder-tools/bin/../lib/gcc -L/home/pinskia/src/toolchain-cavium/thunder-tools/bin/../lib/gcc/aarch64-thunder-elf/4.8.0/../../../../aarch64-thunder-elf/lib /tmp/ccBZOKuH.o -v -lgcc -lc -lgcc /home/pinskia/src/toolchain-cavium/thunder-tools/bin/../lib/gcc/aarch64-thunder-elf/4.8.0/crtend.o /home/pinskia/src/toolchain-cavium/thunder-tools/bin/../lib/gcc/aarch64-thunder-elf/4.8.0/crtn.o I have no patches installed either. The patch above does not work.
[Bug driver/55202] Building a combined tree is broken for LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55202 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-04 08:37:29 UTC --- (In reply to comment #3) I have no patches installed either. The patch above does not work. That is because I was porting the patch from 4.7 to 4.8 and the variable changed named so I had a typo in it.
[Bug middle-end/55145] Different bits for long double constant depending on long int size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55145 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-11-04 10:14:07 UTC --- It is due to long int usage in real.h. Depending on size of long int, real.c gives slightly different results.
[Bug tree-optimization/55191] [4.8 Regression] ICE in compute_antic at tree-ssa-pre.c:2511
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55191 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-11-04 10:36:32 UTC --- Dup of 55176.
[Bug c++/55203] New: No unused warning for variables of non-trivial types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203
Bug #: 55203
Summary: No unused warning for variables of non-trivial types
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: l.lu...@suse.cz
GCC warns about unused variables e.g. of type 'int', but not 'std::string' :
$ cat a.cpp
#include string
void foo()
{
int i;
std::string s;
}
$ g++ -Wall -Wunused -c a.cpp
a.cpp: In function ‘void foo()’:
a.cpp:5:9: warning: unused variable ‘i’ [-Wunused-variable]
int i;
^
In the function 's' is apparently unused too, but the compiler cannot tell it.
[Bug c++/55203] No unused warning for variables of non-trivial types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 Lubos Lunak l.lunak at suse dot cz changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Lubos Lunak l.lunak at suse dot cz 2012-11-04 11:04:01 UTC --- As the compiler cannot tell for sure in some cases, such as the ctor calling an external function, the only reasonable way of handling this I see is explicit tagging of types for which there should be an unused warning if only ctor/dtor are called for a variable. Here's my attempt at attribute warn_unused.
[Bug middle-end/55145] Different bits for long double constant depending on long int size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55145 --- Comment #5 from Andreas Schwab sch...@linux-m68k.org 2012-11-04 11:04:03 UTC --- This cannot explain the crashes you see since the difference is just one ULP.
[Bug c++/55203] No unused warning for variables of non-trivial types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #2 from Lubos Lunak l.lunak at suse dot cz 2012-11-04 11:04:52 UTC --- Created attachment 28609 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28609 gcc patch
[Bug middle-end/55145] Different bits for long double constant depending on long int size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55145 --- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-11-04 11:09:12 UTC --- (In reply to comment #5) This cannot explain the crashes you see since the difference is just one ULP. The glibc crash is fixed by http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00248.html
[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||rejects-valid Last reconfirmed||2012-11-04 CC||janus at gcc dot gnu.org Ever Confirmed|0 |1 Summary|Equivalenced variable has |[OOP] Equivalenced variable |wrong type when used with |has wrong type when used |generic member function |with generic member ||function --- Comment #1 from janus at gcc dot gnu.org 2012-11-04 11:11:42 UTC --- (In reply to comment #0) The attached program fails to compile, with the following error: assoc_err.f90:49.8: a = a + b 1 Error: Operands of binary numeric operator '+' at (1) are REAL(4)/TYPE(foo_t) I can confirm this error with 4.6, 4.7 and trunk. Prior to 4.6 ASSOCIATE was not supported.
[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199 --- Comment #2 from janus at gcc dot gnu.org 2012-11-04 11:23:28 UTC --- Further compactified version of the test case: module assoc_err_m implicit none type :: foo_t contains procedure :: func_1 generic :: func = func_1 end type contains real function func_1 (this) class(foo_t), intent(in) :: this end function end module program assoc_err use assoc_err_m implicit none type(foo_t) :: f associate(b = f%func()) print *, 1. + b end associate end program
[Bug rtl-optimization/55204] New: [4.8 Regression] ICE: in extract_insn, at recog.c:2140 (unrecognizable insn) with -O --param loop-invariant-max-bbs-in-loop=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55204 Bug #: 55204 Summary: [4.8 Regression] ICE: in extract_insn, at recog.c:2140 (unrecognizable insn) with -O --param loop-invariant-max-bbs-in-loop=0 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 28610 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28610 reduced testcase Compiler output: $ gcc -O --param loop-invariant-max-bbs-in-loop=0 testcase.ctestcase.c: In function 'f1': testcase.c:18:1: error: unrecognizable insn: } ^ (insn 53 50 24 5 (set (reg:SI 5 di [77]) (plus:SI (subreg:SI (reg:HI 7 sp) 0) (const_int -248 [0xff08]))) testcase.c:13 -1 (nil)) testcase.c:18:1: internal compiler error: in extract_insn, at recog.c:2140 0x9969ea _fatal_insn(char const*, rtx_def const*, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/rtl-error.c:110 0x996a7a _fatal_insn_not_found(rtx_def const*, char const*, int, char const*) /mnt/svn/gcc-trunk/gcc/rtl-error.c:118 0x9524d8 extract_insn(rtx_def*) /mnt/svn/gcc-trunk/gcc/recog.c:2140 0x9526eb extract_insn_cached(rtx_def*) /mnt/svn/gcc-trunk/gcc/recog.c:2043 0x79f91d cleanup_subreg_operands(rtx_def*) /mnt/svn/gcc-trunk/gcc/final.c:2968 0x94dc60 split_insn /mnt/svn/gcc-trunk/gcc/recog.c:2857 0x956401 split_all_insns() /mnt/svn/gcc-trunk/gcc/recog.c:2911 0x956558 rest_of_handle_split_after_reload /mnt/svn/gcc-trunk/gcc/recog.c:3795 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r193125 - crash r192654 - OK r191586 - OK 4.7 r191640 - OK
[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #3 from janus at gcc dot gnu.org 2012-11-04 12:43:31 UTC --- Draft patch: Index: gcc/fortran/parse.c === --- gcc/fortran/parse.c(revision 193047) +++ gcc/fortran/parse.c(working copy) @@ -3394,13 +3394,6 @@ parse_associate (void) sym-assoc = a; sym-declared_at = a-where; gfc_set_sym_referenced (sym); - - /* Initialize the typespec. It is not available in all cases, - however, as it may only be set on the target during resolution. - Still, sometimes it helps to have it right now -- especially - for parsing component references on the associate-name - in case of association to a derived-type. */ - sym-ts = a-target-ts; } accept_statement (ST_ASSOCIATE); regtesting now ...
[Bug go/55201] [4.8 regression] libgo.so: undefined reference to `__atomic_compare_exchange_8'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55201 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2012-11-04 12:46:19 UTC --- Created attachment 28611 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28611 Preliminary patch Doesn't yet work with -static-libgo
[Bug middle-end/54838] [4.8 Regression] ICE: in merge_latch_edges, at cfgloop.c:678 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-04
12:49:27 UTC ---
I think the problem is that we somehow arrive at this:
loop_1 (header = 2, multiple latches, niter = )
{
bb_2 (preds = {bb_0 }, succs = {bb_4 bb_3 })
{
(note 5 0 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 5 3 2 (set (reg/v/f:DI 60 [ b ])
(reg:DI 5 di [ b ])) ./pr54838.c:5 63 {*movdi_internal_rex64}
(nil))
(insn 3 2 4 2 (set (reg/v/f:DI 61 [ c ])
(reg:DI 4 si [ c ])) ./pr54838.c:5 63 {*movdi_internal_rex64}
(nil))
(note 4 3 7 2 NOTE_INSN_FUNCTION_BEG)
(insn 7 4 14 2 (set (reg:SI 59 [ D.1735 ])
(mem:SI (reg/v/f:DI 61 [ c ]) [2 *c_3(D)+0 S4 A32])) 65
{*movsi_internal}
(nil))
(insn 14 7 15 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 59 [ D.1735 ])
(const_int 1 [0x1]))) ./pr54838.c:7 7 {*cmpsi_1}
(nil))
(jump_insn 15 14 38 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref:DI 20)
(pc))) ./pr54838.c:7 595 {*jcc_1}
(expr_list:REG_BR_PROB (const_int [0xd05])
(nil))
- 20)
}
}
, i.e. we have a loop which contains only the header. The rest of BBs are
there, but in loop_0. When we call disambiguate_loops_with_multiple_latches,
loop-latch is NULL on that loop, so we end up calling merge_latch_edges, but
that ICEs because VEC_length (edge, latches) is of course 0.
[Bug fortran/55205] New: build gcc-4.7.2 failed on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55205 Bug #: 55205 Summary: build gcc-4.7.2 failed on darwin Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: shankerwangm...@163.com Created attachment 28612 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28612 /src/gcc-4.7.2/x86_64-apple-darwin12.2.0/libgfortran/config.log make failed checking dynamic linker characteristics... darwin12.2.0 dyld checking how to hardcode library paths into programs... immediate checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /src/gcc-4.7.2/x86_64-apple-darwin12.2.0/libgfortran/config.log make[1]: *** [configure-target-libgfortran] Error 1 make: *** [all] Error 2
[Bug rtl-optimization/55204] [4.8 Regression] ICE: in extract_insn, at recog.c:2140 (unrecognizable insn) with -O --param loop-invariant-max-bbs-in-loop=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55204 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-04 CC||mpolacek at gcc dot ||gnu.org, rsandifo at gcc ||dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-04 13:18:17 UTC --- Started with http://gcc.gnu.org/viewcvs?view=revisionrevision=192988
[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199 --- Comment #4 from janus at gcc dot gnu.org 2012-11-04 13:40:16 UTC --- (In reply to comment #3) regtesting now ... Somewhat expected, this fails on: FAIL: gfortran.dg/associate_1.f03 -O0 (test for excess errors) FAIL: gfortran.dg/associate_10.f90 -O (test for excess errors) gfortran-4.8 -cpp associate_1.f03 associate_1.f03:79.10: IF (x%comp /= 1) CALL abort () 1 Error: Symbol 'x' at (1) has no IMPLICIT type associate_1.f03:82.10: IF (x%comp /= 5) CALL abort () 1 Error: Symbol 'x' at (1) has no IMPLICIT type gfortran-4.8 associate_10.f90 associate_10.f90:19.12: x1(1)%i = 1 1 Error: Symbol 'x1' at (1) has no IMPLICIT type associate_10.f90:21.12: y1(1)%i = 2 1 Error: Symbol 'y1' at (1) has no IMPLICIT type
[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199 --- Comment #5 from janus at gcc dot gnu.org 2012-11-04 13:56:03 UTC --- Here is an improved patch, which hopefully should be free of testsuite regressions (will re-check): Index: gcc/fortran/parse.c === --- gcc/fortran/parse.c(revision 193133) +++ gcc/fortran/parse.c(working copy) @@ -3395,12 +3395,10 @@ parse_associate (void) sym-declared_at = a-where; gfc_set_sym_referenced (sym); - /* Initialize the typespec. It is not available in all cases, - however, as it may only be set on the target during resolution. - Still, sometimes it helps to have it right now -- especially - for parsing component references on the associate-name - in case of association to a derived-type. */ - sym-ts = a-target-ts; + /* For variables, we can already set the typespec. Other cases have to + wait until resolution stage. */ + if (a-target-expr_type == EXPR_VARIABLE) +sym-ts = a-target-ts; } accept_statement (ST_ASSOCIATE);
[Bug c++/55206] New: GCC Reports Ambiguity; clang and comeau disagree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55206 Bug #: 55206 Summary: GCC Reports Ambiguity; clang and comeau disagree Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@boostpro.com I apologize for not doing the hunt to figure out what the standard says on this one, but since GCC is the outlier I'm reporting it here. The error is: g++ -I ~/src/boost/svn/release -Wall -Wextra -pedantic -Wno-long-long -Wno-unused-parameter -Wno-unused -Wno-parentheses -D_GLIBCXX_DEBUG -g -O0 shared.cpp -o shared In file included from /Users/dave/src/boost/svn/release/boost/make_shared.hpp:15:0, from shared.cpp:24: /Users/dave/src/boost/svn/release/boost/smart_ptr/make_shared.hpp: In instantiation of 'boost::shared_ptrT boost::make_shared(const A1) [with T = json_storejson_string; A1 = boost::rvjson_string]': shared.cpp:261:65: required from 'static json_value::stored_type json_value::make_storage(T, boost::false_type, boost::false_type) [with T = json_string; json_value::stored_type = boost::shared_ptrjson_base; boost::false_type = boost::integral_constantbool, false]' shared.cpp:176:9: required from 'json_value::json_value(T) [with T = json_string]' shared.cpp:300:41: required from here /Users/dave/src/boost/svn/release/boost/smart_ptr/make_shared.hpp:660:5: error: call of overloaded 'json_string(const boost::rvjson_string)' is ambiguous /Users/dave/src/boost/svn/release/boost/smart_ptr/make_shared.hpp:660:5: note: candidates are: shared.cpp:65:5: note: json_string::json_string(const json_string) shared.cpp:61:5: note: json_string::json_string(json_string::rep_t) shared.cpp:145:5: error: initializing argument 1 of 'json_storeT::json_store(T) [with T = json_string]' make: *** [shared] Error 1 Compilation exited abnormally with code 2 at Sun Nov 4 08:45:44
[Bug c++/55189] enable -Wreturn-type by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55189 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-04 14:08:44 UTC --- Let's do this then.
[Bug target/55184] [4.6 Regression] Invalid codegen with vectors and casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55184 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2012-11-04 14:13:58 UTC --- I can't reproduce the error with vanilla gcc-4.6.3 on x86_64-linux.
[Bug fortran/55205] build gcc-4.7.2 failed on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55205 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2012-11-04 15:20:27 UTC --- Probably the same problem as in PR 51343?!?
[Bug c++/55189] enable -Wreturn-type by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55189 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|paolo.carlini at oracle dot |unassigned at gcc dot |com |gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-04 15:26:09 UTC --- Sorry, not me, not now: hundreds of testcases need fixing.
[Bug c++/55206] GCC Reports Ambiguity; clang and comeau disagree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55206 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-11-04 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-04 15:30:50 UTC --- Attachment missing. Please do your best to reduce it as much as possible (maybe with delta, c-reduce, ...)
[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199 --- Comment #6 from janus at gcc dot gnu.org 2012-11-04 15:46:38 UTC --- (In reply to comment #5) Here is an improved patch, which hopefully should be free of testsuite regressions (will re-check): It is. However, I think there is a better way to fix this: Index: gcc/fortran/primary.c === --- gcc/fortran/primary.c(revision 193133) +++ gcc/fortran/primary.c(working copy) @@ -1975,6 +1975,8 @@ gfc_match_varspec (gfc_expr *primary, int equiv_fl gcc_assert (primary-symtree-n.sym-attr.referenced); if (tbp_sym) primary-ts = tbp_sym-ts; + else +gfc_clear_ts (primary-ts); m = gfc_match_actual_arglist (tbp-n.tb-subroutine, primary-value.compcall.actual); This prevents the EXPR_COMPCALL from having the wrong typespec is the first place (and resets it to BT_UNKNOWN instead). I will commit this as obvious after regtesting.
[Bug target/41993] [sh] ICE in create_pre_exit, at mode-switching.c:399
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41993
--- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2012-11-04 16:45:51
UTC ---
I have looked a bit into this problem, since AVX vzeroupper insertion now
depends on MODE_EXIT functionality. IMO, the patch in Comment #1 is correct for
all optimization levels. The reason, the problem is triggered only at -O0 is
that since __builtin_return loads from the memory, gcc emits offsets to memory
locations using the pseudo:
...
(insn 9 8 11 2 (set (reg:SI 0 r0)
(mem:SI (reg/f:SI 163) [0 S4 A8])) pr41933.c:3 238 {movsi_ie}
(nil))
(insn 11 9 12 2 (set (reg:SI 165)
(mem/f/c:SI (plus:SI (reg/f:SI 162)
(const_int 60 [0x3c])) [0 rframe+0 S4 A32])) pr41933.c:3 238
{movsi_ie}
(nil))
(insn 12 11 13 2 (set (reg/f:SI 164)
(plus:SI (reg:SI 165)
(const_int 4 [0x4]))) pr41933.c:3 62 {*addsi3_compact}
(nil))
(insn 13 12 10 2 (set (reg:SI 64 fr0)
(mem:SI (reg/f:SI 164) [0 S4 A8])) pr41933.c:3 238 {movsi_ie}
(nil))
(insn 10 13 14 2 (use (reg:SI 0 r0)) pr41933.c:3 -1
(nil))
(insn 14 10 22 2 (use (reg:SI 64 fr0)) pr41933.c:3 -1
(nil))
(insn 22 14 0 2 (use (reg/i:SI 0 r0)) pr41933.c:4 -1
(nil))
This additional pseudo is what breaks the compilation. At -O2, we enter
mode-switching with:
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (reg/v/f:SI 161 [ rframe ])
(reg:SI 4 r4 [ rframe ])) pr41933.c:2 238 {movsi_ie}
(expr_list:REG_DEAD (reg:SI 4 r4 [ rframe ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 8 2 (set (reg:SI 0 r0)
(mem:SI (reg/v/f:SI 161 [ rframe ]) [0 S4 A8])) pr41933.c:3 238
{movsi_ie}
(nil))
(insn 8 6 7 2 (set (reg:SI 64 fr0)
(mem:SI (plus:SI (reg/v/f:SI 161 [ rframe ])
(const_int 4 [0x4])) [0 S4 A8])) pr41933.c:3 238 {movsi_ie}
(expr_list:REG_DEAD (reg/v/f:SI 161 [ rframe ])
(nil)))
(insn 7 8 9 2 (use (reg:SI 0 r0)) pr41933.c:3 -1
(nil))
(insn 9 7 17 2 (use (reg:SI 64 fr0)) pr41933.c:3 -1
(expr_list:REG_DEAD (reg:SI 64 fr0)
(nil)))
(insn 17 9 0 2 (use (reg/i:SI 0 r0)) pr41933.c:4 -1
(nil))
In this case, we found many return registers (due to __builtin_return), and
consequently lowered nregs to zero. This satisfies the following assert in
(!nregs) and (nregs != hard_regno_nregs[ret_start][GET_MODE (ret_reg)]) cases.
In -O0 case, we broke discovery loop too early, so we can't find all return
regs. I would argue, that we should ignore non-relevant pseudos with:
--cut here--
Index: mode-switching.c
===
--- mode-switching.c(revision 193133)
+++ mode-switching.c(working copy)
@@ -324,7 +324,10 @@ create_pre_exit (int n_entities, int *entity_map,
else
break;
if (copy_start = FIRST_PSEUDO_REGISTER)
- break;
+ {
+ last_insn = return_copy;
+ continue;
+ }
copy_num
= hard_regno_nregs[copy_start][GET_MODE (copy_reg)];
--cut here--
In the same way as in case of i.e. UNSPEC_VOLATILE in the preceeding code.
[Bug c++/55206] GCC Reports Ambiguity; clang and comeau disagree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55206 --- Comment #2 from Dave Abrahams dave at boostpro dot com 2012-11-04 16:47:37 UTC --- I hate bugzilla for always tempting me to think I can add attachments when first submitting a bug, and then refusing the attachment because it's too big. Voilà https://raw.github.com/gist/4012559/b670d1e44ccd1fa1da65f1efd7e09b6b0a471b4a/bug.cpp
[Bug c++/55206] GCC Reports Ambiguity; clang and comeau disagree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55206 --- Comment #3 from Dave Abrahams dave at boostpro dot com 2012-11-04 16:48:39 UTC --- PS my apologies again for the size. Just no time to reduce it now.
[Bug middle-end/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #3 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-04 16:59:07 UTC --- I have done a -j2 bootstrap on gcc61, and in fails somewhere else in a similar fashion. I then transplanted some files to my local (faster) cross environment. I've hacked final.c to provide the equivalent of the sh/arc -misize option, and I see some sizeable chunks of code being estimated with a small size: .L19464: ; at 11cc addil LT'.L19517,%r19 ldw RT'.L19517(%r1),%r1 ldw 0(%r1),%r1 bb,=,n %r1,30,.+16 depi 0,31,2,%r1 ldw 4(%sr0,%r1),%r19 ldw 0(%sr0,%r1),%r1 bl .+8,%r2 addi 8,%r2,%r2 ble 0(%sr4,%r1) stw %r31,-24(%sp) .LVL19507: .L19463: ; at 11d4 addil LT'.L19517,%r19 ldw RT'.L19517(%r1),%r1 ldw 0(%r1),%r1 bb,=,n %r1,30,.+16 depi 0,31,2,%r1 ldw 4(%sr0,%r1),%r19 ldw 0(%sr0,%r1),%r1 bl .+8,%r2 addi 8,%r2,%r2 ble 0(%sr4,%r1) stw %r31,-24(%sp) .LVL19508: .L19462: ; at 11dc
[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199 --- Comment #7 from janus at gcc dot gnu.org 2012-11-04 17:13:22 UTC --- Author: janus Date: Sun Nov 4 17:13:16 2012 New Revision: 193136 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193136 Log: 2012-11-04 Janus Weil ja...@gcc.gnu.org PR fortran/55199 * primary.c (gfc_match_varspec): Clear typespec if it cannot be determined at this point. 2012-11-04 Janus Weil ja...@gcc.gnu.org PR fortran/55199 * gfortran.dg/associate_12.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/associate_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from janus at gcc dot gnu.org 2012-11-04 17:15:25 UTC --- Fixed with r193136. Closing. Thanks for reporting this!
[Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195
Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed:
What|Removed |Added
CC||law at redhat dot com
Component|middle-end |target
--- Comment #4 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org
2012-11-04 17:31:52 UTC ---
(In reply to comment #3)
In the ccA1Vjgkjx.234r.shorten dump file,
between L19464 and L19463, there is but one call instruction, a basic block
start, a barrier, and some 600 NOTE_INSN_VAR_LOCATION:
(code_label 4141 28778 2472 19464 [1 uses])
(note 2472 4141 3318 [bb 311] NOTE_INSN_BASIC_BLOCK)
(call_insn:TI 3318 2472 3319 (parallel [
(call (mem:SI (symbol_ref/v:SI (@_Jv_ThrowBadArrayIndex) [flags
0x241] function_decl 0xb73b8700 _Jv_ThrowBadArrayIndex) [0 S4 A32])
(const_int 16 [0x10]))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (reg:SI 19 %r19))
(use (const_int 0 [0]))
])
/ssd/synopsys/arc_gnu_4.8-r192641/gcc-4.8/libjava/classpath/gnu/java/nio/charset/MacSymbol.java:73
198 {*call_symref_pic_post_reload}
(expr_list:REG_DEAD (reg:SI 26 %r26)
(expr_list:REG_DEAD (reg:SI 19 %r19)
(expr_list:REG_NORETURN (const_int 0 [0])
(nil
(expr_list:REG_CC_SETTER (use (reg:SI 26 %r26))
(nil)))
(barrier 3319 3318 28981)
(note 28981 3319 28980 (nil) NOTE_INSN_CALL_ARG_LOCATION)
...
(note 29183 29182 4140 (var_location D.16611 (nil)) NOTE_INSN_VAR_LOCATION)
(code_label 4140 29183 2459 19463 [1 uses])
The instruction call_symref_pic_post_reload has the following length
attribute setting:
(set (attr length) (symbol_ref pa_attr_length_call (insn, 0)))
Such a length attribute is not considered variable by shorten_branches.
You need to include a clause that is directly in the attribute, e.g.
(and (match_test 0) (eq (match_dup 0) (pc)))
[Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #5 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-04 17:34:47 UTC --- Created attachment 28613 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28613 here is a proof-of-concept patch that allows the offending file to assemble successfully.
[Bug target/55184] [4.6 Regression] Invalid codegen with vectors and casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55184 Mathias Gaunard mathias at gaunard dot com changed: What|Removed |Added Attachment #28600|0 |1 is obsolete|| --- Comment #3 from Mathias Gaunard mathias at gaunard dot com 2012-11-04 17:58:30 UTC --- Created attachment 28614 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28614 Fixed testcase
[Bug target/55184] [4.6 Regression] Invalid codegen with vectors and casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55184 --- Comment #4 from Mathias Gaunard mathias at gaunard dot com 2012-11-04 18:01:27 UTC --- Sorry, I edited the file in between and ended up uploading the wrong test case. Below is the result on my machine with the fixed testcase. $ gcc --version gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Copyright (C) 2011 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. $ gcc -dumpmachine x86_64-linux-gnu $ gcc test.c -o test ./test 1 (should be 1) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 1 (should be 1) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) $ gcc -O1 test.c -o test ./test 1 (should be 1) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 1) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0) 0 (should be 0)
[Bug fortran/55199] [OOP] Equivalenced variable has wrong type when used with generic member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55199 --- Comment #9 from Rich Townsend townsend at astro dot wisc.edu 2012-11-04 18:01:53 UTC --- (In reply to comment #8) Fixed with r193136. Closing. Thanks for reporting this! Hey, thanks for fixing it so quickly -- you never cease to amaze me!
[Bug fortran/55207] New: Automatic deallocation of variables declared in the main program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
Bug #: 55207
Summary: Automatic deallocation of variables declared in the
main program
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
Although F95/F03/F08 only require automatic deallocation of local unsaved
variables upon termination of a procedure, gfortran currently also does it upon
termination of the main program.
Simple test case (for both scalars and arrays):
program main
integer, allocatable :: i
integer, allocatable, dimension(:) :: j
allocate(i)
allocate(j(1:5))
end program
The dump shows a block which automatically deallocates the variables at the end
of the main program:
finally
{
if (j.data != 0B)
{
__builtin_free ((void *) j.data);
}
j.data = 0B;
if (i != 0B)
{
__builtin_free ((void *) i);
}
}
From F08:6.7.3.2:
When the execution of a procedure is terminated by execution of a RETURN or
END statement, an unsaved allocatable local variable of the procedure retains
its allocation and definition status if it is a function result variable or a
subobject thereof; otherwise, it is deallocated.
This mentions only *procedures*, not the main program. Moreover, variables
declared in the main program are implicitly SAVEd in F08, cf. chapter 5.3.16:
A variable, common block, or procedure pointer declared in the scoping unit of
a main program, module, or submodule implicitly has the SAVE attribute, which
may be confirmed by explicit specification. If a common block has the SAVE
attribute in any other kind of scoping unit, it shall have the SAVE attribute
in every scoping unit that is not of a main program, module, or submodule.
Currently we miss to flag this via attr.save = SAVE_IMPLICIT.
In F95 it is basically impossible to detect whether a compiler does
end-of-program auto-dealloc. However, in F03 it can be detected by using a
FINAL procedure, since deallocation (automatic or explicit) also implies
finalization (for finalizable variables).
[Bug fortran/55207] Automatic deallocation of variables declared in the main program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207
--- Comment #1 from janus at gcc dot gnu.org 2012-11-04 18:32:29 UTC ---
Patch:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 193135)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -3771,9 +3771,10 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gf
else
gfc_restore_backend_locus (loc);
- /* Deallocate when leaving the scope. Nullifying is not
- needed. */
- if (!sym-attr.result !sym-attr.dummy)
+ /* Automatic deallocation when leaving the scope.
+ Nullifying is not needed. */
+ if (!proc_sym-attr.is_main_program
+ !sym-attr.result !sym-attr.dummy)
{
if (sym-ts.type == BT_CLASS
CLASS_DATA (sym)-attr.codimension)
This regresses on:
FAIL: gfortran.dg/allocatable_scalar_9.f90 -O0 scan-tree-dump-times original
__builtin_free 32
FAIL: gfortran.dg/coarray_lib_alloc_2.f90 -O scan-tree-dump-times original
_gfortran_caf_deregister .yy._data.token, 0B, 0B, 0.; 1
FAIL: gfortran.dg/move_alloc_4.f90 -O0 scan-tree-dump-times original
__builtin_free 9
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #13 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-11-04 18:44:18 UTC --- Author: aoliva Date: Sun Nov 4 18:44:13 2012 New Revision: 193138 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193138 Log: PR debug/54693 * tree-ssa-threadedge.c (propagate_threaded_block_debug_into): New, rewritten from debug stmt copying code... (thread_around_empty_block): ... removed from here. (thread_across_edge): Call propagate_threaded_block_debug_into. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-threadedge.c
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 --- Comment #14 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-11-04 18:44:32 UTC --- Author: aoliva Date: Sun Nov 4 18:44:25 2012 New Revision: 193139 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193139 Log: PR debug/54693 * tree-ssa-loop-ivopts.c (remove_unused_ivs): Emit debug temps for dropped IV sets. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug target/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 --- Comment #7 from uros at gcc dot gnu.org 2012-11-04 18:58:32 UTC --- Author: uros Date: Sun Nov 4 18:58:29 2012 New Revision: 193140 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193140 Log: PR target/55175 * config/i386/32/sfp-machine.h: Guard exception handling and rounding handling code with _SOFT_FLOAT. * config/i386/64/sfp-machine.h: Ditto. Modified: branches/gcc-4_7-branch/libgcc/ChangeLog branches/gcc-4_7-branch/libgcc/config/i386/32/sfp-machine.h branches/gcc-4_7-branch/libgcc/config/i386/64/sfp-machine.h
[Bug target/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 --- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-11-04 18:59:53 UTC --- (In reply to comment #6) I can confirm i386-rtems4.11-gcc now builds. @Uros: I am inclined to believe this patch probably should be backported to 4.7.x. H have backported similar change to 4.7 branch. Please reopen the PR if there are still problems.
[Bug target/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|4.8.0 |4.7.3
[Bug c/55208] New: ice in remove_redundant_iv_tests, at tree-ssa-loop-ivcanon.c:478
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55208 Bug #: 55208 Summary: ice in remove_redundant_iv_tests, at tree-ssa-loop-ivcanon.c:478 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 28615 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28615 C source code // I just tried to compile the package jfsutils-1.1.13-10 on gcc-4.8 trunk dated 20121104 on an AMD x86_64 box. The compiler said log_dump.c:635:6: internal compiler error: in remove_redundant_iv_tests, at tree-ssa-loop-ivcanon.c:478 void ldmp_xdump(char *saddr, int count) ^ Preprocessed source code attached. Flag -O3 required.
[Bug tree-optimization/54986] [4.7 Regression] Internal Error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54986 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org, mikpe at it dot ||uu.se --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2012-11-04 19:29:37 UTC --- Using Markus' test case in comment #3 my bisection identified r189686 as the point where this SEGV was introduced on 4.7 branch: http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00591.html http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00825.html The corresponding trunk change (r189685) did not cause this test case to fail, so something else must have changed on trunk to prevent it. Patch author CC:d.
[Bug tree-optimization/55191] [4.8 Regression] ICE in compute_antic at tree-ssa-pre.c:2511
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55191 --- Comment #3 from David Binderman dcb314 at hotmail dot com 2012-11-04 20:05:37 UTC --- (In reply to comment #2) Dup of 55176. I don't see the connection. One is an OOM, the other is an ICE.
[Bug rtl-optimization/55204] [4.8 Regression] ICE: in extract_insn, at recog.c:2140 (unrecognizable insn) with -O --param loop-invariant-max-bbs-in-loop=0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55204 rsand...@gcc.gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rsandifo at gcc dot gnu.org |gnu.org |
[Bug tree-optimization/55191] [4.8 Regression] ICE in compute_antic at tree-ssa-pre.c:2511
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55191 --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-11-04 20:08:15 UTC --- (In reply to comment #3) (In reply to comment #2) Dup of 55176. I don't see the connection. One is an OOM, the other is an ICE. OOM - when gcc was build with --enable-checking=release ICE - otherwise
[Bug regression/55168] [4.8 Regression]: gcc.c-torture/compile/pr44119.c ICE, all but -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55168 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-04 20:26:26 UTC --- (In reply to comment #2) This actually looks like a previously latent issue in predict.c For all but estimate_num_iterations_int. It uses the funny definition of number of iterations ... Honza, the regression went away in (193100:193109]. I see you made a series of predict.c improvements there. Is fixing this bug reasonably an expected effect of those patches, so this PR can be closed? As opposed to I thought of that but that bug is expected to still be there, I mean.
[Bug fortran/55174] [4.6 Regression] Segmentation fault with bad array reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174 --- Comment #3 from harper at msor dot vuw.ac.nz 2012-11-04 20:41:10 UTC --- On Fri, 2 Nov 2012, janus at gcc dot gnu.org wrote: Date: Fri, 2 Nov 2012 10:54:50 + From: janus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org To: john.har...@vuw.ac.nz Subject: [Bug fortran/55174] [4.6 Regression] Segmentation fault with bad array reference Resent-Date: Fri, 2 Nov 2012 10:55:07 + Resent-From: john.har...@vuw.ac.nz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-02 CC||janus at gcc dot gnu.org Summary|internal compiler error:|[4.6 Regression] |Segmentation fault with bad |Segmentation fault with bad |array reference |array reference Ever Confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org 2012-11-02 10:54:50 UTC --- (In reply to comment #1) It looks like it has been fixed on trunk (aka 4.8.0). For me it also works with: gcc version 4.7.2 20120920 [gcc-4_7-branch revision 191568] (SUSE Linux) (while it fails with 4.7.0 and 4.6.0). Note: The 4.6 branch is still maintained, so we should consider fixing it there. -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. I have just tried gfortran 4.7.1 (x86_64-unknown-linux-gnu) and it gave the internal compiler error with my program. So it seems that 4.7.0 and 4.7.1 both have the bug and 4.7.2 does not. Evidence: miro[~]$ cat trybadstar.f90 implicit none integer:: array(2)=(/42,666/) print *, size(array(*)) end miro[~]$ gf7 -v trybadstar.f90 Driving: /home/harperj1/gcc47/gf/bin/gfortran -v trybadstar.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=/home/harperj1/gcc47/gf/bin/gfortran COLLECT_LTO_WRAPPER=/home/harperj1/gcc47/gf/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/harperj1/gcc47/gcc-4.7.1/configure --prefix=/home/harperj1/gcc47/gf --enable-languages=c,fortran --disable-libada --with-local-prefix=/home/harperj1/gcc47 --with-gmp=/home/harperj1/gcc47 Thread model: posix gcc version 4.7.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /home/harperj1/gcc47/gf/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/f951 trybadstar.f90 -quiet -dumpbase trybadstar.f90 -mtune=generic -march=x86-64 -auxbase trybadstar -version -fintrinsic-modules-path /home/harperj1/gcc47/gf/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/finclude -o /tmp/ccFXH0I1.s GNU Fortran (GCC) version 4.7.1 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.1, GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (GCC) version 4.7.1 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.1, GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 f951: 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. miro[~]$ -- John Harper, School of Mathematics Statistics and Operations Research Victoria University, PO Box 600, Wellington 6140, New Zealand e-mail john.har...@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045
[Bug target/55184] [4.6 Regression] Invalid codegen with vectors and casts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55184 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2012-11-04 21:24:44 UTC --- I can confirm the bug with gcc-4.6.3 and the fixed test case. However, the bug has since been fixed on 4.6 branch in r187763, the fix for PR52407. The test cases for these bugs are very similar, so I'd consider this bug a duplicate of PR52407.
[Bug debug/54693] VTA guality issues with loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from Alexandre Oliva aoliva at gcc dot gnu.org 2012-11-04 22:09:12 UTC --- Fixed
[Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #6 from dave.anglin at bell dot net 2012-11-04 22:23:04 UTC --- On 4-Nov-12, at 12:31 PM, amylaar at gcc dot gnu.org wrote: The instruction call_symref_pic_post_reload has the following length attribute setting: (set (attr length) (symbol_ref pa_attr_length_call (insn, 0))) Such a length attribute is not considered variable by shorten_branches. You need to include a clause that is directly in the attribute, e.g. (and (match_test 0) (eq (match_dup 0) (pc))) Thanks Jorn for debugging this. Dave -- John David Anglindave.ang...@bell.net
[Bug fortran/55174] [4.6 Regression] Segmentation fault with bad array reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from janus at gcc dot gnu.org 2012-11-04 22:23:40 UTC --- (In reply to comment #3) I have just tried gfortran 4.7.1 (x86_64-unknown-linux-gnu) and it gave the internal compiler error with my program. So it seems that 4.7.0 and 4.7.1 both have the bug and 4.7.2 does not. Good. So it has been fixed between 4.7.1 and 4.7.2, apparently by this commit: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191216 This is the fix for PR 54225, and the good news is that it has also been backported to the 4.6 branch and therefore will be part of the future 4.6.4 release. So I think we can just close this as a duplicate of PR 54225. Nevertheless, thanks for the bug report! *** This bug has been marked as a duplicate of bug 54225 ***
[Bug fortran/54225] [4.6/4.7/4.8 Regression] fortran compiler segfault processing ' print *, A(1,*) '
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54225 janus at gcc dot gnu.org changed: What|Removed |Added CC||john.harper at vuw dot ||ac.nz --- Comment #8 from janus at gcc dot gnu.org 2012-11-04 22:23:40 UTC --- *** Bug 55174 has been marked as a duplicate of this bug. ***
[Bug fortran/55207] Automatic deallocation of variables declared in the main program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 --- Comment #2 from janus at gcc dot gnu.org 2012-11-04 22:26:44 UTC --- (In reply to comment #1) Patch: Note: The patch in comment 1 only fixes the auto-deallocation for scalars.
[Bug fortran/55207] Automatic deallocation of variables declared in the main program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55207 --- Comment #3 from janus at gcc dot gnu.org 2012-11-04 22:48:37 UTC --- The following patch applies the implicit SAVE attribute to variables declared in the main program: Index: gcc/fortran/decl.c === --- gcc/fortran/decl.c(revision 193137) +++ gcc/fortran/decl.c(working copy) @@ -3812,9 +3812,11 @@ match_attr_spec (void) } } - /* Since Fortran 2008 module variables implicitly have the SAVE attribute. */ - if (gfc_current_state () == COMP_MODULE !current_attr.save - (gfc_option.allow_std GFC_STD_F2008) != 0) + /* Since Fortran 2008, variables declared in a MODULE or PROGRAM + implicitly have the SAVE attribute. */ + if ((gfc_current_state () == COMP_MODULE + || gfc_current_state () == COMP_PROGRAM) + !current_attr.save (gfc_option.allow_std GFC_STD_F2008) != 0) current_attr.save = SAVE_IMPLICIT; colon_seen = 1; This also removes the automatic allocation of both variables in the test case in comment 0. Therefore it has the same testsuite failures as the patch in comment 1 (possibly more?).
[Bug middle-end/55145] Different bits for long double constant depending on long int size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55145 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2012-11-04 22:51:46 UTC --- Here are different internal values from the same input: 32-bit long: 1.57079632679489661925640447970309310221637133509 Input: 1.5707963267948966192021943710788178805159986950457096099853515625 64-bit long: 1.57079632679489661914798426245454265881562605500221252441 Input value is extremely close to a half-way value between 32-bit and 64-bit longs.
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2012-11-04 23:06:27 UTC --- From: http://www.sourceware.org/bugzilla/show_bug.cgi?id=14803#c1 --- Really I'd consider this just a variant on bug 21718 (real.c rounding not perfect). That would ideally be fixed by using MPFR for this in GCC ... except that for any MPFR versions before 3.1.1p2, the bug I found with the ternary value from mpfr_strtofr could cause problems for subnormal results. ---
[Bug middle-end/55145] Different bits for long double constant depending on long int size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55145 --- Comment #8 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-11-04 23:43:44 UTC --- (In reply to comment #7) Here are different internal values from the same input: 32-bit long: 1.57079632679489661925640447970309310221637133509 Input: 1.5707963267948966192021943710788178805159986950457096099853515625 64-bit long: 1.57079632679489661914798426245454265881562605500221252441 Input value is extremely close to a half-way value between 32-bit and 64-bit longs. 1.5707963267948966192021943710788178805159986950457096099853515625 is *exactly* the 65-bit binary number 1.100100111011010101000100011011010001110001101001, thus exactly a halfway value between two consecutive long double numbers (for 64-bit precision): 1.10010011101101010100010001101101000111000110100 and 1.10010011101101010100010001101101000111000110101 I suppose that the difference is due to the fact that the algorithm used in GCC has not been written to round correctly, and if this algorithm uses variables of type long internally, it is not surprising to get different results on different architectures (32-bit long and 64-bit long).
[Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #7 from dave.anglin at bell dot net 2012-11-04 23:50:44 UTC --- On 4-Nov-12, at 12:31 PM, amylaar at gcc dot gnu.org wrote: Such a length attribute is not considered variable by shorten_branches. You need to include a clause that is directly in the attribute, e.g. (and (match_test 0) (eq (match_dup 0) (pc))) In some sense, this seems like a hack which might be optimized by an attribute processor. What about a way to mark length attributes as variable? Dave -- John David Anglindave.ang...@bell.net
[Bug fortran/55174] [4.6 Regression] Segmentation fault with bad array reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174 --- Comment #5 from harper at msor dot vuw.ac.nz 2012-11-05 00:02:51 UTC --- On Sun, 4 Nov 2012, janus at gcc dot gnu.org wrote: Date: Sun, 4 Nov 2012 22:23:40 + From: janus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org To: john.har...@vuw.ac.nz Subject: [Bug fortran/55174] [4.6 Regression] Segmentation fault with bad array reference Resent-Date: Sun, 4 Nov 2012 22:24:00 + Resent-From: john.har...@vuw.ac.nz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from janus at gcc dot gnu.org 2012-11-04 22:23:40 UTC --- (In reply to comment #3) I have just tried gfortran 4.7.1 (x86_64-unknown-linux-gnu) and it gave the internal compiler error with my program. So it seems that 4.7.0 and 4.7.1 both have the bug and 4.7.2 does not. Good. So it has been fixed between 4.7.1 and 4.7.2, apparently by this commit: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191216 This is the fix for PR 54225, and the good news is that it has also been backported to the 4.6 branch and therefore will be part of the future 4.6.4 release. So I think we can just close this as a duplicate of PR 54225. Nevertheless, thanks for the bug report! *** This bug has been marked as a duplicate of bug 54225 *** -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. You may well be right. I'll be convinced if your analysis also explains why the bug was there in 4.8.0 of 20120701 but not in 4.8.0 of 20121002. -- John Harper, School of Mathematics Statistics and Operations Research Victoria University, PO Box 600, Wellington 6140, New Zealand e-mail john.har...@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 --- Comment #12 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-11-05 00:16:32 UTC --- (In reply to comment #11) Really I'd consider this just a variant on bug 21718 (real.c rounding not perfect). That would ideally be fixed by using MPFR for this in GCC ... except that for any MPFR versions before 3.1.1p2, the bug I found with the ternary value from mpfr_strtofr could cause problems for subnormal results. Alternatively, you can write code based on MPFR without using the ternary value. The algorithm would be: 1. Round to the target precision. 2. If the result is in the subnormal range (this can be detected by looking at the exponent of the result), then deduce the real precision from the exponent, and recompute the result in this precision directly.
[Bug middle-end/55198] [4.8 Regression] libquadmath/math/fmaq.c:233:7: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55198 --- Comment #2 from dave.anglin at bell dot net 2012-11-05 00:20:16 UTC --- On 3-Nov-12, at 10:38 PM, pinskia at gcc dot gnu.org wrote: Exposed as this is a change in the library and the compiler is crashing with a valid input that the change introduced. The ICE occurs because we get a TF mode REG instead of a MEM. -- John David Anglindave.ang...@bell.net
[Bug fortran/55174] [4.6 Regression] Segmentation fault with bad array reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174 --- Comment #6 from harper at msor dot vuw.ac.nz 2012-11-05 00:52:10 UTC --- On Mon, 5 Nov 2012, John Harper wrote: Date: Mon, 5 Nov 2012 13:02:37 +1300 (NZDT) From: John Harper har...@msor.vuw.ac.nz To: janus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org Subject: Re: [Bug fortran/55174] [4.6 Regression] Segmentation fault with bad array reference On Sun, 4 Nov 2012, janus at gcc dot gnu.org wrote: Date: Sun, 4 Nov 2012 22:23:40 + From: janus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org To: john.har...@vuw.ac.nz Subject: [Bug fortran/55174] [4.6 Regression] Segmentation fault with bad array reference Resent-Date: Sun, 4 Nov 2012 22:24:00 + Resent-From: john.har...@vuw.ac.nz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55174 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from janus at gcc dot gnu.org 2012-11-04 22:23:40 UTC --- (In reply to comment #3) I have just tried gfortran 4.7.1 (x86_64-unknown-linux-gnu) and it gave the internal compiler error with my program. So it seems that 4.7.0 and 4.7.1 both have the bug and 4.7.2 does not. Good. So it has been fixed between 4.7.1 and 4.7.2, apparently by this commit: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191216 This is the fix for PR 54225, and the good news is that it has also been backported to the 4.6 branch and therefore will be part of the future 4.6.4 release. So I think we can just close this as a duplicate of PR 54225. Nevertheless, thanks for the bug report! *** This bug has been marked as a duplicate of bug 54225 *** -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You reported the bug. You may well be right. I'll be convinced if your analysis also explains why the bug was there in 4.8.0 of 20120701 but not in 4.8.0 of 20121002. Apologies - I should have looked carefully at the dates for bug 54225. The bug was fixed between 20120701 and 20121002 so you are indeed right. -- John Harper, School of Mathematics Statistics and Operations Research Victoria University, PO Box 600, Wellington 6140, New Zealand e-mail john.har...@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045
[Bug debug/55209] New: gdb reports 'No symbol x in current context.' at -O0 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55209 Bug #: 55209 Summary: gdb reports 'No symbol x in current context.' at -O0 -g Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: h...@gcc.gnu.org Target: x86_64-linux At revision r192677, I have problems debugging cse1, as a local variable is gone at -O0 -g3. To repeat, just bootstrap, then rm cse.o and make cc1 CXXFLAGS=-g3. Enter gdb-7.5 for cc1 with a suitable command-line (for example -fpreprocessed pr55030-chk.i -quiet -dumpbase pr55030-chk.c -m32 -mtune=generic -march=x86-64 -auxbase pr55030-chk -Os -w -version -fno-diagnostics-show-caret -fno-tree-loop-distribute-patterns -o pr55030-chk.s with the attached pr55030-chk.i, but this is not important) Set a breakpoint on line 5084 (at r192677 it says if (MEM_P (trial) MEM_P (SET_DEST (sets[i].rtl. When the breakpoint hits, do p trial. gdb will respond with 'No symbol trial in current context.' PS. you might want to build gdb-7.5 with --without-auto-load-safe-path or add add-auto-load-safe-path /home to your ~/.gdbinit, assuming your gcc-trees are under your user home directory.
[Bug debug/55209] gdb reports 'No symbol x in current context.' at -O0 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55209 --- Comment #1 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-05 01:20:08 UTC --- Created attachment 28616 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28616 pr55030-chk.i
[Bug debug/55209] gdb reports 'No symbol x in current context.' at -O0 -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55209 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org 2012-11-05 01:21:23 UTC --- (In reply to comment #0) Set a breakpoint on line 5084 ...in cse.c
[Bug target/54938] sh libgcc_unpack_df.o fails to build: ../../../srcw/libgcc/fp-bit.h:221:19: internal compiler error: in emit_cmp_and_jump_insn_1, at optabs.c:4273
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54938 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-05 01:36:41 UTC --- I think this can be closed as it has been fixed.
[Bug middle-end/21718] real.c rounding not perfect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21718 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||areg.melikadamyan at gmail ||dot com, hjl.tools at gmail ||dot com --- Comment #13 from H.J. Lu hjl.tools at gmail dot com 2012-11-05 01:38:14 UTC --- Given that the correct MPFR isn't widely available, is that possible to fix rounding in real.c?
[Bug fortran/55210] New: cannot #define FOO 'a'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55210 Bug #: 55210 Summary: cannot #define FOO 'a' Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: sho...@gmail.com If I define a macro as in the summary I get the following output: [*] gfortran -cpp testfort.f -o testfort built-in:0:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. I tried it with -cpp, -xf95-cpp-input and -xf77-cpp-input. using gfortran 4.7.2, 4.4.3 and 4.4.4. ! testfort.f #define FOO 'a' program testfort implicit none print *, 'pretest' #if FOO == 'a' print *, the macro is a character a #endif print *, 'epitest' end program
[Bug target/55195] [4.8 Regression] shorten_branches generates incorrect forward branch distances
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55195 --- Comment #8 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2012-11-05 02:32:35 UTC --- (In reply to comment #7) In some sense, this seems like a hack which might be optimized by an attribute processor. What about a way to mark length attributes as variable? That would be nice, and pretty straightforward to code, but we seem short of generator program patches reviewers now. Note, I don't think there is any valid reason for the attribute processor to look inside a match_test; if it was something that the generators were supposed to understand, we should have rtl syntax for it.
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris Linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 Ryan Hill dirtyepic at gentoo dot org changed: What|Removed |Added CC||dirtyepic at gentoo dot org --- Comment #5 from Ryan Hill dirtyepic at gentoo dot org 2012-11-05 03:22:27 UTC --- Ping?
[Bug c++/54413] Option for turning off compiler extensions for -std=c++11 with respect to complex/fixed-point numbers missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54413 --- Comment #11 from Ed Smith-Rowland 3dw4rd at verizon dot net 2012-11-05 04:50:20 UTC --- Here is a patch that should work. it passes on x86_64 linux. I would like to get this in for 4.8 if possible.
[Bug c++/54413] Option for turning off compiler extensions for -std=c++11 with respect to complex/fixed-point numbers missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54413 --- Comment #12 from Ed Smith-Rowland 3dw4rd at verizon dot net 2012-11-05 04:55:36 UTC --- Created attachment 28617 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28617 Patch to implement flags allowing gnu suffixes to be used as user-defined literals. Here is a patch that should work. it passes on x86_64 linux. I would like to get this in for 4.8 if possible. There are three flags: -f[no-]imaginary-literals: Frees 'i', 'I', 'j', 'J' -f[no-]fixed-point-literals: Frees 'k', 'K', 'r', 'R' -f[no-]machine-defined-literals: Frees 'w', 'W', 'q', 'Q'
[Bug debug/54402] [4.8 Regression] var-tracking does not scale
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54402 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-05 07:58:52 UTC --- Author: jakub Date: Mon Nov 5 07:58:48 2012 New Revision: 193152 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193152 Log: PR debug/54402 * var-tracking.c (fp_setter): Return false if there is REG_CFA_RESTORE hfp note. (vt_initialize): Look for fp_setter in any bb, not just successor of entry bb. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c
