[Bug fortran/45474] New: Missing definable check actuals to INTENT(INOUT) dummies of intrinsics

No error is printed for: call execute_command_line("date", .true.,(1),(1),('aa')) end although the third to fifth argument are declared as INTENT(INOUT) in intrinsic.c and thus they have to be definable. The example is for execute_command_line, but I think it applies to all intrinsics. --

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

--- Comment #9 from pinskia at gmail dot com 2010-09-01 06:17 --- Subject: Re: Bad optimization in -O3 sometimes I am not talking about a library solution at all. I am talking about a solution inside the compiler. Gcc will optimize memcpy; how much for MIPS is a good question. Try

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

I am not talking about a library solution at all. I am talking about a solution inside the compiler. Gcc will optimize memcpy; how much for MIPS is a good question. Try it out and see. Oh if you are using scei's gcc you really should be reporting issues to them. On Aug 31, 2010, at 10:03 PM

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

--- Comment #30 from howarth at nitro dot med dot uc dot edu 2010-09-01 05:34 --- With only gcc-pr45234-2.patch at r163712 , I am seeing the following regressions... FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os (internal compiler error) FAIL: gcc.dg/stack-usage

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

--- Comment #8 from yotambarnoy at gmail dot com 2010-09-01 05:03 --- Unfortunately, a lib based solutions are difficult for me to implement. The reason is that the current PSP SDK uses newlib. I can probably change my personal toolchain with some work, but then it's a custom modificatio

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

--- Comment #7 from pinskia at gmail dot com 2010-09-01 04:41 --- Subject: Re: Bad optimization in -O3 sometimes On Aug 31, 2010, at 9:32 PM, "yotambarnoy at gmail dot com" wrote: > > > --- Comment #6 from yotambarnoy at gmail dot com 2010-09-01 > 04:32 --- > I recently

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

On Aug 31, 2010, at 9:32 PM, "yotambarnoy at gmail dot com" > wrote: --- Comment #6 from yotambarnoy at gmail dot com 2010-09-01 04:32 --- I recently implemented a custom memcpy for ScummVM. I didn't notice the standard memcpy using lwl and lwr. In any case, how would memcpy do

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

--- Comment #6 from yotambarnoy at gmail dot com 2010-09-01 04:32 --- I recently implemented a custom memcpy for ScummVM. I didn't notice the standard memcpy using lwl and lwr. In any case, how would memcpy do it any better? Unless you're referring to the new memcpy inlining in newer ver

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

--- Comment #29 from howarth at nitro dot med dot uc dot edu 2010-09-01 04:02 --- (In reply to comment #28) > If you don't set MAIN_STACK_BOUNDARY to 128, gcc may > align stack in main. > I am seeing some instability in the testsuite results when I don't redefine MAIN_STACK_BOUNDARY t

[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

--- Comment #2 from hjl dot tools at gmail dot com 2010-09-01 03:03 --- It is caused by revision 147282: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00256.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug c++/45473] [4.6 Regression] ICE: in dfs_walk_once, at cp/search.c:1659

--- Comment #2 from hjl dot tools at gmail dot com 2010-09-01 02:29 --- It is caused by revision 162008: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00362.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug fortran/45463] gfortran internal write bug

--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-09-01 02:10 --- > Update: More responses in comp.lang.fortran bring up the point that if > trim(line) > is supposed to return a temporary, the code might be conforming. Seems that > the > situation is not clear... Where in the

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

--- Comment #2 from hjl dot tools at gmail dot com 2010-09-01 01:10 --- It is caused by revision 163260: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00471.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

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

--- Comment #28 from hjl dot tools at gmail dot com 2010-09-01 01:08 --- (In reply to comment #27) > I don't think MAIN_STACK_BOUNDARY needs to be set, nor will it help to set > it. > The alignment is set up by the crt runtime, and just to call to main, the > alignment of the stack mu

[Bug c++/45473] [4.6 Regression] ICE: in dfs_walk_once, at cp/search.c:1659

--- Comment #1 from zsojka at seznam dot cz 2010-09-01 00:32 --- Created an attachment (id=21631) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21631&action=view) reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45473

[Bug c++/45473] New: [4.6 Regression] ICE: in dfs_walk_once, at cp/search.c:1659

Compiler output: $ gcc testcase.C testcase.C:11:8: internal compiler error: in dfs_walk_once, at cp/search.c:1659 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Tested revisions: r163636 - crash r162940 - crash r161659

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

--- Comment #27 from mrs at gcc dot gnu dot org 2010-09-01 00:25 --- I don't think MAIN_STACK_BOUNDARY needs to be set, nor will it help to set it. The alignment is set up by the crt runtime, and just to call to main, the alignment of the stack must be 128, before we issue the call. -

[Bug rtl-optimization/45472] [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

--- Comment #1 from zsojka at seznam dot cz 2010-08-31 23:58 --- Created an attachment (id=21630) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21630&action=view) reduced testcase $ gcc -O1 -fschedule-insns2 -fselective-scheduling2 pr45472.c -- http://gcc.gnu.org/bugzilla/sho

[Bug rtl-optimization/45472] New: [4.5/4.6 Regression] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

Command line: $ gcc -O1 -fschedule-insns2 -fselective-scheduling2 testcase.c Compiler output: $ gcc -O1 -fschedule-insns2 -fselective-scheduling2 testcase.c testcase.c: In function 'foo': testcase.c:18:1: internal compiler error: in move_op_ascend, at sel-sched.c:6124 Please submit a full bug repo

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

--- Comment #7 from mikael at gcc dot gnu dot org 2010-08-31 23:36 --- (In reply to comment #5) > (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. >

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

--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-31 23:23 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug pch/45471] ICE with PCH and differening strict-aliasing settings

--- Comment #2 from zsojka at seznam dot cz 2010-08-31 23:16 --- Created an attachment (id=21629) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21629&action=view) reduced header file #include can be replaced with: namespace std { struct type_info { }; } The second part of testca

[Bug pch/45471] ICE with PCH and differening strict-aliasing settings

--- Comment #1 from pinskia at gcc dot gnu dot org 2010-08-31 23:14 --- The PCH should be rejected for the differences in strict-aliasing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug pch/45471] New: ICE: in typeid_ok_p, at cp/rtti.c:311 when using precompiled headers

Command line: $ g++ -O2 testcase.h $ g++ -O2 testcase.C -fno-strict-aliasing Compiler output: $ g++ -O2 testcase.h $ g++ -O2 testcase.C -fno-strict-aliasing testcase.h: In constructor 'A< >::A() [with int = 0]': testcase.h:17:12: instantiated from here testcase.h:13:5: internal compiler error:

[Bug target/45469] When building cross compiler cannot compute suffix of object files.

--- Comment #9 from pinskia at gcc dot gnu dot org 2010-08-31 23:01 --- /home/Leo/i386appledarwinbuild/./gcc/as: line 83: exec: : not found The as is not being found. checking for as... no checking for i386-apple-darwin-as... no You don't have the cross binutils/cctools installed. -

[Bug target/45469] When building cross compiler cannot compute suffix of object files.

--- Comment #8 from leo dot izen at gmail dot com 2010-08-31 22:59 --- Created an attachment (id=21628) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21628&action=view) the config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45469

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

--- Comment #2 from jakub at gcc dot gnu dot org 2010-08-31 22:47 --- Subject: Bug 45457 Author: jakub Date: Tue Aug 31 22:47:25 2010 New Revision: 163705 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163705 Log: PR preprocessor/45457 * expr.c (parse_defined): C

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

--- Comment #18 from manu at gcc dot gnu dot org 2010-08-31 22:44 --- (In reply to comment #17) > Manuel, can you back up your claims about the C FE being slow with some > numbers? I don't remember the C FE ever being a time issue recently, of > course > C++ is a different story. I me

[Bug tree-optimization/45470] [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

--- Comment #1 from zsojka at seznam dot cz 2010-08-31 22:39 --- Created an attachment (id=21627) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21627&action=view) reduced testcase $ gcc -O1 -ftree-vectorize -fnon-call-exceptions pr45470.C -- http://gcc.gnu.org/bugzilla/show_b

[Bug tree-optimization/45470] New: [4.6 Regression] ICE: verify_flow_info failed: BB 2 can not throw but has an EH edge with -ftree-vectorize -fnon-call-exceptions

Compiler output: $ gcc -O1 -ftree-vectorize -fnon-call-exceptions testcase.C testcase.C: In constructor 'B::B()': testcase.C:17:1: error: BB 2 can not throw but has an EH edge testcase.C:17:1: internal compiler error: verify_flow_info failed Please submit a full bug report, with preprocessed sourc

[Bug target/45469] When building cross compiler cannot compute suffix of object files.

--- Comment #7 from pinskia at gcc dot gnu dot org 2010-08-31 22:28 --- Can you attach /home/Leo/i386appledarwinbuild/i386-apple-darwin/libgcc/config.log ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45469

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

--- Comment #17 from jakub at gcc dot gnu dot org 2010-08-31 22:26 --- Manuel, can you back up your claims about the C FE being slow with some numbers? I don't remember the C FE ever being a time issue recently, of course C++ is a different story. -- http://gcc.gnu.org/bugzilla/sho

[Bug target/45469] When building cross compiler cannot compute suffix of object files.

--- Comment #6 from leo dot izen at gmail dot com 2010-08-31 22:09 --- Created an attachment (id=21626) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21626&action=view) new make log -- leo dot izen at gmail dot com changed: What|Removed |Adde

[Bug target/45469] When building cross compiler cannot compute suffix of object files.

--- Comment #5 from leo dot izen at gmail dot com 2010-08-31 22:09 --- Created an attachment (id=21625) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21625&action=view) new configure output -- leo dot izen at gmail dot com changed: What|Removed

[Bug target/45469] When building cross compiler cannot compute suffix of object files.

--- Comment #4 from leo dot izen at gmail dot com 2010-08-31 22:08 --- (In reply to comment #3) > >./configure > > First don't build in the source directory. > > > Second can you attach > /home/Leo/Documents/gcc-cross-mactel-4.6.0/i386-apple-darwin/libgcc/config.log > ? > I changed

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

--- Comment #16 from jellegeerts at gmail dot com 2010-08-31 21:38 --- Thanks for the explanation. I understand it's a hard thing to fix. It's a bit of a sad situation, and has been for quite a while, unfortunately. :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45468

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

--- Comment #15 from manu at gcc dot gnu dot org 2010-08-31 21:34 --- (In reply to comment #14) > > depend on which optimization passes are run (and their order). See > > http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings for more background on > > the issues involved and existing bug

[Bug target/45469] When building cross compiler cannot compute suffix of object files.

--- Comment #3 from pinskia at gcc dot gnu dot org 2010-08-31 21:27 --- >./configure First don't build in the source directory. Second can you attach /home/Leo/Documents/gcc-cross-mactel-4.6.0/i386-apple-darwin/libgcc/config.log ? -- pinskia at gcc dot gnu dot org changed:

[Bug target/45469] When building cross compiler cannot compute suffix of object files.

--- Comment #2 from leo dot izen at gmail dot com 2010-08-31 21:18 --- Created an attachment (id=21624) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21624&action=view) make output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45469

[Bug target/45469] When building cross compiler cannot compute suffix of object files.

--- Comment #1 from leo dot izen at gmail dot com 2010-08-31 21:17 --- Created an attachment (id=21623) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21623&action=view) configure output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45469

[Bug target/45469] New: When building cross compiler cannot compute suffix of object files.

I got this error when building an i386-apple-darwin cross compiler on my x86_64-fedora-linux-gnu. It compiles everything up to the command ranlib libbackend.a and a little after, then the sub-directory configure script fails. I configured it and made it with this: [...@chessman gcc-cross-mactel-4.

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

--- Comment #14 from jellegeerts at gmail dot com 2010-08-31 21:16 --- (In reply to comment #13) > (In reply to comment #12) > > @Manuel, > > So, perhaps then this bug report is at least sort of valid? It seems that to > > get `-Wuninitialized' to *fully* work, one would need at least `-

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

--- Comment #13 from manu at gcc dot gnu dot org 2010-08-31 21:07 --- (In reply to comment #12) > Sorry Andrew, misinterpreted some things you said. I understand now that you > meant that normally everything should work as expected. > > @Manuel, > So, perhaps then this bug report is at

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

--- Comment #12 from jellegeerts at gmail dot com 2010-08-31 20:59 --- Sorry Andrew, misinterpreted some things you said. I understand now that you meant that normally everything should work as expected. @Manuel, So, perhaps then this bug report is at least sort of valid? It seems that

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

--- Comment #12 from jellegeerts at gmail dot com 2010-08-31 20:54 --- Thanks. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467

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

--- Comment #11 from jakub at gcc dot gnu dot org 2010-08-31 20:53 --- Because when foo is not static, it has to be compiled. If it is static, GCC figures it is a pure function (only reads memory and arguments and computes from it its return value) and as the result in main of the funct

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

--- Comment #11 from manu at gcc dot gnu dot org 2010-08-31 20:53 --- (In reply to comment #8) > (In reply to comment #7) > > I am pointing out a case where it does not warn (and it seems to me that it > > should); what is your point? > > My point is that you should open a different bug

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

--- Comment #10 from jellegeerts at gmail dot com 2010-08-31 20:49 --- Also, it seems a bit questionable to not warn when it is clearly(?) not the developers intent to use an uninitialized variable. What is the rationale behind this? Is it a pragmatic thing? -- http://gcc.gnu.org/bu

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

--- Comment #10 from pinskia at gcc dot gnu dot org 2010-08-31 20:49 --- (In reply to comment #9) > Though, GCC does not warn about a missing `-O' (or `-Oxxx') flag, which was > the > point of this bug report. That the `-O0' flag doesn't work is another story. And I showed a case wher

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

--- Comment #9 from jellegeerts at gmail dot com 2010-08-31 20:47 --- Okay. :) Though, why does GCC warn when we have `#if 1', and not if we have `#if 0'? Just curiosity... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45467

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

--- Comment #9 from jellegeerts at gmail dot com 2010-08-31 20:45 --- I get that point, and I might open another bug report for that case, sure. Though, GCC does not warn about a missing `-O' (or `-Oxxx') flag, which was the point of this bug report. That the `-O0' flag doesn't work is

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

--- Comment #8 from pinskia at gcc dot gnu dot org 2010-08-31 20:40 --- (In reply to comment #7) > I am pointing out a case where it does not warn (and it seems to me that it > should); what is your point? My point is that you should open a different bug that says we should warn about t

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

--- Comment #7 from jellegeerts at gmail dot com 2010-08-31 20:39 --- I am pointing out a case where it does not warn (and it seems to me that it should); what is your point? -- jellegeerts at gmail dot com changed: What|Removed |Added

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

--- Comment #6 from pinskia at gcc dot gnu dot org 2010-08-31 20:37 --- >so it still seems GCC 4.5.1 should warn about `-O' not being specified. No, I showed an example of where it does warn without -O. -- pinskia at gcc dot gnu dot org changed: What|Removed

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

--- 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. Th

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

--- 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 int

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

--- 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 static int array[32]; #if 0 // If '#if 1' is used, GCC wa

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

--- 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=21607&action=view) [edit] > rely on PREFERRED_STACK_BOUNDARY_DEFAULT and MAIN_STACK_BOUNDARY > This

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

--- Comment #4 from pinskia at gcc dot gnu dot org 2010-08-31 20:28 --- #include 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 gets put

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

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

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

--- 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 uninitial

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

--- 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] New: gcc does not warn about missing `-O' flag when specifying `-Wuninitialized'

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/45467] gcc won't warn about an uninitialized value

--- 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/45467] gcc won't warn about an uninitialized value

--- 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 debug/45465] Wrong type reported by gdb

--- 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

--- 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=21622&action=view) `.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

--- 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=21621&action=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

--- 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=21620&action=view) output of `gcc -v -save-temps -std=c99 -O -g -Wall gcctest.c -o gcctest' -- http://gcc.gnu.org/bugzilla/show_

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

--- 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=21619&action=view) output of `gcc -v -save-temps -std=c99 -O -g -Wall gcctest.c -o gcctest' -- http://gcc.gnu.org/bugzilla/show_

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

Hello, I've compiled the following code using `gcc -std=c99 -O -g -Wall gcctest.c -o gcctest': <<< #include 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

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

--- 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=21618&action=view) diff between alloca-4.s.stock and alloca-4.s show alignment changes in failing test case -- http

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

--- 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=21617&action=view) diff between nest.s.stock and nest.s show alignment changes in failing test case -- http://gcc.g

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

--- 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=21616&action=view) assembly from stock build of gcc.dg/torture/stackalign/alloca-4.c -O1 execution test at -m32 on x86

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

--- 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=21615&action=view) assembly from stock build of gcc.dg/nest.c execution test at -m32 on x86_64-apple-darwin10 -- ht

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

--- 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=21614&action=view) gcc46-pr45250.patch The problem is that the PA backend has quite lame setup, where FRAME_POINTER_REGNUM is the sa

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

--- 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=21613&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45451

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

--- 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 c++/45462] Bad optimization in -O3 sometimes

--- 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" wrote: > > > --- Comment #4 from yotambarnoy at gmail dot com 2010-08-31 > 15:24 --- > Good job pi

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

On Aug 31, 2010, at 8:24 AM, "yotambarnoy at gmail dot com" > 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 instructions without breaki

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

--- 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 prog

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

--- 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=21612&action=view) different testcase, probably better This one needs only -O2 to reproduce: $ valgrind -q --trace-children=yes gcc -O2

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

--- 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=gcc&view=rev&rev=163691 Log: PR fortran/38282 * f95-lang.c (gfc_ini

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

--- 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=21611&action=view) (fairly stupid) Workaround Attaching workaround for people coming across this bug report when googling the error mess

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

--- 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=21610&action=view) a simple test case I'm attaching "temargs.cc", a simple test case from the gdb test suite. I compiled this with

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

--- 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 > > void requestd

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

--- 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

--- 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 i

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

--- 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 Status|

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

--- 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 void requestdouble_(double*, double*, char *, int *len);

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

--- 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 middle-end/45422] [4.6 Regression] compile time increases 3x.

--- 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 com

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

--- 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 Statu

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

--- 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 al

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

--- 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=gcc&view=rev&rev=163686 Log: 2010-08-31 Paolo Carlini PR libstdc++/44480

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

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 extern char* reque

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

--- 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 d

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

--- 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 -- http

[Bug debug/45465] Wrong type reported by gdb

--- 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 debug/45465] Wrong type reported by gdb

--- 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

  1   2   >