[Bug bootstrap/26188] [4.2 Regression] 4.2.0 fails to compile on FreeBSD 4.11
--- Comment #12 from bonzini at gnu dot org 2006-06-15 07:21 --- Created an attachment (id=11670) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11670&action=view) updated configure script for libdecnumber Gerald, here it is. Again, don't forget to disable fortran. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26188
[Bug c/28038] New: Double to char conversion fails at 32769.0
The program
#include
main()
{
double d;
int i;
printf("Starting at 32758\n");
for (d=32758.0, i=0; i<20; i++) {
printf("d is %f, as integer is 0x%0.8x, and (ushort)d is 0x%0.4x
while (unsigned char)d is 0x%0.2x\n",
d, (int)d,
(unsigned short)d, (unsigned char)d);
d += 1.0;
}
return 0;
}
gives the following output on Intel
Starting at 32758
d is 32758.00, as integer is 0x7ff6, and (ushort)d is 0x7ff6 while
(unsigned char)d is 0xf6
d is 32759.00, as integer is 0x7ff7, and (ushort)d is 0x7ff7 while
(unsigned char)d is 0xf7
d is 32760.00, as integer is 0x7ff8, and (ushort)d is 0x7ff8 while
(unsigned char)d is 0xf8
d is 32761.00, as integer is 0x7ff9, and (ushort)d is 0x7ff9 while
(unsigned char)d is 0xf9
d is 32762.00, as integer is 0x7ffa, and (ushort)d is 0x7ffa while
(unsigned char)d is 0xfa
d is 32763.00, as integer is 0x7ffb, and (ushort)d is 0x7ffb while
(unsigned char)d is 0xfb
d is 32764.00, as integer is 0x7ffc, and (ushort)d is 0x7ffc while
(unsigned char)d is 0xfc
d is 32765.00, as integer is 0x7ffd, and (ushort)d is 0x7ffd while
(unsigned char)d is 0xfd
d is 32766.00, as integer is 0x7ffe, and (ushort)d is 0x7ffe while
(unsigned char)d is 0xfe
d is 32767.00, as integer is 0x7fff, and (ushort)d is 0x7fff while
(unsigned char)d is 0xff
d is 32768.00, as integer is 0x8000, and (ushort)d is 0x8000 while
(unsigned char)d is 0x00
d is 32769.00, as integer is 0x8001, and (ushort)d is 0x8001 while
(unsigned char)d is 0x00
d is 32770.00, as integer is 0x8002, and (ushort)d is 0x8002 while
(unsigned char)d is 0x00
d is 32771.00, as integer is 0x8003, and (ushort)d is 0x8003 while
(unsigned char)d is 0x00
d is 32772.00, as integer is 0x8004, and (ushort)d is 0x8004 while
(unsigned char)d is 0x00
d is 32773.00, as integer is 0x8005, and (ushort)d is 0x8005 while
(unsigned char)d is 0x00
d is 32774.00, as integer is 0x8006, and (ushort)d is 0x8006 while
(unsigned char)d is 0x00
d is 32775.00, as integer is 0x8007, and (ushort)d is 0x8007 while
(unsigned char)d is 0x00
d is 32776.00, as integer is 0x8008, and (ushort)d is 0x8008 while
(unsigned char)d is 0x00
d is 32777.00, as integer is 0x8009, and (ushort)d is 0x8009 while
(unsigned char)d is 0x00
That is, the unsigned char is always zero after 32769.0
On Sparc, with gcc (GCC) 3.3.2, we see
Starting at 32758
d is 32758.00, as integer is 0x7ff6, and (ushort)d is 0x7ff6 while
(unsigned char)d is 0xf6
d is 32759.00, as integer is 0x7ff7, and (ushort)d is 0x7ff7 while
(unsigned char)d is 0xf7
d is 32760.00, as integer is 0x7ff8, and (ushort)d is 0x7ff8 while
(unsigned char)d is 0xf8
d is 32761.00, as integer is 0x7ff9, and (ushort)d is 0x7ff9 while
(unsigned char)d is 0xf9
d is 32762.00, as integer is 0x7ffa, and (ushort)d is 0x7ffa while
(unsigned char)d is 0xfa
d is 32763.00, as integer is 0x7ffb, and (ushort)d is 0x7ffb while
(unsigned char)d is 0xfb
d is 32764.00, as integer is 0x7ffc, and (ushort)d is 0x7ffc while
(unsigned char)d is 0xfc
d is 32765.00, as integer is 0x7ffd, and (ushort)d is 0x7ffd while
(unsigned char)d is 0xfd
d is 32766.00, as integer is 0x7ffe, and (ushort)d is 0x7ffe while
(unsigned char)d is 0xfe
d is 32767.00, as integer is 0x7fff, and (ushort)d is 0x7fff while
(unsigned char)d is 0xff
d is 32768.00, as integer is 0x8000, and (ushort)d is 0x8000 while
(unsigned char)d is 0x00
d is 32769.00, as integer is 0x8001, and (ushort)d is 0x8001 while
(unsigned char)d is 0x01
d is 32770.00, as integer is 0x8002, and (ushort)d is 0x8002 while
(unsigned char)d is 0x02
d is 32771.00, as integer is 0x8003, and (ushort)d is 0x8003 while
(unsigned char)d is 0x03
d is 32772.00, as integer is 0x8004, and (ushort)d is 0x8004 while
(unsigned char)d is 0x04
d is 32773.00, as integer is 0x8005, and (ushort)d is 0x8005 while
(unsigned char)d is 0x05
d is 32774.00, as integer is 0x8006, and (ushort)d is 0x8006 while
(unsigned char)d is 0x06
d is 32775.00, as integer is 0x8007, and (ushort)d is 0x8007 while
(unsigned char)d is 0x07
d is 32776.00, as integer is 0x8008, and (ushort)d is 0x8008 while
(unsigned char)d is 0x08
d is 32777.00, as integer is 0x8009, and (ushort)d is 0x8009 while
(unsigned char)d is 0x09
Which seems more intuitively correct.
This problem is also found on a XEON proccessor with
gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-47)
--
Summary: Double to char conversion fails at 32769.0
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
[Bug c/28038] Double to char conversion fails at 32769.0
--- Comment #1 from falk at debian dot org 2006-06-15 10:16 --- If the value of the integral part cannot be represented by the integer type, the behavior is undefined. So this is not a bug. -- falk at debian dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC target triplet| Pentium III (Coppermine) |Pentium III (Coppermine) Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28038
[Bug fortran/28039] New: Warn when ignoring extra characters in the format specification
Assume the following case: One had somewhere '(3(a,),f)', now one copies this and realizes that one does not need the 3(..) anymore. Result: '(a,),f)' Ups, the ",f)" is ignored. Currently, gfortran does not warn in such a case. Expected: gfortran warns at compile time Ifort (9.1) even default warns in such a case: fortcom: Warning: test.f90, line 5: The extra characters in the format specification will be ignored ['(a),f)'] write(*,'(a),f)') 'Hello', r --^ Test case: -- program test implicit none real :: r r = 1.0 write(*,'(a),f)') 'Hello', r end program test -- -- Summary: Warn when ignoring extra characters in the format specification Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28039
[Bug target/28040] New: [m68k]wrong move const extends output at coldfire v4
Hi
I think gcc-4.1.1 generates wrong outputs on coldfire v4 at this code.
-
struct ab {
int a;
unsigned int b;
};
int
main () {
struct ab _ab;
short a = 0;
unsigned short b = 0;
_ab.a = -999;
_ab.b = 1000;
a = _ab.a;
b = _ab.b;
printf("%d\n", a );
printf("%d\n", b );
return 0;
}
-
./xgcc -m5407 -S ./test.c
-
...
link.w %fp,#-8
mvzw #-999,%d0 <- zero extends(_ab.a)
move.l %d0,-8(%fp)
mvsw #1000,%d0 <- sign extends(_ab.b)
move.l %d0,-4(%fp)
move.l -8(%fp),%d0
move.l %d0,-(%sp)
and This is a patch.
gcc/config/m68k/m68k.c: output_move_const_into_data_reg.
--- m68k.bak2006-06-15 19:49:00.0 +0900
+++ m68k.c 2006-06-15 19:49:42.0 +0900
@@ -1658,9 +1658,9 @@
switch (const_method (operands[1]))
{
case MVZ:
- return "mvsw %1,%0";
-case MVS:
return "mvzw %1,%0";
+case MVS:
+ return "mvsw %1,%0";
case MOVQ :
return "moveq %1,%0";
case NOTB :
--
Summary: [m68k]wrong move const extends output at coldfire v4
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tyokota at k2 dot dion dot ne dot jp
GCC build triplet: x86-64-elf-linux
GCC host triplet: x86-64-elf-linux
GCC target triplet: m68k-elf-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28040
[Bug rtl-optimization/26244] [4.2 Regression] FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -O3 -fomit-frame-pointer -funroll-loops
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-06-15 11:17 --- Hello, > > http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00241.html suggests we > > still > > have the bug. Can someone confirm this still passes with > > -fno-move-loop-invariants? > > Confirmed. could you please try to simplify the testcase, ideally to separate just the single misscompiled loop? I again failed to find anything wrong using just a crosscompiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244
[Bug libffi/28036] libffi executable stack (missing .note.GNU-stack on .o files)
--- Comment #2 from aph at gcc dot gnu dot org 2006-06-15 11:23 --- gcj creates all its trampolines on the heap, so exec stack shouldn't be needed. -- aph at gcc dot gnu dot org changed: What|Removed |Added CC||aph at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28036
[Bug tree-optimization/27331] [4.2 Regression] segfault in fold_convert with -ftree-vectorize
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-06-15 11:31 --- Ccing people responsible for data dependence analysis. I have hacked this over on predcom branch, but I would prefer if someone who understands the code could fix it properly. -- rakdver at gcc dot gnu dot org changed: What|Removed |Added CC||sebastian dot pop at cri dot ||ensmp dot fr, dberlin at gcc ||dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27331
[Bug fortran/27998] character arrays: warn if erray constructor values have different lengths
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-06-15 12:26 --- > .so, an error is definitely in order. Maybe one could spit out a default warning and only with -std=f90 an error as this is might be a commonly used Fortran extension. Or one simply always regards it as error. NAG's f95 gives even with -dusty an error ifort gives not error/warning by default, unless -std95 is specified, then an error message is given. g95 gives no warning (not even with -Wall -Wextra) unless -std=f95 is used (then it is an error) Sun Studio's f95 gives always an error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27998
[Bug java/28024] libjava build failure on Solaris 2.8 (sun4u)
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-06-15 12:34 --- > I fixed this problem. But, as I don't have a Solaris box, > I can't test whether this means that the build works. This report was actually invalid, we don't support /bin/sh on Solaris. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28024
[Bug java/28024] libjava build failure on Solaris 2.8 (sun4u)
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-06-15 12:36 --- See http://gcc.gnu.org/install/specific.html#x-x-solaris2 -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|REOPENED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28024
[Bug c++/28041] New: [gomp] ICE in g++.dg/gomp/atomic-[4,5,9].C
The compilation crashes in
/* Gimplify an OMP_ATOMIC statement. */
static enum gimplify_status
gimplify_omp_atomic (tree *expr_p, tree *pre_p)
{
tree addr = TREE_OPERAND (*expr_p, 0);
tree rhs = TREE_OPERAND (*expr_p, 1);
>>> tree type = TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (addr)));
HOST_WIDE_INT index;
Program received signal SIGSEGV, Segmentation fault.
0x001bb40c in gimplify_omp_atomic (expr_p=0xff0edf48, pre_p=0xffbed64c) at
/export/home/uros/gcc-svn/trunk/gcc/gimplify.c:5148
(gdb) bt
#0 0x001bb40c in gimplify_omp_atomic (expr_p=0xff0edf48, pre_p=0xffbed64c) at
/export/home/uros/gcc-svn/trunk/gcc/gimplify.c:5148
#1 0x001bd2a0 in gimplify_expr (expr_p=0xff0edf48, pre_p=0xffbed64c,
post_p=0xffbed648, gimple_test_f=0x1aa228 , fallback=fb_none)
at /export/home/uros/gcc-svn/trunk/gcc/gimplify.c:5646
#2 0x001b6078 in gimplify_statement_list (expr_p=0xffbed6f8) at
/export/home/uros/gcc-svn/trunk/gcc/tree-iterator.h:86
#3 0x001bcdfc in gimplify_expr (expr_p=0xff115970, pre_p=0xffbed784,
post_p=0xffbed780, gimple_test_f=0x1aa228 , fallback=fb_none)
at /export/home/uros/gcc-svn/trunk/gcc/gimplify.c:5595
#4 0x001bde60 in gimplify_body (body_p=0xff115970, fndecl=0xff115900,
do_parms=1 '\001') at
/export/home/uros/gcc-svn/trunk/gcc/gimplify.c:6113
#5 0x001be2a8 in gimplify_function_tree (fndecl=0xff115900) at
/export/home/uros/gcc-svn/trunk/gcc/gimplify.c:6189
#6 0x0017917c in c_genericize (fndecl=0xff115900) at
/export/home/uros/gcc-svn/trunk/gcc/c-gimplify.c:106
#7 0x00143864 in cp_genericize (fndecl=0xff115900) at
/export/home/uros/gcc-svn/trunk/gcc/cp/cp-gimplify.c:739
#8 0x00045a74 in finish_function (flags=0) at
/export/home/uros/gcc-svn/trunk/gcc/cp/decl.c:11130
--
Summary: [gomp] ICE in g++.dg/gomp/atomic-[4,5,9].C
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: uros at kss-loka dot si
GCC build triplet: sparc-sun-solaris2.8
GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28041
[Bug tree-optimization/27331] [4.2 Regression] segfault in fold_convert with -ftree-vectorize
--- Comment #9 from sebastian dot pop at cri dot ensmp dot fr 2006-06-15 13:19 --- Subject: Re: [4.2 Regression] segfault in fold_convert with -ftree-vectorize rakdver at gcc dot gnu dot org wrote: > Ccing people responsible for data dependence analysis. Thanks, for the ping, this bug was not on my todo list. I'll take a look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27331
[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong
--- Comment #21 from amacleod at redhat dot com 2006-06-15 13:30 --- Subject: Bug 27793 Author: amacleod Date: Thu Jun 15 13:30:17 2006 New Revision: 114678 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114678 Log: 2006-06-15 Andrew MacLeod <[EMAIL PROTECTED]> PR middle-end/27793 * tree-dfa.c (referenced_vars_dup_list): Remove. (find_referenced_vars): Remove assert. (referenced_var_check_and_insert): Replace dup list with assert. * tree-ssa.c (delete_tree_ssa): Remove dup list processing. * tree-flow.h (referenced_vars_dup_list): Remove extern decl. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-dfa.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
[Bug c/28042] New: optimizer (-O2) changes the semantics of my programs
See lower part of my article at http://www.ba-stuttgart.de/~helbig/st80/bsearch.txt -- Summary: optimizer (-O2) changes the semantics of my programs Product: gcc Version: 2.95.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: helbig at lehre dot ba-stuttgart dot de GCC build triplet: ? GCC host triplet: solaris-8 x86 GCC target triplet: solaris-8 x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28042
[Bug middle-end/28042] optimizer (-O2) changes the semantics of my programs
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-15 14:15 --- The tesstcase works in "4.2.0 20060608" but fails with Apple's "gcc version 4.0.1 (Apple Computer, Inc. build 5341)". I bet I have seen this bug before. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28042
[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-06-15 14:21 --- Daniel, this bug was exposed by your 2006-02-20 patch. It's been blocking testing/submission of one of my libgfortran patches for more than two months now. It's in an area of the compiler I don't have any experience with, but is there someone I can pressure on in order to get things fixed? Do you have any idea why/where it's happening? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-05-18 07:21:33 |2006-06-15 14:21:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types
--- Comment #10 from dberlin at gcc dot gnu dot org 2006-06-15 14:35 --- Uh, nobody told me it was exposed by my patch, and it's certainly not in the bug history, or else i would be working on the bug. In fact, as comment 8 shows, even if you disable the code i added in 2006-02-20, an ICE still occurs. I'll look at this bug anyway -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug tree-optimization/27331] [4.2 Regression] segfault in fold_convert with -ftree-vectorize
--- Comment #10 from sebastian dot pop at cri dot ensmp dot fr 2006-06-15
14:52 ---
Subject: Re: [4.2 Regression] segfault in fold_convert with -ftree-vectorize
You said that you had a fix in predcom, is that fix in your local
tree, or have you sent a patch to gcc-patches?
Here is a fix for this PR. I don't like the data-ref code that deals
with component_refs, as it seems very fragile.
Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 114678)
+++ tree-data-ref.c (working copy)
@@ -1947,7 +1947,8 @@ create_data_ref (tree memref, tree stmt,
object_analysis divided by the size of data type.
*/
if (!DR_BASE_OBJECT (dr)
- || (TREE_CODE (memref) == COMPONENT_REF && DR_NUM_DIMENSIONS (dr) == 1))
+ || (TREE_CODE (memref) == COMPONENT_REF && DR_NUM_DIMENSIONS (dr) == 1
+ && !automatically_generated_chrec_p (DR_ACCESS_FN (dr, 0
{
tree access_fn;
tree new_step;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27331
[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-06-15 15:04 --- This should fix it It looks like gimplify_val never calls mark_new_vars_to_rename, but may create new statements that nothing else gets a handle to. Index: tree-cfg.c === --- tree-cfg.c (revision 114136) +++ tree-cfg.c (working copy) @@ -5584,6 +5584,8 @@ gimplify_val (block_stmt_iterator *bsi, TREE_BLOCK (new_stmt) = TREE_BLOCK (orig_stmt); bsi_insert_before (bsi, new_stmt, BSI_SAME_STMT); + if (in_ssa_p) +mark_new_vars_to_rename (new_stmt); return t; } I'll look at this bug anyway -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug tree-optimization/27341] [4.2 Regression] ICE in in add_virtual_operand with complex types
--- Comment #12 from dberlin at gcc dot gnu dot org 2006-06-15 15:18
---
Subject: Bug 27341
Patch I am testing for all the testcases here.
It turns out to be a problem not actually in the 02-20-06 patch.
Index: gcc/tree-complex.c
===
--- gcc/tree-complex.c (revision 114136)
+++ gcc/tree-complex.c (working copy)
@@ -1541,11 +1541,12 @@ struct tree_opt_pass pass_lower_complex
0, /* tv_id */
PROP_ssa,/* properties_required */
0, /* properties_provided */
- 0, /* properties_destroyed */
+ PROP_smt_usage, /* properties_destroyed */
0, /* todo_flags_start */
TODO_dump_func | TODO_ggc_collect
-| TODO_update_ssa
-| TODO_verify_stmts, /* todo_flags_finish */
+ | TODO_update_smt_usage
+ | TODO_update_ssa
+ | TODO_verify_stmts, /* todo_flags_finish */
0/* letter */
};
Index: gcc/testsuite/gcc.c-torture/compile/pr27341-1.c
===
--- gcc/testsuite/gcc.c-torture/compile/pr27341-1.c (revision 0)
+++ gcc/testsuite/gcc.c-torture/compile/pr27341-1.c (revision 0)
@@ -0,0 +1,7 @@
+extern double R_NaReal;
+void z_atan2 (double _Complex * r, double _Complex * ccs)
+{
+if (*ccs == 0)
+__imag__ *r = R_NaReal;
+}
+
Index: gcc/testsuite/gcc.c-torture/compile/pr27341-2.c
===
--- gcc/testsuite/gcc.c-torture/compile/pr27341-2.c (revision 0)
+++ gcc/testsuite/gcc.c-torture/compile/pr27341-2.c (revision 0)
@@ -0,0 +1,8 @@
+void zgemm_ (const int*, const double*);
+extern void matmul_c8 (_Complex double * dest)
+{
+ const int ldc = 0;
+ const double zero = 0;
+ zgemm_ ( &zero, &ldc);
+ dest[1] += 1 ;
+}
Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c (revision 114136)
+++ gcc/tree-cfg.c (working copy)
@@ -5584,6 +5584,8 @@ gimplify_val (block_stmt_iterator *bsi,
TREE_BLOCK (new_stmt) = TREE_BLOCK (orig_stmt);
bsi_insert_before (bsi, new_stmt, BSI_SAME_STMT);
+ if (in_ssa_p)
+mark_new_vars_to_rename (new_stmt);
return t;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27341
[Bug c++/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer
--- Comment #12 from dj at redhat dot com 2006-06-15 15:19 --- Subject: Re: [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer > I don't understand the assertion, given that removing it seems to > generate correct output for this test case. The problem is that this function PADS rather than EXTENDS data that's shorter than it's supposed to be, and it always pads in the same direction - IIRC little endian. Thus, it breaks on big endian machines, or machines that require sign extension. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724
[Bug c++/27724] [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer
--- Comment #13 from mark at codesourcery dot com 2006-06-15 15:27 --- Subject: Re: [4.1/4.2 Regression] internal compiler error: no-op convert from 4 to 8 bytes in initializer dj at redhat dot com wrote: > --- Comment #12 from dj at redhat dot com 2006-06-15 15:19 --- > Subject: Re: [4.1/4.2 Regression] internal compiler error: no-op convert from > 4 to 8 bytes in initializer > > >> I don't understand the assertion, given that removing it seems to >> generate correct output for this test case. > > The problem is that this function PADS rather than EXTENDS data that's > shorter than it's supposed to be, and it always pads in the same > direction - IIRC little endian. Thus, it breaks on big endian > machines, or machines that require sign extension. So, you believe that initializer_constant_valid_p should reject this initializer then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724
[Bug middle-end/27781] [4.1/4.2 Regression] weak-attribute over-optimisation
--- Comment #5 from patchapp at dberlin dot org 2006-06-15 15:30 --- Subject: Bug number PR27781 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-06/msg00808.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
[Bug c/28038] Double to char conversion fails at 32769.0
--- Comment #2 from barryb at cwipapps dot net 2006-06-15 15:54 --- The integers in the example ARE all within the range of unsigned short. Therefore Falk's comments may be true, but are not relevant. Note also that the same code works as expected on sparc. We think that the problem lies in the generation of fistps rather than fistpl opcodes, since the latter seems to work. Somehow, MySQL AB have found a way to compile such expressions correctly in their 4.0.23 function, scramble() -- barryb at cwipapps dot net changed: What|Removed |Added CC||barryb at cwipapps dot net Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28038
[Bug c/28038] Double to char conversion fails at 32769.0
--- Comment #3 from schwab at suse dot de 2006-06-15 16:04 --- It is still undefined to convert a float to an integer that is too narrow. The range of short is irrelevant when converting to char. Since the behaviour is undefined there is no requirement on the resulting value. If you want defined behaviour you must first cast to an integer that is wide enough, then you can cast to the narrower (unsigned) type. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28038
[Bug c++/27227] [4.0 Regression] rejects valid code with some extern "C"
--- Comment #6 from sje at cup dot hp dot com 2006-06-15 16:14 ---
Could I get clarification if the following error is a desired effect of this
change. Prior to this, the included program gave no error. I believe the
change was caused by this patch. This is causing a problem with the HP-UX
definition of errno, but it we want this error, I can fixheaders the header
file in question.
e.c:1: error: previous declaration of 'int i' with 'C++' linkage
e.c:4: error: conflicts with new declaration with 'C' linkage
[hpclear8] $ cat e.c
extern int i;
extern "C" {
extern int i;
}
--
sje at cup dot hp dot com changed:
What|Removed |Added
CC||sje at cup dot hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug c++/27227] [4.0 Regression] rejects valid code with some extern "C"
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-15 16:19 ---
(In reply to comment #6)
> e.c:1: error: previous declaration of 'int i' with 'C++' linkage
> e.c:4: error: conflicts with new declaration with 'C' linkage
>
> extern int i;
> extern "C" {
> extern int i;
> }
Not this is a confirmation that the above is invalid code but EDG also errors
out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #12 from hp at gcc dot gnu dot org 2006-06-15 16:50 --- In reply to comment #11, "i" *is* an appropriate constraint, if any. I see the problem with the reduced test-case in comment #3, so I'm going to limit the scope of my involvement to fixing that. Hopefully we can leave the discussion on macro expansion for now, or at least any specific problems with e.g. __FUNCTION__ would be subject to a separate PR. (Though it's interesting if it works but __FILE__ doesn't.) The address of a string constant is for all normal use expressed as a local label, hence "symbolic constant" when it comes to assembly code. As a GCC backend guy, I know that "i" is a constraint useful in a GCC machine description when there's any constant symbol or label, possibly offset by a numeric constant. (Constraints are used for both machine descriptions and asms.) Besides bug.h in asm-ppc and asm-ppc64, I see this construct for asm-x86_64, asm-alpha, asm-ppc64, asm-i386 too. Not as not an argument for correctness, just an observation that contradicts the "only used with powerpc" statement. That is, except for use of __FUNCTION__. Hm. I think I need reconfirmation that we see the same problem: Is the code in comment #3 really a reduced test-case, i.e. does the code in comment #3 cause a warning for the compiler and options (filename replaced) for which you originally reported the problem? (If not, I'd like to know for what version it causes the same warning.) Thanks for your patience. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug c/28038] Double to char conversion fails at 32769.0
--- Comment #4 from barryb at cwipapps dot net 2006-06-15 17:15 --- Sorry, you are right; you have to cast it twice. I'd moved on to d is 32765.00, as integer is 0x7ffd, and (ushort)d is 0x7ffd while (uchar)(ushort)d is 0xfd d is 32766.00, as integer is 0x7ffe, and (ushort)d is 0x7ffe while (uchar)(ushort)d is 0xfe d is 32767.00, as integer is 0x7fff, and (ushort)d is 0x7fff while (uchar)(ushort)d is 0xff d is 32768.00, as integer is 0x8000, and (ushort)d is 0x8000 while (uchar)(ushort)d is 0x00 d is 32769.00, as integer is 0x8001, and (ushort)d is 0x8001 while (uchar)(ushort)d is 0x01 d is 32770.00, as integer is 0x8002, and (ushort)d is 0x8002 while (uchar)(ushort)d is 0x02 Which works for this width of integer. For some reason the following code *to++= (char) (floor(my_rnd(&rand_st)*31)+64); seems to work in MySQL 4.0.23 for Linux, but not when I use it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28038
[Bug middle-end/27781] [4.1/4.2 Regression] weak-attribute over-optimisation
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-06-15 17:23 --- Subject: Bug 27781 Author: rguenth Date: Thu Jun 15 17:23:41 2006 New Revision: 114681 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114681 Log: 2006-06-16 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/27781 * Makefile.in (ipa-pure-const.o): Add $(TARGET_H) dependency. * ipa-pure-const.c (target.h): Include. (analyze_function): Do not analyze functions that do not bind locally. * gcc.dg/tree-ssa/pr27781.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr27781.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ipa-pure-const.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
[Bug middle-end/27781] [4.1 Regression] weak-attribute over-optimisation
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-06-15 17:30 --- Fixed on the mainline. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 Regression] weak- |[4.1 Regression] weak- |attribute over-optimisation |attribute over-optimisation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
[Bug fortran/16206] rejects valid array initialization expression
--- Comment #7 from pault at gcc dot gnu dot org 2006-06-15 17:39 --- Created an attachment (id=11675) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11675&action=view) A near submission level patch for the PR I have not marked the previous version as obsolete because it could well be a valuable chunk of a future patch. The attached fixes most of the cases below, except for the last. Array sections, with variable index expressions, in implicit do loops still give an error; in fact the same error as g95! I think I can see how to do that final tweek Paul PS Please excuse the state of these "working" test programs; I use them as labs to test and diagnose the patch. program gfortran_bug1 ! real, parameter :: x(4,4) = reshape((/(i, i = 1, 16)/), (/4,4/)) real, parameter :: xx(2) = (/ 12.0, 14.0 /) real, parameter :: xxx(2) = (/ xx - 3 /) character(4), parameter :: chr(4) = (/"abcd", "efgh", "ijkl", "mnop"/), & scalar = "abcd" character(4), parameter :: scalar2 = chr(1)(2:4) ,chrt(2) = (/chr(2:2)(2:3), chr(3:3)(3:4)/) character(2), parameter :: chrr(2) = chr(2:3)(2:3) character(2), parameter :: chrx(2) = (/(chr(i)(2:3), i=2,3)/) ! ! gfortran dies at the following, which AFAICT is legal: ! real, parameter :: y(4) = (/ x(1:2, 2), x(1:2, 4)/) real, parameter :: z(2) = x(1:2, 1) + 1 print *, x print *, z print *, y print *, xxx print *, chrr print *, chrt print *, scalar2 print *, chrx end program gfortran_bug1 program gfortran_bug2 ! ! character(4), parameter :: chr(4) = (/"abcd", "efgh", "ijkl", "mnop"/), & ! scalar = "abcd" ! character(4), parameter :: chrx(2) = (/(chr(i), i=2,3)/) integer, parameter :: m(4) = (/1,2,3,4/) integer, parameter :: n(2) = (/(m(i), i = 2,3)/) integer, parameter :: o(4) = (/(n, i = 2,3)/) integer, parameter :: q(4) = (/((/(m(j), j = i, i+1)/), i = 2,3)/) integer, parameter :: p(8) = (/(m(i:i+1), i = 1,4)/) ! print *, chrx print *, n, o, p end program gfortran_bug2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16206
[Bug c++/28044] New: Non-template class function return type taken as template when declared in a function template's return type
See below; G++ appears to correctly handle the use of 'struct B' to declare the
function template g(), but if there is no prior declaration of the class (as in
the declaration of f()), the class is erroneously taken as a class template.
extern "C" int printf( const char*, ... );
struct B{ int n; B(int n_) : n(n_){} };
template struct B g() // OK, g() returns B
{
return B(32);
}
template struct A f(); // OK, f() returns A
struct A { char c; A(char c_) : c(c_){}};
template struct A f()
{
return A('x');
}
int main( )
{
(void) printf( "%d, %c\n",
g().n,
f().c ); // prints "32, x\n".
return 0;
}
--
Summary: Non-template class function return type taken as
template when declared in a function template's return
type
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: widman at gimpel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28044
build problem...
I assume I'm not the only one seeing this build failure: make[5]: Entering directory `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools' /bin/sh ../libtool --mode=link /build/gcc/2006-06-15/./gcc/xgcc -B/build/gcc/2006-06-15/./gcc/ -B/install/gcc/i686-pc-linux-gnu/bin/ -B/install/gcc/i686-pc-linux-gnu/lib/ -isystem /install/gcc/i686-pc-linux-gnu/include -isystem /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2-o gappletviewer -L/install/gcc/lib -lgcj gappletviewer-toolwrapper.o /build/gcc/2006-06-15/./gcc/xgcc -B/build/gcc/2006-06-15/./gcc/ -B/install/gcc/i686-pc-linux-gnu/bin/ -B/install/gcc/i686-pc-linux-gnu/lib/ -isystem /install/gcc/i686-pc-linux-gnu/include -isystem /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2 -o gappletviewer gappletviewer-toolwrapper.o -L/install/gcc/lib -lgcj /usr/bin/ld: cannot find -lgcj collect2: ld returned 1 exit status make[5]: *** [gappletviewer] Error 1 make[5]: Leaving directory `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools' make[4]: *** [all] Error 2 make[4]: Leaving directory `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/build/gcc/2006-06-15' make: *** [all] Error 2 The same failure existed yesterday... Is a fix under way? this is stock mainline with no configuration options except --prefix=install/gcc Andrew
[Bug c++/28044] Non-template class function return type taken as template when declared in a function template's return type
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-15 18:31 --- This works correctly in 4.2.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28044
[Bug c++/28044] Non-template class function return type taken as template when declared in a function template's return type
--- Comment #2 from widman at gimpel dot com 2006-06-15 18:51 --- (In reply to comment #1) > This works correctly in 4.2.0. > Ok; should the fix be back-ported to earlier versions? If not I guess this should be a "WONTFIX". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28044
[Bug c/28045] New: Bitfield, &&, and optimization => bad code generation
This is a stripped-down bit of code representing a bad code generation problem
we've been having with XEmacs 21.5 + gcc 4.X + optimization. I can reproduce
with Fedora Core 5's packaging of gcc 4.1.1 on the x86_64 platform, and with
Ubuntu's packaging of gcc 4.0.3 on the i386 platform.
Compile the following code without optimization, and it reports that the
negation of 1 is -1, which is in bounds. Compile with any -O flag (confirmed
for -O, -O2, -O3, and -Os) and the code reports that the negation of 1 is -1,
which is out of bounds. If I break the && expression up into 2 consecutive if
statements to see which bound is supposedly violated, the optimized code
reports that -1 is within each bound individually.
Things that have no effect: int/long are interchangeable; the size of the "tag"
bitfield doesn't seem to matter, so long as the "tag" size and the "val" size
add up to "INT_BITS".
I also tried compiling with all of the flags turned on by -O, but without -O
itself. Good code is generated in that case.
#include
#define INT_BITS (sizeof(int) * 8)
#define MAX_VALUE (int)((1UL << (INT_BITS - 2)) - 1UL)
#define MIN_VALUE (-MAX_VALUE - 1)
struct tagged_int
{
int tag: 2;
int val: INT_BITS - 2;
};
static void
negate (struct tagged_int accum)
{
printf ("min = %d, max = %d\n", MIN_VALUE, MAX_VALUE);
printf ("The negation of 1 is %d, which is ", -(int)accum.val);
if (-(int)accum.val <= MAX_VALUE && -(int)accum.val >= MIN_VALUE) {
puts ("in bounds.");
} else {
puts ("out of bounds.");
}
}
int
main ()
{
struct tagged_int obj;
obj.tag = 0;
obj.val = 1L;
negate(obj);
return 0;
}
--
Summary: Bitfield, &&, and optimization => bad code generation
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Jerry dot James at usu dot edu
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28045
Re: build problem...
On Thu, 2006-06-15 at 14:14 -0400, Andrew MacLeod wrote: > I assume I'm not the only one seeing this build failure: > > > make[5]: Entering directory > `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools' > /bin/sh ../libtool --mode=link /build/gcc/2006-06-15/./gcc/xgcc > -B/build/gcc/2006-06-15/./gcc/ -B/install/gcc/i686-pc-linux-gnu/bin/ > -B/install/gcc/i686-pc-linux-gnu/lib/ -isystem > /install/gcc/i686-pc-linux-gnu/include -isystem > /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2-o gappletviewer > -L/install/gcc/lib -lgcj gappletviewer-toolwrapper.o > /build/gcc/2006-06-15/./gcc/xgcc -B/build/gcc/2006-06-15/./gcc/ > -B/install/gcc/i686-pc-linux-gnu/bin/ -B/install/gcc/i686-pc-linux-gnu/lib/ > -isystem /install/gcc/i686-pc-linux-gnu/include -isystem > /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2 -o gappletviewer > gappletviewer-toolwrapper.o -L/install/gcc/lib -lgcj > /usr/bin/ld: cannot find -lgcj > collect2: ld returned 1 exit status > make[5]: *** [gappletviewer] Error 1 Thank you Tom.. :-) Andrew
Re: build problem...
Andrew MacLeod wrote: On Thu, 2006-06-15 at 14:14 -0400, Andrew MacLeod wrote: I assume I'm not the only one seeing this build failure: make[5]: Entering directory `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools' /bin/sh ../libtool --mode=link /build/gcc/2006-06-15/./gcc/xgcc -B/build/gcc/2006-06-15/./gcc/ -B/install/gcc/i686-pc-linux-gnu/bin/ -B/install/gcc/i686-pc-linux-gnu/lib/ -isystem /install/gcc/i686-pc-linux-gnu/include -isystem /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2-o gappletviewer -L/install/gcc/lib -lgcj gappletviewer-toolwrapper.o /build/gcc/2006-06-15/./gcc/xgcc -B/build/gcc/2006-06-15/./gcc/ -B/install/gcc/i686-pc-linux-gnu/bin/ -B/install/gcc/i686-pc-linux-gnu/lib/ -isystem /install/gcc/i686-pc-linux-gnu/include -isystem /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2 -o gappletviewer gappletviewer-toolwrapper.o -L/install/gcc/lib -lgcj /usr/bin/ld: cannot find -lgcj collect2: ld returned 1 exit status make[5]: *** [gappletviewer] Error 1 Thank you Tom.. :-) :-( This patch of mine: 2006-06-13 Thomas Fitzsimmons <[EMAIL PROTECTED]> * configure: Regenerate. * Makefile.in: Regenerate. * configure.ac (--enable-plugin): New option. (ac_configure_args): Add --enable-tool-wrappers. (ac_configure_args): Add --disable-plugin unless --enable-plugin was specified. * gcj/Makefile.in: Regenerate. * sources.am (gnu_java_net_source_files): Add classpath/gnu/java/net/IndexListParser.java. (property_files): Remove ... caused a bootstrap failure on multilib architectures. A clean bootstrap did work for me on my x86 workstation, but I hadn't cleared out $prefix. I have a suspicion that the libjava configury reaches into $prefix during the bootstrap. In the future I'll be sure to clear $prefix before bootstrapping, and I'll also bootstrap on a multilib architecture (x86-64). Sorry for the inconvenience. For now I've reverted the part of the patch that was causing the failure. Tom
[Bug c/28045] Bitfield, &&, and optimization => bad code generation
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-15 20:04 --- Works for me on the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28045
Re: build problem...
On Thu, 2006-06-15 at 15:59 -0400, Thomas Fitzsimmons wrote: > Andrew MacLeod wrote: > > On Thu, 2006-06-15 at 14:14 -0400, Andrew MacLeod wrote: > >> I assume I'm not the only one seeing this build failure: > >> > >> > >> make[5]: Entering directory > >> `/build/gcc/2006-06-15/i686-pc-linux-gnu/libjava/classpath/tools' > >> /bin/sh ../libtool --mode=link /build/gcc/2006-06-15/./gcc/xgcc > >> -B/build/gcc/2006-06-15/./gcc/ -B/install/gcc/i686-pc-linux-gnu/bin/ > >> -B/install/gcc/i686-pc-linux-gnu/lib/ -isystem > >> /install/gcc/i686-pc-linux-gnu/include -isystem > >> /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2-o gappletviewer > >> -L/install/gcc/lib -lgcj gappletviewer-toolwrapper.o > >> /build/gcc/2006-06-15/./gcc/xgcc -B/build/gcc/2006-06-15/./gcc/ > >> -B/install/gcc/i686-pc-linux-gnu/bin/ > >> -B/install/gcc/i686-pc-linux-gnu/lib/ -isystem > >> /install/gcc/i686-pc-linux-gnu/include -isystem > >> /install/gcc/i686-pc-linux-gnu/sys-include -O2 -g -O2 -o gappletviewer > >> gappletviewer-toolwrapper.o -L/install/gcc/lib -lgcj > >> /usr/bin/ld: cannot find -lgcj > >> collect2: ld returned 1 exit status > >> make[5]: *** [gappletviewer] Error 1 > > > > Thank you Tom.. :-) > > :-( > > This patch of mine: <...> > caused a bootstrap failure on multilib architectures. A clean bootstrap did > work for me on my x86 workstation, but I hadn't cleared out $prefix. I have > a > suspicion that the libjava configury reaches into $prefix during the > bootstrap. > In the future I'll be sure to clear $prefix before bootstrapping, and I'll > also bootstrap on a multilib architecture (x86-64). > > Sorry for the inconvenience. For now I've reverted the part of the patch > that > was causing the failure. Actually, I just meant 'thank you' for fixing it so quickly after the note :-)
[Bug libgomp/28046] New: libgomp test pr27337.C fails intermittently
My mainline testing gets intermittent failures for test libgomp/testsuite/libgomp.g++/pr27337.c. Some of the failures are due to wrong counts from the constructor and destructor after the call to foo, and others are for wrong values of x.i (with values in the range 19-27) after the call to bar. The percentage of failures depends on which system I test on, but I haven't figured out the significant factors: CPU type, number of processors, binutils version, kernel version, load on the system I haven't studied omp programs; the failures could be due to errors in the test itself. The failures occur at all levels of optimization. I get this failure on powerpc*-linux (with both -m32 and -m64) and on x86_64-linux. -- Summary: libgomp test pr27337.C fails intermittently Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28046
[Bug debug/28047] New: DWARF output_file_names should really understand DOS pathnames
While doing some DWARF-related work, I noticed that output_file_names in dwarf2out.c parses filenames assuming they are UNIX, things like: /* Skip all leading "./". */ f = d->filename; while (f[0] == '.' && f[1] == '/') f += 2; I'm fairly sure it won't work right on DOS-style pathnames, even something as simple as \foo\bar.h won't be handled right. Probably all the filename handling in dwarf2out.c should be checked for related issues. -- Summary: DWARF output_file_names should really understand DOS pathnames Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: geoffk at gcc dot gnu dot org GCC target triplet: *-*-mingw http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28047
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #13 from malitzke at metronets dot com 2006-06-15 22:58 ---
Hans_Peter
Your, not mine, concern seems to be comment 3. For that you have to contact
Pinski. I saw a number os inconsitencies in his comments and after the
reception got did not want to pursue this further. My problem got solved as
follows:
Typescript
for i in `find -name 'bug.h*'` ; do grep -e '\ "i"\ ' $i && echo $i ; done
: : "i" (__LINE__), "i" (__FILE__)); \
: : "r" ((long)(x)), "i" (__LINE__),\
"i" (__FILE__));\
"i" (__LINE__ + BUG_WARNING_TRAP), \
"i" (__FILE__));\
./asm-powerpc/bug.h
: : "i" (__LINE__), "i" (__FILE__), "i" (__FUNCTION__)); \
: : "r" ((long)(x)), "i" (__LINE__),\
"i" (__FILE__), "i" (__FUNCTION__));\
"i" (__LINE__ + BUG_WARNING_TRAP), \
"i" (__FILE__), "i" (__FUNCTION__));\
./asm-powerpc/bug.h.org
"i"(__LINE__), "i" (__FILE__))
./asm-x86_64/bug.h
: : "i" (PAL_bugchk), "i"(__LINE__), "i"(__FILE__))
./asm-alpha/bug.h
: : "i" (__LINE__), "i" (__FILE__))
./asm-i386/bug.h
__asm__ __volatile__("break %0" : : "i" (BRK_BUG)); \
./asm-mips/bug.h
The pertinent patch is on file in my PR to bugzilla.kernel.org.
The problem turned up a week or so before I filed PR 27528, and after
considerable rs6000 changes made by David Edelsohn.
To me this is a matter for the GCC community to solve and not for a non
compiler expert like myself. I am just a user as defined by the steering
committee.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
Re: [Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
> The problem turned up a week or so before I filed PR 27528, and after > considerable rs6000 changes made by David Edelsohn. The change just exposed a latent bug. I am trying to make sure that you understand that and not blaming David. Could someone please CC Richard Sandiford, if he is not already since -fsection-anchors is his creation. -- Pinski
[Bug middle-end/27528] compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code
--- Comment #14 from pinskia at physics dot uc dot edu 2006-06-15 23:03 --- Subject: Re: compiling linux kernels 2.6.16.14/15 2.6.17-rc3 on powerpc (7450) get error on long exixting code > The problem turned up a week or so before I filed PR 27528, and after > considerable rs6000 changes made by David Edelsohn. The change just exposed a latent bug. I am trying to make sure that you understand that and not blaming David. Could someone please CC Richard Sandiford, if he is not already since -fsection-anchors is his creation. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
[Bug fortran/27786] [4.1 only] Bad interaction between Cray pointer, assumed-size array and bounds checking
--- Comment #6 from langton at gcc dot gnu dot org 2006-06-15 23:07 --- Subject: Bug 27786 Author: langton Date: Thu Jun 15 23:07:14 2006 New Revision: 114692 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114692 Log: PR fortran/27786 * cray_pointers_2.f90: Add -fbounds-check compile flag. PR fortran/27786 * trans-array.c (gfc_conv_array_ref): Eliminate bounds checking for assumed-size Cray pointees. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-array.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/cray_pointers_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27786
[Bug fortran/27786] [4.1 only] Bad interaction between Cray pointer, assumed-size array and bounds checking
--- Comment #7 from langton at gcc dot gnu dot org 2006-06-15 23:11 --- I've backported the patch to 4.1, so this bug should be resolved. -- langton at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27786
[Bug target/25272] gcc fails to compile for target h8300-hitachi-hms with unrecognizable insn
--- Comment #4 from flameeyes at gentoo dot org 2006-06-15 23:30 --- This is still an issue in 4.1.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25272
[Bug target/20802] [4.0] mmix-knuth-mmixware testsuite failure: gcc.dg/builtin-apply4.c execution
--- Comment #6 from sje at cup dot hp dot com 2006-06-15 23:46 --- I believe I understand why this test fails on IA64. It may or may not be the same issue as on mmix. See http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00864.html for more info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20802
[Bug c++/27665] [4.0/4.1 regression] ICE writing class instead of typename
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-06-15 23:47 --- Subject: Bug 27665 Author: mmitchel Date: Thu Jun 15 23:47:15 2006 New Revision: 114694 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114694 Log: PR c++/27665 * parser.c (cp_parser_unqualified_id): Use constructor_name_p to identify destructors. (cp_parser_nested_name_specifier_opt): Remove invalid optimization. (cp_parser_template_id): Refine heuristic for determining whether we are entering a scope. PR c++/27665 * g++.dg/template/crash52.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/template/crash52.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/parser.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27665
[Bug c++/27665] [4.0 regression] ICE writing class instead of typename
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-06-15 23:47 --- Fixed in 4.1.2. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1 regression] ICE|[4.0 regression] ICE writing |writing class instead of|class instead of typename |typename| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27665
[Bug c++/28016] [4.2 Regression] emitting template constant
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
[Bug c++/27952] [4.0/4.1/4.2 Regression] ICE with invalid virtual inheritance
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27952
[Bug c++/27961] [4.1/4.2 regression] ICE on invalid template declaration
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27961
[Bug c++/27977] [4.0/4.1/4.2 Regression] ICE when declaring recursive member in std namespace (illegal code)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27977
[Bug c++/27979] [4.2 Regression] conversion check confused by enum bitfields
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27979
[Bug c++/28048] New: ICC on accessing member of dependent name
The testcase below generates a segmentation fault in g++ 4.0.0 to 4.2.0.
/tmp/test.cpp:3: internal compiler error: Segmentation fault
--GCC Info--
Version: g++ (GCC) 4.2.0 20060615 (experimental) SVN revision 114692
(Also tested on g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8))
Configure command: ../configure --prefix=`pwd`/../install
--enable-languages=c++
System: Linux 2.6.16-1.2111_FC4 #1 Sat May 20 19:59:40 EDT 2006 i686 i686 i386
GNU/Linux
--Testcase--
template struct Boom;
template::Internal::Value> // <--ICE
struct Foo
{
};
template struct Boom
{
struct Internal
{
static const bool Value = false;
};
};
--
Summary: ICC on accessing member of dependent name
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc dot gnu dot org at chosenones dot dyndns dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28048
[Bug objc/28049] New: [4.1/4.2 regression] ICE on single +
The following invalid code snippet causes an ICE since GCC 4.1.0: == + == bug.m:1: error: expected ':' at end of input bug.m:1: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] -- Summary: [4.1/4.2 regression] ICE on single + Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: objc 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=28049
[Bug c++/27640] [4.2 Regression] segfault, related to constructor instantiation and virtual base case and templates and new operator
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-06-16 02:09 --- Subject: Bug 27640 Author: mmitchel Date: Fri Jun 16 02:09:10 2006 New Revision: 114701 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114701 Log: PR c++/27640 * pt.c (instantiate_template): Set processing_template_decl to zero while performing substitutions. PR c++/27640 * g++.dg/template/ctor7.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/ctor7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27640
[Bug objc/28050] New: [4.1/4.2 regression] ICE on invalid initializer
The following invalid code snippet causes an ICE since GCC 4.1.0: == int i = [0]; == bug.m:1: error: expected ':' before ']' token bug.m:1: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] This also happens with the objc++ frontend. -- Summary: [4.1/4.2 regression] ICE on invalid initializer Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: objc 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=28050
[Bug c++/27640] [4.2 Regression] segfault, related to constructor instantiation and virtual base case and templates and new operator
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-16 02:11 --- Fixed in 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27640
[Bug c++/28051] New: [4.0/4.1/4.2 regression] ICE on invalid conversion operator
The following invalid code snippet causes an ICE since GCC 3.4.0:
template struct A {};
template struct B : A
{
using A::operator typename A::X;
};
B<0> b;
bug.cc: In instantiation of 'B<0>':
bug.cc:8: instantiated from here
bug.cc:5: error: no type named 'X' in 'struct A<0>'
bug.cc:5: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in mangle_conv_op_name_for_type, at cp/mangle.c:2826
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 regression] ICE on invalid conversion
operator
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=28051
[Bug fortran/27954] ICE on garbage in DATA statement
--- Comment #9 from reichelt at gcc dot gnu dot org 2006-06-16 02:23 --- Confirmed as the bug was reproduced by Steve. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-16 02:23:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug c++/27666] [4.0/4.1/4.2 regression] ICE with volatile in conditional expression
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-16 02:33 --- Subject: Bug 27666 Author: mmitchel Date: Fri Jun 16 02:33:35 2006 New Revision: 114702 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114702 Log: PR c++/27666 * call.c (build_conditional_expr): Robustify. PR c++/27666 * g++.dg/expr/cond9.C: New test. Added: trunk/gcc/testsuite/g++.dg/expr/cond9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27666
[Bug c++/27666] [4.0/4.1 regression] ICE with volatile in conditional expression
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-06-16 02:36 --- Fixed in 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1 regression] ICE |with volatile in conditional|with volatile in conditional |expression |expression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27666
[Bug c++/28052] New: [4.2 regression] ICE on invalid bitfield
The following invalid code snippet causes an ICE on mainline:
struct A
{
double d : 2;
A() {}
};
bug.cc:3: error: bit-field 'double A::d' with non-integral type
bug.cc: In constructor 'A::A()':
bug.cc:4: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in perform_member_init, at cp/init.c:350
Please submit a full bug report, [etc.]
Replacing the constructor by a destructor I get:
struct A
{
double d : 2;
~A() {}
};
bug.cc:3: error: bit-field 'double A::d' with non-integral type
bug.cc: In destructor 'A::~A()':
bug.cc:4: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in push_base_cleanups, at cp/init.c:2903
Please submit a full bug report, [etc.]
This is a very recent regression (GCC 4.2.0 20060527 was not affected).
--
Summary: [4.2 regression] ICE on invalid bitfield
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=28052
[Bug c++/28053] New: [4.2 regression] ICE deriving from class with invalid bitfield
The following invalid code snippet causes an ICE on mainline:
struct X {};
struct A
{
X x : 2;
};
struct B : A {};
bug.cc:5: error: bit-field 'X A::x' with non-integral type
bug.cc:8: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
This is a very recent regression (GCC 4.2.0 20060527 was not affected).
--
Summary: [4.2 regression] ICE deriving from class with invalid
bitfield
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=28053
[Bug c++/28054] New: [4.2 regression] ICE with friend declaration of invalid bitfield
The following invalid code snippet causes an ICE on mainline:
struct A;
struct B
{
friend A : 2;
};
bug.cc:5: error: name 'A' has incomplete type
bug.cc:5: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'error_mark' in grokbitfield, at cp/decl2.c:970
Please submit a full bug report, [etc.]
--
Summary: [4.2 regression] ICE with friend declaration of invalid
bitfield
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=28054
[Bug c++/27689] [4.1/4.2 regression] function template incorrectly selected as candidate
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27689
[Bug c++/27693] [4.0/4.1 Regression] strange interaction with const and sizeof and variable declarations in g++-4.0
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-06-16 03:30 --- Fixed in 4.2.0, perhaps by the fix for PR c++/20103. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] strange |strange interaction with|interaction with const and |const and sizeof and|sizeof and variable |variable declarations in|declarations in g++-4.0 |g++-4.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27693
[Bug target/28055] New: [SH] a function attributed to weak is discarded, if '-O' is specified
I tested using gcc-3.4.6 and gcc-4.1.1. The code generated by gcc-4.1.1 is
wrong, because a function attributed to weak is discarded by optimization.
I wander if this problem is gcc4's specification because I can see same problem
with gcc-4.1.1 for PowerPC.
The source code is as follows. The command line is "sh4-linux-gcc -S testcase.c
-O".
void __attribute__ ((weak))
arch_init_clk_ops()
{
}
void clk_init(void)
{
arch_init_clk_ops();
}
The result for gcc-4.1.1:
.weak arch_init_clk_ops
.type arch_init_clk_ops, @function
arch_init_clk_ops:
mov.l r14,@-r15
mov r15,r14
mov r14,r15
mov.l @r15+,r14
rts
nop
.size arch_init_clk_ops, .-arch_init_clk_ops
.align 1
.global clk_init
.type clk_init, @function
clk_init:
mov.l r14,@-r15
mov r15,r14# arch_init_clk_op can not be called
mov r14,r15
mov.l @r15+,r14
rts
nop
The result for gcc-3.4.6:
arch_init_clk_ops:
mov.l r14,@-r15
sts.l pr,@-r15
mov r15,r14
mov r14,r15
lds.l @r15+,pr
rts
mov.l @r15+,r14
.size arch_init_clk_ops, .-arch_init_clk_ops
.align 1
.global clk_init
.type clk_init, @function
clk_init:
mov.l r14,@-r15
sts.l pr,@-r15
mov.l .L3,r1
jsr @r1
mov r15,r14
mov r14,r15
lds.l @r15+,pr
rts
mov.l @r15+,r14
.L4:
.align 2
.L3:
.long arch_init_clk_ops
--
Summary: [SH] a function attributed to weak is discarded, if '-O'
is specified
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: saito at densan dot co dot jp
GCC build triplet: sh4-linux
GCC host triplet: sh4-linux
GCC target triplet: sh4-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28055
[Bug c++/27689] [4.1/4.2 regression] function template incorrectly selected as candidate
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-06-16 06:08 --- Subject: Bug 27689 Author: mmitchel Date: Fri Jun 16 06:08:49 2006 New Revision: 114703 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114703 Log: PR c++/27689 * cp-tree.h (CLASSTYPE_SPECIALIZATION_OF_PRIMARY_TEMPLATE_P): New macro. * pt.c (unify): Use it. PR c++/27689 * g++.dg/template/ttp18.C: New test. * g++.dg/template/ttp19.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/template/ttp18.C trunk/gcc/testsuite/g++.dg/template/ttp19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27689
[Bug c++/27666] [4.0/4.1 regression] ICE with volatile in conditional expression
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-06-16 06:09 --- Subject: Bug 27666 Author: mmitchel Date: Fri Jun 16 06:09:14 2006 New Revision: 114704 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114704 Log: PR c++/27666 * call.c (build_conditional_expr): Robustify. PR c++/27666 * g++.dg/expr/cond9.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/expr/cond9.C Modified: branches/gcc-4_1-branch/gcc/cp/call.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27666
[Bug c++/27666] [4.0/4.1 regression] ICE with volatile in conditional expression
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-16 06:10 --- Subject: Bug 27666 Author: mmitchel Date: Fri Jun 16 06:09:55 2006 New Revision: 114705 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114705 Log: PR c++/27666 * call.c (build_conditional_expr): Robustify. PR c++/27666 * g++.dg/expr/cond9.C: New test. Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27666
[Bug c++/27666] [4.0 regression] ICE with volatile in conditional expression
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1 regression] ICE|[4.0 regression] ICE with |with volatile in conditional|volatile in conditional |expression |expression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27666
[Bug c++/27689] [4.1 regression] function template incorrectly selected as candidate
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-06-16 06:25 --- Fixed in 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression]|[4.1 regression] function |function template |template incorrectly |incorrectly selected as |selected as candidate |candidate | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27689
