[Bug c/50922] infinite loop when optimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50922 --- Comment #9 from Rolf Pfister pfister at pci dot uzh.ch 2011-11-01 07:25:53 UTC --- Am 31.10.11 21:38, schrieb manu at gcc dot gnu.org: I sincerely hope you are not doing something important with your code. Relying No, I dont use this code in my own programs. It was just the first example program coming with a new hardware device. Now when someone will ask again in the forum, I can tell them that it is a bug in the program and not in the compiler. http://myavr.info/myForum/viewtopic.php?t=2974 Rolf
[Bug fortran/50937] STAT option with ALLOCATE statement on large arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937 --- Comment #10 from Janne Blomqvist jb at gcc dot gnu.org 2011-11-01 07:55:06 UTC --- (In reply to comment #8) I indeed do not know everything about the OS and what it does when I allocate an array. But that's exactly the purpose of a programming language like Fortran, an abstraction that should be good enough for programing without having to know everything about the OS. Sometimes abstractions leak, unfortunately. There's really not anything gfortran can do about that. And, it's not unique to gfortran either. gfortran ALLOCATE uses the C malloc(), as does e.g. the default implementation of the C++ new operator and presumably a lot of other language runtimes as well. So they all share the same issues in case the system overcommits memory. I can certainly sympathize with the notion that memory overcommit is inane and shouldn't be enabled by default, but that's a system policy issue and nothing gfortran can do anything about. As you're on Linux, FWIW you can disable overcommit by setting the vm.overcommit_memory sysctl to the value 2. See http://www.mjmwired.net/kernel/Documentation/vm/overcommit-accounting Secondly, users are sometimes better than programmers at telling them if something is really useful or not. In that case, the question is: what is the purpose of the STAT flag in an allocate STATEMENT if it won't give you any reasonable indication if the array you have can be used or not. Indeed, on a system which overcommits memory, ALLOCATE with STAT is not particularly useful. But, again, memory overcommitting is a system policy issue and gfortran can't do anything about it. And, one might add, if all you're going to do with the STAT result is checking whether it's nonzero and stopping the program in that case, you might as well not bother because that's exactly what ALLOCATE without STAT already does.
[Bug tree-optimization/50902] [4.7 Regression] intVar/dinternal.cc ICEs at -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50902
Ira Rosen irar at il dot ibm.com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011-11-01
CC||irar at il dot ibm.com
Ever Confirmed|0 |1
--- Comment #7 from Ira Rosen irar at il dot ibm.com 2011-11-01 08:25:08 UTC
---
Reduced testcase:
_Bool data[128];
void foo (_Bool *init)
{
int i;
for (i = 0; i 128; i++)
data[i] = *init;
}
gcc_checking_assert (types_compatible_p (TYPE_MAIN_VARIANT (TREE_TYPE (sc)),
TREE_TYPE (vectype)));
fails since VECTYPE is vector(16) unnamed-unsigned:8
and the scalar type is _Bool
[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-01 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-01 09:27:20 UTC --- Confirmed. Can you try writing a dg-effective-target test?
[Bug c++/50939] [C++0x] lambda expression causes ICE when lambda captures const variable and odr-uses the variable in function templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50939 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-01 Ever Confirmed|0 |1 Known to fail||4.6.2, 4.7.0
[Bug target/50940] New: [4.7 Regression] ICE in extract_insn, at recog.c:2137 during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50940 Bug #: 50940 Summary: [4.7 Regression] ICE in extract_insn, at recog.c:2137 during bootstrap Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mar...@trippelsdorf.de I've hit the following ICE during bootstrap on x86_64-pc-linux-gnu. It only happens with the -march=native switch. /var/tmp/gcc_build_dir/./prev-gcc/g++ -B/var/tmp/gcc_build_dir/./prev-gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/var/tmp/gcc/libstdc++-v3/libsupc++ -L/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/gcc_build_dir/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -c -march=native -O3 -pipe -fuse-linker-plugin -flto=jobserver -fno-fat-lto-objects -frandom-seed=1 -fprofile-generate -fno-lto -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-exceptions -fno-rtti -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber../../gcc/gcc/df-core.c -o df-core.o ../../gcc/gcc/df-core.c: In function ‘void df_worklist_dataflow(dataflow*, bitmap, int*, int)’: ../../gcc/gcc/df-core.c:1107:1: error: unrecognizable insn: (insn 2516 2515 2040 168 (set (reg:V4SF 21 xmm0 [1487]) (float:V2DF (vec_select:V2SI (reg:V4SI 21 xmm0 [1487]) (parallel [ (const_int 0 [0]) (const_int 1 [0x1]) ] ../../gcc/gcc/df-core.c:1047 -1 (nil)) ../../gcc/gcc/df-core.c:1107:1: internal compiler error: in extract_insn, at recog.c:2137 Please submit a full bug report, Caused by the recent config/i386/sse.md changes rev. 180723 180724. -march=native on my machine is equal to: -march=amdfam10 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mabm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mlzcnt --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10 -m3dnow -m64 -m80387 -mabm -maccumulate-outgoing-args -malign-stringops -mcx16 -mfancy-math-387 -mfp-ret-in-387 -mglibc -mieee-fp -mlzcnt -mmmx -mno-sse4 -mpopcnt -mpush-args -mred-zone -msahf -msse -msse2 -msse3 -msse4a -mtls-direct-seg-refs
[Bug c++/50941] New: [C++0x] user-defined string literals provide incorrect length for wchar_t, char16_t, and char32_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50941
Bug #: 50941
Summary: [C++0x] user-defined string literals provide incorrect
length for wchar_t, char16_t, and char32_t
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
CC: ja...@redhat.com
gcc 4.7.0 20111029 (experimental) in C++0x mode rejects the following code:
//---
typedef decltype(sizeof(0)) size_type;
constexpr size_type operator _len(const char*, size_type len)
{
return len;
}
constexpr size_type operator _len(const wchar_t*, size_type len)
{
return len;
}
constexpr size_type operator _len(const char16_t*, size_type len)
{
return len;
}
constexpr size_type operator _len(const char32_t*, size_type len)
{
return len;
}
static_assert( _len == 0, Ouch); // OK
static_assert(u8_len == 0, Ouch); // OK
static_assert( L_len == 0, Ouch); // Error
static_assert( u_len == 0, Ouch); // Error
static_assert( U_len == 0, Ouch); // Error
//---
With
error: static assertion failed: Ouch
at the marked lines.
The code should be accepted.
It turns out that for wchar_t, char16_t, and char32_t string literals the
provided length is 1, not 0. But according to N3290 2.14.8 p5 and 2.14.5 p15
the provided length value should also be 0 in above examples. This problem also
occurs for non-empty strings: The length value is always too large by 1 for the
mentioned string types.
[Bug c++/50941] [C++0x] user-defined string literals provide incorrect length for wchar_t, char16_t, and char32_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50941 --- Comment #1 from Daniel Krügler daniel.kruegler at googlemail dot com 2011-11-01 10:24:59 UTC --- I need to make a correction in regard to the actually provided length values: a) The following assertions incorrectly hold: static_assert( L_len == 1, Ouch); static_assert( u_len == 1, Ouch); static_assert( U_len == 3, Ouch); b) For non-empty strings other value patterns occur, e.g. these tests static_assert(L1_len == 3, Ouch); static_assert(u1_len == 3, Ouch); static_assert(U1_len == 7, Ouch); evaluate to true, even though the length should be 1 in all these cases.
[Bug target/50940] [4.7 Regression] ICE in extract_insn, at recog.c:2137 during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50940
--- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-11-01 10:55:21 UTC ---
Testcase:
% cat test.ii
typedef long int ptrdiff_t;
extern C {
typedef struct _IO_FILE FILE;
extern int fprintf (FILE *__restrict __stream,
__const char *__restrict __format, ...);
}
typedef struct bitmap_head_def *bitmap;
typedef struct simple_bitmap_def *sbitmap;
struct function {
struct control_flow_graph *cfg;
};
extern struct function *cfun;
extern FILE *dump_file;
struct control_flow_graph {
int x_n_basic_blocks;
int x_n_edges;
};
static bool df_worklist_propagate_forward (struct dataflow *dataflow,
unsigned bb_index, unsigned *bbindex_to_postorder,
bitmap pending, sbitmap considered, ptrdiff_t age)
{
int dcount = 0;
if (dump_file) fprintf (dump_file, df_worklist_dataflow_doublequeue:
n_basic_blocks %d n_edges %dcount %d (%5.2g)\n,
((cfun + 0)-cfg-x_n_basic_blocks), ((cfun + 0)-cfg-x_n_edges),
dcount, dcount / (float)((cfun + 0)-cfg-x_n_basic_blocks));
}
% g++ test.ii -march=amdfam10 -B/var/tmp/gcc_build_dir/./prev-gcc/
test.ii: In function ‘bool df_worklist_propagate_forward(dataflow*, unsigned
int, unsigned int*, bitmap, sbitmap, ptrdiff_t)’:
test.ii:27:1: error: unrecognizable insn:
(insn 56 55 21 3 (set (reg:V4SF 22 xmm1 [orig:64 D.2155 ] [64])
(float:V2DF (vec_select:V2SI (reg:V4SI 22 xmm1 [orig:64 D.2155 ] [64])
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
] test.ii:26 -1
(nil))
test.ii:27:1: internal compiler error: in extract_insn, at recog.c:2137
[Bug ada/50942] New: Bootstrap failure on mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50942 Bug #: 50942 Summary: Bootstrap failure on mingw32 Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: ivansavvat...@yandex.ru Failure on Stage 3 when a make script try to execute following command: cp -p ../.././gcc/ada/rts adainclude Error messgage: cp: omitting directory '../.././gcc/ada/rts'
[Bug fortran/50937] STAT option with ALLOCATE statement on large arrays
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50937 --- Comment #11 from fwi at inducks dot org 2011-11-01 12:00:54 UTC --- (In reply to comment #10) Sometimes abstractions leak, unfortunately. There's really not anything gfortran can do about that. And, it's not unique to gfortran either. gfortran ALLOCATE uses the C malloc(), as does e.g. the default implementation of the C++ new operator and presumably a lot of other language runtimes as well. So they all share the same issues in case the system overcommits memory. I hate to continue this discussion, but I think the integer overflow problem, which is what I was reporting, was a different issue. The fact that you solved it in recent gfortran versions proves that there was something you could do about that. I can certainly sympathize with the notion that memory overcommit is inane and shouldn't be enabled by default, but that's a system policy issue and nothing gfortran can do anything about. As you're on Linux, FWIW you can disable overcommit by setting the vm.overcommit_memory sysctl to the value 2. See http://www.mjmwired.net/kernel/Documentation/vm/overcommit-accounting Thanks for the info. And, one might add, if all you're going to do with the STAT result is checking whether it's nonzero and stopping the program in that case, you might as well not bother because that's exactly what ALLOCATE without STAT already does. Not really, because then I can directly tell users how they can solve the issue, that is either switch to a 64bit OS or compile the MPI version of the same program (because then the main array is splitted in several chunks, all of them small enough to be indexed with 32bit integers). Without the STAT option, users will be left in the dark with just it doesn't work. Or with I need to spend time reading the manual. And please - I hope you all do not take my remarks as harsh criticism, I do appreciate the efforts and job you did with gfortran. A few years ago, my code was much faster with ifort than gcc's Fortran, nowadays it's comparable and I can tell people to use gfortran if they like.
[Bug c++/50943] New: asm goto in templated code causes internal compiler segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50943
Bug #: 50943
Summary: asm goto in templated code causes internal compiler
segfaults
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dummy...@gmail.com
Created attachment 25675
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25675
The code that causes a segfault
I tested the code in mingw-tdm64 4.5.2, 4.6.1, and under the mac port for
4.6.1, all with the same result.
$ gcc-fsf-4.6 -v -save-temps main.cpp
Using built-in specs.
COLLECT_GCC=gcc-fsf-4.6
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin11.1.0/4.6.1/lto-wrapper
Target: x86_64-apple-darwin11.1.0
Configured with: ../gcc-4.6.1/configure --prefix=/sw
--prefix=/sw/lib/gcc4.6 --mandir=/sw/share/man
--infodir=/sw/lib/gcc4.6/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw
--with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.6
--enable-cloog-backend=isl
Thread model: posix
gcc version 4.6.1 (GCC)
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.2' '-v' '-save-temps'
'-mtune=core2'
/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin11.1.0/4.6.1/cc1plus -E
-quiet -v -D__DYNAMIC__ main.cpp -fPIC -mmacosx-version-min=10.7.2
-mtune=core2 -fpch-preprocess -o main.ii
ignoring nonexistent directory
/sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin11.1.0/4.6.1/../../../../x86_64-apple-darwin11.1.0/include
#include ... search starts here:
#include ... search starts here:
/sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin11.1.0/4.6.1/../../../../include/c++/4.6.1
/sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin11.1.0/4.6.1/../../../../include/c++/4.6.1/x86_64-apple-darwin11.1.0
/sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin11.1.0/4.6.1/../../../../include/c++/4.6.1/backward
/sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin11.1.0/4.6.1/include
/usr/local/include
/sw/lib/gcc4.6/include
/sw/lib/gcc4.6/lib/gcc/x86_64-apple-darwin11.1.0/4.6.1/include-fixed
/usr/include
/System/Library/Frameworks
/Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.2' '-v' '-save-temps'
'-mtune=core2'
/sw/lib/gcc4.6/libexec/gcc/x86_64-apple-darwin11.1.0/4.6.1/cc1plus
-fpreprocessed main.ii -fPIC -quiet -dumpbase main.cpp
-mmacosx-version-min=10.7.2 -mtune=core2 -auxbase main -version -o main.s
GNU C++ (GCC) version 4.6.1 (x86_64-apple-darwin11.1.0)
compiled by GNU C version 4.6.1, GMP version 5.0.2, MPFR version 3.0.1,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.6.1 (x86_64-apple-darwin11.1.0)
compiled by GNU C version 4.6.1, GMP version 5.0.2, MPFR version 3.0.1,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b15fbe702f97b74ba102fe17491ae6a1
main.cpp: In function ‘bool work(int*, int) [with T = int]’:
main.cpp:15:1: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ cat main.ii
# 1 main.cpp
# 1 built-in
# 1 command-line
# 1 main.cpp
templateclass T
bool work(int* data, int bit) {
asm goto(lock and %0, %1;
jz %l[other]
: : r(~(1 bit)), m(data) : : other);
return false;
other:
return true;
}
int main(int argc, char** argv) {
int data = 2;
workint(data, data);
return 0;
}
[Bug target/50940] [4.7 Regression] ICE in extract_insn, at recog.c:2137 during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50940 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-01 AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2011-11-01 12:22:02 UTC --- Confirmed, a typo in *floatsimode2_vector_sse_with_temp splitter. Index: i386.md === --- i386.md(revision 180733) +++ i386.md(working copy) @@ -5053,7 +5053,7 @@ emit_insn (gen_sse2_loadld (operands[4], CONST0_RTX (V4SImode), operands[2])); } - if (ssevecmodemode == V4SImode) + if (ssevecmodemode == V4SFmode) emit_insn (gen_floatv4siv4sf2 (operands[3], operands[4])); else emit_insn (gen_sse2_cvtdq2pd (operands[3], operands[4]));
[Bug tree-optimization/50908] [4.7 Regression] building emacs-23.3; gives msg: indent.c:1140:1: internal compiler error: in verify_dominators, at dominance.c:1041
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50908 --- Comment #6 from vries at gcc dot gnu.org 2011-11-01 12:42:06 UTC --- Author: vries Date: Tue Nov 1 12:42:01 2011 New Revision: 180737 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180737 Log: 2011-11-01 Tom de Vries t...@codesourcery.com PR tree-optimization/50908 * tree-ssa-tail-merge.c (update_vuses): Now that edges are removed before update_vuses, test for 1 predecessor rather than two. (delete_block_update_dominator_info): New function, part of it factored out of ... (replace_block_by): Use delete_block_update_dominator_info. Call update_vuses after deleting bb1 and updating dominator info, instead of before. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-tail-merge.c
[Bug target/45650] [4.4/4.5/4.6 regression] FreeBSD/ia64 builds fails: hidden symbol `_Unwind_FindTableEntry' isn't defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45650 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.7.0 Resolution||FIXED Target Milestone|4.4.7 |4.7.0 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-01 12:53:17 UTC --- Fixed for 4.7.0, wontfix for earlier releases.
[Bug tree-optimization/50902] [4.7 Regression] intVar/dinternal.cc ICEs at -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50902
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-01
13:06:57 UTC ---
Mine.
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c(revision 180737)
+++ gcc/tree-vect-stmts.c(working copy)
@@ -4726,11 +4726,20 @@
/* 4. Handle invariant-load. */
if (inv_p !bb_vinfo)
{
- tree vec_inv;
+ tree tem, vec_inv;
gimple_stmt_iterator gsi2 = *gsi;
gcc_assert (!strided_load);
gsi_next (gsi2);
- vec_inv = build_vector_from_val (vectype, scalar_dest);
+ tem = scalar_dest;
+ if (!useless_type_conversion_p (TREE_TYPE (vectype),
+ TREE_TYPE (tem)))
+{
+ tem = fold_convert (TREE_TYPE (vectype), tem);
+ tem = force_gimple_operand_gsi (gsi2, tem, true,
+ NULL_TREE, true,
+ GSI_SAME_STMT);
+}
+ vec_inv = build_vector_from_val (vectype, tem);
new_temp = vect_init_vector (stmt, vec_inv,
vectype, gsi2);
new_stmt = SSA_NAME_DEF_STMT (new_temp);
[Bug target/50940] [4.7 Regression] ICE in extract_insn, at recog.c:2137 during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50940 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug c++/50943] asm goto in templated code causes internal compiler segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50943 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-01 Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-11-01 13:15:42 UTC --- Confirmed. The frontend fails to re-map the labels in the asm goto statement leading to disagreement at gimplification time: stmt cleanup_point_expr 0x14248dbb8 type void_type 0x14233abd0 void side-effects tree_1 arg 0 asm_expr 0x142324b40 type void_type 0x14233abd0 void side-effects public .. arg 4 tree_list 0x14248dac8 purpose string_cst 0x142489f40 constant other value label_decl 0x14248e080 other ... stmt label_expr 0x14248dc08 type void_type 0x14233abd0 void side-effects arg 0 label_decl 0x14248e200 other type void_type 0x14233abd0 void VOID file t.ii line 7 col 1 align 1 context function_decl 0x142481500 work initial error_mark 0x142329d68 t.ii:7:1
[Bug target/50944] New: gcc-4.6.x regression with complex.h on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50944
Bug #: 50944
Summary: gcc-4.6.x regression with complex.h on
i386-pc-solaris2.10
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mariah.le...@gmail.com
This is reopening #48949 which got closed.
% gcc -c foo.c
foo.c: In function 'foo':
foo.c:5:11: error: '_Imaginary_I' undeclared (first use in this function)
foo.c:5:11: note: each undeclared identifier is reported only once for each
function it appears in
%
% gcc-4.5.1 -c foo.c
%
% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.1/sparc-SunOS-ultrasparc3/libexec/gcc/sparc-sun-solaris2.10/4.6.1/lto-wrapper
Target: sparc-sun-solaris2.10
Configured with: /usr/local/gcc-4.6.1/src/gcc-4.6.1/configure
--enable-languages=c,c++,fortran --with-gnu-as
--with-as=/usr/local/binutils-2.20.1/sparc-SunOS-ultrasparc3-gcc-4.4.3/bin/as
--with-gnu-ld
--with-ld=/usr/local/binutils-2.20.1/sparc-SunOS-ultrasparc3-gcc-4.4.3/bin/ld
--with-gmp=/usr/local/mpir-2.4.0/sparc-SunOS-ultrasparc3-gcc-4.6.0-abi32
--with-mpfr=/usr/local/mpfr-3.0.1/sparc-SunOS-ultrasparc3-mpir-2.4.0-gcc-4.6.0-abi32
--with-mpc=/usr/local/mpc-0.9/sparc-SunOS-ultrasparc3-mpir-2.4.0-mpfr-3.0.1-gcc-4.5.1-abi32
--prefix=/usr/local/gcc-4.6.1/sparc-SunOS-ultrasparc3
Thread model: posix
gcc version 4.6.1 (GCC)
%
% cat foo.c
#include complex.h
double _Complex
foo () {
return I;
}
%
% gcc -E foo.c | grep complex.h
# 1 /usr/include/complex.h 1 3 4
# 9 /usr/include/complex.h 3 4
#pragma ident @(#)complex.h1.9 04/10/23 SMI
# 24 /usr/include/complex.h 3 4
# 61 /usr/include/complex.h 3 4
# 61 /usr/include/complex.h 3 4
%
% diff /usr/include/complex.h
/usr/local/gcc-4.6.1/sparc-SunOS-ultrasparc3/inclu
de/c++/4.6.1/complex.h
1,4c1
/*
* Copyright 2004 Sun Microsystems, Inc. All rights reserved.
* Use is subject to license terms.
*/
---
// -*- C++ -*- compatibility header.
6,7c3,9
#ifndef _COMPLEX_H
#define _COMPLEX_H
---
// Copyright (C) 2007, 2009 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 3, or (at your option)
// any later version.
9c11,14
#pragma ident @(#)complex.h 1.9 04/10/23 SMI
---
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
11c16,18
#if !defined(__cplusplus)
---
// Under Section 7 of GPL version 3, you are granted additional
// permissions described in the GCC Runtime Library Exception, version
// 3.1, as published by the Free Software Foundation.
13,15c20,26
/*
* Compilation environments for Solaris must provide the _Imaginary datatype
* and the compiler intrinsics _Complex_I and _Imaginary_I
---
// You should have received a copy of the GNU General Public License and
// a copy of the GCC Runtime Library Exception along with this program;
// see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
// http://www.gnu.org/licenses/.
/** @file complex.h
* This is a Standard C++ Library header.
17,22d27
#define _Complex_I _Complex_I
#define complex _Complex
#define _Imaginary_I_Imaginary_I
#define imaginary _Imaginary
#undefI
#define I _Imaginary_I
24,45c29
extern float cabsf(float complex);
extern float cargf(float complex);
extern float cimagf(float complex);
extern float crealf(float complex);
extern float complex cacosf(float complex);
extern float complex cacoshf(float complex);
extern float complex casinf(float complex);
extern float complex casinhf(float complex);
extern float complex catanf(float complex);
extern float complex catanhf(float complex);
extern float complex ccosf(float complex);
extern float complex ccoshf(float complex);
extern float complex cexpf(float complex);
extern float complex clogf(float complex);
extern float complex conjf(float complex);
extern float complex cpowf(float complex, float complex);
extern float complex cprojf(float complex);
extern float complex csinf(float complex);
extern float complex csinhf(float complex);
extern float complex csqrtf(float complex);
extern float complex ctanf(float complex);
extern float complex ctanhf(float complex);
---
#include bits/c++config.h
47,61c31,32
extern double cabs(double complex);
extern double carg(double complex);
extern double cimag(double complex);
extern double creal(double complex);
[Bug target/50944] gcc-4.6.x regression with complex.h on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50944 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-11-01 13:34:23 UTC --- (N.B. you could have just reopened PR 48949 and provided the requested info there)
[Bug c++/50500] [C++0x] [DR 1082] move constructor should cause copy constructor to be deleted, but still declared
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50500 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-11-01 13:48:21 UTC --- Author: jason Date: Tue Nov 1 13:48:16 2011 New Revision: 180738 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180738 Log: PR c++/50500 DR 1082 * search.c (lookup_fnfields_idx_nolazy): Split out from... (lookup_fnfields_1): ...here. (lookup_fnfields_slot_nolazy): Use it. * cp-tree.h: Declare it. * class.c (type_has_move_assign): Use it. (type_has_user_declared_move_assign): Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/search.c
[Bug rtl-optimization/50904] Induct benchmark of polyhedron slows down when -fno-protect-parens is enabled by -Ofast.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-01 13:52:48 UTC --- I don't see why RTL invariant motion should move the one variant but not the other. Of course this also shows that we should, after loop unrolling on the tree level, also perform loop invariant motion again ... The problem seems to be in RTL PRE, which hoists simple loads but not loads that are wrapped up in a PLUS or a MINUS. Even with -fprotect-parens, load hoisting opportunities are lost because of this.
[Bug target/50910] [avr] inefficient division by 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50910 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-11-01 14:10:23 UTC --- Author: gjl Date: Tue Nov 1 14:10:13 2011 New Revision: 180739 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180739 Log: PR target/50910 * config/avr/avr.opt (-mbranch-cost=): New option. * config/avr/avr.h (BRANCH_COST): Define to avr_branch_cost. * config/avr/avr.c (avr_rtx_costs_1): Adjust [U]DIV/[U]MOD costs. * config/avr/avr.md (*addqi3.lt0, *addhi3.lt0, *addsi3.lt0): New insns. (*addhi3_zero_extend1): Remov % in constraint of operand 1. (*addhi3.sign_extend1, *subhi3.sign_extend2): New insns. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/avr.opt
[Bug target/50910] [avr] inefficient division by 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50910 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-11-01 14:11:19 UTC --- Fixed in 4.7.0
[Bug tree-optimization/50918] Unoptimal code for vec-shift by scalar for integer (byte, short, long long) operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50918 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||irar at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-01 14:18:47 UTC --- I don't see that for long long we would create inefficient shifts, at least not with -mavx2. For the char/short shifts, I guess we'd want to add vect_recog_narrow_shift_pattern that would recognize these. For shifts by constant, I think it can be done always (if the constant is bigger than precision of the narrower type for left shifts and right unsigned shifts we can just change it into clearing the destination (though the earlier optimizers should have done that already), for right arithmetic shift we could do x 0 ? -1 : 0), for shifts by variable we'd need a target hook or macro how vector shifts with larger or equal shift count than precision behave. AFAIK i?86 (all vector shifts) DTRT for this (i.e. left/right unsigned shifts for too big count store zero and right arithmetic shift stores copies of the sign bit everywhere), but e.g. Altivec shifts truncate and thus can't be used.
[Bug ada/50197] Assert_Failure sinfo.adb:2738 with default generic formal parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50197 Artem V. Andreev Artem.Andreev at oktetlabs dot ru changed: What|Removed |Added CC||Artem.Andreev at oktetlabs ||dot ru --- Comment #1 from Artem V. Andreev Artem.Andreev at oktetlabs dot ru 2011-11-01 15:19:11 UTC --- I have attested the same bug on 4.4.5 (x86_64-pc-linux-gnu)
[Bug tree-optimization/50902] [4.7 Regression] intVar/dinternal.cc ICEs at -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50902 --- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu 2011-11-01 16:53:09 UTC --- (In reply to comment #8) I can confirm that the proposed patch resolves the build failures in xplor-nih without regressions in the xplor-nih testsuite.
[Bug target/50945] New: ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50945
Bug #: 50945
Summary: ICE
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org
Updated today. Revision 180737
Host: x86_64-unknown-linux-gnu
Target: sparc-rtems4.11
/home2/joel/build/b-sparc-gcc/./gcc/xgcc -B/home2/joel/build/b-sparc-gcc/./gcc/
-nostdinc -B/home2/joel/build/b-sparc-gcc/sparc-rtems4.11/newlib/ -isystem
/home2/joel/build/b-sparc-gcc/sparc-rtems4.11/newlib/targ-include -isystem
/users/joel/test-gcc/gcc-svn/newlib/libc/include
-B/users/joel/test-gcc/install-svn/sparc-rtems4.11/bin/
-B/users/joel/test-gcc/install-svn/sparc-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-svn/sparc-rtems4.11/include -isystem
/users/joel/test-gcc/install-svn/sparc-rtems4.11/sys-include-g -O2
-msoft-float -O2
-I/users/joel/test-gcc/gcc-svn/gcc/../newlib/libc/sys/rtems/include -I. -I.
-I/users/joel/test-gcc/gcc-svn/gcc -I/users/joel/test-gcc/gcc-svn/gcc/.
-I/users/joel/test-gcc/gcc-svn/gcc/../include
-I/users/joel/test-gcc/gcc-svn/gcc/../libdecnumber
-I/users/joel/test-gcc/gcc-svn/gcc/../libdecnumber/dpd -I../libdecnumber
-I/users/joel/test-gcc/gcc-svn/gcc/../libgcc -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc
-I/users/joel/test-gcc/gcc-svn/libgcc/../newlib/libc/sys/rtems/include -I. -I.
-I../../.././gcc -I/users/joel/test-gcc/gcc-svn/libgcc
-I/users/joel/test-gcc/gcc-svn/libgcc/.
-I/users/joel/test-gcc/gcc-svn/libgcc/../gcc
-I/users/joel/test-gcc/gcc-svn/libgcc/../include -DHAVE_CC_TLS -o _powixf2.o
-MT _powixf2.o -MD -MP -MF _powixf2.dep -DL_powixf2 -c
/users/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcc2.c \
/users/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcc2.c: In function '__powidf2':
/users/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcc2.c:1778:1: error: could not
split insn
(insn 60 111 195 (set (reg:DF 8 %o0)
(const_double:DF 1.0e+0 [0x0.8p+1]))
/users/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcc2.c:1777 68 {*movdf_insn_sp32}
(expr_list:REG_EQUAL (const_double:DF 1.0e+0 [0x0.8p+1])
(nil)))
/users/joel/test-gcc/gcc-svn/libgcc/../gcc/libgcc2.c:1778:1: internal compiler
error: in final_scan_insn, at final.c:2709
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/50945] ICE in final_scan_insn, at final.c:2709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50945 --- Comment #1 from Joel Sherrill joel at gcc dot gnu.org 2011-11-01 17:53:23 UTC --- Created attachment 25676 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25676 Preprocessed source for failure case
[Bug target/50945] ICE in final_scan_insn, at final.c:2709
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50945 --- Comment #2 from Joel Sherrill joel at gcc dot gnu.org 2011-11-01 17:55:48 UTC --- WORKS: -O0 -msoft-float FAILS: -O1 -msoft-float FAILS: -O2 -msoft-float WORKS: -O2
[Bug target/50944] gcc-4.6.x regression with complex.h on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50944 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot ||gnu.org Resolution||DUPLICATE --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-01 18:16:49 UTC --- Indeed. *** This bug has been marked as a duplicate of bug 48949 ***
[Bug target/48949] [4.6/4.7 Regression] gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48949 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-01 18:16:49 UTC --- *** Bug 50944 has been marked as a duplicate of this bug. ***
[Bug target/48949] [4.6/4.7 Regression] gcc-4.6.0 regression with complex.h on i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48949 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ebotcazou at gcc dot ||gnu.org Resolution|INVALID | --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-01 18:17:31 UTC --- Please answer comment #3.
[Bug fortran/46686] Improve backtracing (unwinding) on non-glibc targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46686 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-01 CC||jb at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jb at gcc dot gnu.org |gnu.org | Summary|Improve backtracing |Improve backtracing |(unwinding) on MinGW|(unwinding) on non-glibc ||targets Ever Confirmed|0 |1 --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org 2011-11-01 18:24:37 UTC --- I have a patch: http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00068.html
[Bug target/50945] ICE on floating-point move with -msoft-float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50945 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target|sparc-rtems4.11 |sparc-*-* CC||ebotcazou at gcc dot ||gnu.org Host|x86_64-unknown-linux-gnu| Version|unknown |4.7.0 Summary|ICE in final_scan_insn, at |ICE on floating-point move |final.c:2709|with -msoft-float --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-01 18:25:56 UTC --- Please set the version field when you open a PR (Unknown doesn't count) and try to find a descriptive summary.
[Bug target/50945] [4.7 regression] ICE on floating-point move with -msoft-float
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50945 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-11-01 AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Target Milestone|--- |4.7.0 Summary|ICE on floating-point move |[4.7 regression] ICE on |with -msoft-float |floating-point move with ||-msoft-float Ever Confirmed|0 |1 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-01 18:27:31 UTC --- Fixing.
[Bug rtl-optimization/47918] [4.6/4.7 Regression] noreturn discovery broke non local gotos on m68k and i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47918 --- Comment #12 from jules at gcc dot gnu.org 2011-11-01 18:38:45 UTC --- Author: jules Date: Tue Nov 1 18:38:42 2011 New Revision: 180740 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180740 Log: PR rtl-optimization/47918 * reload1.c (set_initial_label_offsets): Use initial offsets for labels on the nonlocal_goto_handler_labels chain. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/reload1.c
[Bug rtl-optimization/47918] [4.6/4.7 Regression] noreturn discovery broke non local gotos on m68k and i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47918 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #13 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-11-01 18:58:19 UTC --- Presumably everywhere.
[Bug debug/48354] internal compiler error: in splice_child_die, at dwarf2out.c:8064
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48354 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #15 from Jack Howarth howarth at nitro dot med.uc.edu 2011-11-01 18:59:45 UTC --- This issue appears to still exist in gcc trunk. The same failure is seen building libnmrPot.dylib in xplor-nih with -flto... g++-fsf-4.7 -dynamiclib -Ofast -funroll-loops -g -flto -fdefault-integer-8 -flat_namespace -undefined suppress -single_module noePot.o atomProb.o rdcPot1.o csaPot.o jCoupPot.o shapePot.o atomDensity.o probDistPot.o cosRatioPot.o ncsPot.o prePot.o rdcWavePot.o varTensor.o surfaceArea.o psolPot.o orderPot.o posRMSDPot.o utils.o posSymmPot.o sphereFun.o volume.o planeDistPot.o selNBPot.o gyrPot.o cstMagPot.o diffPot.o relaxRatioPot.o distSymmPot.o sardcPot.o surfTessellation.o torsionDBPot.o nbTargetPot.o solnScatPot.o -o libnmrPot.dylib-lcrypto -L/Users/howarth/xplor-nih-2.27/bin.Darwin_11_x86_64/ -lspecfun -lsurfD -llapack -lblas In file included from surfaceArea.cc:1276:0, from /Users/howarth/xplor-nih-2.27/CDSlib/cdsSStream.cc:327, from :1669: /Users/howarth/xplor-nih-2.27/nmrPot/relaxRatioPot.hh: In member function ‘numRestraints’: /Users/howarth/xplor-nih-2.27/nmrPot/relaxRatioPot.hh:163:37: internal compiler error: in splice_child_die, at dwarf2out.c:5009 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: g++-fsf-4.7 returned 1 exit status collect2: error: lto-wrapper returned 1 exit status
[Bug debug/50869] [4.7 Regression] ice in vt_expand_var_loc_chain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50869 Alexandre Oliva aoliva at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Alexandre Oliva aoliva at gcc dot gnu.org 2011-11-01 19:02:55 UTC --- Fixed
[Bug c++/50946] New: ICE on armhf with webkitgtk+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50946 Bug #: 50946 Summary: ICE on armhf with webkitgtk+ Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: konstantinos.margari...@linaro.org Created attachment 25677 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25677 minimal testcase produced using delta tool from Source/WebCore/bindings/js/SerializedScriptValue.cpp in webkitgtk+ webkitgtk+_1.4.2-2 fails to build from source on Debian armhf due to a gcc ICE: http://buildd.debian-ports.org/status/fetch.php?pkg=webkitgtk%2Barch=armhfver=1.4.2-2stamp=1311782209 Compiler originally used was g++ 4.6.1-10 but the same ICE appears with 4.6.2-3 (current Debian/unstable): ... CXXSource/WebCore/bindings/js/libWebCore_la-SerializedScriptValue.lo In file included from ../Source/JavaScriptCore/wtf/PassRefPtr.h:25:0, from ../Source/JavaScriptCore/wtf/RefPtr.h:28, from ../Source/JavaScriptCore/wtf/HashFunctions.h:24, from ../Source/JavaScriptCore/wtf/HashTraits.h:24, from ../Source/JavaScriptCore/runtime/JSValue.h:31, from ../Source/JavaScriptCore/runtime/CachedTranscendentalFunction.h:29, from ../Source/JavaScriptCore/runtime/JSGlobalData.h:32, from ../Source/JavaScriptCore/interpreter/CallFrame.h:26, from ../Source/JavaScriptCore/runtime/ArgList.h:25, from ../Source/JavaScriptCore/runtime/JSObject.h:26, from ../Source/JavaScriptCore/runtime/JSArray.h:24, from ../Source/JavaScriptCore/runtime/JSGlobalObject.h:25, from ../Source/WebCore/bindings/js/JSDOMGlobalObject.h:30, from ../Source/WebCore/bindings/js/JSDOMBinding.h:25, from ../Source/WebCore/bindings/js/ScriptValue.h:34, from ../Source/WebCore/bindings/js/SerializedScriptValue.h:30, from ../Source/WebCore/bindings/js/SerializedScriptValue.cpp:28: ../Source/JavaScriptCore/wtf/NullPtr.h:48:1: warning: identifier 'nullptr' will become a keyword in C++0x [-Wc++0x-compat] In file included from ../Source/JavaScriptCore/runtime/JSObject.h:31:0, from ../Source/JavaScriptCore/runtime/JSArray.h:24, from ../Source/JavaScriptCore/runtime/JSGlobalObject.h:25, from ../Source/WebCore/bindings/js/JSDOMGlobalObject.h:30, from ../Source/WebCore/bindings/js/JSDOMBinding.h:25, from ../Source/WebCore/bindings/js/ScriptValue.h:34, from ../Source/WebCore/bindings/js/SerializedScriptValue.h:30, from ../Source/WebCore/bindings/js/SerializedScriptValue.cpp:28: ../Source/JavaScriptCore/runtime/JSCell.h: In member function 'void* JSC::MarkedBlock::allocate()': ../Source/JavaScriptCore/runtime/JSCell.h:380:78: warning: cast from 'char (*)[8]' to 'JSC::JSCell*' increases required alignment of target type [-Wcast-align] In file included from ../Source/JavaScriptCore/collector/handles/Handle.h:29:0, from ../Source/JavaScriptCore/collector/handles/HandleHeap.h:30, from ../Source/JavaScriptCore/runtime/Heap.h:25, from ../Source/JavaScriptCore/runtime/JSGlobalData.h:33, from ../Source/JavaScriptCore/interpreter/CallFrame.h:26, from ../Source/JavaScriptCore/runtime/ArgList.h:25, from ../Source/JavaScriptCore/runtime/JSObject.h:26, from ../Source/JavaScriptCore/runtime/JSArray.h:24, from ../Source/JavaScriptCore/runtime/JSGlobalObject.h:25, from ../Source/WebCore/bindings/js/JSDOMGlobalObject.h:30, from ../Source/WebCore/bindings/js/JSDOMBinding.h:25, from ../Source/WebCore/bindings/js/ScriptValue.h:34, from ../Source/WebCore/bindings/js/SerializedScriptValue.h:30, from ../Source/WebCore/bindings/js/SerializedScriptValue.cpp:28: ../Source/JavaScriptCore/runtime/WriteBarrier.h: In member function 'T* JSC::WriteBarrierBaseT::get() const [with T = JSC::JSGlobalObject]': ../Source/JavaScriptCore/runtime/ScopeChain.h:76:86: instantiated from here ../Source/JavaScriptCore/runtime/WriteBarrier.h:97:56: warning: cast from 'JSC::JSCell*' to 'JSC::JSGlobalObject*' increases required alignment of target type [-Wcast-align] ../Source/JavaScriptCore/runtime/WriteBarrier.h: In member function 'T* JSC::WriteBarrierBaseT::get() const [with T = JSC::ObjectPrototype]': ../Source/JavaScriptCore/runtime/JSGlobalObject.h:185:81: instantiated from here ../Source/JavaScriptCore/runtime/WriteBarrier.h:97:56: warning: cast from 'JSC::JSCell*' to 'JSC::ObjectPrototype*' increases required
[Bug target/50940] [4.7 Regression] ICE in extract_insn, at recog.c:2137 during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50940 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2011-11-01 20:06:25 UTC --- Author: uros Date: Tue Nov 1 19:48:34 2011 New Revision: 180742 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180742 Log: PR target/50940 * config/i386/i386.md (floatsimode2_vector_sse_with_temp splitter): Compare ssevecmodemode with V4SFmode, not V4SImode. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug target/50940] [4.7 Regression] ICE in extract_insn, at recog.c:2137 during bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50940 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-11/msg00081.htm ||l Resolution||FIXED --- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2011-11-01 20:07:17 UTC --- Fixed.
[Bug c++/50947] New: ICE on armhf with llvm-2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50947
Bug #: 50947
Summary: ICE on armhf with llvm-2.x
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: konstantinos.margari...@linaro.org
Created attachment 25678
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25678
minimal testcase produced using delta tool from
lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp in llvm-2.x
llvm-2.x fail to build from source on Debian armhf, all due to a g++ ICE:
http://buildd.debian-ports.org/status/fetch.php?pkg=llvm-2.7arch=armhfver=2.7-6.2stamp=1311446819
http://buildd.debian-ports.org/status/fetch.php?pkg=llvm-2.8arch=armhfver=2.8-7stamp=1309205992
http://buildd.debian-ports.org/status/fetch.php?pkg=llvm-2.9arch=armhfver=2.9%2Bdfsg-3stamp=1309210849
Originally the bug appeared with g++-4.6.1-10 but it still fails with
g++-4.6.2-3 (latest Debian/unstable).
...
llvm[4]: Compiling ExternalFunctions.cpp for Release build
if arm-linux-gnueabihf-g++
-I/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/build-llvm/include
-I/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/build-llvm/lib/ExecutionEngine/Interpreter
-I/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/include
-I/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/lib/ExecutionEngine/Interpreter
-DNDEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-g -O2 -fomit-frame-pointer -fno-exceptions -fPIC -Woverloaded-virtual
-Wcast-qual-pedantic -Wno-long-long -Wall -W -Wno-unused-parameter
-Wwrite-strings -c -MMD -MP -MF
/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/build-llvm/lib/ExecutionEngine/Interpreter/Release/ExternalFunctions.d.tmp
-MT
/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/build-llvm/lib/ExecutionEngine/Interpreter/Release/ExternalFunctions.o
-MT
/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/build-llvm/lib/ExecutionEngine/Interpreter/Release/ExternalFunc
tions.d
/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp
-o
/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/build-llvm/lib/ExecutionEngine/Interpreter/Release/ExternalFunctions.o
; \
then /bin/mv -f
/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/build-llvm/lib/ExecutionEngine/Interpreter/Release/ExternalFunctions.d.tmp
/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/build-llvm/lib/ExecutionEngine/Interpreter/Release/ExternalFunctions.d;
else /bin/rm
/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/build-llvm/lib/ExecutionEngine/Interpreter/Release/ExternalFunctions.d.tmp;
exit 1; fi
/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp:
In member function 'llvm::GenericValue
llvm::Interpreter::callExternalFunction(llvm::Function*, const
std::vectorllvm::GenericValue)':
/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp:293:1:
error: insn does not satisfy its constraints:
(insn 3133 3132 3135 306 (set (subreg:SI (reg:DI 1122) 0)
(ior:SI (ashift:SI (reg:SI 1125)
(const_int -24 [0xffe8]))
(subreg:SI (reg:DI 1122) 0)))
/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/include/llvm/ADT/APInt.h:139
251 {*arith_shiftsi}
(nil))
/build/buildd-llvm-2.8_2.8-7-armhf-yLsjcC/llvm-2.8-2.8/lib/ExecutionEngine/Interpreter/ExternalFunctions.cpp:293:1:
internal compiler error: in extract_constrain_insn_cached, at
recog.c:2024
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions.
I used the delta package to produce a minimal testcase for the ICE
which I attach.
You can reproduce the ICE with:
g++ -O2 -fpermissive -w llvm_ExternalFunctions-min.i
The bug has also been filed on the Debian BTS:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642127
Regards
Konstantinos
[Bug c/50948] New: ICE on armhf with neon code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50948 Bug #: 50948 Summary: ICE on armhf with neon code Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: konstantinos.margari...@linaro.org Host: arm-linux-gnueabihf Target: arm-linux-gnueabihf Build: arm-linux-gnueabihf Created attachment 25679 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25679 minimal testcase produced using delta tool from source (propriatery driver including NEON code) When building neon code on armhf -which I cannot attach to its full, due to licensing reason, unfortunately- I get an ICE. Using delta I was able to get a minimal testcase that produces the exact ICE. The testcase is attached. Here is the message and the cmd line used: $ gcc -O -mfpu=neon matrix-min.i matrix-min.i: In function ‘matrixTranspose’: matrix-min.i:10:29: internal compiler error: in immed_double_const, at emit-rtl.c:550 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. Preprocessed source stored into /tmp/cc3zlt4j.out file, please attach this to your bugreport. In fact, the same ICE I get on oneiric gcc with the same testcase. The bug has also been filed on Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646160 Konstantinos
[Bug c/50949] New: ICE on armhf with neon code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50949
Bug #: 50949
Summary: ICE on armhf with neon code
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: konstantinos.margari...@linaro.org
Host: arm-linux-gnueabihf
Target: arm-linux-gnueabihf
Build: arm-linux-gnueabihf
Created attachment 25680
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25680
minimal testcase produced using delta tool from source (propriatery driver
including NEON code)
(Note: this is a different ICE than #PR50948, but produced from the
same file as the previous, in fact it's produced from the same
function, albeit with a small modification).
When building neon code on armhf -which I cannot attach to its full,
due to licensing reason, unfortunately- I get an ICE. Using delta I
was able to get a minimal testcase (which is different than the one in
#PR50948), that produces the exact ICE. The testcase is attached. Here
is the message and the cmd line used:
$ gcc -O -mfpu=neon matrix2-min.i
matrix2-min.i: In function ‘matrixTranspose’:
matrix2-min.i:38:5: error: insn does not satisfy its constraints:
(insn 41 16 17 2 (set (mem/c/i:XI (pre_dec:SI (reg/f:SI 5 r5 [145]))
[0 S64 A64])
(reg:XI 111 d24)) matrix2-min.i:21 753 {*neon_movxi}
(expr_list:REG_INC (reg/f:SI 5 r5 [145])
(nil)))
matrix2-min.i:38:5: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccpGsI3S.out file, please attach
this to your bugreport.
This ICE is not reproducible on gcc-4.6 on oneiric/armel.
This bug has also been filed to the Debian BTS:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=646163
Konstantinos
[Bug target/50948] ICE on armhf with neon code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50948 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-11-01 Ever Confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-11-01 20:44:04 UTC --- arm-linux-gnueabihf isn't a configuration supported by FSF GCC; if this is vendor distribution you need to contact your vendor. Alternatively you need to show how to produce this on the FSF sources.
[Bug target/50949] ICE on armhf with neon code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50949 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-11-01 Ever Confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-11-01 20:44:42 UTC --- arm-linux-gnueabihf isn't a configuration supported by FSF GCC; if this is vendor distribution you need to contact your vendor. Alternatively you need to show how to produce this on the FSF sources.
[Bug target/50947] ICE on armhf with llvm-2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50947 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-11-01 Ever Confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-11-01 20:55:39 UTC --- arm-linux-gnueabihf isn't a configuration supported by FSF GCC; if this is vendor distribution you need to contact your vendor. Alternatively you need to show how to produce this on the FSF sources.
[Bug target/50946] ICE on armhf with webkitgtk+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50946 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-11-01 Ever Confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2011-11-01 20:56:25 UTC --- arm-linux-gnueabihf isn't a configuration supported by FSF GCC; if this is vendor distribution you need to contact your vendor. Alternatively you need to show how to produce this on the FSF sources.
[Bug target/50949] ICE on armhf with neon code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50949 --- Comment #2 from Konstantinos Margaritis konstantinos.margaritis at linaro dot org 2011-11-01 21:05:42 UTC --- This is the full cmd line used: gcc -g -O -mfpu=neon -mfloat-abi=hard -march=armv7-a -mthumb -fpermissive -c matrix.i This is the actual gcc revision used in the Debian package: 20111028 (r180603).
[Bug target/50948] ICE on armhf with neon code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50948 --- Comment #2 from Konstantinos Margaritis konstantinos.margaritis at linaro dot org 2011-11-01 21:07:59 UTC --- This was the actual cmd line used: gcc -O -mfpu=neon -mfloat-abi=hard -march=armv7-a -mthumb -fpermissive -c matrix2-min.i The Debian armhf package is based on SVN 20111028 (r180603) from the gcc-4_6-branch.
[Bug target/50946] ICE on armhf with webkitgtk+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50946 --- Comment #2 from Konstantinos Margaritis konstantinos.margaritis at linaro dot org 2011-11-01 21:15:29 UTC --- This is the actual cmd line used: g++ -O2 -mfpu=vfpv3 -mfloat-abi=hard -march=armv7-a -mthumb -fpermissive -w -c webkit_testcase-min.i The Debian armhf package is based on SVN 20111028 (r180603) from the gcc-4_6-branch.
[Bug c/50950] New: warning missed when OR'ing to an uninitialized variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50950 Bug #: 50950 Summary: warning missed when OR'ing to an uninitialized variable Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: seze...@gmail.com Created attachment 25681 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25681 small test case $ gcc44 -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc44-svn/configure --enable-checking=yes --enable-languages=c --enable-shared --enable-threads --with-local-prefix=/usr --prefix=/opt/gcc440 --program-suffix=44 --bindir=/opt/bin --disable-nls Thread model: posix gcc version 4.4.7 20111023 (prerelease) (GCC) ]$ gcc44 -O2 -Wall -S test.c test.c: In function 'f1': test.c:22: warning: 'x' is used uninitialized in this function test.c: In function 'ff2': test.c:40: warning: 'y' is used uninitialized in this function test.c: In function 'ff1': test.c:30: warning: 'x' is used uninitialized in this function test.c: In function 'f0': test.c:14: warning: 'x' is used uninitialized in this function gcc 4.4 (tested 3.3.6, 3.4.6 and 4.3.0) and gcc 4.4 (tested 4.5.4/r180676 and 4.6.1) does not warn at all. Also notice the selectively issued warnings in ff1() and ff2(), i.e. only for the first uninitialized variable. Not sure if this is a duplicate of bug 18501 co.
[Bug target/50947] ICE on armhf with llvm-2.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50947 --- Comment #2 from Konstantinos Margaritis konstantinos.margaritis at linaro dot org 2011-11-01 21:18:19 UTC --- This is the actual cmd line used: g++ -O2 -mfpu=vfpv3 -mfloat-abi=hard -march=armv7-a -mthumb -fpermissive -w -c llvm_ExternalFunctions-min.i The Debian armhf package is based on SVN 20111028 (r180603) from the gcc-4_6-branch.
[Bug tree-optimization/50908] [4.7 Regression] building emacs-23.3; gives msg: indent.c:1140:1: internal compiler error: in verify_dominators, at dominance.c:1041
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50908 --- Comment #7 from vries at gcc dot gnu.org 2011-11-01 21:48:26 UTC --- Author: vries Date: Tue Nov 1 21:48:22 2011 New Revision: 180746 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180746 Log: 2011-11-01 Tom de Vries t...@codesourcery.com PR tree-optimization/50908 * gcc.dg/pr50908.c: New test. * gcc.dg/pr50908-2.c: Same. * gcc.dg/pr50908-3.c: Same. Added: trunk/gcc/testsuite/gcc.dg/pr50908-2.c trunk/gcc/testsuite/gcc.dg/pr50908-3.c trunk/gcc/testsuite/gcc.dg/pr50908.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/50908] [4.7 Regression] building emacs-23.3; gives msg: indent.c:1140:1: internal compiler error: in verify_dominators, at dominance.c:1041
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50908 vries at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from vries at gcc dot gnu.org 2011-11-01 21:49:43 UTC --- Patch and test-cases checked in, marking PR fixed.
[Bug tree-optimization/50908] [4.7 Regression] building emacs-23.3; gives msg: indent.c:1140:1: internal compiler error: in verify_dominators, at dominance.c:1041
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50908 vries at gcc dot gnu.org changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #9 from vries at gcc dot gnu.org 2011-11-01 21:50:32 UTC --- *** Bug 50878 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/50908] [4.7 Regression] building emacs-23.3; gives msg: indent.c:1140:1: internal compiler error: in verify_dominators, at dominance.c:1041
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50908 vries at gcc dot gnu.org changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #10 from vries at gcc dot gnu.org 2011-11-01 21:51:32 UTC --- *** Bug 50886 has been marked as a duplicate of this bug. ***
[Bug middle-end/50886] [4.7 Regression] 445.gobmk in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50886 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE AssignedTo|unassigned at gcc dot |vries at gcc dot gnu.org |gnu.org | --- Comment #3 from vries at gcc dot gnu.org 2011-11-01 21:51:32 UTC --- Patch for this PR50908 fixes this PR. *** This bug has been marked as a duplicate of bug 50908 ***
[Bug c++/50941] [C++0x] user-defined string literals provide incorrect length for wchar_t, char16_t, and char32_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50941 --- Comment #2 from Ed Smith-Rowland 3dw4rd at verizon dot net 2011-11-01 21:52:13 UTC --- Divide by sizeof, then subtract 1. Working on a patch.
[Bug bootstrap/50878] [4.7 Regression] ARM bootstrap failure on insn-preds.c with error: dominator of 12 should be 6, not 5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50878 vries at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE --- Comment #12 from vries at gcc dot gnu.org 2011-11-01 21:50:32 UTC --- Patch for this PR50908 fixes this PR. *** This bug has been marked as a duplicate of bug 50908 ***
[Bug libstdc++/50951] New: state of subtract_with_carry_engine not saved correctly to output stream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50951 Bug #: 50951 Summary: state of subtract_with_carry_engine not saved correctly to output stream Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dariom...@hotmail.com the value of __x._M_p is not written to output stream __os by operator(std::basic_ostream_CharT, _Traits __os,const subtract_with_carry_engine_UIntType,__w,__s,__r __x) in 4.6.1/include/c++/bits/random.tcc. Consequently, the state of the random engine is not fully restored by the corresponding operator. One way to fix the problem is to write __x._M_p to output stream __os. Alternatively, the contents of the ring buffer could be saved and restored always beginning at index __x._M_p, whatever its value, and then wrapping around the ring buffer as necessary.
[Bug bootstrap/50952] New: libquad relocation R_X86_64_32S failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50952 Bug #: 50952 Summary: libquad relocation R_X86_64_32S failure Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: ka...@gcc.gnu.org Created attachment 25682 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25682 build log With both 4.6.3 and trunk, I'm seeing problems with libquad, which is completely baffling me. The 'gmake bootstrap' completes as expected, but 'gmake install' dies with gfortran.so.3.0 -o .libs/libgfortran.so.3.0 /usr/bin/ld: /home/sgk/work/46/lib/libquadmath.a(fmodq.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC /home/sgk/work/46/lib/libquadmath.a: could not read symbols: Bad value collect2: ld returned 1 exit status libtool: install: error: relink `libgfortran.la' with the above command before installing it gmake[4]: *** [install-toolexeclibLTLIBRARIES] Error 1 gmake[4]: Leaving directory `/usr/home/sgk/gcc/obj46/x86_64-unknown-freebsd10.0/libgfortran' gmake[3]: *** [install-am] Error 2 gmake[3]: Leaving directory `/usr/home/sgk/gcc/obj46/x86_64-unknown-freebsd10.0/libgfortran' gmake[2]: *** [install] Error 2 gmake[2]: Leaving directory `/usr/home/sgk/gcc/obj46/x86_64-unknown-freebsd10.0/libgfortran' gmake[1]: *** [install-target-libgfortran] Error 2 gmake[1]: Leaving directory `/usr/home/sgk/gcc/obj46' gmake: *** [install] Error 2 I've redirected the the output to files and the -fPIC is already on the command line. What seems odd to me is that the 'gmake install' is relinking the libquadmath.so shared library. I've attached 'gmake | build.log' and 'gmake install | install.log'
[Bug bootstrap/50952] libquad relocation R_X86_64_32S failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50952 --- Comment #1 from kargl at gcc dot gnu.org 2011-11-01 22:42:39 UTC --- Created attachment 25683 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25683 install log
[Bug bootstrap/50952] libquad relocation R_X86_64_32S failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50952 --- Comment #2 from kargl at gcc dot gnu.org 2011-11-01 22:43:40 UTC --- I shoudl note that the shared libraries for libgfortran are properly build and installed. This seems to be a libquadmath issue.
[Bug bootstrap/50952] libquad relocation R_X86_64_32S failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50952 --- Comment #3 from kargl at gcc dot gnu.org 2011-11-01 22:53:02 UTC --- It looks like a problem with libquadmath/configure. I recently updated by bleeding edge freebsd system to FreeBSD 10.0, and it looks like configure can't handle the new version number. troutmask:sgk[222] pwd /usr/home/sgk/gcc/gcc4x/libquadmath troutmask:sgk[223] grep -i freebsd * | more aclocal.m4:# (eg FreeBSD returns the mod time of the symlink's containing configure:# WARNING: Do not start the trap code with a newline, due to a FreeBSD 4.0 bug. configure:# (eg FreeBSD returns the mod time of the symlink's containing configure: netbsd* | freebsd* | openbsd* | darwin* | dragonfly*) configure:freebsd* | dragonfly*) configure: lt_cv_deplibs_check_method='file_magic (FreeBSD|OpenBSD|DragonFly)/i[3-9]86 (compact )?demand paged shared library' configure:/* This works around a problem in FreeBSD linker */ configure:#ifdef FREEBSD_WORKAROUND configure:x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \ configure:x86_64-*kfreebsd*-gnu) configure:x86_64-*kfreebsd*-gnu) configure:# FreeBSD 2.2.[012] allows us to include c++rt0.o to get C++ constructor configure:freebsd2.2*) configure:# Unfortunately, older versions of FreeBSD 2 do not have this feature. configure:freebsd2*) configure:# FreeBSD 3 and greater uses gcc -shared to do shared libraries. configure:freebsd* | dragonfly*) configure:freebsd* | dragonfly*) configure:freebsd[123]*) objformat=aout ;; configure: version_type=freebsd-$objformat configure:freebsd-elf*) configure:freebsd-*) configure: freebsd2*) configure: freebsd3.[01]* | freebsdelf3.[01]*) configure: freebsd3.[2-9]* | freebsdelf3.[2-9]* | \ configure: freebsd4.[0-5] | freebsdelf4.[0-5] | freebsd4.1.1 | freebsdelf4.1.1) configure: version_type=freebsd-elf I'm suspicious that the 'freebsd[123]*) objformat=aout ;;' is now bogus.
[Bug libstdc++/50951] state of subtract_with_carry_engine not saved correctly to output stream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50951 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-01 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-01 22:56:41 UTC --- Looks like a simple oversight.
[Bug libstdc++/50951] state of subtract_with_carry_engine not saved correctly to output stream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50951 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/50952] libquad relocation R_X86_64_32S failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50952 kargl at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-freebsd10.0 Component|bootstrap |target Host||x86_64-*-freebsd10.0 Known to fail||4.6.3, 4.7.0 --- Comment #4 from kargl at gcc dot gnu.org 2011-11-01 23:02:50 UTC --- (In reply to comment #3) It looks like a problem with libquadmath/configure. I recently updated by bleeding edge freebsd system to FreeBSD 10.0, and it looks like configure can't handle the new version number. configure:freebsd[123]*) objformat=aout ;; configure: version_type=freebsd-$objformat configure:freebsd-elf*) configure:freebsd-*) configure: freebsd2*) configure: freebsd3.[01]* | freebsdelf3.[01]*) configure: freebsd3.[2-9]* | freebsdelf3.[2-9]* | \ configure: freebsd4.[0-5] | freebsdelf4.[0-5] | freebsd4.1.1 | freebsdelf4.1.1) configure: version_type=freebsd-elf I'm suspicious that the 'freebsd[123]*) objformat=aout ;;' is now bogus. A quick hack to remove the 1 in the above line allows me to configure, build, and install gcc/gfortran. Anyone know how to fix this issue properly?
[Bug other/50953] New: Snow Leopard 10.6.8 - TinyOS - Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50953 Bug #: 50953 Summary: Snow Leopard 10.6.8 - TinyOS - Segmentation Fault Classification: Unclassified Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: mo...@berkeley.edu
[Bug libstdc++/50951] state of subtract_with_carry_engine not saved correctly to output stream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50951 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-01 23:09:45 UTC --- Same issue for mersenne_twister...
[Bug other/50954] New: Snow Leopard 10.6.8 - TinyOS Oscilloscope - Segmentation Fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50954 Bug #: 50954 Summary: Snow Leopard 10.6.8 - TinyOS Oscilloscope - Segmentation Fault Classification: Unclassified Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: mo...@berkeley.edu My OS is MAC OS X 10.6.8, I've TinyOS installed on it. gcc --version: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) It works if I try to build some of the default applications provided by TinyOS release (like Blink, Null, etc.). But if I try to compile the Oscilloscope application for telosb motes I get this output: $ make telosb mkdir -p build/telosb compiling OscilloscopeAppC to a telosb binary ncc -o build/telosb/main.exe -Os -O -fnesc-separator=__ -Wall -Wshadow -Wnesc-all -target=telosb -fnesc-cfile=build/telosb/app.c -board= -DDEFINED_TOS_AM_GROUP=0x22 -DIDENT_APPNAME=\OscilloscopeApp\ -DIDENT_USERNAME=\Cinese\ -DIDENT_HOSTNAME=\MacBook-di-Stef\ -DIDENT_USERHASH=0x688ec652L -DIDENT_TIMESTAMP=0x4eb07db8L -DIDENT_UIDHASH=0xe99bd6e1L OscilloscopeAppC.nc -lm /opt/tinyos-2.x/tos/chips/cc2420/lpl/DummyLplC.nc:39:2: warning: #warning *** LOW POWER COMMUNICATIONS DISABLED *** /opt/tinyos-2.x/tos/chips/msp430/adc12/Msp430Adc12ImplP.nc:68:4: warning: #warning Accessing TimerA for ADC12 /opt/tinyos-2.x/tos/interfaces/TaskBasic.nc: In function `CC2420TransmitP__CaptureSFD__captured': /opt/tinyos-2.x/tos/interfaces/TaskBasic.nc:67: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make: *** [exe0] Error 1 Any hints? regards, Stefano Moret
[Bug c++/44277] [C++0x] Add warning to facilitate nullptr conversion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44277 --- Comment #6 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-11-01 23:28:23 UTC --- Author: paolo Date: Tue Nov 1 23:28:19 2011 New Revision: 180750 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180750 Log: /cp 2011-11-01 Paolo Carlini paolo.carl...@oracle.com PR c++/44277 * cvt.c (cp_convert_to_pointer): Warn for zero as null pointer constant. * typeck.c (cp_truthvalue_conversion): Handle pointers and member function pointers under c_inhibit_evaluation_warnings; use nullptr_node for data member pointers. (cp_build_binary_op): Tweak, just forward to cp_convert op1, either a nullptr_node or an integer_zero_node. (build_ptrmemfunc): Use nullptr_node. * init.c (build_zero_init_1): Likewise. /c-family 2011-11-01 Paolo Carlini paolo.carl...@oracle.com PR c++/44277 * c.opt: Add Wzero-as-null-pointer-constant. /gcc 2011-11-01 Paolo Carlini paolo.carl...@oracle.com PR c++/44277 * doc/invoke.texi: Document -Wzero-as-null-pointer-constant. /testsuite 2011-11-01 Paolo Carlini paolo.carl...@oracle.com PR c++/44277 * g++.dg/warn/Wzero-as-null-pointer-constant-1.C: New. * g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C trunk/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/cp/init.c trunk/gcc/cp/typeck.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug c++/44277] [C++0x] Add warning to facilitate nullptr conversion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44277 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com 2011-11-01 23:30:08 UTC --- Done for 4.7.0.
[Bug target/50906] e500 exception unwinding under -Os causes SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-11-01 CC||amodra at gmail dot com Ever Confirmed|0 |1 --- Comment #4 from Alan Modra amodra at gmail dot com 2011-11-01 23:44:04 UTC --- _Z16closure_test_fn1P7ffi_cifPvPS1_S1_: .LFB0: .file 1 unwindtestfunc.cc .loc 1 17 0 .cfi_startproc .LVL0: stwu 1,-128(1) .LCFI0: .cfi_def_cfa_offset 128 mflr 0 mr 3,6 .LVL1: stw 0,132(1) addi 11,1,-16 .LCFI1: .cfi_def_cfa 11, 160 That last .cfi directive is wrong. To match the instructions it should be .cfi_def_cfa 11, 144
[Bug target/50906] e500 exception unwinding under -Os causes SIGSEGV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50906 --- Comment #5 from Alan Modra amodra at gmail dot com 2011-11-02 00:05:42 UTC --- bl _save64gpr_24 .loc 1 17 0 mr 31,4 .cfi_offset 31, -100 .cfi_offset 1231, -104 .cfi_offset 30, -108 .cfi_offset 1230, -112 .cfi_offset 29, -116 .cfi_offset 1229, -120 .cfi_offset 28, -124 .cfi_offset 1228, -128 .cfi_offset 27, -132 .cfi_offset 1227, -136 .cfi_offset 26, -140 .cfi_offset 1226, -144 .cfi_offset 25, -148 .cfi_offset 1225, -152 .cfi_offset 24, -156 .cfi_offset 1224, -160 These are all wrong too, I think. .loc 1 26 0 lwz 9,0(5) .loc 1 17 0 mr 11,5 Yikes!! Using r11 for something else, but no cfi directive to say the frame is no longer in r11.
[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #13 from Oleg Endo oleg.e...@t-online.de 2011-11-02 00:15:44 UTC
---
Created attachment 25684
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25684
Proposed patch to add QImode displacement addressing
This should be better now. I have also put back support for the SH2A
displacement addressing insns. The CSiBE set compiles fine for -m2a,
-m4-single, -m4a-single, both big and little endian. However, it introduces
new failures in the testsuite. I have examined a few of them and one common
problem seems to be of this nature:
udivmod4.c:59:1: error: insn does not satisfy its constraints:
(insn 313 312 194 (set (reg:SI 150 fpul)
(mem/c:SI (plus:SI (reg/f:SI 15 r15)
(const_int 8 [0x8])) [0 %sfp+-72 S4 A32])) udivmod4.c:54 192
{movsi_ie}
(nil))
udivmod4.c:59:1: internal compiler error: in extract_constrain_insn_cached, at
recog.c:2052
.. when compiled with -O0 -m4-single -mb.
This is mainly caused by the following added lines in sh_legitimate_index_p:
+ if ((GET_MODE_SIZE (mode) == 1) (unsigned) INTVAL (op) 16)
+return true;
Apparently this makes something believe that loading the FPUL register from a
displacement address is possible, which is of course not the case. However, I
can't see any connection there...
[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751 --- Comment #14 from Kazumoto Kojima kkojima at gcc dot gnu.org 2011-11-02 00:57:59 UTC --- (In reply to comment #13) Apparently this makes something believe that loading the FPUL register from a displacement address is possible, which is of course not the case. However, I can't see any connection there... .ira dump would be your friend, though I suspect that your patch triggered off some other reload problem like PR48596. Could you try the change in #5 of that PR?
[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751 --- Comment #15 from Oleg Endo oleg.e...@t-online.de 2011-11-02 01:38:26 UTC --- (In reply to comment #14) .ira dump would be your friend, though I suspect that your patch triggered off some other reload problem like PR48596. Could you try the change in #5 of that PR? I just tried it out, but it seems it has no effect in this case.
[Bug c++/50941] [C++0x] user-defined string literals provide incorrect length for wchar_t, char16_t, and char32_t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50941 --- Comment #3 from Ed Smith-Rowland 3dw4rd at verizon dot net 2011-11-02 04:22:20 UTC --- Created attachment 25685 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25685 Patch with testcase. Patch. Testcase modified from initial report. Thank you Daniel for the report. Jason, should I rename the testcase after the bug number? Ed
[Bug tree-optimization/50955] New: IVopts incorrectly rewrite the address of a global memory access into a local form.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955 Bug #: 50955 Summary: IVopts incorrectly rewrite the address of a global memory access into a local form. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: duyue...@gmail.com Created attachment 25686 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25686 testcase IVopts use a weird IV candidate to rewrite a memory address, after this transform, a non-local memory access have been changed to a local one, and lately it was deleted by pass_cd_dce. see http://gcc.gnu.org/ml/gcc/2011-11/msg2.html for more details.
[Bug tree-optimization/50955] IVopts incorrectly rewrite the address of a global memory access into a local form.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
--- Comment #1 from Yuehai Du duyuehai at gmail dot com 2011-11-02 05:19:24
UTC ---
gcc version r180694
Configured with: /home/croseadu/android/_src/src/gcc-src/configure
--host=i486-linux-gnu --build=i486-linux-gnu
--target=arm-none-linux-gnueabi
--prefix=/home/croseadu/android/_src/install/arm-none-linux-gnueabi
--enable-threads --disable-libmudflap --disable-libssp
--disable-libstdcxx-pch --with-gnu-as --with-gnu-ld
--enable-languages=c,c++ --enable-shared --enable-symvers=gnu
--enable-__cxa_atexit
--with-specs='%{funwind-tables|fno-unwind-tables|mabi=*|ffreestanding|nostdlib:;:-funwind-tables}'
--disable-nls --enable-lto
--with-sysroot=/home/croseadu/android/_src/install/arm-none-linux-gnueabi/arm-none-linux-gnueabi/libc
--with-build-sysroot=/home/croseadu/android/_src/install/arm-none-linux-gnueabi/arm-none-linux-gnueabi/libc
--with-gmp=/home/croseadu/android/_src/objs/arm-none-linux-gnueabi/obj/host-libs-/usr
--with-mpfr=/home/croseadu/android/_src/objs/arm-none-linux-gnueabi/obj/host-libs-/usr
--with-ppl=/home/croseadu/android/_src/objs/arm-none-linux-gnueabi/obj/host-libs-/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic
-lm'
--with-cloog=/home/croseadu/android/_src/objs/arm-none-linux-gnueabi/obj/host-libs-/usr
--enable-cloog-backend=isl
--with-mpc=/home/croseadu/android/_src/objs/arm-none-linux-gnueabi/obj/host-libs-/usr
--enable-poison-system-directories --disable-libquadmath --enable-lto
--enable-libgomp
--with-build-time-tools=/home/croseadu/android/_src/install/arm-none-linux-gnueabi/arm-none-linux-gnueabi/bin
--with-cpu=cortex-a8 --with-float=soft
compile flags:
-O3 -mfpu=neon -mfloat-abi=softfp -mvectorize-with-neon-double
[Bug rtl-optimization/50904] Induct benchmark of polyhedron slows down when -fno-protect-parens is enabled by -Ofast.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
--- Comment #7 from Venkataramanan Kumar venkataramanan.kumar.gnu at gmail dot
com 2011-11-02 05:50:44 UTC ---
(In reply to comment #6)
I don't see why RTL invariant motion should move the one variant but not
the other. Of course this also shows that we should, after loop unrolling
on the tree level, also perform loop invariant motion again ...
The problem seems to be in RTL PRE, which hoists simple loads but not loads
that are wrapped up in a PLUS or a MINUS. Even with -fprotect-parens, load
hoisting opportunities are lost because of this.
You mean to say PRE hosits the when expression of this pattern.
(Snip)
(insn 536 533 537 14 (set (reg:V2DF 1172 [ MEM[(real(kind=8)[9] *)y2gauss] ])
(mem/c:V2DF (symbol_ref:DI (y2gauss.2335) [flags 0x2] var_decl
0x2bb09dc0 y2gauss) [8 MEM[(real(kind=8)[9] *)y2gauss]+0 S16 A256]))
induct2.f90:1662 1102 {*movv2df_internal}
(Snip)
But not of this pattern.
(Snip)
(insn 526 525 527 14 (set (reg:V2DF 1123)
(plus:V2DF (reg:V2DF 1124)
(mem/c:V2DF (symbol_ref:DI (y2gauss.2335) [flags 0x2] var_decl
0x2bb09dc0 y2gauss) [8 MEM[(real(kind=8)[9] *)y2gauss]+0 S16 A256])))
../induct2.f90:1662 1130 {*addv2df3}
(Snip)
[Bug target/50952] libquad relocation R_X86_64_32S failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50952 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-11-02 05:56:14 UTC --- (In reply to comment #4) (In reply to comment #3) It looks like a problem with libquadmath/configure. I recently updated by bleeding edge freebsd system to FreeBSD 10.0, and it looks like configure can't handle the new version number. configure:freebsd[123]*) objformat=aout ;; configure: version_type=freebsd-$objformat configure:freebsd-elf*) configure:freebsd-*) configure: freebsd2*) configure: freebsd3.[01]* | freebsdelf3.[01]*) configure: freebsd3.[2-9]* | freebsdelf3.[2-9]* | \ configure: freebsd4.[0-5] | freebsdelf4.[0-5] | freebsd4.1.1 | freebsdelf4.1.1) configure: version_type=freebsd-elf I'm suspicious that the 'freebsd[123]*) objformat=aout ;;' is now bogus. A quick hack to remove the 1 in the above line allows me to configure, build, and install gcc/gfortran. Anyone know how to fix this issue properly? Yes, just update in-tree libtool: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50952
[Bug target/50952] libquad relocation R_X86_64_32S failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50952 --- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-11-02 05:57:15 UTC --- (In reply to comment #5) (In reply to comment #4) (In reply to comment #3) Anyone know how to fix this issue properly? Yes, just update in-tree libtool: Sorry, I meant to paste this link: http://thread.gmane.org/gmane.comp.gcc.patches/250006
