Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1abc1549a6a164f1/
by James Van Buskirk:
-
module M1
real x
end module M1
module M2
contains
subroutine y
end subroutine y
end module M2
module M3
use M2, x => y
end module M
--- Comment #10 from tobi at gcc dot gnu dot org 2007-09-25 05:39 ---
Fixed.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
bangerth at dealii dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33467
--- Comment #12 from bangerth at dealii dot org 2007-09-25 04:22 ---
(In reply to comment #11)
> Here is what the C++ standard says about linkage:
> A template name may have linkage (3.5). A template, a template explicit
> specialization (14.7.3), or a class
> template partial specializa
--- Comment #7 from dj at redhat dot com 2007-09-25 02:15 ---
Seems to work for me now; could you recheck it with the patches I just
committed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32656
--- Comment #3 from dj at redhat dot com 2007-09-25 01:46 ---
Patch applied.
--
dj at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from dj at redhat dot com 2007-09-25 01:46 ---
Patch applied.
--
dj at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from dj at gcc dot gnu dot org 2007-09-25 01:42 ---
Subject: Bug 31482
Author: dj
Date: Tue Sep 25 01:42:34 2007
New Revision: 128742
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128742
Log:
PR target/31482
* config/m32c/cond.md (stzx_reversed_): Add an output
c
--- Comment #2 from dj at gcc dot gnu dot org 2007-09-25 01:40 ---
Subject: Bug 33184
Author: dj
Date: Tue Sep 25 01:40:30 2007
New Revision: 128741
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128741
Log:
2007-08-26 Rask Ingemann Lambertsen <[EMAIL PROTECTED]>
PR target/331
The source tree in the below build is under /tmp/gcc-4.2.1--x---xx/. Note
how the path contains 1, then 2, then 3, then 4 hyphens.
BEGIN BUILD LOG EXCERPT
if [ xinfo = xinfo ]; then \
makeinfo --split-size=500 --split-size=500 --split-size=500
--no-split -I . -I ../
--- Comment #3 from danglin at gcc dot gnu dot org 2007-09-25 01:22 ---
Fixed:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01545.html
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from danglin at gcc dot gnu dot org 2007-09-25 01:05 ---
The 4.0 branch is closed, so why is this a blocker? Need to know
if this is present in 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33467
--- Comment #8 from dannysmith at users dot sourceforge dot net 2007-09-25
00:31 ---
Fixed on trunk
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--
--- Comment #7 from dannysmith at gcc dot gnu dot org 2007-09-25 00:29
---
Subject: Bug 14688
Author: dannysmith
Date: Tue Sep 25 00:29:42 2007
New Revision: 128740
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128740
Log:
PR c++/14688
* config/i386/i386.c (ix8
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-09-25 00:09
---
Here is what the C++ standard says about linkage:
A template name may have linkage (3.5). A template, a template explicit
specialization (14.7.3), or a class
template partial specialization shall not have C linkage
--- Comment #8 from pcarlini at suse dot de 2007-09-24 23:33 ---
Therefore, if I understand correctly, we want to reject the code and 4.2.0 was
already implementing that behavior. This is not a regression, we can close it
as fixed. If I'm mistaken, please reopen, thanks.
--
pcarlini
I am getting a core dump with a program compiled with gcc-4.1.2 (64bit). The
program crashed inside the function call pam_authenticate.
The program uses the pam library and is compiled by the following command:
gcc-4.1.2/bin/gcc -mlp64 pam_test.c -lpam -o pt
-bash-3.00$ ldd pt
libpam.so.
--- Comment #5 from wilson at gcc dot gnu dot org 2007-09-24 22:53 ---
Echoing what Andrew Pinski already said, this isn't C code, this is RTL code,
the format of which is specified by the read-rtl.c file. Specifically, see the
read_brace_string function, which accepts backslash quoting
--- Comment #24 from bangerth at dealii dot org 2007-09-24 22:07 ---
Since the original issue is resolved and the audit trail of the bug already
very long, I'll close this PR. If you feel that the missed optimization
isn't addressed yet, please open a new report with this issue that sole
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2007-09-24 21:49 ---
Subject: Re: Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of
gfortran
On Mon, Sep 24, 2007 at 09:26:01PM -, pinskia at gmail dot com wrote:
> On 24 Sep 2007 19:59:37 -, sgk a
--- Comment #9 from patchapp at dberlin dot org 2007-09-24 21:48 ---
Subject: Bug number PR33269
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01797.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #7 from patchapp at dberlin dot org 2007-09-24 21:45 ---
Subject: Bug number PR7
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01712.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #6 from pinskia at gmail dot com 2007-09-24 21:26 ---
Subject: Re: Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of
gfortran
On 24 Sep 2007 19:59:37 -, sgk at troutmask dot apl dot washington
dot edu <[EMAIL PROTECTED]> wrote:
> The programmer for whatever
On 24 Sep 2007 19:59:37 -, sgk at troutmask dot apl dot washington
dot edu <[EMAIL PROTECTED]> wrote:
> The programmer for whatever reason could be using rft as temporary storage.
> Yes, I know it's a hypothetical situation, but the following is legal code
> and should not give a warning.
Thou
--- Comment #8 from tobi at gcc dot gnu dot org 2007-09-24 21:15 ---
Subject: Bug 33269
Author: tobi
Date: Mon Sep 24 21:15:00 2007
New Revision: 128732
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128732
Log:
PR fortran/33269
fortran/
* io.c (check_format_string): Move NULL a
--- Comment #1 from schwab at suse dot de 2007-09-24 21:13 ---
0x4E+0x23 is a single preprocessing number. If that cannot be turned into a
valid token then the program is malformed. Put in some space.
--
schwab at suse dot de changed:
What|Removed
--- Comment #10 from jason at gcc dot gnu dot org 2007-09-24 21:00 ---
Fixed in 4.3.0. Not sure if the fix should go into 4.2.x, since it's an ABI
change.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from jason at gcc dot gnu dot org 2007-09-24 20:56 ---
Fixed for 4.3.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASS
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-24 20:55 ---
Re-reading the Fortran standard, I believe now that already "call foo(10)" is
invalid (although it is not ambiguous).
"Two or more accessible entities, other than generic interfaces or
defined operators, may have the
--- Comment #6 from jason at gcc dot gnu dot org 2007-09-24 20:54 ---
Subject: Bug 33239
Author: jason
Date: Mon Sep 24 20:54:34 2007
New Revision: 128725
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128725
Log:
PR c++/33239
* pt.c (resolve_typename_type): Don'
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-24 20:54 ---
we clearly don't do enhancements for a release branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-24 20:28
---
It would be nice to find a patch that doesn't break bootstrap on plenty of
platforms :)
I'll be on it when I have time, PR 33538 indicates the trouble caused by my
first patch, now reverted.
--
fxcoudert at g
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-24 20:26
---
Patch reverted, trunk should be back on track. Sorry.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-24 20:24
---
Subject: Bug 33538
Author: fxcoudert
Date: Mon Sep 24 20:24:11 2007
New Revision: 128724
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128724
Log:
PR fortran/33538
* scanner.c, parse.c, g
--- Comment #5 from falk at debian dot org 2007-09-24 20:18 ---
As noted by Edvin Török, the bug is not fixed for the original test case
(although it is fixed for the small test case). A small test case that still
fails is
int f(void);
void acceptloop_th(int *t) {
int options = 0;
Compiling the following simple snippet:
void foo(void)
{
int i = 0x4E+0x23;
}
triggers the error message indicated in the summary.
Analysis of the problem shows that the macro VALID_SIGN() used inside
lex_number() (libcpp/lex.c) misidentifiex the plus sign following the
E (possible expon
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-09-24 19:59 ---
Subject: Re: Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of
gfortran
On Mon, Sep 24, 2007 at 07:17:54PM -, burnus at gcc dot gnu dot org wrote:
>
>
> --- Comment #4 from b
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-24 19:46 ---
Fixed via http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00696.html .
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-09-24 19:45
---
The testcase in comment #12 was fixed via
http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00696.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-24 19:17 ---
> We may want to hide the warning behind a -Wshort-transfer option
> (or some other appropriate name).
Maybe; I think having a warning by default would be more reasonable but it
should be hideable.
> Afterall, if a p
--- Comment #3 from kargl at gcc dot gnu dot org 2007-09-24 18:57 ---
Tobias,
We may want to hide the warning behind a -Wshort-transfer option
(or some other appropriate name). Afterall, if a programmer
wrote 'rft = transfer(' ', 0.0)', then s/he probably meant it.
--
kargl at gcc
--- Comment #8 from bangerth at dealii dot org 2007-09-24 18:57 ---
(In reply to comment #7)
> Actually, I've fixed several of those in the past few weeks.
I think this very much appreciated fact was what caused Richard to CC:
you on this PR :-)
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-24 18:24 ---
And enhancements only go for the next version and never on production code
(release branches) (like any sane product release should happen, even physicial
ones).
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from pluto at agmk dot net 2007-09-24 18:21 ---
(In reply to comment #1)
> If this has already been fixed on the trunk, then what is the issue?
>
4.3 is not ready for production use.
4.2.2 is quite stable and this missed optimization
introduces a redundant branch which i
--- Comment #2 from pcarlini at suse dot de 2007-09-24 18:10 ---
Maybe the underlying issue is tree-optimization/3713, not fixed in
less-than-trivial cases?
--
pcarlini at suse dot de changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-24 18:07 ---
If this has already been fixed on the trunk, then what is the issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33546
$ cat 0.cpp
template < typename R, typename T, R ( T::* method )() >
static inline R dispatch( T& object )
{
return ( object.*method )();
}
struct X
{
virtual ~X();
virtual void f();
};
void test1( X& obj )
{
void ( *f )( X& ) = dispatch< void, X, &X::f >;
f(
--- Comment #5 from pcarlini at suse dot de 2007-09-24 18:01 ---
Isn't the C++ front-end also fixed? I can confirm that currently the error
comes from cp_parser_jump_statement. In general, the check in build_bc_goto is
apparently dead: I have been able to build and test with gcc_assert
--- Comment #12 from appfault at hotmail dot com 2007-09-24 17:48 ---
Due to lack of responsiveness, a separate Bug 33394 was opened for the missing
test case. Verified this is generically in concept a duplicate of bug 21334,
although the technical details are in fact not the same.
--
--- Comment #5 from jsm28 at gcc dot gnu dot org 2007-09-24 17:36 ---
Working on a patch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-24 17:26 ---
(In reply to comment #0)
> When I compile the program listed below with the snapshot version of gfortran
> dated September 24 I get the following spurious warning:
> pp.f90:3.15:
> rft = TRANSFER(' ', 0.0)
>
I just tried compiling mainline on my dusty alphaev67-dec-osf5.1 and discovered
that recent RTL CFG changes have broken the way that exceptions are implemented
on alpha/Tru64. Natively, this is seen with "configure" and "make bootstrap"
as a breakage configuring libstdc++-v3 where the "exception m
--- Comment #7 from jason at redhat dot com 2007-09-24 17:05 ---
Subject: Re: wrong constructor called -- default argument in
constructor not seen
rguenth at gcc dot gnu dot org wrote:
> Looks like non-regression wrong-code bugs get no attention :/
Actually, I've fixed several of tho
--- Comment #9 from pcarlini at suse dot de 2007-09-24 17:05 ---
In any case, the pre-processed code doesn't compile anymore with 4.2 and
mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
---
--- Comment #4 from pcarlini at suse dot de 2007-09-24 16:46 ---
I see, thanks. Well, if I can bother you a bit more about your very welcome
work on attribute aligned, I noticed also PR10179. Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21385
--- Comment #1 from pinskia at gmail dot com 2007-09-24 15:53 ---
Subject: Re: New: Spurious warning in TRANSFER intrinsic in Sept 24 snapshot
of gfortran
On 24 Sep 2007 15:48:19 -, michael dot a dot richmond at nasa dot
gov <[EMAIL PROTECTED]> wrote:
> When I compile the program l
On 24 Sep 2007 15:48:19 -, michael dot a dot richmond at nasa dot
gov <[EMAIL PROTECTED]> wrote:
> When I compile the program listed below with the snapshot version of gfortran
> dated September 24 I get the following spurious warning:
>
> pp.f90:3.15:
> rft = TRANSFER(' ', 0.0)
>
When I compile the program listed below with the snapshot version of gfortran
dated September 24 I get the following spurious warning:
pp.f90:3.15:
rft = TRANSFER(' ', 0.0)
1
Warning: Intrinsic TRANSFER at (1) has partly undefined result: source size 1 <
result size 4
PROGRAM printd
--- Comment #1 from jakub at gcc dot gnu dot org 2007-09-24 15:16 ---
Subject: Bug 33506
Author: jakub
Date: Mon Sep 24 15:16:23 2007
New Revision: 128718
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128718
Log:
PR c++/33506
* langhooks.h (struct lang_hooks_for
--- Comment #4 from bangerth at dealii dot org 2007-09-24 14:30 ---
My reasoning would be that in the call d%g, the type of the two
expressions are 'double&' and 'A&'. So to call the user-defined
operator%, only the first argument has to be converted to 'A' for which
a conversion constru
--- Comment #3 from pcarlini at suse dot de 2007-09-24 14:07 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot g
--- Comment #3 from martinezfive at comcast dot net 2007-09-24 13:59
---
I spoke with the people at EDG and they have confirmed their compiler's
acceptance of the code indeed constitutes a bug. Since almost every last EDG
developer is also a member of the ISO C++ Core Committee (and vi
--- Comment #9 from jason at gcc dot gnu dot org 2007-09-24 13:53 ---
I'm reluctant to backport the changes to 4.2 now because they're fairly
intrusive; I'm not sufficiently confident yet that the change in typedef
handling won't introduce other problems.
--
http://gcc.gnu.org/bugzi
--- Comment #12 from dgregor at gcc dot gnu dot org 2007-09-24 13:47
---
Fixed, for real. Thanks for the ice_canonical.cpp test-case: it illustrated the
(other) underlying problem that wasn't apparent in 33112.
--
dgregor at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from dgregor at gcc dot gnu dot org 2007-09-24 13:46
---
Subject: Bug 33185
Author: dgregor
Date: Mon Sep 24 13:46:40 2007
New Revision: 128717
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128717
Log:
2007-09-24 Douglas Gregor <[EMAIL PROTECTED]>
PR
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-24 13:45 ---
See PR33502 and http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01721.html for the
patch which causes the regression.
See also http://gcc.gnu.org/ml/fortran/2007-09/msg00394.html
--
burnus at gcc dot gnu dot org chan
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-24 13:10 ---
Created an attachment (id=14250)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14250&action=view)
testcase
Btw, here's the (partly preprocessed) testcase I used.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-24 13:07 ---
haha, 300MB is nothing unusual. Btw, there's no libjava/interpreter.cc but
libjava/interpret.cc. And that uses only ~200MB on x86_64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32653
--- Comment #6 from dgregor at gcc dot gnu dot org 2007-09-24 12:52 ---
Fixed by the patch below
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from bonzini at gnu dot org 2007-09-24 12:39 ---
CCing resident memory-hog bug killer.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #7 from ubizjak at gmail dot com 2007-09-24 12:39 ---
Fixed by http://gcc.gnu.org/viewcvs?view=rev&revision=128710:
2007-09-24 Kai Tietz <[EMAIL PROTECTED]>
PR middle-end/33472
* config/i386/i386.c (return_in_memory_ms_64): Handle return types for
--- Comment #5 from dgregor at gcc dot gnu dot org 2007-09-24 12:15 ---
Subject: Bug 33112
Author: dgregor
Date: Mon Sep 24 12:14:57 2007
New Revision: 128711
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128711
Log:
2007-09-24 Douglas Gregor <[EMAIL PROTECTED]>
PR c
--- Comment #10 from dgregor at gcc dot gnu dot org 2007-09-24 12:15
---
Subject: Bug 33185
Author: dgregor
Date: Mon Sep 24 12:14:57 2007
New Revision: 128711
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128711
Log:
2007-09-24 Douglas Gregor <[EMAIL PROTECTED]>
PR
--- Comment #5 from ebuddington at wesleyan dot edu 2007-09-24 11:24
---
Created an attachment (id=14249)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14249&action=view)
output of 'g++ -Wall -O3 -march=native -v -c test.cc'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3354
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-24 11:06 ---
The regular perl testsuite fails as well:
t/op/override.ok
t/op/pack.Invalid type ']' in unpack at
op/pack.t line 1363.
# Looks like you planned 13864 test
--- Comment #8 from reichelt at gcc dot gnu dot org 2007-09-24 10:53
---
Fixed on mainline.
Probably by the fix for PR 19407.
Jason, would you mind backporting your patch to the branches?
--
reichelt at gcc dot gnu dot org changed:
What|Removed |
The gccinstall documentation can be generated from the install.texi2html
script, but not from the install.texi file.
make html invokes makeinfo on the install.texi file, but it doesn't generate
the full HTML documentation.
The texi file as-is might not be buggy, because the PDF documentation wor
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19407
--- Comment #6 from jakub at gcc dot gnu dot org 2007-09-24 09:18 ---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33316
--- Comment #5 from jakub at gcc dot gnu dot org 2007-09-24 09:17 ---
Subject: Bug 33316
Author: jakub
Date: Mon Sep 24 09:17:10 2007
New Revision: 128709
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128709
Log:
PR debug/33316
* dwarf2out.c (modified_type_die):
--- Comment #3 from pcarlini at suse dot de 2007-09-24 09:15 ---
Hi Janis, a regression hunt would be useful, indeed... Thanks!
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #14 from pcarlini at suse dot de 2007-09-24 09:06 ---
I think Gaby said the issue doesn't exist anymore after Roger work. Otherwise,
please reopen, thanks.
--
pcarlini at suse dot de changed:
What|Removed |Added
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1abc1549a6a164f1/
One should re-check it as only g95 and Portland reject it whereas Pathscale,
gfortran, ifort, sunf95,openf95 and especially NAG f95 and Lahey accept it.
The following program is obviously wrong as one
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-24 08:52 ---
Post script: Fortran 95 contains the same in 11.3.2; the only difference is
that Fortran 2003 talks also about defined-operators.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33541
Reported by John Harper,
http://gcc.gnu.org/ml/fortran/2007-09/msg00397.html
The following
use module
use module, only: xrenamed => x
surely makes xrenamed available; however, -- see clause (3) below -- it does
not make 'x' available. In gfortran the symbol 'x' is also imported into the
namesp
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-24 08:36 ---
-v output when compiling, that is,
g++ -Wall -O3 -march=native -c videospeed.cc -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33540
--- Comment #5 from chrbr at gcc dot gnu dot org 2007-09-24 07:14 ---
the attached patch was hanging in my sandbox. will submit it along with a
testsuite case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19531
--- Comment #4 from chrbr at gcc dot gnu dot org 2007-09-24 07:10 ---
Created an attachment (id=14248)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14248&action=view)
volatile nrv patch
--
chrbr at gcc dot gnu dot org changed:
What|Removed |
88 matches
Mail list logo
