--- 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) progr
--- 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, promo
--- 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 http://gcc.gnu.o
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-02-24 09:00 ---
Really this is nothing to do with header files really.
I think the FAQ is wrong with respect to the C++98 standard as he forgets there
are locale supported added which brings in a lot.
Also including iostream, for
--- Comment #5 from mtrudel at gmx dot ch 2007-02-24 09:04 ---
The problem is that the new SJLJ backtrace algorithm depends on the typical
function entry sequence "pushl %ebp; movl %esp, %ebp". But while they're always
in our compiled Java code, they are mostly optimized away in JNI libs
--- 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
--- 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
> tes
--- 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.
t
> > 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 w
--- 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
> > hos
--- 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 using
> 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/ subdir
--- 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=gcc&view=rev&rev=122289
Log:
2007-02-24 Roger Sayle <[EMAIL PROTECTED]>
Paul Tho
--- 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=gcc&view=rev&rev=122290
Log:
2007-02-23 Paolo Bonzini <[EMAIL PROTECTED]>
PR tree-optim
--- 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 necess
$> 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 i
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, statu
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 i
--- 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_lo
--- 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 pb_ds::detail::lu_map
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=gcc&view=rev&rev=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
Status|UNCONFIRM
--- 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 r
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
$ ~/gcc
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 imp
--- 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 bootstra
--
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 (c
--- 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 en
--- 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 gene
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
Ve
--- 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=gcc&view=rev&rev=122301
Log:
PR target/30770
* config/i386/i386.md (expand_movme
--- 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 = '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: in
--- 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 sp
--- 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=gcc&view=rev&rev=122307
Log:
2007-02-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- 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=gcc&view=rev&rev=122308
Log:
2007-02-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- 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=13104&action=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
--
http://gcc.gnu.org/bugzilla/s
--- 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=gcc&view=rev&rev=122309
Log:
2007-02-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- 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 marked
--- 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=gcc&view=rev&rev=122310
Log:
2007-02-24 Jerry DeLisle <[EMAIL PROTECTED]>
--- 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.
Thi
57 matches
Mail list logo
