[Bug rtl-optimization/30643] [4.1/4.2/4.3 regression] CSE pessimization
--- Comment #16 from patchapp at dberlin dot org 2007-03-13 07:30 --- Subject: Bug number PR30643 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00815.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
[Bug debug/29906] [4.0/4.1/4.2/4.3 Regression] -g option creates internal compiler error
--- Comment #6 from aoliva at gcc dot gnu dot org 2007-03-13 07:56 --- On it. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29906
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #5 from brooks at gcc dot gnu dot org 2007-03-13 08:11 --- I believe that all of the nonstandard intrinsics have now been documented in 4.2 and 4.3, and thus I am closing this bug as fixed. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #6 from brooks at gcc dot gnu dot org 2007-03-13 08:47 --- This bug was erroneously closed. The following intrinsics are undocumented in 4.2: INT2, SHORT INT8, LONG MCLOCK MCLOCK8 SECOND The relevant bits of intrinsic.c: add_sym_1 (int2, ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_GNU, gfc_check_intconv, gfc_simplify_int2, gfc_resolve_int2, a, BT_REAL, dr, REQUIRED); make_alias (short, GFC_STD_GNU); make_generic (int2, GFC_ISYM_INT2, GFC_STD_GNU); add_sym_1 (int8, ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_GNU, gfc_check_intconv, gfc_simplify_int8, gfc_resolve_int8, a, BT_REAL, dr, REQUIRED); make_generic (int8, GFC_ISYM_INT8, GFC_STD_GNU); add_sym_1 (long, ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_GNU, gfc_check_intconv, gfc_simplify_long, gfc_resolve_long, a, BT_REAL, dr, REQUIRED); make_generic (long, GFC_ISYM_LONG, GFC_STD_GNU); add_sym_0 (mclock, ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_GNU, NULL, NULL, gfc_resolve_mclock); make_generic (mclock, GFC_ISYM_MCLOCK, GFC_STD_GNU); add_sym_0 (mclock8, ELEMENTAL, ACTUAL_NO, BT_INTEGER, di, GFC_STD_GNU, NULL, NULL, gfc_resolve_mclock8); make_generic (mclock8, GFC_ISYM_MCLOCK8, GFC_STD_GNU); add_sym_0 (second, NOT_ELEMENTAL, ACTUAL_NO, BT_REAL, 4, GFC_STD_GNU, NULL, NULL, NULL); make_generic (second, GFC_ISYM_SECOND, GFC_STD_GNU); -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED Last reconfirmed|2006-06-16 23:51:33 |2007-03-13 08:48:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #7 from brooks at gcc dot gnu dot org 2007-03-13 09:00 ---
Relevant pieces of trans-intrinsic.c:
/* Integer conversions are handled separately to make sure we get the
correct rounding mode. */
case GFC_ISYM_INT:
case GFC_ISYM_INT2:
case GFC_ISYM_INT8:
case GFC_ISYM_LONG:
gfc_conv_intrinsic_int (se, expr, FIX_TRUNC_EXPR);
break;
case GFC_ISYM_MCLOCK:
case GFC_ISYM_MCLOCK8:
case GFC_ISYM_SECOND:
gfc_conv_intrinsic_funcall (se, expr);
break;
Relevant bits of iresolve.c:
void
gfc_resolve_int2 (gfc_expr * f, gfc_expr * a)
{
f-ts.type = BT_INTEGER;
f-ts.kind = 2;
f-value.function.name =
gfc_get_string (__int_%d_%c%d, f-ts.kind, gfc_type_letter (a-ts.type),
a-ts.kind);
}
void
gfc_resolve_int8 (gfc_expr * f, gfc_expr * a)
{
f-ts.type = BT_INTEGER;
f-ts.kind = 8;
f-value.function.name =
gfc_get_string (__int_%d_%c%d, f-ts.kind, gfc_type_letter (a-ts.type),
a-ts.kind);
}
void
gfc_resolve_long (gfc_expr * f, gfc_expr * a)
{
f-ts.type = BT_INTEGER;
f-ts.kind = 4;
f-value.function.name =
gfc_get_string (__int_%d_%c%d, f-ts.kind, gfc_type_letter (a-ts.type),
a-ts.kind);
}
void
gfc_resolve_mclock (gfc_expr * f)
{
f-ts.type = BT_INTEGER;
f-ts.kind = 4;
f-value.function.name = PREFIX(mclock);
}
void
gfc_resolve_mclock8 (gfc_expr * f)
{
f-ts.type = BT_INTEGER;
f-ts.kind = 8;
f-value.function.name = PREFIX(mclock8);
}
/* G77 compatibility subroutine second(). */
void
gfc_resolve_second_sub (gfc_code * c)
{
const char *name;
name = gfc_get_string (PREFIX(second_sub));
c-resolved_sym = gfc_get_intrinsic_sub_symbol (name);
}
Relevant part of intrinsics/cpu_time.c:
void
second_sub (GFC_REAL_4 *s)
{
cpu_time_4 (s);
}
extern GFC_REAL_4 second (void);
export_proto(second);
GFC_REAL_4
second (void)
{
GFC_REAL_4 s;
cpu_time_4 (s);
return s;
}
Note that cpu_time_4 is the kind=4 variant of CPU_TIME.
--
brooks at gcc dot gnu dot org changed:
What|Removed |Added
CC||brooks at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/31160] New: %VAL and related features need to be documented.
As in the subject line; this feature was added (thanks, Paul!) but the documentation is still pending. -- Summary: %VAL and related features need to be documented. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: fortran AssignedTo: pault at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31160
[Bug fortran/30953] intrinsic: CTIME
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-03 10:24:56 |2007-03-13 09:09:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30953
[Bug debug/29906] [4.0/4.1/4.2/4.3 Regression] -g option creates internal compiler error
--- Comment #7 from patchapp at dberlin dot org 2007-03-13 09:14 --- Subject: Bug number PR29906 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00817.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29906
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #8 from brooks at gcc dot gnu dot org 2007-03-13 09:15 ---
Relevant parts of libgfortran/clock.c:
GFC_INTEGER_4
mclock (void)
{
#ifdef HAVE_CLOCK
return (GFC_INTEGER_4) clock ();
#else
return (GFC_INTEGER_4) -1;
#endif
}
GFC_INTEGER_8
mclock8 (void)
{
#ifdef HAVE_CLOCK
return (GFC_INTEGER_8) clock ();
#else
return (GFC_INTEGER_8) -1;
#endif
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug c/31161] New: __builtin_cexpi is broken on Darwin
When compiled with gcc version 4.3.0 20070309, the following code
#include math.h
#include stdio.h
int main()
{
__complex__ double x;
__real__ x = -1.0;
__imag__ x = 0.0;
__complex__ double t = __builtin_clog(x);
double tmp = 0.5 * (__imag__ t);
x = __builtin_cexpi(tmp);
printf(%g %g\n, (__real__ x), (__imag__ x));
printf(%g %g\n, cos(tmp), sin(tmp));
}
gives an ICE:
failure_v2.c: In function 'main':
failure_v2.c:15: internal compiler error: in expand_builtin_cexpi, at
builtins.c:2380
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
It compiles with g++ and without optimization gives:
[karma] bug/cexp_pb% g++-4 failure_v2.c
[karma] bug/cexp_pb% a.out
-1 1.22465e-16
6.12323e-17 1
where the last line is the expected result. With -O1 the result is:
[karma] bug/cexp_pb% g++-4 -O1 failure_v2.c
[karma] bug/cexp_pb% a.out
-1 1.22465e-16
-1 1.22465e-16
this is PR30980!-(
--
Summary: __builtin_cexpi is broken on Darwin
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
GCC target triplet: powerpc-apple-darwin7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug tree-optimization/31130] [4.3 Regression] VRP no longer derives range for division after negation
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-13 09:30 --- How tracking _two_ value ranges for signed quantities with undefined overflow. One assuming it is undefined and one with wrapping semantics. Whenever you fold something using the value range you warn if the folding result would differ if using either or the other variant, if they do not differ, don't warn. This way you don't affect existing optimizations and strictly warn in the case the transformation is done taking advantage of the undefined overflow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31130
[Bug target/31152] -(xy) generates wrong code
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-13 10:20 --- It works for me on x86_64 and i686 with 4.0.0, 4.1.0 and 4.1.2. So this looks like a target issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31152
[Bug c++/31158] wrong line number in warning: overflow in implicit constant conversion
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31158
[Bug c++/31157] [4.2/4.3 Regression] Bitfield is not promoted
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-13 10:26 --- This has been fixed on the branch by the patch for PR30274. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30274 Status|UNCONFIRMED |RESOLVED Keywords||rejects-valid Known to work||4.1.2 Resolution||FIXED Summary|Bitfield is not promoted|[4.2/4.3 Regression] ||Bitfield is not promoted Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31157
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #42 from baldrick at free dot fr 2007-03-13 10:30 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails It is not possible for a pointer value to be uninitialized. The language requires all pointers to be default initialized to null. I mean the thing that pointer points to! I think I now understand: I thought the problem we were discussing was how to obtain correctness (which seems to be easy using local checks) while in fact you were talking about how to optimize away unnecessary validity checks (as compared to normal checks). My current plan for that in LLVM is to implement validity checks using a builtin_nop intrinsic. Multiple successive validity checks will be eliminated as redundant because builtin_nop is a pure function. That leaves the question of how to teach the optimizers that an object is valid in the various cases where the front-end for some reason knows this. In such cases I'm thinking that you can issue an assert instruction saying so, eg if type T has range 10..20 and at some point the front-end knows that x (of type T) is valid, it can issue: assert(builtin_nop(x)=10 builtin_nop(x)=20); The dataflow and predicate analysis needed to exploit this can hopefully be left to the optimizers, in particular to IPO (which LLVM is rather good at). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-13 10:30 --- It's a target issue. Darwin is broken that it doesn't set TARGET_C99_FUNCTIONS but still appears to have cexp. Your testcase is also invalid for this reason, you should not use __builtin_cexpi if neither sincos nor cexp is available. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-13 10:58 ---
Subject: Re: __builtin_cexpi is broken on Darwin
you should not use __builtin_cexpi if neither sincos nor cexp is available.
Yes indeed, but an ICE is certainly not the best way to say it!
Now I have tested __builtin_cexpi, not because I want to use it, but because
it is used by the optimizer with a wrong result I would like to see fixed
ASAP.
Note that __builtin_cexp is available on Darwin and seems to work:
#include math.h
#include stdio.h
int main()
{
__complex__ double x;
__real__ x = -1.0;
__imag__ x = 0.0;
__complex__ double t = __builtin_clog(x);
double tmp = 0.5 * (__imag__ t);
x = __builtin_cexp(0.5*t);
printf(%g %g\n, (__real__ x), (__imag__ x));
printf(%g %g\n, cos(tmp), sin(tmp));
}
gives with gcc and with or without optimization:
6.12323e-17 1
6.12323e-17 1
while when compiled with g++ -O1, it gives:
6.12323e-17 1
-1 1.22465e-16
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu
--- Comment #23 from martin dot jansa at mk dot cvut dot cz 2007-03-13 11:45 --- (In reply to comment #22) This is a bug in the gentoo distro ask them to fix how they do multilib. so results are (with gcc-4.3) #include_next stdio.h - doesn't work #include stdio.h - doesn't work #include stdio - doesn't work #include /usr/include/stdio.h - works #include /usr/include/gentoo-multilib/amd64/stdio.h - works when /usr/include/stdio.h works then it shouldn't be distro multilib bug, should it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30915
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #43 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-13 12:33 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails I think I now understand: I thought the problem we were discussing was how to obtain correctness (which seems to be easy using local checks) while in fact you were talking about how to optimize away unnecessary validity checks (as compared to normal checks). Yes, I was talking about both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #10 from dominiq at lps dot ens dot fr 2007-03-13 12:56 ---
The problem seems to come from a broken/unavailable __builtin_cexpi,
see PR31161.
My understanding is that __builtin_cexpi and __builtin_sincos are twin
objects(?). Now I see in gcc/tree-ssa-math-opts.c:
...
static bool
gate_cse_sincos (void)
{
/* Make sure we have either sincos or cexp. */
return (TARGET_HAS_SINCOS
|| TARGET_C99_FUNCTIONS)
optimize;
}
struct tree_opt_pass pass_cse_sincos =
{
sincos, /* name */
gate_cse_sincos, /* gate */
execute_cse_sincos, /* execute */
NULL, /* sub */
NULL, /* next */
0,/* static_pass_number */
0,/* tv_id */
PROP_ssa, /* properties_required */
0,/* properties_provided */
0,/* properties_destroyed */
0,/* todo_flags_start */
TODO_dump_func | TODO_update_ssa | TODO_verify_ssa
| TODO_verify_stmts,/* todo_flags_finish */
0 /* letter */
};
...
And TARGET_C99_FUNCTIONS is set to 1 on Darwin - gate_cse_sincos returns
true even if TARGET_HAS_SINCOS is 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-03-13 13:22 --- Because if TARGET_C99_FUNCTIONS is set we can expand __builtin_cexpi by using cexp(). The ICE you get in PR30969 shows that TARGET_C99_FUNCTIONS is _not_ set: /* We can expand via the C99 cexp function. */ gcc_assert (TARGET_C99_FUNCTIONS); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #12 from rguenth at gcc dot gnu dot org 2007-03-13 13:26 --- Now, 2007-02-05 Roger Sayle [EMAIL PROTECTED] * fold-const.c (fold_unary) REAL_PART: Test for availability of BUILT_IN_COS before simplifying REAL_PART(CEXPI)) to COS. IMAG_PART: Likewise, check for availability of BUILT_IN_SIN. * builtins.c (fold_builtin_sincos): Check for TARGET_C99_FUNCTIONS before canonicalizing sincos to cexpi. (fold_builtin_cexp): Likewise, for canonicalizing cexp to cexpi. is too conservative in the sense that we can expand __builtin_cexpi if either TARGET_HAS_SINCOS or TARGET_C99_FUNCTIONS. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||roger at eyesopen dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #7 from krebbel at gcc dot gnu dot org 2007-03-13 13:26 --- ICE can be observed on s390 and s390x as well. http://gcc.gnu.org/ml/gcc/2007-03/msg00357.html -- krebbel at gcc dot gnu dot org changed: What|Removed |Added CC||krebbel at gcc dot gnu dot ||org Last reconfirmed|2007-03-11 10:15:23 |2007-03-13 13:26:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-13 13:39 --- Created an attachment (id=13199) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13199action=view) patch for a better error Can you check if the attached patch gives a more reasonable error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug target/31161] __builtin_cexpi is broken on Darwin
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-13 13:53 --- With a cross compiler to powerpc-apple-darwin7 I now get for the testcase: gcc ./cc1 -quiet t.i t.i: In function 'main': t.i:13: warning: incompatible implicit declaration of built-in function 'printf' t.i:12: sorry, unimplemented: no way to expand a call to 'cexpi' no idea if that's better ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31161
[Bug fortran/31162] New: missing warning for real do-loops with implicit typed variables
real r do r=1.0,2.0 print*,r enddo end gives legacy.f:2.10: do r=1.0,2.0 1 Warning: Obsolete: REAL DO loop iterator at (1) which is ok, however do r=1.0,2.0 print*,r enddo end compiles without warning! the same for implicit real(a-z) do r=1.0,2.0 print*,r enddo end Additionally: It seems this warning is tied to -std=legacy, perhaps it would make more sense to tie it to -Wsurprising as it was the case for g77. -- Summary: missing warning for real do-loops with implicit typed variables Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: manfred99 at gmx dot ch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31162
[Bug fortran/31163] New: SAVEd derived types with ALLOCATABLE components don't work
The output from the attached code looks wrong, as if the derived type components are not SAVEd. -output- [EMAIL PROTECTED] bugtest]$ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3-20070302/configure --prefix=/usr/local/gcc43 --with-mpfr=/home/travel/GCC/BUILDS/mpfr --with-gmp-lib=/home/travel/GCC/BUILDS/gmp/lib/ --with-gmp=/home/travel/GCC/BUILDS/gmp Thread model: posix gcc version 4.3.0 20070302 (experimental) [EMAIL PROTECTED] bugtest]$ ./savebug After first call0 After second call0 - output with Intel fortran - [EMAIL PROTECTED] bugtest]$ ifort -o savebug savebug.f90 [EMAIL PROTECTED] bugtest]$ ./savebug After first call0 After second call 10 -- Summary: SAVEd derived types with ALLOCATABLE components don't work Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it 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=31163
[Bug fortran/31163] SAVEd derived types with ALLOCATABLE components don't work
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-13 14:33 ---
Andrew wrote:
--
it is obvious from the tree dump, what is going on:
static struct foo_type f_a = {};
f_a.mv.data = 0B;
So save is done correctly but allocatables in the derived type is not.
Even at the end of the function:
{
int4 D.965;
_gfortran_deallocate (f_a.mv.data, D.965);
f_a.mv.data = 0B;
}
So it deallocates it.
-
And I wrote:
-
It seems to be related to allocatable
components as if I change them to pointers (incl. =NULL initialization
and allocated - associated), it works.
Pointer:
static struct foo_type f_a = {.mv={.data=0B}};
Allocatable:
static struct foo_type f_a = {};
f_a.mv.data = 0B;
That is: The 0B initialization happens always.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2007-03-13 14:33:24
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31163
[Bug target/30980] [4.3 Regression] Recent complex miscompilation
--- Comment #13 from dominiq at lps dot ens dot fr 2007-03-13 14:48 --- The ICE you get in PR30969 shows that TARGET_C99_FUNCTIONS is _not_ set: Is there a way to test it once the building directory is gone? In gcc/config/rs6000/darwin.h I read: ... /* Old versions of Mac OS/Darwin don't have C99 functions available. */ #undef TARGET_C99_FUNCTIONS #define TARGET_C99_FUNCTIONS\ (TARGET_64BIT \ || strverscmp (darwin_macosx_version_min, 10.3) = 0) ... I assumed that TARGET_C99_FUNCTIONS is set for 10.3 and above, but I may have overlooked something else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30980
[Bug fortran/31163] SAVEd derived types with ALLOCATABLE components don't work
--- Comment #1 from sfilippone at uniroma2 dot it 2007-03-13 14:25 --- Created an attachment (id=13200) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13200action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31163
[Bug fortran/31162] missing warning for real do-loops with implicit typed variables
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-03-13 14:58:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31162
[Bug c/29062] unclear diagnostic for declaration after label
--- Comment #6 from manu at gcc dot gnu dot org 2007-03-13 16:05 --- I think this is confirmed, we can try to do better. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-13 16:05:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29062
[Bug middle-end/30132] [4.1/4.2/4.3 Regression] ICE in find_lattice_value, at tree-complex.c:133
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-13 16:12 --- Created an attachment (id=13201) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13201action=view) patch which I need to retest and fix the last regression -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30132
[Bug c/30368] missing warning for dereferencing null pointer
--- Comment #6 from manu at gcc dot gnu dot org 2007-03-13 16:12 --- So the conclusion is that we should emit a warning for the undefinedness. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-13 16:12:46 date|| Summary|wrong result|missing warning for ||dereferencing null pointer http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30368
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #7 from spark at gcc dot gnu dot org 2007-03-13 16:15 --- tree-nrv code doesn't see: bb 2: retval.type = 0; because it only looks at GIMPLE_MODIFY with the operand 0 as the return value. In this case, there's GIMPLE_MODIFY of the component of the return value hence not all modification to the return value. The following patch seems to get around the problem: Index: tree-nrv.c === --- tree-nrv.c (revision 122871) +++ tree-nrv.c (working copy) @@ -163,6 +163,12 @@ tree_nrv (void) result_type)) return 0; } + else if (TREE_CODE (stmt) == GIMPLE_MODIFY_STMT + TREE_CODE (GIMPLE_STMT_OPERAND (stmt, 0)) == COMPONENT_REF + TREE_OPERAND (GIMPLE_STMT_OPERAND (stmt, 0), 0) == result) + /* If there's any MODIFY of component of RESULT, + then bail out. */ + return 0; } } I'm not sure this is sufficient - can there be any other gimple statement combination that modifies only part of RESULT ? -- spark at gcc dot gnu dot org changed: What|Removed |Added CC||spark at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug tree-optimization/29585] [4.2 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
-- dnovillo at gcc dot gnu dot org changed: What|Removed |Added CC|dnovillo at redhat dot com | AssignedTo|unassigned at gcc dot gnu |dnovillo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-25 05:09:36 |2007-03-13 16:16:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
[Bug c/30368] missing warning for dereferencing null pointer
--- Comment #7 from manu at gcc dot gnu dot org 2007-03-13 16:22 --- and as such, this is a duplicate of bug 16351. *** This bug has been marked as a duplicate of 16351 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30368
[Bug c/16351] NULL dereference warnings
--- Comment #9 from manu at gcc dot gnu dot org 2007-03-13 16:22 --- *** Bug 30368 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||lidaobing at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
[Bug middle-end/30984] [4.1/4.2/4.3 Regression] ICE with computed goto and constants
--- Comment #6 from law at redhat dot com 2007-03-13 16:33 --- Subject: Re: [4.1/4.2/4.3 Regression] ICE with computed goto and constants On Mon, 2007-03-12 at 23:46 +, spark at gcc dot gnu dot org wrote: --- Comment #4 from spark at gcc dot gnu dot org 2007-03-12 23:46 --- This little patch below seems to get around the problem, though I'm not really sure this is sufficient or not. FWIW, ADDR_EXPR needs to be handled as well. Otherwise you'll get testsuite regressions. New test cycle running now :-) jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984
[Bug c++/31164] New: Problem with GCC 4.1 and Boost signals
Hi, There is a problem when using slots trackable from Boost with GCC 4.1 - I don't know whether this is a GCC problem or a Boost problem, but it affects us (OpenWengo) on both Fedora Core and Feisty, since both distribute gcc 4.1. I'm attaching a test case - the expected output is: create A fire SGN A create B fire SGN A B delete A fire SGN B delete B fire SGN exit This doesn't happen :) What actually happens is that you get jibberish after fire SGN once you have deleted A, since the correct signal slot isn't selected. I'll attach the test case straight away. -- Summary: Problem with GCC 4.1 and Boost signals Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot neary at wengo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #1 from dave dot neary at wengo dot com 2007-03-13 16:49 --- Created an attachment (id=13202) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13202action=view) Test case to show problem with Boost and GCC 4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #2 from dave dot neary at wengo dot com 2007-03-13 16:50 --- Additional bug tracker entries have been created against Ubuntu: https://launchpad.net/ubuntu/+source/gcc-4.1/+bug/75724 and OpenSuse: https://bugzilla.novell.com/show_bug.cgi?id=228524 And against Boost: http://sourceforge.net/tracker/index.php?func=detailaid=1679990group_id=7586atid=107586 Dave. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-03-13 16:52 --- Use get_base_address (GIMPLE_STMT_OPERAND (stmt, 0)) == result. (Verify if get_base_address does not return NULL, if it's the result_decl, otherwise replicate the loop therein). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug middle-end/31159] [4.3 regression] ICE in gcc.c-torture/execute/20030323-1.c
-- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-13 17:47:31 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31159
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-13 17:54 --- And this duplicate doesn't add any useful information on top of what was entered into the novell bugzilla. Nobody here is going to wade through boost to understand what is going on here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #9 from spark at gcc dot gnu dot org 2007-03-13 18:29 ---
How does this one look ? If it looks reasonable, I'll start the testing with
the mainline.
Index: tree-nrv.c
===
--- tree-nrv.c (revision 122871)
+++ tree-nrv.c (working copy)
@@ -163,6 +163,14 @@ tree_nrv (void)
result_type))
return 0;
}
+ else if (TREE_CODE (stmt) == GIMPLE_MODIFY_STMT)
+ {
+ tree addr = get_base_address (GIMPLE_STMT_OPERAND (stmt, 0));
+ /* If there's any MODIFY of component of RESULT,
+ then bail out. */
+ if (addr addr == result)
+ return 0;
+ }
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug bootstrap/30899] [4.2/4.3 Regression] build failure with --enable-generated-files-in-srcdir
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|build failure with --enable-|[4.2/4.3 Regression] build |generated-files-in-srcdir |failure with --enable- ||generated-files-in-srcdir Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30899
[Bug middle-end/31159] [4.3 regression] ICE in gcc.c-torture/execute/20030323-1.c
--- Comment #1 from steven at gcc dot gnu dot org 2007-03-13 18:55 --- I believe this is the proper fix: Index: cfglayout.c === --- cfglayout.c (revision 122858) +++ cfglayout.c (working copy) @@ -697,7 +697,6 @@ fixup_reorder_chain (void) #ifdef ENABLE_CHECKING verify_insn_chain (); #endif - delete_dead_jumptables (); /* Now add jumps and labels as needed to match the blocks new outgoing edges. */ @@ -1193,6 +1192,9 @@ cfg_layout_finalize (void) fixup_fallthru_exit_predecessor (); fixup_reorder_chain (); + rebuild_jump_labels (get_insns ()); + delete_dead_jumptables (); + #ifdef ENABLE_CHECKING verify_insn_chain (); #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31159
[Bug target/31165] New: Error: symbol `an_empty_string' is already defined
While compiling groff with latest snapshot from GCC 4.2 branch. I am getting this error with the attached preprocessed file with optimization turned on (O2, O1 ,Os are ones I tried). At -O0 it works ok The error from assembler /tmp/ccOeOEGl.s: Assembler messages: /tmp/ccOeOEGl.s:5826: Error: symbol `an_empty_string' is already defined /tmp/ccOeOEGl.s:5830: Error: symbol `an_empty_string' is already defined /tmp/ccOeOEGl.s:5834: Error: symbol `an_empty_string' is already defined /tmp/ccOeOEGl.s:5838: Error: symbol `an_empty_string' is already defined /tmp/ccOeOEGl.s:5842: Error: symbol `an_empty_string' is already defined -- Summary: Error: symbol `an_empty_string' is already defined Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: raj dot khem at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: powerpc-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug c/31166] New: Integer hex constant does not follow promoting rules
Forgive me if this is reported/fixed already; after many consecutive hours of
debugging I currently do not have the courage to search through the list of
bugs.
Please, try this code (tested on 32bit GNU/Linux), compiled with:
gcc -std=c99 -Wall -Wextra -o wtf wtf.c
#include stdio.h
int main(void)
{
int n1, n2;
long long n3, n4;
n1 = -0x8000;
n2 = -2147483648;
n3 = -0x8000;
n4 = -2147483648;
printf(n1 = %d\n, n1);
printf(n2 = %d\n, n2);
printf(n3 = %lld\n, n3);
printf(n4 = %lld\n, n4);
return 0;
}
It consists of two int variables and two long long variables, all of them set
to the same value (-2147483648 == 0x8000). This is what I get:
n1 = -2147483648
n2 = -2147483648
n3 = 2147483648
n4 = -2147483648
What happened to n3? It appears that hex constants are not promoted to long
long the same way as decimal ones. AFAIK, this behavoir does not match C99
(neither C90).
When compiling without -std=c99, gcc gives this warning:
warning: this decimal constant is unsigned only in ISO C90
I think that gcc is trying to say that the constant does not fit on an int (nor
a long) and it is promoted to unsigned, as it is stated by ISO C90. But yes, it
should fit on an int, because -2147483648 = INT_MIN in this architecture.
Anyway, it is even more funny, because the warning is only for n2 and n4
(decimal constants) but not for n1 nor n4 (hex constants). This is the output
without -std=c99:
n1 = -2147483648
n2 = -2147483648
n3 = 2147483648
n4 = 2147483648
Tested with these versions of gcc:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --with-tune=i686
--enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --with-tune=pentium4 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
--
Summary: Integer hex constant does not follow promoting rules
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: roberto dot gordo at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
[Bug target/31165] Error: symbol `an_empty_string' is already defined
--- Comment #1 from raj dot khem at gmail dot com 2007-03-13 19:59 --- Created an attachment (id=13203) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13203action=view) testcase This is the preprocessed testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-13 20:10 --- That looks reasonable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-03-13 20:12 --- (In reply to comment #10) Thomas, it's a bit kludgy, but why not add a constant expression = 1, if dim is not present? Hi Paul, unless I'm mistaken, this would also change the rank of the function to 0, which FX explained is wrong. Do you have any idea what I cold do to turn this into an array? All the interesting gfc_conv_intrinsic_* functions have the if (se-ss) statement on top. Cheers, Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug c/31166] Integer hex constant does not follow promoting rules
--- Comment #1 from schwab at suse dot de 2007-03-13 20:22 --- 0x8000 is of type unsigned int, negating it gives an unsigned int of the same value, converted to long long still gives the same positive value. On the other hand 2147483648 is of type long long (in C99) because it does not fit in long, and gives -2147483648 as long long when negated. C90 does not have long long, so 2147483648 is undefined behaviour, and GCC chooses unsigned long since it fits there. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
[Bug c++/30108] [4.0/4.1 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-03-13 21:07 --- I think this patch causes the regression reported in PR 31165. copy_node is incorrect as it will even copy decls, I think copy_node should be replaced with unshare_expr instead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug c++/31165] [4.2/4.3 Regression] Error: symbol `an_empty_string' is already defined
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org BugsThisDependsOn||30108 Severity|normal |blocker Component|target |c++ GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|powerpc-*-linux-gnu | Summary| Error: symbol |[4.2/4.3 Regression] Error: |`an_empty_string' is already|symbol `an_empty_string' is |defined |already defined Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug c++/31165] [4.2/4.3 Regression] Error: symbol `an_empty_string' is already defined
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-13 21:11 --- Reducing, I think this was introduced by the patch which fixed PR 30108. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable
-- spark at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spark at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-01-25 20:11:47 |2007-03-13 21:26:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590
[Bug c/31167] New: ICE wnen using __int128_t on x86_64
The source below is meant to return an int32_t that is the result of rounding
the upper 32 bits of an __int128_t, where rounding pays attention to the bits
that have been discarded and the low bit of what is kept. Since it's an ICE,
the details are probably irrelevant.
[EMAIL PROTECTED] cat brokengcc.cxx
#include inttypes.h
int32_t round32hi(const __int128_t arg){
const int SHIFT = 96;
const int mshift = 96;
const __int128_t M = (~__int128_t(0))mshift;
const __int128_t L = (~M) + 1;
const __int128_t L1 = __int128_t(L)1;
const __int128_t Mlo = __int128_t(~M)1;
__int128_t vv = arg M;
if( (arg (L1)) // hi bit of discard set
( (arg Mlo) // and ( any other bits of discard set
|| (arg L) ) ) // or lo bit of keep set )
vv += L;
return int32_t(vvSHIFT);
}
[EMAIL PROTECTED] gcc -v -c -O brokengcc.cxx
Reading specs from
/proj/desres/root/Linux/x86_64/gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/specs
Target: x86_64-unknown-linux-gnu
Configured with: /state/partition1/tmp/tmpwsa5nr/gcc-4.1.2/configure
--enable-languages=c,c++,fortran
--prefix=/proj/desres/root/Linux/x86_64/gcc/4.1.2
Thread model: posix
gcc version 4.1.2
/proj/desres/root/Linux/x86_64/gcc/4.1.2/libexec/gcc/x86_64-unknown-linux-gnu/4.1.2/cc1plus
-quiet -v -D_GNU_SOURCE brokengcc.cxx -quiet -dumpbase brokengcc.cxx -mtune=k8
-auxbase brokengcc -O -version -o /scratch/tmp/ccer1yVv.s
ignoring nonexistent directory
/proj/desres/root/Linux/x86_64/gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/proj/desres/root/Linux/x86_64/gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2
/proj/desres/root/Linux/x86_64/gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2/x86_64-unknown-linux-gnu
/proj/desres/root/Linux/x86_64/gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward
/usr/local/include
/proj/desres/root/Linux/x86_64/gcc/4.1.2/include
/proj/desres/root/Linux/x86_64/gcc/4.1.2/lib/gcc/x86_64-unknown-linux-gnu/4.1.2/include
/usr/include
End of search list.
GNU C++ version 4.1.2 (x86_64-unknown-linux-gnu)
compiled by GNU C version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9975ef1eec7edce53d85d34b86837808
brokengcc.cxx: In function 'int32_t round32hi(const __int128_t)':
brokengcc.cxx:16: error: unrecognizable insn:
(insn 92 91 50 3 (parallel [
(set (reg:DI 38 r9 [ vv+8 ])
(plus:DI (plus:DI (ltu:DI (reg:CC 17 flags)
(const_int 0 [0x0]))
(reg:DI 38 r9 [ vv+8 ]))
(const_int 4294967296 [0x1])))
(clobber (reg:CC 17 flags))
]) -1 (nil)
(nil))
brokengcc.cxx:16: internal compiler error: in extract_insn, at recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
[EMAIL PROTECTED]
--
Summary: ICE wnen using __int128_t on x86_64
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot salmon at deshaw dot com
GCC build triplet: x86_64-unknown-linux-gnu
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=31167
[Bug c++/31165] [4.2/4.3 Regression] Error: symbol `an_empty_string' is already defined
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-13 21:35 ---
Reduced testcase:
class string {
char *ptr;
int len;
int sz;
};
class cset { } _cset_init;
string an_empty_string;
void f(string = an_empty_string);
void
h (void )
{
f();
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-03-13 21:35:15
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug c++/31165] [4.2/4.3 Regression] Error: symbol `an_empty_string' is already defined
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-13 21:36 --- I think this only shows up with section anchors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug c++/30108] [4.0/4.1 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-13 21:40 --- (In reply to comment #13) I think this patch causes the regression reported in PR 31165. copy_node is incorrect as it will even copy decls, I think copy_node should be replaced with unshare_expr instead. A quick run with that change, fixes 31165. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug c++/31165] [4.2/4.3 Regression] Error: symbol `an_empty_string' is already defined
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-03-13 21:40 --- A quick patch which I am testing right now: Index: cp/call.c === --- cp/call.c (revision 122871) +++ cp/call.c (working copy) @@ -4671,7 +4671,7 @@ VAR_DECL. We can avoid the copy for constants, since they are never modified in place. */ if (!CONSTANT_CLASS_P (arg)) - arg = copy_node (arg); + arg = unshare_expr (arg); arg = convert_for_initialization (0, type, arg, LOOKUP_NORMAL, default argument, fn, parmnum); arg = convert_for_arg_passing (type, arg); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31165
[Bug c++/30108] [4.0/4.1 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890
--- Comment #15 from mark at codesourcery dot com 2007-03-13 21:46 --- Subject: Re: [4.0/4.1 Regression] internal compiler error: in make_decl_rtl, at varasm.c:890 pinskia at gcc dot gnu dot org wrote: --- Comment #14 from pinskia at gcc dot gnu dot org 2007-03-13 21:40 --- (In reply to comment #13) I think this patch causes the regression reported in PR 31165. copy_node is incorrect as it will even copy decls, I think copy_node should be replaced with unshare_expr instead. A quick run with that change, fixes 31165. Thanks for that testing. That patch is pre-approved. If you don't want to handle it, let me know, and I will do it. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-13 21:48 --- pr23237.c on powerpc-linux-gnu at -O3 and above ICEs the same way. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|i586-suse-linux, i386- | |unknown-freebsd5.4,s390-ibm-| |linux,s390x-ib | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug target/31167] ICE wnen using __int128_t on x86_64
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-13 22:00 ---
Confirmed. C testcase:
typedef int int32_t;
int32_t round32hi(const __int128_t arg)
{
const int SHIFT = 96;
const int mshift = 96;
const __int128_t M = (~(__int128_t)0)mshift;
const __int128_t L = (~M) + 1;
const __int128_t L1 = ((__int128_t)L)1;
const __int128_t Mlo = ((__int128_t)(~M))1;
__int128_t vv = arg M;
if( (arg (L1)) // hi bit of discard set
( (arg Mlo) // and ( any other bits of discard set
|| (arg L) ) ) // or lo bit of keep set )
vv += L;
return (int32_t)(vvSHIFT);
}
--
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 |2007-03-13 22:00:38
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31167
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-03-13 22:16
---
Another testcase but it is not fixed by my patch as I did not fix the other
side:
int main(void)
{
double b = 234.0;
long long c;
double d = b;
__builtin_memcpy(c, b, sizeof(double));
long long e = c;
if (__builtin_memcmp (e, d, sizeof(double)) != 0)
__builtin_abort ();
return 0;
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
GCC target triplet|hppa64-hp-hpux11.00,|FLOAT_WORDS_BIG_ENDIAN
|powerpc64-linux-gnu |targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug c/31166] Integer hex constant does not follow promoting rules
--- Comment #2 from roberto dot gordo at gmail dot com 2007-03-13 22:27 --- I do not agree at all. Please, read. So 0x8000 is unsigned because does not fit on an int type. That's OK. If negating it gives an unsigned int of the same value, then, how do you explain that the following code prints n1 = -2147483648 int n1; n1 = -0x8000; printf(n1 = %d\n, n1); It works because the expression should not be unsigned. This is a quotation from ISO/IEC 9899:1999 standard: The result of the unary - operator is the negative of its (promoted) operand. The integer promotions are performed on the operand, and the result has the promoted type. and... Several operators convert operand values from one type to another automatically [...] If an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions. The unary - operator can (and should) apply again the promotion rules, and should choose int. So the expression -0x8000 shall promote to a signed integer type in which it fits, which happens to be an int (on c99 and c90). And as you can see, gcc works correcly here, just as the standard says. But if fails when the lvalue is long long instead of int, as here: long long n1; n1 = -0x8000; In case we have an int expression at the right, it should be converted as long long without problems. In case we have a long long at the right, it should also work without problems (at least for c99). And if we have an unsigned int at the right, as you said, it should have not worked with an int and it is a bug by itself in the way I understand the standard. -- roberto dot gordo at gmail dot com changed: What|Removed |Added CC||roberto dot gordo at gmail ||dot com Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
[Bug c/31166] Integer hex constant does not follow promoting rules
--- Comment #3 from schwab at suse dot de 2007-03-13 22:35 --- (In reply to comment #2) So 0x8000 is unsigned because does not fit on an int type. That's OK. If negating it gives an unsigned int of the same value, then, how do you explain that the following code prints n1 = -2147483648 You print it as a signed integer. It works because the expression should not be unsigned. The value is converted to signed int by printf. The unary - operator can (and should) apply again the promotion rules, and should choose int. Integer promotion is only performed on types smaller than int. The unary - operator can (and should) apply again the promotion rules, and should choose int. The operand is unsigned int, so there is no promotion. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
[Bug c/31166] Integer hex constant does not follow promoting rules
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-13 22:35 --- unsigned is never promoted, it always stays unsigned. So -0x8000 == 0x8000 :). Try adding ULL (or UL) if you want an unsigned long long (unsigned long) constant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31166
[Bug c++/30988] [4.1/4.2/4.3 Regression] Incorrect no return statement warning with __attribute__ ((noreturn)) and __FUNCTION__
--- Comment #3 from spark at gcc dot gnu dot org 2007-03-13 22:57 ---
This is somewhat complicated.
The extra type cast causes
different code paths to be taken.
In particular, in finish_call_expr() in cp/semantics.c:
if (processing_template_decl)
{
if (type_dependent_expression_p (fn)
|| any_type_dependent_arguments_p (args))
{
result = build_nt_call_list (fn, args);
KOENIG_LOOKUP_P (result) = koenig_p;
return result;
}
if (!BASELINK_P (fn)
TREE_CODE (fn) != PSEUDO_DTOR_EXPR
TREE_TYPE (fn) != unknown_type_node)
fn = build_non_dependent_expr (fn);
args = build_non_dependent_args (orig_args);
With the type cast,
build_over_call() is called eventually
which checks TREE_THIS_VOLATILE() for the callee function decl
and mark the current function (i.e. caller A::g) as returns_abnormally.
The lack of the type cast triggers
any_type_dependent_arguments_p(args) above,
leading to build_nt_call_list() which doesn't do this marking
of the returns_abnormally.
Now, not being familiar with the c++ frontend,
I'm not sure where exactly we should do the checking
of TREE_THIS_VOLATILE() for the callee decl.
The following patch seems to fix the problem
(though I can't even tell whether this is the right approach):
diff -r 15a559a8fcf0 gcc/cp/semantics.c
--- a/gcc/cp/semantics.cMon Mar 12 15:38:22 2007 -0700
+++ b/gcc/cp/semantics.cTue Mar 13 15:48:45 2007 -0700
@@ -1816,6 +1816,10 @@ finish_call_expr (tree fn, tree args, bo
|| any_type_dependent_arguments_p (args))
{
result = build_nt_call_list (fn, args);
+
+ if (fn TREE_THIS_VOLATILE (fn) cfun)
+ current_function_returns_abnormally = 1;
+
KOENIG_LOOKUP_P (result) = koenig_p;
return result;
}
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
CC||spark at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988
[Bug target/31123] FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation, -O3 ...
--- Comment #1 from danglin at gcc dot gnu dot org 2007-03-13 23:21 --- Subject: Bug 31123 Author: danglin Date: Tue Mar 13 23:21:40 2007 New Revision: 122886 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122886 Log: PR target/31123 * pa.md (vdepi_ior): Don't allow zero length deposit. Likewise for two unamed patterns. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/pa/pa.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31123
[Bug target/31123] FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation, -O3 ...
--- Comment #2 from danglin at gcc dot gnu dot org 2007-03-13 23:24 --- Subject: Bug 31123 Author: danglin Date: Tue Mar 13 23:23:54 2007 New Revision: 122887 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122887 Log: PR target/31123 Fix ChangeLog entry. Modified: trunk/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31123
[Bug inline-asm/28686] ebp from clobber list used as operand
--- Comment #8 from spark at gcc dot gnu dot org 2007-03-13 23:43 --- I believe all issues are fixed at this point, except for the extra error message of can't find a register. But since it's accompanied with a proper error message, I don't think this is a problem anymore. $gcc -fPIC -fomit-frame-pointer -O2 -S t.c grep DEBUG t.s #DEBUG %0=(%esp), clobber: %ebp, ... $gcc -DNBEFORE=1 -fPIC -fomit-frame-pointer -O2 -S t.c grep DEBUG t.s #DEBUG %0=(%esp), clobber: %ebp, ... $gcc-O1 -S t.c $@ grep DEBUG t.s t.c: In function 'test_function': t.c:15: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' t.c:15: error: 'asm' operand has impossible constraints $gcc -O1 -fPIC -S t.c $@ grep DEBUG t.s t.c: In function 'test_function': t.c:20: error: bp cannot be used in asm here t.c:15: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' t.c:15: error: 'asm' operand has impossible constraints $gcc -fPIC -O0 -S t.c grep DEBUG t.s t.c: In function 'test_function': t.c:20: error: bp cannot be used in asm here $gcc -fPIC -O0 -S t.c -fomit-frame-pointer grep DEBUG t.s #DEBUG %0=12(%esp), clobber: %ebp, ... -- spark at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686
[Bug bootstrap/30899] [4.2/4.3 Regression] build failure with --enable-generated-files-in-srcdir
--- Comment #1 from mmitchel at gcc dot gnu dot org 2007-03-13 23:49 --- Subject: Bug 30899 Author: mmitchel Date: Tue Mar 13 23:48:49 2007 New Revision: 122888 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122888 Log: PR bootstrap/30899 * Make-lang.in (doc/g++.1): Use $ to specify the location from which to copy. Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30899
[Bug bootstrap/30899] [4.2/4.3 Regression] build failure with --enable-generated-files-in-srcdir
--- Comment #2 from mmitchel at gcc dot gnu dot org 2007-03-13 23:50 --- Fixed in 4.2.0, 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30899
[Bug driver/12448] -MT / -MQ don't behave as documented.
--- Comment #11 from tromey at gcc dot gnu dot org 2007-03-13 23:50 --- Subject: Bug 12448 Author: tromey Date: Tue Mar 13 23:50:42 2007 New Revision: 122889 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122889 Log: 2007-03-13 David Taylor [EMAIL PROTECTED] PR driver/12448: * gcc.c (cpp_unique_options): If -MT or -MQ is seen, don't pass default -MQ. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12448
[Bug bootstrap/30899] [4.2/4.3 Regression] build failure with --enable-generated-files-in-srcdir
--- Comment #3 from mmitchel at gcc dot gnu dot org 2007-03-13 23:51 --- Subject: Bug 30899 Author: mmitchel Date: Tue Mar 13 23:51:07 2007 New Revision: 122890 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122890 Log: PR bootstrap/30899 * Make-lang.in (doc/g++.1): Use $ to specify the location from which to copy. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/Make-lang.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30899
[Bug middle-end/30196] VLA and setjumplongjump exceptions
--- Comment #2 from jconner at apple dot com 2007-03-13 23:55 --- I have a patch for this that I'm testing right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30196
[Bug target/31123] FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation, -O3 ...
--- Comment #3 from danglin at gcc dot gnu dot org 2007-03-14 00:06 --- Subject: Bug 31123 Author: danglin Date: Wed Mar 14 00:06:26 2007 New Revision: 122891 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122891 Log: PR target/31123 * pa.md (vdepi_ior): Don't allow zero length deposit. Likewise for two unamed patterns. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/pa/pa.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31123
[Bug target/31123] FAIL: gcc.c-torture/execute/builtin-bitops-1.c compilation, -O3 ...
--- Comment #4 from danglin at gcc dot gnu dot org 2007-03-14 00:17 --- Fixed by change on 4.1, 4.2 and trunk. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31123
[Bug tree-optimization/30730] -Wunsafe-loop-optimizations gives too many warnings
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-03-14 00:39 --- Subject: Bug 30730 Author: rakdver Date: Wed Mar 14 00:38:34 2007 New Revision: 122896 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122896 Log: PR tree-optimization/30730 PR tree-optimization/26900 * tree-ssa-loop-niter.c: Include gmp.h. (bounds): New type. (mpz_set_double_int, get_type_bounds, mpz_to_double_int, split_to_var_and_offset, determine_value_range, bound_difference_of_offsetted_base, refine_bounds_using_guard, bound_difference, bounds_add, bounds_negate, number_of_iterations_ne_max, dump_affine_iv): New functions. (number_of_iterations_ne, number_of_iterations_lt_to_ne, assert_loop_rolls_lt, assert_loop_rolls_le): Use bounds on the difference of initial and final value of control iv to validate results. (number_of_iterations_cond): Add loop parameter. Determine bounds on the difference of the extremes of the control iv. Add dumps. (expand_simple_operations): Handle phi nodes. (simplify_using_initial_conditions): Do not record used conditions. (number_of_iterations_exit): Pass loop to number_of_iterations_cond. Do not set additional_info. (implies_nonnegative_p, implies_ge_p): Removed. (derive_constant_upper_bound): Do not use parameter `additional'. (record_estimate): Parameter `additional' removed. Parameter `i_bound' added. Do not call derive_constant_upper_bound. (record_nonwrapping_iv): Use derive_constant_upper_bound to bound the number of iterations estimate. (estimate_numbers_of_iterations_loop): Pass the estimate from the number of iterations analysis to record_estimate. * tree.h (multiple_of_p): Declare. * tree-scalar-evolution.c (expression_expensive_p): Removed. (scev_const_prop): Do not check expression_expensive_p. * fold-const.c (multiple_of_p): Exported. * double-int.c (double_int_mask): Exported. * double-int.h (double_int_mask): Declare. * tree-flow.h (struct tree_niter_desc): Removed additional_info field. Added max field. * gcc.dg/tree-ssa/loop-26.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-26.c Modified: trunk/gcc/ChangeLog trunk/gcc/double-int.c trunk/gcc/double-int.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30730
[Bug middle-end/26900] Number of iterations not know for simple loop
--- Comment #16 from rakdver at gcc dot gnu dot org 2007-03-14 00:39 --- Subject: Bug 26900 Author: rakdver Date: Wed Mar 14 00:38:34 2007 New Revision: 122896 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122896 Log: PR tree-optimization/30730 PR tree-optimization/26900 * tree-ssa-loop-niter.c: Include gmp.h. (bounds): New type. (mpz_set_double_int, get_type_bounds, mpz_to_double_int, split_to_var_and_offset, determine_value_range, bound_difference_of_offsetted_base, refine_bounds_using_guard, bound_difference, bounds_add, bounds_negate, number_of_iterations_ne_max, dump_affine_iv): New functions. (number_of_iterations_ne, number_of_iterations_lt_to_ne, assert_loop_rolls_lt, assert_loop_rolls_le): Use bounds on the difference of initial and final value of control iv to validate results. (number_of_iterations_cond): Add loop parameter. Determine bounds on the difference of the extremes of the control iv. Add dumps. (expand_simple_operations): Handle phi nodes. (simplify_using_initial_conditions): Do not record used conditions. (number_of_iterations_exit): Pass loop to number_of_iterations_cond. Do not set additional_info. (implies_nonnegative_p, implies_ge_p): Removed. (derive_constant_upper_bound): Do not use parameter `additional'. (record_estimate): Parameter `additional' removed. Parameter `i_bound' added. Do not call derive_constant_upper_bound. (record_nonwrapping_iv): Use derive_constant_upper_bound to bound the number of iterations estimate. (estimate_numbers_of_iterations_loop): Pass the estimate from the number of iterations analysis to record_estimate. * tree.h (multiple_of_p): Declare. * tree-scalar-evolution.c (expression_expensive_p): Removed. (scev_const_prop): Do not check expression_expensive_p. * fold-const.c (multiple_of_p): Exported. * double-int.c (double_int_mask): Exported. * double-int.h (double_int_mask): Declare. * tree-flow.h (struct tree_niter_desc): Removed additional_info field. Added max field. * gcc.dg/tree-ssa/loop-26.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/loop-26.c Modified: trunk/gcc/ChangeLog trunk/gcc/double-int.c trunk/gcc/double-int.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow.h trunk/gcc/tree-scalar-evolution.c trunk/gcc/tree-ssa-loop-niter.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
[Bug c++/20280] [4.0/4.1 regression] ICE in create_tmp_var, at gimplify.c:368
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-03-14 00:42
---
I have a patch which fixes after my patch for PR 30132. The way I fixed it is
an all front-end fix:
Index: typeck.c
===
--- typeck.c(revision 122880)
+++ typeck.c(working copy)
@@ -4060,6 +4060,14 @@ build_address (tree t)
if (error_operand_p (t) || !cxx_mark_addressable (t))
return error_mark_node;
+ if (TREE_CODE (t) == COND_EXPR)
+{
+ tree ptrtype = build_pointer_type (TREE_TYPE (t));
+ return build3 (COND_EXPR, ptrtype, TREE_OPERAND (t, 0),
+build_address (TREE_OPERAND (t, 1)),
+build_address (TREE_OPERAND (t, 2)));
+}
+
addr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (t)), t);
return addr;
Create a new COND_EXPR for when we want to create an address of a COND_EXPR, by
this point, we should have errored out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20280
[Bug testsuite/31168] New: FAIL: g++.dg/eh/ia64-2.C (test for excess errors)
Executing on host: /xxx/gnu/gcc/objdir/gcc/testsuite/g++/../../g++ -B/xxx/gnu/gc c/objdir/gcc/testsuite/g++/../../ /xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64- 2.C -nostdinc++ -I/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/include /hppa1.1-hp-hpux10.20 -I/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/in clude -I/xxx/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/xxx/gnu/gcc/gcc/libstdc++-v3/ include/backward -I/xxx/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length =0 -O2-L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/./libstdc++-v3/src/.libs -L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/./libstdc++-v3/src/.libs -L/xxx/gnu/g cc/objdir/hppa1.1-hp-hpux10.20/./libiberty -lm -o ./ia64-2.exe(timeout = 600) /xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64-2.C:18: warning: weak declaration of 'p' not supported output is: /xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64-2.C:18: warning: weak declaration of 'p' not supported FAIL: g++.dg/eh/ia64-2.C (test for excess errors) Excess errors: /xxx/gnu/gcc/gcc/gcc/testsuite/g++.dg/eh/ia64-2.C:18: warning: weak declaration of 'p' not supported -- Summary: FAIL: g++.dg/eh/ia64-2.C (test for excess errors) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa1.1-hp-hpux10.20 GCC host triplet: hppa1.1-hp-hpux10.20 GCC target triplet: hppa1.1-hp-hpux10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31168
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #9 from aoliva at gcc dot gnu dot org 2007-03-14 01:45 --- Subject: Bug 31127 Author: aoliva Date: Wed Mar 14 01:45:39 2007 New Revision: 122900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122900 Log: gcc/ChangeLog: PR middle-end/31127 * cse.c (cse_find_path): Do not bail out if a basic block that we already visited now becomes part of a path that starts at a different basic block. Just disallow this, to make sure we visit each basic block at most once. gcc/testsuite/ChangeLog: PR middle-end/31127 * gcc.dg/pr31127.c: New. Added: trunk/gcc/testsuite/gcc.dg/pr31127.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug bootstrap/29741] Fails to build bootstrap under solaris 10, i386
--- Comment #2 from ted dot keller at goodrich dot com 2007-03-14 02:37 --- Check out http://forum.java.sun.com/thread.jspa?threadID=5077618 Describes problem and resolution. You need to install the gcc and gas from the solaris 10 distribution prior to building a new gcc compiler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29741
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #9 from brooks at gcc dot gnu dot org 2007-03-14 02:43 --- Subject: Bug 28068 Author: brooks Date: Wed Mar 14 02:43:27 2007 New Revision: 122902 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122902 Log: PR fortran/28068 * intrinsic.texi: General whitespace cleanup, remove comment about missing intrinsics. (menu): Add lines for new entries listed below. (ACOSH): Mention specific function DACOSH, correct description phrasing. (ASINH): Mention specific function DASINH, correct description phrasing. (ATANH): Mention specific function DATANH, correct description phrasing. (COS): Add index entry for CCOS. (CPU_TIME): Correct REAL to REAL(*). (EXP): Add index entry for CEXP. (INT): Correct argument name to A. (INT2): New entry. (INT8): New entry. (LONG): New entry. (MAX): Add index entries for specific variants. (MCLOCK): New entry. (MCLOCK8): New entry. (SECNDS): Adjust to a more standard form. (SECOND): New entry. (TIME): Add cross-reference to MCLOCK. (TIME8): Add cross-reference to MCLOCK8. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #10 from brooks at gcc dot gnu dot org 2007-03-14 02:45 --- Subject: Bug 28068 Author: brooks Date: Wed Mar 14 02:45:14 2007 New Revision: 122903 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122903 Log: PR fortran/28068 * intrinsic.texi: General whitespace cleanup, remove comment about missing intrinsics. (menu): Add lines for new entries listed below. (ACOSH): Mention specific function DACOSH, correct description phrasing. (ASINH): Mention specific function DASINH, correct description phrasing. (ATANH): Mention specific function DATANH, correct description phrasing. (COS): Add index entry for CCOS. (CPU_TIME): Correct REAL to REAL(*). (EXP): Add index entry for CEXP. (INT): Correct argument name to A. (INT2): New entry. (INT8): New entry. (LONG): New entry. (MAX): Add index entries for specific variants. (MCLOCK): New entry. (MCLOCK8): New entry. (SECNDS): Adjust to a more standard form. (SECOND): New entry. (TIME): Add cross-reference to MCLOCK. (TIME8): Add cross-reference to MCLOCK8. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug fortran/28068] Non-standard intrinsics should be documented
--- Comment #11 from brooks at gcc dot gnu dot org 2007-03-14 02:46 --- _Now_ this is fixed on 4.2 and trunk. :) -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28068
[Bug tree-optimization/31169] New: Bootstrap comparison error at revision 122821
make[3]: Leaving directory `/test/gnu/gcc/objdir' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs Bootstrap comparison failure! ./build/genautomata.o differs ./pointer-set.o differs ./cfgexpand.o differs ./cfglayout.o differs ./builtins.o differs ./cfgloopanal.o differs ./cfgloopmanip.o differs ./cse.o differs ./cselib.o differs ./combine.o differs ./df-core.o differs ./df-scan.o differs ./gcse.o differs ./gimplify.o differs ./global.o differs ./graph.o differs ./jump.o differs ./lambda-mat.o differs ./langhooks.o differs ./lambda-code.o differs ./loop-invariant.o differs ./lower-subreg.o differs ./omega.o differs ./postreload.o differs ./real.o differs ./recog.o differs ./regmove.o differs ./regclass.o differs ./regrename.o differs ./reload.o differs ./reload1.o differs ./rtlanal.o differs ./see.o differs ./sched-rgn.o differs ./simplify-rtx.o differs ./stmt.o differs ./struct-equiv.o differs ./tree-complex.o differs ./tree-cfg.o differs ./tree-data-ref.o differs ./tree-eh.o differs ./tree-pretty-print.o differs ./tree-ssa-coalesce.o differs ./tree-ssa-dom.o differs ./tree-ssa-live.o differs ./tree-ssa-loop-im.o differs ./tree-ssa-loop-niter.o differs ./tree-ssa-loop-ivopts.o differs ./tree-ssa-phiopt.o differs ./tree-ssa-pre.o differs ./tree-ssa.o differs ./tree-vect-analyze.o differs ./tree-vectorizer.o differs ./tree-vect-transform.o differs ./cgraphunit.o differs ./gccspec.o differs ./gcc.o differs ./c-decl.o differs ./final.o differs ./modulo-sched.o differs ./passes.o differs ./ipa-inline.o differs ./gcov.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/test/gnu/gcc/objdir' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/test/gnu/gcc/objdir' -bash-2.05b$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu/bin/as --enable-shared --disable-nls --with-local-prefix=/opt/gnu --prefix=/opt/gnu/gcc/gcc-4.3.0 --enable-debug=no --enable-threads=posix --with-mpfr=/opt/gnu/gcc/gcc-4.3.0 --with-gmp=/opt/gnu/gcc/gcc-4.3.0 --disable-libmudflap --enable-languages=c Thread model: posix gcc version 4.3.0 20070311 (experimental) -- Summary: Bootstrap comparison error at revision 122821 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa*-*-* (32-bit) GCC host triplet: hppa*-*-* (32-bit) GCC target triplet: hppa*-*-* (32-bit) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #17 from patchapp at dberlin dot org 2007-03-14 03:45 --- Subject: Bug number PR31052 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00892.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug middle-end/31127] [4.3 regression] ICE in cse_find_path, at cse.c:5930
--- Comment #10 from aoliva at gcc dot gnu dot org 2007-03-14 04:09 --- Fixed. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31127
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-14 04:19 --- Furthermore, the function form of CHDIR erroneously has A as the argument name. (Actually, all three of the names involved for this artgument are erroneous compared to the G77 documentation, which gives the variable name as DIR!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #3 from brooks at gcc dot gnu dot org 2007-03-14 04:37 --- Subject: Bug 30948 Author: brooks Date: Wed Mar 14 04:37:15 2007 New Revision: 122904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122904 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #6 from brooks at gcc dot gnu dot org 2007-03-14 04:37 --- Subject: Bug 30922 Author: brooks Date: Wed Mar 14 04:37:15 2007 New Revision: 122904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122904 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug fortran/30953] intrinsic: CTIME
--- Comment #1 from brooks at gcc dot gnu dot org 2007-03-14 04:37 --- Subject: Bug 30953 Author: brooks Date: Wed Mar 14 04:37:15 2007 New Revision: 122904 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122904 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30953
[Bug fortran/30922] IMPORT fails for same symbol in multiple interface bodies of same interface block
--- Comment #7 from brooks at gcc dot gnu dot org 2007-03-14 04:39 --- Subject: Bug 30922 Author: brooks Date: Wed Mar 14 04:38:47 2007 New Revision: 122905 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122905 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30922
[Bug fortran/30948] intrinsic: CHDIR
--- Comment #4 from brooks at gcc dot gnu dot org 2007-03-14 04:39 --- Subject: Bug 30948 Author: brooks Date: Wed Mar 14 04:38:47 2007 New Revision: 122905 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122905 Log: PR fortran/30922 PR fortran/30948 PR fortran/30953 * intrinsics.texi (CHDIR): Fix argument names, note that STATUS must be a default integer. (CTIME): Fix argument names, note that RESULT must be a default integer. (EXIT): Note that STATUS must be a default integer. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30948
