--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-30
08:07 ---
Subject: Bug 23131
CVSROOT:/cvs/gcc
Module name:gcc
Branch: csl-gxxpro-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-07-30 08:06:54
Modified files:
. :
--
Bug 22416 depends on bug 22444, which changed state.
Bug 22444 Summary: [4.1 regression] testsuite
failure:23_containers/set/explicit_instantiation/2.cc ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22444
What|Old Value |New Value
--- Additional Comments From hp at gcc dot gnu dot org 2005-07-30 08:17
---
I'm reopening this PR as the failure with mmix-knuth-mmixware and
LAST_UPDATED "Fri Jul 29 18:30:36 UTC 2005" is identical to the
original description.
--
What|Removed |Added
--
Bug 22483 depends on bug 22444, which changed state.
Bug 22444 Summary: [4.1 regression] testsuite
failure:23_containers/set/explicit_instantiation/2.cc ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22444
What|Old Value |New Value
When I use -Wuninitialized without -O, gfortran says
f951: warning: -Wuninitialized is not supported without -O
This is with
GNU Fortran 95 (GCC 4.1.0 20050727 (experimental))
For debugging, I do not want optimisation, because this makes debugging more
difficult. On the other hand I d
The program below compiles cleanly with GCC 4.0.1, although the definition of
Foo::foo required by the standard (9.4.2/4) is missing.
It probably makes sense to accept such programs as a GNU extension (as long as
the address of the member is not taken).
#include
struct Foo
{
static const int
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-07-30
10:56 ---
Marked as confirmed due to Jerry's comment. Right now, building on mingw is an
awful pain (4 PR
preventing the build), and cygwin is only a bit better. So, I think work on
that point is useless until th
--- Additional Comments From falk at debian dot org 2005-07-30 13:35
---
Well, the behavior is undefined here, so what we currently do is just fine.
Moreover, this can only be detected at link time, so there's no way for us to
give a warning; at best, we could emit a fake reference and
--- Additional Comments From fw at deneb dot enyo dot de 2005-07-30 13:45
---
What about a GNU extension which would make this program well-formed? I think
it's quite a common pattern, and a requirement to provide a definition would
just increase object code size meaninglessly.
--
h
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-30
15:11 ---
-Wuninitialized is done in the back-end of GCC and not in the front-end.
And I think this was decided against so many times that there might be abother
bug about this which
has already been closed.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-30
15:13 ---
Actually the compiler is allowed to "inlined" the value of the constant. And
the missing definition does
not have to be diagnostic.
So closing as invalid.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-30
15:20 ---
This is a dup of 7710 but it is not going to be fixed because it is too hard to
do and will make
compile time way slower.
This has been discussed some many times but we are not going to do it.
*** This b
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-30
15:20 ---
*** Bug 23146 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23138
--- Additional Comments From phython at gcc dot gnu dot org 2005-07-30
15:25 ---
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg02054.html
--
What|Removed |Added
Assig
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-30
15:26 ---
3.4 produces a warning and not an error, maybe the warning became a pedwarn in
4.0.0 but this
should not produce a warning or an error at all.
For some reason the C front-end does not produce a warning or
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-30
15:39 ---
Yes it is the same issue as PR 16796.
To reproduce this before 3.4.0, you have to add __attribute__((regparam(1))).
Though the code is worse
than before 3.3.3.
--
What|Removed
--
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23100
--
What|Removed |Added
OtherBugsDependingO||22444
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22598
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-30
16:08 ---
Patches posted here:
http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01961.html
and
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00655.html
I did not read through the whole thread to figure out what happened t
--- Additional Comments From phython at gcc dot gnu dot org 2005-07-30
18:12 ---
Created an attachment (id=9388)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9388&action=view)
Patch for a bunch of vrp problems
--
What|Removed |Added
--
--- Additional Comments From phython at gcc dot gnu dot org 2005-07-30
18:13 ---
See the patch in pr23128.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot g
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-07-30 19:19
---
My newly added test transparent-union-4.c fails on ia64-hpux for the same
reason.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20094
FAIL: 102:is -:should be 1
FAIL: 258: expected branch percentages not found: 25
FAIL: g++.dg/gcov/gcov-1.C gcov: 1 failures in line counts, 1 in branch
percentages, 0 in return percentages
FAIL: 211: expected branch percentages not found: 25
FAIL: 96:is -:should be 1
FAIL: gcc.misc-tests/gcov-4.c g
On 20050728 the results in gcc.sum for gcov-4.c said:
PASS: gcc.misc-tests/gcov-4.c (test for excess errors)
PASS: gcc.misc-tests/gcov-4.c execution test
PASS: gcc.misc-tests/gcov-4.c gcov
while on 20050730 with no change to the test they said:
PASS: gcc.misc-tests/gcov-4.c (test for excess
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-07-30 19:50
---
Started passing again on ia64-hpux between 20050708 and 20050711, I don't know
about on the other platforms discussed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21831
Here is a reduced version of 20050713-1.c.
extern void abort (void);
struct S
{
int a, b, c;
};
int
foo2 (struct S x, struct S y)
{
if (x.b != 4)
abort ();
return 0;
}
int
bar2 (struct S x, struct S y)
{
return foo2 (y, x);
}
int
main (void)
{
struct S a = { 3, 4, 5 }, b = { 6, 7
The following is illegal:
$ cat print.f90
program main
character*80 line
print (line,'(A)'), 'hello'
end program main
$ cat print.f90
program main
character*80 line
print (line,'(A)'), 'hello'
end program main
$ gfortran print.f90
$ gfortran -std=f95 print.f90
$ gfortran -v
Using built-in
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-30
20:40 ---
(In reply to comment #0)
> Unlike PR 23090, which is for powerpc and only about -O2,
> this one fails with -O2 or -Os on arm-none-eabi.
You mean only about -Os.
You might want to check if this is a regress
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-30
20:45 ---
Subject: Bug 22436
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-30 20:45:03
Modified files:
libgfortran: ChangeLog
libgfortran/io : w
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-07-30
20:47 ---
Fixed on mainline. 4.0 branch does not have support for large real kinds, so no
need to apply there.
--
What|Removed |Added
---
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-07-30
20:59 ---
Thomas, I guess your patch is doing the right thing. Could you submit it to gcc-
patches so that it gets reviewed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22143
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-07-30
21:18 ---
For the bug noted in comments 5 and 6:
[dranta:~/tests/gfortran] dir% gfortran -o callabort callabort.f
[dranta:~/tests/gfortran] dir% callabort
Abort
[dranta:~/tests/gfortran] dir% cat callabort.f
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-30
21:46 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-30
22:29 ---
Subject: Bug 20436
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-30 22:29:25
Modified files:
gcc/testsuite : Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-30
22:29 ---
Subject: Bug 20074
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-30 22:29:25
Modified files:
gcc/testsuite : Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-30
22:29 ---
Subject: Bug 21108
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-07-30 22:29:25
Modified files:
gcc/testsuite : Change
The following should be illegal:
$ cat namelist-1.f90
program main
integer, dimension(2) :: i
i = 2
call foo(i)
contains
subroutine foo(i)
integer :: i(:)
namelist /bar/ i
write (*,bar)
end subroutine foo
end program main
$ gfortran namelist-1.f90
$ gfortran -v
Using built-in
Compiling xterm-202 on i686-pc-linux-gnu shows that 4.1 generates bigger code
than 4.0.
This happens for all combinations of {-march=i386 and -march=i686} and
{-O2 and -Os}.
size -f 4.*/xterm
textdata bss dec hex filename
175215 217246684 203623 31b67 4.0-O2-i386/xt
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-30
23:13 ---
This could be many things, first we don't care about code size for -O2.
Second this is most likely jump threading.
Can you add -ftree-dominator-opts and see what the code size problems are?
--
http://g
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
00:11 ---
Hmm, we leak all the BLOCKs created by the tree-inline:
tree-inline.c:421 (remap_block) 0: 0.0% 0:
0.0%3166956:74.8% 0: 0.0%
60903
tree-inline.c:2027 (e
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
00:26 ---
I was wrong in comment #1 for saying this was caused by the early inliner.
This was caused by: "Copy debug info properly in the inliner":
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02022.html
What is happ
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
00:43 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
00:46 ---
Confirmed.
--
What|Removed |Added
CC||hubicka at
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-07-31 00:56 ---
This may be the problem:
In mk-kinds-h.sh:
case $largest_ctype in
float) echo "#define GFC_REAL_LARGEST_FORMAT \"\"" ;;
double) echo "#define GFC_REAL_LARGEST_FORMAT \"l\"" ;;
"long doub
The following test case results in a floating point read error.
DOUBLE PRECISION XIN, YIN, ZIN, WIN, QIN
CHARACTER*4 SID, RID, RID2, REN, IUP
CHARACTER*5 A
CHARACTER*132 COMLYN
COMLYN = "abcd efgh jklmn 1.2345.678 21.765 2.34
& 3.45xx
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
02:24 ---
If I turn off copy prop, this passes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
02:35 ---
Fixed in 4.0.0.
--
What|Removed |Added
Status|NEW |RESOL
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
02:38 ---
Confirmed.
--
What|Removed |Added
URL||http://gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
02:43 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
03:44 ---
Has this been fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21984
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
03:47 ---
-fno-tree-copy-prop "fixes" the problem.
--
What|Removed |Added
CC|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
03:48 ---
This is a dup of bug 23048.
*** This bug has been marked as a duplicate of 23048 ***
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
03:48 ---
*** Bug 22122 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
03:49 ---
Testcase from PR 22122:
void f(unsigned char *mem)
{
int i;
for(i=0;i<4;i++) {
while(mem[i]==0) ;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23048
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
04:04 ---
I am no longer going to work on this.
--
What|Removed |Added
AssignedTo|pinskia at g
--
What|Removed |Added
Status|WAITING |NEW
Last reconfirmed|2005-06-27 21:59:14 |2005-07-31 04:06:12
date|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
04:14 ---
no Feedback in 3 months.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
04:14 ---
I am going on a limb here and say this is fixed.
--
What|Removed |Added
Status|W
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
04:16 ---
I cannot reproduce this and this works for everyone else.
--
What|Removed |Added
I am not sure that the example is valid GCC-extended C, but GCC definitely
should not ICE with "gimplification failed". The example is:
typedef short __attribute__((vector_size (16))) v8hi;
union vx {short f[8]; v8hi v;};
extern void bar1(v8hi);
void
foo5 (v8hi vec, short n)
{
((union vx) vec
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
04:21 ---
The front-end produces:
{.v=vec}.f[5] = n;
--
What|Removed |Added
Status|UNCO
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-31 04:21
---
Sorry, there was a typo in the previous example. The correct example is:
typedef short __attribute__((vector_size (16))) v8hi;
union vx {short f[8]; v8hi v;};
extern void bar1(v8hi);
void
foo5 (v8hi vec, sho
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
04:23 ---
Here is another testcase:
union vx {short f[8]; int v;};
int vec;
void
foo5 (int vec)
{
((union vx) vec).f[5] = 1;
}
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
04:25 ---
If we give -pedantic-errors we reject it with an error but still ICE.
--
What|Removed |Added
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-31 04:25
---
I tried overriding libstdc++'s definition of __GXX_WEAK__ and GCC's definition
of ONE_ONLY. Both caused additional C++ testsuite failures. AIX does support
weak, but not exactly the way that G++ is expecting.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
04:42 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
04:58 ---
This is a dup of bug 22139. The reason for the errors in 4.0.1 and above:
class a
{
friend class b;
b f(void);
};
is invalid code.
*** This bug has been marked as a duplicate of 22139 ***
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
04:58 ---
*** Bug 19776 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:17 ---
Hmm, on powerpc-darwin on the mainline, we spike up to 900MB for some reason
and then drop back
down to 400MB.
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:36 ---
The memory is not in GC at all. I don't which pass is allocating the memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15414
typedef int A;
struct foo{
A A;
};
compiles in 3.4.0 and on Comeau, but on 3.4.2 you get:
changedMeaning.cc:3: error: declaration of `A foo::A'
changedMeaning.cc:1: error: changes meaning of `A' from `typedef int A'
So who's right, you or EDG?
Ivan
--
Summary: Fails valid? (valid
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:39 ---
GCC is. See PR 17353 and [basic.scope.class] of the standard.
*** This bug has been marked as a duplicate of 17353 ***
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:39 ---
*** Bug 23156 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:40 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:40 ---
Mark as a dup of bug 17353.
*** This bug has been marked as a duplicate of 17353 ***
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:40 ---
*** Bug 17644 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:41 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:41 ---
As a dup of bug 17353.
*** This bug has been marked as a duplicate of 17353 ***
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:41 ---
*** Bug 17605 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:42 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:42 ---
Mark as a dup of bug 17353.
*** This bug has been marked as a duplicate of 17353 ***
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
05:42 ---
*** Bug 18320 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17353
--- Additional Comments From phython at gcc dot gnu dot org 2005-07-31
05:45 ---
I would really prefer option b, where we keep VRP information persistant. That
way fold can use VRP information when available.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
--- Additional Comments From jvdelisle at gcc dot gnu dot org 2005-07-31
05:52 ---
I have instrumented a few places in transfer.c. In particular looking at the
string at 'q' in sf_read. The original string is corrupted before getting to
the first read.
--
http://gcc.gnu.org/bugzill
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-31
06:07 ---
Fixed on the mainline by moving over to the tree based profiling.
--
What|Removed |Added
--- Additional Comments From jvdelisle at gcc dot gnu dot org 2005-07-31
06:15 ---
Created an attachment (id=9389)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9389&action=view)
Revised test case to honor 72 column magic
The revised test case here, remembering not to exceed 72 co
--- Additional Comments From jvdelisle at gcc dot gnu dot org 2005-07-31
06:47 ---
Reference information on this thread:
http://gcc.gnu.org/ml/fortran/2005-07/msg00495.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23154
88 matches
Mail list logo
