[Bug tree-optimization/28187] [4.1/4.2 Regression] '-O2 -fwrapv' exhausts memory.
--- Comment #8 from patchapp at dberlin dot org 2006-07-06 06:45 --- Subject: Bug number PR28187 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/2006-07/msg00195.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28187
[Bug c++/28279] New: [4.2 Regression] ICE in finish_static_data_member_decl, at cp/decl2.c:716
trunk fails to build boost with
/space/rguenther/src/c++bench/html/sandbox/boost_1_33_1/boost/type_traits/is_pointer.hpp:68:
internal compiler error: in finish_static_data_member_decl, at cp/decl2.c:716
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
reduced testcase:
templatetypename T
struct is_pointer_impl {
static const bool value = true;
};
namespace {
class prefix_name_mapper {};
}
static const bool val = is_pointer_implprefix_name_mapper::value;
the anonymous namespace is critical.
--
Summary: [4.2 Regression] ICE in finish_static_data_member_decl,
at cp/decl2.c:716
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28279
[Bug c++/28279] [4.2 Regression] ICE in finish_static_data_member_decl, at cp/decl2.c:716
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28279
[Bug c++/28279] [4.2 Regression] ICE in finish_static_data_member_decl, at cp/decl2.c:716
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-07-06 07:32 --- Jason, it looks like you caused this... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28279
[Bug target/26949] [4.2 regression] worse code generated for -march=pentium4
--- Comment #1 from uros at kss-loka dot si 2006-07-06 08:23 --- This problem appears to be fixed in gcc version 4.2.0 20060705 (experimental). The generated asm for the loop is now: -O2 -march=pentium4 -fno-tree-ch: jmp .L2 .L3: movl%esi, -4(%edx) addl$1, %eax .L2: addl$4, %edx cmpl%ecx, %eax jle .L3 -O2 -march=i686 -fno-tree-ch: jmp .L2 .p2align 4,,7 .L3: movl%ebx, -4(%ecx) addl$1, %edx .L2: addl$4, %ecx cmpl%eax, %edx jle .L3 Closing the bug as FIXED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26949
[Bug target/26949] [4.2 regression] worse code generated for -march=pentium4
--- Comment #2 from uros at kss-loka dot si 2006-07-06 08:24 --- Closing it for real... -- uros at kss-loka dot si changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26949
[Bug fortran/28276] EXPONENT() broken for real constants
-- steven at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28276
[Bug middle-end/28252] pow(x,1/3.0) should be converted to cbrt(x)
--- Comment #3 from steven at gcc dot gnu dot org 2006-07-06 08:57 --- Uros, You could post it now, just so that people can have a look at it and maybe suggest some changes. You know how that goes. It would be interesting to see if this actually gives speedups... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28252
[Bug debug/28280] New: [4.2 regression] bogus statement with no effect warning
gcc 4.2 shows the following bogus warning message. I'm not sure whether this
is a regression or a new warning but it would be great if this could be
improved. The warning shows up in elfutils, the minimal testcase was extracted
by Eugeniy Meshcheryakov.
41714:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -W -Wall test.c
test.c: In function 'fun':
test.c:9: warning: statement with no effect
41715:[EMAIL PROTECTED]: ~] gcc-4.1 -c -W -Wall test.c
41716:[EMAIL PROTECTED]: ~] cat test.c
#include inttypes.h
void * fun(char *desc, int descsz)
{
struct
{
uint32_t os;
uint32_t version[descsz / 4 - 1];
} *tag = (__typeof (tag)) desc;
return tag;
}
--
Summary: [4.2 regression] bogus statement with no effect
warning
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28280
[Bug c/28281] New: gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode
Userspace and kernel space use a different segment register for TLS access in x86_64. (This is so that a syscall doesn't need to switch these registers most of the time, so good for performance) This means that the kernel cannot use -fstack-protector currently, which is sad since today another buffer overflow has been found in the linux kernel. The solution is quite simple, and I will attach a patch to fix this next; just use a different segement register for the mc_kernel model. (the patch is trivial; it copies a line and changes a few characters in it, and then places an if around it) -- Summary: gcc uses the wrong segment register for TLS access for - fstack-protector in kernel mode Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: arjan at linux dot intel dot com GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28281
[Bug c/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode
--- Comment #1 from arjan at linux dot intel dot com 2006-07-06 09:24 --- Created an attachment (id=11839) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11839action=view) patch to fix this issue, including a testcase patch + testcase for this issue 2006-07-06 Arjan van de Ven [EMAIL PROTECTED] * config/i386/i386.md: add conditonal for kernel side stack-protector -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28281
[Bug rtl-optimization/28282] New: Attempt to delete prologue/epilogue insn, again
In a bit of code with an out-of-bounds array access, the following ICN is
triggered:
$ gcc -c -O1 bug.c
bug.c: In function âfuncâ:
bug.c:12: error: Attempt to delete prologue/epilogue insn:
(insn/f 64 63 65 0 (set (mem:SI (plus:SI (reg/f:SI 6 bp)
(const_int -8 [0xfff8])) [0 S4 A8])
(reg:SI 3 bx)) -1 (nil)
(nil))
bug.c:12: internal compiler error: in propagate_one_insn, at flow.c:1699
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
Preprocessed source stored into /tmp/ccEvY67W.out file, please attach this to
your bugreport.
This appears to be different from bug 26945 as the test case attached to it
does not trigger any error on my machine.
The test case is as follows:
int global;
int func(int argc) {
int* array[1];
array[1] = global; /* out of bounds, of course */
if (something(array, argc))
otherfunc(array);
if (argc != 17)
return 17;
}
$ /usr/bin/gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,fortran,objc,obj-c++,ada,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-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --enable-mpfr
--with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060630 (prerelease) (Debian 4.1.1-6)
--
Summary: Attempt to delete prologue/epilogue insn, again
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ted at midg3t dot net
GCC build triplet: gcc version 4.1.2 20060630 (prerelease) (Debian 4.1.1-6)
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28282
[Bug rtl-optimization/28282] Attempt to delete prologue/epilogue insn, again
--- Comment #1 from ted at midg3t dot net 2006-07-06 09:29 --- Created an attachment (id=11840) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11840action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28282
[Bug rtl-optimization/28282] Attempt to delete prologue/epilogue insn, again
--- Comment #2 from ted at midg3t dot net 2006-07-06 09:29 --- Created an attachment (id=11841) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11841action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28282
[Bug rtl-optimization/28282] Attempt to delete prologue/epilogue insn, again
--- Comment #3 from ted at midg3t dot net 2006-07-06 09:35 --- For clarity, when not run via ccache the first line of the preprocessed source output is: // /usr/lib/gcc/i486-linux-gnu/4.1.2/cc1 -quiet bug.c -quiet -dumpbase bug.c -mtune=i686 -auxbase bug -O1 -o - -frandom-seed=0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28282
[Bug rtl-optimization/26945] [4.0/4.1 regression] Attempt to delete prologue/epilogue insn
--- Comment #4 from ted at midg3t dot net 2006-07-06 09:38 --- I came across a similar error, but because the test case attached to this report did not trigger on my machine I filed a separate report, bug #28282. It looks like it's probably related. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26945
[Bug c/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode
--- Comment #2 from arjan at linux dot intel dot com 2006-07-06 09:49 --- Created an attachment (id=11842) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11842action=view) updated patch updated patch; it helps if I send the non-test version of the testsuite test so that it actually tests the right behavior -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28281
[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-07-06 10:01 ---
Created an attachment (id=11843)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11843action=view)
testcase
reduced C++ testcase attached. C testcase:
void foo(void)
{
int value47D2367, valueD2287;
unsigned int jD2283;
value47D2367 = x-x;
jD2283 = 0;
L0:
if (value47D2367 0) goto L3; else goto L17;
L17:
valueD2287 = value47D2367;
L2:
valueD2287 = valueD2287 + 2147483647;
if (valueD2287 0) goto L3; else goto L2;
L3:
jD2283 = jD2283 + 1;
if (jD2283 != 607) goto L0; else goto L6;
L6:
return;
}
gcc ./cc1 -O2 -quiet t.i
t.i: In function 'foo':
t.i:26: error: NOTE_INSN_BASIC_BLOCK is missing for block 8
t.i:26: error: NOTE_INSN_BASIC_BLOCK 92 in middle of basic block 8
t.i:26: error: too many outgoing branch edges from bb 2
t.i:26: internal compiler error: verify_flow_info failed
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28221
[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-06 10:02 --- So, confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-06 10:02:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28221
[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-07-06 10:07 --- The reduced testcases are with checking only. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-checking http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28221
[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-06 10:10 --- ICE is after rtl loop2 optimizer, looks like it requires a doloop target. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28221
[Bug rtl-optimization/28221] [4.1 regression] ICE in add_insn_before, at emit-rtl.c:3479
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-07-06 10:11 --- Really looks like a dup of PR27291, but the patch for that doesn't apply to the 4.1 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28221
[Bug middle-end/28268] [4.2 regression] ICE with simple vector operations
--- Comment #2 from patchapp at dberlin dot org 2006-07-06 10:20 --- Subject: Bug number PR28268 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/2006-07/msg00203.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28268
[Bug tree-optimization/28238] [4.1/4.2 regression] verify_stmts failed (invalid operand to unary operator)
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-06 10:55 --- 4.1.2 also fails. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.2.0 |4.2.0 4.1.2 Summary|[4.2 regression]|[4.1/4.2 regression] |verify_stmts failed (invalid|verify_stmts failed (invalid |operand to unary operator) |operand to unary operator) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28238
[Bug c/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode
--- Comment #3 from arjan at linux dot intel dot com 2006-07-06 11:08 --- Created an attachment (id=11844) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11844action=view) updates with Jakub's comments updates with jakubs comments -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28281
[Bug java/28153] Under Windows Xp the generated JNI headers need to have a '_' prepended for each function.
--- Comment #7 from bcmpinc at hotmail dot com 2006-07-06 12:37 --- extern JNIEXPORT void JNICALL Java_JavaSide_sayHello (JNIEnv *env, jobject); After preprossesing this becomes: __attribute__((dllexport)) void __attribute__((__stdcall__)) Java_sample_myNative (JNIEnv *, jobject, jstring); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28153
[Bug tree-optimization/28238] [4.1/4.2 regression] verify_stmts failed (invalid operand to unary operator)
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-07-06 12:38 --- I have a fix. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-07-03 23:16:00 |2006-07-06 12:38:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28238
[Bug fortran/28237] print call()
-- 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28237
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #10 from bergner at vnet dot ibm dot com 2006-07-06 14:32 --- I used Alan's code changes from comments #8 and #9 on the 4.1 branch and it bootstrapped and regression tested (32-bit and 64-bit) fine. Mainline bootstraps and regression tests are still running. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #11 from dje at gcc dot gnu dot org 2006-07-06 14:37 --- The original code could not be totally broken unless Alan's code also is totally broken because he computes many of the same tests. Also, Alan does not include an important test from the original code, so his code is wrong. I am testing a variant of the original code that includes some of Alan's simplifications. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug c/28280] [4.2 regression] bogus statement with no effect warning
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-06 14:51 --- This is not a debug issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC|fche at redhat dot com, | |jakub at redhat dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28280
[Bug target/28281] gcc uses the wrong segment register for TLS access for -fstack-protector in kernel mode
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28281
[Bug tree-optimization/28238] [4.1/4.2 regression] verify_stmts failed (invalid operand to unary operator)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28238
[Bug tree-optimization/28238] [4.1/4.2 regression] verify_stmts failed (invalid operand to unary operator)
--- Comment #8 from patchapp at dberlin dot org 2006-07-06 14:55 --- Subject: Bug number PR28238 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/2006-07/msg00226.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28238
[Bug c/28280] [4.2 regression] bogus statement with no effect warning with VLA and typeof
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-06 15:12 ---
We are warning inside the typeof.
Here is a shorter testcase:
void f(__SIZE_TYPE__ d)
{
typedef int t[d];
t *g = (__typeof(g))d;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||diagnostic
Summary|[4.2 regression] bogus |[4.2 regression] bogus
|statement with no effect |statement with no effect
|warning |warning with VLA and typeof
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28280
[Bug c/28280] [4.2 regression] bogus statement with no effect warning with VLA and typeof
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-07-06 15:13 --- Most likely caused by: 2006-05-18 Mike Stump [EMAIL PROTECTED] Fix up vla, vm and [*] sematics. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||mrs at apple dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-06 15:13:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28280
[Bug c++/26905] default-visibility class symbol improperly resolved as hidden-visibility
--- Comment #6 from jason at gcc dot gnu dot org 2006-07-06 15:21 --- I'm afraid it's too large a patch to go into the FSF 4.0/1 branches, though Red Hat will apply include it in our 4.1 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26905
[Bug c++/28279] [4.2 Regression] ICE in finish_static_data_member_decl, at cp/decl2.c:716
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-06 15:22:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28279
[Bug target/27991] [4.2 regression] ICE in reload_cse_simplify_operands
--- Comment #3 from pbrook at gcc dot gnu dot org 2006-07-06 15:26 --- It looks like this is a latent bug. My patch allows negxf to operate on integer registers (previously it was only implemented on FP regs). This causes the register allocator to make different register choices, and reload falls over. -- pbrook at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-06 15:26:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27991
[Bug rtl-optimization/28283] New: SuperH: Very unoptimal code generated for 64-bit ints
NetBSD has recently imported gcc 4.1.2 prerelease. I've noticed that
for sh3 there's a serious degradation in the quality of the generated
code for long long handling.
While generally the generated code is more compact, as soon as 64-bit
ints come into play, the size increases, e.g. softfloat.o explodes
from 10K to 28K just to pick one of the worst cases from our libc.
The worst case was actually bswap64 - by an oversight libc used C
version instead of hand-written asm version and it grew from a few
instructions to 100+ instructions.
A minimal self-contained test case (extracted from bswap64) that
demonstrates this is:
unsigned long long int
expand64(unsigned int x)
{
return (unsigned long long int)x 32;
}
Compiling with -O2 -fomit-frame-pointer I get:
* gcc3
shle--netbsdelf-gcc (GCC) 3.3.6 (NetBSD nb1 20060605)
expand64:
mov r4,r5
mov #0,r4
mov r4,r0
rts
mov r5,r1
* gcc4
shle--netbsdelf-gcc (GCC) 4.1.2 20060628 (prerelease) (NetBSD nb1 20060602)
expand64:
mov #0,r5
mov r4,r1
clrt
addcr4,r1
mov r5,r2
addcr5,r2
mov r1,r3
clrt
addcr1,r3
mov r2,r4
addcr2,r4
clrt
addcr3,r3
addcr4,r4
...
/* crlt/addc/addc sequence repeated total of 32 times */
...
mov r3,r0
rts
mov r4,r1
--
Summary: SuperH: Very unoptimal code generated for 64-bit ints
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uwe at netbsd dot org
GCC build triplet: i386--netbsdelf
GCC host triplet: i386--netbsdelf
GCC target triplet: shle--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283
[Bug fortran/28167] ICE: in fold_binary, at fold-const.c:8239 (temporary character array?)
--- Comment #7 from pault at gcc dot gnu dot org 2006-07-06 15:35 --- Subject: Bug 28167 Author: pault Date: Thu Jul 6 15:35:24 2006 New Revision: 115222 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115222 Log: 2006-07-06 Paul Thomas [EMAIL PROTECTED] PR fortran/28174 * trans-array.c (gfc_conv_expr_descriptor): When building temp, ensure that the substring reference uses a new charlen. * trans-expr.c (gfc_conv_aliased_arg): Add the formal intent to the argument list, lift the treatment of missing string lengths from the above and implement the use of the intent. (gfc_conv_function_call): Add the extra argument to the call to the above. PR fortran/28167 * trans-array.c (get_array_ctor_var_strlen): Treat a constant substring reference. * array.c (gfc_resolve_character_array_constructor): Remove static attribute and add the gfc_ prefix, make use of element charlens for the expression and pick up constant string lengths for expressions that are not themselves constant. * gfortran.h : resolve_character_array_constructor prototype added. * resolve.c (gfc_resolve_expr): Call resolve_character_array_ constructor again after expanding the constructor, to ensure that the character length is passed to the expression. 2006-07-06 Paul Thomas [EMAIL PROTECTED] PR fortran/28174 * gfortran.dg/actual_array_substr_2.f90: New test. PR fortran/28167 * gfortran.dg/actual_array_constructor_2.f90: New test. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/array.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28167
[Bug fortran/28174] Corruption of multiple character arrays when passing array sections
--- Comment #7 from pault at gcc dot gnu dot org 2006-07-06 15:35 --- Subject: Bug 28174 Author: pault Date: Thu Jul 6 15:35:24 2006 New Revision: 115222 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115222 Log: 2006-07-06 Paul Thomas [EMAIL PROTECTED] PR fortran/28174 * trans-array.c (gfc_conv_expr_descriptor): When building temp, ensure that the substring reference uses a new charlen. * trans-expr.c (gfc_conv_aliased_arg): Add the formal intent to the argument list, lift the treatment of missing string lengths from the above and implement the use of the intent. (gfc_conv_function_call): Add the extra argument to the call to the above. PR fortran/28167 * trans-array.c (get_array_ctor_var_strlen): Treat a constant substring reference. * array.c (gfc_resolve_character_array_constructor): Remove static attribute and add the gfc_ prefix, make use of element charlens for the expression and pick up constant string lengths for expressions that are not themselves constant. * gfortran.h : resolve_character_array_constructor prototype added. * resolve.c (gfc_resolve_expr): Call resolve_character_array_ constructor again after expanding the constructor, to ensure that the character length is passed to the expression. 2006-07-06 Paul Thomas [EMAIL PROTECTED] PR fortran/28174 * gfortran.dg/actual_array_substr_2.f90: New test. PR fortran/28167 * gfortran.dg/actual_array_constructor_2.f90: New test. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/array.c branches/gcc-4_1-branch/gcc/fortran/gfortran.h branches/gcc-4_1-branch/gcc/fortran/resolve.c branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/fortran/trans-expr.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28174
[Bug fortran/28174] Corruption of multiple character arrays when passing array sections
--- Comment #8 from pault at gcc dot gnu dot org 2006-07-06 15:37 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28174
[Bug fortran/28167] ICE: in fold_binary, at fold-const.c:8239 (temporary character array?)
--- Comment #8 from pault at gcc dot gnu dot org 2006-07-06 15:38 --- Fixed on trunk and 4.1 Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28167
[Bug target/28126] gcc moves an expensive instruction outside of a conditional
--- Comment #3 from anemo at mba dot ocn dot ne dot jp 2006-07-06 16:20 --- Subject: Re: gcc moves an expensive instruction outside of a conditional One note: I think rdhwr $v1, $29 should not be placed in delay slot anyway. The instruction always generate an exception, so if it was in delay slot the kernel must calculate the target address of the preceding branch/jump instruction. Is it OK to add (set_attr can_delay no) for tls_get_tp_mode definition? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126
[Bug fortran/28237] print call()
--- Comment #4 from patchapp at dberlin dot org 2006-07-06 16:20 --- Subject: Bug number PR28237 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/2006-07/msg00245.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28237
[Bug c++/28284] New: [4.2 regression] ICE with invalid static const variable
The following invalid code snippet triggers an ICE on mainline:
=
templateint struct A
{
static const int i=x, j, k;
};
templateint N const int AN::j = i;
templateint N const int AN::k = j;
A0 a;
=
bug.cc:3: error: 'x' was not declared in this scope
bug.cc:7: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.2 regression] ICE with invalid static const variable
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28284
[Bug c++/28284] [4.2 regression] ICE with invalid static const variable
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28284
[Bug target/28285] New: [4.2 Regression] duplicate case value in alpha_swapped_comparison operator
Bootstrapping current mainline on Tru64 UNIX fails in stage1 as of 20060705: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I/vol/gcc/src/gcc/gcc -I/vol/gcc/src/gcc/gcc/. -I/vol/gcc/src/gcc/gcc/../include -I/vol/gcc/src/gcc/gcc/../libcpp/include -I/vol/gnu/obj/gmp-4.1.3/mpfr -I/vol/gnu/obj/gmp-4.1.3 -I/vol/gcc/src/gcc/gcc/../libdecnumber -I../libdecnumberinsn-preds.c -o insn-preds.o /vol/gcc/src/gcc/gcc/config/alpha/predicates.md: In function `alpha_swapped_comparison_operator': /vol/gcc/src/gcc/gcc/config/alpha/predicates.md:571: error: duplicate case value /vol/gcc/src/gcc/gcc/config/alpha/predicates.md:570: error: previously used here make[3]: *** [insn-preds.o] Error 1 Inspecting the generated insn-preds.c (alpha_swapped_comparison_operator), there are indeed two case GTU entries. Environment: System: OSF1 bartok V5.1 2650 alpha Machine: alpha host: alpha-dec-osf5.1b build: alpha-dec-osf5.1b target: alpha-dec-osf5.1b configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 --with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr --enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap How-To-Repeat: Bootstrap mainline as above. -- Summary: [4.2 Regression] duplicate case value in alpha_swapped_comparison operator Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28285
[Bug c/28286] New: [4.0/4.1/4.2 regression] ICE with invalid value in #pragma pack
The following invalid code snippet triggers an ICE since GCC 3.3: = #pragma pack(0..) = bug.c:1:14: error: too many decimal points in number bug.c:1: internal compiler error: tree check: expected integer_cst, have error_mark in handle_pragma_pack, at c-pragma.c:163 Please submit a full bug report, [etc.] This happens with the C and C++ frontend. -- Summary: [4.0/4.1/4.2 regression] ICE with invalid value in #pragma pack Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28286
[Bug c/28286] [4.0/4.1/4.2 regression] ICE with invalid value in #pragma pack
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28286
[Bug c/28287] New: [4.1/4.2 regression] ICE with misplaced attribute weak
The following invalid code snippet triggers an ICE since GCC 4.1.0:
=
void foo(int __attribute__((weak)));
=
bug.c:1: error: weak declaration of '({anonymous})' must be public
bug.c:1: internal compiler error: tree check: expected tree that contains 'decl
with visibility' structure, have 'parm_decl' in mark_weak, at varasm.c:4506
Please submit a full bug report, [etc.]
This happens with the C and C++ frontend.
--
Summary: [4.1/4.2 regression] ICE with misplaced attribute weak
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28287
[Bug c/28287] [4.1/4.2 regression] ICE with misplaced attribute weak
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28287
[Bug fortran/28176] FAIL: gfortran.dg/actual_array_constructor_1.f90 -O0 (ICE)
--- Comment #3 from danglin at gcc dot gnu dot org 2006-07-06 16:49 --- There seem to be more files now but they might be new tests. See http://gcc.gnu.org/ml/gcc-testresults/2006-04/msg00445.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28176
[Bug c++/28288] New: [4.0/4.1/4.2 regression] ICE with min/max operator
The following invalid code snippet triggers an ICE since GCC 4.0.0:
=
void foo(int i)
{
(i++ ? i) ++;
}
=
bug.cc: In function 'void foo(int)':
bug.cc:3: warning: minimum/maximum operators are deprecated
bug.cc:3: internal compiler error: in rationalize_conditional_expr, at
cp/typeck.c:1653
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] ICE with min/max operator
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28288
[Bug c++/28288] [4.0/4.1/4.2 regression] ICE with min/max operator
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28288
[Bug c++/28236] wrong control reaches warning with enums.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-06 16:55 --- Values in enums that are out of range are undefined in C++ (while defined in C). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-07-06 16:55:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28236
[Bug c++/28288] [4.0/4.1/4.2 regression] ICE with min/max operator
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-06 16:57 --- This is why they are deprecated :). Anyways this is PR 14556 is the PR about removing them, I don't know why they have not been removed yet. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||14556 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28288
[Bug fortran/27874] Bad interaction between bounds checking, forall and derived types
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-07-06 17:12 --- Subject: Bug 27874 Author: fxcoudert Date: Thu Jul 6 17:12:25 2006 New Revision: 115224 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115224 Log: PR fortran/27874 * trans-stmt.c (compute_inner_temp_size): Don't perform bounds checking when calculating the bounds of scalarization. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27874
[Bug target/28285] [4.2 Regression] duplicate case value in alpha_swapped_comparison operator
--- Comment #1 from ro at gcc dot gnu dot org 2006-07-06 17:16 --- Subject: Bug 28285 Author: ro Date: Thu Jul 6 17:16:48 2006 New Revision: 115225 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115225 Log: PR target/28285 * config/alpha/predicates.md (alpha_swapped_comparison_operator): Remove duplicate gtu. Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28285
[Bug target/28285] [4.2 Regression] duplicate case value in alpha_swapped_comparison operator
--- Comment #2 from ro at gcc dot gnu dot org 2006-07-06 17:18 --- Fixed for 4.2.0. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28285
[Bug c/28289] New: composite_types called to do two different things
composite_types is called in c-decl.c to merge function declarations, but in c-typeck.c to merge the types of two arms of a COND_EXPR. The former should result in a union of traits of the inputs, which composite_types computes, but the latter should give the intersection of traits unless the C standard says otherwise. In particular, when TREE_READONLY is set for a function type, that means that this function has no side effect, i.e. it is pure. When a cond expression yields a function type, it is pure only if both functions are pure. When a call is made through a COND_EXPR which is improperly marked as yielding a pure function pointer, and the result is ignored, the actual function call is not emitted. Likewise, when we merge the type of a function with a noreturn attribute with the type of a function without that attribute, merging the types for a COND_EXPR should yield a function type without this attribute. -- Summary: composite_types called to do two different things Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28289
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #12 from bergner at vnet dot ibm dot com 2006-07-06 18:00 --- Mainline with Alan's changed bootstrapped, but showed a few regressions. David's suggested fix from comment #7 (using mainline) bootstrapped and is currently in the middle of running the test suite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug target/27922] final link failed: Nonrepresentable section on output
--- Comment #2 from kristoffer_e1 at hotmail dot com 2006-07-06 18:34 --- Created an attachment (id=11846) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11846action=view) Log of osb-jscore build -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27922
[Bug c++/28279] [4.2 Regression] ICE in finish_static_data_member_decl, at cp/decl2.c:716
--- Comment #2 from jason at gcc dot gnu dot org 2006-07-06 18:39 --- Subject: Bug 28279 Author: jason Date: Thu Jul 6 18:39:39 2006 New Revision: 115228 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115228 Log: PR c++/28279 * decl2.c (finish_static_data_member_decl): Don't assert TREE_PUBLIC. Added: trunk/gcc/testsuite/g++.dg/template/anon2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28279
[Bug target/28170] [4.1/4.2 Regression] Wrong result after swap byte in one word when compiled in 64-bit mode
--- Comment #13 from dje at gcc dot gnu dot org 2006-07-06 19:00 ---
Subject: Bug 28170
Author: dje
Date: Thu Jul 6 18:59:58 2006
New Revision: 115229
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115229
Log:
2006-07-06 David Edelsohn [EMAIL PROTECTED]
PR target/28150
* config/rs6000/rs6000.c (rs6000_legitimate_address): Do not allow
PRE_{INC,DEC} of TFmode.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
Alan Modra [EMAIL PROTECTED]
PR target/28170
* config/rs6000/rs6000.c (insvdi_rshift_rlwimi_p): Correct shiftop
bounds. Simplify.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
[Bug target/28150] ICE in reload_cse_simplify_operands, at postreload.c:394
--- Comment #8 from dje at gcc dot gnu dot org 2006-07-06 19:00 ---
Subject: Bug 28150
Author: dje
Date: Thu Jul 6 18:59:58 2006
New Revision: 115229
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115229
Log:
2006-07-06 David Edelsohn [EMAIL PROTECTED]
PR target/28150
* config/rs6000/rs6000.c (rs6000_legitimate_address): Do not allow
PRE_{INC,DEC} of TFmode.
2006-07-06 David Edelsohn [EMAIL PROTECTED]
Alan Modra [EMAIL PROTECTED]
PR target/28170
* config/rs6000/rs6000.c (insvdi_rshift_rlwimi_p): Correct shiftop
bounds. Simplify.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28150
[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-07-06 19:08 --- This patch has added code that is nonsentical when the operation can be synthesized cheaply in a narrower mode: r83956 | sayle | 2004-07-01 05:27:09 +0100 (Thu, 01 Jul 2004) | 6 lines * expmed.c (expand_shift): Consider expanding LSHIFT_EXPR by a constant as a sequence of additions depending upon the rtx_costs. (synth_mult): Update the observed cost of a shift, based upon the above optimization. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added CC||roger at eyesopen dot com Status|UNCONFIRMED |NEW Component|target |middle-end Ever Confirmed|0 |1 Known to fail||4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-07-06 19:08:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283
[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints
--- Comment #2 from roger at eyesopen dot com 2006-07-06 19:17 --- Investigating... I suspect that the SH backend's rtx_costs are parameterized incorrectly, such that a 64-bit shift by the constant 32, looks to be at least 32 times more expensive than a 64-bit addition. The middle-end then uses these numbers to select the appropriate code sequence to generate. Combine also doesn't both cleaning this up because it also the same invalid rtx_costs, and discovers than combining additions into shifts doesn't appear to be a win on this target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283
[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-07-06 19:30 --- When I disable the offending code (by altering add_cost[DImode] at the right moment), I get the right result for little endian. However, compiling for big endian gives wrong code: _expand64: mov #0,r5 mov r4,r0 rts mov r5,r1 .size _expand64, .-_expand64 .ident GCC: (GNU) 4.2.0 20060620 (experimental) 3.4.0 was sane: _expand64: mov r4,r5 mov #0,r4 mov r4,r0 rts mov r5,r1 .size _expand64, .-_expand64 .ident GCC: (GNU) 3.4.0 20040113 (experimental) -- amylaar at gcc dot gnu dot org changed: What|Removed |Added CC||joern dot rennecke at st dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283
[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-07-06 19:32 --- (In reply to comment #2) Investigating... I suspect that the SH backend's rtx_costs are parameterized incorrectly, such that a 64-bit shift by the constant 32, looks to be at least 32 times more expensive than a 64-bit addition. No, the costs are correct, no DImode shift is supported with a count other than one. The expanders are supposed to use SImode shifts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283
[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints
--- Comment #5 from roger at eyesopen dot com 2006-07-06 19:47 --- No the rtx_costs for a DImode shift really are wrong. The use of the constant 1 in sh.c:shift_costs instructs the middle-end to avoid using DImode shifts at all costs. The semantics of rtx_costs is that it is expected to provide an estimate of the cost of performing an instruction (either in size when optimize_size or in performance whrn !optimize_size) even if the hardware doesn't support that operation directly. For example, a backend may even need to provide estimates of the time taken for a libcall to libgcc, if such an operation is necessary, or when optimizing for size, how large such setting up and executing such a call sequence should be. It's only by providing accurate information such as this that an embedded backend such as SH is able to provide fine control over the code sequences selected by the GCC middle-end. As for the little-endian vs. big-endian issue that looks like a second bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283
[Bug middle-end/28283] SuperH: Very unoptimal code generated for 64-bit ints
--- Comment #6 from joern dot rennecke at st dot com 2006-07-06 19:59 --- Subject: Re: SuperH: Very unoptimal code generated for 64-bit ints roger at eyesopen dot com wrote: --- Comment #5 from roger at eyesopen dot com 2006-07-06 19:47 --- No the rtx_costs for a DImode shift really are wrong. The use of the constant 1 in sh.c:shift_costs instructs the middle-end to avoid using DImode shifts at all costs. The semantics of rtx_costs is that it is expected to provide an estimate of the cost of performing an instruction (either in size when optimize_size or in performance whrn !optimize_size) If the RTX is not valid, the md is not required to give a valid rtx cost estimates. As for the little-endian vs. big-endian issue that looks like a second bug. Yes, but it's hard to debug as long as you have to poke internal data structures to get the compiler to use SImode shifts. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28283
[Bug libstdc++/28290] New: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
Bootstrapping current mainline as of 20060705 fails on Tru64 UNIX V5.1B when trying to genererate the PCH file for extc++.h: /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc/xgcc -shared-libgcc -B/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc -nostdinc++ -L/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src -L/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/src/.libs -B/vol/gcc/share/alpha-dec-osf5.1b/bin/ -B/vol/gcc/share/alpha-dec-osf5.1b/lib/ -isystem /vol/gcc/share/alpha-dec-osf5.1b/include -isystem /vol/gcc/share/alpha-dec-osf5.1b/sys-include -Winvalid-pch -Wno-deprecated -x c++-header -g -O2 -mieee -I/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/alpha-dec-osf5.1b -I/vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include -I/vol/gccsrc/src/gcc/libstdc++-v3/libsupc++ /vol/gccsrc/src/gcc/libstdc++-v3/include/precompiled/extc++.h -O2 -g -o ./alpha-dec-osf5.1b/bits/extc++.h.gch/O2g.gch; /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:57: error: 'iconv_t' does not name a type /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:67: error: 'descriptor_type' does not name a type /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:70: error: 'descriptor_type' does not name a type /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:147: error: ISO C++ forbids declaration of 'descriptor_type' with no type /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:147: error: expected ';' before '' token /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:151: error: expected `;' before 'const' /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:151: error: ISO C++ forbids declaration of 'descriptor_type' with no type /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:151: error: expected ';' before '' token /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:155: error: expected `;' before 'protected' /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h: In constructor '__gnu_cxx::encoding_state::encoding_state()': /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:86: error: class '__gnu_cxx::encoding_state' does not have any field named '_M_in_desc' /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:86: error: class '__gnu_cxx::encoding_state' does not have any field named '_M_out_desc' /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h: In constructor '__gnu_cxx::encoding_state::encoding_state(const char*, const char*, int, int, int)': /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:92: error: class '__gnu_cxx::encoding_state' does not have any field named '_M_in_desc' /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:92: error: class '__gnu_cxx::encoding_state' does not have any field named '_M_out_desc' /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h: In copy constructor '__gnu_cxx::encoding_state::encoding_state(const __gnu_cxx::encoding_state)': /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:104: error: class '__gnu_cxx::encoding_state' does not have any field named '_M_in_desc' /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:104: error: class '__gnu_cxx::encoding_state' does not have any field named '_M_out_desc' /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h: In member function 'bool __gnu_cxx::encoding_state::good() const': /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:121: error: 'descriptor_type' does not name a type /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:122: error: '_M_in_desc' was not declared in this scope /vol/gccsrc/obj/gcc-4.2.0-20060705/5.1b-gcc/alpha-dec-osf5.1b/libstdc++-v3/include/ext/codecvt_specializations.h:122: error: '__err' was not declared in this scope
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #1 from ro at gcc dot gnu dot org 2006-07-06 20:03 --- Created an attachment (id=11847) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11847action=view) -save-temps output Output from gcc -save-temps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #2 from ro at techfak dot uni-bielefeld dot de 2006-07-06 20:10 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B Even if I add iconv.h directly to extc++.h (a complete hack), the compilation errors about iconv_t missing are gone, but the ICE remains, even at -O0. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #3 from falk at debian dot org 2006-07-06 20:14 --- (In reply to comment #2) Even if I add iconv.h directly to extc++.h (a complete hack), the compilation errors about iconv_t missing are gone, but the ICE remains, even at -O0. Can you give the .ii for that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #4 from ro at gcc dot gnu dot org 2006-07-06 20:18 --- Created an attachment (id=11848) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11848action=view) -save-temps output with iconv.h hack and -O0 gcc -save-temps output that compiles (due to iconv.h inclusion in extc++.h) with -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2006-07-06 20:19 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B falk at debian dot org writes: Can you give the .ii for that? Sure, done. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug fortran/27874] [4.1 only] Bad interaction between bounds checking, forall and derived types
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.2 Known to work||4.2.0 Summary|Bad interaction between |[4.1 only] Bad interaction |bounds checking, forall and |between bounds checking, |derived types |forall and derived types Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27874
[Bug fortran/28129] gfortran -fbounds-check: Shows invalid array out of bounds error
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-07-06 20:37 --- Subject: Bug 28129 Author: fxcoudert Date: Thu Jul 6 20:37:36 2006 New Revision: 115231 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=115231 Log: PR fortran/28129 * trans-array.c (gfc_trans_array_bound_check): Add a locus argument, and use it in the error messages. (gfc_conv_array_index_offset): Donc perform bounds checking on the last dimension of assumed-size arrays. * gfortran.dg/bounds_check_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28129
[Bug c++/28291] New: [4.1/4.2 regression] ICE on invalid designated initializer
The following invalid code snippet triggers an ICE since GCC 4.1.0:
==
struct A
{
static int i;
int j;
};
A a = { i:0 };
==
bug.cc:7: error: 'A' has no non-static data member named 'i'
bug.cc:7: internal compiler error: in process_init_constructor_record, at
cp/typeck2.c:895
Please submit a full bug report, [etc.]
--
Summary: [4.1/4.2 regression] ICE on invalid designated
initializer
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28291
[Bug c++/28291] [4.1/4.2 regression] ICE on invalid designated initializer
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28291
[Bug c++/28292] New: [4.2 regression] ICE in acceptable_java_type
The following invalid code snippet triggers an ICE on mainline:
==
extern Java
{
struct A
{
void foo(void;
};
}
==
bug.cc:5: error: expected `)' before ';' token
bug.cc:5: error: 'anonymous' has incomplete type
bug.cc:5: error: invalid use of 'void'
bug.cc:5: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in acceptable_java_type, at cp/decl2.c:472
Please submit a full bug report, [etc.]
--
Summary: [4.2 regression] ICE in acceptable_java_type
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28292
[Bug c++/28292] [4.2 regression] ICE in acceptable_java_type
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28292
[Bug fortran/25271] gfortran fails to pad lines in format statements to 72 characters.
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-07-06 21:00 --- Unless I'm severely mistaken, this is not library issue but a front-end issue. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Component|libfortran |fortran http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25271
[Bug c++/28293] New: ICE on invalid typedef
The following invalid code snippet triggers an ICE since at least GCC 2.95.3:
==
templateint void foo();
struct A
{
typedef void foo0();
};
==
bug.cc:5: internal compiler error: tree check: expected identifier_node, have
template_id_expr in grokfield, at cp/decl2.c:805
Please submit a full bug report, [etc.]
--
Summary: ICE on invalid typedef
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28293
[Bug c++/28294] New: [4.0/4.1/4.2 regression] ICE with invalid use of __builtin_offsetof
The following invalid code snippet triggers an ICE since at GCC 4.0.0:
struct A
{
static int foo();
};
int i = __builtin_offsetof(A, foo[0]);
bug.cc:6: error: pointer to a function used in arithmetic
bug.cc:6: internal compiler error: tree check: expected class 'expression',
have 'declaration' (function_decl) in finish_offsetof, at cp/semantics.c:2895
Please submit a full bug report, [etc.]
Testing a patch.
--
Summary: [4.0/4.1/4.2 regression] ICE with invalid use of
__builtin_offsetof
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: reichelt at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28294
[Bug c++/28294] [4.0/4.1/4.2 regression] ICE with invalid use of __builtin_offsetof
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28294
[Bug libgcj/28244] [4.2 regression] missing dependency causes build failure
--- Comment #5 from fitzsim at redhat dot com 2006-07-06 21:14 --- I fixed the missing dependency on trunk. The hppa-unknown-linux-gnu problem should probably be a separate bug. I'm closing this one. -- fitzsim at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28244
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2006-07-06 22:04 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B The same ICE happens on Solaris 10/x86 (i386-pc-solaris2.10). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
Re: [Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #6 from ro at techfak dot uni-bielefeld dot de 2006-07-06 22:04 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B The same ICE happens on Solaris 10/x86 (i386-pc-solaris2.10). On x86-linux-gnu with FC4 I hear, I could not reproduce it on FC5, I am in the middle of a GCAC checking build. -- Pinski
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #7 from pinskia at physics dot uc dot edu 2006-07-06 22:16 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B --- Comment #6 from ro at techfak dot uni-bielefeld dot de 2006-07-06 22:04 --- Subject: Re: [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B The same ICE happens on Solaris 10/x86 (i386-pc-solaris2.10). On x86-linux-gnu with FC4 I hear, I could not reproduce it on FC5, I am in the middle of a GCAC checking build. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-07-06 22:17 --- *** This bug has been marked as a duplicate of 28217 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug c++/28217] [4.2 regression] ICE in tree_int_cst_sgn
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-07-06 22:17 --- *** Bug 28290 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ro at techfak dot uni- ||bielefeld dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28217
[Bug libstdc++/28290] [4.2 Regression] ICE during extc++.h pch generation on Tru64 UNIX V5.1B
--- Comment #9 from ro at gcc dot gnu dot org 2006-07-06 22:21 --- The ICE is a duplicate, but the compile failure before is not (though it could be the same issue as libstdc++/28265). -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28290
[Bug target/28232] Wrong aligned load is generated with -m4a on sh-*
--- Comment #2 from patchapp at dberlin dot org 2006-07-06 22:35 --- Subject: Bug number PR target/28232 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/2006-07/msg00266.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28232
[Bug libgcj/1907] symbol demangling by Throwable.printStackTrace
--- Comment #8 from mckinlay at redhat dot com 2006-07-06 22:56 --- Fixed. libgcj no longer needs to do symbol demangling. -- mckinlay at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1907
[Bug libgcj/13139] gcj throws exception with faulty stacktrace with freenet
--- Comment #7 from mckinlay at redhat dot com 2006-07-06 23:06 --- Verified that freenet-0.5.2.1 now produces valid stack traces running under gcj. -- mckinlay at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13139
[Bug libgomp/28296] New: libgomp fails to configure on Tru64 UNIX
libgomp just doesn't configure any more on Tru64 UNIX V5.1B: configure: error: Pthreads are required to build libgomp This is due to the last configure.ac change: 2006-07-05 Eric Christopher [EMAIL PROTECTED] * configure.ac: Depend addition of -pthread on host OS. * configure: Regenerate. which list the -pthread flag during the compile test, so both pthread tests fail now: configure:8315: /vol/gcc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc/xgcc -B/vol/gcc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc/ -B/vol/gcc/share/alpha-dec-osf5.1b/bin/ -B/vol/gcc/share/alpha-dec-osf5.1b/lib/ -isystem /vol/gcc/share/alpha-dec-osf5.1b/include -isystem /vol/gcc/share/alpha-dec-osf5.1b/sys-include -o conftest -O2 -g -O2 -mieee conftest.c 5 In file included from conftest.c:25: /vol/gcc/obj/gcc-4.2.0-20060705/5.1b-gcc/./gcc/include/pthread.h:339:4: error: #error Please compile the module including pthread.h with -pthread Before that patch, -pthread was included and the test succeeded. I think this tweaking of pthread detection in libgomp must stop: this introduces problems all over the place. I suppose there are some tested autoconf macros to achieve this correctly on all platforms. Environment: System: OSF1 bartok V5.1 2650 alpha Machine: alpha host: alpha-dec-osf5.1b build: alpha-dec-osf5.1b target: alpha-dec-osf5.1b configured with: /vol/gcc/src/gcc/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build alpha-dec-osf5.1b --target alpha-dec-osf5.1b --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 --with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr --enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap How-To-Repeat: Bootstrap mainline as described above. -- Summary: libgomp fails to configure on Tru64 UNIX Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28296
