[Bug target/35661] __attribute__((cold)) generates wrong code

2008-04-07 Thread zuxy dot meng at gmail dot com
--- Comment #3 from zuxy dot meng at gmail dot com 2008-04-07 06:00 --- Created an attachment (id=15437) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15437action=view) Proposed patch against 4.3.0, marking .text.unlikely as executable. --

[Bug target/34787] fix -shared + -pthread for mips/linux

2008-04-07 Thread vapier at gentoo dot org
--- Comment #3 from vapier at gentoo dot org 2008-04-07 06:00 --- this is in gcc-4.3.0 and that's fine by me -- vapier at gentoo dot org changed: What|Removed |Added

[Bug other/35855] New: build locale not properly handled with awk scripts

2008-04-07 Thread vapier at gentoo dot org
the gcc build system has some awk scripts that use unsafe character ranges: $ grep a-z gcc/*.awk gcc/optc-gen.awk: gsub( [^A-Za-z0-9_], X, macros[i] ) gcc/optc-gen.awk: gsub ([^A-Za-z0-9], _, enum) gcc/opt-functions.awk: gsub ([^A-Za-z0-9], _, name) gcc/opth-gen.awk: gsub(

gcc-4.3.0 configure can't identify ld 2.18 version

2008-04-07 Thread Yevgeniy Litvinenko
Hello. I have binutils 2.18 $ ld --version GNU ld (GNU Binutils) 2.18 ... But during compilation of gcc-4.3.0 I get following: configure: WARNING: === Linker version 1800 is too old for configure: WARNING: === full symbol versioning support in this release of GCC. configure: WARNING:

[Bug tree-optimization/35821] Internal compiler error: segmentation fault

2008-04-07 Thread irar at il dot ibm dot com
--- Comment #7 from irar at il dot ibm dot com 2008-04-07 07:06 --- I am testing the following patch: Index: tree-vect-transform.c === --- tree-vect-transform.c (revision 132478) +++ tree-vect-transform.c

[Bug middle-end/35856] New: Wrong CCP -- yielding wrong results at O1 and above

2008-04-07 Thread xinliangli at gmail dot com
// Test case: should print 0 but it prints 10 when compiled at -O or -O2. The culprit is very likely ccp1. #include stdio.h int g; int foo(int i, int j, int* flag) { int t; if (i 0 || j 0) { t = 10; *flag = 1; } if (*flag) g+= t; } int main() { int

Re: [Bug middle-end/35856] New: Wrong CCP -- yielding wrong results at O1 and above

2008-04-07 Thread Andrew Pinski
Sent from my iPhone On Apr 7, 2008, at 0:06, xinliangli at gmail dot com [EMAIL PROTECTED] wrote: // Test case: should print 0 but it prints 10 when compiled at -O or -O2. The culprit is very likely ccp1. I don't think it should t used uninitialized if *flag is true and both I and

[Bug middle-end/35856] Wrong CCP -- yielding wrong results at O1 and above

2008-04-07 Thread pinskia at gmail dot com
--- Comment #1 from pinskia at gmail dot com 2008-04-07 07:10 --- Subject: Re: New: Wrong CCP -- yielding wrong results at O1 and above Sent from my iPhone On Apr 7, 2008, at 0:06, xinliangli at gmail dot com [EMAIL PROTECTED] wrote: // Test case: should print 0 but it

[Bug middle-end/35856] Wrong CCP -- yielding wrong results at O1 and above

2008-04-07 Thread xinliangli at gmail dot com
--- Comment #2 from xinliangli at gmail dot com 2008-04-07 07:30 --- Right, the source is buggy, but looks the compiler misses uninitialized warning -- with -Wuninitialized -- no warning is given. (In reply to comment #1) Subject: Re: New: Wrong CCP -- yielding wrong results at O1

[Bug middle-end/35856] missing unitialized variable warning

2008-04-07 Thread xinliangli at gmail dot com
--- Comment #3 from xinliangli at gmail dot com 2008-04-07 07:39 --- It is debatable whether the const prop should happen in the presence of unitilaized variable, but a warning should be given. -- xinliangli at gmail dot com changed: What|Removed

[Bug libstdc++/35588] [parallel mode] parallel std::sort and bind()

2008-04-07 Thread singler at gcc dot gnu dot org
--- Comment #3 from singler at gcc dot gnu dot org 2008-04-07 08:28 --- Subject: Bug 35588 Author: singler Date: Mon Apr 7 08:27:34 2008 New Revision: 133975 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133975 Log: 2008-04-07 Johannes Singler [EMAIL PROTECTED] *

[Bug tree-optimization/29751] not optimizing access a[0] , a[1]

2008-04-07 Thread rguenth at gcc dot gnu dot org
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-04-07 08:51 --- Only if you extend refs_may_alias_p, as for pointers you have p_2 = p_1 + 1; *p_2 *p_1 and it doesn't follow def-use chains to see the pointer-plus to disambiguate both pointer de-references. With arrays you

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

2008-04-07 Thread oder at eleks dot lviv dot ua
--- Comment #8 from oder at eleks dot lviv dot ua 2008-04-07 08:58 --- Created an attachment (id=15438) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15438action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug tree-optimization/2480] aliasing problem with global structures

2008-04-07 Thread rguenth at gcc dot gnu dot org
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-04-07 09:00 --- This is because the oracle is confused by the link_error () call which clobbers *ex2 and *ex1. Note that SCCVN does not consider control-dependence as it considers all edges executable all the time. --

[Bug c++/35758] [4.3/4.4 Regression] vector_size attribute lost in function arguments for templates

2008-04-07 Thread jakub at gcc dot gnu dot org
--- Comment #15 from jakub at gcc dot gnu dot org 2008-04-07 10:52 --- I've tried the first step - putting the attributes that require type to TYPE_ATTRIBUTES rather than DECL_ATTRIBUTES, see below. Unfortunately tsubst doesn't call apply_late_template_attributes in that case (the only

[Bug middle-end/35856] missing unitialized variable warning

2008-04-07 Thread rguenth at gcc dot gnu dot org
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-07 10:10 --- It's all optimized away before the may-be-used-uninitialized warning is emitted (we only execute warn_uninitialized_phi in the late pass). -- rguenth at gcc dot gnu dot org changed: What|Removed

[Bug c++/35773] [4.3/4.4 regression] auto_ptr references don't convert

2008-04-07 Thread rguenth at gcc dot gnu dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-07 11:56 --- Eventually a fallout from rvalue references? CCing Dough. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug other/35857] New: --disable-shared doesn't build libgcc_eh.a

2008-04-07 Thread pluto at agmk dot net
i noticed that --disable-shared also disables the libgcc_eh.a in libgcc/Makefile.in: (...) ifeq ($(enable_shared),yes) all: libgcc_eh.a libgcc_s$(SHLIB_EXT) ifneq ($(LIBUNWIND),) all: libunwind$(SHLIB_EXT) endif endif (...) imho this looks like a bug. libgcc_eh.a is used with libgcc.a in

[Bug target/35842] ICE in legitimize_pic_address, at config/i386/i386.c:7666

2008-04-07 Thread ktietz at gcc dot gnu dot org
--- Comment #9 from ktietz at gcc dot gnu dot org 2008-04-07 13:35 --- Committed revision 133981. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added

[Bug other/35858] New: time/memory hog for large c++ source.

2008-04-07 Thread pluto at agmk dot net
i've checked 4.1 vs 4.3 on my c++ codebase and 4.3 doesn't look good. more time/mem details are in attached logs. testcase was compiled with following options: -m32 -D_STLP_DEBUG -D_STLP_DEBUG_MODE_THROWS -D_DEBUG -pthread \ -Wall -Wno-uninitialized -Woverloaded-virtual -Werror \ -march=i686

[Bug other/35858] time/memory hog for large c++ source.

2008-04-07 Thread pluto at agmk dot net
--- Comment #1 from pluto at agmk dot net 2008-04-07 14:58 --- Created an attachment (id=15439) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15439action=view) 4.1 stats. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858

[Bug other/35858] time/memory hog for large c++ source.

2008-04-07 Thread pluto at agmk dot net
--- Comment #2 from pluto at agmk dot net 2008-04-07 14:58 --- Created an attachment (id=15440) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15440action=view) 4.3 stats. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858

[Bug other/35858] time/memory hog for large c++ source.

2008-04-07 Thread pluto at agmk dot net
--- Comment #3 from pluto at agmk dot net 2008-04-07 14:59 --- Created an attachment (id=15441) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15441action=view) testcase for 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858

[Bug other/35858] time/memory hog for large c++ source.

2008-04-07 Thread rguenth at gcc dot gnu dot org
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-04-07 15:29 --- Please try --param max-fields-for-field-sensitive=0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858

[Bug target/35839] [4.4 Regression] Altivec with the vectorizer causes an ICE in rs6000_check_sdmode

2008-04-07 Thread janis at gcc dot gnu dot org
--- Comment #3 from janis at gcc dot gnu dot org 2008-04-07 16:48 --- Argh, this is an excellent of example of why full testing is necessary for small changes to a patch that has been fully tested; I thought I could get away with just bootstrapping C and running tests that use decimal

[Bug c++/33486] namespace association doesn't handle parallel namespaces

2008-04-07 Thread jason at redhat dot com
--- Comment #8 from jason at redhat dot com 2008-04-07 17:29 --- Subject: Re: namespace association doesn't handle parallel namespaces bkoz at gcc dot gnu dot org wrote: Hey Jason, can we get this fixed on 4_3-branch? (Could probably get away with just gcc/cp/name-lookup.c fix,

[Bug preprocessor/35859] New: preprocessor segfaults when #include directive passed to macro

2008-04-07 Thread kulhanek dot 5 at wright dot edu
Build command: cat M -- Summary: preprocessor segfaults when #include directive passed to macro Product: gcc Version: 4.0.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: preprocessor

[Bug preprocessor/35859] preprocessor segfaults when #include directive passed to macro

2008-04-07 Thread kulhanek dot 5 at wright dot edu
--- Comment #1 from kulhanek dot 5 at wright dot edu 2008-04-07 19:29 --- (oops, hit enter on the wrong screen) Error message: In file included from test.h:2: test.def:2:2: warning: embedding a directive within macro arguments is not portable In file included from

[Bug other/35858] time/memory hog for large c++ source.

2008-04-07 Thread pluto at agmk dot net
--- Comment #5 from pluto at agmk dot net 2008-04-07 20:25 --- (In reply to comment #4) Please try --param max-fields-for-field-sensitive=0 it helps. TOTAL: 67.59 3.99 71.69 1220782 kB -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35858

[Bug c++/35734] [4.3/4.4 regression] ICE with copy constructor in derived class

2008-04-07 Thread jason at gcc dot gnu dot org
--- Comment #2 from jason at gcc dot gnu dot org 2008-04-07 20:51 --- Subject: Bug 35734 Author: jason Date: Mon Apr 7 20:50:21 2008 New Revision: 133987 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133987 Log: PR c++/35734 * class.c

[Bug c/35860] New: code bloat caused by -fsplit-wide-types

2008-04-07 Thread a dot kaiser at gmx dot net
Command: avr-gcc -O1 -S div32_7.c or avr-gcc -O1 -fno-split-wide-types -S div32_7.c Code size 4.1.2: 0x28 Code size 4.3.0: 0x68 Code size 4.3.0: 0x28 with -fno-split-wide-types // unsigned long udivr32_7( unsigned long a, unsigned char b, unsigned char *r ) { unsigned char

[Bug target/35860] code bloat caused by -fsplit-wide-types

2008-04-07 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-07 21:38 --- I think this is already fixed on the trunk, fword prop was not proping as much as it should have. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/35861] New: code bloat due to -finline-small-functions

2008-04-07 Thread a dot kaiser at gmx dot net
In 4.3.0 -finline-small-functions cause excessive code bloat even though according to the docs this option should not significantly increase code size. Code size 4.1.2: 0x8A Code size 4.3.0: 0x1EA Code size 4.3.0: 0x88 with -fno-inline-small-functions Command line: avr-gcc -Os -c rf12.c or

[Bug c/35861] code bloat due to -finline-small-functions

2008-04-07 Thread a dot kaiser at gmx dot net
--- Comment #1 from a dot kaiser at gmx dot net 2008-04-07 21:54 --- Created an attachment (id=15442) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15442action=view) sample code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35861

[Bug middle-end/35861] code bloat due to -finline-small-functions

2008-04-07 Thread pinskia at gcc dot gnu dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-07 21:59 --- I think this is just a miscounting of inline-asm. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/35830] ICE with PROCEDURE(interface) containing array formal arguments

2008-04-07 Thread jaydub66 at gmail dot com
--- Comment #3 from jaydub66 at gmail dot com 2008-04-07 22:01 --- Another thing I just noticed is that dummy procedures are currently not checked for being called with the right arguments (- compare_actual_formal), e.g. in the above test case call f([1,2,3]) could also be called with a

[Bug fortran/25829] [F2003] Asynchronous IO support

2008-04-07 Thread jvdelisle at gcc dot gnu dot org
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-04-07 22:06 --- Subject: Bug 25829 Author: jvdelisle Date: Mon Apr 7 22:05:52 2008 New Revision: 133988 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133988 Log: 2008-04-07 Jerry DeLisle [EMAIL PROTECTED] PR

[Bug fortran/25829] [F2003] Asynchronous IO support

2008-04-07 Thread jvdelisle at gcc dot gnu dot org
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-04-07 22:08 --- Subject: Bug 25829 Author: jvdelisle Date: Mon Apr 7 22:07:44 2008 New Revision: 133989 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133989 Log: 2008-04-07 Jerry DeLisle [EMAIL PROTECTED] PR

[Bug fortran/25829] [F2003] Asynchronous IO support

2008-04-07 Thread jvdelisle at gcc dot gnu dot org
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-04-07 22:11 --- Subject: Bug 25829 Author: jvdelisle Date: Mon Apr 7 22:10:41 2008 New Revision: 133991 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133991 Log: 2008-04-07 Jerry DeLisle [EMAIL PROTECTED] PR

[Bug middle-end/35861] code bloat due to -finline-small-functions

2008-04-07 Thread a dot kaiser at gmx dot net
--- Comment #3 from a dot kaiser at gmx dot net 2008-04-07 22:14 --- Created an attachment (id=15443) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15443action=view) sample code w/o inline assembly Same situation when inline asm is removed. --

[Bug fortran/28655] [F2003] In/output: DECIMAL=/dp/dc; SIGN=/S/SP/SS BLANK=/PAD=; DELIM=; ENCODING=

2008-04-07 Thread jvdelisle at gcc dot gnu dot org
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-04-07 22:29 --- Now completed. INQUIRE functions work. Closing this PR will open seorate PRS for the run time items UTF-8 and ROUNDing modes. -- jvdelisle at gcc dot gnu dot org changed: What|Removed

[Bug libfortran/35862] New: [F2003] Implement new rounding modes for run time

2008-04-07 Thread jvdelisle at gcc dot gnu dot org
The front-end parsing and translation are completed. We now need to determine how to implement UP, DOWN, COMPATIBLE, NEAREST, etc. in output_float. -- Summary: [F2003] Implement new rounding modes for run time Product: gcc Version: 4.4.0 Status:

[Bug libfortran/35863] New: [F2003] Implement ENCODING=UTF-8

2008-04-07 Thread jvdelisle at gcc dot gnu dot org
Front end and library are ready to handle this when implemented. -- Summary: [F2003] Implement ENCODING=UTF-8 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran

[Bug target/34210] ffs builtin calls undefined __ffshi2

2008-04-07 Thread hutchinsonandy at gcc dot gnu dot org
--- Comment #7 from hutchinsonandy at gcc dot gnu dot org 2008-04-07 23:16 --- Subject: Bug 34210 Author: hutchinsonandy Date: Mon Apr 7 23:15:35 2008 New Revision: 133993 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133993 Log: PR target/34210 PR target/35508 * config.host

[Bug target/35508] [avr] 4.3.0: undefined reference to `__ffshi2'

2008-04-07 Thread hutchinsonandy at gcc dot gnu dot org
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2008-04-07 23:16 --- Subject: Bug 35508 Author: hutchinsonandy Date: Mon Apr 7 23:15:35 2008 New Revision: 133993 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133993 Log: PR target/34210 PR target/35508 * config.host

[Bug fortran/35864] New: [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90 for cris-elf

2008-04-07 Thread hp at gcc dot gnu dot org
With r133964, this test passed. With 133965 I see: f951: internal compiler error: Segmentation fault Backtrace (f951 recompiled with CFLAGS=-g) (gdb) bt #0 splay_tree_delete (sp=0x103f880) at /home/hp/combh/combined/libiberty/splay-tree.c:67 #1 0x00423c96 in gfc_free_expr

Re: gcc-4.3.0 configure can't identify ld 2.18 version

2008-04-07 Thread Jim Wilson
Yevgeniy Litvinenko wrote: I've found out that two configure scripts can not determine the linker version. These scripts are: gcc-4.3.0/libstdc++-v3/configure and gcc-4.3.0/libgomp/configure We don't track bugs mailed to the gcc-bugs mailing list. File a problem in bugzilla, or ask on

[Bug target/35695] [4.3 Regression] -funroll-loops breaks inline float divide

2008-04-07 Thread wilson at gcc dot gnu dot org
--- Comment #7 from wilson at gcc dot gnu dot org 2008-04-07 23:48 --- Anyone care whether this gets fixed in 4.3? If so, are you willing to test it? I'll approve it for 4.3 with proper testing, which is not easy for me to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695

[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90 for cris-elf

2008-04-07 Thread jvdelisle at verizon dot net
--- Comment #1 from jvdelisle at verizon dot net 2008-04-07 23:49 --- Subject: Re: New: [4.4 Regression] Revision 133965broke gfortran.dg/initialization_1.f90 for cris-elf On Mon, 2008-04-07 at 23:18 +, hp at gcc dot gnu dot org wrote: With r133964, this test passed. With

[Bug fortran/35864] [4.4 Regression] Revision 133965 broke gfortran.dg/initialization_1.f90 for cris-elf

2008-04-07 Thread hp at gcc dot gnu dot org
--- Comment #2 from hp at gcc dot gnu dot org 2008-04-08 00:12 --- (In reply to comment #1) It is not target specific. Ah, I was a bit worried that it was. Since the failure had been there all day, and noone have entered a matching PR or mentioning it on the lists, I just *assumed*

[Bug fortran/35865] New: Spurious warning for vector-valued functions passed as arguments

2008-04-07 Thread john dot young at jrc dot co dot jp
In the code below, the following warning is produced Waring: Actual argument contains too few elements for dummy argument 'func' (1/3) at (1) If the function result is changed to a scalar instead of a vector, no warning is produced. I do not know the standard well enough to know if this is a

[Bug fortran/35865] Spurious warning for vector-valued functions passed as arguments

2008-04-07 Thread john dot young at jrc dot co dot jp
--- Comment #1 from john dot young at jrc dot co dot jp 2008-04-08 01:42 --- Created an attachment (id=15444) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15444action=view) code to produce spurious warning described in bug report --

[Bug target/35866] New: Vector load/store from a packed struct does not work (without -mstrict-align)

2008-04-07 Thread pinskia at gcc dot gnu dot org
Testcase: #define vector __attribute__((vector_size(16) )) #pragma pack(push, r1, 1) struct a { char t; vector float f; }; #pragma pack(push, r1, 1) vector float f(struct a * b, vector float a) { return b-f = a; } CUT --- We use directly a stvx instruction here and this will store

[Bug target/35866] Vector load/store from a packed struct does not work (without -mstrict-align)

2008-04-07 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-04-08 02:00 --- (In reply to comment #0) We use directly a stvx instruction here and this will store in the incorrect position. as stvx masks out the lower bits for a 16byte aligned address. -- pinskia at gcc dot gnu dot org

[Bug target/35866] Vector load/store from a packed struct does not work (without -mstrict-align)

2008-04-07 Thread pinskia at gcc dot gnu dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-08 02:04 --- With -mstrict-align, we get the correct (but suboptimal) answer as the middle-end knows that load and stores cannot handled unaligned addresses. I think we need more flexible TARGET_STRICT_ALIGN which is based on a

[Bug rtl-optimization/35841] [ira] segfault while building libgcc

2008-04-07 Thread vmakarov at redhat dot com
--- Comment #1 from vmakarov at redhat dot com 2008-04-08 02:39 --- I think the problem has been solved by http://gcc.gnu.org/ml/gcc-patches/2008-04/msg00469.html I need some time to check it because my sun machine is too slow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35841

[Bug target/35867] New: [4.4 Regression]: gcc.target/i386/addr-sel-1.c

2008-04-07 Thread hjl dot tools at gmail dot com
With revision134001 , I got Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /export/gnu/src/gcc/gcc/gcc/testsuite/gcc.target/i386/addr-sel-1.c -O2 -mtune=i686 -fno-show-column -S -m32 -o addr-sel-1.s(timeout = 300) PASS: