[Bug c++/30946] classes and structs are interchangeable?
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30946
[Bug fortran/30943] Compiler Crash while compiling GNU Octave
--- 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) programs. It should also be available under Ubuntu (as you have gcc 4.0.3). However, the GCC/gfortran 4.0.x version is a bit buggy thus you should therefore better install gfortran 4.1 (or 4.2.x or 4.3.x). gfortran binaries are available from: http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30943
[Bug target/30778] [4.3 Regression] invalid code generation for memset() with -mtune=k8
--- 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, promoted_val, count_exp, Pmode, 4, expected_size); However, the value of "expected_size" equals 31 in the above testcase! This is smaller that the smallest chunk size (SIZEOF (Pmode) * 4), requested by caller. For some reason, expand_set_or_movmem_via_loop() doesn't detect this anomaly and generates loop for requested chunk size. The fix is obvious and straightforward. Bail out of expand_set_or_movmem_via_loop() early if expected_size < piece_size. I'll fix this in the evening (CET) if Jan won't beat me to it ;) , where some kind of guard is missing before entering "Main loop" section. -- ubizjak at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30778
[Bug c++/30944] cstddef:54: internal compiler error: Segmentation fault
--- 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.org/bugs.html which comes out when an internal compiler error happens. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30944
[Bug c++/30945] iostream includes excessive headers - results in large files
--- 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, forces the initialization of the C++ standard streams. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30945
[Bug libgcj/29477] [SJLJ EH] JNI broken with certain libs
--- 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. Microsoft Visual C++ mostly removes them in optimization mode -Og (and -Ox which includes -Og), GCC seems to sometimes remove them in -O2 -O3 and -Os mode. I think -fno-omit-frame-pointer keeps them for GCC, but I didn't test it. I think this won't be fixed and we just wait until DWARF EH is finally available for mingw. Should be soon since it already exists but has not yet been approved/committed. -- mtrudel at gmx dot ch changed: What|Removed |Added Summary|[MinGW] JNI broken with |[SJLJ EH] JNI broken with |certain libs|certain libs http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29477
[Bug middle-end/30908] -Os inlines functions that are called more than once (optimization regression)
--- 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();) {
x = 1;
wait(100);
x = 0;
wait(100);
}
Which does not have an infinite loop, the non inline case is one instruction (4
bytes) less so really the cost of > WORD_SIZE should be about twice as much for
the arthimenatic.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-02-24 09:12:20
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
[Bug middle-end/30908] tree cost for types which are > WORD_SIZE
--- 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 |Added Summary|-Os inlines functions that |tree cost for types which |are called more than once |are > WORD_SIZE |(optimization regression) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30908
Re: [Bug tree-optimization/30911] 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 > 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 cross compilers. Arno
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- 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 > 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 cross compilers. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug libstdc++/30945] iostream includes excessive headers - results in large files
--- 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: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30945
[Bug libstdc++/28080] header dependencies
--- 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 CC||rosenwad at bxscience dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28080
[Bug target/30778] [4.3 Regression] invalid code generation for memset() with -mtune=k8
--- 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.
testsuite/ChangeLog:
2007-02-24 Uros Bizjak <[EMAIL PROTECTED]>
* gcc.target/i386/pr30778.c: New test.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 122286)
+++ config/i386/i386.c (working copy)
@@ -13315,13 +13315,19 @@
{
rtx out_label, top_label, iter, tmp;
enum machine_mode iter_mode;
- rtx piece_size = GEN_INT (GET_MODE_SIZE (mode) * unroll);
- rtx piece_size_mask = GEN_INT (~((GET_MODE_SIZE (mode) * unroll) - 1));
+ HOST_WIDE_INT min_size = GET_MODE_SIZE (mode) * unroll;
+ rtx piece_size = GEN_INT (min_size);
+ rtx piece_size_mask = GEN_INT (~min_size - 1);
rtx size;
rtx x_addr;
rtx y_addr;
int i;
+ /* Bail out if expected size is less than minimum size
+ that can be emitted. */
+ if (expected_size < min_size)
+return;
+
iter_mode = GET_MODE (count);
if (iter_mode == VOIDmode)
iter_mode = word_mode;
There is also an optimization opportunity. When compiling testcase to 32bit
code (with -m32 -O2 -mtune=k8), following is generated:
init_reg_last:
pushl %ebp
movlreg_stat, %edx
xorl%eax, %eax
movl%esp, %ebp
.L2:
movl$0, (%edx,%eax)
movl$0, 4(%edx,%eax)
movl$0, 8(%edx,%eax)
movl$0, 12(%edx,%eax)
addl$16, %eax
cmpl$16, %eax<<< not needed
jb .L2 <<< not needed
addl%eax, %edx
movw$0, (%edx)
movb$0, 2(%edx)
leave
ret
We don't need to create loop in this case, as this loop will be executed only
once.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30778
Re: [Bug tree-optimization/30911] 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 compiler(?). > > No, that never happens. The rts is always built with the latest (stage3) > compiler. Otherwise it would not even begin to work fro cross compilers. Note that I'm talking about ada/rts, which gets installed under adainclude and adalib, and used by Ada apps. That's the target run-time. Maybe you are talking about the part of the Ada run-time which is used by the compiler itself, in which case, it's considered as a source of the compiler, and treated as such (built successively by all compilers from bootstrap compiler to stage2 compiler). Arno
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- 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 compiler(?). > > No, that never happens. The rts is always built with the latest (stage3) > compiler. Otherwise it would not even begin to work fro cross compilers. Note that I'm talking about ada/rts, which gets installed under adainclude and adalib, and used by Ada apps. That's the target run-time. Maybe you are talking about the part of the Ada run-time which is used by the compiler itself, in which case, it's considered as a source of the compiler, and treated as such (built successively by all compilers from bootstrap compiler to stage2 compiler). Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- 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 the bootstrap compiler. At least this would explain the difference in the number of acats failures I see comparing a bootstrapped tree vs. a non-bootstrapped tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
Re: [Bug tree-optimization/30911] 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/ 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 > number of acats failures I see comparing a bootstrapped tree vs. a > non-bootstrapped tree. Sorry, I am not familiar with --disable-bootstrap, but if it builds the Ada rts with the bootstrap compiler, then that's a clear bug in the top level makefiles. Ada makefiles are not designed to build the Ada rts with the host compiler, so there must be some very strange makefile interaction going on if true. You can easily verify that of course by checking your build log. Arno
[Bug tree-optimization/30911] VRP fails to eliminate range checks in Ada code
--- 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/ 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 > number of acats failures I see comparing a bootstrapped tree vs. a > non-bootstrapped tree. Sorry, I am not familiar with --disable-bootstrap, but if it builds the Ada rts with the bootstrap compiler, then that's a clear bug in the top level makefiles. Ada makefiles are not designed to build the Ada rts with the host compiler, so there must be some very strange makefile interaction going on if true. You can easily verify that of course by checking your build log. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30911
[Bug fortran/30400] [4.2 and 4.1 only] ANY not accepted as mask in FORALL
--- 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 Thomas <[EMAIL PROTECTED]> PR fortran/30400 * match.c (match_forall_iterator): Use gfc_match_expr instead of gfc_match_variable to match the iterator variable. Return MATCH_NO if not a variable. Remove the reset of the symbol's flavor in cleanup. * gfortran.dg/forall_10.f90: New test case. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/forall_10.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/match.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30400
[Bug tree-optimization/30904] VRP does not track values of shifts and/or bitfields?
--- 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-optimization/30904 * gcc.dg/pr30904.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr30904.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug c++/30944] cstddef:54: internal compiler error: Segmentation fault
--- 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 necessary. Um, for future reference, should I change the resolution? (In reply to comment #1) > 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" ? Sure: [EMAIL PROTECTED]:~$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5) > > This was all mentioned on http://gcc.gnu.org/bugs.html which comes out when an > internal compiler error happens. > Yes, it was, and I am a jackass. Apologies. Noted for future reference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30944
[Bug fortran/30947] New: intrinsic: ALARM
$> 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 int1 h = 0;
static int1 stat = -1;
static int1 sec = 1;
_gfortran_set_std (70, 127, 0, 0);
{
int4 D.1005;
int4 D.1004;
int4 D.1003;
D.1003 = (int4) sec;
D.1004 = (int4) h;
D.1005 = (int4) stat;
_gfortran_alarm_sub_int (&D.1003, &D.1004, &D.1005);
}
if (stat == -1)
{
_gfortran_abort ();
}
}
Here, the status (optional return value) is lost.
--
Summary: intrinsic: ALARM
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
OtherBugsDependingO 30932
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30947
[Bug fortran/30948] New: intrinsic: CHDIR
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, status = int_4)';
call = 'CALL chdir(path = string, status = int_8)';
};
1. The name of the first dummy argument is "NAME" instead of "PATH" (as
documented)
2. The library does not provide overloads for int1 and int2 (i16?)
3. The documentation does not specify the type of the STATUS argument
--
Summary: intrinsic: CHDIR
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: rejects-valid, documentation
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
OtherBugsDependingO 30932
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug c/30949] New: "incompatible pointer type" warning does not point to declaration
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 is.
A test programme is
int func (int x);
void recv (int (* funcptr) (double x));
void call (void)
{
recv (func);
}
This programme calls "recv" with a wrong argument. When I compile this, I
receive the warning below:
$ ~/gcc/bin/gcc --version
gcc (GCC) 4.3.0 20070201 (experimental)
$ ~/gcc/bin/gcc -Wall -c fptr.c
fptr.c: In function call:
fptr.c:7: warning: passing argument 1 of recv from incompatible pointer type
I would have liked a multi-line warning, pointing to the line which declares
"recv". I also would have liked an explanation like "the passed argument is of
type int (*)(int), but the type int (*)(double) is expected".
--
Summary: "incompatible pointer type" warning does not point to
declaration
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schnetter at aei dot mpg dot de
GCC build triplet: i386-apple-darwin8.8.1
GCC host triplet: i386-apple-darwin8.8.1
GCC target triplet: i386-apple-darwin8.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30949
[Bug c++/30944] cstddef:54: internal compiler error: Segmentation fault
--- 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 |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30944
[Bug fortran/30948] intrinsic: CHDIR
--- 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
[Bug fortran/30950] New: intrinsic: CPU_TIME
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
Version: 4.3.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
OtherBugsDependingO 30932
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30950
[Bug target/30770] [4.3 regression] BOOT_CFLAGS="-O2 -g -mtune=nocona" miscompiled the stage 3 compiler
--- 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 stringop handling.
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01937.html and the
following patch that disables unrolled loop stringops (for nocona) bootstraps
OK for -mtune=nocona. This applies to -march=athlon64 as well.
Index: i386.c
===
--- i386.c (revision 122286)
+++ i386.c (working copy)
@@ -789,10 +789,10 @@
COSTS_N_INSNS (44), /* cost of FSQRT instruction. */
{{libcall, {{12, loop_1_byte}, {-1, rep_prefix_4_byte}}},
{libcall, {{32, loop}, {2, rep_prefix_8_byte},
- {10, unrolled_loop}, {-1, libcall,
+ /*{10, unrolled_loop},*/ {-1, libcall,
{{libcall, {{6, loop_1_byte}, {48, loop}, {20480, rep_prefix_4_byte},
{-1, libcall}}},
- {libcall, {{24, loop}, {64, unrolled_loop},
+ {libcall, {{24, loop}, /*{64, unrolled_loop},*/
{8192, rep_prefix_8_byte}, {-1, libcall
};
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC||ubizjak at gmail dot com
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-02-24 19:09:51
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30770
[Bug c++/30866] [4.3 regression] Another ICE in calc_dfs_tree()
--- 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_data_::entry_pointer pb_ds::detail::lu_map_data_::allocate_new_entry(typename pb_ds::detail::types_traits::const_reference, pb_ds::detail::false_type) [with Key = pb_ds::test::basic_type, Mapped = pb_ds::test::basic_type, Eq_Fn = std::equal_to, Allocator = __gnu_cxx::throw_allocator, Update_Policy = pb_ds::test::counter_lu_policy_t_<__gnu_cxx::throw_allocator, 5u>]': /tmp/20070223/powerpc-ibm-aix5.2.0.0/libstdc++-v3/include/ext/pb_ds/detail/list_update_map_/insert_fn_imps.hpp:75: internal compiler error: in calc_dfs_tree, at dominance.c:374 -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-24 19:11:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30866
[Bug middle-end/30951] New: Does not fold x + CST == x and x + CST != x
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
Component: middle-end
AssignedTo: rguenth at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30951
[Bug middle-end/30951] Does not fold x + CST == x and x + CST != x
--- 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 middle-end/30951 * fold-const.c (fold_binary): Fold x +- CST op x for EQ_EXPR and NE_EXPR. * gcc.dg/pr30951.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr30951.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30951
[Bug middle-end/30951] Does not fold x + CST == x and x + CST != x
--- 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|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30951
[Bug fortran/30865] optional argument passed on to size(...,dim=)
--- 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 regression-test now. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30865
[Bug c++/30952] New: Unclear error message when callling via a function pointer
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/bin/g++ --version
g++ (GCC) 4.3.0 20070201 (experimental)
$ ~/gcc/bin/g++ -c argerror.cc
argerror.cc: In function void call(void (*)(int*, void**), int, int*):
argerror.cc:5: error: invalid conversion from int to int*
argerror.cc:5: error: cannot convert int* to void** in argument passing
Note that the first error does not specify that it appears in the first
function argument, and the second error only says "in argument passing", not
"in the second argument". None of the errors say that the function *sub is
called.
--
Summary: Unclear error message when callling via a function
pointer
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schnetter at aei dot mpg dot de
GCC build triplet: i386-apple-darwin8.8.1
GCC host triplet: i386-apple-darwin8.8.1
GCC target triplet: i386-apple-darwin8.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30952
[Bug fortran/30953] New: intrinsic: CTIME
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 implement dummy argument names are "time" and "result".
--
Summary: intrinsic: CTIME
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
OtherBugsDependingO 30392
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30953
[Bug target/30770] [4.3 regression] BOOT_CFLAGS="-O2 -g -mtune=nocona" miscompiled the stage 3 compiler
--- 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 bootstrap for
all x86_64 targets.
2007-02-24 Uros Bizjak <[EMAIL PROTECTED]>
PR target/30770
* config/i386/i386.md (expand_movmem_epilogue): Fix typo, mask
count argument with 0x10, not with 0x16.
(expand_setmem_epilogue): Ditto.
Index: i386.c
===
--- i386.c (revision 122286)
+++ i386.c (working copy)
@@ -13522,7 +13549,7 @@
HOST_WIDE_INT countval = INTVAL (count);
int offset = 0;
- if ((countval & 0x16) && max_size > 16)
+ if ((countval & 0x10) && max_size > 16)
{
if (TARGET_64BIT)
{
@@ -13675,7 +13702,7 @@
HOST_WIDE_INT countval = INTVAL (count);
int offset = 0;
- if ((countval & 0x16) && max_size > 16)
+ if ((countval & 0x10) && max_size > 16)
{
if (TARGET_64BIT)
{
--
ubizjak at gmail dot com changed:
What|Removed |Added
BugsThisDependsOn||30778
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-02-24 19:09:51 |2007-02-24 22:54:35
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30770
[Bug target/30778] [4.3 Regression] invalid code generation for memset() with -mtune=k8
-- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-02-13 09:43:50 |2007-02-24 22:55:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30778
[Bug middle-end/30509] [4.3 Regression] ice for legal code with -O3
--- 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 (copy_body_data *id, basic_block
*** 873,879
gcc_assert (lookup_stmt_eh_region_fn (id->src_cfun, orig_stmt)
!= 0);
! if (tree_could_throw_p (stmt))
{
int region = lookup_stmt_eh_region_fn (id->src_cfun,
orig_stmt);
/* Add an entry for the copied tree in the EH hashtable.
--- 873,892
gcc_assert (lookup_stmt_eh_region_fn (id->src_cfun, orig_stmt)
!= 0);
! if (tree_could_throw_p (stmt)
! /* When we are cloning for inlining, we are supposed to
!construct a clone that calls precisely the same functions
!as original. However IPA optimizers might've proved
!earlier some function calls as non-trapping that might
!render some basic blocks dead that might become
!unreachable.
!
!We can't update SSA with unreachable blocks in CFG and
thus
!we prevent the scenario by preserving even the "dead" eh
!edges until the point they are later removed by
!fixup_cfg pass. */
! || (id->transform_call_graph_edges == CB_CGE_MOVE
! && lookup_stmt_eh_region_fn (id->src_cfun, orig_stmt) >
0))
{
int region = lookup_stmt_eh_region_fn (id->src_cfun,
orig_stmt);
/* Add an entry for the copied tree in the EH hashtable.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2007-01-22 02:17:10 |2007-02-24 22:58:13
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30509
[Bug target/30778] [4.3 Regression] invalid code generation for memset() with -mtune=k8
--- 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 end up using move_by_pieces so we won't produce the loop anyway, but still there should be loop header test emitted, I am just looking on why it is skipped. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30778
[Bug target/30778] [4.3 Regression] invalid code generation for memset() with -mtune=k8
--- 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 we should in this case end up using move_by_pieces so we won't > produce the loop anyway, but still there should be loop header test emitted, I > am just looking on why it is skipped. Please note, that the proposed patch in gcc-patches ML is a bit different and also removes loops when number of iterations is 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30778
[Bug fortran/30954] New: intrinsic: DATE_AND_TIME
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 Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org OtherBugsDependingO 30392 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30954
[Bug target/30770] [4.3 regression] BOOT_CFLAGS="-O2 -g -mtune=nocona" miscompiled the stage 3 compiler
--- 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_movmem_epilogue): Fix typo, mask count argument with 0x10, not with 0x16. (expand_setmem_epilogue): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30770
[Bug target/30778] [4.3 Regression] invalid code generation for memset() with -mtune=k8
--- 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 not triggering partial
memory stalls.
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.
Thanks a lot for looking into it - I should've dealt with this bug a lot
sooner, but I was very busy last week...
Honza
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 122292)
+++ config/i386/i386.c (working copy)
@@ -13522,7 +13522,7 @@ expand_movmem_epilogue (rtx destmem, rtx
HOST_WIDE_INT countval = INTVAL (count);
int offset = 0;
- if ((countval & 0x16) && max_size > 16)
+ if ((countval & 0x10) && max_size > 16)
{
if (TARGET_64BIT)
{
@@ -13539,8 +13539,8 @@ expand_movmem_epilogue (rtx destmem, rtx
emit_strmov (destmem, srcmem, destptr, srcptr, DImode, offset);
else
{
- emit_strmov (destmem, srcmem, destptr, srcptr, DImode, offset);
- emit_strmov (destmem, srcmem, destptr, srcptr, DImode, offset +
4);
+ emit_strmov (destmem, srcmem, destptr, srcptr, SImode, offset);
+ emit_strmov (destmem, srcmem, destptr, srcptr, SImode, offset +
4);
}
offset += 8;
}
@@ -13675,7 +13675,7 @@ expand_setmem_epilogue (rtx destmem, rtx
HOST_WIDE_INT countval = INTVAL (count);
int offset = 0;
- if ((countval & 0x16) && max_size > 16)
+ if ((countval & 0x10) && max_size > 16)
{
if (TARGET_64BIT)
{
@@ -14118,19 +14118,22 @@ ix86_expand_movmem (rtx dst, rtx src, rt
gcc_assert (desired_align >= 1 && align >= 1);
/* Ensure that alignment prologue won't copy past end of block. */
- if ((size_needed > 1 || (desired_align > 1 && desired_align > align))
- && !count)
+ if (size_needed > 1 || (desired_align > 1 && desired_align > align))
{
- epilogue_size_needed = MAX (size_needed - 1, desired_align - align);
+ enum machine_mode mode = GET_MODE (count_exp);
+ if (mode == VOIDmode)
+ mode = DImode;
+
+ epilogue_size_needed = MAX (size_needed - 1, desired_align - align);
/* Epilogue always copies COUNT_EXP & EPILOGUE_SIZE_NEEDED bytes.
Make sure it is power of 2. */
epilogue_size_needed = smallest_pow2_greater_than
(epilogue_size_needed);
label = gen_label_rtx ();
- emit_cmp_and_jump_insns (count_exp,
+ emit_cmp_and_jump_insns (force_reg (mode, count_exp),
GEN_INT (epilogue_size_needed),
- LTU, 0, GET_MODE (count_exp), 1, label);
+ LTU, 0, mode, 1, label);
if (expected_size == -1 || expected_size < epilogue_size_needed)
predict_jump (REG_BR_PROB_BASE * 60 / 100);
else
@@ -14430,11 +14433,14 @@ ix86_expand_setmem (rtx dst, rtx count_e
promoted_val = promote_duplicated_reg_to_size (val_exp, size_needed,
desired_align, align);
/* Ensure that alignment prologue won't copy past end of block. */
- if ((size_needed > 1 || (desired_align > 1 && desired_align > align))
- && !count)
+ if (size_needed > 1 || (desired_align > 1 && desired_align > align))
{
- epilogue_size_needed = MAX (size_needed - 1, desired_align - align);
+ enum machine_mode mode = GET_MODE (count_exp);
+
+ if (mode == VOIDmode)
+ mode = DImode;
+ epilogue_size_needed = MAX (size_needed - 1, desired_align - align);
/* Epilogue always copies COUNT_EXP & EPILOGUE_SIZE_NEEDED bytes.
Make sure it is power of 2. */
epilogue_size_needed = smallest_pow2_greater_than
(epilogue_size_needed);
@@ -14446,9 +14452,9 @@ ix86_expand_setmem (rtx dst, rtx count_e
if (epilogue_size_needed > 2 && !promoted_val)
force_loopy_epilogue = true;
label = gen_label_rtx ();
- emit_cmp_and_jump_insns (count_exp,
+ emit_cmp_and_jump_insns (force_reg (mode, count_exp),
GEN_INT (epilogue_size_needed),
- LTU, 0, GET_MODE (count_exp), 1, label);
+ LTU, 0, mode, 1, label);
if (expected_size == -1 || expected_size <= epilogue_size_needed)
predict_jump (REG_BR_PROB_BASE * 60 / 100);
else
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30778
[Bug fortran/30955] New: intrinsic: FGET
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 fget(count = char, status = int_4)';
call = 'CALL fget(count = char, status = int_8)';
};
1. The argument name of the first dummy argument name is "count", documented is
"c. Neither one is very descriptive for fget, IMO plain "c" is better than
"count"
2. The first argument shall accept only CHARACTER, but CHARACTER(*) is also
allowed:
$> cat fget.f90
character(len=10) :: s
s = '0123456789'
CALL fget(s)
write(*,*) s
end
$> gfortran-svn fget.f90 && ./a.out
x
x
I.e. the string is cleared and the first character is set to the input.
This also "works" with substrings, e.g. s(3:6).
In my eyes I would consider the blanking the bug, not that a string is allowed.
Consistent behaviour should overwrite the first character, not ALL of them.
3. The optional status argument accepts variables of type default integer only.
--
Summary: intrinsic: FGET
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dfranke at gcc dot gnu dot org
OtherBugsDependingO 30932
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30955
[Bug libfortran/30918] Failure to skip commented out NAMELIST
--- 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 AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-25 00:28:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30918
[Bug c/30956] New: ice on final.c
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: internal compiler error: in rest_of_handle_final, at final.c:3942 fribidi-0.10.4 is ok Compiler version ming32 4.1.2 compile options: Configured with: ../gcc-4.1.2/configure --with-gcc --with-ld=/mingw/bin/ld --with-gnu-as --program-suffix=-4.1 --enable-version-specific-runtime-libs --disable-libstdcxx-debug --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads=win32 --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-shared --enable-sjlj-exceptions --disable-interpreter --disable-werror --enable-hash-synchronization Thread model: win32 I'll attach dumps -- Summary: ice on final.c Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sherpya at netfarm dot it GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30956
[Bug c/30956] ice on final.c
--- 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 specs. Target: mingw32 Configured with: ../gcc-4.1.2/configure --with-gcc --with-ld=/mingw/bin/ld --with-gnu-as --program-suffix=-4.1 --enable-version-specific-runtime-libs --disable-libstdcxx-debug --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads=win32 --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-shared --enable-sjlj-exceptions --disable-interpreter --disable-werror --enable-hash-synchronization Thread model: win32 gcc version 4.1.2 [Sherpya] j:/mingw/bin/../libexec/gcc/mingw32/4.1.2/cc1.exe -E -quiet -v -I. -I. -I. -iprefix j:\mingw\bin\../lib/gcc/mingw32/4.1.2/ -MD fribidi_utils.d -MF .deps/fribidi_utils.Tpo -MP -MT fribidi_utils.lo -MQ fribidi_utils.o -DHAVE_CONFIG_H fribidi_utils.c -Wall -pedantic -fno-strict-aliasing -fworking-directory -O2 -fpch-preprocess -o fribidi_utils.i ignoring nonexistent directory "j:/MinGW/mingw32/include" #include "..." search starts here: #include <...> search starts here: . . . j:/mingw/bin/../lib/gcc/mingw32/4.1.2/include j:/MinGW/include /mingw/include j:/MinGW/lib/gcc/mingw32/4.1.2/include /mingw/include End of search list. j:/mingw/bin/../libexec/gcc/mingw32/4.1.2/cc1.exe -fpreprocessed fribidi_utils.i -quiet -dumpbase fribidi_utils.c -auxbase-strip fribidi_utils.o -g -O2 -Wall -pedantic -version -fno-strict-aliasing -o fribidi_utils.s GNU C version 4.1.2 [Sherpya] (mingw32) compiled by GNU C version 4.1.1 [Sherpya]. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=131005 Compiler executable checksum: 189b7f34c85af66fb411018b3b42b485 fribidi_utils.c: In function 'fribidi_map_range': fribidi_utils.c:108: internal compiler error: in rest_of_handle_final, at final.c:3942 -- sherpya at netfarm dot it changed: What|Removed |Added CC||sherpya at netfarm dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30956
[Bug libfortran/30918] Failure to skip commented out NAMELIST
--- 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]> PR libgfortran/30918 * io/listread.c (namelist_read): Eat comment line. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30918
[Bug libfortran/30918] Failure to skip commented out NAMELIST
--- 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]> PR libgfortran/30918 * gfortran.dg/namelist_26.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_26.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30918
[Bug c/30956] ice on final.c
--- 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30956
[Bug fortran/30865] optional argument passed on to size(...,dim=)
--- 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/show_bug.cgi?id=30865
[Bug libfortran/30918] Failure to skip commented out NAMELIST
--- 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]> PR libgfortran/30918 * io/listread.c (namelist_read): Eat comment line. 2007-02-24 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/30918 * gfortran.dg/namelist_26.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/namelist_26.f90 Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30918
[Bug middle-end/30956] ice on final.c
--- 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 as dllimport Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30956
[Bug libfortran/30918] Failure to skip commented out NAMELIST
--- 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]> PR libgfortran/30918 * io/listread.c (namelist_read): Eat comment line. 2007-02-24 Jerry DeLisle <[EMAIL PROTECTED]> PR libgfortran/30918 * gfortran.dg/namelist_26.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_26.f90 Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30918
[Bug libfortran/30918] Failure to skip commented out NAMELIST
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30918
[Bug fortran/30285] gfortran excessive memory usage with large modules
--- 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
===
--- gcc/gcc/fortran/module.c(revision 122310)
+++ gcc/gcc/fortran/module.c(working copy)
@@ -3598,6 +3598,7 @@
write_common (gfc_symtree *st)
{
gfc_common_head *p;
+ pointer_info *pinfo;
const char * name;
int flags;
@@ -3607,6 +3608,14 @@
write_common (st->left);
write_common (st->right);
+ /* only need to write a given symtree entry once for
+ common blocks */
+ p = st->n.common;
+ pinfo = find_pointer(p);
+
+ if (pinfo != NULL && pinfo->u.wsym.state != UNREFERENCED)
+return;
+
mio_lparen ();
/* Write the unmangled name. */
@@ -3614,7 +3623,6 @@
mio_pool_string (&name);
- p = st->n.common;
mio_symbol_ref (&p->head);
flags = p->saved ? 1 : 0;
if (p->threadprivate) flags |= 2;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30285
[Bug target/30778] [4.3 Regression] invalid code generation for memset() with -mtune=k8
--- 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 patch ICEs for "-O2 -march=nocona -m32" on the testcase above: pr30778.c: In function init_reg_last: pr30778.c:21: internal compiler error: in predict_jump, at config/i386/i386.c:13246 BTW: For -march=k8, we now generate: movqreg_stat(%rip), %rax movq$0, (%rax) addq$8, %rax movq$0, (%rax) addq$8, %rax movq$0, (%rax) addq$8, %rax movl$0, (%rax) addq$4, %rax movw$0, (%rax) movb$0, 2(%rax) ret and previously: movqreg_stat(%rip), %rax movq$0, (%rax) movq$0, 8(%rax) movq$0, 16(%rax) movl$0, 24(%rax) movw$0, 28(%rax) movb$0, 30(%rax) ret (I don't know if this is intentionally, just want to point it out.) -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|ubizjak at gmail dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30778
