--- Comment #1 from schwab at suse dot de 2007-02-24 08:21 ---
This is how C++ works, see [dcl.type.elab]/3.
--
schwab at suse dot de changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-02-24 08:27 ---
(In reply to comment #1)
This crash is with g77, which is no longer support.
To elaborate more: The GCC 4.x series comes with the compiler gfortran which
can compile Fortran 77/90/95 (and some Fortran 2003)
--- Comment #2 from ubizjak at gmail dot com 2007-02-24 08:53 ---
The problem here is in ix86_expand_set_or_movmem_via_loop().
In mtune=k8 case, we choose unrolled_loop as the algorithm, where main loop is
expanded as
expand_set_or_movmem_via_loop (dst, NULL, destreg, NULL,
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-24 08:53 ---
Could you attach the preprocessed source code which you can get by adding
-save-temps and it will be named something.ii. Also can you provide the full
output of gcc -v ?
This was all mentioned on
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-02-24 09:12
---
Hmm, on PPC, changing wait to take long long instead of int, still makes the
inline case a little shorter (8 bytes/2 instructions). Though that is just not
fully true.
If I change main to be:
for (;f();)
--- Comment #17 from pinskia at gcc dot gnu dot org 2007-02-24 09:14
---
Though I can tell you for spu-elf, really even WORD_SIZE is 128bits, the
arthematic is more than twice the cost of a 4 byte arthematic.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
I guess that nearly all range checks are eliminated and without bootstrapping
we have a disconnect between the redundant checks in the rts and the
testcases. If it happens that the non-bootstrapped rts is built by the
host compiler(?).
No, that never happens. The rts is always built with the
--- Comment #33 from charlet at adacore dot com 2007-02-24 10:12 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
I guess that nearly all range checks are eliminated and without bootstrapping
we have a disconnect between the redundant checks in the rts and the
--- Comment #2 from pcarlini at suse dot de 2007-02-24 10:15 ---
Let's consider this simply a duplicate of 28080. I'm improving the situation a
bit, but don't expect miracles ;)
*** This bug has been marked as a duplicate of 28080 ***
--
pcarlini at suse dot de changed:
--- Comment #15 from pcarlini at suse dot de 2007-02-24 10:15 ---
*** Bug 30945 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2007-02-24 10:59 ---
I'm currently testing this patch:
2007-02-24 Uros Bizjak [EMAIL PROTECTED]
* config/i386/i386.md (expand_set_or_movmem_via_loop): Return if
GET_MODE_SIZE (mode) * unroll is less than expected_size.
we have a disconnect between the redundant checks in the rts and the
testcases. If it happens that the non-bootstrapped rts is built by the
host compiler(?).
No, that never happens. The rts is always built with the latest (stage3)
compiler. Otherwise it would not even begin to work fro
--- Comment #34 from charlet at adacore dot com 2007-02-24 12:32 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
we have a disconnect between the redundant checks in the rts and the
testcases. If it happens that the non-bootstrapped rts is built by the
host
--- Comment #35 from rguenth at gcc dot gnu dot org 2007-02-24 12:38
---
I was talking about the rts that get's used if I configure with
--disable-bootstrap, do a make and then run make check-ada from within the
gcc/ subdirectory. As far as I understand that rts seems to be built
I was talking about the rts that get's used if I configure with
--disable-bootstrap, do a make and then run make check-ada from within the
gcc/ subdirectory. As far as I understand that rts seems to be built using
the bootstrap compiler. At least this would explain the difference in the
--- Comment #36 from charlet at adacore dot com 2007-02-24 12:47 ---
Subject: Re: VRP fails to eliminate range checks in Ada code
I was talking about the rts that get's used if I configure with
--disable-bootstrap, do a make and then run make check-ada from within the
gcc/
--- Comment #4 from sayle at gcc dot gnu dot org 2007-02-24 15:10 ---
Subject: Bug 30400
Author: sayle
Date: Sat Feb 24 15:09:50 2007
New Revision: 122289
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122289
Log:
2007-02-24 Roger Sayle [EMAIL PROTECTED]
Paul Thomas
--- Comment #8 from bonzini at gnu dot org 2007-02-24 16:07 ---
Subject: Bug 30904
Author: bonzini
Date: Sat Feb 24 16:07:41 2007
New Revision: 122290
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122290
Log:
2007-02-23 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #2 from tdepuy at gmail dot com 2007-02-24 18:24 ---
Actually, I found that I couldn't compile anything with gcc or g++. Even the
codes I was compiling yesterday! Sheesh. So, I restarted. Everything is fine
now in the garden of squirrel. Please close/delete this bug as
$ cat alarm.f90
program test_alarm
integer(kind=1) :: sec = 1
integer(kind=1) :: h= 0
integer(kind=1) :: stat = -1
CALL alarm(sec, h, stat)
if (stat == -1) call abort()
end program
$ gfortran-svn -fdump-tree-original alarm.f90
$ cat alarm.f90.003t.original
MAIN__ ()
{
static
subroutine = {
name = 'chdir';
arg = 'path';
arg = 'status';
call = 'CALL chdir(path = string)';
call = 'CALL chdir(path = string, status = int_1)';
call = 'CALL chdir(path = string, status = int_2)';
call = 'CALL chdir(path = string,
I passed a pointer of the wrong type to a function. I received a warning about
this. This warning contained only little information; it only said that the
pointer types differ. It did not specify what type was passed, nor what type
was expected, nor where the declaration of the called function
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-02-24 18:53 ---
4.1.2 20060928
It should noted that you are using a prerelease of 4.1.2.
Anyways closing as works for me as requested by the reporter.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-02-24 18:55 ---
4. The chdir()-function is implemented but not documented
$ cat chdir.f90
integer :: s
s = chdir(/tmp)
end
$ gfortran-svn -Wall chdir.f90 echo ok
ok
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
subroutine = {
name = 'cpu_time';
arg = 'x';
call = 'CALL cpu_time(x = real_4)';
call = 'CALL cpu_time(x = real_8)';
};
1. The name of the dummy argument is TIME instead of X as documented.
--
Summary: intrinsic: CPU_TIME
Product: gcc
--- Comment #5 from ubizjak at gmail dot com 2007-02-24 19:09 ---
(In reply to comment #2)
I have verified that revision 119252:
http://gcc.gnu.org/ml/gcc-cvs/2006-11/msg00907.html
breaks -mtune=nocona. Jan, can you take a look? Thanks.
Something is still wrong with unrolled_loop
--- Comment #4 from dje at gcc dot gnu dot org 2007-02-24 19:11 ---
I see a similar error in the libstdc++ testsuite on AIX:
/tmp/20070223/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/ext/pb_ds/detail/list_update_map_/insert_fn_imps.hpp:
In member function 'typename
int foo (int x)
{
return x + 5 == x;
}
(mine)
--
Summary: Does not fold x + CST == x and x + CST != x
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-02-24 19:55 ---
Subject: Bug 30951
Author: rguenth
Date: Sat Feb 24 19:55:47 2007
New Revision: 122295
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122295
Log:
2007-02-24 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-02-24 19:56 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from tkoenig at gcc dot gnu dot org 2007-02-24 21:48 ---
(In reply to comment #7)
Paul, I tried to apply your patch, but it is rejected.
I applied the patch with a recent trunk, which worked (except
I got a message that the patch file contained CR/LF).
I'm running a
When I call a function via a function pointer, then the error message does not
specify which argument contains an error. Consider the code
typedef void (* subptr) (int * x, void ** y);
void call (subptr sub, int a, int * b)
{
(* sub) (a, b);
}
when compiled, then I receive the errors
$
subroutine = {
name = 'ctime';
arg = 'time';
arg = 'result';
call = 'CALL ctime(time = int_8, result = string)';
};
The documentation states:
Arguments:
S The type shall be of type CHARACTER.
T The type shall be of type INTEGER(KIND=8).
But the
--- Comment #6 from ubizjak at gmail dot com 2007-02-24 22:54 ---
It was a typo in expand_movmem_epilogue() and expand_setmem_epilogue().
Following patch, fixes this bug and together with patch for PR target/30778
(http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01937.html) enables
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
--- Comment #6 from hubicka at gcc dot gnu dot org 2007-02-24 22:58 ---
I am testing a fix:
Index: tree-inline.c
===
*** tree-inline.c (revision 122292)
--- tree-inline.c (working copy)
*** copy_bb
--- Comment #4 from hubicka at gcc dot gnu dot org 2007-02-24 23:09 ---
Hi,
testing for expected_size is wrong here - with profile feedback, expected_size
is average size of the block and thus can be smaller than actual size of the
block being copied.
In general we should in this case
--- Comment #5 from ubizjak at gmail dot com 2007-02-24 23:24 ---
(In reply to comment #4)
Hi,
testing for expected_size is wrong here - with profile feedback, expected_size
is average size of the block and thus can be smaller than actual size of the
block being copied.
In general
DATE_AND_TIME has four optional arguments, thus
CALL date_and_time()
is valid.
As all arguments are INTENT(out),
_gfortran_date_and_time (0B, 0B, 0B, 0B, 0, 0, 0);
is sort of a no-op and can be omitted.
--
Summary: intrinsic: DATE_AND_TIME
Product: gcc
--- Comment #7 from uros at gcc dot gnu dot org 2007-02-24 23:29 ---
Subject: Bug 30770
Author: uros
Date: Sat Feb 24 23:29:30 2007
New Revision: 122301
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122301
Log:
PR target/30770
* config/i386/i386.md
--- Comment #6 from hubicka at gcc dot gnu dot org 2007-02-24 23:47 ---
Hi,
this is version I ended up with. In general I don't think that code should
handle with such a small constant sizes, we probably should bump move_by_pieces
constants since it can do better job using proper moves
subroutine = {
name = 'fget';
arg = 'count';
arg = 'status'; /* optional */
call = 'CALL fget(count = char)';
call = 'CALL fget(count = char, status = int_1)';
call = 'CALL fget(count = char, status = int_2)';
call =
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-02-25 00:28
---
Found it. Patch on the way.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
When compiling fribidi-0.10.7 the compiler fails here:
gcc -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -Wall -pedantic -fno-strict-aliasing -MT
fribidi_utils.lo -MD -MP -MF .deps/fribidi_utils.Tpo -c fribidi_utils.c -o
fribidi_utils.o
fribidi_utils.c: In function 'fribidi_map_range':
fribidi_utils.c:108:
--- Comment #1 from sherpya at netfarm dot it 2007-02-25 02:26 ---
Detailed output:
gcc -v -save-temps -DHAVE_CONFIG_H -I. -I. -I. -g -O2 -Wall -pedantic
-fno-strict-aliasing -MT fribidi_utils.lo -MD -MP -MF .deps/fribidi_utils.Tpo
-c fribidi_utils.c -o fribidi_utils.o
Using built-in
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-02-25 02:27
---
Subject: Bug 30918
Author: jvdelisle
Date: Sun Feb 25 02:27:17 2007
New Revision: 122307
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122307
Log:
2007-02-24 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-02-25 02:30
---
Subject: Bug 30918
Author: jvdelisle
Date: Sun Feb 25 02:30:14 2007
New Revision: 122308
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122308
Log:
2007-02-24 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #2 from sherpya at netfarm dot it 2007-02-25 02:33 ---
Created an attachment (id=13104)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13104action=view)
source .s and .i
the full source of program can be found here:
http://fribidi.org/download/fribidi-0.10.7.tar.gz
--
--- Comment #9 from patchapp at dberlin dot org 2007-02-25 02:46 ---
Subject: Bug number PR 30865
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-02/msg01956.html
--
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-02-25 03:39
---
Subject: Bug 30918
Author: jvdelisle
Date: Sun Feb 25 03:39:19 2007
New Revision: 122309
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122309
Log:
2007-02-24 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #3 from dannysmith at users dot sourceforge dot net 2007-02-25
03:39 ---
On trunk and 4.2.0 (target i686-pc-mingw32), invalid code is diagnosed
correctly:
fribidi_utils.c: In function 'fribidi_map_range':
fribidi_utils.c:72: error: 'fribidi_map_range': definition is
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-02-25 03:52
---
Subject: Bug 30918
Author: jvdelisle
Date: Sun Feb 25 03:52:11 2007
New Revision: 122310
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122310
Log:
2007-02-24 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-02-25 04:00
---
Fixed on 4.3, 4.2, and 4.1
Thanaks Herald for report. Please let me know if you have any other troubles.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from bdavis at gcc dot gnu dot org 2007-02-25 04:42 ---
the below patch looks like it fixes the problem. any chance this could be
tryed on the reported problem ?
--bud
Index: gcc/gcc/fortran/module.c
===
--- Comment #7 from ubizjak at gmail dot com 2007-02-25 07:54 ---
(In reply to comment #6)
This patch however fixes one extra pasto and makes the prologue test
unconditional - I was a bit overagressive minimizing amount of RTL produced
that only leads to bugs in side corners.
This
55 matches
Mail list logo
