--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21
17:31 ---
m68k is not a primary or secondary target; removing target milestone.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21
17:31 ---
m32r is not a primary or secondary target; removing target milestone.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21
17:32 ---
ns32k is not a primary or secondary platform; removing target milestone.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21
17:32 ---
AVR is not a primary or secondary platform; removing target milestone.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21
17:33 ---
SH is not a primary or secondary platform; removing target milestone.
--
What|Removed |Added
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-21 17:38
---
Digging further, there *is* a __eprintf reference in
/tmp/hptmp/obj/sparc-sun-solaris2.8/libstdc++-v3/src/.libs/libstdc++.so,
the one supposedly complained about when building the test-application.
Now, how did
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-21 17:41
---
To clarify, comment #16 should read No: GNU ld is actually used:
that is, an affirmation that GNU ld is used, contrary to comment #15.
(It could be read as the negation, and we have enough confusion.
I'm not
gfortran formatted read incorrectly reads beyond end of record when
record length is io,format length.
Demo:
[EMAIL PROTECTED]:~/source/test cat ftest.f95
program ftest
integer i
character*1 b(10)
open (77, file='input_file')
read (77, '(10A1)') b
print *, b
end program ftest
[EMAIL
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-21
17:45 ---
There are no 8-bit or 16-bit targets in the primary or secondary platform lists;
removing target milestone.
--
What|Removed |Added
--- Additional Comments From ncm-nospam at cantrip dot org 2005-01-21
17:45 ---
Do I understand correctly that the FE fix has been applied? I don't
see any corresponding __attribute__ in HEAD for basic_string.h.
Probably _Rep should be aligned not to a constant size, but rather to
the
--- Additional Comments From pcarlini at suse dot de 2005-01-21 17:53
---
Do I understand correctly that the FE fix has been applied? I don't
see any corresponding __attribute__ in HEAD for basic_string.h.
No, largely __attribute__(aligned) is still broken, doesn't work with
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-21
17:54 ---
Subject: Bug 576
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-21 17:54:27
Modified files:
gcc: ChangeLog real.c real.h fold-const.c
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org |
Status|NEW
It appears that explicit instantiation of specialized template classes isn't
instantiating all of the class's members as it should:
--- Begin Sample Code
template typename T
class A
{
public:
void foo( T const ) {}
};
template
class Achar
{
public:
void foo( char const )
The -O2 optimization moves code outside of loop causing function call to
be done after the data structure was unlocked. The code was actually moved
to after the second usage of the variable assigned the return value of the
indirect function call. The problem does not occur when the optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
18:47 ---
Removing the target milestone as per
http://gcc.gnu.org/ml/gcc/2005-01/msg01255.html as this
is only known to happen in Ada.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
18:48 ---
Removing the target milestone as per
http://gcc.gnu.org/ml/gcc/2005-01/msg01255.html as this
is only known to happen in Ada.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
18:48 ---
Removing the target milestone as per
http://gcc.gnu.org/ml/gcc/2005-01/msg01255.html as this
is only known to happen in Ada.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
18:48 ---
Removing the target milestone as per
http://gcc.gnu.org/ml/gcc/2005-01/msg01255.html as this
is only known to happen in Ada.
--
What|Removed |Added
--- Additional Comments From andres_takach at mentorg dot com 2005-01-21
18:58 ---
Subject: Re: Compile error on template member function called
from template function
Thanks for the workaround and for the fast response!
Looking at the standard this is what I see:
- mc_fooW3 is a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
19:04 ---
Can you attach the preprocessed version of the source below?
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-21
19:05 ---
Subject: Bug 13000
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-21 19:05:25
Modified files:
gcc: ChangeLog tree-inline.c tree-cfg.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-21
19:06 ---
Subject: Bug 13000
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-21 19:05:54
Modified files:
gcc/testsuite : ChangeLog
--- Additional Comments From ian at airs dot com 2005-01-21 19:07 ---
Fixed on mainline.
--
What|Removed |Added
Known to fail|4.0.0 3.4.0 |3.4.0
--- Additional Comments From ian at airs dot com 2005-01-21 19:14 ---
Note that if we do move to a better solution, i.e., building a CFG for inline
functions, we should remove the patch to c_finish_bc_stmt in c-typeck.c. It
prevents -Wunreachable from ever warning about an unreachable
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-01-21
19:19 ---
I just tired this on struct-aliasing, to come up iwth a dom fix, and it
load-store moved everything, so there was nothing left for ivopts to create
ivtmps of :)
I think that's good.
I'll have to go try my
pcarlini at suse dot de wrote:
--- Additional Comments From pcarlini at suse dot de 2005-01-20 12:10
---
A first implementation of the algorithm was already in 3_4, under the name
expand_cmplxdiv_wide (in optabs.cc), then Rth rewrote it in the tree-ssa branch
as part of the new
--- Additional Comments From toon at moene dot indiv dot nluug dot nl
2005-01-21 20:23 ---
Subject: Re: Naive (default) complex division algorithm
pcarlini at suse dot de wrote:
--- Additional Comments From pcarlini at suse dot de 2005-01-20 12:10
---
A first
--
What|Removed |Added
GCC host triplet|i486-linux |
Known to fail||3.0.4 3.2.3 3.3.6 3.4.4
|
--- Additional Comments From andreev at comm dot mot dot com 2005-01-21
20:37 ---
Andrew, any comments?..
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19492
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
20:45 ---
(In reply to comment #3)
Subject: Re: Compile error on template member function called
from template function
- Section 14.6.2 (last two sentences in paragraph 1) says:
If an operand of an
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
21:05 ---
(In reply to comment #11)
This actually looks like a duplicate of PR19038 now.
Actually it is not, the problem is related not doing loop copy header for -Os.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
21:29 ---
Removing target milestone per:
http://gcc.gnu.org/ml/gcc/2005-01/msg01255.html. This does
not effect any of the primary or secondary targets.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
21:30 ---
Removing target milestone per:
http://gcc.gnu.org/ml/gcc/2005-01/msg01255.html. This does
not effect any of the primary or secondary targets.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
21:30 ---
Removing target milestone per:
http://gcc.gnu.org/ml/gcc/2005-01/msg01255.html. This does
not effect any of the primary or secondary targets.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
21:31 ---
Removing target milestone per:
http://gcc.gnu.org/ml/gcc/2005-01/msg01255.html. This does
not effect any of the primary or secondary targets.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21
21:37 ---
Jakub you are a life saver some times. Thanks for looking into this.
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01529.html.
--
What|Removed |Added
--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-21 21:57
---
This only happens for parameters.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19543
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-21 22:03
---
I've found the problem, via binary search on the povray source and then
visual inspection of the file found to be miscompiled. The mov[sd]fcc_1_sse
patterns are missing an earlyclobber. The fix isn't quite
--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-21 22:21
---
Ugh. This is ugly.
When building the I/O statement, we create a temporary because the argument is
passed by reference (why?). The type of the temporary is determined as
TREE_TYPE(se-expr), where se-expr is
--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-21 22:37
---
Weird, the build hadn't picked up my patch, which had led me to do the analysis
given above.
Patch: http://gcc.gnu.org/ml/fortran/2005-01/msg00239.html
--
What|Removed
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dje at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-21 22:58
---
Unfortunately, this patch is not sufficient to fix this issue, as the logical
constants are not dealt with correctly by the middle-end.
The following testcase shouldn't abort:
program test
implicit none
--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-21 23:32
---
Forgot to say this: an obvious fix would be not setting the type precision to 1
bit, but to the full width of the type. This would of course somewhat defeat
the purpose of giving logicals a type of their own.
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-01-21
23:46 ---
This isn't a regression, fold could never do that.
--
What|Removed |Added
The code generator for the ARM target does not preserve register f5 (and
possibly other floating point registers) when they are clobbered by a function.
Thus, if function uses those registers and calls another function which uses
them too, the caller behaves weirdly.
The bug has been found in GCC
--- Additional Comments From jack at cs dot york dot ac dot uk 2005-01-21
23:47 ---
Created an attachment (id=8036)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8036action=view)
Test case which demonstrates the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19571
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-21
23:53 ---
Subject: Bug 19510
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_3-branch
Changes by: [EMAIL PROTECTED] 2005-01-21 23:52:49
Modified files:
libstdc++-v3 :
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-01-21
23:54 ---
Fixed in gcc 3.3.6, 3.4.4, and mainline.
--
What|Removed |Added
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19571
I'm compiling the Chipmunk electronic design/simulation tools (psys 1.58) and
the default makefile gets an ICE in compiling math.c. The default Makefile
specifies -O3, but the ICE does not happen if I use no optimization or just -O.
-O2 also gets the same ICE. Here is the compilation line and
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19572
--- Additional Comments From bugs at chen-becker dot org 2005-01-22 00:02
---
Created an attachment (id=8037)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8037action=view)
The preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19572
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-22
00:13 ---
Subject: Bug 18809
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-22 00:12:28
Modified files:
gcc: ChangeLog c-typeck.c
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-01-22
00:14 ---
Fixed in mainline.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22
00:16 ---
No feed back in 3 months (T-2 days).
--
What|Removed |Added
Status|WAITING
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22
00:17 ---
$ cat namel.inp
foo
a= 2.30,/
$ cat namel-tst.f90
program sechs_w
implicit none
integer, parameter :: dr=selected_real_kind(15)
integer, parameter :: nkmax=6
real(kind=dr) :: rb(nkmax)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-22
00:30 ---
Subject: Bug 19543
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-22 00:29:36
Modified files:
gcc/fortran: ChangeLog trans-const.c
Log
--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-22 00:36
---
The first four can be fixed by slightly reordering the contents of the functions
they're in. I'm not proposing a patch, because I'm not completely sure why that
code is needed, and I'm too tired to look into
--- Additional Comments From tobi at gcc dot gnu dot org 2005-01-22 00:52
---
Patch which implements the obvious workaround mentioned above:
http://gcc.gnu.org/ml/fortran/2005-01/msg00242.html
This doesn't fix the backend issue, so no patch keyword.
--
--- Additional Comments From schlie at comcast dot net 2005-01-22 00:53
---
just for reference, as didn't notice this pr eariler:
http://gcc.gnu.org/ml/gcc/2005-01/msg01270.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19566
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-01-22 01:32 ---
A new path is available.
http://gcc.gnu.org/ml/fortran/2005-01/msg00243.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17941
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-22
02:26 ---
Subject: Bug 19548
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-22 02:26:13
Modified files:
gcc: ChangeLog
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-22
03:04 ---
Subject: Bug 19548
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-01-22 03:04:19
Modified files:
gcc:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-22
03:09 ---
Subject: Bug 19491
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-22 03:09:31
Modified files:
gcc: ChangeLog
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-22
03:13 ---
Patch shown in comment #3 commited to gcc-trunk and gcc-3_4-branch.
--
What|Removed |Added
--- Additional Comments From dje at gcc dot gnu dot org 2005-01-22 03:24
---
Patch committed.
This is not a regression, so it will not be fixed on earlier branches.
--
What|Removed |Added
--- Additional Comments From gnu_andrew at member dot fsf dot org
2005-01-22 03:29 ---
In current Classpath CVS head, parsing of this string is now successful. The
output of the given test case is:
$ java TestParse
Result: Wed Jun 04 03:09:35 2003
Fail
Fail is printed because the
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-22
03:51 ---
Subject: Bug 19314
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-22 03:51:13
Modified files:
gcc/testsuite : ChangeLog
libgfortran:
With LAST_UPDATED: Fri Jan 21 21:01:24 UTC 2005 I get:
FAIL: g++.old-deja/g++.robertl/eb132.C (test for excess errors)
FAIL: g++.old-deja/g++.robertl/eb73.C (test for excess errors)
With the message in the g++.log being:
Executing on host: /home/hp/combined/mmixware-sim/gcc/testsuite/../g++
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|fortran |libfortran
Ever Confirmed|
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-01-22
06:19 ---
The problem is in the main program
type(objA),target :: oa
type(objB),target :: ob
call new(oa,1)
call new(ob,oa,2)
call print(ob)
call print(getOa(ob)) !here
end program test
This
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22
06:59 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22
07:01 ---
I thought I saw that this also happens on i686-pc-linux-gnu but I could wrong.
http://gcc.gnu.org/ml/gcc-regression/2005-01/msg00071.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-22
07:07 ---
As I said this is generic regressions and not related to mmix at all.
--
What|Removed |Added
--
What|Removed |Added
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19548
101 - 177 of 177 matches
Mail list logo
