[Bug target/60062] [4.7/4.9 Regression] wrong code (for code with the optimize attribute) at -O1 and above on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60062 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32043 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32043action=edit gcc49-pr60062.patch The problem is that !!optimize determines calling convention on i?86 -m32 in some cases, but for calling conventions the caller and callee obviously have to agree on that, but !!optimize when optimize attribute comes into the picture is whether the current function is optimized. So, on the testcase, it is true for the callee and false for the caller. The attached untested patch fixes that by considering whether the callee is optimized instead.
[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660 Thomas Martitz kugel at rockbox dot org changed: What|Removed |Added CC||kugel at rockbox dot org --- Comment #23 from Thomas Martitz kugel at rockbox dot org --- Which release is the first to ship and was it backported? I experience this bug in an old 4.4.6 armeabi gcc.
[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660 --- Comment #24 from Thomas Martitz kugel at rockbox dot org --- Alright, looking at the revision history it appears to me that the GCC 4.6 series ship the fix and it was not backported to 4.4 (although 4.4.7 was released months after this patch hit svn trunk) or 4.5.
[Bug ipa/60072] New: wrong code (for code with an optimize attribute) at -O0 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60072
Bug ID: 60072
Summary: wrong code (for code with an optimize attribute) at
-O0 on x86_64-linux-gnu in 32-bit mode
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The current gcc trunk (as well as all earlier versions from 4.6.x to 4.8.x)
miscompiles the following code with an optimize attribute on x86_64-linux at
-O0 in 32-bit mode (but not 64-bit).
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20140204 (experimental) [trunk revision 207486] (GCC)
$
$ gcc-trunk -m32 -O1 small.c; a.out
$ gcc-trunk -m64 -O0 small.c; a.out
$
$ gcc-trunk -m32 -O0 small.c; a.out
Segmentation fault (core dumped)
$ gcc-4.8.2 -m32 -O0 small.c; a.out
Segmentation fault (core dumped)
$ gcc-4.7.3 -m32 -O0 small.c; a.out
Segmentation fault (core dumped)
$ gcc-4.6.4 -m32 -O0 small.c; a.out
Segmentation fault (core dumped)
$
---
int i, *a = i, **b = a, c, d, **e = a;
__attribute__ ((optimize (1)))
static int *foo (int *p)
{
*e = p;
return 0;
}
int
main ()
{
foo (c);
d 1 **b;
return 0;
}
[Bug c/59193] Unused postfix operator temporaries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID
[Bug fortran/60066] Bad elemental invocation of non-scalar base object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- I have applied the patch at http://gcc.gnu.org/ml/fortran/2014-02/txtX3eVILZEGw.txt on top of 4.8.3 r206497 and the test runs successfully (so it fixed on trunk by r207389).
[Bug ipa/60072] wrong code (for code with an optimize attribute) at -O0 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60072 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Seems to be a dup of PR60062. *** This bug has been marked as a duplicate of bug 60062 ***
[Bug target/60062] [4.7/4.9 Regression] wrong code (for code with the optimize attribute) at -O1 and above on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60062 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- *** Bug 60072 has been marked as a duplicate of this bug. ***
[Bug target/60071] [4.9 Regression] [SH] internal compiler error: in final_scan_insn, at final.c:2963
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60071 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.9.0
[Bug lto/60061] Different dump-ipa-cp-details without/with -flto for gfortran.dg/pr53787.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60061
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-02-05
CC||jamborm at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
The dumps seem to be different for the Jump functions already. It seems that
passing -flto makes the machinery behave differently for some reason
(note this is compile-stage only so make sure to also pass -ffat-lto-objects).
Martin? Honza?
Maybe this is because of
ipa_compute_jump_functions (struct cgraph_node *node,
struct param_analysis_info *parms_ainfo)
{
struct cgraph_edge *cs;
for (cs = node-callees; cs; cs = cs-next_callee)
{
struct cgraph_node *callee = cgraph_function_or_thunk_node (cs-callee,
NULL);
/* We do not need to bother analyzing calls to unknown
functions unless they may become known during lto/whopr. */
if (!callee-definition !flag_lto)
continue;
? Or other flag_lto tests? Or maybe this is just because -fwhole-program
is interpreted differently when used with/without -flto? Indeed the
actual transforms of -flto -fwhole-program match those of -fno-lto
-fno-whole-program.
[Bug fortran/60060] [4.9 Rgression] lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60060 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-05 Component|debug |fortran Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug fortran/60066] Bad elemental invocation of non-scalar base object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I have applied the patch at
http://gcc.gnu.org/ml/fortran/2014-02/txtX3eVILZEGw.txt
on top of 4.8.3 r206497 and the test runs successfully ...
Marking as duplicate of pr49906.
Paul,
For the record, no regression when testing with
make -k -j8 check-gfortran RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
*** This bug has been marked as a duplicate of bug 49906 ***
[Bug debug/49906] wrong .debug_line for -O0 -g prologue skip
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49906 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||fmartinez at gmv dot com --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 60066 has been marked as a duplicate of this bug. ***
[Bug middle-end/37921] __builtin_constant_p seems to be giving false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37921 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Seems to be fixed a long time ago.
[Bug fortran/59906] [4.7/4.8 Regression] error: size of variable 'anonymous' is too large
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59906 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||fmartinez at gmv dot com --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 60066 has been marked as a duplicate of this bug. ***
[Bug fortran/60066] Bad elemental invocation of non-scalar base object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- Wrong PR in the previous post. Sorry for the noise. *** This bug has been marked as a duplicate of bug 59906 ***
[Bug debug/49906] wrong .debug_line for -O0 -g prologue skip
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49906 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 60066 has been marked as a duplicate of this bug. *** Wrong post. Sorry for the noise.
[Bug fortran/60066] Bad elemental invocation of non-scalar base object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066 --- Comment #7 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com --- The patch submission (1st February) said: That must be one of the fastest reviews on record! Committed as revision 207389 4.7 and 4.8 to follow next weekend. Given my limited time, that is as much as I can do. In any case, it has been our working convention to hold off backporting in order to expose untested regressions. Cheers Paul On 4 February 2014 22:47, dominiq at lps dot ens.fr gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-04 CC||mikael at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- This seems to have been fixed between r207387 and r207408 (r207389 or r207386). These revisions are supposed to be back ported. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug target/60071] [4.9 Regression] [SH] internal compiler error: in final_scan_insn, at final.c:2963
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60071 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- I'd say it is a backend bug. Canonicalizing (minus:SI (const_int INT_MIN)) into (const_int INT_MIN) is IMNSHO very much desirable, it is just a target bug that it matches an insn with it at the point where it no longer is able to cope with it. So, either it needs to use some predicate which will make such insn invalid right after split1, or it needs to cope also with the case where during splitting it can't create pseudos.
[Bug target/60071] [4.9 Regression] [SH] internal compiler error: in final_scan_insn, at final.c:2963
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60071 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Note the case RTX_UNARY: handling in simplify_while_replacing wasn't strictly necessary to fix the bug, so in theory that can be temporarily reverted, but that doesn't change anything on this being a target bug.
[Bug fortran/60060] [4.9 Rgression] lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60060
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
The issue is that we create the DIE for the namelist before we've emitted
DIEs for global vars. Thus we run into
static dw_die_ref
gen_namelist_decl (tree name, dw_die_ref scope_die, tree item_decls)
{
...
FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (item_decls), i, value)
{
nml_item_ref_die = lookup_decl_die (value);
if (!nml_item_ref_die)
nml_item_ref_die = force_decl_die (value);
which forces the creation of a DIE for mem_nml as context of nxc and
creates a declaration DIE of nxc in that context.
The actual AT_specification is added when we output debuginfo for mem_nml
but then again via emit_debug_global_declarations.
Without LTO we don't call dwarf2out_global_decl on mem_nml::NXC.
I believe that somehow we have to honor TREE_ASM_WRITTEN here to avoid
outputting the decl twice ...?
That said, frontends disconnect on what are globals is obviously an
area to improve upon ... as is removing the various langhooks around
this area (write_global_declarations) in the light of cgraph/varpool/symtab.
[Bug c/45152] LTO breaks C99 inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45152 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Severity|critical|normal
[Bug c/52615] function pointer casting bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52615 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- I'd say fixed by r207300.
[Bug c/59753] Missing -Woverflow warning with signed constant conversion between T_MAX+1 and UT_MAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59753 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- -Wconversion catches all of these.
[Bug middle-end/59150] [4.9 Regression] ICE: in expand_one_var, at cfgexpand.c:1242 with -fopenmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59150 Sebastian Huber sebastian.hu...@embedded-brains.de changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #5 from Sebastian Huber sebastian.hu...@embedded-brains.de --- On ARM the test case fails with an ICE: http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00211.html http://gcc.gnu.org/ml/gcc-testresults/2014-02/msg00203.html With GCC version: git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@207497 138bc75d-0d04-0410-961f-82ee72b054a4 I get the following error for target arm-rtems: spawn -ignore SIGHUP /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../xg++ -B/scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../ /home/sh/archive/gcc-git/gcc/testsuite/g++.dg/gomp/pr59150.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/scratch/git-rtems-testing/gcc/b-arm-gcc/arm-rtems4.11/libstdc++-v3/include/arm-rtems4.11 -I/scratch/git-rtems-testing/gcc/b-arm-gcc/arm-rtems4.11/libstdc++-v3/include -I/home/sh/archive/gcc-git/libstdc++-v3/libsupc++ -I/home/sh/archive/gcc-git/libstdc++-v3/include/backward -I/home/sh/archive/gcc-git/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -O -fopenmp-simd -fno-tree-ccp -fno-tree-copy-prop -fno-tree-dce -S -isystem /scratch/git-rtems-testing/gcc/b-arm-gcc/arm-rtems4.11/./newlib/targ-include -isystem /home/sh/archive/gcc-git/newlib/libc/include -B/scratch/git-rtems-testing/gcc/install-git/arm-rtems4.11/edb7312/lib/ -specs bsp_specs -qrtems -o pr59150.s *** glibc detected *** /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus: double free or corruption (fasttop): 0x01921620 *** === Backtrace: = /lib64/libc.so.6(+0x766d6)[0x7f6a40fd06d6] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z14free_data_refs3vecIP14data_reference7va_heap6vl_ptrE+0x3e)[0x101979e] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z21vect_destroy_datarefsP14_loop_vec_infoP12_bb_vec_info+0x68)[0xd36258] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z21destroy_loop_vec_infoP14_loop_vec_infob+0x17d)[0xd1939d] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z17vect_analyze_loopP4loop+0x134)[0xd20084] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z15vectorize_loopsv+0xb90)[0xd37360] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z16execute_one_passP8opt_pass+0x343)[0xa87713] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z17execute_pass_listP8opt_pass+0x16)[0xa87a06] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z17execute_pass_listP8opt_pass+0x28)[0xa87a18] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z17execute_pass_listP8opt_pass+0x28)[0xa87a18] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus[0x816963] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z7compilev+0x5f9)[0x818819] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z25finalize_compilation_unitv+0x65)[0x819085] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z28cp_write_global_declarationsv+0xf5c)[0x60613c] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus[0xb2ee8d] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus(_Z11toplev_mainiPPc+0xb22)[0xb30c02] /lib64/libc.so.6(__libc_start_main+0xed)[0x7f6a40f7b23d] /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/testsuite/g++/../../cc1plus[0x51238d] === Memory map: 0040-015ba000 r-xp 08:16 1314946 /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/cc1plus 017ba000-017bc000 r--p 011ba000 08:16 1314946 /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/cc1plus 017bc000-017c7000 rw-p 011bc000 08:16 1314946 /scratch/git-rtems-testing/gcc/b-arm-gcc/gcc/cc1plus 017c7000-0194 rw-p 00:00 0 [heap] 7f6a40944000-7f6a40959000 r-xp 08:03 131176 /lib64/libgcc_s.so.1 7f6a40959000-7f6a40b58000 ---p 00015000 08:03 131176 /lib64/libgcc_s.so.1 7f6a40b58000-7f6a40b59000 r--p 00014000 08:03 131176 /lib64/libgcc_s.so.1 7f6a40b59000-7f6a40b5a000 rw-p 00015000 08:03 131176 /lib64/libgcc_s.so.1 7f6a40b5a000-7f6a40f5a000 rw-p 00:00 0 7f6a40f5a000-7f6a410e1000 r-xp 08:03 131080 /lib64/libc-2.14.1.so 7f6a410e1000-7f6a412e ---p 00187000 08:03 131080 /lib64/libc-2.14.1.so
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #7 from Paulo J. Matos pa...@matos-sorge.com --- (In reply to Richard Biener from comment #5) Apart from expand there is the redundant-extension-elimination, ree.c. In expand we get the following gimple for the loop: ;; basic block 4, loop depth 0 ;;pred: 2 ;;4 # i_15 = PHI 0(2), i_12(4) # _18 = PHI 0(2), _4(4) _6 = arr[_18]; _7 = _6 + 1; arr[_18] = _7; _17 = (unsigned short) i_15; _13 = _17 + 1; i_12 = (short int) _13; _4 = (int) i_12; if (_4 limit_5(D)) goto bb 4; else goto bb 3; ;;succ: 4 ;;3 Where _13 is an unsigned short and what we want to eliminate is this sign extend: _4 = (int) i_12; This doesn't seem trivial in the expand phase because to eliminate the sign expand, you promote i_12 to int and have then to promote a bunch of other variables, whose insn have been already emitted when you get here. Shouldn't this be ivopts noticing that if it generates an int IV, it saves a sign extend and therefore is better?
[Bug fortran/60060] [4.9 Rgression] lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60060 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Another possibility is to simply stream the FEs idea of what is a global ...
[Bug fortran/60066] Bad elemental invocation of non-scalar base object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60066
Paul Thomas pault at gcc dot gnu.org changed:
What|Removed |Added
Resolution|DUPLICATE |FIXED
--- Comment #8 from Paul Thomas pault at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #5)
I have applied the patch at
http://gcc.gnu.org/ml/fortran/2014-02/txtX3eVILZEGw.txt
on top of 4.8.3 r206497 and the test runs successfully ...
Marking as duplicate of pr49906.
Paul,
For the record, no regression when testing with
make -k -j8 check-gfortran RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
*** This bug has been marked as a duplicate of bug 49906 ***
I will, however, add this testcase to that of PR59906 - it is different yet
again from the verification tests although it is fixed by the patch.
Cheers
Pau
[Bug c/59753] Missing -Woverflow warning with signed constant conversion between T_MAX+1 and UT_MAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59753 Vincent Lefèvre vincent-gcc at vinc17 dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME |--- --- Comment #2 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- -Wconversion is used to warn about possibly-suspicious valid code such as: unsigned ui = -1; (see the gcc man page), not for overflows. At least there is an inconsistency in the use of warnings. There is no reason why 65535 and 65536 should be treated differently when assigned to a short: neither value is representable in a short.
[Bug tree-optimization/60042] vectorizer still does too many dependence tests for himeno:jacobi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60042 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Depends on||23855 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- For analysis of the DRs in outer loops we need to fix PR23855.
[Bug target/59718] Behaviour of -mcpu documented incorrectly for ARM targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59718 --- Comment #2 from jgreenhalgh at gcc dot gnu.org --- Author: jgreenhalgh Date: Wed Feb 5 11:42:50 2014 New Revision: 207501 URL: http://gcc.gnu.org/viewcvs?rev=207501root=gccview=rev Log: [ARM Documentation] Clarify -mcpu, -mtune, -march gcc/ PR target/59718 * doc/invoke.texi (-march=): Clarify documentation for ARM. (-mtune=): Likewise. (-mcpu=): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #8 from Paulo J. Matos pa...@matos-sorge.com --- (In reply to Paulo J. Matos from comment #7) (In reply to Richard Biener from comment #5) Apart from expand there is the redundant-extension-elimination, ree.c. In expand we get the following gimple for the loop: ;; basic block 4, loop depth 0 ;;pred: 2 ;;4 # i_15 = PHI 0(2), i_12(4) # _18 = PHI 0(2), _4(4) _6 = arr[_18]; _7 = _6 + 1; arr[_18] = _7; _17 = (unsigned short) i_15; _13 = _17 + 1; i_12 = (short int) _13; _4 = (int) i_12; if (_4 limit_5(D)) goto bb 4; else goto bb 3; ;;succ: 4 ;;3 Where _13 is an unsigned short and what we want to eliminate is this sign extend: _4 = (int) i_12; This doesn't seem trivial in the expand phase because to eliminate the sign expand, you promote i_12 to int and have then to promote a bunch of other variables, whose insn have been already emitted when you get here. Shouldn't this be ivopts noticing that if it generates an int IV, it saves a sign extend and therefore is better? Made a mistake. With the attached test, the final gimple before expand for the loop basic block is: ;; basic block 5, loop depth 0 ;;pred: 5 ;;4 # i_26 = PHI i_1(5), 0(4) # ivtmp.24_18 = PHI ivtmp.24_12(5), ivtmp.24_29(4) _28 = (void *) ivtmp.24_18; _13 = MEM[base: _28, offset: 0B]; x.4_14 = x; _15 = _13 ^ x.4_14; MEM[base: _28, offset: 0B] = _15; ivtmp.24_12 = ivtmp.24_18 + 4; temp_ptr.5_17 = (Sample *) ivtmp.24_12; _11 = (unsigned short) i_26; _2 = _11 + 1; i_1 = (short int) _2; _10 = (int) i_1; if (_10 _25) goto bb 5; else goto bb 6; ;;succ: 5 ;;6 However, the point is the same. IVOPTS should probably generate an int IV instead of a short int IV to avoid the sign extend since removing the sign extend during RTL seems to be quite hard. What do you think?
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 --- Comment #9 from Paulo J. Matos pa...@matos-sorge.com --- Created attachment 32044 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32044action=edit Testcase
[Bug target/60071] [4.9 Regression] [SH] internal compiler error: in final_scan_insn, at final.c:2963
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60071 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org --- I'll have a look.
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #43 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Created attachment 32045 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32045action=edit new testcase r207489 fixes the original issue. Thanks. But llvm still doesn't build with -flto: FAILED: : /usr/bin/g++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-may be-uninitialized -Wnon-virtual-dtor -fno-rtti -O3 -DNDEBUG -pipe -march=native -flto=4 -Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=all,--icf-iterations=3 utils/ FileCheck/CMakeFiles/FileCheck.dir/FileCheck.cpp.o -o bin/FileCheck -lrt -ldl -lcurses -lpthread -lz lib/libLLVMSupport.so -lpthread -lrt -ldl -lcurses -lpthread -lz -Wl,-r path,/var/tmp/llvm_build/lib : lib/libLLVMSupport.so: error: undefined reference to 'void* llvm::object_creatorllvm::StringMapllvm::Timer, llvm::MallocAllocator ()' lib/libLLVMSupport.so: error: undefined reference to 'void* llvm::object_creatorstd::string()' lib/libLLVMSupport.so: error: undefined reference to 'void* llvm::object_creatorstd::vectorllvm::Timer*, std::allocatorllvm::Timer* ()' collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. In this case lto produces an undefined symbol for e.g.: 42902 static ManagedStaticstd::vectorTimer* ActiveTimers; Before r207489 the symbol was weak. markus@x4 llvm_build % g++ -fPIC -O3 -flto -shared Timer.ii markus@x4 llvm_build % nm a.out | grep _ZN4llvm14object_creatorISt6vectorIPNS_5TimerESaIS3_Pvv U _ZN4llvm14object_creatorISt6vectorIPNS_5TimerESaIS3_Pvv markus@x4 llvm_build % g++ -fPIC -O3 -flto -flto-partition=none -shared Timer.ii markus@x4 llvm_build % nm a.out | grep _ZN4llvm14object_creatorISt6vectorIPNS_5TimerESaIS3_Pvv 3770 W _ZN4llvm14object_creatorISt6vectorIPNS_5TimerESaIS3_Pvv markus@x4 llvm_build % g++ -fPIC -O3 -shared Timer.ii markus@x4 llvm_build % nm a.out | grep _ZN4llvm14object_creatorISt6vectorIPNS_5TimerESaIS3_Pvv 8dc0 W _ZN4llvm14object_creatorISt6vectorIPNS_5TimerESaIS3_Pvv markus@x4 llvm_build %
[Bug objc/56044] Add dialect option to gobjc to prevent instance variables from posing as local variables inside methods.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044 --- Comment #8 from Dimitris Papavasiliou dpapavas at gmail dot com --- Is there anything more I can do to help with this? Does the process simply take a lot of time or is there no interest in such a feature?
[Bug libffi/60073] New: [4.9 regression] 64-bit libffi.call/cls_double_va.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073 Bug ID: 60073 Summary: [4.9 regression] 64-bit libffi.call/cls_double_va.c FAILs on Solaris/SPARC Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: amodra at gcc dot gnu.org, ebotcazou at gcc dot gnu.org, green at gcc dot gnu.org Host: sparc*-sun-solaris2.* Target: sparc*-sun-solaris2.* Build: sparc*-sun-solaris2.* Since ca. 20131121, the 64-bit libffi.call/cls_double_va.c test FAILs on Solaris/SPARC: FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is 7.0 FAIL: libffi.call/cls_double_va.c -O2 output pattern test, is 7.0 FAIL: libffi.call/cls_double_va.c -O3 output pattern test, is 7.0 FAIL: libffi.call/cls_double_va.c -Os output pattern test, is 7.0 FAIL: libffi.call/cls_double_va.c -O2 -fomit-frame-pointer output pattern test, is 7.0 E.g. FAIL: libffi.call/cls_double_va.c -O0 -W -Wall output pattern test, is 7.0 res: 4 0.0 res: 4 , should match 7.0? res: 4? 7.0? res: 4 This is due to 2013-11-18 Alan Modra amo...@gmail.com * src/powerpc/ppc_closure.S: Don't bl .Luint128. * src/powerpc/ffitarget.h: Import from upstream. * src/powerpc/ffi.c: Likewise. * src/powerpc/linux64.S: Likewise. * src/powerpc/linux64_closure.S: Likewise. * doc/libffi.texi: Likewise. * testsuite/libffi.call/cls_double_va.c: Likewise. * testsuite/libffi.call/cls_longdouble_va.c: Likewise. Reverting the cls_double.ca change lets the testcase pass. Strangely, the cls_longdouble_va.c test still passes even with the patch, so this could indicate a bug in the libffi sparcv9 code. Rainer
[Bug libffi/60073] [4.9 regression] 64-bit libffi.call/cls_double_va.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug libffi/60073] [4.9 regression] 64-bit libffi.call/cls_double_va.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Reverting the cls_double.ca change lets the testcase pass. Strangely, the cls_longdouble_va.c test still passes even with the patch, so this could indicate a bug in the libffi sparcv9 code. Possibly, but modifying a testcase without explanation (Import from upstream doesn't say anything about what has changed) is problematic.
[Bug target/60074] New: g++.dg/vect/pr33426-ivdep-[34].cc FAIL on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60074
Bug ID: 60074
Summary: g++.dg/vect/pr33426-ivdep-[34].cc FAIL on SPARC
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
CC: ebotcazou at gcc dot gnu.org, rdsandiford at googlemail dot
com
Host: sparc*-sun-solaris2.*
Target: sparc*-sun-solaris2.*
Build: sparc*-sun-solaris2.*
This change
2014-01-30 Richard Sandiford rdsandif...@googlemail.com
* g++.dg/vect/pr33426-ivdep.cc, g++.dg/vect/pr33426-ivdep-2.cc,
g++.dg/vect/pr33426-ivdep-3.cc, g++.dg/vect/pr33426-ivdep-4.cc,
gcc.dg/vect/vect-ivdep-1.c, gcc.dg/vect/vect-ivdep-2.c: Require
vect_int rather than vect_float.
caused to new FAILs on Solaris/SPARC (both 32 and 64-bit):
FAIL: g++.dg/vect/pr33426-ivdep-3.cc (test for warnings, line )
FAIL: g++.dg/vect/pr33426-ivdep-4.cc (test for warnings, line )
This corresponds to
/* { dg-message loop vectorized { target *-*-* } 0 } */
Before, when the test required vect_float support, the test was UNSUPPORTED.
Rainer
[Bug target/60074] g++.dg/vect/pr33426-ivdep-[34].cc FAIL on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60074 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug tree-optimization/60075] New: Wrong code from loop optimizer with address-space accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60075
Bug ID: 60075
Summary: Wrong code from loop optimizer with address-space
accesses
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Created attachment 32046
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32046action=edit
loop-memx.c: C source triggering the bug
The following C code runs to abort:
== C code ==
typedef unsigned char uint8_t;
volatile uint8_t buf[12];
volatile uint8_t buf_used;
void __attribute__((noinline,noclone))
copy_string (uint8_t len, const __memx char* str)
{
uint8_t n;
for (n = 0; n len; n++)
{
if (*str != '1')
__builtin_abort();
buf[n] = *str++;
}
buf_used = len;
}
int main (void)
{
copy_string (1, 1);
return 0;
}
== Command Line ==
$ avr-gcc -mmcu=atmega128 loop-memx.c -O2 -v
== Configuration ==
It's from the current (2014-02-05) 4.7 head but the problem is also known for
official releases like 4.7.2
gcc version 4.7.4 20140205 (prerelease) [gcc-4_7-branch revision 195858] (GCC)
Target: avr
Configured with: ../../gcc.gnu.org/gcc-4_7-branch/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --with-dwarf2
--enable-languages=c,c++ --enable-target-optspace=yes --with-avrlibc=yes
[Bug tree-optimization/60075] Wrong code from loop optimizer with address-space accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60075 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||addr-space, wrong-code Target||avr Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-05 Ever confirmed|0 |1 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org --- The code is correct of -fno-ivopts or -fno-tree-loop-optimize is added to the command options. Presumably, the problem is that the __memx address space uses a 24-bit mode (PSImode) but sizetype is only 16 bits.
[Bug libffi/60073] [4.9 regression] 64-bit libffi.call/cls_double_va.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073 Alan Modra amodra at gmail dot com changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #2 from Alan Modra amodra at gmail dot com --- This is almost certainly a bug in sparc libffi. The explanation for the testcase fix went to the upstream libffi list.. This also fixes two faulty tests that used a non-variadic function cast to call a variadic function, and spuriously reasoned that this is somehow necessary for static functions.
[Bug target/60076] gcc.dg/vect/pr60012.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60076 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/60076] gcc.dg/vect/pr60012.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60076 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 32047 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32047action=edit .vect dump
[Bug target/60076] New: gcc.dg/vect/pr60012.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60076 Bug ID: 60076 Summary: gcc.dg/vect/pr60012.c FAILs on Solaris/SPARC Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org, rguenth at gcc dot gnu.org Host: sparc*-sun-solaris2.* Target: sparc*-sun-solaris2.* Build: sparc*-sun-solaris2.* The new gcc.dg/vect/pr60012.c FAILs on Solaris/SPARC, both 32 and 64-bit: FAIL: gcc.dg/vect/pr60012.c scan-tree-dump vect LOOP VECTORIZED FAIL: gcc.dg/vect/pr60012.c -flto -ffat-lto-objects scan-tree-dump vect LOOP VECTORIZED I'm attaching the .vect dump. Rainer
[Bug ipa/59469] [4.8/4.9 Regression] LLVM build failure with gcc LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59469 --- Comment #44 from Markus Trippelsdorf trippels at gcc dot gnu.org --- diff --git a/gcc/lto/lto-partition.c b/gcc/lto/lto-partition.c index da76b10511f0..e47679239d84 100644 --- a/gcc/lto/lto-partition.c +++ b/gcc/lto/lto-partition.c @@ -97,7 +97,7 @@ get_symbol_class (symtab_node *node) /* Linker discardable symbols are duplicated to every use unless they are keyed. Keyed symbols or those. */ - if (DECL_ONE_ONLY (node-decl) + if ((DECL_COMDAT (node-decl) || DECL_ONE_ONLY (node-decl)) !node-force_output !node-forced_by_abi !symtab_used_from_object_file_p (node)) fixes the issue for me. With this LLVM-3.4 now compiles fine with LTO. (LLVM trunk build still fails, but it looks like an LLVM bug to me.)
[Bug target/60077] New: [4.9 regression] gcc.target/i386/pr35767-5.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60077 Bug ID: 60077 Summary: [4.9 regression] gcc.target/i386/pr35767-5.c FAILs Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Host: i386-pc-solaris2.*, x86_64-unknown-linux-gnu, x86_64-unknown-darwin* Target: i386-pc-solaris2.*, x86_64-unknown-linux-gnu, x86_64-unknown-darwin* Build: i386-pc-solaris2.*, x86_64-unknown-linux-gnu, x86_64-unknown-darwin* Since ca. 20140124, the following testcase FAILs everywhere: FAIL: gcc.target/i386/pr35767-5.c scan-assembler-not movups This is a regression from 4.8. Rainer
[Bug target/60077] [4.9 regression] gcc.target/i386/pr35767-5.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60077 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832
Sam Kellett sam at wavestore dot com changed:
What|Removed |Added
CC||sam at wavestore dot com
--- Comment #1 from Sam Kellett sam at wavestore dot com ---
Created attachment 32048
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32048action=edit
Preprocessed source
I think this is another example of the same bug:
#include vector
struct Message
{
typedef union {
char byte;
const char *str;
} Parameter;
Parameter p1;
Parameter p2;
};
int main()
{
std::vectorMessage messages_;
messages_.push_back({{ .byte = 'a' }});
Message message = {{ .byte = 'a' }, { .str = Hello World }};
messages_.push_back(message);
messages_.push_back({{ .byte = 'a' }, { .str = Hello World }});
}
Outputs:
union.cpp: In function ‘int main()’:
union.cpp:23:66: internal compiler error: in reshape_init_class, at
cp/decl.c:5216
messages_.push_back({{ .byte = 'a' }, { .str = Hello World }});
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into /tmp/ccbxyQRY.out file, please attach this to
your bugreport.
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832 --- Comment #2 from Sam Kellett sam at wavestore dot com --- Using gcc v4.8.2 I should add...
[Bug lto/60061] Different dump-ipa-cp-details without/with -flto for gfortran.dg/pr53787.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60061 --- Comment #2 from Martin Jambor jamborm at gcc dot gnu.org --- I see init cloned in both -fwhole-program ipa-cp dumps and in WPA -flto dumps (i.e. when omitting the -S option). Apparently, when creating fat LTO object file -fwhole-program does not apply during the compilation phase (which is a bit confusing but I tend to believe it is a good thing), we thus do not know that we would clone init for all contexts and it is considered too cold for creating an extra clone (which is also a good decision). But non-lto -fwhole-program should be compared to -flto WPA stage, not fat object optimization phase (assuming it is OK that -fwhole-program in LTO only applies during the WPA phase). Yes, jump functions are different exactly because of the condition quoted above, there is little use analyzing them when they lead to something unknown that is going to stay unknown.
[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #10 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Rainer Orth from comment #9) I see the same issue on some Solaris 10/SPARC systems on UltraSPARC T2: do you use the default mutex-based implementation for lib atomic? I do, since this is the only option on SPARC. (I suspect that this is where the darwin slowness originates) if I configure --with-cpu=core2 (which allows 16b exchanges) the time drops from ~50m = 5m with the complex double tests dominating as you have. Even that seems to require ifunc support, which isn't supported on Solaris even with gld. Rainer
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855 --- Comment #27 from Richard Biener rguenth at gcc dot gnu.org --- Some more TLC to be applied before it's ready for prime time (and obviously testing). Eventually integrating with LIM sounds better?
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Attachment #11231|0 |1 is obsolete|| Assignee|rakdver at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #26 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32049 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32049action=edit updated patch Updated the patch to trunk.
[Bug preprocessor/56824] [4.8/4.9 regression] pragma GCC diagnostic push/pop fail with GCC diagnostic ignored -Waggregate-return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56824 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32050 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32050action=edit gcc49-pr56824.patch Untested fix.
[Bug tree-optimization/23855] loop header should also be pulled out of the inner loop too
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23855 --- Comment #28 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 32051 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32051action=edit updated patch Slight update to apply all possible hoists to PR60042.
[Bug middle-end/57499] [4.7/4.8/4.9 Regression] ICE when noreturn destructor returns after throw with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57499 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Feb 5 14:34:30 2014 New Revision: 207504 URL: http://gcc.gnu.org/viewcvs?rev=207504root=gccview=rev Log: PR middle-end/57499 * tree-eh.c (cleanup_empty_eh): Bail out on totally empty bb with no successors. * g++.dg/torture/pr57499.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr57499.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-eh.c
[Bug tree-optimization/60042] vectorizer still does too many dependence tests for himeno:jacobi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60042
--- Comment #9 from Richard Biener rguenth at gcc dot gnu.org ---
PR23855 fixed we'd get for the analysis of the remaining DRs in the outermost
loop
for example for matrix A:
Creating dr for *_290
analyze_innermost: success.
base_address: pretmp_1792 + (sizetype) ((long unsigned int) pretmp_1974
* 4)
offset from base address: 0
constant offset from base address: 4
step: 4
aligned to: 128
base_object: *pretmp_1792 + (sizetype) ((long unsigned int)
(((pretmp_1831 + 1) * pretmp_1794 + 1) * pretmp_1796) * 4)
Access function 0: {{{4B, +, (sizetype) ((long unsigned int)
(pretmp_1794 * pretmp_1796) * 4)}_2, +, (sizetype) ((long unsigned int)
pretmp_1796 * 4)}_6, +, 4}_7
Creating dr for *_81
analyze_innermost: success.
base_address: pretmp_1792 + (sizetype) ((long unsigned int) pretmp_1915
* 4)
offset from base address: 0
constant offset from base address: 4
step: 4
aligned to: 128
base_object: *pretmp_1792 + (sizetype) ((long unsigned int)
(((pretmp_1804 + 1) * pretmp_1794 + 1) * pretmp_1796) * 4)
Access function 0: {{{4B, +, (sizetype) ((long unsigned int)
(pretmp_1794 * pretmp_1796) * 4)}_2, +, (sizetype) ((long unsigned int)
pretmp_1796 * 4)}_6, +, 4}_7
Creating dr for *_60
analyze_innermost: success.
base_address: pretmp_1792 + (sizetype) ((long unsigned int) pretmp_1902
* 4)
offset from base address: 0
constant offset from base address: 4
step: 4
aligned to: 128
base_object: *pretmp_1792 + (sizetype) ((long unsigned int)
(((pretmp_1801 + 1) * pretmp_1794 + 1) * pretmp_1796) * 4)
Access function 0: {{{4B, +, (sizetype) ((long unsigned int)
(pretmp_1794 * pretmp_1796) * 4)}_2, +, (sizetype) ((long unsigned int)
pretmp_1796 * 4)}_6, +, 4}_7
which still requires hard work to actually combine as the base objects still
differ (but the access function is equal).
[Bug target/60077] [4.9 regression] gcc.target/i386/pr35767-5.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60077 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-05 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug middle-end/57499] [4.7/4.8 Regression] ICE when noreturn destructor returns after throw with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57499 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] ICE |ICE when noreturn |when noreturn destructor |destructor returns after|returns after throw with -O |throw with -O | Known to fail|4.9.0 | --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed on the trunk so far.
[Bug target/59718] Behaviour of -mcpu documented incorrectly for ARM targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59718 --- Comment #3 from jgreenhalgh at gcc dot gnu.org --- Author: jgreenhalgh Date: Wed Feb 5 14:40:36 2014 New Revision: 207505 URL: http://gcc.gnu.org/viewcvs?rev=207505root=gccview=rev Log: [Backport: ARM Documentation] Clarify -mcpu, -mtune, -march gcc/ Backport from mainline. 2014-02-05 James Greenhalgh james.greenha...@arm.com PR target/59718 * doc/invoke.texi (-march): Clarify documentation for ARM. (-mtune): Likewise. (-mcpu): Likewise. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/doc/invoke.texi
[Bug target/60076] gcc.dg/vect/pr60012.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60076 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-05 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine. Some dg-requires of vect_XXX missing probably. note: not vectorized: no vectype for stmt: _8 = *_7; scalar_type: long long unsigned int I propose to change s/unsigned long long/unsigned int/g in the testcase. Does that fix it for you?
[Bug c/59850] Support sparse-style pointer address spaces (type attributes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #6 from Tom Tromey tromey at gcc dot gnu.org --- Null pointer constants are treated specially, which makes sense, but only if they have type void * and are in address space 0. That is, this works: #define NULL ((__attribute__ ((address_space (0))) void *) 0) __attribute__((address_space (1))) int *p = NULL; But this gets a warning: #define NULL ((__attribute__ ((address_space (1))) void *) 0) __attribute__((address_space (0))) int *p = NULL; And so does this: #define NULL ((int *) 0) __attribute__((address_space (1))) int *p = NULL; I'm not sure whether that last one ought to be an error or not.
[Bug ada/60078] New: acats c761007 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 Bug ID: 60078 Summary: acats c761007 fails on ARM Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de ,.,. C761007 ACATS 2.5 14-02-05 11:14:25^M C761007 Check that if a finalize procedure invoked by a transfer of^M control or selection of a terminate alternative attempts^M to propagate an exception, the exception is ignored, but^M any other finalizations due to be performed are^M performed.^M * C761007 Asynchronously aborted operation Expecting: GHIJ Got:^M GGHIJ.^M C761007 FAILED .^M FAIL: c761007 root@socfpga_cyclone5:/home/ed/gnu/arm-linux-gnueabihf/bin# ./gcc -v Using built-in specs. COLLECT_GCC=./gcc COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf/libexec/gcc/armv7l-unknown-linux-gnueabihf/4.9.0/lto-wrapper Target: armv7l-unknown-linux-gnueabihf Configured with: ../gcc-4.9-20140202/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf --enable-languages=c,c++,objc,obj-c++,fortran,ada,go --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16 --with-float=hard Thread model: posix gcc version 4.9.0 20140202 (experimental) (GCC)
[Bug target/60076] gcc.dg/vect/pr60012.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60076 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine. Some dg-requires of vect_XXX missing probably. note: not vectorized: no vectype for stmt: _8 = *_7; scalar_type: long long unsigned int I propose to change s/unsigned long long/unsigned int/g in the testcase. Does that fix it for you? Unfortunately not. I'm attaching the new .vect file. Rainer
[Bug target/60076] gcc.dg/vect/pr60012.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60076 --- Comment #4 from Rainer Orth ro at gcc dot gnu.org --- Created attachment 32052 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32052action=edit unsigned int .vect dump
[Bug target/59718] Behaviour of -mcpu documented incorrectly for ARM targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59718 --- Comment #4 from jgreenhalgh at gcc dot gnu.org --- Author: jgreenhalgh Date: Wed Feb 5 14:55:18 2014 New Revision: 207506 URL: http://gcc.gnu.org/viewcvs?rev=207506root=gccview=rev Log: [Backport: ARM Documentation] Clarify -mcpu, -mtune, -march gcc/ Backport from mainline. 2014-02-05 James Greenhalgh james.greenha...@arm.com PR target/59718 * doc/invoke.texi (-march): Clarify documentation for ARM. (-mtune): Likewise. (-mcpu): Likewise. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/doc/invoke.texi
[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305 --- Comment #12 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to r...@cebitec.uni-bielefeld.de from comment #11) --- Comment #10 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Rainer Orth from comment #9) I see the same issue on some Solaris 10/SPARC systems on UltraSPARC T2: do you use the default mutex-based implementation for lib atomic? I do, since this is the only option on SPARC. Do you repeat the findings we see on Darwin, where a heavily loaded system does not exhibit the slow-down? I was part-way through investigating whether spin locks would be a better solution for these very short code-segements. Essentially, the duration should only be a few insns. Available time is ever the killer.
[Bug rtl-optimization/60079] [LRA] ICE when compiling attached case.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60079 --- Comment #1 from Tejas Belagod belagod at gcc dot gnu.org --- Created attachment 32053 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32053action=edit Reduced test case for LRA ICE.
[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #12 from Iain Sandoe iains at gcc dot gnu.org --- [...] Do you repeat the findings we see on Darwin, where a heavily loaded system does not exhibit the slow-down? no, I see it both on unloaded and heavily loaded systems. Even on an idle system, the runtime varies by a magnitude or more. Rainer
[Bug target/59718] Behaviour of -mcpu documented incorrectly for ARM targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59718 jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from jgreenhalgh at gcc dot gnu.org --- Fixed on trunk and all current release branches (4.8/4.7). The text now reads: This specifies the name of the target ARM processor. GCC uses this name to derive the name of the target ARM architecture (as if specified by -march) and the ARM processor type for which to tune for performance (as if specified by -mtune). Where this option is used in conjunction with -march or -mtune, those options take precedence over the appropriate part of this option.
[Bug rtl-optimization/60079] New: [LRA] ICE when compiling attached case.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60079 Bug ID: 60079 Summary: [LRA] ICE when compiling attached case. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: belagod at gcc dot gnu.org When the attached case is compiled with -O2 for AArch64, LRA ICEs thus: $ ../install/bin/aarch64-none-elf-gcc -O2 besttry.c -c besttry.c: In function 'ripemd160_block_data_order': besttry.c:936:1: internal compiler error: in update_reg_eliminate, at lra-eliminations.c:1157 } ^ 0x899638 update_reg_eliminate /work/aarch64/src/svn-trunk//gcc/gcc/lra-eliminations.c:1157 0x89ad3c lra_eliminate(bool, bool) /work/aarch64/src/svn-trunk//gcc/gcc/lra-eliminations.c:1387 0x897436 lra_constraints(bool) /work/aarch64/src/svn-trunk//gcc/gcc/lra-constraints.c:3974 0x8863bc lra(_IO_FILE*) /work/aarch64/src/svn-trunk//gcc/gcc/lra.c:2339 0x849f96 do_reload /work/aarch64/src/svn-trunk//gcc/gcc/ira.c:5457 0x84ac38 rest_of_handle_reload /work/aarch64/src/svn-trunk//gcc/gcc/ira.c:5598 0x84ac38 execute /work/aarch64/src/svn-trunk//gcc/gcc/ira.c:5627 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. My configure: .../gcc/configure --target=aarch64-none-elf --prefix=.../install --with-gmp=.../host-tools --with-mpfr=.../host-tools --with-mpc=.../host-tools --with-pkgversion=unknown --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=yes --enable-languages=c,c++ --with-newlib Sorry, I couldn't reduce the test case any further - commenting any line in besttry.c makes the ICE go away.
[Bug target/60076] gcc.dg/vect/pr60012.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60076
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
note: extract even/odd not supported by target
aha... next try:
Index: gcc/testsuite/gcc.dg/vect/pr60012.c
===
--- gcc/testsuite/gcc.dg/vect/pr60012.c (revision 207504)
+++ gcc/testsuite/gcc.dg/vect/pr60012.c (working copy)
@@ -8,14 +8,14 @@ typedef struct
} complex16_t;
void
-libvector_AccSquareNorm_ref (unsigned long long *acc,
+libvector_AccSquareNorm_ref (unsigned int *acc,
const complex16_t *x, unsigned len)
{
unsigned i;
for (i = 0; i len; i++)
-acc[i] += ((unsigned long long)((int)x[i].real * x[i].real))
- + ((unsigned long long)((int)x[i].imag * x[i].imag));
+acc[i] += ((unsigned int)((int)x[i].real * x[i].real))
+ + ((unsigned int)((int)x[i].imag * x[i].imag));
}
-/* { dg-final { scan-tree-dump LOOP VECTORIZED vect } } */
+/* { dg-final { scan-tree-dump LOOP VECTORIZED vect { target {
vect_extract_even_odd } } } } */
/* { dg-final { cleanup-tree-dump vect } } */
[Bug target/60076] gcc.dg/vect/pr60012.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60076 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- note: extract even/odd not supported by target aha... next try: This works: scan-tree-dump isn't even attempted. Thanks. Rainer
[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #14 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to r...@cebitec.uni-bielefeld.de from comment #13) [...] so the open question is whether there's a fault in the fall-back solution - or whether it's fundamentally incapable of delivering reasonable performance (at least on some non-linux platforms). I don't think so: on identical hardware, the test performs reasonably well on Solaris 11, but is sometimes slow as molasses on Solaris 10. Rather looks like a libc bug there. Rainer
[Bug target/60076] gcc.dg/vect/pr60012.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60076 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug target/60076] gcc.dg/vect/pr60012.c FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60076 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Feb 5 15:14:56 2014 New Revision: 207509 URL: http://gcc.gnu.org/viewcvs?rev=207509root=gccview=rev Log: 2014-02-05 Richard Biener rguent...@suse.de PR testsuite/60076 * gcc.dg/vect/pr60012.c: Require vect_extract_even_odd and avoid using unsigned long long. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr60012.c
[Bug target/59305] [4.9 Regression] gcc.dg/atomic/c11-atomic-exec-5.c fails with WARNING: program timed out on x86_64-apple-darwin13
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59305 --- Comment #14 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to r...@cebitec.uni-bielefeld.de from comment #13) --- Comment #12 from Iain Sandoe iains at gcc dot gnu.org --- [...] Do you repeat the findings we see on Darwin, where a heavily loaded system does not exhibit the slow-down? no, I see it both on unloaded and heavily loaded systems. Even on an idle system, the runtime varies by a magnitude or more. so the open question is whether there's a fault in the fall-back solution - or whether it's fundamentally incapable of delivering reasonable performance (at least on some non-linux platforms).
[Bug middle-end/60080] New: gcc.dg/vect/vect-nop-move.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60080 Bug ID: 60080 Summary: gcc.dg/vect/vect-nop-move.c FAILs Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Host: i386-pc-solaris2.9, i386-pc-solaris2.10 Target: i386-pc-solaris2.9, i386-pc-solaris2.10 Build: i386-pc-solaris2.9, i386-pc-solaris2.10 The gcc.dg/vect/vect-nop-move.c FAILs on both Solaris 9 and 10/x86: FAIL: gcc.dg/vect/vect-nop-move.c (internal compiler error) FAIL: gcc.dg/vect/vect-nop-move.c (test for excess errors) WARNING: gcc.dg/vect/vect-nop-move.c compilation failed to produce executable FAIL: gcc.dg/vect/vect-nop-move.c -flto -ffat-lto-objects (internal compiler error) FAIL: gcc.dg/vect/vect-nop-move.c -flto -ffat-lto-objects (test for excess errors) WARNING: gcc.dg/vect/vect-nop-move.c -flto -ffat-lto-objects compilation failed to produce executable The ICE can be reproduced with $ cc1 -fpreprocessed vect-nop-move.i -quiet -msse2 -O2 -fdump-rtl-combine-details -o vect-nop-move.s Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfee0646c in strlen () from /lib/libc.so.1 (gdb) where #0 0xfee0646c in strlen () from /lib/libc.so.1 #1 0xfee61bce in _ndoprnt () from /lib/libc.so.1 #2 0xfee6477e in fprintf () from /lib/libc.so.1 #3 0x085641ea in print_rtx (in_rtx=0xfeaf718c) at /vol/gcc/src/hg/trunk/local/gcc/print-rtl.c:430 #4 0x0856339c in print_rtx (in_rtx=0xfea8a800) at /vol/gcc/src/hg/trunk/local/gcc/print-rtl.c:384 #5 0x0856331f in print_rtx (in_rtx=0xfeadfdd4) at /vol/gcc/src/hg/trunk/local/gcc/print-rtl.c:363 #6 0x0856339c in print_rtx (in_rtx=in_rtx@entry=0xfea9bea8) at /vol/gcc/src/hg/trunk/local/gcc/print-rtl.c:384 #7 0x08564814 in print_rtl_single_with_indent (outf=0x92e8100 _iob+64, x=0xfea9bea8, ind=0) at /vol/gcc/src/hg/trunk/local/gcc/print-rtl.c:836 #8 0x08564873 in print_rtl_single (outf=0x92e8100 _iob+64, x=0xfea9bea8) at /vol/gcc/src/hg/trunk/local/gcc/print-rtl.c:818 #9 0x08a7608b in recog_for_combine (pnewpat=pnewpat@entry=0x8047230, insn=insn@entry=0xfeaf6264, pnotes=pnotes@entry=0x8047254) at /vol/gcc/src/hg/trunk/local/gcc/combine.c:10579 #10 0x08a879ea in try_combine (i3=i3@entry=0xfeaf6264, i2=optimized out, i1=i1@entry=0x0, i0=optimized out, new_direct_jump_p=0x8047328, last_combined_insn=0xfeaf6264) at /vol/gcc/src/hg/trunk/local/gcc/combine.c:3240 #11 0x08a8c2f4 in combine_instructions (nregs=optimized out, f=optimized out) at /vol/gcc/src/hg/trunk/local/gcc/combine.c:1256 #12 rest_of_handle_combine () at /vol/gcc/src/hg/trunk/local/gcc/combine.c:13865 #13 (anonymous namespace)::pass_combine::execute (this=0x9316930) at /vol/gcc/src/hg/trunk/local/gcc/combine.c:13908 #14 0x0854d8d1 in execute_one_pass (pass=0x9316930) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2229 #15 0x0854db6f in execute_pass_list (pass=optimized out) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2282 #16 0x0854db86 in execute_pass_list (pass=optimized out) at /vol/gcc/src/hg/trunk/local/gcc/passes.c:2283 #17 0x082df681 in expand_function (node=node@entry=0xfea08c7c) at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1774 #18 0x082e1619 in expand_all_functions () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:1908 #19 compile () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2252 #20 0x082e1deb in finalize_compilation_unit () at /vol/gcc/src/hg/trunk/local/gcc/cgraphunit.c:2329 #21 0x081b4aab in c_write_global_declarations () at /vol/gcc/src/hg/trunk/local/gcc/c/c-decl.c:10401 #22 0x085f346d in compile_file () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:562 #23 0x085f5526 in do_compile () at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1914 #24 toplev_main (argc=9, argv=0x8047548) at /vol/gcc/src/hg/trunk/local/gcc/toplev.c:1990 #25 0x08d959ab in main (argc=9, argv=0x8047548) at /vol/gcc/src/hg/trunk/local/gcc/main.c:36 There's an attempt to print a NULL string. On Solaris 11, the test works and in the vect-nop-move.c.201r.combine dump there are many instances of (null), e.g. Trying 25 - 26: Failed to match this instruction: (parallel [ (set (reg:SI 97 [ __eax ]) (asm_operands:SI (cpuid ) (=a) 0 [ (const_int 0 [0]) ] [ (asm_input:SI (0) (null):0) ] [] /var/gcc/regression/trunk/11-gcc/build/gcc/include/cpuid.h:248)) Rainer
[Bug middle-end/60080] gcc.dg/vect/vect-nop-move.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60080 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug ipa/60072] wrong code (for code with an optimize attribute) at -O0 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60072 --- Comment #2 from Zhendong Su su at cs dot ucdavis.edu --- (In reply to Jakub Jelinek from comment #1) Seems to be a dup of PR60062. *** This bug has been marked as a duplicate of bug 60062 *** Sorry for the dup Jakub, but are you certain about it? Since 60062 also affects 4.8.x, but this one doesn't, so I went and filed this report.
[Bug c++/58703] [4.9 Regression] ICE with invalid types in OpenMP declare reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58703 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Feb 5 15:32:01 2014 New Revision: 207511 URL: http://gcc.gnu.org/viewcvs?rev=207511root=gccview=rev Log: PR c++/58703 * parser.c (cp_parser_omp_declare_reduction): Save and free declarator_obstack. * c-c++-common/gomp/pr58703.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr58703.c Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/59947] [4.9 Regression] Segmentation fault with #pragma GCC optimize (O2), ICE in get_odr_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59947 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Feb 5 15:34:25 2014 New Revision: 207512 URL: http://gcc.gnu.org/viewcvs?rev=207512root=gccview=rev Log: PR ipa/59947 * ipa-devirt.c (possible_polymorphic_call_targets): Fix a comment typo and formatting issue. If odr_hash hasn't been created, return vNULL and set *completep to false. * g++.dg/opt/pr59947.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr59947.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/59999] [4.9 Regression] Sign extension in loop regression blocks generation of zero overhead loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #10 from Paulo J. Matos pa...@matos-sorge.com ---
(In reply to Paulo J. Matos from comment #8)
Made a mistake. With the attached test, the final gimple before expand for
the loop basic block is:
;; basic block 5, loop depth 0
;;pred: 5
;;4
# i_26 = PHI i_1(5), 0(4)
# ivtmp.24_18 = PHI ivtmp.24_12(5), ivtmp.24_29(4)
_28 = (void *) ivtmp.24_18;
_13 = MEM[base: _28, offset: 0B];
x.4_14 = x;
_15 = _13 ^ x.4_14;
MEM[base: _28, offset: 0B] = _15;
ivtmp.24_12 = ivtmp.24_18 + 4;
temp_ptr.5_17 = (Sample *) ivtmp.24_12;
_11 = (unsigned short) i_26;
_2 = _11 + 1;
i_1 = (short int) _2;
_10 = (int) i_1;
if (_10 _25)
goto bb 5;
else
goto bb 6;
;;succ: 5
;;6
However, the point is the same. IVOPTS should probably generate an int IV
instead of a short int IV to avoid the sign extend since removing the sign
extend during RTL seems to be quite hard.
What do you think?
For = 4.8 the scalar evolution of _10 is deemed not simple, because it looks
like the following:
nop_expr 0x2acd9ee0
type integer_type 0x2ab16690 int public SI
size integer_cst 0x2ab12c60 constant 32
unit size integer_cst 0x2ab12c80 constant 4
align 32 symtab 0 alias set 3 canonical type 0x2ab16690 precision
32 min integer_cst 0x2ab12f80 -2147483648 max integer_cst 0x2ab12fa0
2147483647 context translation_unit_decl 0x2ab29c00 D.2881
pointer_to_this pointer_type 0x2ab23348
arg 0 polynomial_chrec 0x2acdb090
type integer_type 0x2ab16540 short int sizes-gimplified public HI
size integer_cst 0x2ab12f20 constant 16
unit size integer_cst 0x2ab12f40 constant 2
align 16 symtab 0 alias set 4 canonical type 0x2ab16540
precision 16 min integer_cst 0x2ab12ec0 -32768 max integer_cst
0x2ab12ee0 32767
pointer_to_this pointer_type 0x2aca1f18
arg 0 integer_cst 0x2ab1f260 constant 1
arg 1 integer_cst 0x2acc9140 constant 1 arg 2 integer_cst
0x2acc9140 1
This is something like: (int) (short int) {1, +, 1}_1. Since these are signed
integers, we can assume they don't overflow, can't we simplify the scalar
evolution to a polynomial_chrec over 32bit integers and forget the nop_expr
that represents the sign extend?
[Bug target/60062] [4.7/4.9 Regression] wrong code (for code with the optimize attribute) at -O1 and above on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60062
--- Comment #5 from Zhendong Su su at cs dot ucdavis.edu ---
(In reply to Jakub Jelinek from comment #4)
*** Bug 60072 has been marked as a duplicate of this bug. ***
The testcase below is most likely another dup as the only difference is that it
affects the trunk at -Os only. Just include it here for reference. Thanks.
--
int printf (const char *, ...);
int a;
int
fn1 (unsigned char p1)
{
return p1 % p1;
}
static void
fn2 (char *p1, int p2)
{
if (p2)
printf (p1);
}
__attribute__ ((optimize (0)))
int fn3 (short p1, short p2)
{
a = 0;
return 0;
}
__attribute__ ((optimize (1)))
int fn4 ()
{
fn3 (0, 0);
if (fn1 (1))
for (;;)
;
return 1;
}
__attribute__ ((optimize (0)))
int main ()
{
fn4 ();
fn2 (, 0);
return 0;
}
[Bug c/59753] Missing -Woverflow warning with signed constant conversion between T_MAX+1 and UT_MAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59753 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- OK, if you use -Wpedantic, you'll get all the overflow warnings even without -Wconversion.
[Bug c/59850] Support sparse-style pointer address spaces (type attributes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #7 from Josh Triplett josh at joshtriplett dot org --- (In reply to Tom Tromey from comment #6) Null pointer constants are treated specially, which makes sense, but only if they have type void * and are in address space 0. Otherwise, they're not a null pointer constant, so they're not treated specially. :) A null pointer constant must be in address space 0; that's for compatibility with the standard definition of NULL, to avoid needing unique NULL constants for each possible address space (USER_NULL, IOMEM_NULL). I don't think it makes sense to treat a 0 in address space 1 as a null pointer constant; safer to give a warning for mixing address spaces. The goal isn't to treat 0 magically as an address in all address spaces; it's specifically to treat NULL as the null for all address spaces. That is, this works: #define NULL ((__attribute__ ((address_space (0))) void *) 0) __attribute__((address_space (1))) int *p = NULL; But this gets a warning: #define NULL ((__attribute__ ((address_space (1))) void *) 0) __attribute__((address_space (0))) int *p = NULL; I can't think of a legitimate reason to have a null pointer constant in a non-zero address space; there's already a null pointer constant, NULL, effectively in all address spaces, so why would you want to redefine it? And on the contrary, I can think of a very good reason to *have* this warning: suppose you wanted to define an INVALID_FOO_POINTER in the foo address space, and you decided to use 0 as the invalid value. You should get a warning if you try to use INVALID_FOO_POINTER with a non-foo pointer type; it shouldn't magically pass silently just because the chosen value is 0. And so does this: #define NULL ((int *) 0) __attribute__((address_space (1))) int *p = NULL; I'm not sure whether that last one ought to be an error or not. That isn't a null pointer constant, since it isn't (void *); it can't be converted to any other pointer type without warning, and I don't think it's unreasonable to say it can't be converted to any other address space without warning either.
[Bug c++/60081] New: Internal compiler error: Error reporting routines re-entered.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60081 Bug ID: 60081 Summary: Internal compiler error: Error reporting routines re-entered. Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: stanislav.manilov at gmail dot com Created attachment 32054 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32054action=edit preprocessed source It appears that declaring a class member to have type a vector of unique_ptr's is the reason for this bug, but could not verify details.
[Bug ipa/60072] wrong code (for code with an optimize attribute) at -O0 on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60072 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- It is fixed by the same patch, and is the same problem. If one of the two PRs ever worked with optimize attribute, it was purely by accident.
[Bug ipa/59947] [4.9 Regression] Segmentation fault with #pragma GCC optimize (O2), ICE in get_odr_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59947 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug c++/58703] [4.9 Regression] ICE with invalid types in OpenMP declare reduction clause
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58703 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug ipa/59918] [4.9 Regression] ICE in record_target_from_binfo, at ipa-devirt.c:693
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59918 Bug 59918 depends on bug 59947, which changed state. Bug 59947 Summary: [4.9 Regression] Segmentation fault with #pragma GCC optimize (O2), ICE in get_odr_type http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59947 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug ipa/59918] [4.9 Regression] ICE in record_target_from_binfo, at ipa-devirt.c:693
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59918 --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #5) Should be the same issue as PR59947 No. Still happens after r207512.
[Bug libffi/60073] [4.9 regression] 64-bit libffi.call/cls_double_va.c FAILs after recent modification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target|sparc*-sun-solaris2.* |sparc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-05 Host|sparc*-sun-solaris2.* |sparc*-*-* Summary|[4.9 regression] 64-bit |[4.9 regression] 64-bit |libffi.call/cls_double_va.c |libffi.call/cls_double_va.c |FAILs on Solaris/SPARC |FAILs after recent ||modification Ever confirmed|0 |1 Build|sparc*-sun-solaris2.* |sparc*-*-* --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I can reproduce, probably not specific to Solaris.
[Bug c++/60047] [4.7/4.8/4.9 Regression] ICE with defaulted copy constructor and virtual base class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60047 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug libffi/60073] [4.9 regression] 64-bit libffi.call/cls_double_va.c FAILs after recent modification
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Investigating.
[Bug c/59753] -Woverflow warning inconsistency with signed constant conversion between T_MAX+1 and UT_MAX vs larger than UT_MAX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59753 Vincent Lefèvre vincent-gcc at vinc17 dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME |--- Summary|Missing -Woverflow warning |-Woverflow warning |with signed constant|inconsistency with signed |conversion between T_MAX+1 |constant conversion between |and UT_MAX |T_MAX+1 and UT_MAX vs ||larger than UT_MAX --- Comment #4 from Vincent Lefèvre vincent-gcc at vinc17 dot net --- There's still an inconsistency without -Wpedantic, which is the point of this bug. I've changed the bug title to: -Woverflow warning inconsistency with signed constant conversion between T_MAX+1 and UT_MAX vs larger than UT_MAX If this inconsistency is intentional, then it should be documented. The current behavior doesn't match the documentation: -Wno-overflow Do not warn about compile-time overflow in constant expressions. I fail to see why there should be a warning for short c = 65536; but not for short b = 65535; BTW, there's actually no overflow in the constant expressions themselves, just in the assignments.
[Bug ada/60078] acats c761007 fails on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60078 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-05 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Is that on real hardware or simulator? This test is one of the infamous tests that require very solid concurrency support from the environment.
