[Bug tree-optimization/31095] New: [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786
I get the following ICE on IA-64: [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O libnasl-capture_packet.c libnasl-capture_packet.c: In function 'capture_next_packet': libnasl-capture_packet.c:19: internal compiler error: in expand_expr_real_1, at expr.c:8786 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c libnasl-capture_packet.c [EMAIL PROTECTED]:~$ gcc-4.1 -c -O2 libnasl-capture_packet.c [EMAIL PROTECTED]:~$ -- Summary: [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
[Bug tree-optimization/31095] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786
--- Comment #1 from tbm at cyrius dot com 2007-03-09 08:30 ---
Testcase:
typedef long unsigned int size_t;
__extension__ typedef long int __time_t;
__extension__ typedef long int __suseconds_t;
typedef struct
{
}
__sigset_t;
struct timeval
{
__time_t tv_sec;
__suseconds_t tv_usec;
};
extern void bcopy (__const void *__src, void *__dest, size_t __n)
__attribute__ ((__nothrow__)) __attribute__ ((__nonnull__ (1, 2)));
capture_next_packet (int bpf, int timeout, int *sz)
{
struct timeval past, now, then;
{
bcopy (&then, &past, sizeof (then));
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
[Bug rtl-optimization/30643] [4.1/4.2/4.3 regression] CSE pessimization
--- Comment #9 from bonzini at gnu dot org 2007-03-09 08:44 --- Zdenek, any chance that your aliasing oracle can be used to fix these? -- bonzini at gnu dot org changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
[Bug middle-end/31095] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |middle-end Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
[Bug rtl-optimization/30643] [4.1/4.2/4.3 regression] CSE pessimization
--- Comment #10 from rakdver at gcc dot gnu dot org 2007-03-09 08:54 --- Alias oracle could be used for this; but my patch only uses it in loop optimizers. So some changes to make ccp use it would be necessary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
[Bug middle-end/31096] New: a*C == b*C where C is a constant is not optimized to a == b
The following two functions should be equzlivant when overflow is undefined:
int f(int a, int b)
{
return a * 10 == b*10;
}
int f1(int a, int b)
{
return a==b;
}
--
Summary: a*C == b*C where C is a constant is not optimized to a
== b
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31096
[Bug middle-end/31096] a*C == b*C where C is a constant is not optimized to a == b
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19987 nThis|| Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31096
[Bug middle-end/31097] New: a/C == b/C is not foldded to a == b with --fast-math/floating point
The following two functions should be equalivant with --fast-math:
int f(float a, float b)
{
return a/10 == b/10;
}
int f1(float a, float b)
{
return a == b;
}
--
Summary: a/C == b/C is not foldded to a == b with --fast-
math/floating point
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31097
[Bug middle-end/31097] a/C == b/C is not foldded to a == b with --fast-math/floating point
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||19987 nThis|| Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31097
[Bug middle-end/31098] New: a*C == b*C is not foldded to a == b with --fast-math/floating point
The following two functions should be equalivant with --fast-math:
int f(float a, float b)
{
return a*10 == b*10;
}
int f1(float a, float b)
{
return a == b;
}
--
Summary: a*C == b*C is not foldded to a == b with --fast-
math/floating point
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
OtherBugsDependingO 19987
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31098
[Bug c++/29164] Overloaded operator delete[] doesn't get called
--- Comment #8 from Andreas dot Kowarz at tu-dresden dot de 2007-03-09 09:37 --- It seems that the bug triggers only when returning NULL in the new operators. Returning something different ( tested with (void *)1 ) is a workaround for the problem. Checking for not returning NULL in the new operators seems reasonable even if it does not solve the mentioned mis-compilation of the delete operators. Tested for - g++ 3.2.3 - g++ 4.1.1 - icpc 9.1 (returning NULL prevents both delete operators from being called correctly) Andreas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29164
[Bug bootstrap/30635] --enable-stage1-langauges configure option is not 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 09:42:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30635
[Bug libfortran/31099] New: Runtime error on legal code using RECL
$ cat a.f90 PROGRAM TEST INTEGER :: A OPEN(10, FORM="UNFORMATTED", RECL=1024) A = -1 WRITE(10) A END PROGRAM TEST $ gfortran a.f90 && ./a.out At line 5 of file a.f90 Fortran runtime error: I/O past end of record on unformatted file $ pgf90 a.f90 && ./a.out && xxd fort.10 000: 0400 0400 $ sunf90 a.f90 && ./a.out && xxd fort.10 000: 0400 0400 $ ifort a.f90 && ./a.out && xxd fort.10 000: 0400 0400 -- Summary: Runtime error on legal code using RECL Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug target/31100] New: ASM_OUTPUT_ALIGN_WITH_NOP wrong on sparc/gas
The macro ASM_OUTPUT_ALIGN_WITH_NOP on sparc contains an explicit filler on the
align statement. This is given as a word representing the NOP. The GNU
assembler only uses the last byte of the filler. This generates wrong code. The
original SUN assembler needs this word to insert NOPs instead of zero.
The testcase is compiled with gcc -v -S -O3 -falign-labels=16 test.c
The testcase:
int f(int i)
{
int res;
switch ( i )
{
case 5:
res = i -i ;
break;
default:
res = i* 2;
}
return res;
}
int f(int);
main()
{
return f(2);
}
--
Summary: ASM_OUTPUT_ALIGN_WITH_NOP wrong on sparc/gas
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Erwin dot Unruh at fujitsu-siemens dot com
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=31100
[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-09 10:06 --- This one hurts. Nevertheless, it's probably too late for 4.2.0... -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||jerrydy at sbcglobal dot net Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.2.0 4.3.0 Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2007-03-09 10:06:17 date|| Summary|Runtime error on legal code |[4.3/4.2 regression] Runtime |using RECL |error on legal code using ||RECL Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug target/31054] FLDx not emitted for 80387 constants in 64-bit mode.
--- Comment #1 from ubizjak at gmail dot com 2007-03-09 10:22 --- This problem is fixed in 4.3.0. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-09 10:22:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31054
[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-09 10:32 --- It looks like a no-op change. For reference: --- ChangeLog (revision 121301) +++ ChangeLog (revision 121302) @@ -1,3 +1,41 @@ +2007-01-28 Daniel Berlin <[EMAIL PROTECTED]> + + * tree.h (struct tree_memory_tag): Add aliases member. + (MTAG_ALIASES): New macro. + * tree-ssa-alias.c (alias_bitmap_obstack): New variable. + (add_may_alias): Remove pointer-set. Update for may_aliases being + a bitmap. + (mark_aliases_call_clobbered): Update for may_aliases being a + bitmap. + (compute_tag_properties): Ditto. + (create_partition_for): Ditto. + (compute_memory_partitions): Ditto. + (dump_may_aliases_for): Ditto. + (is_aliased_with): Ditto. + (add_may_alias_for_new_tag): Ditto. + (rewrite_alias_set_for): Rewrite for may_aliases being a bitmap. + (compute_is_aliased): New function. + (compute_may_aliases): Call compute_is_aliased). + (init_alias_info): Initialize alias_bitmap_obstack. + (union_alias_set_into): New function. + (compute_flow_sensitive_aliasing): Use union_aliases_into. + (have_common_aliases_p): Rewrite to take two bitmaps and use + intersection. + (compute_flow_insensitive_aliasing): Stop using pointer-sets. + Update for bitmaps. + (finalize_ref_all_pointers): Update for add_may_alias changes. + (new_type_alias): Ditto. + * tree-flow-inline.h (may_aliases): Return a bitmap. + * tree-dfa.c (dump_variable): Check for MTAG_P'ness. + * tree-ssa.c (verify_flow_insensitive_alias_info): Update for + may_aliases being a bitmap. + * tree-flow.h (struct var_ann_d): Remove may_aliases member. + may_aliases now returns a bitmap. + * tree-ssa-structalias.c (merge_smts_into): Update for may_aliases + being a bitmap. + * tree-ssa-operands.c (add_virtual_operand): Update for + may_aliases being a bitmap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug middle-end/31094] Support annotating function parameters as read-only and/or non-escaping
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:33 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org, dnovillo at redhat ||dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 10:33:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094
[Bug middle-end/31096] a*C == b*C where C is a constant is not optimized to a == b
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:35 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 10:35:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31096
[Bug middle-end/31097] a/C == b/C is not foldded to a == b with --fast-math/floating point
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:36 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 10:36:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31097
[Bug middle-end/31098] a*C == b*C is not foldded to a == b with --fast-math/floating point
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 10:37 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 10:37:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31098
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #29 from baldrick at free dot fr 2007-03-09 10:41 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > > Sure, it's just that overloading V_C_E like this feels somehow wrong to me. > > Why? It's not "overloading". V_C_E of an expression E of type X to > type Y means "interpret the bits of E as if it were type Y and not type X". > If Y is X'Base, then interpreting E as being Y means that it can now have > all the values of Y. For example, after the view conversion it is legal to place a value in it that is in the range of Y but not of X. This is logical. What seems illogical to me is that by doing the V_C_E you are supposed to forget anything you had deduced about the bits before the conversion. For example, suppose you had deduced that the bits were all zero. After the V_C_E the bits will still be zero - are you really supposed to forget this information? Another example: suppose you had worked out somehow that the bits corresponded to an integer in the range 4..5. After the V_C_E this is still true - why is it logical to forget this information? You may well respond that you are only supposed to forget information you deduced from the range of the type, not information you worked out by some other means. But these cannot really be distinguished, c.f. VRP. In short, it is overloading because it means: consider this bunch of bits to be of the new type AND forget anything you ever deduced about them. > In other words, we could only change a V_C_E to a > NOP_EXPR if we can prove that the value of E is in range of *both* X > and Y. Surely you only have to prove that it is in the range of Y, since if it is not in the range of X then you have a bounded error, and doing a NOP_EXPR should be perfectly legal. > Of course, we still have a bit of a mess here in that the real point is > a confusion between what in Ada is called a Bounded Error and C's notion > of "undefined" (Ada's "erroneous"). But I think we can do better in this > area: we just haven't gotten to take a really good look at it. > > > However I haven't been able to put my finger on any technical obstacle to > > this use of V_C_E. > > Nor can I ... Actually I do have a technical objection, however it comes from my LLVM port and not mainline gcc. LLVM is lower level than gimple. Supposing types X and Y have eg 32 bits, then they both get mapped to LLVM's Int32 type. A V_C_E gets turned into nothing at all. There are no types with restricted ranges. Suppose x is a variable of type X. When a value is loaded into x I'm planning on generating the following LLVM code: x = value; assert(x >= lower_bound_for_gcc_type && x <= upper_bound_for_gcc_type); I don't generate the assert when you do a V_C_E, so for example suppose there is a y = V_C_E(Y, x). This gets turned into: y = x; Since the optimizers have range info for x, they instantly deduce the same ranges for y as for x. Thus if you test for validity of y using valid = (y >= lower_bound_for_gcc_type_X && y <= upper_bound_for_gcc_type-X); then the result is always true. How to get around this? The obvious method is to use an intrinsic, such as __builtin_nop. For the V_C_E I can then do: y = __builtin_nop(x); and all will be well. However, I only really need to use the __builtin_nop if I'm doing the V_C_E in order to implement 'Valid. For other uses of V_C_E it is unnecessary and gets in the way of optimization. So I would much rather that 'Valid directly made use of a builtin. Ciao, Duncan. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #8 from tbm at cyrius dot com 2007-03-09 10:52 --- I definitely think this should be an error, not a warning. I only saw this problem by luck. I'm compiling the entire Debian archive (ie 7000 packages) on IA64 with GCC 4.3 and I cannot look at every log file (especially when the build was successful). I only noticed this one because the program failed to compile later on and I looked at the log to see the error. Anyway, are there any other "warning" messages like this one? If so, I can search my log files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug rtl-optimization/31101] New: Problem with -funroll-all-loops
This testcase:
double t (double a, double b)
{
return fmod (a, b);
}
generates wrong code when compiled with -O2 -funroll-all-loops
(-ffast-math -fomit-frame-pointer is used here only for clarity):
:
fldl4(%esp)
fldl12(%esp)
fxch%st(1)
.L2:
fprem
fnstsw %ax
sahf
jnp .L22
fprem
fnstsw %ax
sahf
jnp .L22
fprem
jnp .L22
fprem
.p2align 4,,2
jnp .L22
fprem
.p2align 4,,5
jnp .L22
fprem
.p2align 4,,5
jnp .L22
fprem
.p2align 4,,5
jnp .L22
fprem
.p2align 4,,5
jp .L2
.p2align 4,,7
.L22:
fstp%st(1)
.p2align 4,,5
ret
Please note that from second iteration,fnstsw %ax and sahf are not present
anymore in the instruction stream. The problem starts in .159r.postreload RTL
dump, where missing instructions just vanish without NOTE_INSN_DELETED trace
from RTL insn stream, although they are still present in 158r.greg dump.
--
Summary: Problem with -funroll-all-loops
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ubizjak at gmail dot com
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=31101
[Bug middle-end/31095] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786
--- Comment #2 from tbm at cyrius dot com 2007-03-09 11:11 --- I've confirmed that this doesn't happen with 4.2.0 20070309. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #30 from rguenth at gcc dot gnu dot org 2007-03-09 11:11 --- Well, the only problem with V_C_E is that if you assert on the range of the base type like if (V_C_E (y) > 5) abort(); that you still want VRP to infer that V_C_E (y) is <= 5 after this check (to eliminate further checks). I believe this will not automatically happen at the moment because V_C_E (y) will not have the same ssa name assigned for evey occurance. But of course we will never know until the Ada FE people finally fix their frontend. All the mess would be way easier if the FE would not expose the subtypes to the middle-end... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2007-03-09 11:19 --- > All the mess would be way easier if the FE would not expose the subtypes to > the middle-end... I personally agree, but there is no clear consensus among the Ada maintainers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #9 from tbm at cyrius dot com 2007-03-09 11:21 --- This warning is really frequent. I can find 2200 warnings that mention "const" and "same canonical type node for different types". Some don't mention "const"; I'll look at them and file separate bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #10 from ubizjak at gmail dot com 2007-03-09 11:22 --- (In reply to comment #8) > Anyway, are there any other "warning" messages like this one? If so, I can > search my log files. Yes, the one reported in PR middle-end/30666. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug c++/31027] [4.1/4.2/4.3 regression] Compiler segfaults in simple virtual inheritance situation
--- Comment #5 from v dot lesk at ic dot ac dot uk 2007-03-09 11:28 --- Can anyone suggest a workaround? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31027
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #32 from baldrick at free dot fr 2007-03-09 11:34 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > Well, the only problem with V_C_E is that if you assert on the range of the > base type like > > if (V_C_E (y) > 5) > abort(); > > that you still want VRP to infer that V_C_E (y) is <= 5 after this > check (to eliminate further checks). I don't think this is a very serious problem. My understanding is that the checks can be divided into two classes: normal checks and validity checks. A normal check, such as when you do a type conversion, does not use a V_C_E, it just does: if (y < new_type_lb || y > new_type_ub) abort; new_var = (new_type) y; A validity check does: if (V_C_E (y) < x_lb || V_C_E (y) > x_ub) abort(); Note how it checks that x is in the range of x's type, so this does not give any new information about x. It is true that multiple validity checks will not be eliminated (multiple normal checks will be eliminated), but validity checks are not that common. One place that might hurt is in array accesses: IIRC the front-end does a validity check on the index before accessing an array, rather than a normal check, because it considers it too dangerous to do otherwise (eg: they want to catch the case when the index has an out-of-range value because it is uninitialized). My suggested use of a builtin would allow multiple redundant validity checks to be safely eliminated, because the builtin would be a "pure" function. The validity check becomes: y2 = __builtin_nop(y); if (y2 < x_lb || y2 > x_ub) abort(); Now suppose you do another one: y22 = __builtin_nop(y); if (y22 < x_lb || y22 > x_ub) abort(); The compiler can deduce that y2 and y22 are the same, and eliminate the second check. > I believe this will not automatically > happen at the moment because V_C_E (y) will not have the same > ssa name assigned for evey occurance. But of course we will never know until > the Ada FE people finally fix their frontend. > > All the mess would be way easier if the FE would not expose the subtypes to > the middle-end... I agree. The LLVM model seems more sensible in this regard. D. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #33 from baldrick at free dot fr 2007-03-09 11:50 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > My suggested use of a builtin would allow multiple redundant validity checks > to be safely eliminated, because the builtin would be a "pure" function. This is presumably also the case with V_C_E. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug middle-end/31096] a*C == b*C where C is a constant is not optimized to a == b
--- Comment #2 from joseph at codesourcery dot com 2007-03-09 12:06 ---
Subject: Re: New: a*C == b*C where C is a constant
is not optimized to a == b
On Fri, 9 Mar 2007, pinskia at gcc dot gnu dot org wrote:
> The following two functions should be equzlivant when overflow is undefined:
> int f(int a, int b)
> {
> return a * 10 == b*10;
> }
>
> int f1(int a, int b)
> {
> return a==b;
> }
If the constant is odd, they are equivalent for wrapping (but not for
trapping) and for unsigned as well.
(If the constant is 0, they aren't equivalent at all but the first should
become "return 1;".)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31096
[Bug c++/31102] New: ICE with -O2 -ftracer
> cat bug.cc
inline double f(double) {
int t;
asm("fldcw %0" : : "m"(t));
}
double a;
void g(unsigned long long c) {
double b = c;
a = f(b) ? b : b - a;
}
> g++ -O2 -ftracer bug.cc
bug.cc: In function 'void g(long long unsigned int)':
bug.cc:9: internal compiler error: Segmentation fault
> g++ --version
g++ (GCC) 4.3.0 20070309 (experimental)
--
Summary: ICE with -O2 -ftracer
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at pi dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31102
[Bug c++/31102] ICE with -O2 -ftracer
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 12:10:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31102
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #11 from tbm at cyrius dot com 2007-03-09 12:13 --- Another problem is that this warning does not always occur, even when I use the same source and options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL
--- Comment #2 from burnus at gcc dot gnu dot org 2007-03-09 12:29 ---
The error setting happens in io/transfer.c's write_buf:
/* Unformatted sequential. */
have_written = 0;
if (dtp->u.p.current_unit->flags.has_recl
&& (gfc_offset) nbytes > dtp->u.p.current_unit->bytes_left)
{
printf("write_buf: has_recl=%d, nbytes=%ld, bytes_left=%ld\n",
dtp->u.p.current_unit->flags.has_recl, nbytes,
dtp->u.p.current_unit->bytes_left);
nbytes = dtp->u.p.current_unit->bytes_left;
short_record = 1;
}
else
short_record = 0;
My added printf shows:
write_buf: has_recl=1, nbytes=4, bytes_left=0
The check was added in Thomas' record length patch PR 29568.
http://gcc.gnu.org/viewcvs/trunk/libgfortran/io/transfer.c?r1=119087&r2=119412&diff_format=h
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org, tkoenig at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug tree-optimization/30904] VRP does not track values of shifts and/or bitfields?
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-03-09 12:29 --- Subject: Bug 30904 Author: rguenth Date: Fri Mar 9 12:29:09 2007 New Revision: 122748 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122748 Log: 2007-03-09 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/30904 PR middle-end/31058 * tree-vrp.c (extract_range_from_binary_expr): Handle RSHIFT_EXPR the same way as *_DIV_EXPR. * gcc.dg/pr30904.c: Remove xfail. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr30904.c trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #24 from rguenth at gcc dot gnu dot org 2007-03-09 12:29 --- Subject: Bug 31058 Author: rguenth Date: Fri Mar 9 12:29:09 2007 New Revision: 122748 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122748 Log: 2007-03-09 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/30904 PR middle-end/31058 * tree-vrp.c (extract_range_from_binary_expr): Handle RSHIFT_EXPR the same way as *_DIV_EXPR. * gcc.dg/pr30904.c: Remove xfail. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr30904.c trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug tree-optimization/30904] VRP does not track values of shifts and/or bitfields?
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-03-09 12:29 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904
[Bug middle-end/31058] overflow warnings should not be enabled with -Wall
--- Comment #25 from rguenth at gcc dot gnu dot org 2007-03-09 12:30 --- The original issue is fixed. The rest belongs in a different bug. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30904 Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 Bug 31058 depends on bug 30904, which changed state. Bug 30904 Summary: VRP does not track values of shifts and/or bitfields? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30904 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31058
[Bug c++/30822] wrong choice of overloaded template functions in recursive call
--- Comment #6 from Zarathustra at gentlemansclub dot de 2007-03-09 12:35
---
(In reply to comment #5)
> So, the way I read this is that gcc3.3 and icc9.0 agree that the call is
> ambiguous. I must admit that I don't know whether this is the correct
> behavior.
Also the SunCC yields the ambiguity message. I think in all such cases the
compilers do not implement all rules for the look up of template names as given
by the standard. Probably starting from version 3.4.0 of gcc the error message
changes.
Perhaps it is worth taking a look at the following code:
One template argument is left away, and some "<>" are added.
foo2 is accepted, foo3 is not! From this I assume that there is some problem
with the implementation of the argument-dependent lookup (ADP) in gcc. Does
anyone have any other assumptions?
struct cons_end {};
template struct cons {
U elem;
V tail;
};
template
void foo2(U elem, V tail)
{
foo2(tail.elem,tail.tail);
}
template
void foo2(U elem, cons_end tail)
{}
template
void foo3(U elem, V tail)
{
foo3<>(tail.elem,tail.tail); // <-- the difference is here (<> added)
}
template
void foo3(U elem, cons_end tail)
{}
int main()
{
cons > list;
foo2(list.elem,list.tail);
foo2<>(list.elem,list.tail);
foo3(list.elem,list.tail);
}
The error message (from gcc 4.1.2 and gcc 4.3):
test_gccbug.cpp: In function "void foo3(U, V) [with U = int, V = cons_end]":
test_gccbug.cpp:32: instantiated from "void foo3(U, V) [with U = int, V =
cons]"
test_gccbug.cpp:44: instantiated from here
test_gccbug.cpp:32: error: "struct cons_end" has no member named "elem"
test_gccbug.cpp:32: error: "struct cons_end" has no member named "tail"
Volker
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30822
[Bug rtl-optimization/30643] [4.1/4.2/4.3 regression] CSE pessimization
--- Comment #11 from patchapp at dberlin dot org 2007-03-09 12:40 --- 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/msg00545.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30643
[Bug c++/31103] New: [4.3 Regression] same canonical type node for different types with long int
warning: same canonical type node for different types - with long int % /usr/lib/gcc-snapshot/bin/g++ -c -g -O2 icu-dtfmtsym.ii dtfmtsym.cpp: In member function 'void icu_3_6::DateFormatSymbols::setMonths(const icu_3_6::UnicodeStr ing*, int32_t, icu_3_6::DateFormatSymbols::DtContextType, icu_3_6::DateFormatSymbols::DtWidthType)': dtfmtsym.cpp:738: warning: same canonical type node for different types icu_3_6::UnicodeString [(long int)iftmp.95] and icu_3_6::UnicodeString [(long int)iftmp.95] unit size align 64 symtab 722782848 alias set 4 canonical type 0x2b142b13b600 fields ignored decl_6 BLK file ../common/unicode/unistr.h line 188 size unit size align 64 offset_align 128 offset bit offset context chain > context needs-constructor needs-destructor X() X(constX&) new new[] delete delete[] this=(X&) n_parents =1 use_template=0 interface-only pointer_to_this reference_to_this chain > needs-constructing type_4 BLK size unit size align 64 symtab 0 alias set -1 canonical type 0x2b142aa21e40 precision 64 min max > side-effects invariant arg 0 side-effects invariant ... -- Summary: [4.3 Regression] same canonical type node for different types with long int Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
[Bug c++/31103] [4.3 Regression] same canonical type node for different types with long int
--- Comment #1 from tbm at cyrius dot com 2007-03-09 12:46 --- Created an attachment (id=13176) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13176&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
[Bug c++/31104] New: [4.3 Regression] same canonical type node for different types with anonymous
warning: same canonical type node for different types - anonymous % /usr/lib/gcc-snapshot/bin/g++ -c -g -O2 dosbox-sdl_mapper.ii sdl_mapper.cpp: In function 'void CreateBindGroups()': sdl_mapper.cpp:1554: warning: same canonical type node for different types CBindList [(long int)] and CBindList [(long int)] unit size align 64 symtab 1730749184 alias set -1 canonical type 0x2b3867280e40 fields ignored decl_6 BLK file /usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.3.0/../../../../i nclude/c++/4.3.0/bits/stl_list.h line 408 size unit size align 64 offset_align 128 offset bit offset context chain > context needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=1 use_template=1 interfac e-unknown pointer_to_this reference_to_this chain > needs-constructing type_4 BLK size unit size align 64 symtab 0 alias set -1 canonical type 0x2b3865afbe40 precision 64 min max > side-effects invariant ... -- Summary: [4.3 Regression] same canonical type node for different types with anonymous Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31104
[Bug c++/31078] [4.3 Regression] warning: same canonical type node for different types with const strings
--- Comment #12 from tbm at cyrius dot com 2007-03-09 12:49 --- PR31103 - same canonical type node for different types with long int PR31104 - same canonical type node for different types with anonymous -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31078
[Bug c++/31104] [4.3 Regression] same canonical type node for different types with anonymous
--- Comment #1 from tbm at cyrius dot com 2007-03-09 12:50 --- Created an attachment (id=13177) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13177&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31104
[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL
--- Comment #3 from burnus at gcc dot gnu dot org 2007-03-09 12:55 ---
I was checking where bytes_left is set:
open.c: u->bytes_left = 0;
This is the default setting in new_unit (/* Open an unused unit. */)
It is also set to 0 in file_pos.c (two places).
In list_read.c's next_char it is set to current_unit->recl;
And in transfer.c:
- read_block
- write_block (but only if stdout/stderr or default reclen, otherwise a
ERROR_EOR error is generated, but this is not the error of this PR.)
- us_read
- us_write: This one is also not called for this PR
- next_record_w: Not for unformatted
The problem seems to be that bytes_left == 0 from the initial setting in
new_unit as no data has been written. And as 4bytes have to be written, nbytes
= 4 > bytes_left.
Note: The same problem occurs if one tries to read from a file which has been
written by gfortran-4.1. In this case the error condition is in:
transfer.c's read_block_direct:
if (dtp->u.p.current_unit->flags.has_recl)
{
to_read_record =
*nbytes > (size_t) dtp->u.p.current_unit->bytes_left ?
*nbytes : (size_t) dtp->u.p.current_unit->bytes_left;
short_record = 1;
}
else
{
to_read_record = *nbytes;
short_record = 0;
}
This check has been introduced by the same patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug c++/31103] [4.3 Regression] same canonical type node for different types with long int
--- Comment #2 from tbm at cyrius dot com 2007-03-09 13:06 --- Created an attachment (id=13178) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13178&action=view) testcase I should mention that this warning doesn't show up all the time, but it'll eventually show when you try long enough. This applies both to the smaller testcase and the original preprocessed source. See e.g. here: (sid)4419:[EMAIL PROTECTED]: ~] rm -f icu*.o; g++ -c -g -O2 icu*.cc > x 2>&1 ; ls -l x -rw-r--r-- 1 tbm users 0 2007-03-09 13:00 x (sid)4420:[EMAIL PROTECTED]: ~] rm -f icu*.o; g++ -c -g -O2 icu*.cc > x 2>&1 ; ls -l x -rw-r--r-- 1 tbm users 0 2007-03-09 13:00 x (sid)4421:[EMAIL PROTECTED]: ~] rm -f icu*.o; g++ -c -g -O2 icu*.cc > x 2>&1 ; ls -l x -rw-r--r-- 1 tbm users 0 2007-03-09 13:00 x (sid)4422:[EMAIL PROTECTED]: ~] rm -f icu*.o; g++ -c -g -O2 icu*.cc > x 2>&1 ; ls -l x -rw-r--r-- 1 tbm users 55766 2007-03-09 13:00 x (sid)4423:[EMAIL PROTECTED]: ~] head -3 x icu-dtfmtsym.cc: In member function 'void icu_3_6::DateFormatSymbols::initZoneStrings(UErrorCode&)': icu-dtfmtsym.cc:166: warning: same canonical type node for different types icu_3_6::UnicodeString [(long int)iftmp.10] and icu_3_6::UnicodeString [(long int)iftmp.10] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
[Bug driver/31087] gcc 323 reports "output filename specified twice error" for simple x.c compilation
--- Comment #2 from droessle at us dot ibm dot com 2007-03-09 13:25 --- Thanks for the direction. I will take the issue up at RH. -- droessle at us dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31087
[Bug c/31105] New: build broken (trunk rev 122742)
/home/Marco/Desktop/compile-lin-lin/gcc-build/./prev-gcc/xgcc -B/home/Marco/Desktop/compile-lin-lin/gcc-build/./prev-gcc/ -B/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -I. -I. -I/usr/local/src/gcc/gcc -I/usr/local/src/gcc/gcc/. -I/usr/local/src/gcc/gcc/../include -I/usr/local/src/gcc/gcc/../libcpp/include -I/home/Marco/Desktop/compile-lin-lin/gmp-out/include -I/home/Marco/Desktop/compile-lin-lin/mpfr-out/include -I/usr/local/src/gcc/gcc/../libdecnumber -I../libdecnumber /usr/local/src/gcc/gcc/recog.c -o recog.o cc1: warnings being treated as errors /usr/local/src/gcc/gcc/recog.c: In function 'decode_asm_operands': /usr/local/src/gcc/gcc/recog.c:1558: error: ISO C90 forbids mixed declarations and code /usr/local/src/gcc/gcc/recog.c:1600: error: ISO C90 forbids mixed declarations and code make[3]: *** [recog.o] Error 1 make[3]: Leaving directory `/home/Marco/Desktop/compile-lin-lin/gcc-build/gcc' This strongly remembers me to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510 Is it possible that some flags trigger the "warnings being treated as errors" but most developers don't use this? That would explain why people stumble over it while it seems to work after changes for the developers?! I configured with: /usr/local/src/gcc/configure --prefix=/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin --with-sysroot=/home/Marco/Desktop/compile-lin-lin/gcc-XYZXYZ-lin/sys-root --build=`/usr/local/src/gcc/config.guess` --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --enable-languages=c,c++,java --enable-libgcj --disable-shared --with-gnu-as --with-gnu-ld --disable-nls --disable-debug --disable-checking --enable-threads=posix --disable-win32-registry --enable-java-gc=boehm --enable-java-maintainer-mode --with-gmp=/home/Marco/Desktop/compile-lin-lin/gmp-out --with-mpfr=/home/Marco/Desktop/compile-lin-lin/mpfr-out -- Summary: build broken (trunk rev 122742) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch 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=31105
[Bug c++/31106] New: FPE, floating point exception bugs
1) fesetexcept(FE_EXCEPT_ALL) sets the control fpu control word to 0x342, so that the denormal operand exeption is masked, by definition all exceptions are supposed to be enabled so it should be using 0x340. 2) If I establish a signal handler for FPEs the fpu is being reset to its default state before the signal handler is called, so that fegetexcept and fegetenv are unable to return any information about the exception that occured. here is information about my FC2 x86_64 athlon system: [EMAIL PROTECTED] burlen]$ g++ -v Reading specs from /usr/lib/gcc-lib/x86_64-redhat-linux/3.3.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --disable-libunwind-exceptions --with-system-zlib --enable-__cxa_atexit --host=x86_64-redhat-linux Thread model: posix gcc version 3.3.3 20040412 (Red Hat Linux 3.3.3-7) -- Summary: FPE, floating point exception bugs Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burlen at apollo dot sr dot unh dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31106
[Bug c++/31106] FPE, floating point exception bugs
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 13:58 --- These are all not compiler issues but glibc and/or kernel issues. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31106
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #34 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09 13:59 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > You may well respond that you are only supposed to forget > information you deduced from the range of the type, not information > you worked out by some other means. But these cannot really be > distinguished, c.f. VRP. Exactly. That's indeed the problem. It's similar to the whole signed-overflow issue: what you're able to safely do with with VRP-derived information depends on how you derived it and there's no way of tracking that. > Surely you only have to prove that it is in the range of Y, since if it > is not in the range of X then you have a bounded error, and doing a NOP_EXPR > should be perfectly legal. Think of a range check being done in a subscript reference in the LHS of an assignment. A bounded error is not allowed to cause a memory store outside the bounds of an array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug c/31105] build broken (trunk rev 122742)
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 13:59 --- Fixed by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122746 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31105
[Bug rtl-optimization/31101] Problem with -funroll-all-loops
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-09 14:03 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-09 14:03:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31101
[Bug boehm-gc/29476] [cygwin] gcc compilation is broken
--- Comment #3 from mtrudel at gmx dot ch 2007-03-09 14:05 --- I close this bug as "WONTFIX" because there's no active cygwin maintainer for libjava. So, if it's not fixed already, it probably won't be fixed anyway. I just once tested it for fun :-) -- mtrudel at gmx dot ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29476
[Bug c/31105] build broken (trunk rev 122742)
--- Comment #2 from mtrudel at gmx dot ch 2007-03-09 14:12 --- Thanks. But actually I also tried to start a discussion why such compilation errors can happen: This strongly remembers me to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510 Is it possible that some flags trigger the "warnings being treated as errors" but most developers don't use this? That would explain why people stumble over it while compilation seems to work for the developers?! Of course I could be completely wrong. But if I'm right, there would be an easy way to prevent such build breaks... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31105
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #35 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09 14:18 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > All the mess would be way easier if the FE would not expose the subtypes to > the middle-end... I don't see how giving *additional* information could be bad: the middle-end is certainly free to ignore the bounds if it wants to! The point is that the bounds *do* say something and provide useful information to optimizers. The problem is that they don't say what the middle-end *wants* them to say! What they *do* mean is that it's a "bounded error" for a variable to have a value outside of the given bounds. What the middle-end *wants* them to mean is that it's *erroneous* for a variable to have a value outside of the given bounds. We need to reconcile those two concepts. >From a pragmatic point of view, they aren't that different, but there are a couple of important exceptions. The array bound on the LHS is one of them. A full solution to this is complex, but is indeed something that I'd like to happen some day. It involves work in various places. One thing that would help is that many variables can be proven to have the property that the only way they can have an invalid value is if erroneous behavior has occurred. For such variables, the meaning of the bounds is precisely what the middle-end expects it to mean. The most common case where you can't do this is for component references or pointer dereferences. In that case, we have to address this by distinguishing between two types of tests, those that will just propagate the bounded error condition and those that would convert a bounded error to erroneous behavior. We are allowed to use the bounds information in reasoning about the former, but not the latter. Note that there are similarities to the signed-overflow case here: there are some tests that we can safely eliminate with knowlege that signed-overflow is undefined, but others that we don't want to. So I think the "final" solution here will be to have the Ada front end provide the flag information on variables and tests mentioned above and extend VRP to use them. One of the two front-end issues (the latter) is quite easy and I think the other is moderately-easy. I don't know how much work the required VRP changes would be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug ada/26797] [4.3 regression] ACATS cxh1001 fails
--- Comment #36 from kenner at vlsi1 dot ultra dot nyu dot edu 2007-03-09 14:29 --- Subject: Re: [4.3 regression] ACATS cxh1001 fails > I don't think this is a very serious problem. My understanding is > that the checks can be divided into two classes: normal checks and > validity checks. A normal check, such as when you do a type > conversion, does not use a V_C_E, it just does: > > if (y < new_type_lb || y > new_type_ub) > abort; > new_var = (new_type) y; Not clear. Consider the range check for a subscript on the LHS, for example. These issues are *very* subtle ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug c++/31103] [4.3 Regression] same canonical type node for VLAs
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 Regression] same |[4.3 Regression] same |canonical type node for |canonical type node for VLAs |different types with long | |int | Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31103
[Bug driver/31107] New: --target-help doesn't say which options are compiler, assembler or linker options
--target-help shows compiler, assembler and linker options together, without saying which is which. It can confuse users (see PR31073 for example). Example: on i686-pc-linux-gnu, with mainline: $ gcc --target-help | tail -n 35 -mtune= Schedule code for given CPU -muclibcUse uClibc instead of GNU libc -Q ignored -V print assembler version number -k ignored -n Do not optimize code alignment -q quieten some warnings -s ignored --divideignored elf_i386: -Bgroup Selects group name lookup rules for DSO --disable-new-dtags Disable new dynamic tags --enable-new-dtagsEnable new dynamic tags --eh-frame-hdrCreate .eh_frame_hdr section -z combreloc Merge dynamic relocs into one section and sort -z defs Report unresolved symbols in object files. -z execstack Mark executable as requiring executable stack -z initfirst Mark DSO to be initialized first at runtime -z interpose Mark object to interpose all DSOs but executable -z loadfltr Mark object requiring immediate process -z muldefsAllow multiple definitions -z nocombrelocDon't merge dynamic relocs into one section -z nocopyrelocDon't create copy relocs -z nodefaultlib Mark object not to use default search paths -z nodelete Mark DSO non-deletable at runtime -z nodlopen Mark DSO not available to dlopen -z nodump Mark DSO not available to dldump -z noexecstackMark executable as not requiring executable stack -z norelroDon't create RELRO program header -z nowMark object non-lazy runtime binding -z origin Mark object requiring immediate $ORIGIN processing at runtime -z relro Create RELRO program header -z KEYWORDIgnored for Solaris compatibility The first options displayed above are the last of the compiler options, followed (without any explicit mention) by the assembler options, and the linker options. Users then want to try an option in the list, and it doesn't work: $ gcc --eh-frame-hdr a.c cc1: error: unrecognized command line option "-feh-frame-hdr" -- Summary: --target-help doesn't say which options are compiler, assembler or linker options Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31107
[Bug driver/31107] --target-help doesn't say which options are compiler, assembler or linker options
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.1.1 4.2.0 4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-03-09 15:18:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31107
[Bug target/31073] symbol names are not created with stdcall syntax
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-03-09 15:23 --- (In reply to comment #6) > when typing gfortran --target-help those options are all listed as compiler > options. We all agree it's a bug: compiler, assembler and linker options are listed there indifferently. I filed it as a different PR (PR 31107) so that we don't get too confused. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug driver/31107] --target-help doesn't say which options are compiler, assembler or linker options
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-09 15:23 --- I think gas should be fixed instead of the driver. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31107
[Bug boehm-gc/29476] [cygwin] gcc compilation is broken
--- Comment #4 from manu at gcc dot gnu dot org 2007-03-09 15:30 --- (In reply to comment #3) > I close this bug as "WONTFIX" because there's no active cygwin maintainer for > libjava. So, if it's not fixed already, it probably won't be fixed anyway. > I just once tested it for fun :-) > Hum, perhaps someone will step in in the future... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29476
[Bug ada/31108] New: [regression 4.2] ACATS C35507M fails on MinGW
The ACATS failure occurs with gcc-4.2-20070307 bootstrapped from gcc-4.2-20061226. I was not able to build any 4.0 or 4.1 Ada compiler on MinGW, so this is a regression against gcc-3.4. ,.,. C35507M ACATS 2.5 07-03-09 15:15:52 C35507M CHECK THAT THE ATTRIBUTES 'POS' AND 'VAL' YIELD THE CORRECT RESULTS WHEN THE PREFIX IS A CHARACTER TYPE WITH AN ENUMERATION REPESENTATION CLAUSE. * C35507M NO EXCEPTION RAISED FOR CHAR'VAL (IDENT_INT(2)) - 2. * C35507M NO EXCEPTION RAISED FOR NEWCHAR'VAL (IDENT_INT (-1)) - 2. C35507M FAILED . -- Summary: [regression 4.2] ACATS C35507M fails on MinGW Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rolf dot ebert dot gcc at gmx dot de GCC host triplet: mingw32 GCC target triplet: mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31108
[Bug c/17946] wanted: warning for "a && MASK" when "a & MASK" was probably intended
--- Comment #13 from mueller at gcc dot gnu dot org 2007-03-09 16:16 --- Subject: Bug 17946 Author: mueller Date: Fri Mar 9 16:16:35 2007 New Revision: 122751 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122751 Log: 2007-03-09 Dirk Mueller <[EMAIL PROTECTED]> PR c++/17946 * doc/invoke.texi (-Wlogical-op): Document. * common.opt (-Wlogical-op): New. * c-common.h (warn_logical_operator): Declare. * c-common.c (warn_logical_operator): Define. * c-typeck.c (parser_build_binary_op): Call warn_logical_operator. * cp/call.c (build_new_op): Call warn_logical_operator. * testsuite/gcc.dg/Wlogical-op-1.c: New. * testsuite/g++.dg/warn/Wlogical-op-1.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/Wlogical-op-1.C trunk/gcc/testsuite/gcc.dg/Wlogical-op-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-common.h trunk/gcc/c-typeck.c trunk/gcc/common.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c/17946] wanted: warning for "a && MASK" when "a & MASK" was probably intended
--- Comment #14 from mueller at gcc dot gnu dot org 2007-03-09 16:17 --- Fixed for 4.3. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17946
[Bug c/31109] New: gcc 3.3 not functioning under Interix 3.5
gcc 3.3 is working fine in Interix (Services for Unix under Windows) on other Windows XP machines that I use (both laptop and desktop) A new installation of SFU35SEL_EN.exe (SFU/Interix) on a new IBM ThinkPad laptop with Centrino Duo procesor does not seem to allow compilation of any program (I for instance tried the well-known dedos program). The system description is: Interix 3.5 SP-8.0.1969.1 x86 Intel_x86_Family6_Model15_Stepping6 while the reported error message (in response to: gcc dedos.c) is: gcc; Internal error: Segmentation fault (program cc1) -- Summary: gcc 3.3 not functioning under Interix 3.5 Product: gcc Version: 3.3 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: j dot b dot o dot s dot martens at tue dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31109
[Bug target/31109] gcc 3.3 not functioning under Interix 3.5
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31109
[Bug target/30987] [4.3 Regression] Problem while compiling gcc for score
--- Comment #4 from mstein at phenix dot rootshell dot be 2007-03-09 17:05 --- Created an attachment (id=13179) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13179&action=view) from SVN revision: 122728 Commandline used to create libgcc2.i: /home/mstein/sim/score-elf/build/./gcc/xgcc -B/home/mstein/sim/score-elf/build/./gcc/ -nostdinc -B/home/mstein/sim/score-elf/build/score-elf/newlib/ -isystem /home/mstein/sim/score-elf/build/score-elf/newlib/targ-include -isystem /n/07/mstein/combined-trunk/newlib/libc/include -B/n/07/mstein/cross-local/score-elf-new/score-elf/bin/ -B/n/07/mstein/cross-local/score-elf-new/score-elf/lib/ -isystem /n/07/mstein/cross-local/score-elf-new/score-elf/include -isystem /n/07/mstein/cross-local/score-elf-new/score-elf/sys-include -L/home/mstein/sim/score-elf/build/./ld -O2 -g -O2 -mmac -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -G 0 -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/n/07/mstein/combined-trunk/libgcc -I/n/07/mstein/combined-trunk/libgcc/. -I/n/07/mstein/combined-trunk/libgcc/../gcc -I/n/07/mstein/combined-trunk/libgcc/../include -I/n/07/mstein/combined-trunk/libgcc/../libdecnumber -I../../../libdecnumber -o _floatdisf.o -MT _floatdisf.o -MD -MP -MF _floatdisf.dep -DL_floatdisf -c /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c \ -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30987
[Bug target/31073] symbol names are not created with stdcall syntax
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-03-09 17:05 --- This is not that much of a blocker, really. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug target/31073] symbol names are not created with stdcall syntax
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-03-09 17:08 --- In fact this is an enhancement and really there just needs a new win32 option for this feature. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|GNU Fortran 95 (GCC) 4.3.0 | |20061021 (experimental) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31073
[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
--- Comment #3 from hjl at lucon dot org 2007-03-09 17:11 --- Gcc 4.3 revision 122738 has the same issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug c/31105] build broken (trunk rev 122742)
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-09 17:14 --- > Of course I could be completely wrong. But if I'm right, there would be an > easy > way to prevent such build breaks... People make mistakes, this was just one of them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31105
[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
--- Comment #4 from hjl at lucon dot org 2007-03-09 17:40 --- Created an attachment (id=13180) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13180&action=view) A breakdown testcase xxx.f90 is the problem. -fdump-tree-all shows that revision 121302 generates very different alias info. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
--- Comment #5 from dberlin at gcc dot gnu dot org 2007-03-09 17:51 --- Subject: Re: Revision 121302 causes 30% performance regression Could you attach dumps for fdump-tree-alias-vops-details-blocks-stats (tarr'ing up the resulting dumps is fine) for before and after? I don't have a clean tree around, and it would really help. (If not, it's okay, it would just make my analysis faster). On 9 Mar 2007 17:40:50 -, hjl at lucon dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #4 from hjl at lucon dot org 2007-03-09 17:40 --- > Created an attachment (id=13180) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13180&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13180&action=view) > A breakdown testcase > > xxx.f90 is the problem. -fdump-tree-all shows that revision 121302 > generates very different alias info. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090 > > --- You are receiving this mail because: --- > You are on the CC list for the bug, or are watching someone who is. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
--- Comment #20 from dberlin at gcc dot gnu dot org 2007-03-09 17:55 --- Uh, i think i accidentally fixed the reduced testcase with my recent alias patch (r122741). Are the others still failing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
[Bug tree-optimization/31090] Revision 121302 causes 30% performance regression
--- Comment #6 from hjl at lucon dot org 2007-03-09 17:57 --- Created an attachment (id=13181) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13181&action=view) Dumps of -fdump-tree-alias-vops-details-blocks-stats 121301 is from revision 121301 and 121302 is from revision 121302. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31090
[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-03-09 18:02
---
I believe I have a fix. I am testing now. We were not initializing a few
things when we have a record length given.
Index: io/open.c
===
--- io/open.c (revision 122529)
+++ io/open.c (working copy)
@@ -437,6 +437,8 @@ new_unit (st_parameter_open *opp, gfc_un
{
u->flags.has_recl = 1;
u->recl = opp->recl_in;
+ u->recl_subrecord = u->recl;
+ u->bytes_left = u->recl;
}
else
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug target/31110] New: Problem while compiling gcc for mn10300-elf
Hello, there seems to be a gcc problem with the target 'mn10300-elf': /home/mstein/sim/mn10300-elf/build/./gcc/xgcc -B/home/mstein/sim/mn10300-elf/build/./gcc/ -nostdinc -B/home/mstein/sim/mn10300-elf/build/mn10300-elf/newlib/ -isystem /home/mstein/sim/mn10300-elf/build/mn10300-elf/newlib/targ-include -isystem /n/07/mstein/combined-trunk/newlib/libc/include -B/n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/bin/ -B/n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/lib/ -isystem /n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/include -isystem /n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/sys-include -L/home/mstein/sim/mn10300-elf/build/./ld -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.15.0\" -DPACKAGE_STRING=\"newlib\ 1.15.0\" -DPACKAGE_BUGREPORT=\"\" -I. -I/n/07/mstein/combined-trunk/newlib/libc/stdlib -O2 -fno-builtin -O2 -g -O2 -mam33 -c -o lib_a-ldtoa.o `test -f 'ldtoa.c' || echo '/n/07/mstein/combined-trunk/newlib/libc/stdlib/'`ldtoa.c /n/07/mstein/combined-trunk/newlib/libc/stdlib/ldtoa.c: In function '_ldtoa_r': /n/07/mstein/combined-trunk/newlib/libc/stdlib/ldtoa.c:2858: internal compiler error: in default_secondary_reload, at targhooks.c:588 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[8]: *** [lib_a-ldtoa.o] Error 1 make[8]: Leaving directory `/home/mstein/sim/mn10300-elf/build/mn10300-elf/am33/newlib/libc/stdlib' The SVN revision was 122728. -- Summary: Problem while compiling gcc for mn10300-elf Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: mn10300-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
[Bug tree-optimization/29877] [4.0/4.1/4.2 Regression] out of SSA (TER) extends variable life of variable beyond original declared
--- Comment #7 from amacleod at redhat dot com 2007-03-09 18:11 --- Subject: Bug 29877 Author: amacleod Date: Fri Mar 9 18:11:40 2007 New Revision: 122754 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122754 Log: 2006-03-09 Mark Shinwell <[EMAIL PROTECTED]> Andrew MacLeod <[EMAIL PROTECTED]> PR tree-optimization/29877 * tree-outof-ssa.c (check_replaceable): Don't allow TER to replace an expression if the RHS is a register variable. testsuite * gcc.dg/pr16194.c: Skip test entirely if we don't know the name of a hard register for the target concerned. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr16194.c branches/gcc-4_2-branch/gcc/tree-outof-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29877
[Bug target/31110] Problem while compiling gcc for mn10300-elf
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-03-09 18:16 --- Created an attachment (id=13182) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13182&action=view) from SVN revision: 122728 Commandline used to create ldtoa.i: /home/mstein/sim/mn10300-elf/build/./gcc/xgcc -B/home/mstein/sim/mn10300-elf/build/./gcc/ -nostdinc -B/home/mstein/sim/mn10300-elf/build/mn10300-elf/newlib/ -isystem /home/mstein/sim/mn10300-elf/build/mn10300-elf/newlib/targ-include -isystem /n/07/mstein/combined-trunk/newlib/libc/include -B/n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/bin/ -B/n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/lib/ -isystem /n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/include -isystem /n/07/mstein/cross-local/mn10300-elf-new/mn10300-elf/sys-include -L/home/mstein/sim/mn10300-elf/build/./ld -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.15.0\" -DPACKAGE_STRING=\"newlib\ 1.15.0\" -DPACKAGE_BUGREPORT=\"\" -I. -I/n/07/mstein/combined-trunk/newlib/libc/stdlib -O2 -fno-builtin -O2 -g -O2 -mam33 -c -o lib_a-ldtoa.o `test -f 'ldtoa.c' || echo '/n/07/mstein/combined-trunk/newlib/libc/stdlib/'`ldtoa.c -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
[Bug c++/30895] [4.1/4.2/4.3 regression] ICE with complex values in template parameter
--- Comment #7 from simartin at gcc dot gnu dot org 2007-03-09 18:21 --- Fixed in 4.1, 4.2 and 4.3. -- simartin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30895
[Bug rtl-optimization/31101] Problem with -funroll-all-loops (postreload CSE problems)
--- Comment #2 from ubizjak at gmail dot com 2007-03-09 18:21 ---
No, this is not a target problem. I have traced the problem down to
reload_cse_simplify(), where insn that loads flags (either test or sahf) gets
cleared. This is highly suspicious part of code (why value is set to 0 ?):
if (!count && reload_cse_noop_set_p (body))
{
rtx value = SET_DEST (body);
if (REG_P (value)
&& ! REG_FUNCTION_VALUE_P (value))
value = 0;
delete_insn_and_edges (insn);
return;
}
So, reload_cse_noop_set_p() through rtx_equal_for_cse_lib_p() finds many copies
of:
(set (reg:CCNO 17 flags)
(compare:CCNO (and:SI (zero_extract:SI (reg:HI 0 ax [73])
(const_int 8 [0x8])
(const_int 8 [0x8]))
(const_int 4 [0x4]))
(const_int 0 [0x0])))
And since postreload CSE pass thinks it can copy them from previous flag
register (neglecting the fact that ax is changed in a preceeding insn), it
clears all but the first two occurences of flags loading insn. Following this,
second postreload CSE pass removes also fnstsw instructions.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Component|target |rtl-optimization
Summary|Problem with -funroll-all- |Problem with -funroll-all-
|loops |loops (postreload CSE
||problems)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31101
[Bug c++/30811] __FUNCTION__ allowed in function declaration
--- Comment #6 from sebor at roguewave dot com 2007-03-09 18:25 --- (In reply to comment #5) Good point! I hadn't thought of that. Since that option is out and __FUNCTION__ should simply behave identically to __func__ and be disallowed in global or namespace scope function argument lists, or its documentation should be changed to say that unlike __func__, __FUNCTION__ is allowed in argument lists of C++ functions declared at namespace scope. The point is that if the two are documented to be interchangeable users ought to be able to switch between one and the other with no change in behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30811
[Bug c/27030] Warning instead of error with weakref on local functions (also wrong warning message at that)
--- Comment #2 from manu at gcc dot gnu dot org 2007-03-09 18:33 --- (In reply to comment #1) > 4.1.0 fails the same way. > 4.3.0 revision 122287 says: pr27030.c: In function f: pr27030.c:3: warning: __weakref__ attribute ignored -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27030
[Bug c++/30857] [4.1/4.2/4.3 regression] accepts both explicit instantiation and explicit specialization, duplicate explicit instantiations, etc.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30857
[Bug target/31111] New: Problem while compiling gcc for sh-elf
Hello, there seems to be a gcc problem with the target 'sh-elf': /home/mstein/sim/sh-elf/build/./gcc/xgcc -B/home/mstein/sim/sh-elf/build/./gcc/ -nostdinc -B/home/mstein/sim/sh-elf/build/sh-elf/newlib/ -isystem /home/mstein/sim/sh-elf/build/sh-elf/newlib/targ-include -isystem /n/07/mstein/combined-trunk/newlib/libc/include -B/n/07/mstein/cross-local/sh-elf-new/sh-elf/bin/ -B/n/07/mstein/cross-local/sh-elf-new/sh-elf/lib/ -isystem /n/07/mstein/cross-local/sh-elf-new/sh-elf/include -isystem /n/07/mstein/cross-local/sh-elf-new/sh-elf/sys-include -L/home/mstein/sim/sh-elf/build/./ld -O2 -g -O2 -m2a -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/n/07/mstein/combined-trunk/libgcc -I/n/07/mstein/combined-trunk/libgcc/. -I/n/07/mstein/combined-trunk/libgcc/../gcc -I/n/07/mstein/combined-trunk/libgcc/../include -I/n/07/mstein/combined-trunk/libgcc/../libdecnumber -I../../../libdecnumber -o _divdi3.o -MT _divdi3.o -MD -MP -MF _divdi3.dep -DL_divdi3 -c /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c \ -fexceptions -fnon-call-exceptions /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c: In function '__divdi3': /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c:1102: internal compiler error: in create_pre_exit, at mode-switching.c:352 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[4]: *** [_divdi3.o] Error 1 make[4]: Leaving directory `/home/mstein/sim/sh-elf/build/sh-elf/m2a/libgcc' The SVN revision was 122728. -- Summary: Problem while compiling gcc for sh-elf Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: sh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug target/31111] Problem while compiling gcc for sh-elf
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-03-09 19:16 --- Created an attachment (id=13183) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13183&action=view) from SVN revision: 122728 Commandline used to create libgcc2.i: /home/mstein/sim/sh-elf/build/./gcc/xgcc -B/home/mstein/sim/sh-elf/build/./gcc/ -nostdinc -B/home/mstein/sim/sh-elf/build/sh-elf/newlib/ -isystem /home/mstein/sim/sh-elf/build/sh-elf/newlib/targ-include -isystem /n/07/mstein/combined-trunk/newlib/libc/include -B/n/07/mstein/cross-local/sh-elf-new/sh-elf/bin/ -B/n/07/mstein/cross-local/sh-elf-new/sh-elf/lib/ -isystem /n/07/mstein/cross-local/sh-elf-new/sh-elf/include -isystem /n/07/mstein/cross-local/sh-elf-new/sh-elf/sys-include -L/home/mstein/sim/sh-elf/build/./ld -O2 -g -O2 -m2a -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I/n/07/mstein/combined-trunk/libgcc -I/n/07/mstein/combined-trunk/libgcc/. -I/n/07/mstein/combined-trunk/libgcc/../gcc -I/n/07/mstein/combined-trunk/libgcc/../include -I/n/07/mstein/combined-trunk/libgcc/../libdecnumber -I../../../libdecnumber -o _divdi3.o -MT _divdi3.o -MD -MP -MF _divdi3.dep -DL_divdi3 -c /n/07/mstein/combined-trunk/libgcc/../gcc/libgcc2.c \ -fexceptions -fnon-call-exceptions -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3
[Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
--- Comment #21 from tbm at cyrius dot com 2007-03-09 19:28 --- (In reply to comment #20) > Uh, i think i accidentally fixed the reduced testcase with my recent alias > patch (r122741). > Are the others still failing? Yes, conf.i is still failing at -O2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
[Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
--- Comment #22 from tbm at cyrius dot com 2007-03-09 19:34 ---
Testcase based on conf.i:
struct symbol
{
char *help;
};
struct menu
{
struct menu *next;
struct menu *list;
struct symbol *sym;
};
enum
{
ask_all,
}
input_mode = ask_all;
static char line[128];
static char nohelp_text[] =
("Sorry, no help available for this option yet.\n");
conf_choice (struct menu *menu)
{
struct menu *child;
while (1)
{
int cnt, def;
conf_childs:for (child = menu->list; child; child = child->next)
{
if (!child->sym || !menu_is_visible (child))
if (!--cnt)
break;
}
if (!child)
continue;
if (line[strlen (line) - 1] == '?')
{
printf ("\n%s\n", child->sym->help ? child->sym->help : "");
continue;
}
return 1;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
[Bug target/31113] New: Problem while compiling gcc for m32c-elf
Hello, there seems to be a gcc problem with the target 'm32c-elf': When I use make -j 1 it works, whith make -j 2 it fails. gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I/n/07/mstein/svn/trunk/gcc -I/n/07/mstein/svn/trunk/gcc/. -I/n/07/mstein/svn/trunk/gcc/../include -I/n/07/mstein/svn/trunk/gcc/../libcpp/include -I/n/07/mstein/gmp-stuff/include -I/n/07/mstein/svn/trunk/gcc/../libdecnumber -I../libdecnumber -I. -I. -I/n/07/mstein/svn/trunk/gcc -I/n/07/mstein/svn/trunk/gcc/. -I/n/07/mstein/svn/trunk/gcc/../include -I/n/07/mstein/svn/trunk/gcc/../libcpp/include -I/n/07/mstein/gmp-stuff/include -I/n/07/mstein/svn/trunk/gcc/../libdecnumber -I../libdecnumber /n/07/mstein/svn/trunk/gcc/config/m32c/m32c-pragma.c In file included from /n/07/mstein/svn/trunk/gcc/config/m32c/m32c-pragma.c:26: ./tm.h:12:29: error: insn-constants.h: No such file or directory ./tm.h:13:25: error: insn-flags.h: No such file or directory /n/07/mstein/svn/trunk/gcc/config/m32c/m32c-pragma.c: In function 'm32c_pragma_memregs': /n/07/mstein/svn/trunk/gcc/config/m32c/m32c-pragma.c:77: warning: assignment makes integer from pointer without a cast make[2]: *** [m32c-pragma.o] Error 1 The SVN revision was 122728. -- Summary: Problem while compiling gcc for m32c-elf Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: m32c-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31113
[Bug tree-optimization/30375] [4.3 Regression] tree-ssa-dse incorrectly removes struct initialization
--- Comment #9 from aldyh at gcc dot gnu dot org 2007-03-09 20:05 --- Subject: Bug 30375 Author: aldyh Date: Fri Mar 9 20:05:08 2007 New Revision: 122758 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122758 Log: PR tree-optimization/30375 * tree-ssa-dse.c (dse_possible_dead_store_p): Do not eliminate if LHS of statements is not the same. * testsuite/gcc.dg/tree-ssa/ssa-dse-10.c: New. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-10.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-dse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30375
[Bug fortran/31114] New: Consistent floating point arithmetic model option
This is a feature request.
It stems from a discussion on gcc-help ("RE: Internal representation of double
variables - 3.4.6 vs 4.1.0").
There is no general, high-level option to enforce any particular arithmetic
model. Thus running floating point code on different CPUs may give different
results. While this is a normal feature of floating point arithmetic, there
are well-defined models (such as the IEEE models) that allow for consistent
results without the influence of idiosyncrasies such as the x86 80 bit
registers.
Currently, options that give more consistent behaviour are architecture
specific (such as -mfpmath=sse). A top-level option to turn on these options
without having to dig into architecture-specific details would be an excellent
addition. Having an option to switch off a set of optimisations that impact on
the floating point precision would also be a wonderful thing.
In other words, I'm after an analogue of ifort's -mp/-fltconsistency/-mieee-fp.
--
Summary: Consistent floating point arithmetic model option
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terry at chem dot gu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31114
[Bug target/31113] Problem while compiling gcc for m32c-elf
--- Comment #1 from dj at redhat dot com 2007-03-09 20:08 --- Subject: Re: New: Problem while compiling gcc for m32c-elf Fixed via revision 122759. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31113
[Bug fortran/31114] Consistent floating point arithmetic model option
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-09 20:11 --- -ffloat-store *** This bug has been marked as a duplicate of 323 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31114
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #91 from pinskia at gcc dot gnu dot org 2007-03-09 20:11 --- *** Bug 31114 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||terry at chem dot gu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
