[Bug fortran/38318] moving the allocation of temps out of loops.

--- Comment #2 from jv244 at cam dot ac dot uk 2010-02-21 09:12 --- seemingly being discussed, since useful for tonto http://gcc.gnu.org/ml/fortran/2010-02/msg00157.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38318

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

--- Comment #31 from paolo dot carlini at oracle dot com 2010-02-21 09:51 --- (In reply to comment #30) > Wouldn't it be a violation of the one definition rule (ODR), > when one translation unit is compiled with -fwrapv and another without? > In that case this would be a regression. I

[Bug fortran/41113] spurious _gfortran_internal_pack

--- Comment #23 from paul dot richard dot thomas at gmail dot com 2010-02-21 10:43 --- Subject: Re: spurious _gfortran_internal_pack I was going to check out the situation for 4.4. However, my inclination is to close it. I'll be working on it tonight. Cheers Paul On Sat, Feb 20,

[Bug fortran/43072] unneeded temporary (s=s+f(a))

--- Comment #6 from paul dot richard dot thomas at gmail dot com 2010-02-21 10:43 --- Subject: Re: unneeded temporary (s=s+f(a)) Same as 41113 - I'll decide what to do tonight - see you on #gfortran? Paul On Sat, Feb 20, 2010 at 10:48 PM, burnus at gcc dot gnu dot org wrote: > > >

[Bug fortran/38318] moving the allocation of temps out of loops.

--- Comment #3 from burnus at gcc dot gnu dot org 2010-02-21 11:06 --- (In reply to comment #2) > seemingly being discussed, since useful for tonto > > http://gcc.gnu.org/ml/fortran/2010-02/msg00157.html > But there: "it's unfortunately not possible to avoid the temporary creation wit

[Bug c++/43131] New: internal compiler error: tree check expected class �type� have �exceptional�

Seen with gcc 4.4.0: $ gcc temp.cpp -I../.. In file included from temp.cpp:2: ../../gptm/thread_scope_new.h:128: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (identifier_node) in constructor_name_full, at cp/name-lookup.c:1777 Please submit a full bug report,

[Bug c++/43131] internal compiler error: tree check expected class �type� have �exceptional�

--- Comment #1 from kian dot karas dot dev at gmail dot com 2010-02-21 12:02 --- Created an attachment (id=19931) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19931&action=view) Preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43131

[Bug middle-end/38318] moving the allocation of temps out of loops.

--- Comment #4 from jv244 at cam dot ac dot uk 2010-02-21 12:11 --- (In reply to comment #3) > (In reply to comment #2) > > seemingly being discussed, since useful for tonto > > > > http://gcc.gnu.org/ml/fortran/2010-02/msg00157.html > > > > But there: "it's unfortunately not possible

[Bug c++/43131] internal compiler error: tree check expected class �type� have �exceptional�

--- Comment #2 from paolo dot carlini at oracle dot com 2010-02-21 12:19 --- I can't reproduce this with the *released* gcc4.4.0 or current gcc-4_4-branch, I get instead: ../../gptm/thread_scope_new.h:128: error: declaration of ‘~ThreadScopeNew’ as member of ‘gptm::ThreadScope_New’

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

--- Comment #32 from veksler at il dot ibm dot com 2010-02-21 12:44 --- (In reply to comment #31) > (In reply to comment #30) > > Wouldn't it be a violation of the one definition rule (ODR), > > when one translation unit is compiled with -fwrapv and another without? > > In that case thi

[Bug objc/43061] 47 new GCC h...@156527 regressions

--- Comment #41 from dominiq at lps dot ens dot fr 2010-02-21 12:46 --- AFAICT this pr and the side effects have been fixed, hence closing. If someone disagree, please reopen. Thanks all for the work. -- dominiq at lps dot ens dot fr changed: What|Removed

[Bug target/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *

--- Comment #14 from dominiq at lps dot ens dot fr 2010-02-21 12:47 --- Closing as fixed. Thanks for the patch. -- dominiq at lps dot ens dot fr changed: What|Removed |Added --

[Bug middle-end/41043] [4.4 Regression] virtual memory exhausted: Cannot allocate memory

--- Comment #11 from dominiq at lps dot ens dot fr 2010-02-21 12:49 --- Any plan to backport the fix to 4.4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41043

[Bug middle-end/41043] [4.4 Regression] virtual memory exhausted: Cannot allocate memory

--- Comment #12 from rguenther at suse dot de 2010-02-21 12:50 --- Subject: Re: [4.4 Regression] virtual memory exhausted: Cannot allocate memory On Sun, 21 Feb 2010, dominiq at lps dot ens dot fr wrote: > --- Comment #11 from dominiq at lps dot ens dot fr 2010-02-21 12:49 > --

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

--- Comment #33 from paolo dot carlini at oracle dot com 2010-02-21 12:53 --- (In reply to comment #32) > If this hazard is so prevalent shouldn't it deserve a separate PR? > If a method or function depend on a flag or macro then it can be handled > by overloading and specialization wit

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

--- Comment #34 from rguenth at gcc dot gnu dot org 2010-02-21 13:04 --- (In reply to comment #33) > (In reply to comment #32) > > If this hazard is so prevalent shouldn't it deserve a separate PR? > > If a method or function depend on a flag or macro then it can be handled > > by overl

[Bug fortran/35259] -fassociative-math not enabled by default; No option to associate with PAREN_EXPRs

--- Comment #6 from burnus at gcc dot gnu dot org 2010-02-21 13:06 --- Subject: Bug 35259 Author: burnus Date: Sun Feb 21 13:06:07 2010 New Revision: 156937 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156937 Log: 2010-02-21 Tobias Burnus PR fortran/35259 *

[Bug fortran/35259] -fassociative-math not enabled by default; No option to associate with PAREN_EXPRs

--- Comment #7 from burnus at gcc dot gnu dot org 2010-02-21 13:06 --- FIXED on the (4.5) trunk. -- burnus at gcc dot gnu dot org changed: What|Removed |Added

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

--- Comment #35 from veksler at il dot ibm dot com 2010-02-21 13:33 --- (In reply to comment #34) > (In reply to comment #33) > > (In reply to comment #32) > > > If this hazard is so prevalent shouldn't it deserve a separate PR? > > > If a method or function depend on a flag or macro the

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

--- Comment #36 from rguenther at suse dot de 2010-02-21 13:37 --- Subject: Re: numeric_limits::is_modulo is inconsistent with gcc On Sun, 21 Feb 2010, veksler at il dot ibm dot com wrote: > > Or suspend it. I think this warrants a defect report anyway since I think > > is_modulo wa

[Bug fortran/36933] unneeded temporary with derived type containing an array as argument

--- Comment #9 from jv244 at cam dot ac dot uk 2010-02-21 14:11 --- (In reply to comment #7) > (In reply to comment #3) > > This could be somewhat similar, I really wonder if this needs a temp: > > > > TYPE T1 > > INTEGER :: a(3) > > END TYPE T1 > > TYPE(T1), POINTER :: x,y > > ALLOCAT

[Bug fortran/36932] unneeded temporary (2x)

--- Comment #14 from jv244 at cam dot ac dot uk 2010-02-21 14:12 --- all fixed -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|NEW

[Bug fortran/41113] spurious _gfortran_internal_pack

--- Comment #24 from jv244 at cam dot ac dot uk 2010-02-21 14:16 --- (In reply to comment #23) > Subject: Re: spurious _gfortran_internal_pack > > I was going to check out the situation for 4.4. However, my > inclination is to close it. I'll be working on it tonight. this is not stu

[Bug target/27016] [4.3/4.4/4.5 Regression] ARM optimizer produces severely suboptimal code

--- Comment #8 from steven at gcc dot gnu dot org 2010-02-21 14:32 --- I have played with CSiBE with this patch: -- 8< - --- ../../gcc/gcc/config/arm/arm.c 2010-02-12 21:45:29.0 +0100 +++ ../../combined/gcc/config/

[Bug c/43128] c-c++-common/pr41779.c doesn't work

--- Comment #7 from hjl dot tools at gmail dot com 2010-02-21 15:39 --- It also failed on Linux/x86-64 with -m32: FAIL: c-c++-common/pr41779.c -Wc++-compat (test for warnings, line 30) -- hjl dot tools at gmail dot com changed: What|Removed |Ad

[Bug c/43125] [4.5 Regression] Revision 156907 failed gcc.dg/attr-used.c

-- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |c Ever Confi

[Bug c/43128] c-c++-common/pr41779.c doesn't work

-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43128

[Bug fortran/38199] missed optimization: I/O performance

--- Comment #10 from jvdelisle at gcc dot gnu dot org 2010-02-21 15:59 --- An update. I have a patch developing. Conceptually, it requires handling of separators in list_read.c to be moved to the beginning of each invocation of list_formatted_read_scalar. This avoids trying to eat_sp

[Bug other/42980] GCC parallel "make install" failures

--- Comment #5 from rwild at gcc dot gnu dot org 2010-02-21 16:13 --- Thanks for the logs. I don't understand the libiberty installation failure yet. Can you please run the following, and provide the log file and the number of runs needed, in case it provokes a failure? while make -j

[Bug c/43128] c-c++-common/pr41779.c doesn't work

--- Comment #8 from hjl dot tools at gmail dot com 2010-02-21 16:15 --- It is C99 and ILP32: [...@gnu-6 gcc]$ ./xgcc -B./ -S /export/gnu/import/git/gcc/gcc/testsuite/c-c++-common/pr41779.c -Wconversion -m32 -std=c99 [...@gnu-6 gcc]$ ./xgcc -B./ -S /export/gnu/import/git/gcc/gcc/tests

[Bug c/40528] Add a new ifunc attribute

--- Comment #13 from agner at agner dot org 2010-02-21 16:21 --- What is the status of this issue? Is option 3 implemented? Which versions of Linux and binutils support IFUNC? Any plans for BSD and Mac? -- agner at agner dot org changed: What|Removed

[Bug other/43132] New: installation directory defaults do not match documentation, Coding Standards

Since the update to Autoconf >= 2.60, the installation directory defaults do not match the GNU Coding Standards, nor do they match the semantics documented in the manual. The problems are described in more detail in . Opening this bug so th

[Bug web/43133] New: changes.html needs to document configure API changes due to autotools upgrade

The autotools upgrade (specifically, the move to Autoconf >= 2.60) changed installation directory variable defaults. This patch would do that, but it is not correct as of now, because of the issues mentioned in PR 43132 and in

[Bug other/43134] New: installation directory defaults do not match documentation, Coding Standards

Since the update to Autoconf >= 2.60, the installation directory defaults do not match the GNU Coding Standards, nor do they match the semantics documented in the manual. The problems are described in more detail in . Opening this bug so th

[Bug other/43134] installation directory defaults do not match documentation, Coding Standards

--- Comment #1 from rwild at gcc dot gnu dot org 2010-02-21 16:28 --- sorry for the dupe *** This bug has been marked as a duplicate of 43132 *** -- rwild at gcc dot gnu dot org changed: What|Removed |Added

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

--- Comment #1 from rwild at gcc dot gnu dot org 2010-02-21 16:28 --- *** Bug 43134 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43132

[Bug web/43133] changes.html needs to document configure API changes due to autotools upgrade

-- rwild at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirm

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

-- rwild at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirm

[Bug c/40528] Add a new ifunc attribute

--- Comment #14 from hjl dot tools at gmail dot com 2010-02-21 16:34 --- (In reply to comment #13) > What is the status of this issue? It is implemented on ifunc branch. > Is option 3 implemented? Yes, on ifunc branch. > Which versions of Linux and binutils support IFUNC? You need

[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work

--- Comment #9 from hjl dot tools at gmail dot com 2010-02-21 16:46 --- On Linux/ia32, -std=c99 changes silently float to long double and we don't get a warning. It is a regression from gcc 4.4. -- hjl dot tools at gmail dot com changed: What|Removed

[Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location

--- Comment #3 from dodji at gcc dot gnu dot org 2010-02-21 16:47 --- Okay Daniel, your POV makes sense to me. Thank you. I am preparing a patch. -- dodji at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work

--- Comment #10 from hjl dot tools at gmail dot com 2010-02-21 16:47 --- [...@gnu-6 gcc]$ cat /tmp/x.i float f5(float x, int y) { return x * y; } [...@gnu-6 gcc]$ gcc -S /tmp/x.i -Wconversion -m32 -std=c99 /tmp/x.i: In function ‘f5’: /tmp/x.i:3: warning: conversion to ‘float’ from ‘in

[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work

--- Comment #11 from manu at gcc dot gnu dot org 2010-02-21 17:25 --- I may have miscompared the bootstrap results to miss this because I do test -m32. Yes, the excess precision stuff changes the common type to long double in build_binary_op in C and -m32 (but not in C++!). Joseph, is

[Bug other/43132] installation directory defaults do not match documentation, Coding Standards

--- Comment #2 from rwild at gcc dot gnu dot org 2010-02-21 17:27 --- I think one way to start addressing this would be to transport an unexpanded docdir='${datarootdir}/doc/${PACKAGE}' through to the sub makes (it's fairly irrelevant whether datarootdir is expanded in the toplevel or

[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work

--- Comment #12 from joseph at codesourcery dot com 2010-02-21 17:43 --- Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't work There is a technical bug here, in that the semantics I intended to implement and said I was implementing were that implicit conversions from in

[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work

--- Comment #13 from manu at gcc dot gnu dot org 2010-02-21 17:57 --- (In reply to comment #12) > Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't > work Sorry I do not understand completely your answer. Shouldn't we warn at all? If the semantics were implemented as intend

[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work

--- Comment #14 from hjl dot tools at gmail dot com 2010-02-21 18:00 --- That is true that the previous release didn't have proper excess precision semantics. But from the user perspective, the previous release handles -- float f5(float x, int y) { return x * y; } -- correctly with

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

--- Comment #37 from gdr at integrable-solutions dot net 2010-02-21 18:04 --- Subject: Re: numeric_limits::is_modulo is inconsistent with gcc On Sun, Feb 21, 2010 at 7:04 AM, rguenth at gcc dot gnu dot org wrote: > Or suspend it.  I think this warrants a defect report anywa

[Bug c++/42824] [4.5 regression] c++ compilation complains about error: call of overloaded

--- Comment #14 from dodji at gcc dot gnu dot org 2010-02-21 18:07 --- Subject: Bug 42824 Author: dodji Date: Sun Feb 21 18:06:39 2010 New Revision: 156939 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156939 Log: Fix PR c++/42824 gcc/cp/ChangeLog: PR c++/42824

[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work

--- Comment #15 from joseph at codesourcery dot com 2010-02-21 18:15 --- Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't work On Sun, 21 Feb 2010, manu at gcc dot gnu dot org wrote: > Sorry I do not understand completely your answer. Shouldn't we warn at all? If > the s

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

--- Comment #38 from veksler at il dot ibm dot com 2010-02-21 18:20 --- (In reply to comment #37) > is_modulo is intended to describe the implementation's choice, not necessarily > the CPU behaviour (which the implementation may choose to mask or not.) > > The issue here is that GCC do

[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work

--- Comment #16 from manu at gcc dot gnu dot org 2010-02-21 18:25 --- (In reply to comment #15) > > With the intended semantics, we should warn; there would be an actual > conversion from integer to float there, that could change the value. Great. Any hints where could be the problem

[Bug c/43128] [4.5 Regression] c-c++-common/pr41779.c doesn't work

--- Comment #17 from joseph at codesourcery dot com 2010-02-21 18:32 --- Subject: Re: [4.5 Regression] c-c++-common/pr41779.c doesn't work On Sun, 21 Feb 2010, manu at gcc dot gnu dot org wrote: > --- Comment #16 from manu at gcc dot gnu dot org 2010-02-21 18:25 --- > (In r

[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc

--- Comment #39 from gdr at integrable-solutions dot net 2010-02-21 18:50 --- Subject: Re: numeric_limits::is_modulo is inconsistent with gcc On Sun, Feb 21, 2010 at 12:20 PM, veksler at il dot ibm dot com wrote: > --- Comment #38 from veksler at il dot ibm dot com  2010

[Bug c++/17459] Spurious message when forgetting parentheses on call of member

--- Comment #3 from manu at gcc dot gnu dot org 2010-02-21 19:07 --- More weirdeness. // PR c++/17459: Spurious message when forgetting parentheses on call of member // { dg-do compile } struct S { void foo(); void bar() { foo; } // { dg-error "statement cannot resolve address of ov

[Bug c++/18016] Warn about member variables initialized with itself

--- Comment #6 from manu at gcc dot gnu dot org 2010-02-21 19:17 --- (In reply to comment #5) > Is there any chance of activity on this bug? > It would be wonderful to have a warning for this > case, since these bugs can be extremely annoying to find. -Winit-self is generally broken for

[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923

--- Comment #6 from dodji at gcc dot gnu dot org 2010-02-21 20:19 --- The resolution of PR c++/43036 seems related to array types only. So I don't understand why it fixes this PR. I'd like to investigate a bit further. The test case is too big for me to understand it so I am delta-reduc

[Bug c++/23510] skip some instantation contexts if there are too many

--- Comment #5 from manu at gcc dot gnu dot org 2010-02-21 21:20 --- Subject: Bug 23510 Author: manu Date: Sun Feb 21 21:20:04 2010 New Revision: 156942 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156942 Log: 2010-02-21 Manuel López-Ibáñez PR c++/23510 cp/

[Bug c++/23510] skip some instantation contexts if there are too many

--- Comment #6 from manu at gcc dot gnu dot org 2010-02-21 21:21 --- FIXED in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIG

[Bug c/42199] A problem with -maltivec

--- Comment #3 from galtgendo at o2 dot pl 2010-02-21 21:22 --- There's new input in a different Gentoo bug: http://bugs.gentoo.org/show_bug.cgi?id=305333 Apparently in certain conditions on ppc, bool is both defined and undefined. Unless you'll see that as bad code on openjpeg side.

[Bug target/33767] GLOBAL_ASM_OP needs to be documented in tm.texi

--- Comment #1 from davek at gcc dot gnu dot org 2010-02-21 22:27 --- just ran into this myself! -- davek at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/42994] Status of using both -m32 and -m64 on the same command line

--- Comment #4 from manu at gcc dot gnu dot org 2010-02-21 23:21 --- So this is confirmed, yes? no? Joseph? -- manu at gcc dot gnu dot org changed: What|Removed |Added

[Bug tree-optimization/43026] [4.5 Regression][graphite] ICE in sese.c with -fgraphite-identity in 447.dealII

--- Comment #6 from grosser at gcc dot gnu dot org 2010-02-22 00:42 --- I believe this commit introduced the bug: Remove COMPONENT_REF limitation in SCoP detection. 2010-01-08 Sebastian Pop * graphite-scop-detection.c (exclude_component_ref): Removed. (is_si

[Bug libstdc++/21321] [4.3/4.4/4.5 regression] mmix-knuth-mmixware 27_io/basic_filebuf/seekpos/12790-3.cc execution test

--- Comment #17 from hp at gcc dot gnu dot org 2010-02-22 01:31 --- (In reply to comment #13) > Is this still an issue? To be honest I have no idea if this target is still in > good shape or not... Not that this PR is dependent on the shape of the port, but at r156927 it was in unexpect

[Bug c++/43135] New: Possible bug in name resolution during template instantiation

I'm reporting this against my system compiler (4.1.2 on NetBSD/macppc), but I can reproduce it using all versions from 3.4 (when two-stage name lookup was introduced) to 4.4 - which I was able to test on a linux/amd64 machine with a large collection of compilers installed. The following code (mini

[Bug c++/43135] Possible bug in name resolution during template instantiation

--- Comment #1 from uwe at netbsd dot org 2010-02-22 02:51 --- Created an attachment (id=19932) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19932&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43135

[Bug c++/43135] Possible bug in name resolution during template instantiation

--- Comment #2 from bangerth at gmail dot com 2010-02-22 03:56 --- This is not a bug. Because the base class of Node::OpNode does not depend on template arguments, the members of the base class are visible in Node::OpNode::f(). On the other hand, since the base class of Node::FooOpNode d

[Bug c++/43135] Possible bug in name resolution during template instantiation

--- Comment #3 from uwe at netbsd dot org 2010-02-22 04:08 --- (In reply to comment #2) > This is not a bug. Because the base class of Node::OpNode does not > depend on template arguments, the members of the base class are > visible in Node::OpNode::f(). On the other hand, since the base

[Bug c++/43135] Possible bug in name resolution during template instantiation

--- Comment #4 from bangerth at gmail dot com 2010-02-22 04:29 --- (In reply to comment #3) > But doesn't this error happens during instantiation as the error message > indicates? If definition of Node::FooNode is commented out, the templates > themselves are accepted. What I meant to

[Bug c++/43135] Possible bug in name resolution during template instantiation

--- Comment #5 from uwe at netbsd dot org 2010-02-22 04:45 --- (In reply to comment #4) > What I meant to say is this: during parsing ... So do I get this right (knowing nothing about g++ internals) that in the first phase ("during parsing") the call to "test" is resolved to sibling be

[Bug c++/43135] Possible bug in name resolution during template instantiation

--- Comment #6 from uwe at netbsd dot org 2010-02-22 04:47 --- (In reply to comment #5) > What confuses me is that explictly qualifying the offending call as > > Node::test(op.i) > > makes it compile correctly. I mean as far as I understand Node::test should resolve to the same sibl

[Bug fortran/43072] unneeded temporary (s=s+f(a))

--- Comment #7 from pault at gcc dot gnu dot org 2010-02-22 05:44 --- Subject: Bug 43072 Author: pault Date: Mon Feb 22 05:43:57 2010 New Revision: 156949 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156949 Log: 2010-02-22 Paul Thomas PR fortran/43072 * dep

[Bug fortran/41113] spurious _gfortran_internal_pack

--- Comment #25 from pault at gcc dot gnu dot org 2010-02-22 05:45 --- Fixed on trunk. Thanks for reportimg the problems and all the help, Tobias and Joost. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/41117] spurious _gfortran_internal_pack (II)

--- Comment #5 from pault at gcc dot gnu dot org 2010-02-22 05:45 --- Fixed on trunk. Thanks for reportimg the problems and all the help, Tobias and Joost. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added

[Bug fortran/38112] unneeded temporary

--- Comment #3 from pault at gcc dot gnu dot org 2010-02-22 05:48 --- Fixed on trunk. Thanks for reportimg the problem, Joost. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added -

[Bug fortran/43136] New: Excess copy-in/copy-out with character argument

After fixing, 43072 and friends, one excess copy-in and copy-out remains, where a substring describes the declared string length. The testcase is in internal_pack_9.f90: subroutine foo2 implicit none external foo character(len=20) :: str(2) = '1234567890' call foo(str(:)(1:20)) ! This is

[Bug rtl-optimization/20211] autoincrement generation is poor

--- Comment #39 from amylaar at gcc dot gnu dot org 2010-02-22 06:04 --- (In reply to comment #38) > Maybe this issue migrated into PR31849? Not entirely, PR31849 is tree-optimization, and a lot of auto-increment opportunities are only visible at the rtl level. -- http://gcc.gnu.o

[Bug libstdc++/21321] [4.3/4.4/4.5 regression] mmix-knuth-mmixware 27_io/basic_filebuf/seekpos/12790-3.cc execution test

--- Comment #18 from hp at gcc dot gnu dot org 2010-02-22 07:05 --- Results at . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321