[Bug fortran/43841] Missing temporary for ELEMENTAL function call

--- Comment #8 from pault at gcc dot gnu dot org 2010-04-24 07:44 --- (In reply to comment #7) > I posted a fix this morning. ...which gives, { struct polar_t D.1625; D.1625 = b[0]; { integer(kind=8) S.18; S.18 = 1; while (1) { if (S.1

[Bug c/43876] New: [avr] Improper updating of struct members when written out of order from struct definition

avr-gcc may improperly update members of a struct if: 1) The access to the members is in a different order than the struct was defined and 2) The volatile modifier is used on the struct variable (instance) and 3) The target device is set to atxmega128a1 (possibly all xmega chips) and 4) Optimizati

[Bug fortran/43843] Wrong-code due to missing temporary with user-defined operatator

--- Comment #3 from pault at gcc dot gnu dot org 2010-04-24 09:28 --- Subject: Bug 43843 Author: pault Date: Sat Apr 24 09:28:32 2010 New Revision: 158683 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158683 Log: 2010-04-24 Paul Thomas PR fortran/43841 PR fo

[Bug fortran/43841] Missing temporary for ELEMENTAL function call

--- Comment #9 from pault at gcc dot gnu dot org 2010-04-24 09:28 --- Subject: Bug 43841 Author: pault Date: Sat Apr 24 09:28:32 2010 New Revision: 158683 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158683 Log: 2010-04-24 Paul Thomas PR fortran/43841 PR fo

[Bug libstdc++/43877] New: container declaration disables standard outoput

With g++ 4.5.0 built on cygwin pc (x86, 32bit) the following program has no output. Without the declaration of the vector anything works fine as expected. Does anybody know what could cause this strange behavior? #include #include int main() { std::cout << "hello" << std::endl; std::vec

[Bug bootstrap/43878] New: Building a cross gcc fails due to a bug in the build process

I am building gcc 4.4.3 with the following ./configure command line: ../gcc-4.4.3/configure --prefix=/some_path/build_tools --program-prefix=build-tool- --build=i686-pc-linux-gnu --host=i686-buildtools-linux-gnu --with-gmp-include=/some_path/build_tools/include --with-gmp-lib=/some_path/build_tool

[Bug libstdc++/43877] container declaration disables standard output

--- Comment #1 from nico at josuttis dot de 2010-04-24 10:16 --- compiler built with: ../src/gcc-4*/configure --prefix=/cygdrive/p/gcc4 --program-suffix=4 --with-gxx-include-dir=/cygdrive/p/gcc4-include example compiled with: g++4 -std=c++0x move.cpp -o move -- nico at

[Bug target/42879] Replace "tst r3, 1" with "lsl r3, r3, 31" in thumb2

--- Comment #3 from carrot at google dot com 2010-04-24 11:53 --- lsls r2,r3, #1 can be assembled to 16 bit. lsl r2,r3, #1 is 32 bit because only 32 bit encoding can ignore condition code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42879

[Bug libfortran/43844] open(unit, status="scratch") fails to create tempporary file

--- Comment #10 from ktietz at gcc dot gnu dot org 2010-04-24 12:02 --- So I investigated this issue about mktemp in more detail and found finally the first-scope and second-scope bug here. Old logic was opening files and as long as mktemp failed on a second call, things were working (t

[Bug fortran/43832] OPEN statement not diagnosing missing unit number

--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-04-24 12:04 --- Subject: Bug 43832 Author: jvdelisle Date: Sat Apr 24 12:04:09 2010 New Revision: 158684 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158684 Log: 2010-04-24 Jerry DeLisle PR fortran/43832

[Bug fortran/43832] OPEN statement not diagnosing missing unit number

--- Comment #5 from jvdelisle at gcc dot gnu dot org 2010-04-24 12:07 --- Subject: Bug 43832 Author: jvdelisle Date: Sat Apr 24 12:07:07 2010 New Revision: 158685 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158685 Log: 2010-04-24 Jerry DeLisle PR fortran/43832

[Bug fortran/43832] OPEN statement not diagnosing missing unit number

--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-04-24 12:09 --- Fixed on trunk. Closing -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added

[Bug libfortran/43844] open(unit, status="scratch") fails to create tempporary file

--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-04-24 12:17 --- Yes, OK to commit to trunk. Thanks! -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

--- Comment #12 from jv244 at cam dot ac dot uk 2010-04-24 12:25 --- This was also ported back to 4.5.1, causing a regression there. This is against the policy of 'open for regression and documentation fixes'. It was also never approved for the branch only trunk. 2010-04-16 Steven G. K

[Bug libfortran/43844] open(unit, status="scratch") fails to create tempporary file

--- Comment #12 from ktietz at gcc dot gnu dot org 2010-04-24 12:25 --- (In reply to comment #11) > Yes, OK to commit to trunk. Thanks! > Ok, applied to trunk at revision 158686. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43844

[Bug fortran/43227] [4.5 Regression] ICE: segmentation fault in mio_expr

--- Comment #28 from pault at gcc dot gnu dot org 2010-04-24 12:29 --- Subject: Bug 43227 Author: pault Date: Sat Apr 24 12:29:23 2010 New Revision: 158687 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158687 Log: 2010-04-24 Paul Thomas PR fortran/43227 * re

[Bug fortran/43266] ICE on invalid: in ensure_not_abstract_walker, at fortran/resolve.c:10290

--- Comment #6 from pault at gcc dot gnu dot org 2010-04-24 12:29 --- Subject: Bug 43266 Author: pault Date: Sat Apr 24 12:29:23 2010 New Revision: 158687 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158687 Log: 2010-04-24 Paul Thomas PR fortran/43227 * res

[Bug fortran/43227] [4.5 Regression] ICE: segmentation fault in mio_expr

--- Comment #29 from pault at gcc dot gnu dot org 2010-04-24 12:30 --- Fixed on trunk and 4.5. Thanks, as ever, Dominique! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added -

[Bug rtl-optimization/18401] Bootstrap failure on all ARM targets due to incorrect GCSE

--- Comment #9 from rearnsha at gcc dot gnu dot org 2010-04-24 12:43 --- Not seen this again in a long time, so closing as works for me. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c++/43868] [4.5/4.6 Regression] ICE with -g

--- Comment #3 from hjl dot tools at gmail dot com 2010-04-24 13:47 --- It is caused by revision 153978: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00196.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug target/19598] [arm] non-optimal handling of invalid immediate constant in XOR

--- Comment #2 from rearnsha at gcc dot gnu dot org 2010-04-24 14:24 --- Fixed with: http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01723.html -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added -

[Bug tree-optimization/43879] New: [4.6 Regression] -fipa-pta causes FAIL: gcc.c-torture/execute/20000822-1.c execution

Tested revisions: r158683 - fail r158486 - OK Compiler output: $ binary-158683-lto-fortran/bin/gcc -O2 -fipa-pta gcc/testsuite/gcc.c-torture/execute/2822-1.c && ./a.out gcc/testsuite/gcc.c-torture/execute/2822-1.c: In function 'main': gcc/testsuite/gcc.c-torture/execute/2822-1.c:25:5:

[Bug tree-optimization/43879] [4.6 Regression] -fipa-pta causes FAIL: gcc.c-torture/execute/20000822-1.c execution

--- Comment #1 from zsojka at seznam dot cz 2010-04-24 16:17 --- It also causes: $ binary-158683-lto-fortran/bin/gcc -O3 -fipa-pta gcc/testsuite/gcc.c-torture/execute/nestfunc-3.c && ./a.out gcc/testsuite/gcc.c-torture/execute/nestfunc-3.c: In function 'main': gcc/testsuite/gcc.c-tortur

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

--- Comment #13 from kargl at gcc dot gnu dot org 2010-04-24 16:56 --- (In reply to comment #12) > > Just for completeness, this testcase again emphasizes that this is an ICE on > valid code. > > MODULE fft_tools > IMPLICIT NONE > INTEGER, PARAMETER :: sp=4, dp=8 > INTEGER, PARAM

[Bug fortran/43832] OPEN statement not diagnosing missing unit number

--- Comment #7 from hp at gcc dot gnu dot org 2010-04-24 17:01 --- Subject: Bug 43832 Author: hp Date: Sat Apr 24 17:00:52 2010 New Revision: 158688 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158688 Log: PR fortran/43832 * gfortran.dg/fgetc_3.f90: Delete bogu

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

--- Comment #14 from jv244 at cam dot ac dot uk 2010-04-24 17:58 --- (In reply to comment #13) > For even more completeness, the code in comment #12 is still > invalid. do you mind to clarify ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

--- Comment #15 from kargl at gcc dot gnu dot org 2010-04-24 18:03 --- (In reply to comment #14) > (In reply to comment #13) > > > For even more completeness, the code in comment #12 is still > > invalid. > > do you mind to clarify ? > pos is undefined. Here's the testcase I will be

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

--- Comment #16 from jv244 at cam dot ac dot uk 2010-04-24 18:12 --- (In reply to comment #15) > > pos is undefined. > Ah, we're at that level. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

--- Comment #17 from kargl at gcc dot gnu dot org 2010-04-24 18:38 --- Patch is here: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01518.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43793

[Bug tree-optimization/43879] [4.6 Regression] -fipa-pta causes various miscompilations

--- Comment #2 from zsojka at seznam dot cz 2010-04-24 18:49 --- Bootstrap fails too with -fipa-pta, (at least) cfgrtl.o is miscompiled. -- zsojka at seznam dot cz changed: What|Removed |Added ---

[Bug tree-optimization/41442] missed optimization for boolean expression

--- Comment #4 from bernds at gcc dot gnu dot org 2010-04-24 18:54 --- Subject: Bug 41442 Author: bernds Date: Sat Apr 24 18:53:47 2010 New Revision: 158689 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158689 Log: gcc/ PR tree-optimization/41442 * fold-const.c

[Bug tree-optimization/43879] -fipa-pta causes various miscompilations

--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-24 18:55 --- Well, -fipa-pta is no longer a no-op and I wouldn't call the existing (known) bugs a regression. I have some pending patches to fix issues. -- rguenth at gcc dot gnu dot org changed: What|Removed

[Bug tree-optimization/43879] -fipa-pta causes various miscompilations

--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-24 20:04 --- (In reply to comment #2) > Bootstrap fails too with -fipa-pta, (at least) cfgrtl.o is miscompiled. Yep, I know. If you can isolate the miscompile that would be great (I am concentrating on completing IPA PTA as tim

[Bug lto/43467] LTO error "bytecode stream: trying to read 0 bytes after the end of the input buffer"

--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-24 20:23 --- With -fipa-cp -flto -fuse-linker-plugin -Wl,--allow-multiple-definition, but gold does not know --allow-multiple-definition and thus I get > gcc-4.5 1.c 2.c -fipa-cp -flto -fuse-linker-plugin /usr/bin/gold: error: /

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

--- Comment #18 from kargl at gcc dot gnu dot org 2010-04-24 20:32 --- Subject: Bug 43793 Author: kargl Date: Sat Apr 24 20:32:04 2010 New Revision: 158692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158692 Log: 2010-04-24 Steven G. Kargl PR fortran/30073

[Bug fortran/30073] Array out of bounds gives name of RHS array not LHS array

--- Comment #12 from kargl at gcc dot gnu dot org 2010-04-24 20:32 --- Subject: Bug 30073 Author: kargl Date: Sat Apr 24 20:32:04 2010 New Revision: 158692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158692 Log: 2010-04-24 Steven G. Kargl PR fortran/30073

[Bug c++/43880] New: internal compiler error: in make_decl_rtl

pngtex.cpp: In constructor ‘test::test()’: pngtex.cpp:12:14: internal compiler error: in make_decl_rtl, at varasm.c:1317 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO

[Bug c++/43880] internal compiler error: in make_decl_rtl

--- Comment #1 from jengelh at medozas dot de 2010-04-24 20:40 --- Created an attachment (id=20478) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20478&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43880

[Bug middle-end/43880] [4.5/4.6 Regression] internal compiler error: in make_decl_rtl

--- Comment #2 from rguenth at gcc dot gnu dot org 2010-04-24 21:44 --- Confirmed. Somehow another DECL_VALUE_EXPR issue test::test() (struct test * const this) { union ._0 D.2124; char pngpal[1] [value-expr: D.2119.pngpal]; char * D.2127; # BLOCK 2 # PRED: ENTRY (fallthru)

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

--- Comment #19 from kargl at gcc dot gnu dot org 2010-04-24 21:47 --- Subject: Bug 43793 Author: kargl Date: Sat Apr 24 21:46:45 2010 New Revision: 158693 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158693 Log: 010-04-24 Steven G. Kargl PR fortran/30073 P

[Bug fortran/30073] Array out of bounds gives name of RHS array not LHS array

--- Comment #13 from kargl at gcc dot gnu dot org 2010-04-24 21:47 --- Subject: Bug 30073 Author: kargl Date: Sat Apr 24 21:46:45 2010 New Revision: 158693 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158693 Log: 010-04-24 Steven G. Kargl PR fortran/30073 P

[Bug fortran/43793] [4.5/4.6 Regression] tree check: expected tree that contains �decl minimal� structure, have �indirect_ref� in gfc_trans_array_bound_check

--- Comment #20 from kargl at gcc dot gnu dot org 2010-04-24 21:48 --- Fix. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug c++/43881] New: warning attached to a function is emitted even though the function is not being called

The gcc documentation, section "Declaring Attributes of Functions", states about the __attribute__ ((__warning__ ("..."))) of a function: "If this attribute is used on a function declaration and a call to such a function is not eliminated through dead code elimination or other optimizations, a warn

[Bug c++/43881] warning attached to a function is emitted even though the function is not being called

--- Comment #1 from bruno at clisp dot org 2010-04-24 22:49 --- Created an attachment (id=20479) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20479&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43881

Re: [Bug c++/43881] New: warning attached to a function is emitted even though the function is not being called

It is called directly because safe_close's value is replaced in the indirect call. Since safe_close is static and not changed in the code at all, it is marked as read only and the initialized value can be used directly. Sent from my iPhone On Apr 24, 2010, at 3:49 PM, "bruno at clisp dot o

[Bug c++/43881] warning attached to a function is emitted even though the function is not being called

--- Comment #2 from pinskia at gmail dot com 2010-04-24 23:12 --- Subject: Re: New: warning attached to a function is emitted even though the function is not being called It is called directly because safe_close's value is replaced in the indirect call. Since safe_close is static an

[Bug middle-end/43880] [4.5/4.6 Regression] internal compiler error: in make_decl_rtl

--- Comment #3 from hjl dot tools at gmail dot com 2010-04-24 23:23 --- It is caused by revision 149750: http://gcc.gnu.org/ml/gcc-cvs/2009-07/msg00631.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43880

[Bug libstdc++/43877] container declaration disables standard output

--- Comment #2 from paolo dot carlini at oracle dot com 2010-04-24 23:28 --- Totally crazy. Dave can you reproduce this? -- paolo dot carlini at oracle dot com changed: What|Removed |Added --

[Bug libstdc++/43877] container declaration disables standard output

--- Comment #3 from davek at gcc dot gnu dot org 2010-04-24 23:33 --- (In reply to comment #2) > Totally crazy. Dave can you reproduce this? > I have a theory. Will report back in ten minutes or so... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43877

[Bug libstdc++/43877] container declaration disables standard output

--- Comment #4 from davek at gcc dot gnu dot org 2010-04-24 23:44 --- (In reply to comment #3) > (In reply to comment #2) > > Totally crazy. Dave can you reproduce this? > > > > I have a theory. Will report back in ten minutes or so... Uh, well, nope, that didn't work. I was wonde

[Bug c++/43881] warning attached to a function is emitted even though the function is not being called

--- Comment #3 from bruno at clisp dot org 2010-04-24 23:54 --- When the line static int (*safe_close) (int fd) = close; is changed to static int (*safe_close) (int fd) = ((void)0, close); the warning also disappears, but then the generate code is suboptimal: the variable safe_close

[Bug c++/43881] warning attached to a function is emitted even though the function is not being called

--- Comment #4 from bruno at clisp dot org 2010-04-24 23:58 --- (In reply to comment #2) > It is called directly because safe_close's value is replaced in the > indirect call. Since safe_close is static and not changed in the code > at all, it is marked as read only and the initializ

[Bug c++/43882] New: 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

I have a c++ project with a lots of STL. It compiles fine with gcc 4.3.1 and 4.4.3, but with the new 4.5.0 I get those two missing symbols in linking: std::_List_node_base::_M_hook(std::_List_node_base*) std::_List_node_base::_M_unhook() libstdc++.so from 4.5.0 has those relevant symbols, and the

[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

--- Comment #1 from paolo dot carlini at oracle dot com 2010-04-25 00:28 --- Thus the symbols are there, and exported (ie, capital T), everything seems fine to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43882

[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

--- Comment #2 from yuri at tsoft dot com 2010-04-25 00:35 --- But linker produces messages like this: x.C:229: undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)' New with the switch to 4.5.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43882

[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

--- Comment #3 from paolo dot carlini at oracle dot com 2010-04-25 00:37 --- Thus, either the linker is buggy, or the installation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43882

[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

--- Comment #4 from paolo dot carlini at oracle dot com 2010-04-25 00:40 --- Note, those symbols are new in 4.5.0, thus you should check that your new 4.5.0 *.so is actually searched by linker, ie, check the installation, again, because if the linker tries to link vs the 4.4.x *.so the

[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

--- Comment #5 from yuri at tsoft dot com 2010-04-25 01:17 --- Sorry, my bad. It really was picking up the default libstdc++.so from the OS installation. I used -R/path/to/4.5.0/libstdc++.so to fix this library path. But it turns out that -L/path/to/4.5.0/libstdc++.so is also required i

[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)

--- Comment #6 from paolo dot carlini at oracle dot com 2010-04-25 04:49 --- Ok, thanks, let's close this then. -- paolo dot carlini at oracle dot com changed: What|Removed |Added ---

[Bug middle-end/43883] New: missed optimization of constant __int128_t modulus

The following function gets optimized at -O3 to: long long tmod2(long long x) { return x % 2; } mov%rdi,%rdx shr$0x3f,%rdx lea(%rdi,%rdx,1),%rax