[Bug c/53859] New: ICE when calculate insn latency for armv7e-m arch in O2 level
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53859
Bug #: 53859
Summary: ICE when calculate insn latency for armv7e-m arch in
O2 level
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zhuolin@arm.com
I cross built a compiler from recent trunk code for arm-none-eabi target. When
use this compiler to compile following code for armv7e-m arch, I got an
internal compiler error.
My code is simple as:
void bar (int,int,char* ,int);
void foo (char c)
{
bar (1,2,c,3 );
}
ICE is triggered by command:
build@sha-pdsh-build:$ arm-none-eabi-gcc -mthumb -march=armv7e-m -O2 -c test.c
test.c: In function 'foo':
test.c:13:1: internal compiler error: Segmentation fault
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
After I change my code to:
void bar (int,int,char* ,int);
static void foo (char c)
{
bar (1,2,c,3 );
}
This ICE is gone.
[Bug fortran/53449] [4.8 regression] fortran fails to build with LTO bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53449 --- Comment #4 from uros at gcc dot gnu.org 2012-07-05 07:22:25 UTC --- Author: uros Date: Thu Jul 5 07:22:17 2012 New Revision: 189281 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189281 Log: * expmed.c (expand_mult): Initialize coeff and is_neg. java/ChangeLog: * jcf-io.c (read_zip_member): Initialize d_stream. fortran/ChangLog: PR fortran/53449 * parse.c (gfc_parse_file): Initialize errors_before. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/java/ChangeLog trunk/gcc/java/jcf-io.c
[Bug fortran/53449] [4.8 regression] fortran fails to build with LTO bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53449 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-07/msg00145.htm ||l Resolution||FIXED --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2012-07-05 07:27:54 UTC --- Fixed.
[Bug middle-end/47298] -O3 destroys beautifully vectorized code obtained at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298 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 2012-07-05 07:36:15 UTC --- The issue is we completely unroll the innermost loop at -O3 -funroll-loops. We then vectorize the outer loop but have to peel for alignment (and are not good at seeing we run at most once there). It's not cunroll (-funroll-loops), it's cunrolli which can have adverse effects on vectorization and cannot be disabled. We run into this in Ada as well.
[Bug debug/53860] New: [4.8 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6254 with -fkeep-inline-functions -fdebug-types-section -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53860 Bug #: 53860 Summary: [4.8 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6254 with -fkeep-inline-functions -fdebug-types-section -g Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz Created attachment 27744 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27744 reduced testcase Compiler output: $ gcc -fkeep-inline-functions -fdebug-types-section -g testcase.C testcase.C:7:1: internal compiler error: in should_move_die_to_comdat, at dwarf2out.c:6254 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) bt #0 fancy_abort (file=0x13a48e0 /mnt/svn/gcc-trunk/gcc/dwarf2out.c, line=6254, function=0x13a2000 should_move_die_to_comdat) at /mnt/svn/gcc-trunk/gcc/diagnostic.c:1010 #1 0x008acdf1 in should_move_die_to_comdat (die=0x76ad42d0) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:6254 #2 break_out_comdat_types (die=Unhandled dwarf expression opcode 0xfa ) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:6568 #3 0x008d1103 in dwarf2out_finish (filename=optimized out) at /mnt/svn/gcc-trunk/gcc/dwarf2out.c:22347 #4 0x00b8c8db in compile_file () at /mnt/svn/gcc-trunk/gcc/toplev.c:598 #5 0x00b8e408 in do_compile () at /mnt/svn/gcc-trunk/gcc/toplev.c:1867 #6 toplev_main (argc=16, argv=0x7fffd6a8) at /mnt/svn/gcc-trunk/gcc/toplev.c:1943 #7 0x76f052ad in __libc_start_main () from /lib64/libc.so.6 #8 0x00592811 in _start () Tested revisions: r189247 - crash 4.7 r188682 - OK
[Bug rtl-optimization/53861] New: Assignment of an array element from pointer is not taken as ARRAY_TYPE when expand_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53861
Bug #: 53861
Summary: Assignment of an array element from pointer is not
taken as ARRAY_TYPE when expand_assignment
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zhenqiang.c...@linaro.org
In expr.c, there are comments and codes in function expand_assignment.
/* Assignment of a structure component needs special treatment
if the structure component's rtx is not simply a MEM.
Assignment of an array element at a constant index, and assignment of
an array element in an unaligned packed structure field, has the same
problem. Same for (partially) storing into a non-memory object. */
if (handled_component_p (to)
|| (TREE_CODE (to) == MEM_REF
mem_ref_refers_to_non_mem_p (to))
|| TREE_CODE (TREE_TYPE (to)) == ARRAY_TYPE)
But if an array element is accessed from a pointer, the condition check will
fail. Here is an example:
void test1( unsigned char* t, unsigned char* t1);
void test (int i, int j)
{
unsigned char *p;
unsigned char a1[16];
unsigned char a[8];
p = a;
p[1] = 1;
p[3] = 3;
a1[2] = 6;
test1(a, a1);
}
Compile it with -O2/Os. The t.c.149t.optimized is like:
;; Function test (test, funcdef_no=0, decl_uid=4059, cgraph_uid=0)
test (int i, int j)
{
unsigned char a[8];
unsigned char a1[16];
bb 2:
MEM[(unsigned char *)a + 1B] = 1;
MEM[(unsigned char *)a + 3B] = 3;
a1[2] = 6;
test1 (a, a1);
a1 ={v} {CLOBBER};
a ={v} {CLOBBER};
return;
}
The MEM_REF is not taken as an array element access. Then their address will be
simplified based on the sp during expanding. But in some targets (like ARM
THUMB1), sp can not be used in some sore instructions, we have to reset the
base address from sp before each reference.
If we take the MEM_REF as ARRAY_TYPE (by tracing its operand's TREE_TYPE, we
can find it is from ARRAY_TYPE), we can keep the index mode during expanding.
After that, if the targets support sp used in store instructions (like X86,
MIPS, ARM THUMB2 etc), fwprop1 can optimized it. Otherwise, just keep the index
mode, then we need only set the base address once.
[Bug debug/53860] [4.8 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6254 with -fkeep-inline-functions -fdebug-types-section -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53860 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/47298] -O3 destroys beautifully vectorized code obtained at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-05 08:38:05 UTC --- It's a pass ordering issue, cunrolli also can tremendously help vectorization because it enables vectorization of the loop that is then the innermost loop after unrolling. It also helps exposing redunancies as you can trivially see in SPEC CPU 2006 calculix (gfortran.dg/reassoc_4.f).
[Bug middle-end/53855] Emitting a warning for use after clobber
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53855 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-05 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-05 08:40:06 UTC --- Confirmed.
[Bug rtl-optimization/53861] Assignment of an array element from pointer is not taken as ARRAY_TYPE when expand_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53861 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-05 08:44:02 UTC --- You should be able to use index mode for expanding MEM[(unsigned char *)a + 1B] as well.
[Bug c++/53862] New: [GCC 4.7.1] sorry, unimplemented: use of 'type_pack_expansion' in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53862
Bug #: 53862
Summary: [GCC 4.7.1] sorry, unimplemented: use of
'type_pack_expansion' in template
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: likan_999.stud...@sina.com
The following code is complained by gcc 4.7.1:
[hidden]$ cat c.cpp
#include type_traits
using namespace std;
template size_t N, typename... Args
void f(Args...) {}
template size_t N, typename T, typename... Args
typename enable_ifis_scalarT::value, void::type f(T, Args...) {}
int main() {
f1(1);
}
[hidden]$ g++ -std=gnu++11 c.cpp
c.cpp: In function 'int main()':
c.cpp:12:11: sorry, unimplemented: use of 'type_pack_expansion' in template
All Possible Duplicates shown to me are in RESOLVED FIXED status, but
sorry, looks like not fixed yet. This needs to get some attention otherwise
this long standing bugs won't be fixed soon.
[Bug middle-end/47298] -O3 destroys beautifully vectorized code obtained at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298 --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-07-05 08:48:24 UTC --- It's a pass ordering issue, cunrolli also can tremendously help vectorization because it enables vectorization of the loop that is then the innermost loop after unrolling. It also helps exposing redunancies as you can trivially see in SPEC CPU 2006 calculix (gfortran.dg/reassoc_4.f). Sure, no disagreement here. But we have cases where the outer loop is trivially not vectorizable because of CFG contructs and cunrolli kills the vectorization for the 32 innermost loops... Possible stopgap measures are a switch to disable cunrolli or a no vectorize pragma on the outer loop to thwart it.
[Bug c++/53862] [GCC 4.7.1] sorry, unimplemented: use of 'type_pack_expansion' in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53862 Ke Liu likan_999.student at sina dot com changed: What|Removed |Added Severity|major |critical
[Bug c++/53862] [C++11] sorry, unimplemented: use of 'type_pack_expansion' in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53862 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Summary|[GCC 4.7.1] sorry, |[C++11] sorry, |unimplemented: use of |unimplemented: use of |'type_pack_expansion' in|'type_pack_expansion' in |template|template Severity|critical|normal
[Bug c++/53862] [C++11] sorry, unimplemented: use of 'type_pack_expansion' in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53862 --- Comment #1 from Ke Liu likan_999.student at sina dot com 2012-07-05 09:08:44 UTC --- BTW: this piece of code can be compiled successfully by clang++
[Bug c++/53862] [C++11] sorry, unimplemented: use of 'type_pack_expansion' in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53862 --- Comment #2 from Ke Liu likan_999.student at sina dot com 2012-07-05 09:10:04 UTC --- Any work around is welcome.
[Bug c++/53862] [C++11] sorry, unimplemented: use of 'type_pack_expansion' in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53862 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #3 from Daniel Krügler daniel.kruegler at googlemail dot com 2012-07-05 09:47:01 UTC --- The problem also exists for gcc 4.8.0 20120624 (experimental)
[Bug c++/53862] [C++11] sorry, unimplemented: use of 'type_pack_expansion' in template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53862
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-07-05
Ever Confirmed|0 |1
--- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-05
09:48:33 UTC ---
It compiles OK if you just change f(Args...) to f(Args...)
Reduced to remove header (and C++11) dependencies:
typedef unsigned long size_t;
templatetypename struct is_scalar { static const bool value = true; };
templatebool, typename T struct enable_if { typedef T type; };
template size_t N, typename... Args
void f(Args...) {}
template size_t N, typename T, typename... Args
typename enable_ifis_scalarT::value, void::type f(T, Args...) {}
int main() {
f1(1);
}
[Bug c++/41958] [c++0x] bogus variadic partial ordering code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41958 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2009-11-05 22:41:18 |2012-07-05 CC||redi at gcc dot gnu.org --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-05 10:10:40 UTC --- That causes G++ to get the wrong results for the last two examples in 14.5.6.2 [temp.func.order] FWIW clang++ has exactly the same behaviour as G++
[Bug middle-end/47298] -O3 destroys beautifully vectorized code obtained at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298 --- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-05 10:10:28 UTC --- I have a few patches that try to estimate CSE opportunities exposed by complete unrolling. In this case the CSE opportunity is the reduction into C(i,j) (possibly also detected by store motion later). Adding a patch to enable disabling of cunrolli (and cunroll - which you also cannot disable) would be fine, but we should keep unrolling once rolling loops early at least. Note that we should still try to fix (and are not good at seeing we run at most once there) so we avoid messing up things here. In theory the vectorizer should be fully capable of vectorizing even the unrolled loop (in this particular case) via SLP or basic-block vectorization.
[Bug middle-end/47298] -O3 destroys beautifully vectorized code obtained at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-05 10:11:55 UTC --- Oh, and you can disable cunrolli already via -fdisable-tree-cunrolli.
[Bug c++/53863] New: misleading error message for redefinitions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53863
Bug #: 53863
Summary: misleading error message for redefinitions
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akim.demai...@gmail.com
Hi,
In my opinion gcc provides a clearer error than g++ does.
$ cat fo.c
enum { a = 1 };
enum { a = 1 };
$ gcc-mp-4.7 -Wall /tmp/fo.c
/tmp/fo.c:2:8: error: redeclaration of enumerator 'a'
/tmp/fo.c:1:8: note: previous definition of 'a' was here
$ g++-mp-4.7 -Wall /tmp/fo.c
/tmp/fo.c:2:12: error: conflicting declaration 'a'
/tmp/fo.c:1:8: error: 'a' has a previous declaration as 'anonymous enum a'
(also, shouldn't it be about definition instead of declaration?
gcc has previous definition but redeclaration, while g++ has declaration
twice)
Thanks for GCC!
[Bug middle-end/47298] -O3 destroys beautifully vectorized code obtained at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47298 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-07-05 10:30:09 UTC --- Oh, and you can disable cunrolli already via -fdisable-tree-cunrolli. Indeed, I always forget that we have it in 4.7 and above.
[Bug c++/53863] misleading error message for redefinitions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53863 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-05 10:45:51 UTC --- In the words of the C++ standard a = 1 is an enumerator-definition, which declares the name a (EDG says declaration for C and C++, Clang says definition for C and C++) I think the reason for the G++ wording is that the same diagnostic is used in this case: extern int a; extern long a; t.cc:2:13: error: conflicting declaration 'long int a' t.cc:1:12: error: 'a' has a previous declaration as 'int a' And in this case they are declarations, not definitions. Interestingly the C front end gives a different diagnostic here, changing definition to declaration t.c:2:13: error: conflicting types for 'a' t.c:1:12: note: previous declaration of 'a' was here
[Bug c++/53864] New: g++ internal compiler error: Illegal instruction at AIX.5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53864 Bug #: 53864 Summary: g++ internal compiler error: Illegal instruction at AIX.5.3 Classification: Unclassified Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: cpapa...@gmail.com I will try to compile a cpp file in AIX 5.3 with gcc/g++ 4.2.0 and the following error occurs cgi_api.cpp:568: internal compiler error: Illegal instruction GNU C++ version 4.2.0 (powerpc-ibm-aix5.3.0.0) compiled by GNU C version 4.2.0. /usr/bin/g++ -o CMakeFiles/cppcms.dir/src/cgi_api.cpp.o -c /f1/users/cpap/Diafora_g/CppCMS/cppcms-1.0.1/src/cgi_api.cpp -I/f1/users/cpap/Diafora_g/CppCMS/cppcms-1.0.1/booster -I/f1/users/cpap/Diafora_g/CppCMS/cppcms-1.0.1/src -I/f1/users/cpap/Diafora_g/CppCMS/cppcms-1.0.1/private -I/f1/users/cpap/Diafora_g/CppCMS/cppcms-1.0.1/cppcms_boost -I/f1/users/cpap/Diafora_g/CppCMS/cppcms-1.0.1/build -I/f1/users/cpap/Diafora_g/CppCMS/cppcms-1.0.1/build/booster -I/f1/users/cpap/Diafora_g/CppCMS/cppcms-1.0.1 -fno-strict-aliasing -fwrapv -save-temps -v
[Bug bootstrap/52947] [4.7/4.8 Regression] bootstrap fails due to wrong include search path composition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52947 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-05 Ever Confirmed|0 |1 --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org 2012-07-05 11:42:25 UTC --- So, issue tracked down. It isn't related to the change I did for 4.7 version. At least not in a direct way. My changed fixed some issues, which now shown a hidden issue about msys' make, which changes happily arguments containing a POSIX-path to absolute DOS-style paths. By this NATIVE_SYSTEM_HEADER_DIR (which is /mingw/include) to something like 'D:/msys/mingw/include'. As native system-header-directory gets additionally prefixed by the specified sysroot, this leads to merging of two absolute DOS-style paths. So solution for this might be to redefine NATIVE_SYSTEM_HEADER_DIR within target's mingw32.h header for cases that TARGET_SYSTEM_ROOT is defined back to '/mingw/include'.
[Bug c++/53864] g++ internal compiler error: Illegal instruction at AIX.5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53864 --- Comment #1 from cpap cpapaluk at gmail dot com 2012-07-05 11:44:50 UTC --- Created attachment 27745 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27745 the preprocessed file
[Bug target/53853] FAIL: g++.dg/other/pr53811.C -std=gnu++* (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53853
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2012-07-05 12:07:31
UTC ---
It turned out that -mcmodel -fPIC also ICEd on x86_64-pc-linux-gnu.
We need additional part to handle CM_LARGE_PIC, basically:
--cut here--
@@ -33057,6 +33059,10 @@ x86_output_mi_thunk (FILE *file,
emit_jump_insn (gen_indirect_jump (fnaddr));
else
{
+ if (ix86_cmodel == CM_LARGE_PIC
+ GET_CODE (fnaddr) == SYMBOL_REF)
+fnaddr = construct_plt_address (fnaddr,
+gen_rtx_REG (Pmode, tmp_regno));
if (!sibcall_insn_operand (fnaddr, word_mode))
{
tmp = gen_rtx_REG (word_mode, tmp_regno);
--cut here--
to create:
.size _ZN12ScriptString12CreateStringEPKc,
.-_ZN12ScriptString12CreateStringEPKc
.set.LTHUNK0,_ZN12ScriptString12CreateStringEPKc
.p2align 4,,15
.globl _ZThn8_N12ScriptString12CreateStringEPKc
.type _ZThn8_N12ScriptString12CreateStringEPKc, @function
_ZThn8_N12ScriptString12CreateStringEPKc:
.LFB1:
.cfi_startproc
subq$8, %rdi
movabsq $.LTHUNK0@PLTOFF, %r10
addq%rbx, %r10
jmp *%r10
.cfi_endproc
I'd like to ask Jakub fo opinion here. The generated code otherwise works OK
for a couple of tests (g++.dg/inherit/thunk*.C) when compiled with
-mcmodel=large -fPIC.
[Bug target/53853] FAIL: g++.dg/other/pr53811.C -std=gnu++* (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53853 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-07-05 12:09:36 UTC --- Created attachment 27746 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27746 Patch to fix the ICE with -fPIC The complete patch in testing.
[Bug middle-end/53865] New: [4.8 Regression] 176.gcc in SPEC CPU 2000 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53865 Bug #: 53865 Summary: [4.8 Regression] 176.gcc in SPEC CPU 2000 failed to build with LTO Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 189277 gave: gcc -m32 -O3 -funroll-loops -msse2 -mfpmath=sse -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin c-parse.o c-lang.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-iterate.o toplev.o version.o tree.o print-tree.o stor-layout.o fold-const.o function.o stmt.o expr.o calls.o expmed.o explow.o optabs.o varasm.o rtl.o print-rtl.o rtlanal.o emit-rtl.o real.o dbxout.o sdbout.o dwarfout.o xcoffout.o integrate.o jump.o cse.o loop.o unroll.o flow.o stupid.o combine.o regclass.o local-alloc.o global.o reload.o reload1.o caller-save.o insn-peep.o reorg.o sched.o final.o recog.o reg-stack.o insn-opinit.o insn-recog.o insn-extract.o insn-output.o insn-emit.o insn-attrtab.o m88k.o getpwd.o convert.o bc-emit.o bc-optab.o obstack.o -lm -o cc1 ... In file included from :90:0: dwarfout.c: In function 'output_enumeration_type_die': dwarfout.c:3116:1: internal compiler error: Aborted output_enumeration_type_die (arg) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [/tmp/cc20jqbM.ltrans6.ltrans.o] Error 1
[Bug middle-end/53865] [4.8 Regression] 176.gcc in SPEC CPU 2000 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53865 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-05 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-05 13:33:59 UTC --- dwarfout.c:3116:1: internal compiler error: Aborted we usually do not abort - instead this looks like gmp/mpfr crashing?
[Bug bootstrap/53866] New: [4.8 Regression] c/c-parser.c:6891:16: error: \u2018origtypes\u2019 may be used uninitialized in this function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53866 Bug #: 53866 Summary: [4.8 Regression] c/c-parser.c:6891:16: error: \u2018origtypes\u2019 may be used uninitialized in this function Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com On Linux/ia32, revision 189288 gave /export/build/gnu/gcc-lto-32bit/build-i686-linux/./prev-gcc/g++ -B/export/build/gnu/gcc-lto-32bit/build-i686-linux/./prev-gcc/ -B/usr/gcc-4.8.0/i686-linux/bin/ -nostdinc++ -B/export/build/gnu/gcc-lto-32bit/build-i686-linux/prev-i686-linux/libstdc++-v3/src/.libs -B/export/build/gnu/gcc-lto-32bit/build-i686-linux/prev-i686-linux/libstdc++-v3/libsupc++/.libs -I/export/build/gnu/gcc-lto-32bit/build-i686-linux/prev-i686-linux/libstdc++-v3/include/i686-linux -I/export/build/gnu/gcc-lto-32bit/build-i686-linux/prev-i686-linux/libstdc++-v3/include -I/export/gnu/import/git/gcc/libstdc++-v3/libsupc++ -L/export/build/gnu/gcc-lto-32bit/build-i686-linux/prev-i686-linux/libstdc++-v3/src/.libs -L/export/build/gnu/gcc-lto-32bit/build-i686-linux/prev-i686-linux/libstdc++-v3/libsupc++/.libs -c -DIN_GCC_FRONTEND -O3 -mfpmath=sse -msse2 -funroll-loops -ffast-math -flto=jobserver -frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Ic -I/export/gnu/import/git/gcc/gcc -I/export/gnu/import/git/gcc/gcc/c -I/export/gnu/import/git/gcc/gcc/../include -I/export/gnu/import/git/gcc/gcc/../libcpp/include -I/export/gnu/import/git/gcc/gcc/../libdecnumber -I/export/gnu/import/git/gcc/gcc/../libdecnumber/bid -I../libdecnumber /export/gnu/import/git/gcc/gcc/c/c-parser.c -o c/c-parser.o /export/gnu/import/git/gcc/gcc/c/c-parser.c: In function \u2018c_parser_postfix_expression_after_primary(c_parser*, unsigned int, c_expr)\u2019: /export/gnu/import/git/gcc/gcc/c/c-parser.c:6891:16: error: \u2018origtypes\u2019 may be used uninitialized in this function [-Werror=maybe-uninitialized]
[Bug bootstrap/53866] [4.8 Regression] lto-bootstrap: c/c-parser.c:6891:16: error: origtypes may be used uninitialized in this function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53866 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|[4.8 Regression]|[4.8 Regression] |c/c-parser.c:6891:16: |lto-bootstrap: |error: |c/c-parser.c:6891:16: |\u2018origtypes\u2019 may |error: origtypes may be |be used uninitialized in|used uninitialized in this |this function |function
[Bug bootstrap/53866] [4.8 Regression] lto-bootstrap: c/c-parser.c:6891:16: error: origtypes may be used uninitialized in this function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53866 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-07-05 13:53:42 UTC --- GCC was configured with BOOT_CFLAGS=-O3 -mfpmath=sse -msse2 -funroll-loops -ffast-math RUNTESTFLAGS=--target_board='unix' /export/gnu/import/git/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++,fortran i686-linux --prefix=/usr/gcc-4.8.0 --with-local-prefix=/usr/local --enable-gnu-indirect-function --with-build-config=bootstrap-lto --with-fpmath=sse I also got /export/gnu/import/git/gcc/libiberty/simple-object-mach-o.c: In function \u2018simple_object_mach_o_find_sections\u2019: /export/gnu/import/git/gcc/libiberty/simple-object-mach-o.c:653:37: error: \u2018wrapper_sect_offset\u2019 may be used uninitialized in this function [-Werror=maybe-uninitialized] secoffset = wrapper_sect_offset + subsect_offset;
[Bug debug/53860] [4.8 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6254 with -fkeep-inline-functions -fdebug-types-section -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53860 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-05 CC||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-07-05 14:00:34 UTC --- It is caused by revision 188621: http://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00531.html
[Bug tree-optimization/35292] Missing Const Prop -- union fields
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35292
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work||4.7.0
Resolution||FIXED
Target Milestone|--- |4.7.0
Known to fail||4.6.4
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-05
14:05:00 UTC ---
This is fixed in 4.7, done by FRE1:
Replaced u.cc.c[0] with 20 in D.1722_1 = u.cc.c[0];
Replaced (int) D.1722_1 with 20 in D.1723_2 = (int) D.1722_1;
Replaced u.cc.c[1] with 0 in D.1724_3 = u.cc.c[1];
Replaced (int) D.1724_3 with 0 in D.1725_4 = (int) D.1724_3;
Replaced D.1723_2 + D.1725_4 with 20 in D.1721_5 = D.1723_2 + D.1725_4;
foo (int i)
{
int D.1725;
char D.1724;
int D.1723;
char D.1722;
int D.1721;
bb 2:
u.ii = 20;
D.1722_1 = 20;
D.1723_2 = 20;
D.1724_3 = 0;
D.1725_4 = 0;
D.1721_5 = 20;
return D.1721_5;
}
[Bug target/53853] FAIL: g++.dg/other/pr53811.C -std=gnu++* (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53853 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-07-05 14:07:00 UTC --- The patch in comment #3 fixes the PR. Full regstrapping scheduled for tonight.
[Bug bootstrap/53866] [4.8 Regression] lto-bootstrap: c/c-parser.c:6891:16: error: origtypes may be used uninitialized in this function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53866 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-07-05 14:10:28 UTC --- Also /export/gnu/import/git/gcc/gcc/bitmap.c:576:8: error: \u2018in_ready.indx\u2019 may be used uninitialized in this function [-Werror=maybe-uninitialized] else if (head-indx / 2 indx) ^ In file included from /export/gnu/import/git/gcc/gcc/emit-rtl.c:6649:0, from /export/gnu/import/git/gcc/gcc/config/i386/i386.md:3788, from :6102: /export/gnu/import/git/gcc/gcc/haifa-sched.c:7586:15: note: \u2018in_ready.indx\u2019 was declared here bitmap_head in_ready; ^ lto1: all warnings being treated as errors make[5]: *** [/tmp/ccS5gs1T.ltrans9.ltrans.o] Error 1
[Bug lto/45089] -Os -g -fwhopr dwarf2out ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45089 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-05 14:18:40 UTC --- Assuming fixed.
[Bug bootstrap/53866] [4.8 Regression] lto-bootstrap: c/c-parser.c:6891:16: error: origtypes may be used uninitialized in this function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53866 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-07-05 14:43:48 UTC --- The problem seems LTO + O3, which leads many -Werror=maybe-uninitialized error.
[Bug middle-end/50708] Infinite loop between rshift_double and lshift_double if count is LONG_MIN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50708 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #10 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-05 14:55:41 UTC --- Anyway, fixed for 4.8.
[Bug target/53789] ICE in gen_reg_rtx, at emit-rtl.c:864/865 when compiling GNU MPFR on parisc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53789 --- Comment #2 from Vincent Lefèvre vincent-gcc at vinc17 dot net 2012-07-05 14:55:52 UTC --- (In reply to comment #1) Please try with a version of GCC that is still maintained. This is currently not possible due to bug 53270.
[Bug target/53789] ICE in gen_reg_rtx, at emit-rtl.c:864/865 when compiling GNU MPFR on parisc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53789 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-05 15:12:02 UTC --- You can use trunk or the tip of the 4.7 branch.
[Bug fortran/53732] [4.7/4.8 Regression] mismatching comparison operand types on compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53732 --- Comment #9 from Mikael Morin mikael at gcc dot gnu.org 2012-07-05 15:18:30 UTC --- Author: mikael Date: Thu Jul 5 15:18:26 2012 New Revision: 189292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189292 Log: fortran/ PR fortran/53732 * trans-array.c (gfc_add_loop_ss_code): Disable self recursive calls handling nested loop(s) if the subscript flag is true. testsuite/ PR fortran/53732 * gfortran.dg/inline_sum_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/inline_sum_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug target/53789] ICE in gen_reg_rtx, at emit-rtl.c:864/865 when compiling GNU MPFR on parisc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53789 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-05 15:21:31 UTC --- Or IIRC build with --disable-threads
[Bug fortran/53818] -finit-local-zero -fno-automatic: Function result cannot have initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53818 --- Comment #5 from johnjohn j.moyard at voila dot fr 2012-07-05 16:32:44 UTC --- (In reply to comment #3) (In reply to comment #0) But when I integrate '-fno-automatic' option, I obtain this error message : function testing(date1, date2) result(test) 1 Error: Function result 'test' at (1) cannot have an initializer I helps if you tell up all options. The issue seemingly only occurs with -fno-automatic *and* -finit-local-zero (or -finit-logical=true|false). Two things surprise me: a) Why are there two initializer, when looking at the dump (-fdump-tree-original). (Requires that one does not have -fno-automatic) - the should be only one, shouldn't it? b) Why does this only trigger with -fno-automatic? The code currently has the following. At a glance, it should always trigger and the apply_default_init_local should be after the checks (together with the simplify): resolve_fl_variable (gfc_symbol *sym, int mp_flag) ... if (sym-value == NULL sym-attr.referenced) apply_default_init_local (sym); /* Try to apply a default initialization. */ ... /* Reject illegal initializers. */ if (!sym-mark sym-value) ... else if (sym-attr.result) gfc_error (Function result '%s' at %L cannot have an initializer, sym-name, sym-declared_at); Yes in fact, I use finit-local with fno-automatic!
[Bug rtl-optimization/49891] [4.7 regression] ICE in redirect_jump_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49891 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-05 16:45:29 UTC --- Author: ramana Date: Thu Jul 5 16:45:18 2012 New Revision: 189294 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189294 Log: 2012-07-05 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/49891 PR target/51980 * gcc/testsuite/gcc.target/arm/neon/vtrnf32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vtrns32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vtrnu32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzipf32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzips32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzipu32.c: Update. 2012-07-05 Ramana Radhakrishnan ramana.radhakrish...@linaro.org Julian Brown jul...@codesourcery.com PR target/49891 PR target/51980 * config/arm/neon-gen.ml (return_by_ptr): Delete. (print_function): Handle empty strings. (return): Delete use of return_by_ptr. (mask_shape_for_shuffle): New function. (mask_elems): Likewise. (shuffle_fn): Likewise. (params): Simplify and remove use of return_by_ptr. (get_shuffle): New function. (print_variant): Update. * config/arm/neon.ml (rev_elems): New function. (permute_range): Likewise. (zip_range): Likewise. (uzip_range): Likewise. (trn_range): Likewise. (zip_elems): Likewise. (uzip_elems): Likewise. (trn_elems): Likewise. (features): New enumeration Use_shuffle. Delete ReturnPtr. (pf_su_8_16): New. (suf_32): New. (ops): Update entries for Vrev64, Vrev32, Vrev16, Vtr, Vzip, Vuzp. * config/arm/arm_neon.h: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm_neon.h trunk/gcc/config/arm/neon-gen.ml trunk/gcc/config/arm/neon.ml trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/neon/vtrnf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vtrns32.c trunk/gcc/testsuite/gcc.target/arm/neon/vtrnu32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzipf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzips32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzipu32.c
[Bug target/51980] ARM - Neon code polluted by useless stores to the stack with vuzpq / vzipq / vtrnq
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51980 --- Comment #6 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-05 16:45:32 UTC --- Author: ramana Date: Thu Jul 5 16:45:18 2012 New Revision: 189294 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189294 Log: 2012-07-05 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/49891 PR target/51980 * gcc/testsuite/gcc.target/arm/neon/vtrnf32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vtrns32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vtrnu32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzipf32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzips32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzipu32.c: Update. 2012-07-05 Ramana Radhakrishnan ramana.radhakrish...@linaro.org Julian Brown jul...@codesourcery.com PR target/49891 PR target/51980 * config/arm/neon-gen.ml (return_by_ptr): Delete. (print_function): Handle empty strings. (return): Delete use of return_by_ptr. (mask_shape_for_shuffle): New function. (mask_elems): Likewise. (shuffle_fn): Likewise. (params): Simplify and remove use of return_by_ptr. (get_shuffle): New function. (print_variant): Update. * config/arm/neon.ml (rev_elems): New function. (permute_range): Likewise. (zip_range): Likewise. (uzip_range): Likewise. (trn_range): Likewise. (zip_elems): Likewise. (uzip_elems): Likewise. (trn_elems): Likewise. (features): New enumeration Use_shuffle. Delete ReturnPtr. (pf_su_8_16): New. (suf_32): New. (ops): Update entries for Vrev64, Vrev32, Vrev16, Vtr, Vzip, Vuzp. * config/arm/arm_neon.h: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm_neon.h trunk/gcc/config/arm/neon-gen.ml trunk/gcc/config/arm/neon.ml trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/neon/vtrnf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vtrns32.c trunk/gcc/testsuite/gcc.target/arm/neon/vtrnu32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzipf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzips32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzipu32.c
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 --- Comment #12 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-05 16:56:23 UTC --- Author: ramana Date: Thu Jul 5 16:56:15 2012 New Revision: 189295 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189295 Log: Correct bug number to PR target/48941 First part of the fix . Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/49891] [4.7 regression] ICE in redirect_jump_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49891 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-05 16:56:53 UTC --- (In reply to comment #3) Author: ramana Date: Thu Jul 5 16:45:18 2012 New Revision: 189294 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189294 Log: 2012-07-05 Ramana Radhakrishnan ramana.radhakrish...@linaro.org PR target/49891 This should have been PR target/48941 . PR target/51980 * gcc/testsuite/gcc.target/arm/neon/vtrnf32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vtrns32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vtrnu32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzipf32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzips32.c: Update. * gcc/testsuite/gcc.target/arm/neon/vzipu32.c: Update. 2012-07-05 Ramana Radhakrishnan ramana.radhakrish...@linaro.org Julian Brown jul...@codesourcery.com PR target/49891 PR target/51980 * config/arm/neon-gen.ml (return_by_ptr): Delete. (print_function): Handle empty strings. (return): Delete use of return_by_ptr. (mask_shape_for_shuffle): New function. (mask_elems): Likewise. (shuffle_fn): Likewise. (params): Simplify and remove use of return_by_ptr. (get_shuffle): New function. (print_variant): Update. * config/arm/neon.ml (rev_elems): New function. (permute_range): Likewise. (zip_range): Likewise. (uzip_range): Likewise. (trn_range): Likewise. (zip_elems): Likewise. (uzip_elems): Likewise. (trn_elems): Likewise. (features): New enumeration Use_shuffle. Delete ReturnPtr. (pf_su_8_16): New. (suf_32): New. (ops): Update entries for Vrev64, Vrev32, Vrev16, Vtr, Vzip, Vuzp. * config/arm/arm_neon.h: Regenerate. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm_neon.h trunk/gcc/config/arm/neon-gen.ml trunk/gcc/config/arm/neon.ml trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/neon/vtrnf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vtrns32.c trunk/gcc/testsuite/gcc.target/arm/neon/vtrnu32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzipf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzips32.c trunk/gcc/testsuite/gcc.target/arm/neon/vzipu32.c
[Bug target/48941] [arm gcc] NEON: Stack pointer operations performed even tho stack is not accessed at all in function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48941 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #13 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2012-07-05 17:01:39 UTC --- (In reply to comment #12) fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=189294
[Bug c++/53039] [4.7/4.8 Regression] including functional breaks std::is_convertible with template-pack expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org |
[Bug middle-end/53865] [4.8 Regression] 176.gcc in SPEC CPU 2000 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53865 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2012-07-05 17:21:09 UTC --- Created attachment 27747 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27747 A testcase (gdb) r -quiet -dumpdir ./ -dumpbase cc1.ltrans6 -mfpmath=sse -mtune=generic -march=x86-64 -m32 -msse2 -mfpmath=sse -mtune=generic -march=x86-64 -auxbase-strip cc1.ltrans6.ltrans.o -O3 -version -funroll-loops -ffast-math -fwhole-program -fuse-linker-plugin -fltrans cc1.ltrans6.o -o cc1.ltrans6.s Starting program: /export/build/gnu/gcc/build-x86_64-linux/gcc/lto1 -quiet -dumpdir ./ -dumpbase cc1.ltrans6 -mfpmath=sse -mtune=generic -march=x86-64 -m32 -msse2 -mfpmath=sse -mtune=generic -march=x86-64 -auxbase-strip cc1.ltrans6.ltrans.o -O3 -version -funroll-loops -ffast-math -fwhole-program -fuse-linker-plugin -fltrans cc1.ltrans6.o -o cc1.ltrans6.s GNU GIMPLE (GCC) version 4.8.0 20120705 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.3 20120306 (Red Hat 4.6.3-2), GMP version 4.3.2, MPFR version 3.0.1, MPC version 0.8.3-dev GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU GIMPLE (GCC) version 4.8.0 20120705 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.6.3 20120306 (Red Hat 4.6.3-2), GMP version 4.3.2, MPFR version 3.0.1, MPC version 0.8.3-dev GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Program received signal SIGABRT, Aborted. 0x0035a6a352f5 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x0035a6a352f5 in raise () from /lib64/libc.so.6 #1 0x0035a6a36c0b in abort () from /lib64/libc.so.6 #2 0x0119cd71 in htab_clear_slot (htab=0x71b948c0, slot=0x0) at /export/gnu/import/git/gcc/libiberty/hashtab.c:756 #3 0x00a4c576 in remove_referenced_var (var=0x70fbb3c0) at /export/gnu/import/git/gcc/gcc/tree-dfa.c:605 #4 0x00b785f1 in remove_unused_locals () at /export/gnu/import/git/gcc/gcc/tree-ssa-live.c:834 #5 0x0090e13e in execute_function_todo (data=0x208a24) at /export/gnu/import/git/gcc/gcc/passes.c:1793 #6 0x0090dbcb in do_per_function ( callback=0x90e034 execute_function_todo, data=0x208a24) at /export/gnu/import/git/gcc/gcc/passes.c:1646 #7 0x0090e2a8 in execute_todo (flags=2132516) at /export/gnu/import/git/gcc/gcc/passes.c:1842 #8 0x0090e6f1 in execute_one_ipa_transform_pass (node=0x715e7ea0, ipa_pass=0x17ba300) at /export/gnu/import/git/gcc/gcc/passes.c:2020 #9 0x0090e7a1 in execute_all_ipa_transforms () at /export/gnu/import/git/gcc/gcc/passes.c:2045 #10 0x005826ae in expand_function (node=0x715e7ea0) at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1608 #11 0x00582d98 in expand_all_functions () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:1720 ---Type return to continue, or q return to quit--- #12 0x005838b0 in compile () at /export/gnu/import/git/gcc/gcc/cgraphunit.c:2018 #13 0x004b9d43 in lto_main () at /export/gnu/import/git/gcc/gcc/lto/lto.c:2120 #14 0x00a033db in compile_file () at /export/gnu/import/git/gcc/gcc/toplev.c:550 #15 0x00a05370 in do_compile () at /export/gnu/import/git/gcc/gcc/toplev.c:1867 #16 0x00a054e0 in toplev_main (argc=26, argv=0x7fffe1b8) at /export/gnu/import/git/gcc/gcc/toplev.c:1943 #17 0x01133bcc in main (argc=26, argv=0x7fffe1b8) at /export/gnu/import/git/gcc/gcc/main.c:36 (gdb) f 3 #3 0x00a4c576 in remove_referenced_var (var=0x70fbb3c0) at /export/gnu/import/git/gcc/gcc/tree-dfa.c:605 605 htab_clear_slot (gimple_referenced_vars (cfun), loc); (gdb) p loc $1 = (void **) 0x0 (gdb)
[Bug middle-end/53865] [4.8 Regression] 176.gcc in SPEC CPU 2000 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53865 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-07-05 17:33:29 UTC --- abort comes from htab_clear_slot in libiberty/hashtab.c.
[Bug bootstrap/53866] [4.8 Regression] lto-bootstrap failed at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53866 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Summary|[4.8 Regression]|[4.8 Regression] |lto-bootstrap: |lto-bootstrap failed at -O3 |c/c-parser.c:6891:16: | |error: origtypes may be | |used uninitialized in this | |function| --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-07-05 18:04:08 UTC --- This is triggered by -O3 when GCC is configured with BOOT_CFLAGS=-O3 /export/gnu/import/git/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-languages=c,c++,fortran --prefix=/usr/gcc-4.8.0 --with-local-prefix=/usr/local --enable-gnu-indirect-function --with-build-config=bootstrap-lto --with-fpmath=sse
[Bug c++/50852] [4.6/4.7/4.8 Regression] ICE: internal compiler error: in tsubst, at cp/pt.c:11030
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50852 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added AssignedTo|dodji at gcc dot gnu.org|jason at gcc dot gnu.org --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2012-07-05 18:05:21 UTC --- Trying a different approach.
[Bug target/53833] m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833 --- Comment #1 from Larry Baker baker at usgs dot gov 2012-07-05 18:07:48 UTC --- I didn't try to figure out why the code in libgcc/config/m68k/linux-atomic.c is causing the GCC 4.7.1 xgcc cross compiler to fail. I just patched libgcc/config.host to disable atomic builtins when compiling for Motorola m68k/ColdFire running uClinux with uClibc: --- gcc-4.7.1/libgcc/config.host.orig2012-04-30 10:39:57.0 -0700 +++ gcc-4.7.1/libgcc/config.host2012-07-05 00:01:17.0 -0700 @@ -710,3 +710,3 @@ m68k-*-uclinux*)# Motorola m68k/ColdFire running uClinux with uClibc -tmake_file=$tmake_file m68k/t-floatlib m68k/t-linux +tmake_file=$tmake_file m68k/t-floatlib md_unwind_header=m68k/linux-unwind.h Someone still needs to figure out why the implementation fails for m68k-uclinux --with-arch=cf.
[Bug c++/53039] [4.7/4.8 Regression] including functional breaks std::is_convertible with template-pack expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039 --- Comment #15 from Jason Merrill jason at gcc dot gnu.org 2012-07-05 19:39:07 UTC --- Author: jason Date: Thu Jul 5 19:39:01 2012 New Revision: 189298 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189298 Log: PR c++/50852 PR c++/53039 * tree.c (strip_typedefs_expr): New. * cp-tree.h: Declare it. * pt.c (convert_template_argument, unify): Use it. * parser.c (cp_parser_template_declaration_after_export): Don't call fixup_template_parms. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic133.C trunk/gcc/testsuite/g++.dg/template/typedef39.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/param1.C
[Bug c++/50852] [4.6/4.7/4.8 Regression] ICE: internal compiler error: in tsubst, at cp/pt.c:11030
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50852 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2012-07-05 19:39:07 UTC --- Author: jason Date: Thu Jul 5 19:39:01 2012 New Revision: 189298 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189298 Log: PR c++/50852 PR c++/53039 * tree.c (strip_typedefs_expr): New. * cp-tree.h: Declare it. * pt.c (convert_template_argument, unify): Use it. * parser.c (cp_parser_template_declaration_after_export): Don't call fixup_template_parms. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic133.C trunk/gcc/testsuite/g++.dg/template/typedef39.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/param1.C
[Bug c++/50852] [4.6/4.7 Regression] ICE: internal compiler error: in tsubst, at cp/pt.c:11030
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50852 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] ICE: |ICE: internal compiler |internal compiler error: in |error: in tsubst, at|tsubst, at cp/pt.c:11030 |cp/pt.c:11030 | --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2012-07-05 19:42:58 UTC --- Fixed on trunk for now.
[Bug middle-end/53864] g++ internal compiler error: Illegal instruction at AIX.5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53864 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c++ |middle-end Severity|critical|normal --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-07-05 21:15:00 UTC --- Have you tried a newer GCC? Since 4.2.0 is no longer supported.
[Bug c++/53039] [4.7/4.8 Regression] including functional breaks std::is_convertible with template-pack expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org 2012-07-05 21:24:43 UTC --- Author: jason Date: Thu Jul 5 21:24:33 2012 New Revision: 189305 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189305 Log: PR c++/53039 * pt.c (arg_from_parm_pack_p): Go back to using same_type_p or cp_tree_equal. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #17 from JTappin jtappin at gmail dot com 2012-07-05 23:03:00 UTC --- Created attachment 27748 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27748 Testcase for List-directed read By default gtk_init calls setlocale, so if the locale is set to one that uses comma for decimal, the attached code fails to read the numbers after the decimal in the case with the point. However neither before or after is the cases with the comma handled as a decimal: james@amarice-4 Dev $ export LC_ALL=de_DE.UTF8 james@amarice-4 Dev $ ./a.out 100.34560 100.0 100.0 100.0 james@amarice-4 Dev $ export LC_ALL= james@amarice-4 Dev $ ./a.out 100.34560 100.0 100.34560 100.0 james@amarice-4 Dev $ N.B. I do have a work-around for gtk-fortran by adding a call to gtk_disable_setlocale, which I will add to the gtk_init routine.
[Bug fortran/53867] New: Probably a bogus warning on types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53867 Bug #: 53867 Summary: Probably a bogus warning on types Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fkrogh#g...@mathalacarte.com Created attachment 27749 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27749 Compiling the attachment gives the error message Attached is a 9 line file which gives the following diagnostic EnumKind.f90:7.19: integer(k) :: C 1 Warning: Component 'c' in derived type 't' at (1) may not be C interoperable, even though derived type 't' is BIND(C) The NAG and Intel compilers (I have been told) don't give any such warning.
[Bug c++/53039] [4.7 Regression] including functional breaks std::is_convertible with template-pack expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53039 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8 Regression]|[4.7 Regression] including |including functional |functional breaks |breaks std::is_convertible |std::is_convertible with |with template-pack |template-pack expansion |expansion | --- Comment #17 from Jason Merrill jason at gcc dot gnu.org 2012-07-06 01:34:09 UTC --- Fixed on trunk.
[Bug target/53447] missed optimization of 64bit ALU operation with small constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53447 Carrot carrot at google dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Carrot carrot at google dot com 2012-07-06 02:22:58 UTC --- Fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=189102.
[Bug c++/53868] New: Temporary for indirect binding is not destroyed when destructor from initializer temp throws
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53868
Bug #: 53868
Summary: Temporary for indirect binding is not destroyed when
destructor from initializer temp throws
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
The temporary created for indirect binding should be completely constructed
(and from the output _it is_) before the destructors for temporaries in the
initializer are called.
In the following case, the destructor for a temporary in the initializer throws
an int. During stack unwinding, it seems the temporary bound to the reference
is missed.
### Self-contained source: cat tempbindIndirect_inittempDtorThrows.cpp
extern C int printf(const char *, ...);
extern C void abort();
struct SubobjectInA {
SubobjectInA();
~SubobjectInA();
};
struct A : SubobjectInA {
A() = delete;
A(const A ) = delete;
A(A ) { }
A(int);
~A();
};
#define TRACE_FUNC( ... ) \
{ printf(%s\n, __PRETTY_FUNCTION__); __VA_ARGS__ }
struct Q {
Q() : q(0) TRACE_FUNC()
~Q();
int q;
};
int main() {
try { const A a = Q().q; }
catch (...) { return 0; }
abort();
}
SubobjectInA::SubobjectInA() TRACE_FUNC()
SubobjectInA::~SubobjectInA() TRACE_FUNC()
A::A(int) TRACE_FUNC()
A::~A() TRACE_FUNC()
Q::~Q() TRACE_FUNC( throw 0; )
### Compiler invocation:
g++-4.7.0 -std='c++11' tempbindIndirect_inittempDtorThrows.cpp -o test
### Compiler output:
(return code 0)
### Output from resulting executable: ./test ; echo rc=$?
Q::Q()
SubobjectInA::SubobjectInA()
A::A(int)
Q::~Q()
rc=0
### Expected output:
Q::Q()
SubobjectInA::SubobjectInA()
A::A(int)
Q::~Q()
A::~A()
SubobjectInA::~SubobjectInA()
rc=0
### gcc -v output: g++-4.7.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.7.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ../gcc-4.7.0/configure --prefix=/data/gcc
--program-suffix=-4.7.0 --disable-libssp --disable-libgcj
--enable-version-specific-runtime-libs --with-cpu=default32 --enable-secureplt
--with-long-double-128 --enable-shared --enable-__cxa_atexit
--enable-threads=posix --enable-languages=c,c++,fortran --with-mpfr=/usr/local/
--with-mpc=/usr/local/ --with-gmp=/usr/local/
Thread model: posix
gcc version 4.7.0 (GCC)
[Bug middle-end/53864] g++ internal compiler error: Illegal instruction at AIX.5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53864 --- Comment #3 from cpap cpapaluk at gmail dot com 2012-07-06 05:55:46 UTC --- (In reply to comment #2) Have you tried a newer GCC? Since 4.2.0 is no longer supported. No. Should I go to newer version of gcc/g++ or an older one? Can you please suggest me a couple of official site that I could download rpm for AIX? Is there any other compiler option that could provide more information? Thank you
