--- Comment #8 from jakub at gcc dot gnu dot org 2007-09-24 06:36 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- 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=14248action=view)
volatile nrv patch
--
chrbr at gcc dot gnu dot org changed:
What|Removed
--- 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 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
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
--- 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
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
--- 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
--- 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 #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=gccview=revrev=128709
Log:
PR debug/33316
* dwarf2out.c (modified_type_die):
--- 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
--
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
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
--- 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
--- 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
--- 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=14249action=view)
output of 'g++ -Wall -O3 -march=native -v -c test.cc'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33540
--- 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=gccview=revrev=128711
Log:
2007-09-24 Douglas Gregor [EMAIL PROTECTED]
PR
--- 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=gccview=revrev=128711
Log:
2007-09-24 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #7 from ubizjak at gmail dot com 2007-09-24 12:39 ---
Fixed by http://gcc.gnu.org/viewcvs?view=revrevision=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 #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 #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 #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 #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=14250action=view)
testcase
Btw, here's the (partly preprocessed) testcase I used.
--
--- 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
--- 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=gccview=revrev=128717
Log:
2007-09-24 Douglas Gregor [EMAIL PROTECTED]
PR
--- 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 #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.
--
--- 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
--- 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
--- 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
--- 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=gccview=revrev=128718
Log:
PR c++/33506
* langhooks.h (struct
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
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)
1
--- 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
--- 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 #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 #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
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 model
--- 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)
--- 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
--- 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 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
$ 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( obj );
--- 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
--- 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 #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 is
--- 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 #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 :-)
--
--- 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
--- 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
--- 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 #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 #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
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
--- 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;
--- 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=gccview=revrev=128724
Log:
PR fortran/33538
* scanner.c, parse.c,
--- 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 #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
--- 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 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=gccview=revrev=128725
Log:
PR c++/33239
* pt.c (resolve_typename_type): Don't
--- 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 #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
--- 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 #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 #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=gccview=revrev=128732
Log:
PR fortran/33269
fortran/
* io.c (check_format_string): Move NULL
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.
Though I
--- 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
--- 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
--
--- 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
--
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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=gccview=revrev=128740
Log:
PR c++/14688
* config/i386/i386.c
--- 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 #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 #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
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 #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=gccview=revrev=128741
Log:
2007-08-26 Rask Ingemann Lambertsen [EMAIL PROTECTED]
PR target/33184
--- 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=gccview=revrev=128742
Log:
PR target/31482
* config/m32c/cond.md (stzx_reversed_mode): Add an
--- 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 #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 #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 #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
--
bangerth at dealii dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33467
--- 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
88 matches
Mail list logo
