--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-10-18 06:03
---
There is one final patch to go before closing this PR. I am testing it now and
developing a test case. This is the part that converts LF to CR-LF for
FORMATTED STREAM IO on those systems that #define
--- Comment #1 from tromey at gcc dot gnu dot org 2006-10-18 06:24 ---
*** This bug has been marked as a duplicate of 29491 ***
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2006-10-18 06:24 ---
*** Bug 29492 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29491
--- Comment #1 from tromey at gcc dot gnu dot org 2006-10-18 06:34 ---
I've done #1 and #3.
The cache code hasn't yet been written.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28454
--- Comment #12 from patchapp at dberlin dot org 2006-10-18 07:01 ---
Subject: Bug number PR29277
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/2006-10/msg00887.html
--
--- Comment #5 from debian-gcc at lists dot debian dot org 2006-10-18
07:35 ---
works with 4.1 4.1.2 20061015, closing.
Matthias
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
Currently the modifier flags synthetic and enum for fields;
and synthetic, bridge, and varargs for methods; are not passed
through gcj and put into the resulting structures in the object
code.
--
Summary: [ecj] some field method flags not passed through
Product: gcc
_M_invalidate function in safe_iterator.tcc is not thread safe against
_M_detach()/_M_attach() functions from _Safe_iterator_base.
Here is the example of erronous scenario:
Thread1()
{
list::iterator iter;
lock(mutex);
iter = myList.begin();
// do something with iter
On Mac OS X PowerPC G4, I type:
gfortran -x f95-cpp-input -DNDIM=3 toto.f90 -o toto
and the compilation of the source was OK, but at link time, I got
In file toto.o:1
\xFE\xED\xFA\xCE\x12\x01\x03\x01(
--- Comment #1 from pcarlini at suse dot de 2006-10-18 09:00 ---
Benjamin and Doug, can you have a look to this issue? Thanks.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from patchapp at dberlin dot org 2006-10-18 09:10 ---
Subject: Bug number PR22372
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/2006-10/msg00892.html
--
See http://gcc.gnu.org/ml/gcc/2005-08/msg00284.html. IMHO it's currently only
working for Linux. Given the author has claimed a big performance boost with
this patch, I guess it should be ported mingw32 since it's also an i386 host.
--
Summary: FTZ/DAZ for SSE should be ported to
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-18 09:18 ---
Subject: Bug 27787
Author: rguenth
Date: Wed Oct 18 09:18:07 2006
New Revision: 117852
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117852
Log:
2006-10-18 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-18 09:18
---
Subject: Bug 25878
Author: rguenth
Date: Wed Oct 18 09:18:07 2006
New Revision: 117852
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117852
Log:
2006-10-18 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-10-18 09:18
---
Fixed on the 4.1 branch by backporting the fix for PR27787.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-10-18 09:24
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-10-18 09:26
---
A backport of the patch bootstraps regtests ok on the 4.1 branch, but I'm
unsure we want the side-effects of the rejects-valid, because this is valid
code according to jsm (only undefined at runtime).
--
--- Comment #33 from rguenth at gcc dot gnu dot org 2006-10-18 09:27
---
A backport bootstraps and regtests ok on the 4.1 branch. Don't know if the
side-effects of this patch makes it appplicable for backporting though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17506
--- Comment #13 from pluto at agmk dot net 2006-10-18 09:34 ---
(In reply to comment #8)
The call int_const_binop to seems to be wrong, if the comment is correct the
following is more correct:
tree tmp = int_const_binop (TRUNC_DIV_EXPR,
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-10-18 09:43 ---
Please attach a complete test case, not a sketch.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29496
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-10-18 09:46 ---
Janis, can you check what fixed this on the mainline? Thanks!
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-18 09:49 ---
I wonder what fixed this on the mainline - janis?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-10-18 10:00
---
Well, this looks like a miscompilation somewhere then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29439
--- Comment #3 from pcarlini at suse dot de 2006-10-18 10:06 ---
Let's suppose the issue is confirmed, and we have an useful complete testcase,
then, a wild idea (at the moment I'm missing many details about the internals
of the safe iterators, sorry): maybe we could explore the
--- Comment #3 from pault at gcc dot gnu dot org 2006-10-18 10:08 ---
(In reply to comment #2)
Thank you, Richard - thanks to your splendid analysis, I was able to go
straight to the source of the problem:
trans-types.c(gfc_get_nodesc_array_type):1038 sets GFC_TYPE_ARRAY_LBOUND to
--- Comment #4 from pcarlini at suse dot de 2006-10-18 10:40 ---
(In reply to comment #3)
I'm
only unsure about the tests this-base() == __victim-base(), I hope can be
done on the base objects too...
And of
--- Comment #3 from shinwell at gcc dot gnu dot org 2006-10-18 10:57
---
Subject: Bug 26884
Author: shinwell
Date: Wed Oct 18 10:57:18 2006
New Revision: 117854
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117854
Log:
PR c++/26884
* typeck2.c (digest_init):
--- Comment #4 from shinwell at gcc dot gnu dot org 2006-10-18 10:57
---
Subject: Bug 26884
Author: shinwell
Date: Wed Oct 18 10:57:37 2006
New Revision: 117855
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117855
Log:
PR c++/26884
* typeck2.c (digest_init):
--- Comment #5 from shinwell at gcc dot gnu dot org 2006-10-18 10:58
---
Fixed in mainline and 4.1 (revs 117854 and 117855 respectively).
--
shinwell at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from irar at il dot ibm dot com 2006-10-18 11:03 ---
(In reply to comment #13)
We need to check if above patch fixes PR26969 as well.
Checked, it does not.
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #9 from patchapp at dberlin dot org 2006-10-18 11:20 ---
Subject: Bug number PR29216
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/2006-10/msg00900.html
--
--- Comment #6 from pcarlini at suse dot de 2006-10-18 11:37 ---
A straightforward approach to the problem uses the unsigned type associated
with _Distance (via __gnu_cxx::__add_unsigned) to avoid the risk of overflows
in __adjust_heap completely. I'm currently looking into the cleanest
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-10-18 12:31
---
The Fortran people are interested in this. For full F2003 support, we need the
Fortran front-end to know during code generation which integer mode correspond
to certain C integer types, including the int_fastN_t,
--- Comment #5 from matz at gcc dot gnu dot org 2006-10-18 14:04 ---
The problem is in libcpp/files.c:open_file_failed. It deliberately only
gives a warning when producing dependencies (and under some circumstances
doesn't even give a warning) for missing files. I think it does that
--- Comment #2 from dir at lanl dot gov 2006-10-18 14:37 ---
This turned out to be a gtk bug - a rebuild of glib-2.12.4 followed by a
rebuild of gtk+-2.10.6 fixed the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29491
--- Comment #5 from grzes at nec-labs dot com 2006-10-18 14:40 ---
I encountered this bug (?) in the past. I thought, maybe incorrectly, that
accessing an interator (e.g copying it) equals read access to a container,
hence no thread safety guarnatees for concurrent modifications to the
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--- Comment #3 from patchapp at dberlin dot org 2006-10-18 14:50 ---
Subject: Bug number PR c++/28053
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/2006-10/msg00913.html
--
--- Comment #4 from patchapp at dberlin dot org 2006-10-18 15:00 ---
Subject: Bug number PR c++/29363
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/2006-10/msg00914.html
--
--- Comment #2 from ian at davenant dot greenend dot org dot uk 2006-10-18
15:11 ---
Again this is a policy issue rather than really a bug, I am
thinking about closing this as invalid as I thought our policy is clear.
I'm afraid I don't understand. What policy are you referring to
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-10-18 15:12 ---
Subject: Bug 28829
Author: rguenth
Date: Wed Oct 18 15:11:52 2006
New Revision: 117856
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117856
Log:
2006-10-18 Richard Guenther [EMAIL PROTECTED]
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-10-18 15:56 ---
Paolo: Seems like an interesting idea.
Grzegorz: interesting that others have run into this. Without a testcase, it's
hard to say with certainty what is valid and what is invalid. Also, without a
testcase there are
--- Comment #11 from janis at gcc dot gnu dot org 2006-10-18 16:27 ---
A regression hunt on powerpc-linux using the testcase from the submitter's
description showed that it went from an ICE to an error with this patch:
http://gcc.gnu.org/viewcvs?view=revrev=110925
r110925 |
#define SSP_X_SMALL_POOL_SIZE 10
template class ObjT, unsigned int uiInitialSize
class ObjectFactory
{
public:
virtual ~ObjectFactory();
};
class TD{
public:
typedef ObjectFactory TD, SSP_X_SMALL_POOL_SIZE Factory;
public:
friend class TD::Factory;
}
Compiling the
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #12 from geoffk at gcc dot gnu dot org 2006-10-18 17:08 ---
Isn't this a dup of bug 28834?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29436
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-18 17:08 ---
This is working as designed, -x makes all input files as that type of file.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-18 17:12 ---
The ICE is fixed in 4.0.4 for sure:
[EMAIL PROTECTED] ~]$ ~/gcc-4.0/bin/gcc t.cc
t.cc:16: error: using typedef-name TD::Factory after class
t.cc:13: error: TD::Factory has a previous declaration here
t.cc:18:
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-10-18 17:19
---
(In reply to comment #12)
Isn't this a dup of bug 28834?
Related for sure, dup unknown at this point.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
With newlib-1.13.0
TOOLDIR := /some/path/tools
HOSTARCH := $(shell uname -p)-$(shell uname -s)
TOOLARCHDIR := $(TOOLDIR)/arch/$(HOSTARCH)
# On os-x TOOLARCHDIR == /some/patch/tools/arch/powerpc-Darwin
# On linux TOOLARCHDIR == /some/patch/tools/arch/i686-Linux
# On solaris TOOLARCHDIR ==
--- Comment #4 from sje at cup dot hp dot com 2006-10-18 18:16 ---
Looking at my old logs it looks like gfortran.dg/actual_array_constructor_1.f90
has been failing on hppa64 since it first went in on April 21, 2006. Someone
is creating a TImode variable even though hppa64 doesn't
--- Comment #8 from geoffk at gcc dot gnu dot org 2006-10-18 18:41 ---
The stabs numbering should probably match whatever AIX does.
--
geoffk at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-18
18:51 ---
Subject: Re: FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
Looking at my old logs it looks like
gfortran.dg/actual_array_constructor_1.f90
has been failing on hppa64 since it first went
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-18 18:53 ---
The fix is to move the including of i386/t-crtfm down to the i?86/x86_64
generic section instead of having it in the GNU/Linux section of config.gcc.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-10-18 18:56
---
(In reply to comment #17)
A backport of the patch bootstraps regtests ok on the 4.1 branch.
Except it introduces PR 29478.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-10-18 19:03 ---
Closing as invalid then.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following program compiles in gfortran.
I don't know how easily it could be detected, but defining a scalar and using
it as an array should be detectable?
For what it is worth: ifort also does not detect this error.
Changing the integer :: j = 1 into integer :: j; j = 1 causes gfortran to
--
lmillward at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot
|dot org
--- Comment #2 from patchapp at dberlin dot org 2006-10-18 19:36 ---
Subject: Bug number PR c++/29022
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/2006-10/msg00940.html
--
--- Comment #2 from fang at csl dot cornell dot edu 2006-10-18 20:25
---
That would be PR 21498.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29503
This code:
module z
character(8), parameter :: a(1:3)=(/'nint() ', 'log10() ', 'sqrt() '/)
integer, parameter :: b(1:3) = index(a, '(')
end module z
causes
troutmask:sgk[415] gfc4x -o z z.f90
z.f90:0: internal compiler error: in gfc_conv_array_initializer, at
--- Comment #6 from sje at cup dot hp dot com 2006-10-18 20:49 ---
Well, I have tracked it back a little ways. gfc_trans_vla_type_sizes_1 calls
gfc_trans_vla_one_sizepos with:
gfc_trans_vla_one_sizepos (TYPE_SIZE (type), body);
If I print out type-type.size I see:
gdb) p
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-10-18 20:50
---
Confirmed, and Andrew will soon have a patch for this.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-18 20:52
---
(In reply to comment #6)
Since you are actively working on this, I have reassigned it to you. I hope
that's OK?
It was OK, but I spent time looking at it and looking again, and I can't figure
it out.
--- Comment #1 from kargl at gcc dot gnu dot org 2006-10-18 20:52 ---
Tobias,
The code is valid fortran in that del(j) = sin(10) is a
statement function. Putting any executable line before that line
(such as j = 1) causes an error to be emitted. If you look at the
-fdump-parse-tree
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-18 20:59
---
Fixed on 4.2, won't backport to 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-18 20:59
---
Fixed on 4.2, won't backport to 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-10-18 21:02
---
Paul, I need to be Enlightened as to why the gfc_evaluate_now statements in
your patch are needed here. If and when you have a little time, that is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29489
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de
2006-10-18 21:11 ---
Yes, you are right. I somehow missed those.
12.5.4 Statement function
A statement function is a function defined by a single statement.
R1238 stmt-function-stmt is function-name ( [
--- Comment #5 from janis at gcc dot gnu dot org 2006-10-18 21:20 ---
A regression hunt using the testcase and options from comment #2 with an
i686-linux cross compiler identified the following patch which fixed the bug on
mainline:
http://gcc.gnu.org/viewcvs?view=revrev=114293
Attached is the make output. I haven't had any luck getting a core dump --
ulimit -c 0 can't be changed, no matter what I try. Any suggestions welcome.
/eng/users/billt/gcc-4.1.1/host-powerpc-unknown-linux-gnu/gcc/gcj
-B/eng/users/billt/gcc-4.1.1/powerpc-unknown-linux-gnu/nof/libjava/
--- Comment #11 from hubicka at gcc dot gnu dot org 2006-10-18 21:54
---
Patch for non-unit-at-a-time comitted now.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-10-18 22:05
---
Yet another bug found, yet another patch. I think this one is the last:
Index: trans-intrinsic.c
===
--- trans-intrinsic.c (revision 117862)
+++
--- Comment #9 from robert dot nagy at gmail dot com 2006-10-18 22:06
---
Hi.
I'd like to backport the fix of this problem to OpenBSD because we still use
gcc 3.3 here and we are not able to compile OpenOffice w/o fixing this.
If someone can point me to the change you guys made I'd
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-10-18 22:09
---
(In reply to comment #9)
If someone can point me to the change you guys made I'd really appriciate it.
There have been too many changes to figure out what fixed this really and 3.3
is no longer being maintained
--- Comment #1 from tromey at gcc dot gnu dot org 2006-10-18 22:23 ---
... and also enum, synthetic, and annotation for Class
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2006-10-18 23:13
---
Subject: Bug 29277
Author: jvdelisle
Date: Wed Oct 18 23:13:33 2006
New Revision: 117866
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117866
Log:
2006-10-18 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-10-18 23:23
---
Fixed on 4.2.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tromey at gcc dot gnu dot org 2006-10-18 23:36 ---
Subject: Bug 28938
Author: tromey
Date: Wed Oct 18 23:36:32 2006
New Revision: 117868
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117868
Log:
PR java/28938:
* doc/install.texi
--- Comment #6 from tromey at gcc dot gnu dot org 2006-10-18 23:37 ---
Note that this isn't quite fixed yet, as we haven't documented
how to handle gcjh.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28938
--- Comment #2 from danglin at gcc dot gnu dot org 2006-10-19 01:04 ---
I'm thinking this may have been caused by the emutls patch
which was subsequently reverted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-10-19
01:56 ---
Subject: Re: FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
So I have a TImode here. How it got here, I don't yet know.
I checked that pa_scalar_mode_supported_p is called and rejects
--- Comment #6 from bergner at gcc dot gnu dot org 2006-10-19 04:05 ---
Subject: Bug 26026
Author: bergner
Date: Thu Oct 19 04:05:34 2006
New Revision: 117877
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117877
Log:
* doc/invoke.texi: Add cpu_type power6x
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-10-19 04:49
---
Eric's patch is http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01300.html
Right, but the info is already in the Patch URL field.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29494
--- Comment #10 from pault at gcc dot gnu dot org 2006-10-19 04:51 ---
Subject: Bug 29216
Author: pault
Date: Thu Oct 19 04:51:14 2006
New Revision: 117879
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117879
Log:
2006-10-19 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #2 from pault at gcc dot gnu dot org 2006-10-19 04:51 ---
Subject: Bug 29314
Author: pault
Date: Thu Oct 19 04:51:14 2006
New Revision: 117879
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=117879
Log:
2006-10-19 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #2 from acahalan at gmail dot com 2006-10-19 05:28 ---
Why is this still UNCONFIRMED, and why is it marked enhancement?
The compiler is failing to follow the documented behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29172
88 matches
Mail list logo
