[Bug c/45593] New: ICE on Sparc with -Os
from linux-2.6.36-rc3, `fs/jdb2/journal.c' triggers the following: /linux-2.6/fs/jbd2/journal.c:1200: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. On a reduced testcase: /sparc-none-linux-none/libexec/gcc/sparc-none-linux-none/4.5.2/cc1 -version reduced-testcase.c -auxbase-strip fs/jbd2/journal.o -Os -o /tmp/ccW5WcDf.s GNU C (crosstool-NG) version 4.5.2 20100814 (prerelease) (sparc-none-linux-none) compiled by GNU C version 4.3.3, GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (crosstool-NG) version 4.5.2 20100814 (prerelease) (sparcnone-linux-none) compiled by GNU C version 4.3.3, GMP version 5.0.1, MPFR version 3.0.0, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 options passed: reduced-testcase.c -auxbase-strip fs/jbd2/journal.o -Os options enabled: -falign-functions -falign-jumps -falign-labels -fargument-alias -fauto-inc-dec -fbranch-count-reg -fcaller-saves -fcommon -fcprop-registers -fcrossjumping -fcse-follow-jumps -fdefer-pop -fdelayed-branch -fdelete-null-pointer-checks -fdwarf2-cfi-asm -fearly-inlining -feliminate-unused-debug-types -fexpensive-optimizations -fforward-propagate -ffunction-cse -fgcse -fgcse-lm -fguess-branch-probability -fident -fif-conversion -fif-conversion2 -findirect-inlining -finline -finline-functions -finline-functions-called-once -finline-small-functions -fipa-cp -fipa-pure-const -fipa-reference -fipa-sra -fira-share-save-slots -fira-share-spill-slots -fivopts -fkeep-static-consts -fleading-underscore -fmath-errno -fmerge-constants -fmerge-debug-strings -fmove-loop-invariants -fomit-frame-pointer -foptimize-register-move -foptimize-sibling-calls -fpcc-struct-return -fpeephole -fpeephole2 -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fsched-critical-path-heuristic -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fschedule-insns2 -fshow-column -fsigned-zeros -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing -fstrict-overflow -fthread-jumps -ftoplevel-reorder -ftrapping-math -ftree-builtin-call-dce -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop -ftree-pre -ftree-pta -ftree-reassoc -ftree-scev-cprop -ftree-sink -ftree-slp-vectorize -ftree-sra -ftree-switch-conversion -ftree-ter -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -fvar-tracking -fvar-tracking-assignments -fzero-initialized-in-bss -m32 -mapp-regs -mfpu -mglibc -mlong-double-64 -mptr32 -msoft-quad-float Compiler executable checksum: f32dd74a0af03a816776742ef7661751 printk journal_fail_superblock journal_get_superblock load_superblock jbd2_journal_update_format jbd2_journal_wipe Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups whole-program cp inline static-var pure-constAssembling functions: journal_get_superblock reduced-testcase.c: In function 'journal_get_superblock': reduced-testcase.c:64: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. Backtrace is: Program received signal SIGSEGV, Segmentation fault. 0x083a5001 in mark_target_live_regs () Current language: auto; currently asm (gdb) bt #0 0x083a5001 in mark_target_live_regs () #1 0x0839fecd in fill_slots_from_thread () #2 0x083a0f06 in fill_eager_delay_slots () #3 0x083a2777 in dbr_schedule () #4 0x083a2ee9 in rest_of_handle_delay_slots () #5 0x08340c89 in execute_one_pass () #6 0x08340f6d in execute_pass_list () #7 0x08340f89 in execute_pass_list () #8 0x08340f89 in execute_pass_list () #9 0x08460809 in tree_rest_of_compilation () #10 0x085b5040 in cgraph_expand_function () #11 0x085b52aa in cgraph_expand_all_functions () #12 0x085b58f6 in cgraph_optimize () #13 0x085b3cbc in cgraph_finalize_compilation_unit () #14 0x080c411c in c_write_global_declarations () #15 0x0840d15b in compile_file () #16 0x0840ef84 in do_compile () #17 0x0840f049 in toplev_main () #18 0x08131936 in main () This ICE happens seems to happen on sparc- with -Os. -- Summary: ICE on Sparc with -Os Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lacombar at gmail dot com GCC host triplet: i686-pc GCC target triplet:
[Bug rtl-optimization/45593] ICE on Sparc with -Os
--- Comment #1 from lacombar at gmail dot com 2010-09-08 06:13 --- Created an attachment (id=21734) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21734action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45593
[Bug fortran/43665] INTENT(IN) etc. optimization of calls: function annotations for noclobber/noescape arguments
--- Comment #19 from burnus at gcc dot gnu dot org 2010-09-08 06:25 --- Reviewed patch (OK) available at http://gcc.gnu.org/ml/fortran/2010-09/msg00198.html however, it causes regressions as some of the intrinsics (in intrinsic.c) have the wrong intents - which causes wrong code (too much optimized away). Thus, one first needs to audit and fix intrinsic.c before this patch can be committed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43665
[Bug middle-end/45589] [4.6 Regression] 200.sixtrack in SPEC CPU 2000 is miscompiled
--- Comment #4 from dominiq at lps dot ens dot fr 2010-09-08 06:55 --- This pr could be a duplicate of pr45578. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45589
[Bug tree-optimization/45578] [4.6 Regression] The polyhedron test mdbx is miscompiled with -O2 -ftree-vectorize at revision 163915
--- Comment #6 from dominiq at lps dot ens dot fr 2010-09-08 06:56 --- pr45589 could be a duplicate of this pr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45578
[Bug bootstrap/44001] .o vs. obj = @OBJEXT@ and $ac_objext
--- Comment #3 from gingold at gcc dot gnu dot org 2010-09-08 07:27 --- Subject: Bug 44001 Author: gingold Date: Wed Sep 8 07:27:11 2010 New Revision: 163989 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163989 Log: 2010-09-08 Tristan Gingold ging...@adacore.com PR 44001 * maint-tool (missing): Fix pattern for object file. (deps): Use $(objext) for object extension. * Makefile.in (objext): New variable. Replace all occurences of .o with .$(objext) Regenerate with maint-deps * configure.ac (pexecute): Set to the basename. * configure: Regenerate. Modified: trunk/libiberty/ChangeLog trunk/libiberty/Makefile.in trunk/libiberty/configure trunk/libiberty/configure.ac trunk/libiberty/maint-tool -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44001
[Bug bootstrap/44001] .o vs. obj = @OBJEXT@ and $ac_objext
--- Comment #4 from gingold at gcc dot gnu dot org 2010-09-08 08:26 --- Subject: Bug 44001 Author: gingold Date: Wed Sep 8 08:25:39 2010 New Revision: 163993 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163993 Log: 2010-09-08 Tristan Gingold ging...@adacore.com PR 44001 * Makefile.in (objext): New variable. (bid_OBJS): Use $(objext) for extension. (libdecnumber_a_OBJS): Ditto. (mostlyclean): Ditto (.c.o): Ditto. Update dependencies. Modified: trunk/libdecnumber/ChangeLog trunk/libdecnumber/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44001
[Bug bootstrap/44001] .o vs. obj = @OBJEXT@ and $ac_objext
--- Comment #5 from gingold at gcc dot gnu dot org 2010-09-08 08:48 --- Fixed with the filed patches. -- gingold at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44001
[Bug middle-end/44554] Stack space after sigsetjmp is reused
--- Comment #7 from ibolton at gcc dot gnu dot org 2010-09-08 08:49 --- (In reply to comment #6) (In reply to comment #5) Do we need to act as if -fno-ira-share-spill-slots is set in cfun-calls_setjmp functions? At least in my case -Os -fno-ira-share-spill-slots seems to solve the problem. This applies also to the original (not stripped down) version of the code. Is this still a bug then? Should ira-share-spill-slots be automatically disabled for the caller function when a callee function can return twice? -- ibolton at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554
[Bug c++/45594] New: g++ incorrectly treats inline function redefinition
If two separate .cpp files contain two versions of inline function with the
same signature, that are used by functions in the corresponding files, one of
them is dropped and all functions use only one of them.
Consider example:
main.cpp
-
#include test1.h
#include test2.h
int main()
{
print_out_1();
print_out_2();
return 0;
}
-
test1.h
-
#ifndef TEST1_H
#define TEST1_H
void print_out_1();
#endif // TEST1_H
-
test2.h
-
#ifndef TEST2_H
#define TEST2_H
void print_out_2();
#endif // TEST2_H
-
test1.cpp
-
#include test1.h
#include stdio.h
inline int print_stuff(int n)
{
printf(number 255\n);
return n;
}
void print_out_1()
{
print_stuff(10);
}
-
test2.cpp
-
#include test2.h
#include stdio.h
inline int print_stuff(int n)
{
printf(letter A\n);
return n;
}
void print_out_2()
{
print_stuff(10);
}
-
The main() function simply calls print_out_1() function from test1.h and
print_out_2() function from test2.h, which in turn call print_stuff() inline
functions.
The expected output would be:
-
number 255
letter A
-
The actual output is:
-
number 255
number 255
-
This error appears for both debug and release (-O2) builds.
--
Summary: g++ incorrectly treats inline function redefinition
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: justchecking8964 at gmail dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45594
[Bug target/44189] PIC compilation on ARM screws up DWARF lineinfo in function prologue
--- Comment #3 from ibolton at gcc dot gnu dot org 2010-09-08 09:12 --- Thanks for raising this bug, Gergely, and suggesting a patch. I've moved the bug to the NEW state, so if you want to post your patch to the gcc-patches list, then you will hopefully get some feedback on it there and we will be able to work towards an approved fix. -- ibolton at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.6.0 4.5.3 4.4.5 Last reconfirmed|-00-00 00:00:00 |2010-09-08 09:12:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44189
[Bug fortran/45575] ICE on missing module file
--- Comment #5 from ubizjak at gmail dot com 2010-09-08 09:18 --- (In reply to comment #1) and search for the line with starts with /some/path/f95 and run then the f951 line in a debugger, e.g. gdb --args /some/path/to/f951 many, many, many options and then in (gdb) run bt and post the result of the backtrace (bt). You should also break fatal_error in between run and bt command. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45575
[Bug c++/45594] g++ incorrectly treats inline function redefinition
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-08 09:20 --- You are violating the ODR. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45594
[Bug middle-end/45585] [4.6 Regression] ICE on powerpc-apple-darwin9 for gfortran.dg/transfer_simplify_2.f90 with -O2 -m64
--- Comment #1 from iains at gcc dot gnu dot org 2010-09-08 09:20 --- also on powerpc64-darwin9 -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-08 09:20:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45585
[Bug testsuite/45590] FAIL: gcc.dg/graphite/pr44391.c: unrecognized command line option '-m32'
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-09-08 09:22 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45590
[Bug testsuite/45590] FAIL: gcc.dg/graphite/pr44391.c: unrecognized command line option '-m32'
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-08 09:22 --- Subject: Bug 45590 Author: rguenth Date: Wed Sep 8 09:22:35 2010 New Revision: 163995 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163995 Log: 2010-09-08 Richard Guenther rguent...@suse.de PR testsuite/45590 * gcc.dg/graphite/pr44391.c: Remove -m32 option. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/graphite/pr44391.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45590
[Bug middle-end/45589] [4.6 Regression] 200.sixtrack in SPEC CPU 2000 is miscompiled
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-09-08 09:22 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-08 09:22:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45589
[Bug rtl-optimization/45593] ICE on Sparc with -Os
--- Comment #2 from mikpe at it dot uu dot se 2010-09-08 09:30 --- I can reproduce the ICE on sparc64-linux with 4.5-20100902 and 4.6-20100904 -Os -m32. With -m64 or -O1/O2/O3 it doesn't ICE. 4.4-20100817 doesn't ICE. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45593
[Bug lto/45586] [4.6 Regression] ICE non-trivial conversion at assignment
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-08 09:36 --- Confirmed. We have two different array3_real(kind=8) record types that are not considered compatible. One data pointer member is restrict qualified while the other one is not. Why do we have an aggregate assignment of an array descriptor anyway? struct array3_real(kind=8) y; struct realspace_grid_type * D.2157; bb 2: y.data = 0B; D.2157_5 = *x_4(D); y = D.2157_5-r; D.2172_6 = y.data; The issue here is of course that LTO re-computes TYPE_CANONICAL and the FE sets it in a way that the above situation is not detected as non-trivial conversion. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||lto Last reconfirmed|-00-00 00:00:00 |2010-09-08 09:36:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
[Bug middle-end/45585] [4.6 Regression] ICE on powerpc-apple-darwin9 for gfortran.dg/transfer_simplify_2.f90 with -O2 -m64
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45585
[Bug c/45584] typeof with casting from const to non-const does not work properly
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-08 09:37 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-08 09:37:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45584
[Bug fortran/45592] [F03] Valid structure constructor rejected for extended types
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-08 09:49 --- This problem is apparently related to type extension (but not to abstract types). The following still fails: implicit none type :: pointGen end type pointGen type, extends(pointGen) :: point2d real :: x,y end type type(point2d) :: myPoint myPoint = point2d(2.3, 4.2)! The problem is here myPoint = point2d(x=2.3,y=4.2) ! ok with that end It works when removing the EXTENDS clause. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-08 09:49:09 date|| Summary|[OOP] Valid structure |[F03] Valid structure |constructor rejected|constructor rejected for ||extended types http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45592
[Bug middle-end/30908] tree cost for types which are WORD_SIZE
--- Comment #21 from abnikant dot singh at atmel dot com 2010-09-08 09:50
---
The head version [gcc version 4.6.0 20100907 (experimental) (GCC)] tends to
inline the attached test case in case of -Os, just because it gets better code
size [see the dump using : -fdump-ipa-inline] by performing inline.
If the test case is changed slightly as
given below, the head version does not perform the inline because without
performing inline it gets better code size.
#ifdef NOINLINE
__attribute__((noinline))
#endif
;
static void wait(int i)
{
volatile int a = 5;
while (i-- 0)
{
a = a + i;
}
asm volatile( ::: memory);
}
int
main(void)
{
volatile x;
for (;;) {
x = 1;
wait(100);
x = 0;
wait(100);
}
return 0;
}
--
abnikant dot singh at atmel dot com changed:
What|Removed |Added
CC||abnikant dot singh at atmel
||dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #10 from paolo dot carlini at oracle dot com 2010-09-08 09:56 --- (In reply to comment #8) Maybe you should tell that to Paolo Carlini, who closed bug 15002 as resolved fixed in 2004, And it *is* fixed. Did you actually open the testcases? Just plain fstreams, thus no syncing. or to Loren Rittle, who closed bug 5001 as resolved fixed in 2003, declaring This issue was addressed by gcc 3.2.X such that sync_with_stdio was no longer required for reasonable performance. And indeed it's true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #11 from paolo dot carlini at oracle dot com 2010-09-08 09:59 --- (In reply to comment #8) But a 9-10x difference doesn't sound reasonable to me. The synced mode is not unbuffered, before or after my suggested change, it uses the internal buffer in glibc. So? We are not changing glibc here. The C++ library does *not* use buffering in the synced mode, and it does otherwise, for fstreams in particular. Where do you think the performance difference is essentially coming from? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug middle-end/43976] warning about increased alignment during casting printed even though variable is properly aligned
--- Comment #5 from ibolton at gcc dot gnu dot org 2010-09-08 10:02 ---
Confirmed on latest 4.4, 4.5 and 4.6 (trunk).
Related GCC documentation on alignment of structure fields is here:
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Variable-Attributes.html#Variable-Attributes
In the short-term, one workaround is to write the code as follows:
#include stdio.h
struct Foo
{
char c[sizeof(int)];
} __attribute__((aligned(4)));
char junk;
Foo f;
int main()
{
int *i = reinterpret_castint *(f);
*i = 0x44434241;
printf(%c %c %c %c, f.c[0], f.c[1], f.c[2], f.c[3]);
}
By aligning the structure Foo to 4 bytes, you can successfully cast a Foo* to
an int* and then initialise all four chars in one go. (Without the type
attribute for the struct Foo, you still get the warning.) My example prints A
B C D.
FYI: I have tracked down the alleged offending code mentioned in an earlier
comment to build_c_cast() in c-typeck.c.
--
ibolton at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.4.5 4.5.2 4.6.0
Last reconfirmed|-00-00 00:00:00 |2010-09-08 10:02:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43976
[Bug bootstrap/45174] Make fails in zlib
--- Comment #23 from ibolton at gcc dot gnu dot org 2010-09-08 10:06 --- (In reply to comment #21) Subject: Re: Make fails in zlib Hello; Well I solved my problem, however the issue still remains. I installed the latest native binutils and gcc-4.5.1 on my linux installation. The script now works without any errors. However it appears that using the supplied binutils and compilers from Ubuntu 10.04 there is a problem creating the cross compilers. I do not know how or if I should proceed from here. It maybe there there is some subtle error in the bins supplied with Ubuntu. Thank You, Donald Schlicht I've just read this thread and am now unsure as to whether there is a bug with GCC or not. It sounds like your initial troubles have gone away and now there is a new problem. Would it make sense to close this bug and raise a new bug to cover the new issue? -- ibolton at gcc dot gnu dot org changed: What|Removed |Added CC||ibolton at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174
[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811
--- Comment #6 from mikpe at it dot uu dot se 2010-09-08 10:16 --- (In reply to comment #5) I can't get this to ICE with latest version of 4.4, 4.5 or 4.6 branches. The default_secondary_reload ICE is on a gcc_assert() so you must configure with --enable-checking; --enable-checking=release is sufficient. You also need to target Thumb-1 not Thumb-2; -march=armv5te suffices. The gen_thumb_movhi_clobber ICE is a gcc_unreachable() in a pattern guarded by TARGET_THUMB1, so you must target Thumb-1 not Thumb-2; -march=armv5te suffices. I just reproduced the first with 4.4-20100907 and 4.5-20100902, and the second with 4.5-20100902. I didn't check 4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #12 from paolo dot carlini at oracle dot com 2010-09-08 10:20 --- By the way, getdelim is not standard, thus would work only on linux, even more special casing. More importantly, fgets *stores* newline and '\0', at variance with getline, I don't think it can be used as-is as an implementation detail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug c++/45594] g++ incorrectly treats inline function redefinition
--- Comment #2 from justchecking8964 at gmail dot com 2010-09-08 10:30 --- (In reply to comment #1) You are violating the ODR. ODR rule relates only to the non-inline functions, which is not the case here, see http://en.wikipedia.org/wiki/One_Definition_Rule : #2: In the entire program, an object or non-inline function cannot have more than one definition; if an object or function is used, it must have exactly one definition. You can declare an object or function that is never used, in which case you don't have to provide a definition. In no event can there be more than one definition. The case that apply here is discussed in point 3: #3: Some things, like types, templates, and extern inline functions, can be defined in more than one translation unit. For a given entity, each definition must be the same. Non-extern objects and functions in different translation units are different entities, even if their names and types are the same. The case above concerns non-extern inline functions, that are different entities, even if their names and types are the same. -- justchecking8964 at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45594
[Bug c++/45594] g++ incorrectly treats inline function redefinition
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-08 10:34 --- (In reply to comment #2) The case that apply here is discussed in point 3: #3: ... For a given entity, each definition must be the same. ... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45594
[Bug c++/45594] g++ incorrectly treats inline function redefinition
--- Comment #4 from justchecking8964 at gmail dot com 2010-09-08 10:39 --- (In reply to comment #3) (In reply to comment #2) The case that apply here is discussed in point 3: #3: ... For a given entity, each definition must be the same. ... But this applies only to [...] types, templates, and extern inline functions. My case is about non-extern inline functions, which in different translation units are different entities, even if their names and types are the same. -- justchecking8964 at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45594
[Bug c++/45594] g++ incorrectly treats inline function redefinition
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-09-08 10:42 --- (In reply to comment #4) (In reply to comment #3) (In reply to comment #2) The case that apply here is discussed in point 3: #3: ... For a given entity, each definition must be the same. ... But this applies only to [...] types, templates, and extern inline functions. My case is about non-extern inline functions, which in different translation units are different entities, even if their names and types are the same. Your inline functions are extern, not static. Make them static and it will work. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45594
[Bug c++/45594] g++ incorrectly treats inline function redefinition
--- Comment #6 from justchecking8964 at gmail dot com 2010-09-08 11:00 --- Your inline functions are extern, not static. Make them static and it will work. I see, thanks, I missed the part of the new standard that defines inline as being implicitly extern. There's something new to learn every day. Sorry for the bother. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45594
[Bug middle-end/44554] Stack space after sigsetjmp is reused
--- Comment #8 from christian dot eggers at kathrein dot de 2010-09-08 11:12 --- (In reply to comment #7) Is this still a bug then? Should ira-share-spill-slots be automatically disabled for the caller function when a callee function can return twice? I've never tested with gcc-4.5.x, but in 4.4.x the problem is still present. Unfortunately -fno-ira-share-spill-slots seems to introduce another bug which leads to wrong computations (nearly at the same code position where I had the problems mentioned is this report). At this moment I can not provide a detailed report for this problem, but perhaps it's the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386. -- christian dot eggers at kathrein dot de changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554
[Bug tree-optimization/45578] [4.6 Regression] The polyhedron test mdbx is miscompiled with -O2 -ftree-vectorize at revision 163915
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-09-08 11:17 --- Subject: Bug 45578 Author: rguenth Date: Wed Sep 8 11:17:31 2010 New Revision: 163997 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163997 Log: 2010-09-08 Richard Guenther rguent...@suse.de PR tree-optimization/45578 * tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Be more careful when transfering alignment information to the new induction variable. (copy_ref_info): Likewise. * gfortran.dg/pr45578.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr45578.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45578
[Bug tree-optimization/45578] [4.6 Regression] The polyhedron test mdbx is miscompiled with -O2 -ftree-vectorize at revision 163915
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-09-08 11:21 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45578
[Bug fortran/43829] Scalarization of reductions
--- Comment #27 from dominiq at lps dot ens dot fr 2010-09-08 11:29 --- What is the fate of the patch in comment #19? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
[Bug fortran/45595] New: segfault on omp collapse
this test case (with an invalid collapse): SUBROUTINE init_input_type() INTEGER :: k,l(3),u(3) !$omp parallel do shared(l,u) collapse(3) DO k = l(3),u(3) ENDDO END SUBROUTINE leads to an ice with current trunk as: #0 gfc_resolve_omp_directive (code=0x1437880, ns=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/openmp.c:1519 #1 0x0051f74c in resolve_code (code=0x1437880, ns=0x1435f00) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/resolve.c:9126 #2 0x0052063a in resolve_codes (ns=0x1435f00) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/resolve.c:13339 #3 0x0052074c in gfc_resolve (ns=0x1435f00) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/resolve.c:13366 #4 0x00513cd7 in gfc_parse_file () at /data03/vondele/gcc_trunk/gcc/gcc/fortran/parse.c:4194 #5 0x0054ce7d in gfc_be_parse_file (set_yydebug=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:242 #6 0x0085fa4d in toplev_main (argc=20, argv=0x7fff13674938) at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:972 #7 0x7ffdb4e7d436 in __libc_start_main () from /lib64/libc.so.6 #8 0x004aa599 in _start () -- Summary: segfault on omp collapse Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45595
[Bug fortran/45596] New: Implement simple static points-to analysis in Fortran FE
This is a RFC, the intent of this is to improve tonto speed and hopefully other Fortran testcases. I'll attach a WIP patch. What it currently does is from frontend-passes.c walks down procedure body and tries to determine all possible POINTER assignments (currently for POINTER vars only, no POINTER components), computing points_to list for each suitable POINTER var. NULL points_to means points to not computed, or could point to anything. Otherwise it can contain other symbols, the fact that ALLOCATE has been used on some pointer, that it is nullified, that it inherits its value from caller for dummy vars or that a callee might set the var. Currently the patch doesn't implement interprocedural analysis (we give up immediately on GFC_PT_CALL). Eventually, for GFC_PT_CALL we should be able to look up if we have points_to for the corresponding dummy argument and somehow try to remap the stuff from its points_to to current function. GFC_PT_DUMMY obviously can map to whatever we pass to that argument, GFC_PT_NULL is null as well, similarly GFC_PT_ALLOCATE, for other pointers just recurse and remap what they point to, for stuff like module vars I'm afraid the FE syms might not be shared, or for COMMONs etc. Another thing which still needs solving is distinction between full pointer assignments and partial ones (ptr = x vs. ptr = y(:, 1) ), as for the latter ones we should simply give up if we find out symbols might be same, instead of trying to do some dependency resolution. For tonto there is another problem, create_ and destroy method subroutines are defined in a different file, so in order to optimize that we'd probably need to save the computed points_to info into *.mod file and read it from that again. -- Summary: Implement simple static points-to analysis in Fortran FE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45596
[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-08 12:01 --- Created an attachment (id=21735) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21735action=view) gcc46-pr45596.patch WIP patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45596
[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-08 12:05 --- Created an attachment (id=21736) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21736action=view) uu.f90 One testcase I've been playing with. The patch allows optimizing away temporaries on 3 of the 4 p? = a + ? assignments, only for p3 it assumes it might point to a (well, in this case a is never assigned to any pointer, but that is not tracked). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45596
[Bug fortran/45596] Implement simple static points-to analysis in Fortran FE
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-08 12:08 --- Created an attachment (id=21737) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21737action=view) tonto2.f90 Modified testcase from tonto (well, in particular from richi's testcase in one of the tonto PRs), where the allocate is done directly in the current function instead of another subroutine. Here the most important temporary can be optimized out. With (working) GFC_PT_CALL handling even the case where create_ is a module function defined in the current file could work, and with saving/restoring points_to stuff in theory even the original tonto could be optimized. Anyway, before I continue working on this, I'd appreciate comments on issues you see in the current code already. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45596
[Bug fortran/45597] New: [4.6 Regression] ICE: in gfc_trans_cycle, at fortran/trans-stmt.c:4320
gfortran -c -fopenmp bug.f90 bug.f90: In function rs_pw_transfer_distributed: bug.f90:6:0: internal compiler error: in gfc_trans_cycle, at fortran/trans-stmt.c:4320 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. cat bug.f90 SUBROUTINE rs_pw_transfer_distributed() INTEGER, ALLOCATABLE, DIMENSION(:, :):: bounds !$omp parallel do default(none), !$omp shared(bounds,my_rs_rank) DO i = 0, N IF (ub_send(1) .LT.bounds(my_rs_rank,1)) CYCLE END DO END SUBROUTINE rs_pw_transfer_distributed -- Summary: [4.6 Regression] ICE: in gfc_trans_cycle, at fortran/trans-stmt.c:4320 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45597
[Bug fortran/45595] segfault on omp collapse
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-08 12:18:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45595
[Bug fortran/45597] [4.6 Regression] ICE: in gfc_trans_cycle, at fortran/trans-stmt.c:4320
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-08 12:18:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45597
[Bug c++/45594] g++ incorrectly treats inline function redefinition
--- Comment #7 from paolo dot carlini at oracle dot com 2010-09-08 12:21 --- new? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45594
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #6 from mikpe at it dot uu dot se 2010-09-08 12:24 --- The smallest .o file that differs between stage2 and stage3 is sreal.o. Diffing the objdump -d output shows: @@ -1,5 +1,5 @@ -stage2-gcc/sreal.o: file format elf32-littlearm +stage3-gcc/sreal.o: file format elf32-littlearm Disassembly of section .text: @@ -19,7 +19,7 @@ 2c: 01520004cmpeq r2, r4 30: 3a11bcc 7c normalize.isra.1+0x7c 34: e5911000ldr r1, [r1] - 38: e0944004addsr4, r4, r4 + 38: e1b04084lslsr4, r4, #1 3c: e0a55005adc r5, r5, r5 40: e1530005cmp r3, r5 44: 01520004cmpeq r2, r4 That is, a single adds became an lsls instead. cfgloopanal.o and tree-ssa-loop-ivcanon.o show the exact same one-instruction adds-became-lsls difference. double-int.o has more elaborate differences: @@ -1,5 +1,5 @@ -stage2-gcc/double-int.o: file format elf32-littlearm +stage3-gcc/double-int.o: file format elf32-littlearm Disassembly of section .text: @@ -427,13 +427,13 @@ 674: e1a0c33clsr ip, ip, r3 678: e58d4018str r4, [sp, #24] 67c: e58d2020str r2, [sp, #32] - 680: e1cd21d8ldrdr2, [sp, #24] - 684: e0922002addsr2, r2, r2 - 688: e58d5024str r5, [sp, #36] ; 0x24 + 680: e58d5024str r5, [sp, #36] ; 0x24 + 684: e1cd21d8ldrdr2, [sp, #24] + 688: e1b02082lslsr2, r2, #1 68c: e0a33003adc r3, r3, r3 - 690: e1cd02d0ldrdr0, [sp, #32] - 694: e1822000orr r2, r2, r0 - 698: e1833001orr r3, r3, r1 + 690: e1cd42d0ldrdr4, [sp, #32] + 694: e1822004orr r2, r2, r4 + 698: e1833005orr r3, r3, r5 69c: e58ab000str fp, [sl] 6a0: e58ac004str ip, [sl, #4] 6a4: e1c820f0strdr2, [r8] I'll try to extract a test case from one of these. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug tree-optimization/33244] Missed opportunities for vectorization due to PRE
--- Comment #3 from matz at gcc dot gnu dot org 2010-09-08 12:35 --- Subject: Bug 33244 Author: matz Date: Wed Sep 8 12:34:52 2010 New Revision: 163998 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163998 Log: PR tree-optimization/33244 * tree-ssa-sink.c (statement_sink_location): Don't sink into empty loop latches. testsuite/ PR tree-optimization/33244 * gfortran.dg/vect/fast-math-vect-8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/vect/fast-math-vect-8.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sink.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33244
[Bug tree-optimization/43430] Missed vectorization: stmt not supported: cond_expr
--- Comment #8 from matz at gcc dot gnu dot org 2010-09-08 12:40 --- Subject: Bug 43430 Author: matz Date: Wed Sep 8 12:40:24 2010 New Revision: 163999 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163999 Log: PR tree-optimization/43430 * tree-vect-stmts.c (vectorizable_condition): Support multiple copies for conditional statements if it's not part of a reduction. testsuite/ PR tree-optimization/43430 * gcc.dg/vect/pr43430-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr43430-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43430
[Bug tree-optimization/45578] [4.6 Regression] The polyhedron test mdbx is miscompiled with -O2 -ftree-vectorize at revision 163915
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-09-08 12:54 --- *** Bug 45421 has been marked as a duplicate of this bug. *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45578
[Bug tree-optimization/45421] [4.6 regression] Ada bootstrap failure on IRIX 6.5: SIGBUS in sem_aggr.sort_case_table
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-09-08 12:54 --- Unfortunately, even with your patch the mips-sgi-irix6.5 Ada bootstrap is still broken. OK, thanks for testing. Presumably fixed by Richard now, reopen if not. *** This bug has been marked as a duplicate of 45578 *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45421
[Bug tree-optimization/45598] New: [4.6 Regression] ICE; in build_int_cst_wide, at tree.c:1218
Between revisions 163966 (working) and 164000 compiling the following test gives an ICE with -O[23s] [macbook] f90/bug% cat pr30940.f90 program main implicit none character(len=10) :: digit_string = '123456789' character :: digit_arr(10) call copy(digit_string, digit_arr) print '(1x, a1)',digit_arr(1:9) contains subroutine copy(in, out) character, dimension(10) :: in, out out(1:10) = in(1:10) end subroutine copy end program main [macbook] f90/bug% gfc -O2 pr30940.f90 pr30940.f90: In function 'MAIN__': pr30940.f90:1:0: internal compiler error: in build_int_cst_wide, at tree.c:1218 -- Summary: [4.6 Regression] ICE; in build_int_cst_wide, at tree.c:1218 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45598
[Bug tree-optimization/45598] [4.6 Regression] ICE; in build_int_cst_wide, at tree.c:1218
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-09-08 13:53 --- #4 0x00b25f5e in fold_const_aggregate_ref (t=0x77f0cc18) at /space/rguenther/src/svn/trunk/gcc/tree-ssa-ccp.c:1444 1444return build_int_cst_type (TREE_TYPE (t), (gdb) l 1439 == TYPE_MODE (TREE_TYPE (TREE_TYPE (ctor 1440 (GET_MODE_CLASS (TYPE_MODE (TREE_TYPE (TREE_TYPE (ctor 1441 == MODE_INT) 1442 GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (TREE_TYPE (ctor == 1 1443 double_int_cmp (index_cst, length_cst, signed_p) 0) 1444return build_int_cst_type (TREE_TYPE (t), 1445 (TREE_STRING_POINTER (ctor) 1446[double_int_to_uhwi (index_cst)])); 1447 return NULL_TREE; 1448} (gdb) p t-common.type-base.code $2 = ARRAY_TYPE -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-08 13:53:34 date|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45598
[Bug fortran/45595] segfault on omp collapse
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-08 14:02 --- Created an attachment (id=21738) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21738action=view) gcc46-pr45595.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45595
[Bug preprocessor/45599] New: Remove all code applying to obsolete #pragma once
The pragma once is obsolete due to cpp optimizations and #pragma once can be completely ignored. Any code referring to it should be removed. -- Summary: Remove all code applying to obsolete #pragma once Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot browder at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45599
[Bug fortran/45597] [4.6 Regression] ICE: in gfc_trans_cycle, at fortran/trans-stmt.c:4320
--- Comment #1 from jakub at gcc dot gnu dot org 2010-09-08 14:25 --- Created an attachment (id=21739) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21739action=view) gcc46-pr45597.patch Seems to be a recent regression, caused by http://gcc.gnu.org/viewcvs?view=revisionrevision=163798 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45597
[Bug preprocessor/45599] Remove all code applying to obsolete #pragma once
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-09-08 14:46 --- #pragma once Can you explain why you think it can be completely ignored? It can be used without macro guards. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45599
[Bug fortran/45577] [4.6 Regression] Bogus(?) ... type incompatible with source-expr ... error
--- Comment #6 from dominiq at lps dot ens dot fr 2010-09-08 14:46 --- Here is a better patch: ... Yes! it accepts program main type b_obj integer,allocatable :: c(:) real :: r = 5. end type b_obj type (b_obj),allocatable :: b(:) integer,allocatable :: c(:) integer :: i,n n = 3 allocate(b(n),c(n)) end program main It passed my tests (it may even fixed another ICE, I am reducing) and regtested without regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45577
[Bug libstdc++/45574] cin.getline() is extremely slow
--- Comment #13 from jakub at gcc dot gnu dot org 2010-09-08 14:48 --- And, getdelim insist on allocating resp. reallocating the buffer. That is of course usually desirable when used from C, but I'm afraid it isn't in this case, where you have user provided buffer with fixed size. You don't want to read more than that size, while getdelim will read any amount of data. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45574
[Bug preprocessor/45599] Remove all code applying to obsolete #pragma once
--- Comment #2 from tom dot browder at gmail dot com 2010-09-08 15:02 --- Ah, you are correct--old code may have that only. How about a warning instead about using the recommended construct (the header guard) instead of the pragma once? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45599
[Bug preprocessor/45599] Remove all code applying to obsolete #pragma once
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-08 15:04 --- At one point we deprecated it and then undeprecated it. See PR 11569. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45599
[Bug preprocessor/45599] Remove all code applying to obsolete #pragma once
--- Comment #4 from tom dot browder at gmail dot com 2010-09-08 15:29 --- Oops, I missed that PR. I still think that an optional warning should be there--something like -Wpragma-once with a message about the better practice. (Sorry I missed finding the original bug--I only looked at open bugs--I now know better.) -- tom dot browder at gmail dot com changed: What|Removed |Added CC||tom dot browder at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45599
[Bug tree-optimization/45598] [4.6 Regression] ICE; in build_int_cst_wide, at tree.c:1218
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-08 15:30 --- On Linux/x86-64, revision 163997 failed to build 191.fma3d in SPEC CPU 2K: [...@gnu-27 0001]$ /export/gnu/import/svn/gcc-test/usr/bin/gfortran -c -o getirv.o -DSPEC_CPU2000_LP64 -O3 -funroll-loops -ffast-math getirv.f90 getirv.f90: In function rcrdrd: getirv.f90:213:0: internal compiler error: in build_int_cst_wide, at tree.c:1218 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [...@gnu-27 0001]$ -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com GCC build triplet|x86_64-apple-darwin10 | GCC host triplet|x86_64-apple-darwin10 | GCC target triplet|x86_64-apple-darwin10 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45598
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #10 from sfilippone at uniroma2 dot it 2010-09-08 15:35 --- (In reply to comment #9) I have found a cure. The original configuration had GMP, MPFR and MPC built and installed under the user home directory (there were neither mpfr nor mpc system-wide, and gmp was a bit old); somehow this is the root cause of the problem, despite --with-gmp and friends. Building the three packages from source in the GCC source tree gets the bootstrap process beyond the previous stopping point (currently in middle of stage 3). Maybe this should be added to the platform-specific notes? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug fortran/45577] [4.6 Regression] Bogus(?) ... type incompatible with source-expr ... error
--- Comment #7 from dominiq at lps dot ens dot fr 2010-09-08 15:52 --- The following code reduced from http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/76f99e7fd4f3e772# module type2_type implicit none type, abstract :: Type2 character :: typeName*(30) = unknown end type Type2 end module type2_type module extended2A_type use type2_type implicit none type, extends(Type2) :: Extended2A real(kind(1.0D0)) :: coeff1 = 1. real(kind(1.0D0)) :: coeff2 = 2. contains procedure :: setCoeff1 = Extended2A_setCoeff1 end type Extended2A contains function Extended2A_new(c1, c2) result(typePtr_) real(kind(1.0D0)), optional, intent(in) :: c1 real(kind(1.0D0)), optional, intent(in) :: c2 type(Extended2A), pointer :: typePtr_ type(Extended2A), save, allocatable, target :: type_ allocate(type_) typePtr_ = null() if (present(c1)) call type_%setCoeff1(c1) typePtr_ = type_ if ( .not.(associated (typePtr_))) then stop 'Error initializing Extended2A Pointer.' endif end function Extended2A_new subroutine Extended2A_setCoeff1(this,c1) class(Extended2A) :: this real(kind(1.0D0)), intent(in) :: c1 this% coeff1 = c1 end subroutine Extended2A_setCoeff1 end module extended2A_type module type1_type use type2_type implicit none type Type1 class(type2), pointer :: type2Ptr = null() contains procedure :: initProc = Type1_initProc end type Type1 contains function Type1_initProc(this) result(iError) use extended2A_type implicit none class(Type1) :: this integer :: iError this% type2Ptr = extended2A_new() if ( .not.( associated(this% type2Ptr))) then iError = 1 write(*,'(A)') Something Wrong. else iError = 0 endif end function Type1_initProc end module type1_type program main use type1_type use extended2A_type implicit none integer :: iErr, i integer :: numArgs character, dimension(:), allocatable :: tempArgs*(100) class(type1), allocatable :: thisType1 allocate (Type1::thisType1) iErr = thisType1%initProc() deallocate (thisType1% type2Ptr) ! What happens here??? See questions below. ! now the pointer should be dangling and needs to be nullified / reassigned end program main gives a segmentation fault when compiled with revision 163966 without the patch in comment #5, backtrace Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0010 0x0001000c6120 in gfc_trans_structure_assign (dest=0x142504cc0) at ../../p_work/gcc/fortran/trans-expr.c:4436 4436 tmp = fold_build3_loc (input_location, COMPONENT_REF, TREE_TYPE (field), (gdb) bt #0 0x0001000c6120 in gfc_trans_structure_assign (dest=0x142504cc0) at ../../p_work/gcc/fortran/trans-expr.c:4436 #1 0x0001000c692a in gfc_trans_structure_assign (dest=0x142503c80) at ../../p_work/gcc/fortran/trans-expr.c:4381 while it compiles at revision 164002 with the patch. I'll try to revert the patch tonight to see if the gone ICE is due to it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45577
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #11 from mikpe at it dot uu dot se 2010-09-08 16:00 --- (In reply to comment #10) (In reply to comment #9) I have found a cure. The original configuration had GMP, MPFR and MPC built and installed under the user home directory (there were neither mpfr nor mpc system-wide, and gmp was a bit old); somehow this is the root cause of the problem, despite --with-gmp and friends. Building the three packages from source in the GCC source tree gets the bootstrap process beyond the previous stopping point (currently in middle of stage 3). Maybe this should be added to the platform-specific notes? How did you configure those prebuilt gmp/mpfr/mpc libraries installed under your home directory? In particular, did you configure them all with --disable-shared? If not, then you have to be extremely careful to avoid unintended mismatches, and in some cases incorrectly duplicated state. I know for a fact that prebuilt gmp/mpfr/mpc installed in a private location works fine on powerpc64-linux when all are configured with --disable-shared. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug c/45600] New: gcc generates illegal AVX aligned moves
For the attached testcase, gcc generates a vmovapd for the store to llvm_cbe__24__StackDv_P53. The latest Intel sde generates an alignment error: SDE ERROR: ALIGN32 FAILED PC=40048b MEMEA=7ff057d0 vmovapd ymmword ptr [rax], ymm0 It looks like gcc is considering 16-byte aligned data to be suitable for a 256-bit vmovapd, which it isn't. -- Summary: gcc generates illegal AVX aligned moves Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: greened at obbligato dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
[Bug c/45600] gcc generates illegal AVX aligned moves
--- Comment #1 from greened at obbligato dot org 2010-09-08 16:08 --- Compile with -c -mavx reduced.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
[Bug c/45600] gcc generates illegal AVX aligned moves
--- Comment #2 from greened at obbligato dot org 2010-09-08 16:09 --- Created an attachment (id=21740) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21740action=view) Reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #12 from sfilippone at uniroma2 dot it 2010-09-08 16:11 --- (In reply to comment #11) (In reply to comment #10) How did you configure those prebuilt gmp/mpfr/mpc libraries installed under your home directory? In particular, did you configure them all with --disable-shared? If not, then you have to be extremely careful to avoid unintended mismatches, and in some cases incorrectly duplicated state. I know for a fact that prebuilt gmp/mpfr/mpc installed in a private location works fine on powerpc64-linux when all are configured with --disable-shared. Indeed, they were shared. The thing that caught me is that I have built GCC hundreds of times on i686/x86_64 with shared, private dir gmp/mpfr/mpc without a problem, so I went ahead and did the same on this machine; I normally bootstrap on my two main machines the 4.6 trunk every other day. Of course I am not claiming I didn't do anything wrong, just that it was not obvious from the various docs, including platform notes, that it was safer to use disable-shared or build from the GCC source tree. Anyway, my problem is fixed, and I know a bit more than yesterday; thanks everybody. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug tree-optimization/20517] bit shift/mask optimization potential
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-08 16:19 --- Yes, please, and assign to me (working on a simplify_comparison fix for that). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20517
[Bug tree-optimization/45598] [4.6 Regression] ICE; in build_int_cst_wide, at tree.c:1218
--- Comment #3 from hjl dot tools at gmail dot com 2010-09-08 16:19 --- This is caused by revision 163973: http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00265.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45598
[Bug rtl-optimization/43491] Unnecessary temporary for global register variable
--- Comment #1 from ibolton at gcc dot gnu dot org 2010-09-08 16:21 ---
reg is assigned to a temporary (reg.0) at the very first tree pass, as shown by
this 004t.gimple dump:
d ()
{
struct b * const reg.0;
unsigned int * D.2019;
int D.2020;
goto D.1276;
D.1275:
c ();
D.1276:
reg.0 = reg;
D.2019 = reg.0-j;
D.2020 = diff (D.2019);
if (D.2020 != 0) goto D.1275; else goto D.1277;
D.1277:
}
I'm thinking that this is perfectly normal thing to do, and that the redundant
move is meant to disappear in a later pass. My guess is that IRA is choosing
not to assign the pseudo to r4, but I do not know why at the moment.
--
ibolton at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||missed-optimization, ra
Known to fail||4.5.3 4.6.0
Last reconfirmed|-00-00 00:00:00 |2010-09-08 16:21:50
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491
[Bug bootstrap/45174] Make fails in zlib
--- Comment #24 from rwild at gcc dot gnu dot org 2010-09-08 16:26 --- (In reply to comment #22) I've just read this thread and am now unsure as to whether there is a bug with GCC or not. It sounds like your initial troubles have gone away and now there is a new problem. Would it make sense to close this bug and raise a new bug to cover the new issue? It would make sense to treat any issues that Donald has in a new PR (after making sure they are not setup problems). However, I am fairly sure that comment #13 describes a real issue, as it has been reported to Libtool before, and there is a Libtool testsuite addition that exposes link tests in AC_PROG_LIBTOOL that are not guarded by a cache variable. The issue described by #13 may be latent in GCC. I haven't tried to reproduce it there yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45174
[Bug c++/45601] New: explicit template instanciation problem
The explicit template instantiation fails. As far as I can find on the net, it should work. See attached minimal test case. -- Summary: explicit template instanciation problem Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: stephane at magnenat dot net GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45601
[Bug c++/45601] explicit template instanciation problem
--- Comment #1 from stephane at magnenat dot net 2010-09-08 16:30 --- Created an attachment (id=21741) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21741action=view) Minimal test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45601
[Bug c++/45601] explicit template instanciation problem
--- Comment #2 from stephane at magnenat dot net 2010-09-08 16:31 --- Output of g++ -v -save-temps -o test.o -c test.cpp : Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test.o' '-c' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.4.3/cc1plus -E -quiet -v -D_GNU_SOURCE test.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -fpch-preprocess -fstack-protector -o test.ii ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu ignoring nonexistent directory /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../x86_64-linux-gnu/include ignoring nonexistent directory /usr/include/x86_64-linux-gnu #include ... search starts here: #include ... search starts here: /usr/include/c++/4.4 /usr/include/c++/4.4/x86_64-linux-gnu /usr/include/c++/4.4/backward /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.4.3/include /usr/lib/gcc/x86_64-linux-gnu/4.4.3/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'test.o' '-c' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.4.3/cc1plus -fpreprocessed test.ii -quiet -dumpbase test.cpp -mtune=generic -auxbase-strip test.o -version -fstack-protector -o test.s GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (x86_64-linux-gnu) compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (Ubuntu 4.4.3-4ubuntu5) version 4.4.3 (x86_64-linux-gnu) compiled by GNU C version 4.4.3, GMP version 4.3.2, MPFR version 2.4.2-p1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 88858f45841827736473e527a4e9ab10 test.cpp:27: error: template-id h for void h(Tint::U) does not match any template declaration -- stephane at magnenat dot net changed: What|Removed |Added CC||stephane at magnenat dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45601
[Bug c++/45601] explicit template instantiation problem
--- Comment #3 from paolo dot carlini at oracle dot com 2010-09-08 16:44 --- Please clarify: As far as I can find on the net, it should work. No compiler to which I have access compiles it, I tried, besides GCC, Intel, SunStudio, Comeau, VC++8. Note I didn't really analyze the testcase from the Standard point of view, at the moment I'm just curious to understand how you came to that conclusion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45601
[Bug fortran/45595] segfault on omp collapse
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-08 16:46 --- Subject: Bug 45595 Author: jakub Date: Wed Sep 8 16:46:13 2010 New Revision: 164004 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164004 Log: PR fortran/45595 * openmp.c (resolve_omp_do): Report not enough do loops for collapse even if block-next is NULL. * gfortran.dg/gomp/pr45595.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr45595.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45595
[Bug fortran/45597] [4.6 Regression] ICE: in gfc_trans_cycle, at fortran/trans-stmt.c:4320
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-08 16:47 --- Subject: Bug 45597 Author: jakub Date: Wed Sep 8 16:47:16 2010 New Revision: 164005 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164005 Log: PR fortran/45597 * trans-openmp.c (gfc_trans_omp_do): Store exit/cycle labels on code instead of code-block. * gfortran.dg/gomp/pr45597.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr45597.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-openmp.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45597
[Bug c++/45601] explicit template instantiation problem
--- Comment #4 from paolo dot carlini at oracle dot com 2010-09-08 16:58 --- Actually, it seems pretty straightforward to me that S is nondeduced in the last case: see 14.8.2.4/4, the last line. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45601
[Bug tree-optimization/44972] [4.6 Regression] ICE: in load_assign_lhs_subreplacements, at tree-sra.c:2475
--- Comment #14 from jamborm at gcc dot gnu dot org 2010-09-08 17:01 --- Patches submitted to the mailing list for approval/comments: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00674.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44972
[Bug fortran/43829] Scalarization of reductions
--- Comment #28 from mikael at gcc dot gnu dot org 2010-09-08 17:21 --- (In reply to comment #27) What is the fate of the patch in comment #19? Some (admittedly small) parts of the patch are already on trunk. The transpose patches still waiting review at http://gcc.gnu.org/ml/fortran/2010-09/msg00109.html are the first important step to commit this patch (they prevent one regression). The rest is decaying. :-( But it can still be updated and committed before the end of stage 1. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43829
[Bug fortran/45595] segfault on omp collapse
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-08 17:22 --- Subject: Bug 45595 Author: jakub Date: Wed Sep 8 17:22:36 2010 New Revision: 164007 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164007 Log: PR fortran/45595 * openmp.c (resolve_omp_do): Report not enough do loops for collapse even if block-next is NULL. * gfortran.dg/gomp/pr45595.f90: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/pr45595.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/openmp.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45595
[Bug fortran/45595] segfault on omp collapse
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-08 17:24 --- Subject: Bug 45595 Author: jakub Date: Wed Sep 8 17:23:52 2010 New Revision: 164008 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164008 Log: PR fortran/45595 * openmp.c (resolve_omp_do): Report not enough do loops for collapse even if block-next is NULL. * gfortran.dg/gomp/pr45595.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/gomp/pr45595.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/openmp.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45595
[Bug other/45443] GCC documentation for -O3 flag doesn't mention -fipa-cp-clone
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-09-08 17:27 --- Subject: Bug 45443 Author: jamborm Date: Wed Sep 8 17:27:09 2010 New Revision: 164009 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164009 Log: 2010-09-08 Martin Jambor mjam...@suse.cz PR other/45443 * doc/invoke.texi: Add -fipa-cp-clone to list of switches turned on at -O3. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45443
[Bug other/45443] GCC documentation for -O3 flag doesn't mention -fipa-cp-clone
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-09-08 17:36 --- Subject: Bug 45443 Author: jamborm Date: Wed Sep 8 17:36:40 2010 New Revision: 164011 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164011 Log: 2010-09-08 Martin Jambor mjam...@suse.cz PR other/45443 * doc/invoke.texi: Add -fipa-cp-clone to list of switches turned on at -O3. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/doc/invoke.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45443
[Bug target/45600] gcc generates illegal AVX aligned moves
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-09-08 17:39 --- I think this code is undefined with respect of alignment requirements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
[Bug target/45600] gcc generates illegal AVX aligned moves
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-09-08 17:43 --- Yes this is invalid with respect of alignment requirements. It becomes obvious from the optimized at -O0 on the trunk. v4df llvm_cbe_r5585; v4df llvm_cbe_r5584; struct l_DV1 llvm_cbe__24__StackDv_P53; unsigned int * D.3215; struct l_DV1 * llvm_cbe__24__StackDv_P53.0; bb 2: llvm_cbe__24__StackDv_P53.0_1 = llvm_cbe__24__StackDv_P53; MEM[(v4df *)llvm_cbe__24__StackDv_P53.0_1] = llvm_cbe_r5584_2(D); // requires v4df alignment D.3215_3 = llvm_cbe__24__StackDv_P53.field1.field5; MEM[(struct *)D.3215_3].data = llvm_cbe_r5585_4(D); // requires v4df alignment -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45600
[Bug middle-end/40386] wrong code generation for several SPEC CPU2000 benchmarks (lucas, mgrid, face, applu, apsi) with -O1 -fno-ira-share-spill-slots
--- Comment #9 from vmakarov at redhat dot com 2010-09-08 17:44 --- The problem is in that pseudos (r121 in our case) spilled by IRA are not added to live_throughout of reload chain. As the result, pseudo_forbidden_regs are not set up for such pseudos and they can get a hard registers (42 in our case) even if they live through insns (insn 153 in our case) using reload (0th in our case) with this register when another pseudo is spilled and reload ask IRA to assign the correspodning hard register to other pseudo. Here are some parts of IRA dump: Spilling for insn 153. Using reg 2 for reload 1 Using reg 42 for reload 0 ... Spilling for insn 238. Using reg 2 for reload 0 Spill 117(a35), cost=5000 Spilled regs 117 Try assign 121(a6), cost=5000: reassign to 42 The fix is pretty simple. I'll send it soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40386
[Bug libobjc/23214] libobjc doesn't initialize protocols in some cases
--- Comment #7 from nicola at gcc dot gnu dot org 2010-09-08 17:48 --- Confirmed. Thanks -- nicola at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-09-08 17:48:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23214
[Bug libobjc/23215] libobjc doesn't work on windows.
--- Comment #6 from nicola at gcc dot gnu dot org 2010-09-08 17:49 --- Created an attachment (id=21742) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21742action=view) A tidied up testcase ready for the GCC testsuite -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23215
[Bug tree-optimization/33113] Failing to represent the stride (with array) of a dataref when it is not a constant
--- Comment #8 from dominiq at lps dot ens dot fr 2010-09-08 17:49 --- One of the first thing taught in fortran is that the loop ordering in the test in comment #0 is bad. If the loops are interchanged (as they should) the code vectorize. Is not -floop-interchange supposed to do that if graphite is enabled (actually it does not do it or if it does, it does not allow the code to be vectorized)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113
[Bug libobjc/23215] libobjc doesn't work on windows.
--- Comment #7 from nicola at gcc dot gnu dot org 2010-09-08 17:50 --- Apologies, bugzilla confused me by jumping to the next bug and I attached a testcase to the wrong bug! ;-) Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23215
[Bug fortran/45595] segfault on omp collapse
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-08 17:52 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45595
[Bug libobjc/23214] libobjc doesn't initialize protocols in some cases
--- Comment #8 from nicola at gcc dot gnu dot org 2010-09-08 17:52 --- Created an attachment (id=21743) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21743action=view) A tidied up testcase ready for the GCC testsuite -- nicola at gcc dot gnu dot org changed: What|Removed |Added Attachment #9420 is|0 |1 obsolete|| Attachment #9421 is|0 |1 obsolete|| Attachment #9422 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23214
[Bug fortran/45597] [4.6 Regression] ICE: in gfc_trans_cycle, at fortran/trans-stmt.c:4320
--- Comment #3 from jakub at gcc dot gnu dot org 2010-09-08 17:52 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45597
[Bug tree-optimization/23647] [4.0 Regression] Bug w\ while (1) loop and counter variable w\ optimization
When a while loop with the true condition (while (1)) contains
an if statement with a modulus evaluated on a counter variable, it
appears that gcc incorrectly optimizes out the modulus check as a
constant (even though the counter variable is updated after the if
statement). If the counter variable is updated _before_ the if
statement, it works properly. Example code is in the how-to-repeat section.
Environment:
System: Linux uktena64 2.6.10-5-amd64-k8 #1 Fri Jun 24 17:08:40 UTC 2005 x86_64
GNU/Linux
Architecture: x86_64
host: x86_64-pc-linux-gnu
build: x86_64-pc-linux-gnu
target: x86_64-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc --disable-multilib x86_64-linux
How-To-Repeat:
The following code produces the bug (output is 1 1 1 1 ... instead
of 0 1 2 3 ...):
void main() {
int i=0;
while (1) {
if (i%100==0) printf(%d ,i);
i++;
}
}
--- Comment #1 from Nick at idontproperlyfilloutmyemailaddress dot com
2005-08-31 03:18 ---
Fix:
If i++; is above the if statement, the code works properly
(1 2 3 4 ...).
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-08-31 04:55 ---
Fixed at least in 4.0.2 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c |tree-optimization
Keywords||wrong-code
Resolution||FIXED
Summary|Bug w\ while (1) loop and |[4.0 Regression] Bug w\
|counter variable w\ |while (1) loop and counter
|optimization|variable w\ optimization
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23647
[Bug fortran/34633] Compiler crash on FORALL loop
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-01-01 01:25 --- That is because it is the same as PR 31217. *** This bug has been marked as a duplicate of 31217 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34633
