[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #11 from howarth at nitro dot med dot uc dot edu 2010-08-31 07:04 --- Using the proposed PR36502v2.patch, which eliminates any attempts to change the default stack boundary handling in gcc trunk, I find the following regressions at -m32 on x86_64-apple-darwin10... FAIL:

[Bug bootstrap/45444] [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]

2010-08-31 Thread ramana at gcc dot gnu dot org
--- Comment #2 from ramana at gcc dot gnu dot org 2010-08-31 08:15 --- confirmed. I was working on fixing this but you beat my patch to it. cheers Ramana -- ramana at gcc dot gnu dot org changed: What|Removed |Added

[Bug lto/44992] ld -r breaks LTO

2010-08-31 Thread rguenth at gcc dot gnu dot org
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-08-31 09:13 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug lto/44992] ld -r breaks LTO

2010-08-31 Thread andi-gcc at firstfloor dot org
--- Comment #8 from andi-gcc at firstfloor dot org 2010-08-31 09:32 --- Sorry this is not fixed yet, only partially. Still working on the last bits, in particular passthrough of non LTOed code like assembler functions. -- andi-gcc at firstfloor dot org changed: What

[Bug middle-end/45458] [4.5/4.6 Regression] ICE: in add_labels_and_missing_jumps, at bb-reorder.c:1306 with-fnon-call-exceptions -freorder-blocks-and-partition -fprofile-use

2010-08-31 Thread rguenth at gcc dot gnu dot org
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|ICE: in |[4.5/4.6 Regression] ICE: in

[Bug c/45457] [4.6 Regression] ICE: invalid built-in macro __DBL_DENORM_MIN__

2010-08-31 Thread rguenth at gcc dot gnu dot org
-- 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=45457

[Bug rtl-optimization/45454] [4.6 Regression] ICE: in verify_target_availability, at sel-sched.c:1614

2010-08-31 Thread rguenth at gcc dot gnu dot org
-- 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=45454

[Bug tree-optimization/45453] [4.6 Regression] ICE: verify_cgraph_node failed: inlined_to pointer set for noninline callers with -O2 -fno-early-inlining

2010-08-31 Thread rguenth at gcc dot gnu dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-31 09:56 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC|

[Bug testsuite/45455] gcc.dg/vect/vect-cond-4.c uses uninitialised variable

2010-08-31 Thread rguenth at gcc dot gnu dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-08-31 10:01 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug testsuite/45455] gcc.dg/vect/vect-cond-4.c uses uninitialised variable

2010-08-31 Thread rguenth at gcc dot gnu dot org
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-08-31 10:01 --- Subject: Bug 45455 Author: rguenth Date: Tue Aug 31 10:01:04 2010 New Revision: 163669 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163669 Log: 2010-08-31 Richard Guenther rguent...@suse.de PR

[Bug middle-end/45461] New: [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg

2010-08-31 Thread zsojka at seznam dot cz
Compiler output: $ gcc -fshort-enums testcase.c testcase.c: In function 'foo': testcase.c:12:29: warning: 'enum E' is promoted to 'int' when passed through '...' [enabled by default] testcase.c:12:29: note: (so you should pass 'int' not 'enum E' to 'va_arg') testcase.c:12:29: note: if this code is

[Bug middle-end/45461] [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg

2010-08-31 Thread zsojka at seznam dot cz
--- Comment #1 from zsojka at seznam dot cz 2010-08-31 10:12 --- Created an attachment (id=21600) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21600action=view) reduced testcase $ gcc -fshort-enums pr45461.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45461

[Bug middle-end/45461] [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg

2010-08-31 Thread jakub at gcc dot gnu dot org
-- 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

[Bug preprocessor/45457] [4.6 Regression] ICE: invalid built-in macro __DBL_DENORM_MIN__

2010-08-31 Thread jakub at gcc dot gnu dot org
--- Comment #1 from jakub at gcc dot gnu dot org 2010-08-31 11:24 --- Created an attachment (id=21601) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21601action=view) gcc46-pr45457.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45457

[Bug fortran/38282] Add the remaining HPF bit intrinsics

2010-08-31 Thread fxcoudert at gcc dot gnu dot org
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2010-08-31 11:26 --- Patch submitted at http://gcc.gnu.org/ml/fortran/2010-08/msg00476.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/39694] [4.4 only] -print-file-name doesn't work on mingw in 100%.

2010-08-31 Thread fxcoudert at gcc dot gnu dot org
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.5.0 |4.5.0 4.6.0 Summary|-print-file-name doesn't|[4.4

[Bug c++/45462] New: Bad optimization in -O3 sometimes

2010-08-31 Thread yotambarnoy at gmail dot com
This bug was very hard to trace. I'm on the ScummVM dev team and I develop specifically for the PSP(MIPS). I came across a crash when trying to start one of our engines. The bug only occurred under very specific circumstances -- I bisected it and adding class variables or adding some code made it

[Bug rtl-optimization/45353] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()

2010-08-31 Thread ebotcazou at gcc dot gnu dot org
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2010-08-31 11:52 --- Subject: Bug 45353 Author: ebotcazou Date: Tue Aug 31 11:52:01 2010 New Revision: 163670 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163670 Log: Backport from mainline 2010-08-20 Jakub

[Bug c++/45462] Bad optimization in -O3 sometimes

2010-08-31 Thread yotambarnoy at gmail dot com
--- Comment #1 from yotambarnoy at gmail dot com 2010-08-31 11:52 --- Created an attachment (id=21602) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21602action=view) Logic.ii, where gcc makes the mistake LogicUp() is the critical function --

[Bug rtl-optimization/45353] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in sel_bb_head, at sel-sched-ir.c:4329 with -fselective-scheduling and __builtin_unreachable()

2010-08-31 Thread ebotcazou at gcc dot gnu dot org
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2010-08-31 11:53 --- On the 4.5 branch as well. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/45462] Bad optimization in -O3 sometimes

2010-08-31 Thread yotambarnoy at gmail dot com
--- Comment #2 from yotambarnoy at gmail dot com 2010-08-31 11:53 --- Created an attachment (id=21603) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21603action=view) header.h, used by logic.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45462

[Bug middle-end/45461] [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg

2010-08-31 Thread jakub at gcc dot gnu dot org
--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-31 11:55 --- Created an attachment (id=21604) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21604action=view) gcc46-pr45461.patch Untested fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45461

[Bug target/45452] Change default link order for x86_64-mingw32

2010-08-31 Thread ktietz at gcc dot gnu dot org
--- Comment #1 from ktietz at gcc dot gnu dot org 2010-08-31 12:17 --- Ok, patch sent to gcc's ML. This issue can lead to troubles on Windows OSes Vista or newer. But this bug isn't just x86_64-*-mingw32 one. It affects (if more recent import-libraries are used) even 32-bit mingw and

[Bug fortran/45463] New: gfortran internal write bug

2010-08-31 Thread david dot sagan at gmail dot com
Consider the following code: program test implicit none character(40) line line = 'Hello World!' write (line, '(i3, 2x, a)') 7, trim(line) print *, line end program With the gfortran compiler (v4.5.1) the output is: 77lo World! I would expect the output to be 7 Hello World!

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #12 from howarth at nitro dot med dot uc dot edu 2010-08-31 12:57 --- Testresults for PR36502v2.patch at http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg03098.html. It appears that the only additional failures triggered by this patch are listed in comment 11. --

[Bug fortran/45463] gfortran internal write bug

2010-08-31 Thread kargl at gcc dot gnu dot org
--- Comment #1 from kargl at gcc dot gnu dot org 2010-08-31 13:28 --- Did you see the responses to your post in c.l.f? It seems that your program is non-conforming. I leave the PR open until either I or someone else has time to verify the conformity of the program. --

[Bug target/39694] -print-file-name doesn't work on mingw in 100%.

2010-08-31 Thread pluto at agmk dot net
--- Comment #2 from pluto at agmk dot net 2010-08-31 13:45 --- no, it still doesn't work with 4.5.2 on linux hosted cross compiler. gcc finds libgcc_s pretty well during linking: % /local/devel/toolchain45/i686-pc-mingw32.host64.mt_alloc/bin/i686-pc-mingw32-gcc t.c -shared-libgcc

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread hjl dot tools at gmail dot com
--- Comment #13 from hjl dot tools at gmail dot com 2010-08-31 13:48 --- (In reply to comment #9) Created an attachment (id=21599) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21599action=view) [edit] rely on PREFERRED_STACK_BOUNDARY_DEFAULT for intel darwin You should keep

[Bug c++/45464] New: Warning missing using -Wall when comparing unsigned int and sum of unsigned chars.

2010-08-31 Thread brutus at free dot fr
The following code will warn for line 6 but not for line 5, however, I _think_the type of a + a + a is the same as the type of a + a. int main() { unsigned char a=0; unsigned int b =0; bool test1 =( b a + a);//no warning, why bool test2 =( b a + a + a);//warning if (wtf1 wtf2)

[Bug c++/45464] Warning missing using -Wall when comparing unsigned int and sum of unsigned chars.

2010-08-31 Thread brutus at free dot fr
--- Comment #1 from brutus at free dot fr 2010-08-31 13:53 --- There is a small mystake to the snippet, it should read instead: int main() { unsigned char a = 0; unsigned int b = 0; bool test1 =( b a + a); bool test2 =( b a + a + a); if (test1 test2) return 1; } --

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread hjl dot tools at gmail dot com
--- Comment #14 from hjl dot tools at gmail dot com 2010-08-31 13:54 --- (In reply to comment #12) Testresults for PR36502v2.patch at http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg03098.html. It appears that the only additional failures triggered by this patch are listed in

[Bug target/44606] Wrong SPE floating point during computation

2010-08-31 Thread Kyle dot D dot Moffett at boeing dot com
--- Comment #5 from Kyle dot D dot Moffett at boeing dot com 2010-08-31 14:03 --- Created an attachment (id=21605) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21605action=view) Further stripped testcase with problematic section identified Ok, I've spent a bit more time fiddling

[Bug target/44606] Wrong SPE floating point during computation

2010-08-31 Thread Kyle dot D dot Moffett at boeing dot com
--- Comment #6 from Kyle dot D dot Moffett at boeing dot com 2010-08-31 14:04 --- Created an attachment (id=21606) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21606action=view) Makefile for test.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44606

[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.

2010-08-31 Thread sfilippone at uniroma2 dot it
--- Comment #5 from sfilippone at uniroma2 dot it 2010-08-31 14:04 --- (In reply to comment #4) Ok, I could reduce this quite a bit: Good :) In the meantime, I tried with MOLD= in place of SOURCE=, and in the full application it still gives a segfault; I think that variant should be

[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.

2010-08-31 Thread janus at gcc dot gnu dot org
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-31 14:17 --- (In reply to comment #5) In the meantime, I tried with MOLD= in place of SOURCE=, and in the full application it still gives a segfault; I think that variant should be checked as well. Note that for MOLD there is

[Bug c++/45462] Bad optimization in -O3 sometimes

2010-08-31 Thread rguenth at gcc dot gnu dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-31 14:17 --- inline __attribute__((__always_inline__)) uint32 READ_UINT32(const void *ptr) { struct Unaligned32 { uint32 val; } __attribute__ ((__packed__)); return ((const Unaligned32 *)ptr)-val; } and similar look like

[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.

2010-08-31 Thread sfilippone at uniroma2 dot it
--- Comment #7 from sfilippone at uniroma2 dot it 2010-08-31 14:18 --- (In reply to comment #6) Note that for MOLD there is PR 44541 left (which I am about to fix). Up to now MOLD works only with non-polymorphic expressions. Once the PR is fixed, polymorphics should work too. Until

[Bug middle-end/45461] [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg

2010-08-31 Thread rguenth at gcc dot gnu dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-08-31 14:19 --- Looks obvious. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target

[Bug fortran/45463] gfortran internal write bug

2010-08-31 Thread david dot sagan at gmail dot com
--- Comment #2 from david dot sagan at gmail dot com 2010-08-31 14:20 --- (In reply to comment #1) Did you see the responses to your post in c.l.f? It seems that your program is non-conforming. I leave the PR open until either I or someone else has time to verify the conformity of

[Bug preprocessor/41943] include search path composition is bogus

2010-08-31 Thread ktietz at gcc dot gnu dot org
--- Comment #9 from ktietz at gcc dot gnu dot org 2010-08-31 14:31 --- Fixed on trunk and won't be backported to 4.5.x, therefore I close this bug -- ktietz at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/45463] gfortran internal write bug

2010-08-31 Thread david dot sagan at gmail dot com
--- Comment #3 from david dot sagan at gmail dot com 2010-08-31 14:32 --- (In reply to comment #2) Sorry. When I looked after I had posted the question there was only one response and that response said it was a bug so I submitted this bug report. Now other people have posted saying

[Bug c++/45462] Bad optimization in -O3 sometimes

2010-08-31 Thread yotambarnoy at gmail dot com
--- Comment #4 from yotambarnoy at gmail dot com 2010-08-31 15:24 --- Good job picking up on that. There must be a better way of telling the compiler to generate lwr and lwl MIPS instructions without breaking strict aliasing rules...? Thanks a bunch! -- yotambarnoy at gmail dot

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #15 from howarth at nitro dot med dot uc dot edu 2010-08-31 15:39 --- Created an attachment (id=21607) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21607action=view) rely on PREFERRED_STACK_BOUNDARY_DEFAULT and MAIN_STACK_BOUNDARY --

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #16 from howarth at nitro dot med dot uc dot edu 2010-08-31 15:48 --- (In reply to comment #14) Please try this patch: http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01916.html With the patch above and PR36502v3.patch, I still get... FAIL:

[Bug middle-end/45461] [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg

2010-08-31 Thread jakub at gcc dot gnu dot org
--- Comment #4 from jakub at gcc dot gnu dot org 2010-08-31 16:13 --- Subject: Bug 45461 Author: jakub Date: Tue Aug 31 16:13:14 2010 New Revision: 163678 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163678 Log: PR middle-end/45461 * builtins.c (dummy_object):

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #17 from howarth at nitro dot med dot uc dot edu 2010-08-31 16:30 --- With http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01916.html and the patch in comment 15, I am also still failing at -m32 on x86_64-apple-darwin10... FAIL: gcc.dg/nest.c execution test FAIL:

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #18 from howarth at nitro dot med dot uc dot edu 2010-08-31 16:36 --- Created an attachment (id=21608) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21608action=view) assembly from failing gcc.dg/nest.c execution test at -m32 on x86_64-apple-darwin10 Generated with...

[Bug fortran/45463] gfortran internal write bug

2010-08-31 Thread kargl at gcc dot gnu dot org
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-31 16:40 --- (In reply to comment #3) (In reply to comment #2) Sorry. When I looked after I had posted the question there was only one response and that response said it was a bug so I submitted this bug report. Now other

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #19 from howarth at nitro dot med dot uc dot edu 2010-08-31 16:41 --- (In reply to comment #18) In gdb, the failing nest.exe exection shows... Starting program: /Users/howarth/stack_align_bug2/nest.exe Reading symbols for shared libraries ++. done Program received

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #20 from howarth at nitro dot med dot uc dot edu 2010-08-31 16:42 --- Created an attachment (id=21609) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21609action=view) assembly from failing gcc.dg/torture/stackalign/alloca-4.c -O1 execution test at -m32 on

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #21 from howarth at nitro dot med dot uc dot edu 2010-08-31 16:46 --- (In reply to comment #20) Created alloca-4.s with... /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/

[Bug middle-end/45461] [4.6 Regression] ICE: verify_gimple failed: INDIRECT_REF in gimple IL with -fshort-enums and va_arg

2010-08-31 Thread jakub at gcc dot gnu dot org
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-31 16:47 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug fortran/45463] gfortran internal write bug

2010-08-31 Thread kargl at gcc dot gnu dot org
--- Comment #5 from kargl at gcc dot gnu dot org 2010-08-31 16:49 --- (In reply to comment #4) (In reply to comment #3) (In reply to comment #2) Sorry. When I looked after I had posted the question there was only one response and that response said it was a bug so I submitted

[Bug debug/45465] New: Wrong type reported by gdb

2010-08-31 Thread andre dot poenitz at nokia dot com
This is a somewhat curious issue as one needs fairly recent gcc (= 4.5) _and_ gdb ( 2010-07-29 ) to reproduce. - snip - #!/bin/sh # To reproduce: # - use g++ 4.5 or 4.6 (but not 4.4) # - use gdb from CVS from 2010-07-29 or newer echo templatetypename

[Bug debug/45465] Wrong type reported by gdb

2010-08-31 Thread andre dot poenitz at nokia dot com
--- Comment #1 from andre dot poenitz at nokia dot com 2010-08-31 17:08 --- This is also tracked on gdb's bugzilla as http://sourceware.org/bugzilla/show_bug.cgi?id=11961 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45465

[Bug debug/45465] Wrong type reported by gdb

2010-08-31 Thread andre dot poenitz at nokia dot com
--- Comment #2 from andre dot poenitz at nokia dot com 2010-08-31 17:08 --- This is now also tracked on the gcc bugzilla as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45465 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45465

[Bug target/41989] Code optimized for AMD Geode is slower than generic

2010-08-31 Thread andrew at atrens dot ca
--- Comment #26 from andrew at atrens dot ca 2010-08-31 17:14 --- (In reply to comment #25) try -march=i686 it should be the best What about the fact that Geode LX does not have a NOPL instruction, while i686 does. Couldn't that result in binaries that crash? --Andrew --

[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double

2010-08-31 Thread jason at gcc dot gnu dot org
--- Comment #28 from jason at gcc dot gnu dot org 2010-08-31 17:26 --- (In reply to comment #18) The optimization question in Comment #11 was answered incorrectly. The C++ standard in fact requires that Y be initialized before the constructor is run; see [basic.start.init]. I

[Bug fortran/45466] New: Bus Error: C program calls Fortran Function which has returned value as Character string

2010-08-31 Thread Lulin dot Song at gmail dot com
The program will crash if compile with version 4.4.3 or 4.3.2 but works with 4.1.2. Main program is written in C. (see the following) /* * C file passdouble.c * To compile the program, using the following command. *gcc passdouble.c requestdouble.o -lgfortran */ #include stdio.h extern

[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers

2010-08-31 Thread paolo at gcc dot gnu dot org
--- Comment #13 from paolo at gcc dot gnu dot org 2010-08-31 17:40 --- Subject: Bug 44480 Author: paolo Date: Tue Aug 31 17:39:51 2010 New Revision: 163686 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163686 Log: 2010-08-31 Paolo Carlini paolo.carl...@oracle.com PR

[Bug c++/21089] [4.0/4.1 Regression] C++ front-end does not inline the static const double

2010-08-31 Thread mmitchel at gcc dot gnu dot org
--- Comment #29 from mmitchel at gcc dot gnu dot org 2010-08-31 17:41 --- Jason -- I can't argue with that as a literal reading of the standard, but is there any reason why the standard doesn't allow const float variables in (not necessarily integral) constant expressions just as we

[Bug libstdc++/44480] [C++0x] Linear performance of begin() in unordered associative containers

2010-08-31 Thread paolo dot carlini at oracle dot com
--- Comment #14 from paolo dot carlini at oracle dot com 2010-08-31 17:41 --- Done. -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug middle-end/45422] [4.6 Regression] compile time increases 3x.

2010-08-31 Thread davidxl at gcc dot gnu dot org
--- Comment #26 from davidxl at gcc dot gnu dot org 2010-08-31 17:45 --- Good observation re. the number of IVs in the final set. This usually points to some problem/bug in the cost function. I briefly looked at this case -- it indeed exposes two more bugs in the cost model: 1) the

[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string

2010-08-31 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 17:45 --- I think the return value for character(16) returns are passed via the first argument. So I think this is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45466

[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string

2010-08-31 Thread kargl at gcc dot gnu dot org
--- Comment #2 from kargl at gcc dot gnu dot org 2010-08-31 17:53 --- Try compiling with -fdump-tree-original and inspecting the expected argument lists. You really don't want to use a function here. Use a subroutine. include stdio.h void requestdouble_(double*, double*, char *,

[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string

2010-08-31 Thread kargl at gcc dot gnu dot org
--- Comment #3 from kargl at gcc dot gnu dot org 2010-08-31 17:53 --- Closing as INVALID. -- kargl at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string

2010-08-31 Thread Lulin dot Song at gmail dot com
--- Comment #4 from Lulin dot Song at gmail dot com 2010-08-31 18:02 --- (In reply to comment #1) I think the return value for character(16) returns are passed via the first argument. So I think this is invalid. If the return value of function 'requestdouble' is changed to be

[Bug target/41989] Code optimized for AMD Geode is slower than generic

2010-08-31 Thread rootkit85 at yahoo dot it
--- Comment #27 from rootkit85 at yahoo dot it 2010-08-31 18:02 --- you could try but i'm not sure that NOPL is mandatory for the i686 arch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989

[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string

2010-08-31 Thread Lulin dot Song at gmail dot com
--- Comment #5 from Lulin dot Song at gmail dot com 2010-08-31 18:06 --- (In reply to comment #2) Try compiling with -fdump-tree-original and inspecting the expected argument lists. You really don't want to use a function here. Use a subroutine. include stdio.h void

[Bug debug/41736] missing DW_TAG_template_*_ in some cases

2010-08-31 Thread tromey at gcc dot gnu dot org
--- Comment #4 from tromey at gcc dot gnu dot org 2010-08-31 18:33 --- Created an attachment (id=21610) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21610action=view) a simple test case I'm attaching temargs.cc, a simple test case from the gdb test suite. I compiled this with

[Bug tree-optimization/45314] [4.5/4.6 Regression] ICE: error: in remove_unreachable_handlers, at tree-sh.c:3294 with -O2 -floop-interchange

2010-08-31 Thread bero at arklinux dot org
--- Comment #3 from bero at arklinux dot org 2010-08-31 18:48 --- Created an attachment (id=21611) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21611action=view) (fairly stupid) Workaround Attaching workaround for people coming across this bug report when googling the error

[Bug fortran/38282] Add the remaining HPF bit intrinsics

2010-08-31 Thread fxcoudert at gcc dot gnu dot org
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2010-08-31 18:57 --- Subject: Bug 38282 Author: fxcoudert Date: Tue Aug 31 18:56:46 2010 New Revision: 163691 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163691 Log: PR fortran/38282 * f95-lang.c

[Bug tree-optimization/45412] [4.6 Regression] ICE: SIGSEGV in update_ssa (tree-flow-inline.h:479) with -O2 -fipa-cp-clone -ftracer

2010-08-31 Thread zsojka at seznam dot cz
--- Comment #4 from zsojka at seznam dot cz 2010-08-31 19:07 --- Created an attachment (id=21612) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21612action=view) different testcase, probably better This one needs only -O2 to reproduce: $ valgrind -q --trace-children=yes gcc -O2

[Bug fortran/45466] Bus Error: C program calls Fortran Function which has returned value as Character string

2010-08-31 Thread kargl at gcc dot gnu dot org
--- Comment #6 from kargl at gcc dot gnu dot org 2010-08-31 19:09 --- (In reply to comment #5) Thanks. I do know how to work around it with subroutine which I already did in my program. But it doesn't explain why 4.1.2 version allows return character string from function. Our

Re: [Bug c++/45462] Bad optimization in -O3 sometimes

2010-08-31 Thread Andrew Pinski
On Aug 31, 2010, at 8:24 AM, yotambarnoy at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #4 from yotambarnoy at gmail dot com 2010-08-31 15:24 --- Good job picking up on that. There must be a better way of telling the compiler to generate lwr and lwl MIPS

[Bug c++/45462] Bad optimization in -O3 sometimes

2010-08-31 Thread pinskia at gmail dot com
--- Comment #5 from pinskia at gmail dot com 2010-08-31 19:09 --- Subject: Re: Bad optimization in -O3 sometimes On Aug 31, 2010, at 8:24 AM, yotambarnoy at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: --- Comment #4 from yotambarnoy at gmail dot com 2010-08-31 15:24

[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.

2010-08-31 Thread sfilippone at uniroma2 dot it
--- Comment #8 from sfilippone at uniroma2 dot it 2010-08-31 19:20 --- (In reply to comment #7) (In reply to comment #6) Fine. Waiting for it Consider the following variation: upon exit from DOIT, the ACSR variable should be deallocated (since it was MOVE_ALLOCed to atx%a)

[Bug fortran/45451] [OOP] Inconsistent status of ALLOCATABLE components inside CLASS variables.

2010-08-31 Thread sfilippone at uniroma2 dot it
--- Comment #9 from sfilippone at uniroma2 dot it 2010-08-31 19:21 --- Created an attachment (id=21613) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21613action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451

[Bug target/45250] [4.6 Regression] FAIL: tr1/5_numerical_facilities/special_functions/01_assoc_laguerre/check_nan.cc

2010-08-31 Thread jakub at gcc dot gnu dot org
--- Comment #7 from jakub at gcc dot gnu dot org 2010-08-31 19:48 --- Created an attachment (id=21614) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21614action=view) gcc46-pr45250.patch The problem is that the PA backend has quite lame setup, where FRAME_POINTER_REGNUM is the

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #22 from howarth at nitro dot med dot uc dot edu 2010-08-31 19:50 --- Created an attachment (id=21615) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21615action=view) assembly from stock build of gcc.dg/nest.c execution test at -m32 on x86_64-apple-darwin10 --

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #23 from howarth at nitro dot med dot uc dot edu 2010-08-31 19:55 --- Created an attachment (id=21616) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21616action=view) assembly from stock build of gcc.dg/torture/stackalign/alloca-4.c -O1 execution test at -m32 on

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #24 from howarth at nitro dot med dot uc dot edu 2010-08-31 19:57 --- Created an attachment (id=21617) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21617action=view) diff between nest.s.stock and nest.s show alignment changes in failing test case --

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread howarth at nitro dot med dot uc dot edu
--- Comment #25 from howarth at nitro dot med dot uc dot edu 2010-08-31 19:59 --- Created an attachment (id=21618) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21618action=view) diff between alloca-4.s.stock and alloca-4.s show alignment changes in failing test case --

[Bug c/45467] New: gcc won't warn about an uninitialized value

2010-08-31 Thread jellegeerts at gmail dot com
Hello, I've compiled the following code using `gcc -std=c99 -O -g -Wall gcctest.c -o gcctest': #include stdio.h static int array[32]; #if 0 // If '#if 1' is used, GCC warns correctly about the use of uninitialized variable 'i' below. void foo(void); void foo(void) #else static void foo(void)

[Bug c/45467] gcc won't warn about an uninitialized value

2010-08-31 Thread jellegeerts at gmail dot com
--- Comment #1 from jellegeerts at gmail dot com 2010-08-31 20:02 --- Created an attachment (id=21619) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21619action=view) output of `gcc -v -save-temps -std=c99 -O -g -Wall gcctest.c -o gcctest' --

[Bug c/45467] gcc won't warn about an uninitialized value

2010-08-31 Thread jellegeerts at gmail dot com
--- Comment #2 from jellegeerts at gmail dot com 2010-08-31 20:03 --- Created an attachment (id=21620) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21620action=view) output of `gcc -v -save-temps -std=c99 -O -g -Wall gcctest.c -o gcctest' --

[Bug c/45467] gcc won't warn about an uninitialized value

2010-08-31 Thread jellegeerts at gmail dot com
--- Comment #3 from jellegeerts at gmail dot com 2010-08-31 20:03 --- Created an attachment (id=21621) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21621action=view) the `.i' file that GCC created -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467

[Bug c/45467] gcc won't warn about an uninitialized value

2010-08-31 Thread jellegeerts at gmail dot com
--- Comment #4 from jellegeerts at gmail dot com 2010-08-31 20:04 --- Created an attachment (id=21622) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21622action=view) `.i' file that GCC created -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467

[Bug debug/45465] Wrong type reported by gdb

2010-08-31 Thread tromey at gcc dot gnu dot org
--- Comment #3 from tromey at gcc dot gnu dot org 2010-08-31 20:12 --- This was purely a gdb bug. It only showed up with a newish gcc because older ones don't emit DW_TAG_template_*. -- tromey at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/45467] gcc won't warn about an uninitialized value

2010-08-31 Thread jakub at gcc dot gnu dot org
--- Comment #5 from jakub at gcc dot gnu dot org 2010-08-31 20:13 --- That's because the whole foo function doesn't have any side-effects, so it is optimized away completely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467

[Bug c/45467] gcc won't warn about an uninitialized value

2010-08-31 Thread jellegeerts at gmail dot com
--- Comment #6 from jellegeerts at gmail dot com 2010-08-31 20:14 --- It also happens in functions that do have side-effects. I can give you an example if you want? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467

[Bug c/45468] New: gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'

2010-08-31 Thread jellegeerts at gmail dot com
When compiling a file with the `-Wuninitialized' flag, but without `-O', one does not get a warning from GCC 4.5.1 (and `-Wuninitialized' has no effect). GCC should output something like `cc1.exe: warning: -Wuninitialized is not supported without -O', like GCC 3.4.5 did. -- Summary:

[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'

2010-08-31 Thread pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 20:19 --- GCC 3.4.5 did. That is because GCC 4.5 and above support -Wuninitialized at -O0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'

2010-08-31 Thread jellegeerts at gmail dot com
--- Comment #2 from jellegeerts at gmail dot com 2010-08-31 20:23 --- I already reasoned that that might have been the case, but it seems false, because if I compile the following snippet with GCC 4.5.1 with the command `gcc newtest.c -std=c99 -Wall', I get no warning about the

[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'

2010-08-31 Thread jellegeerts at gmail dot com
--- Comment #3 from jellegeerts at gmail dot com 2010-08-31 20:24 --- Reopening bug. -- jellegeerts at gmail dot com changed: What|Removed |Added

[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'

2010-08-31 Thread pinskia at gcc dot gnu dot org
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-31 20:28 --- #include stdio.h int main(void) { int i; printf (%d\n, i); return 0; } Is warned about with -Wuninitialized at -O0. We don't warn about the uses that might be used unitialized. That means if i is

[Bug target/36502] i386/darwin generates unnecessary stack ops in every function

2010-08-31 Thread hjl dot tools at gmail dot com
--- Comment #26 from hjl dot tools at gmail dot com 2010-08-31 20:30 --- (In reply to comment #15) Created an attachment (id=21607) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21607action=view) [edit] rely on PREFERRED_STACK_BOUNDARY_DEFAULT and MAIN_STACK_BOUNDARY This is

[Bug c/45467] gcc won't warn about an uninitialized value

2010-08-31 Thread jellegeerts at gmail dot com
--- Comment #7 from jellegeerts at gmail dot com 2010-08-31 20:32 --- Updated code snippet, GCC doesn't warn here either if we leave `#if 0' as-is, even though the function foo() may have side-effects. #include stdio.h static int array[32]; #if 0 // If '#if 1' is used, GCC warns

[Bug c/45468] gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'

2010-08-31 Thread jellegeerts at gmail dot com
--- Comment #5 from jellegeerts at gmail dot com 2010-08-31 20:36 --- With `gcc -std=c99 -Wuninitialized -O0' I get no warning for the following code snippet (I do with `-O1' though), so it still seems GCC 4.5.1 should warn about `-O' not being specified. #include stdio.h int

[Bug c/45467] gcc won't warn about an uninitialized value

2010-08-31 Thread manu at gcc dot gnu dot org
--- Comment #8 from manu at gcc dot gnu dot org 2010-08-31 20:37 --- (In reply to comment #7) Updated code snippet, GCC doesn't warn here either if we leave `#if 0' as-is, even though the function foo() may have side-effects. No, the function below does not have any side-effects. The

  1   2   >