[Bug target/38708] [4.4 Regression] Revision 137646 caused gcc.c-torture/execute/memset-[23].c fail with -mtune=pentiumpro
--- Comment #5 from jakub at gcc dot gnu dot org 2009-01-03 08:46 ---
There are several issues. One is what H.J. mentioned, seen e.g. on:
char buf[8] __attribute__((aligned));
char A = 'A';
int len = 1;
void __attribute__((noinline))
check (void)
{
if (__builtin_memcmp (buf, \0\0A\0\0\0\0\0, 8))
__builtin_abort ();
}
int
main ()
{
__builtin_memset (buf + 2, A, len);
check ();
return 0;
}
with -O -mtune=pentium-m -m32. This can be fixed by adding
max_size = smallest_pow2_greater_than (max_size - 1); at the start of
expand_setmem_epilogue_via_loop. But another testcase with the same options
that still fails is:
char buf[8] __attribute__((aligned)) = ;
char A = 'A';
int len = 4;
void __attribute__((noinline))
check (void)
{
if (__builtin_memcmp (buf, \0\0\0\0, 8))
__builtin_abort ();
}
int
main ()
{
__builtin_memset (buf + 4, '\0', len);
check ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38708
[Bug target/38708] [4.4 Regression] Revision 137646 caused gcc.c-torture/execute/memset-[23].c fail with -mtune=pentiumpro
--- Comment #6 from jakub at gcc dot gnu dot org 2009-01-03 09:09 ---
--- i386.c.jj42008-12-27 10:12:25.0 +0100
+++ i386.c2009-01-03 10:03:05.0 +0100
@@ -18012,13 +18012,12 @@ ix86_expand_setmem (rtx dst, rtx count_e
Epilogue code will actually copy COUNT_EXP EPILOGUE_SIZE_NEEDED
bytes. Compensate if needed. */
- if (size_needed desired_align - align)
+ if (size_needed epilogue_size_needed)
{
tmp =
expand_simple_binop (counter_mode (count_exp), AND, count_exp,
GEN_INT (size_needed - 1), count_exp, 1,
OPTAB_DIRECT);
- size_needed = desired_align - align + 1;
if (tmp != count_exp)
emit_move_insn (count_exp, tmp);
}
@@ -18029,10 +18028,10 @@ ix86_expand_setmem (rtx dst, rtx count_e
{
if (force_loopy_epilogue)
expand_setmem_epilogue_via_loop (dst, destreg, val_exp, count_exp,
- size_needed);
+ epilogue_size_needed);
else
expand_setmem_epilogue (dst, destreg, promoted_val, count_exp,
-size_needed);
+epilogue_size_needed);
}
if (jump_around_label)
emit_label (jump_around_label);
instead seems to fix memset-3.c with -mtune=pentium-m -m32 at all optimizations
levels (and is what ix86_expand_movmem does). But memset-2.c still fails, and
not just at -O3, but also at -O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38708
[Bug c++/38705] [4.4 Regression] ICE: canonical types differ for identical types const int and const AlpsNodeIndex_t
--- Comment #7 from steven at gcc dot gnu dot org 2009-01-03 10:24 --- Reviewer said: So, this is ok with or without the volatile restriction. (see http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00070.html). The committed patch still seems to have this restriction...? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38705
[Bug target/38708] [4.4 Regression] Revision 137646 caused gcc.c-torture/execute/memset-[23].c fail with -mtune=pentiumpro
--- Comment #7 from jakub at gcc dot gnu dot org 2009-01-03 10:26 --- Created an attachment (id=17025) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17025action=view) gcc44-pr38708.patch For size_needed, we never want any epilogue. This cures memset-2.c at -O2, but -O3 still fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38708
[Bug target/38708] [4.4 Regression] Revision 137646 caused gcc.c-torture/execute/memset-[23].c fail with -mtune=pentiumpro
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-03 10:26 --- I meant for size_needed == 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38708
[Bug c++/38705] [4.4 Regression] ICE: canonical types differ for identical types const int and const AlpsNodeIndex_t
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-03 11:28 --- Yes. Just removing the restriction is wrong, because then volatile from the wrong side of the copy would be used. So extra code would be needed to handle that, and I really don't think it is worth it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38705
[Bug target/36680] ICE in spill_failure, reload1.c:1995
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-01-03 11:32 --- Confirmed, goes back at least to 4.2 (so not a regression). -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.4.0 4.3.3 4.2.4 Last reconfirmed|-00-00 00:00:00 |2009-01-03 11:32:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36680
[Bug target/38708] [4.4 Regression] Revision 137646 caused gcc.c-torture/execute/memset-[23].c fail with -mtune=pentiumpro
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-03 11:39 ---
I ran check-gcc RUNTESTFLAGS='execute.exp
--target_board=unix/{-m32,-m32/-mtune=pentium-m,-m64}/-mstringop-strategy={rep_byte,libcall,rep_4byte,rep_8byte,byte_loop,loop,unrolled_loop}'
before and after the patch. In all cases, -m32 together with
-mstringop-strategy=rep_8byte
ICEs in many testcases, obviously we need to reject -m32
-mstringop-strategy=rep_8byte.
Other than that, we have:
unix/-m64/-mstringop-strategy=loop
FAIL: gcc.c-torture/execute/memset-2.c execution, -O2
FAIL: gcc.c-torture/execute/memset-2.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/memset-2.c execution, -O3 -fomit-frame-pointer
-funroll-loops
FAIL: gcc.c-torture/execute/memset-2.c execution, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/memset-2.c execution, -O3 -g
(before and after the patch) and:
unix/-m32/-mtune=pentium-m/-mstringop-strategy=rep_byte
-FAIL: gcc.c-torture/execute/memcpy-2.c execution, -O1
-FAIL: gcc.c-torture/execute/memcpy-2.c execution, -O2
-FAIL: gcc.c-torture/execute/memcpy-2.c execution, -O3 -fomit-frame-pointer
-FAIL: gcc.c-torture/execute/memcpy-2.c execution, -O3 -fomit-frame-pointer
-funroll-loops
-FAIL: gcc.c-torture/execute/memcpy-2.c execution, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
-FAIL: gcc.c-torture/execute/memcpy-2.c execution, -O3 -g
FAIL: gcc.c-torture/execute/memset-1.c execution, -O1
FAIL: gcc.c-torture/execute/memset-1.c execution, -O2
FAIL: gcc.c-torture/execute/memset-1.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/memset-1.c execution, -O3 -fomit-frame-pointer
-funroll-loops
FAIL: gcc.c-torture/execute/memset-1.c execution, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/memset-1.c execution, -O3 -g
FAIL: gcc.c-torture/execute/memset-2.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/memset-2.c execution, -O3 -fomit-frame-pointer
-funroll-loops
FAIL: gcc.c-torture/execute/memset-2.c execution, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/memset-2.c execution, -O3 -g
FAIL: gcc.c-torture/execute/memset-3.c execution, -O1
FAIL: gcc.c-torture/execute/memset-3.c execution, -O2
FAIL: gcc.c-torture/execute/memset-3.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/memset-3.c execution, -O3 -fomit-frame-pointer
-funroll-loops
FAIL: gcc.c-torture/execute/memset-3.c execution, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
FAIL: gcc.c-torture/execute/memset-3.c execution, -O3 -g
unix/-m32/-mtune=pentium-m/-mstringop-strategy=rep_4byte
-FAIL: gcc.c-torture/execute/memset-3.c execution, -O1
-FAIL: gcc.c-torture/execute/memset-3.c execution, -O2
-FAIL: gcc.c-torture/execute/memset-3.c execution, -O3 -fomit-frame-pointer
-FAIL: gcc.c-torture/execute/memset-3.c execution, -O3 -fomit-frame-pointer
-funroll-loops
-FAIL: gcc.c-torture/execute/memset-3.c execution, -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions
-FAIL: gcc.c-torture/execute/memset-3.c execution, -O3 -g
( FAIL is before+after the patch, -FAIL is before the patch, cured by the
patch).
To reject rep_8byte for -m32 we IMHO want:
--- i386.c.jj42008-12-27 10:12:25.0 +0100
+++ i386.c2009-01-03 11:53:15.0 +0100
@@ -2686,7 +2686,8 @@ override_options (bool main_args_p)
stringop_alg = libcall;
else if (!strcmp (ix86_stringop_string, rep_4byte))
stringop_alg = rep_prefix_4_byte;
- else if (!strcmp (ix86_stringop_string, rep_8byte))
+ else if (!strcmp (ix86_stringop_string, rep_8byte)
+TARGET_64BIT)
stringop_alg = rep_prefix_8_byte;
else if (!strcmp (ix86_stringop_string, byte_loop))
stringop_alg = loop_1_byte;
and obviously the remaining FAILs need to be investigated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38708
[Bug c/38714] New: gcc allows last member of a struct or union without a semicolon
struct S
{
int m
};
This compiles as a C program (not as C++) with warning: no semicolon at end of
struct or union.
I checked the c99 document and the semicolon seems to be mandatory.
--
Summary: gcc allows last member of a struct or union without a
semicolon
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: get dot sonic at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38714
[Bug middle-end/38586] quadratic behaviour in find_temp_slot_from_address.
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-03 11:51 --- Ok. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38586
[Bug c/38714] gcc allows last member of a struct or union without a semicolon
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-01-03 11:53 --- gcc -S t.c -pedantic-errors t.c:4: error: no semicolon at end of struct or union thus, this works for me. We accept it by default with an unconditional warning for legacy reasons. Use -pedantic-errors to force strict compliance checking. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38714
[Bug c/38716] New: Undocumented __attribute__((optimize)) behaviour when the attribute specifies no optimisation level
If __attribute__((optimize(...))) does not specify an optimisation
level (-Ox), we act as though the prevailing -Ox level had been restated.
So:
__attribute__((optimize(no-gcse)))
behaves like:
__attribute__((optimize(Ox, no-gcse)))
where Ox is the current optimisation level. This means that if you
compile:
void bar (int);
void __attribute__((optimize(no-gcse))) f1 (void)
{
bar (1);
bar (2);
}
void f2 (void)
{
bar (1);
bar (2);
}
with -O2 -fno-omit-frame-pointer, f1 will be implicitly use:
__attribute__((optimize(O2, no-gcse)))
and this implicit -O2 will override the explicit -fno-omit-frame-pointer.
So f1 will be compiled without a frame pointer but f2 will be compiled
with one.
This behaviour isn't mentioned in the current documentation,
so this is either an implementation or a documentation bug.
In RichardG's opinion (and my opinion) it's an implementation
bug, so I'm marking it as c.
--
Summary: Undocumented __attribute__((optimize)) behaviour when
the attribute specifies no optimisation level
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
GCC host triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38716
[Bug target/38643] Doesn't hide (visibility-wise) vtables and VTTs on ARM EABI
--- Comment #3 from tbm at cyrius dot com 2009-01-03 14:13 --- You're right that it works with trunk. I was wrong when I said it still shows up with trunk. However, it's not fixed with 4.3 from SVN, so this bug should be left open. -- tbm at cyrius dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38643
[Bug fortran/38594] [4.4 Regression] module function name mangled improperly if contained function of same name exists
--- Comment #5 from pault at gcc dot gnu dot org 2009-01-03 14:15 --- I have just posted a patch on the list. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-22 12:07:26 |2009-01-03 14:15:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38594
[Bug target/38692] ep9312/maverick code generation is broken
--- Comment #3 from martinwguy at yahoo dot it 2009-01-03 14:42 --- gue...@gcc50:~$ ./install-trunk-142808/bin/gcc -mfpu=maverick -mcpu=ep9312 -mfloat-abi=softfp is also needed to generate Maverick instructions, and the resulting binary should give illegal instructions on an Xscale. If it's useful, there's an n2100 here and an ep9307 board, both running EABI systems and on 24/7, the first directly on the net and the other on the localnet accessible from the n2100, accounts on request -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38692
[Bug rtl-optimization/15023] -frename-registers is slow
--- Comment #18 from steven at gcc dot gnu dot org 2009-01-03 15:24 --- Closing this as a dup of bug 38582 because that bug has a test case. *** This bug has been marked as a duplicate of 38582 *** -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug middle-end/38582] excessive time in rename registers
--- Comment #2 from steven at gcc dot gnu dot org 2009-01-03 15:24 --- *** Bug 15023 has been marked as a duplicate of this bug. *** -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38582
[Bug c++/36846] [4.3/4.4 regression] ICE with variadic templates partial specialization
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-03 15:26 --- valid or not? If so then it's a rejects-valid, otherwise it is error-recovery. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dgregor at cs dot indiana ||dot edu Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36846
[Bug c++/36607] [4.3/4.4 Regression] Incorrect type diagnostic on substracting casted char pointers
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36607
[Bug target/38642] [4.3/4.4 Regression] Code with -fPIC results in segfault on ARM (old ABI)
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-03 15:28 --- only arm-eabi is in the list of primary/secondary targets. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to work||4.2.4 Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38642
[Bug c++/38699] [4.2/4.3/4.4 regression] ICE using offsetof with pointer and array accesses
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.1.2 Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38699
[Bug c/38700] [4.2/4.3 regression] ICE with __builtin_expect and label
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-03 15:32 --- This occurs only with checking enabled, so IMHO not worth fixing on the branches. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Keywords||ice-checking Known to fail||4.3.3 Resolution||FIXED Target Milestone|4.2.5 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38700
[Bug target/38692] ep9312/maverick code generation is broken
--- Comment #4 from laurent at guerby dot net 2009-01-03 15:39 --- I do indeed get an illegal instruction when I add -mfloat-abi=softfp I don't have the skills to fix this but thanks for your offer :). Note: gcc50 is an n2100, part of the GCC compile farm: http://gcc.gnu.org/wiki/CompileFarm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38692
[Bug c++/36846] [4.3/4.4 regression] ICE with variadic templates partial specialization
--- Comment #6 from tristan at wibberley dot org 2009-01-03 15:50 --- Subject: Re: [4.3/4.4 regression] ICE with variadic templates partial specialization On Sat, 2009-01-03 at 15:26 +, rguenth at gcc dot gnu dot org wrote: --- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-03 15:26 --- valid or not? If so then it's a rejects-valid, otherwise it is error-recovery. I had discussed these c++0x features in ##c++ and I came to the conclusion that it was valid code. But I'm not an expert in c++0x, I discovered this problem while experimenting when learning. It accepts the code without the nested struct, it is only with a nested struct that the code is rejected. I don't think a nested struct will make it invalid and the behaviour of ambiguity analysis with a larger example suggests the code is very carefully and consciously accepted without that struct - agreeing with my studies and conversations on IRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36846
[Bug target/38707] [4.4 Regression] gcc.c-torture/execute/20050121-1.c ICEs with -march=pentium-m
--- Comment #5 from jakub at gcc dot gnu dot org 2009-01-03 15:50 --- Created an attachment (id=17026) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17026action=view) gcc44-pr38707.patch Patch that I'm going to bootstrap/regtest. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38707
[Bug target/38707] [4.4 Regression] gcc.c-torture/execute/20050121-1.c ICEs with -march=pentium-m
--- Comment #6 from jakub at gcc dot gnu dot org 2009-01-03 15:57 --- *** Bug 38710 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38707
[Bug target/38710] [4.4 Regression] ICE with _Complex short and -march=pentiumpro
--- Comment #2 from jakub at gcc dot gnu dot org 2009-01-03 15:57 --- It is the same bug. *** This bug has been marked as a duplicate of 38707 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38710
[Bug target/38706] [4.4 regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault
--- Comment #1 from ubizjak at gmail dot com 2009-01-03 16:57 --- Can you create a reduced testcase? gcc bootstrapped OK a couple of days ago on alphaev56-unknown-linux-gnu (gcc30.fsffrance.org). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38706
[Bug target/38706] [4.4 regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault
--- Comment #2 from ubizjak at gmail dot com 2009-01-03 16:58 --- BTW: Did you build from a clean build directory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38706
[Bug java/38717] New: gcc 4.4.0 20090102 - jc1: out of memory allocating ... (with 1 G of RAM)
Similar to this bug: jc1: out of memory allocating 4072 bytes after a total of 708630224 bytes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29587 I am compiling gcc on a machine with 1024 MB of memory and can't get past here: gmake[5]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/testsuite' gmake[5]: Entering directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava' /bin/sh ./libtool --tag=GCJ --mode=compile /usr/share/src/gcc_build/gcc/gcj -B/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/ -B/usr/share/src/gcc_build/gcc/ -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../../gcc_trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m64 -c -o gnu/javax/swing/text/html/parser/HTML_401F.lo -fsource-filename=/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser/HTML_401F.lo -MD -MP -MF gnu/javax/swing/text/html/parser/HTML_401F.deps @gnu/javax/swing/text/html/parser/HTML_401F.list libtool: compile: /usr/share/src/gcc_build/gcc/gcj -B/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/ -B/usr/share/src/gcc_build/gcc/ -ffloat-store -fomit-frame-pointer -Usun -fclasspath= -fbootclasspath=../../../../gcc_trunk/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -m64 -c -fsource-filename=/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/classpath/lib/classes -MT gnu/javax/swing/text/html/parser/HTML_401F.lo -MD -MP -MF gnu/javax/swing/text/html/parser/HTML_401F.deps @gnu/javax/swing/text/html/parser/HTML_401F.list -fPIC -o gnu/javax/swing/text/html/parser/.libs/HTML_401F.o jc1: out of memory allocating 4072 bytes after a total of 312090624 bytes gmake[5]: *** [gnu/javax/swing/text/html/parser/HTML_401F.lo] Error 1 gmake[5]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava' gmake[4]: *** [all-recursive] Error 1 gmake[4]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava' gmake[3]: *** [multi-do] Error 1 gmake[3]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava' gmake[2]: *** [all-multi] Error 2 gmake[2]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava' gmake[1]: *** [all-target-libjava] Error 2 gmake[1]: Leaving directory `/usr/share/src/gcc_build' gmake: *** [all] Error 2 I shutdown VirtualBox, increased the memory to 1600MB and rebooted. During the build I ran the System Performance Monitor and monitored the amount of memory used. The memory peaked at 1.3 GBs. The build is now able to continue correctly with this memory size. Will ./configure be getting a memory test to see if we have enough available to compile? ;) Rob -- Summary: gcc 4.4.0 20090102 - jc1: out of memory allocating ... (with 1 G of RAM) Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com GCC build triplet: i386-pc-solaris2.11 GCC host triplet: i386-pc-solaris2.11 GCC target triplet: i386-pc-solaris2.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38717
[Bug java/38717] gcc 4.4.0 20090102 - jc1: out of memory allocating ... (with 1 G of RAM)
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-03 17:16 --- Do you have virtual memory turned on because it sounds like you don't. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38717
[Bug c/38704] Very bad quality of compilation of a floating point numbers.
--- Comment #7 from lisp2d at lisp2d dot net 2009-01-03 17:19 --- The type long double does not have uniform standard. Confusion has turned out. Accuracy of type double suits me. Let's complete this talk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38704
[Bug rtl-optimization/38583] huge test case makes register allocator run out of memory while constructing the conflict graph
--- Comment #2 from steven at gcc dot gnu dot org 2009-01-03 17:23 --- I agree with Vlad, this is not a regression. It'd still be nice if you can figure out a way to make this work, Vlad. It is possible, perhaps, to split huge basic blocks up in chunks (e.g. separate basic blocks or regions) and allocate the chunks separately? -- steven at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] ira memory |huge test case makes |explosion |register allocator run out ||of memory while constructing ||the conflict graph http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38583
[Bug fortran/38594] [4.4 Regression] module function name mangled improperly if contained function of same name exists
--- Comment #6 from pault at gcc dot gnu dot org 2009-01-03 17:48 --- Subject: Bug 38594 Author: pault Date: Sat Jan 3 17:47:20 2009 New Revision: 143032 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143032 Log: 2009-01-03 Paul Thomas pa...@gcc.gnu.org PR fortran/38594 * resolve.c (resolve_call): When searching for proper host association, use symtree rather than symbol. For everything except generic subroutines, substitute the symtree in the call rather than the symbol. 2009-01-03 Paul Thomas pa...@gcc.gnu.org PR fortran/38594 * gfortran.dg/host_assoc_call_3.f90: Make sure that the generic interface still works, in addition to original tests. * gfortran.dg/host_assoc_call_6.f90: New test. Added: trunk/gcc/fortran/ChangeLog-2008 trunk/gcc/testsuite/gfortran.dg/host_assoc_call_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/host_assoc_call_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38594
[Bug fortran/22210] gfc_conv_array_initializer weirdness
--- Comment #13 from dfranke at gcc dot gnu dot org 2009-01-03 18:05 --- (In reply to comment #12) Maybe this weekend :). I guess I have been really behind on my FSF bugs. Yearly reminder. Any progress here? :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
[Bug fortran/24886] different character length in actual and formal argument not detected
--- Comment #8 from domob at gcc dot gnu dot org 2009-01-03 19:08 --- Runtime checking is PR 37746, BTW, I'm working on it and have a pending patch. Would this fix this bug or should we wait for the whole-file checking? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
[Bug bootstrap/38693] gcc 4.4.0 20090101 - gcc/config/i386/sol2-10.h uses USE_GAS which is undefined
--- Comment #2 from rob1weld at aol dot com 2009-01-03 19:15 --- Since this bug is related to the assembler I tried setting the --with-gnu-as --with-as= options for configure and while that allowed the build to continue it then went down a path of uncharted waters (and numerous problems with the scripts not creating/copying libtool, not building the 64 directories, etc.). What I finally ended up doing was this: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-multilib --enable-shared --disable-static --enable-decimal-float --enable-nls --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Note that I set 'as' and 'ld' to the binutils-2.19 version (it is first in the path). On the Solaris Platform it is common (and recommended) to set --with-gnu-as --with-as=binutils-as --without-gnu-ld --with-ld=/usr/ccs/bin/ld when compiling gcc -- since I had not set these configure options the later scripts tooks paths that are untested on this platform (and therefore failed). It would seem that this is a second bug; that the configure script does not have the same effect if it detects options automatically that it would have if the user manually set the configure option to the same value. I should not have to actually set configure options (to their automatically determined (default) value) in order that later scripts will work correctly. I have completed make install and now for a little testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38693
[Bug target/38706] [4.4 regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault
--- Comment #3 from arthur dot loiret at gmail dot com 2009-01-03 19:24 --- I tried again with trunk 143029, still on a clean build directory, and I get the same failure, even with --disable-bootstrap. Hardware is an 21264C (ev68cb), I'll try to make a reduced testcase and to build on an other machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38706
[Bug fortran/23169] INTENT information not used in the middle-end for optimizations
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-01-03 19:46 --- Maybe realted: PR29697?! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23169
[Bug target/27880] [4.2/4.3 regression] undefined reference to `_Unwind_GetIPInfo'
--- Comment #33 from rob1weld at aol dot com 2009-01-03 19:53 --- With gcc version 4.4.0 20090102 on i386-pc-solaris2.11 I'm getting: # gcc -v -o test_gmp_1 test_gmp_1.cc -lgmp -lstdc++ /usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/../../../libstdc++.so: undefined reference to `_unwind_getipi...@gcc_4.2.0' collect2: ld returned 1 exit status -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug bootstrap/38693] gcc 4.4.0 20090101 - gcc/config/i386/sol2-10.h uses USE_GAS which is undefined
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-01-03 19:54 --- And this is documented in the installation documentation. (Confusion may also result if the compiler finds the GNU assembler but has not been configured with --with-gnu-as.) http://gcc.gnu.org/install/configure.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38693
[Bug target/27880] [4.2/4.3 regression] undefined reference to `_Unwind_GetIPInfo'
--- Comment #34 from pinskia at gcc dot gnu dot org 2009-01-03 19:55 --- (In reply to comment #33) With gcc version 4.4.0 20090102 on i386-pc-solaris2.11 I'm getting: # gcc -v -o test_gmp_1 test_gmp_1.cc -lgmp -lstdc++ /usr/local/lib/gcc/i386-pc-solaris2.11/4.4.0/../../../libstdc++.so: undefined reference to `_unwind_getipi...@gcc_4.2.0' collect2: ld returned 1 exit status sounds like correct version of libgcc is not being so that is not a bug with GCC but with your installation of GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug fortran/30609] Calculating masks twice
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-01-03 20:04 --- I wouldn't expect this to be optimized as 'a0' creates temporary arrays in different contexts. The same call used twice, as in PR22572, seems to be more likely. WONTFIX? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30609
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #11 from dfranke at gcc dot gnu dot org 2009-01-03 20:28 --- PR27989 and PR30939 essentially describe the same problem, once with an implicit, once with an explicit interface. The explicit case is sort-of solved, the implicit case will be if we ever get whole-file checking. Do we need to keep both open? Can we merge them, close both and/or open a new one that clarifies what needs to be done? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug fortran/27766] [meta] -fbounds-check related bugs
--- Comment #12 from dfranke at gcc dot gnu dot org 2009-01-03 21:01 --- (In reply to comment #11) Count PR32317 in as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766
[Bug target/38707] [4.4 Regression] gcc.c-torture/execute/20050121-1.c ICEs with -march=pentium-m
--- Comment #7 from jakub at gcc dot gnu dot org 2009-01-03 21:12 --- Subject: Bug 38707 Author: jakub Date: Sat Jan 3 21:11:30 2009 New Revision: 143036 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143036 Log: PR target/38707 * expmed.c (store_bit_field_1): Don't modify op0 if movstrict insn can't be used. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38707
[Bug fortran/32707] Warn on mismatched character lengths in array
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-01-03 21:12 --- Fixed in trunk. Both testcases give: $ gfortran-svn pr32707.f90 pr32707.f90:5.12: xx = [boy,girl] 1 Error: Different CHARACTER lengths (3/4) in array constructor at (1) Testcases are already present in the testsuite. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail||4.3.2 Known to work||4.4.0 Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32707
[Bug fortran/32890] Compile-time detect of LHS/RHS missmatch for PACK
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-01-03 21:22 --- For constant arguments, the simplifier (which isn't implemented yet) should make detection possible. Blocking 29969 although no init expression is involved here. However, PACK is one of those functions that require a simplifier anyway. Btw, in the testcase, VAR is undefined. I assume VAR != 30 to trigger an error? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org OtherBugsDependingO||29962 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32890
[Bug target/38707] [4.4 Regression] gcc.c-torture/execute/20050121-1.c ICEs with -march=pentium-m
--- Comment #8 from jakub at gcc dot gnu dot org 2009-01-03 21:26 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38707
[Bug fortran/33097] Function decl trees without proper argument list
--- Comment #14 from dfranke at gcc dot gnu dot org 2009-01-03 21:26 --- For the interested reader, see another approach here: http://gcc.gnu.org/ml/fortran/2008-12/msg00306.html Instead of guessing the arguments, I fused existing decls with later interfaces. It generally workes, but the patch is a horrible hack (see thread for comments and a different approach). -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097
[Bug fortran/33341] array temporaries for array constructors (unnecessary stores)
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-01-03 21:39 --- Not specific to the ALL intrinsic. $ cat ctor.f90 INTEGER :: i, n, a(5) n = 5 a = (/ (i, i = 1, n) /) END $ gfortran-svn -Warray-temporaries ctor.f90 ctor.f90:3.9: a = (/ (i, i = 1, n) /) 1 Warning: Creating array temporary at (1) If N is not a variable, the simplifier takes over and no runtime construction of arrays is necessary. Not applicable example in #0, of course. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Summary|array temporaries for all |array temporaries for array |intrinsic (unnecessary |constructors (unnecessary |stores for array|stores) |constructor)| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33341
[Bug fortran/33408] ICE: tree check: expected type_decl, have in debug_flush_symbol_queue, at final.c:3986
--- Comment #17 from dfranke at gcc dot gnu dot org 2009-01-03 21:43 --- Closing as fixed as it wasn't reproduced since 10 months. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33408
[Bug fortran/34554] time compiling complicated size initialization expression
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-01-03 22:11 --- array.c (gfc_get_array_element) states: Access is not efficient at all, but this is another place where things do not have to be particularly fast. As get_array_element shows up in #2, this might be a place to start. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34554
[Bug fortran/34771] [4.3 only] Parenthesis around character variables: No expression
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-01-03 22:26 --- Ping? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34771
[Bug libstdc++/38678] [DR XXX] istream::read() calls streambuf::sgetn()
--- Comment #5 from paolo dot carlini at oracle dot com 2009-01-03 22:37 --- Changes reverted for now, consistently with the discussion: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg4.html Waiting for the resolution of a new DR (# to be added Summary). -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|istream::read() calls |[DR XXX] istream::read() |streambuf::sgetn() |calls streambuf::sgetn() http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38678
[Bug libstdc++/38678] [DR XXX] istream::read() calls streambuf::sgetn()
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|REOPENED|SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38678
[Bug fortran/35009] error on valid with -std=f95 (character arrays in format tags)
--- Comment #12 from dfranke at gcc dot gnu dot org 2009-01-03 22:38 --- Jerry, do you think we can (finally) commit/fix this? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org, jvdelisle at gcc dot ||gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35009
[Bug fortran/35015] missing cleanup-modules directive in testsuite/gfortran*
--- Comment #7 from dfranke at gcc dot gnu dot org 2009-01-03 22:48 --- (In reply to comment #4) Fair enough. We should thus apply the script to gcc/contrib/ (ok for adding it?) and consequently close this as fixed. thanks, Hasn't been added yet. I think it's still useful. Please add. Before closing, a note to the ML would be nice, so people know that it's available and how to use it - thanks! :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35015
[Bug fortran/38594] [4.4 Regression] module function name mangled improperly if contained function of same name exists
--- Comment #7 from pault at gcc dot gnu dot org 2009-01-03 22:58 --- Fixed on trunk. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38594
[Bug fortran/35161] Bind(C): Procedures with different interface and same C binding label
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-01-03 23:00 --- (In reply to comment #0) See also question posted at: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b1e8c8d0af9d16e8/ (when writing this, the question was not yet answered) Conclusion at c.l.f: the standard does not require the compiler to issue a message about names associated to BIND(C,name=...). However I like to see gfortran reporting that two C names coincide. Confirmed. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org OtherBugsDependingO||32630 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-03 23:00:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35161
[Bug fortran/38665] [4.4 Regression] ICE in check_host_association
--- Comment #5 from pault at gcc dot gnu dot org 2009-01-03 23:01 --- Mikael, Now the solutions: (1) Add some conditions to the if before to prevent executing this. (2) Remove the gfc_match_whatever that has nothing to do in resolve.c and find a better way (yes, I prefer (2), how did you guess?). Hum, maybe (1) is better for 4.4.0 Believe me, I looked for a better solution when I wrote this function! It is possible but seems to require more scans of the code tree than I liked - maybe this can be streamlined by marking candidate expressions In the mean time, I know how to apply a fix along the lines of 1. Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-29 22:10:15 |2009-01-03 23:01:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38665
[Bug fortran/36313] [F2003] {MIN,MAX}{LOC,VAL} should accept character arguments
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-01-03 23:02 --- Patch at http://gcc.gnu.org/ml/fortran/2009-01/msg00010.html impliments simplifiers for MINVAL/MAXVAL and character arguments. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36313
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-01-03 23:26 --- (In reply to comment #7) Good question. FX and Joe don't like the idea, but Fortran files (.h/.inc and .mod files one can find in /usr/include in some Linux distributions. Whoever requires .mod files probably has a Makefile around anyway - adding -I/usr/include is not exactly much to ask for. I also think we shouldn't search the system paths by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug c++/38472] [4.4 Regression] Wrong result type of ternary operator
--- Comment #3 from jason at gcc dot gnu dot org 2009-01-03 23:28 --- Yes, this is definitely related to that patch. The usual arithmetic conversions do not include promotions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38472
[Bug fortran/35849] wrong line shown in error message for parameter
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-01-03 23:33 --- Do you plan to commit this? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35849
[Bug fortran/35951] Unexpected erro Expected another dimension in array declaration
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-01-03 23:46 --- *** This bug has been marked as a duplicate of 31560 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35951
[Bug fortran/31560] improve error message for using components of later decl. variables in specification expressions
--- Comment #9 from dfranke at gcc dot gnu dot org 2009-01-03 23:46 --- *** Bug 35951 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||john dot young at jrc dot co ||dot jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31560
[Bug fortran/35732] -fbounds-check: LHS/RHS size mismatch: Misleading error message
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-01-03 23:52 --- *** Bug 36029 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35732
[Bug fortran/36029] Off-by-one runtime bounds checking message
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-01-03 23:52 --- *** This bug has been marked as a duplicate of 35732 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36029
[Bug fortran/36161] gfc_error formats are not marked gcc-internal-format in po file
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-01-03 23:58 --- No idea about translation, but PR38573 is surely related. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36161
[Bug fortran/38573] Missing markers for translation
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-01-03 23:58 --- Also translation related: PR36161. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573
[Bug fortran/36260] Audit intrinsic.texi and check whether keyword= names match
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-01-03 23:59 --- This is still an issue. Confirmed. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-03 23:59:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36260
[Bug fortran/36378] Support Fortran files with \r line breaks
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-01-04 00:04 --- Following Steve's suggestion. Closing as WONTFIX. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36378
[Bug fortran/29600] MINLOC, MAXLOC and SHAPE take an optional KIND argument
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-01-04 00:10 --- See also: PR36462. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29600
[Bug fortran/36462] KIND argument in INDEX results in wrong code
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-01-04 00:10 --- See also: PR29600. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||20585 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36462
[Bug fortran/36754] Compile-time bound-checking for allocatable arrays with known bonds
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-01-04 00:13 --- (In reply to comment #3) Let me recheck tomorrow. Found anything? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36754
[Bug middle-end/38584] [4.3/4.4 Regression] Inline heuristics run even at -O0
--- Comment #8 from steven at gcc dot gnu dot org 2009-01-04 00:15 --- Subject: Bug 38584 Author: steven Date: Sun Jan 4 00:15:08 2009 New Revision: 143040 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143040 Log: PR middle-end/38584 * cfgexpand.c (estimate_stack_frame_size): Simplify the estimate: Calculate the size of all stack vars assuming no packing of stack vars will happen, replacing a quadratic algorithm with a linear one. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38584
[Bug middle-end/38586] quadratic behaviour in find_temp_slot_from_address.
--- Comment #3 from steven at gcc dot gnu dot org 2009-01-04 00:16 --- Subject: Bug 38586 Author: steven Date: Sun Jan 4 00:15:58 2009 New Revision: 143041 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143041 Log: PR middle-end/38586 * function.c (struct temp_slot): Move to the section of the file that deals with temp slots. Remove field 'address'. (temp_slot_address_table): New hash table of address - temp slot. (struct temp_slot_address_entry): New struct, items for the table. (temp_slot_address_compute_hash, temp_slot_address_hash, temp_slot_address_eq, insert_temp_slot_address): Support functions for the new table. (find_temp_slot_from_address): Rewrite to use the new hash table. (remove_unused_temp_slot_addresses): Remove addresses of temp slots that have been made available. (remove_unused_temp_slot_addresses_1): Call-back for htab_traverse, worker function for remove_unused_temp_slot_addresses. (assign_stack_temp_for_type): Don't clear the temp slot address list. Add the temp slot address to the address - temp slot map. (update_temp_slot_address): Update via insert_temp_slot_address. (free_temp_slots): Call remove_unused_temp_slot_addresses. (pop_temp_slots): Likewise. (init_temp_slots): Allocate the address - temp slot map, or empty the map if it is already allocated. (prepare_function_start): Initialize temp slot processing. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38586
[Bug middle-end/38586] quadratic behaviour in find_temp_slot_from_address.
--- Comment #4 from steven at gcc dot gnu dot org 2009-01-04 00:17 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38586
[Bug middle-end/38584] [4.3/4.4 Regression] Inline heuristics run even at -O0
--- Comment #9 from steven at gcc dot gnu dot org 2009-01-04 00:17 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38584
[Bug fortran/33341] array temporaries for array constructors (unnecessary stores)
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-01-04 00:20 --- *** Bug 36935 has been marked as a duplicate of this bug. *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33341
[Bug fortran/36935] unneeded temporary for array constructor
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-01-04 00:20 --- *** This bug has been marked as a duplicate of 33341 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36935
[Bug fortran/38115] unneeded temp
--- Comment #5 from dfranke at gcc dot gnu dot org 2009-01-04 00:22 --- PR33341 belongs here as well. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38115
[Bug fortran/37605] Remarks on user manual for Gfortran
--- Comment #9 from dfranke at gcc dot gnu dot org 2009-01-04 00:29 --- Anything left here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37605
[Bug fortran/36854] [meta] fortran front-end optimization
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-01-04 00:40 --- Among the unneeded temporaries, the array constructor (e.g. PR33341) is the most annoying, i.e. the most often reported, one. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org BugsThisDependsOn||34706 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36854
[Bug fortran/38669] [4.3/4.4 Regression] Array bounds violation for arguments of elemental subroutine
--- Comment #6 from mikael at gcc dot gnu dot org 2009-01-04 00:40 --- (In reply to comment #5) (In reply to comment #4) Created an attachment (id=17016) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17016action=view) [edit] fix Does anyone know the use of the block variable I remove in this patch? Yes indeed. When I wrote this function, this block of code needed to be merged as the comments says: /* Generate the temporary. Merge the block so that the declarations are put at the right binding level. */ The second sentence needs to go in your patch:-) What I have no recall of is why the block had to be merged. I believe that it was conditional on the intent of the argument. That's not what I was asking, sorry. I'll try to be clearer. The block variable seems to hold nothing. 271gfc_start_block (block); 272tmp = gfc_typenode_for_spec (e-ts); 273tmp = gfc_trans_create_temp_array (se-pre, se-post, 274 tmp_loop, info, tmp, 275 false, true, false); 276gfc_add_modify_expr (se-pre, size, tmp); 277tmp = fold_convert (pvoid_type_node, info-data); 278gfc_add_modify_expr (se-pre, data, tmp); 279gfc_merge_block_scope (block); The above is your initial commit. As gfc_trans_create_temp_array is putting his code in se-pre and se-post, it looks like no code goes to the block variable which is useless then. Or do I miss something? This is largely off-topic though. It is just something I wondered when I looked at the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38669
[Bug fortran/38247] problem with contained subprocedure.
--- Comment #9 from dfranke at gcc dot gnu dot org 2009-01-04 00:43 --- (In reply to comment #8) Try to make sure that the testcases you attach reproduce the problem, by testing your testcase ;-) Marked as waiting for a testcase. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38247
[Bug fortran/38386] Update BIND(C,name= checking for Fortran 2008
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-01-04 00:48 --- See also PR35161. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org OtherBugsDependingO||32630 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38386
[Bug fortran/35161] Bind(C): Procedures with different interface and same C binding label
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-01-04 00:48 --- See also: PR38386. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35161
[Bug fortran/38665] [4.4 Regression] ICE in check_host_association
--- Comment #6 from mikael at gcc dot gnu dot org 2009-01-04 01:02 --- (In reply to comment #5) Mikael, Now the solutions: (1) Add some conditions to the if before to prevent executing this. (2) Remove the gfc_match_whatever that has nothing to do in resolve.c and find a better way (yes, I prefer (2), how did you guess?). Hum, maybe (1) is better for 4.4.0 Believe me, I looked for a better solution when I wrote this function! Well, I didn't think much about it. It's probably the easiest, but I don't like those hacks which are likely to pop up again later. Anyway, I can't blame you for finding a fix for a bug. In the mean time, I know how to apply a fix along the lines of 1. Ok, then; go for (1). I have nothing to propose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38665
[Bug tree-optimization/37692] [alias-improvements-branch] can't alias fortran function arguments
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-01-04 01:23 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37692
[Bug tree-optimization/37699] [alias-improvements-branch] can't alias ptr and local array
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-01-04 01:23 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37699
[Bug target/38706] [4.4 regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault
--- Comment #4 from arthur dot loiret at gmail dot com 2009-01-04 03:49 --- Created an attachment (id=17027) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17027action=view) reduced testcase Here is a first reduced testcase, with it I get: $ ./gcc/cc1plus -quiet /tmp/bug.cc /tmp/bug.cc: In member function 'void std::basic_istreamchar, std::char_traitschar ::_ZTv0_n24_NSiD1Ev()': /tmp/bug.cc:97: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (gdb) run -quiet /tmp/bug.cc Starting program: /home/arthur/build/gcc/cc1plus -quiet /tmp/bug.cc Program received signal SIGSEGV, Segmentation fault. alpha_end_function (file=0x120b962c0, fnname=0x2c74e80 _ZTv0_n24_NSiD1Ev, decl=value optimized out) at ../../src/gcc/config/alpha/alpha.c:8270 8270 if (!INSN_P (insn)) (gdb) bt #0 alpha_end_function (file=0x120b962c0, fnname=0x2c74e80 _ZTv0_n24_NSiD1Ev, decl=value optimized out) at ../../src/gcc/config/alpha/alpha.c:8270 #1 0x0001207ba400 in assemble_end_function (decl=0x2c67a00, fnname=0x2c74e80 _ZTv0_n24_NSiD1Ev) at ../../src/gcc/varasm.c:1775 #2 0x000120155584 in use_thunk (thunk_fndecl=0x2c67a00, emit_p=value optimized out) at ../../src/gcc/cp/method.c:445 #3 0x000120162990 in emit_associated_thunks (fn=value optimized out) at ../../src/gcc/cp/semantics.c:3144 #4 0x0001207e4fdc in cgraph_expand_function (node=0x2c8c800) at ../../src/gcc/cgraphunit.c:1046 #5 0x0001207e5338 in cgraph_output_in_order () at ../../src/gcc/cgraphunit.c:1195 #6 0x0001207e7d60 in cgraph_optimize () at ../../src/gcc/cgraphunit.c:1306 #7 0x0001200d57e4 in cp_write_global_declarations () at ../../src/gcc/cp/decl2.c:3630 #8 0x00012059d61c in toplev_main (argc=value optimized out, argv=value optimized out) at ../../src/gcc/toplev.c:981 #9 0x00012022b8e8 in main (argc=549020352, argv=0x2c74e80) at ../../src/gcc/main.c:35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38706
[Bug target/38706] [4.4 regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault
--- Comment #5 from arthur dot loiret at gmail dot com 2009-01-04 04:16 --- Created an attachment (id=17028) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17028action=view) more reduced testcase -- arthur dot loiret at gmail dot com changed: What|Removed |Added Attachment #17027|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38706
[Bug tree-optimization/31130] [4.2/4.3/4.4 Regression] VRP no longer derives range for division after negation
--- Comment #16 from ian at airs dot com 2009-01-04 04:21 --- I'm not working on this, sorry. -- ian at airs dot com changed: What|Removed |Added AssignedTo|ian at airs dot com |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31130
[Bug fortran/35009] error on valid with -std=f95 (character arrays in format tags)
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-01-04 06:08 --- hmm, forgot all about this. I will apply the patch, retest, and commit if OK -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35009
