[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #35 from ubizjak at gmail dot com 2008-02-15 08:01 --- (In reply to comment #34) > With the patch in http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00507.html, the > PR is fixed without regression on intel(32/64 bit) and ppc(32 bit) darwin9. > I'll post the test results ASAP. Great! OTOH, the test for STACK_BOUNDARY can simply be removed, because PARM_BOUNDARY is always equal or smaller than STACK_BOUNDARY. I have checked all targets, and this is true everywhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug c++/35191] [4.3 regression] ICE: tree check: expected class 'expression', have 'exceptional' (error_mark) in bot_manip, at cp/tree.c:1480
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-02-15 08:19
---
Confirmed. This is a serious problem IMHO. Here's a valid example that crashes
for me:
#include
#include
struct A
{
std::string s;
};
struct B
{
B();
std::vector v;
};
B::B() : v(0) {}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Severity|normal |blocker
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC build triplet|i386-apple-darwin9.2.0 |
GCC host triplet|i386-apple-darwin9.2.0 |
GCC target triplet|i386-apple-darwin9.2.0 |
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2008-02-15 08:19:01
date||
Summary|internal compiler error:|[4.3 regression] ICE: tree
|tree check: expected class |check: expected class
|'expression', have |'expression', have
|'exceptional' (error_mark) |'exceptional' (error_mark)
|in bot_manip, at|in bot_manip, at
|cp/tree.c:1480 |cp/tree.c:1480
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35191
[Bug c++/35191] [4.3 regression] ICE: tree check: expected class 'expression', have 'exceptional' (error_mark) in bot_manip, at cp/tree.c:1480
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35191
[Bug c++/35191] [4.3 regression] ICE: tree check: expected class 'expression', have 'exceptional' (error_mark) in bot_manip, at cp/tree.c:1480
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-02-15 09:03
---
Reduced testcase:
struct A
{
A();
A(const A&);
};
struct B
{
A a;
};
struct C
{
C(const B& = B());
};
C c;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35191
[Bug c++/35191] [4.3 regression] ICE: tree check: expected class 'expression', have 'exceptional' (error_mark) in bot_manip, at cp/tree.c:1480
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-02-15 09:05 --- The (valid!) testcase in comment #4 gives the following error message: bug.cc:17: error: void value not ignored as it ought to be bug.cc:17: internal compiler error: tree check: expected class 'expression', have 'exceptional' (error_mark) in bot_manip, at cp/tree.c:1480 Please submit a full bug report, [etc.] -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35191
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #7 from rguenther at suse dot de 2008-02-15 09:08 --- Subject: Re: [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898 On Thu, 14 Feb 2008, steven at gcc dot gnu dot org wrote: > --- Comment #6 from steven at gcc dot gnu dot org 2008-02-14 23:25 > --- > Should be P1. P1 are bugs that block the release. With your reasoning below, this is not going to work out. Marcus, did you have checking enabled for your gcc build? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-02-15 09:23 --- Yeah, forwprop checks that it may propagate the name SR.40_22, but it doesn't check recursively if any of the names occuring in the ADDR_EXPR of the rhs are marked abnormal. We should check for this before calling forward_propagate_addr_expr in tree_ssa_forward_propagate_single_use_vars. And probably add a new predicate tree_contains_abnormal_ssa_name_p (tree exp) which walks exp recursively (consider &b->c[d(AB)] or as in this case &a(AB)->x...). Please unassign yourself if you want me to do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35164
[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35164
[Bug fortran/35150] ICE in expand_expr_addr_expr_1, at expr.c:6728 (regression vs. earlier 4.3)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35150
[Bug c++/35205] Structure enum wrongly interpreted as a variable in switch case.
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-15 09:40 ---
Either you want
struct s {
int i;
enum { x } foo;
}a;
and case a.foo: which is indeed not a integral cosntant expression or you
simply want
case x:
which is what of course works.
--
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=35205
[Bug c/35207] gcc does not warn when wrong value is passed to enumerated data type
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-15 09:43 --- We can add a warning to follow C++ which would reject this code. EDG for example says t.c(38): warning #188: enumerated type mixed with another type t.model_color = 5; but the C std says the enum can hold all values represented by the underlying type, so the code is behaving as required. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35207
[Bug c++/35191] [4.3 Regression] ICE: tree check: expected class 'expression', have 'exceptional' (error_mark) in bot_manip, at cp/tree.c:1480
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-02-15 09:54 --- All testcases work for me with r132335. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Keywords||ice-checking Resolution||FIXED Summary|[4.3 regression] ICE: tree |[4.3 Regression] ICE: tree |check: expected class |check: expected class |'expression', have |'expression', have |'exceptional' (error_mark) |'exceptional' (error_mark) |in bot_manip, at|in bot_manip, at |cp/tree.c:1480 |cp/tree.c:1480 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35191
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #36 from uros at gcc dot gnu dot org 2008-02-15 09:56 --- Subject: Bug 34621 Author: uros Date: Fri Feb 15 09:55:36 2008 New Revision: 132336 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132336 Log: PR middle-end/34621 * function.c (pad_to_arg_alignment): Remove test for STACK_BOUNDARY when calculating alignment_pad. Modified: trunk/gcc/ChangeLog trunk/gcc/function.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #37 from ubizjak at gmail dot com 2008-02-15 10:01 --- Fixed with the patch that removes the test for STACK_BOUNDARY. [Let's wait to see if there are any targets that break with this change...] -- ubizjak at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2008- |patches/2008- |02/msg00507.html|02/msg00541.html Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug ada/35194] floating point truncation error on intel platform
--- Comment #4 from jerome dot duquennoy at wanadoo dot fr 2008-02-15
10:11 ---
Created an attachment (id=15156)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15156&action=view)
floating point tests with different FPU configuration
This archive contains code to test the behavior of the floating points using
different configurations of the i387 FPU.
It shows that the Float type in ada only works well when using a 64 bits
mantissa.
When using a 53 bits mantissa, the results are the same as those obtained using
test_fio under valgrind or using Oracle's lib :
CW origine: 1.20001E+00
SW = 895
{Infinity Off; NEAREST_OR_EVEN; BITS_64}
Bits_53: 1.20831E+00
SW = 639
{Infinity Off; NEAREST_OR_EVEN; BITS_53}
Bits_24: 0.E+00
SW = 127
{Infinity Off; NEAREST_OR_EVEN; BITS_24}
The output under valgrind is weird : the Float IOs behave as if the FPU was is
53 bits mantissa mode, but the config is reported to be 64 bits ...
I guess this has to do with the way valgrind works.
When calling an oracle function, we can see that the FPU is in 64 bits mantissa
mode before the call, and 53 bits after, thus the problems we have.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35194
[Bug c/35207] gcc does not warn when wrong value is passed to enumerated data type
--- Comment #2 from manu at gcc dot gnu dot org 2008-02-15 10:24 --- *** This bug has been marked as a duplicate of 7654 *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35207
[Bug c/7654] -Wenum-assignment : Warn if an enum is being assigned a non enum value
--- Comment #8 from manu at gcc dot gnu dot org 2008-02-15 10:24 --- *** Bug 35207 has been marked as a duplicate of this bug. *** -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||venk2ksubbu at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7654
[Bug ada/35194] floating point truncation error on intel platform
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-02-15 10:25 ---
So this is a problem of the oracle library not re-setting FPU state. The
general ada problem, if it exists, is probably a dup of PR323 if it expects
double to behave consistently as if it had a mantissa of 53 bits. Note
that starting with gcc 4.3 there is a global flag to control FPU precision
at program start (-mpc{32,64,80}), but that affects all types and so doesn't
help here (but with -mpc64 the behavior should be consistent at least wrt
the oracle library).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35194
[Bug c/7654] warn if an enum is being assigned a non enum value
--- Comment #9 from manu at gcc dot gnu dot org 2008-02-15 10:36 --- It is not clear whether we want such a warning or not (and in 6 years, just 2 people have suggested it not too loudly). But if we do: * -Wstrict-enums seems a better name. It should be consistent and not handle only assignments but also argument passing. * An explicit cast should suppress the warning. * The warning should not be enabled by -Wall and probably neither by -Wextra because enums are *correctly* used as integers by C programmers. It is also unclear whether we want to warn for any integer/enum assigned to a different enum type or just for integers/enums outside the range of a particular enum type. -- manu at gcc dot gnu dot org changed: What|Removed |Added Summary|-Wenum-assignment : Warn if |warn if an enum is being |an enum is being assigned a |assigned a non enum value |non enum value | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7654
[Bug ada/35194] floating point truncation error on intel platform
--- Comment #6 from jerome dot duquennoy at wanadoo dot fr 2008-02-15 11:07 --- After testing it, the -mpc option do not help. I agree this seems to be a problem of oracle not re-setting the FPU state. Nevertheless, this makes ada unusable (or unreliable, which is not really better) with oracle 10, oracle 11, and potentially many other software under Linux ... a quite sad situation. At the beginning of set_image_real procedure, a call to a reset function is made. Comments indicate that this function is used to ensure the FPU is properly configured. In g-flocon.ads, the comments on this procedure state that : "For example under Windows NT some system DLL calls change the default FPU arithmetic to 64 bit precision mode. [...] The call to Reset simply has no effect if the target environment does not give rise to such concerns" Well, maybe it should have an effect under Linux too now :-). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35194
[Bug c++/12242] g++ should warn about out-of-range int->enum conversions
--- Comment #9 from manu at gcc dot gnu dot org 2008-02-15 11:09 ---
(In reply to comment #0)
> enum E { A };
> ...
> E e = static_cast (10);
>
> Yes, i know that result of this is undefined.
Is this true? I haven't found any mention of this.
> However, previous versions of g++ (and every other c++ compiler i've used)
> has implemented this in what seems like the simplest way: the compiler
> simply assigns the value `10' to the enum value, regardless of the
> fact that this is not a valid value for the enum.
We assing 10 in GCC 4.3.
> Therefore, the compiler is silently changing the behavior of the
> code from what was likely intended. So i think a warning would
> be appropriate in this situation. The current verison of 3.4 does
> not issue any warning, even with `-Wall -pedantic'.
The following patch implements the warning for this testcase. Do you know other
cases that may be interesting to warn about?
Index: gcc/testsuite/g++.dg/warn/pr12242.C
===
--- gcc/testsuite/g++.dg/warn/pr12242.C (revision 0)
+++ gcc/testsuite/g++.dg/warn/pr12242.C (revision 0)
@@ -0,0 +1,4 @@
+// { dg-do compile }
+// { dg-options "-Wall -Wextra -Wconversion" }
+enum E { A };
+E e = static_cast (10); // { dg-warning "warning.*undefined" }
Index: gcc/cp/typeck.c
===
--- gcc/cp/typeck.c (revision 132310)
+++ gcc/cp/typeck.c (working copy)
@@ -5069,10 +5069,15 @@ build_static_cast_1 (tree type, tree exp
types which are integral, floating, or enumeration types can be
performed. */
if ((INTEGRAL_TYPE_P (type) || SCALAR_FLOAT_TYPE_P (type))
&& (INTEGRAL_TYPE_P (intype) || SCALAR_FLOAT_TYPE_P (intype)))
{
+ if (TREE_CODE (expr) == INTEGER_CST
+ && TREE_CODE (type) == ENUMERAL_TYPE
+ && !int_fits_type_p (expr, type))
+ warning (0, "this conversion is undefined");
+
expr = ocp_convert (type, expr, CONV_C_CAST, LOOKUP_NORMAL);
/* Ignore any integer overflow caused by the cast. */
expr = ignore_overflows (expr, orig);
return expr;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
[Bug ada/35194] floating point truncation error on intel platform
--- Comment #7 from ubizjak at gmail dot com 2008-02-15 11:12 --- (In reply to comment #6) > After testing it, the -mpc option do not help. > > I agree this seems to be a problem of oracle not re-setting the FPU state. > Nevertheless, this makes ada unusable (or unreliable, which is not really > better) with oracle 10, oracle 11, and potentially many other software under > Linux ... a quite sad situation. What if you add -msse2 -mfpmath=sse? Then you use SSE for float and double calculations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35194
[Bug ada/35194] floating point truncation error on intel platform
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-02-15 11:13 --- Is there a reason why this is a GCC bug, from the comments I see you agree it is a bug in oracle and valgrind. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35194
[Bug c++/12242] g++ should warn about out-of-range int->enum conversions
--- Comment #10 from pinskia at gcc dot gnu dot org 2008-02-15 11:15 --- > Is this true? I haven't found any mention of this. It is at least unspecified. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
[Bug middle-end/35149] [4.3 Regression] ICE: in expand_call_inline, at tree-inline.c:2653
--- Comment #9 from hubicka at gcc dot gnu dot org 2008-02-15 11:15 --- Fixed by my patch. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35149
[Bug middle-end/35149] [4.3 Regression] ICE: in expand_call_inline, at tree-inline.c:2653
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-02-15 11:16 --- Subject: Bug 35149 Author: hubicka Date: Fri Feb 15 11:15:48 2008 New Revision: 132337 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132337 Log: PR middle-end/35149 * ipa.c (cgraph_remove_unreachable_nodes): Clear local.inlinable flag. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35149
[Bug c/30260] Enumeration types and enumeration constants erroneously given unsigned types
--- Comment #5 from manu at gcc dot gnu dot org 2008-02-15 11:25 ---
I am not sure how we want to fix this bug.
A possible fix is to have 2 behaviours, one with -std=cX and another with
-std=gnuX. So, for -std=cX we always convert enum values to integer, while for
-std=gnuX we don't. Currently , this is what is implemented for -pedantic (see
PR15236). This is wrong to do for -pedantic, but may be ok for the -std=
switch.
Otherwise, we could just unconditionally convert anything that fits into a
signed integer into signed integer. That is,
enum A {A1 = 0, A2 = A1 - 1};
enum B {B1 = 0u, B2 = B1 - 1};
will produce the same result. While
enum A {A1 = (int)0x80001000, A2 = A1 - 1};
enum B {B1 = 0x80001000, B2 = B1 - 1};
won't.
Joseph, what do you think?
Any more ideas?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2008-02-12 14:25:48 |2008-02-15 11:25:52
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30260
[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges
--- Comment #8 from hubicka at ucw dot cz 2008-02-15 11:29 --- Subject: Re: [4.2/4.3 Regression] ICE in coalesce_abnormal_edges The split happens in loop_optimized_init during profile construction pass, not in inliner. #0 make_ssa_name (var=0xb7da1228, stmt=0xb7daf000) at ../../gcc/tree-ssanames.c:150 #1 0x0850c03c in tree_make_forwarder_block (fallthru=0xb7ce8e60) at ../../gcc/tree-cfg.c:4727 #2 0x082905d4 in make_forwarder_block (bb=0xb7da2ca8, redirect_edge_p=0x82952e0 , new_bb_cbk=0) at ../../gcc/cfghooks.c:782 #3 0x08295544 in merge_latch_edges (loop=0xb7daa8dc) at ../../gcc/cfgloop.c:697 #4 0x0829571c in disambiguate_loops_with_multiple_latches () at ../../gcc/cfgloop.c:762 #5 0x08428448 in loop_optimizer_init (flags=0) at ../../gcc/loop-init.c:65 #6 0x0846d892 in tree_estimate_probability () at ../../gcc/predict.c:1354 Don't we have separate PR for this? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35182
[Bug c++/12242] g++ should warn about out-of-range int->enum conversions
--- Comment #11 from manu at gcc dot gnu dot org 2008-02-15 11:32 --- (In reply to comment #10) > > Is this true? I haven't found any mention of this. > It is at least unspecified. > So warning makes sense then, doesn't it? But perhaps the wording is not ideal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
[Bug c++/12242] g++ should warn about out-of-range int->enum conversions
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-02-15 11:34 --- It should probably say that it will truncate the value, which is what will happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
[Bug c++/35191] [4.3 Regression] ICE: tree check: expected class 'expression', have 'exceptional' (error_mark) in bot_manip, at cp/tree.c:1480
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-02-15 11:40 --- Reopen... -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35191
[Bug c++/35116] [4.3 Regression]: Fail to compile valid code
--- Comment #6 from reichelt at gcc dot gnu dot org 2008-02-15 11:40 --- *** Bug 35191 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||schnetter at aei dot mpg dot ||de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35116
[Bug c++/35191] [4.3 Regression] ICE: tree check: expected class 'expression', have 'exceptional' (error_mark) in bot_manip, at cp/tree.c:1480
--- Comment #8 from reichelt at gcc dot gnu dot org 2008-02-15 11:40 --- ... to mark as duplicate of PR35116 *** This bug has been marked as a duplicate of 35116 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35191
[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges
--- Comment #9 from rguenther at suse dot de 2008-02-15 11:41 --- Subject: Re: [4.2/4.3 Regression] ICE in coalesce_abnormal_edges On Fri, 15 Feb 2008, hubicka at ucw dot cz wrote: > --- Comment #8 from hubicka at ucw dot cz 2008-02-15 11:29 --- > Subject: Re: [4.2/4.3 Regression] ICE in coalesce_abnormal_edges > > The split happens in loop_optimized_init during profile construction pass, not > in inliner. > #0 make_ssa_name (var=0xb7da1228, stmt=0xb7daf000) at > ../../gcc/tree-ssanames.c:150 > #1 0x0850c03c in tree_make_forwarder_block (fallthru=0xb7ce8e60) at > ../../gcc/tree-cfg.c:4727 > #2 0x082905d4 in make_forwarder_block (bb=0xb7da2ca8, > redirect_edge_p=0x82952e0 , new_bb_cbk=0) at > ../../gcc/cfghooks.c:782 #3 0x08295544 in merge_latch_edges (loop=0xb7daa8dc) > at > ../../gcc/cfgloop.c:697 #4 0x0829571c in > disambiguate_loops_with_multiple_latches () at > ../../gcc/cfgloop.c:762 #5 0x08428448 in loop_optimizer_init (flags=0) at > ../../gcc/loop-init.c:65 #6 0x0846d892 in tree_estimate_probability () at > ../../gcc/predict.c:1354 > > Don't we have separate PR for this? Maybe this is related to PR35164. I will look into that one at the weekend if nobody beats me on it. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35182
[Bug ada/35194] floating point truncation error on intel platform
--- Comment #9 from jerome dot duquennoy at wanadoo dot fr 2008-02-15 11:55 --- I believe the problem is enlighten by Oracle, but needs to be addressed in the compiler : The adalib requires a specific FPU configuration to behave normally. Therefore, it should ensure this requirement is fulfilled. Under windows, internix, EMX, lynx, netBSD and freeBSD on an i386 CPU, the Reset procedure (alias to __gnat_init_float) issues a 'finit' to reset the FPU. I believe Linux should be added to the list. This is defined in gcc/ada/init.c, on lines 1910 to 1927 in the sources of gcc 4.2.3. I will try to compile a patched version for testing purpose. > Uros Bizjak : > What if you add -msse2 -mfpmath=sse? Then you use SSE for float and double > calculations Well ... still no difference :-(. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35194
[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-02-15 11:55
---
Seems like it. After fwprop1 iter_1 and iter_7 conflict:
D.2095_6 = &iter_1(ab)->D.2086;
iter_7(ab) = iter_1(ab) + 8;
__comp_ctor (&D.2138, D.2094_5);
# SUCC: 4 [100.0%] (fallthru,exec) 5 (ab,eh,exec)
# BLOCK 4
# PRED: 3 [100.0%] (fallthru,exec)
D.2139_8 = D.2138._M_refcount._M_pi;
iter_1(ab)->D.2086._M_refcount._M_pi ={v} D.2139_8;
goto ;
before they doesn't:
# BLOCK 3
# PRED: 2 (fallthru,exec)
D.2094_5 = (int *) D.2093_4;
D.2095_6 = &iter_1(ab)->D.2086;
iter_7(ab) = iter_1(ab) + 8;
__comp_ctor (&D.2138, D.2094_5);
# SUCC: 4 [100.0%] (fallthru,exec) 5 (ab,eh,exec)
# BLOCK 4
# PRED: 3 [100.0%] (fallthru,exec)
D.2139_8 = D.2138._M_refcount._M_pi;
D.2095_6->_M_refcount._M_pi ={v} D.2139_8;
goto ;
# SUCC: 2 (fallthru,exec)
I will be away for a weekend, so I goess I won't beat you :(
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35182
[Bug c++/12242] g++ should warn about out-of-range int->enum conversions
--- Comment #13 from manu at gcc dot gnu dot org 2008-02-15 11:42 --- (In reply to comment #12) > It should probably say that it will truncate the value, which is what will > happen. > That doesn't happen. The result of the conversion is 10 in GCC 4.3. It seems it doesn't need to be 10 and it wasn't 10 in 3.4. I don't want to get a PR saying "the warning says that the value is truncated but I printed it and it is not truncated! the warning is wrong! what a crappy compiler!". So better say that whatever may happen in a formal way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12242
[Bug inline-asm/35160] [4.3 regression] local-alloc introduces sharing of the same pseudo/hard reg between different output regs in inline asm
--- Comment #14 from ubizjak at gmail dot com 2008-02-15 12:20 --- Testcase is fixed by http://gcc.gnu.org/ml/gcc-cvs/2008-02/msg00353.html: Author: uros Date: Fri Feb 15 12:19:00 2008 New Revision: 132339 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132339 Log: * gcc.target/i386/pr35160.c: Skip if !nonpic for 32bit x86 targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr35160.c -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-15 12:20:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35160
[Bug ada/35194] floating point truncation error on intel platform
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2008-02-15 12:23 --- > The adalib requires a specific FPU configuration to behave normally. > Therefore, it should ensure this requirement is fulfilled. > > Under windows, internix, EMX, lynx, netBSD and freeBSD on an i386 CPU, the > Reset procedure (alias to __gnat_init_float) issues a 'finit' to reset the > FPU. > > I believe Linux should be added to the list. It is fulfilled under Linux, unless someone else screws things up, like Oracle. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35194
[Bug c++/35182] [4.2/4.3 Regression] ICE in coalesce_abnormal_edges
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-02-15 12:36 --- It is indeed fixed by a patch for PR35164 which I have. *** This bug has been marked as a duplicate of 35164 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35182
[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-02-15 12:36 --- *** Bug 35182 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||gcc at david dot osborn dot ||name http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35164
[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-02-15 12:37 --- With confirming that PR35182 is the same issue as this I produced a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|rakdver at gcc dot gnu dot |rguenth at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35164
[Bug tree-optimization/30604] Unable to coalesce ssa_names and which are marked as MUST COALESCE
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-02-15 12:55 --- Eventually this is related to PR35164, so please re-check here once that is fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||35164 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30604
[Bug middle-end/23868] [4.1/4.2/4.3 regression] builtin_apply uses wrong mode for multi-hard-register return values
--- Comment #11 from chrbr at gcc dot gnu dot org 2008-02-15 13:08 ---
If no one as started to do so, I'm resurecting this patch for the mainline, I
can test builtin-apply4.c on sh4.
btw, builtin-apply4.c doesn't currently fail with the testsuite because it is
restricted to { target { { i?86-*-* x86_64-*-* } && ilp32 } }
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
CC||kkojima at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
[Bug middle-end/35196] [4.3 Regression] lastprivate broken for static non-ordered loops
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35196
[Bug testsuite/35208] New: Please apply the patch in comment #19 of PR35035
Would it be possible to apply the patch in comment #19 of PR35035 before releasing gcc 4.3.0? Without this patch the libjava test hangs and needs to reboot the computer if the window in which the test has been launched is out of focus (for instance due to the screensave). -- Summary: Please apply the patch in comment #19 of PR35035 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35208
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-02-15 13:32 ---
We can, similarly to limiting the overall SCC size, limit the depth to where
we search. This testcase hits the stack limit on x86_64 with an unoptimized
cc1 built with gcc 4.2 with
(gdb) print *sccstack
$2 = {base = {num = 25069, alloc = 35065, vec = {0x2b201c6f8c60}}}
as we limit the SCC size to 1 we might as well limit the SCC stack size
to some magic number.
Or gcc could simply upper the (soft) stack limit with setrlimit...
Note that DFS in a bootstrapped compiler with release checking enabled doesn't
use an excessive amount of stack, but only pushes 6 registers (which are of
course 64bit wide) and allocates room for 56 extra bytes, which makes the
stack space used per recursion 110 bytes.
All big structures (in particular the ssa_op_iter) are scalarized though,
at least if VN_INFO is not inlined (if marked with always_inline ssa_op_iter
is not scalarized because then op_iter_next_use is not inlined). So we
may run into some inlining issues here (all of op_iter_* in tree-flow-inline.h
_are_ big, so they definitely get defered to the final inlining phase while
VN_INFO is (w/o checking) inlined by the early inliner). But at least
I don't see traces of op_iter_* calls in a bootstrapped compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-02-15 13:35 --- Shouldn't we make sure, eventually by an ALWAYS_INLINE macro, that all of our iterator functions are inlined so they definitely can be scalarized? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug tree-optimization/33992] [4.3 Regression] Miscompiles function with inlining, breaks profiledbootstrap
--- Comment #41 from ubizjak at gmail dot com 2008-02-15 13:39 --- *** Bug 34720 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added OtherBugsDependingO|34720 | nThis|| CC||tgall dot foo at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33992
[Bug c/34720] ICE in real_to_decimal, at real.c:1656
--- Comment #10 from ubizjak at gmail dot com 2008-02-15 13:39 --- Duplicate of PR33992. *** This bug has been marked as a duplicate of 33992 *** -- ubizjak at gmail dot com changed: What|Removed |Added BugsThisDependsOn|33992 | Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34720
[Bug target/35088] ICE: in def_cfa_1, at dwarf2out.c:804
--- Comment #3 from jsm28 at gcc dot gnu dot org 2008-02-15 13:42 --- Subject: Bug 35088 Author: jsm28 Date: Fri Feb 15 13:41:44 2008 New Revision: 132341 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132341 Log: PR target/35088 * config/m68k/m68k.h (DWARF_CIE_DATA_ALIGNMENT): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
[Bug target/35119] FAIL: g++.dg/template/spec35.C scan-assembler
--- Comment #6 from dominiq at lps dot ens dot fr 2008-02-15 13:37 --- Would it be possible to test the patch in comment #4 on non Darwin architecture and, if it does not cause regressions, to apply it before the release of gcc 4.3.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35119
[Bug testsuite/35208] Please apply the patch in comment #19 of PR35035
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-15 13:45 --- Please post/ping patches on the gcc-patches mailinglist. In this case CC some java/libjava maintainers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35208
[Bug testsuite/35208] Please apply the patch in comment #19 of PR35035
--- Comment #3 from andreast at gcc dot gnu dot org 2008-02-15 13:57 --- http://gcc.gnu.org/ml/java-patches/2008-q1/msg00051.html I will commit soon. -- andreast at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |andreast at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-15 13:57:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35208
[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs
--- Comment #9 from rakdver at kam dot mff dot cuni dot cz 2008-02-15 14:06 --- Subject: Re: [4.3 regression] Unable to coalesce ab SSA_NAMEs > Yeah, forwprop checks that it may propagate the name SR.40_22, but it doesn't > check recursively if any of the names occuring in the ADDR_EXPR of the rhs > are marked abnormal. > > We should check for this before calling forward_propagate_addr_expr in > tree_ssa_forward_propagate_single_use_vars. And probably add a new predicate > tree_contains_abnormal_ssa_name_p (tree exp) which walks exp recursively > (consider &b->c[d(AB)] or as in this case &a(AB)->x...). > > Please unassign yourself if you want me to do it. actually, I have a patch in testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35164
[Bug target/35119] FAIL: g++.dg/template/spec35.C scan-assembler
--- Comment #7 from ubizjak at gmail dot com 2008-02-15 14:06 --- (In reply to comment #6) > Would it be possible to test the patch in comment #4 on non Darwin > architecture > and, if it does not cause regressions, to apply it before the release of gcc > 4.3.0? It works OK on *-linux. Please post the patch with ChangeLog description to gcc-patches@ and I'll commit it for you. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-15 14:06:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35119
[Bug testsuite/35208] Please apply the patch in comment #19 of PR35035
--- Comment #4 from andreast at gcc dot gnu dot org 2008-02-15 14:09 --- Subject: Bug 35208 Author: andreast Date: Fri Feb 15 14:08:59 2008 New Revision: 132342 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132342 Log: 2008-02-15 Andreas Tobler <[EMAIL PROTECTED]> PR testsuite/35208 * testsuite/libjava.jvmti/interp/natgetstacktrace.cc (Java_getstacktrace_natRunner): Increase the usleep time to a value which prevents OS-X to get into a deadlock. Modified: trunk/libjava/ChangeLog trunk/libjava/testsuite/libjava.jvmti/interp/natgetstacktrace.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35208
[Bug testsuite/35208] Please apply the patch in comment #19 of PR35035
--- Comment #2 from dominiq at lps dot ens dot fr 2008-02-15 13:55 --- > Please post/ping patches on the gcc-patches mailinglist. The patch is not mine. What is the etiquette for this situation, beside adding the author to the cc list (done)? > In this case CC some java/libjava maintainers. Do you have name(s) to suggest? To say the least they have not been very active for PR35035. -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||andreast at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35208
[Bug testsuite/35208] Please apply the patch in comment #19 of PR35035
--- Comment #5 from andreast at gcc dot gnu dot org 2008-02-15 14:10 --- Fixed. -- andreast at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35208
[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs
--- Comment #10 from rguenther at suse dot de 2008-02-15 14:12 --- Subject: Re: [4.3 regression] Unable to coalesce ab SSA_NAMEs On Fri, 15 Feb 2008, rakdver at kam dot mff dot cuni dot cz wrote: > --- Comment #9 from rakdver at kam dot mff dot cuni dot cz 2008-02-15 > 14:06 --- > Subject: Re: [4.3 regression] Unable to coalesce ab SSA_NAMEs > > > Yeah, forwprop checks that it may propagate the name SR.40_22, but it > > doesn't > > check recursively if any of the names occuring in the ADDR_EXPR of the rhs > > are marked abnormal. > > > > We should check for this before calling forward_propagate_addr_expr in > > tree_ssa_forward_propagate_single_use_vars. And probably add a new > > predicate > > tree_contains_abnormal_ssa_name_p (tree exp) which walks exp recursively > > (consider &b->c[d(AB)] or as in this case &a(AB)->x...). > > > > Please unassign yourself if you want me to do it. > > actually, I have a patch in testing. Ok. I also have finished testing a patch. Let's just pick the nicer one, so just post yours after it finished testing. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35164
[Bug target/35119] FAIL: g++.dg/template/spec35.C scan-assembler
--- Comment #8 from uros at gcc dot gnu dot org 2008-02-15 14:34 --- Subject: Bug 35119 Author: uros Date: Fri Feb 15 14:33:57 2008 New Revision: 132344 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132344 Log: PR testsuite/35119 * testsuite/g++.dg/template/spec35.C Change the regular expressions in dg-final to match the assembly code generated by Darwin 9. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/spec35.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35119
[Bug target/35119] FAIL: g++.dg/template/spec35.C scan-assembler
--- Comment #10 from ubizjak at gmail dot com 2008-02-15 14:37 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35119
[Bug target/35119] FAIL: g++.dg/template/spec35.C scan-assembler
-- ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35119
[Bug preprocessor/35061] #pragma pop_macro causes ICE if no macro value on stack
--- Comment #5 from ubizjak at gmail dot com 2008-02-15 14:18 --- (In reply to comment #4) > Fixed for real. Wrong dg-do directive in the testcase was fixed by: Author: uros Date: Fri Feb 15 14:17:41 2008 New Revision: 132343 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132343 Log: * gcc.dg/cpp/pragma-pop_macro-1.c: Fix dg-do directive. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/pragma-pop_macro-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35061
[Bug target/35119] FAIL: g++.dg/template/spec35.C scan-assembler
--- Comment #9 from dominiq at lps dot ens dot fr 2008-02-15 14:36 --- Uros, thanks for the quick commit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35119
[Bug c/27030] Warning instead of error with weakref on local functions (also wrong warning message at that)
--- Comment #3 from manu at gcc dot gnu dot org 2008-02-15 14:36 --- Andrew, what is the status of this bug? It seems fixed in trunk. Do you want to fix it in the branches or should we close it? -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27030
[Bug middle-end/35196] [4.3 Regression] lastprivate broken for static non-ordered loops
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-15 15:18:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35196
[Bug fortran/35150] ICE in expand_expr_addr_expr_1, at expr.c:6728 (regression vs. earlier 4.3)
--- Comment #6 from burnus at gcc dot gnu dot org 2008-02-15 15:24 ---
(In reply to comment #3)
> Simplified test case:
This now works with FX's patch.
However, using F03GL still fails with:
OpenGL_glut.f90: In function glutinit_f03:
OpenGL_glut.f90:1518: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:6835
For a reduced test case see comment 0. For that test case, one has the dump:
glutinit_f03 ()
{
static integer(kind=4) argcp = 1;
static void * argv[1] = {0};
{
static void *[1] * C.910 = &argv;
glutinit_gl (&argcp, &C.910);
}
}
That is, the ELSE branch needs to be fixed as well; the fix was only for rank
== 0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35150
[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-02-15 15:25 --- Subject: Bug 35164 Author: rguenth Date: Fri Feb 15 15:24:19 2008 New Revision: 132345 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132345 Log: 2008-02-15 Richard Guenther <[EMAIL PROTECTED]> Zdenek Dvorak <[EMAIL PROTECTED]> PR tree-optimization/35164 * tree-flow.h (stmt_references_abnormal_ssa_name): Declare. * tree-dfa.c (stmt_references_abnormal_ssa_name): New function. * tree-ssa-forwprop.c (tree_ssa_forward_propagate_single_use_vars): Only propagate addresses which do not have abnormal SSA_NAMEs in their operands. * g++.dg/torture/pr35164-1.C: New testcase. * g++.dg/torture/pr35164-2.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/torture/pr35164-1.C trunk/gcc/testsuite/g++.dg/torture/pr35164-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-dfa.c trunk/gcc/tree-flow.h trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35164
[Bug tree-optimization/35164] [4.3 regression] Unable to coalesce ab SSA_NAMEs
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-02-15 15:25 --- Fixed. Thanks Zdenek for the initial analysis. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35164
[Bug libstdc++/35197] Native linker can't locate file for -lstdc++ with --enable-version-specific-runtime-libs
--- Comment #3 from Ralf dot Wildenhues at gmx dot de 2008-02-15 15:30 --- OK. Well, libstdc++ should not be present in /opt/tg/lib/gcc/alphaev56-dec-osf4.0g but instead in /opt/tg/lib/gcc/alphaev56-dec-osf4.0g/4.2.3 Do you still have the build tree or a build log? If the former, could you please look up the value of glibcxx_toolexeclibdir in alphaev56-dec-osf4.0g/libstdc++-v3/src/Makefile to find out why it's not being installed there? I should note that I'm seeing a related problem on x86_64-unknown-linux-gnu with --enable-version-specific-runtime-libs not finding -lgcc_s which is in $libdir/gcc/x86_64-unknown-linux-gnu/lib64. But I think that is a separate bug (and I will open a PR for it later). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35197
[Bug libstdc++/35209] New: __gnu_cxx::stdio_sync_filebuf constructor isn't exported by the DSO
The __gnu_cxx::stdio_sync_filebuf constructor are
not listed in gnu.ver, so aren't provided by libstdc++.so.
The following test doesn't link with -O0 or -O1, although
it does with -O2, "-O0 -static" and "-O1 -static".
-
#include
#include
__gnu_cxx::stdio_sync_filebuf foo (stdin);
int main () {}
-
--
Summary: __gnu_cxx::stdio_sync_filebuf constructor isn't
exported by the DSO
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: link-failure
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rsandifo at gcc dot gnu dot org
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35209
[Bug libstdc++/35209] __gnu_cxx::stdio_sync_filebuf constructor isn't exported by the DSO
--- Comment #1 from rsandifo at gcc dot gnu dot org 2008-02-15 15:59 --- Er, sorry for the grammar failure in that summary. I wrote "are" instead of "is" because the same problem affects the wchar_t version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35209
[Bug tree-optimization/35202] [4.1/4.2/4.3 Regression] exp->expf transformation incorrect with -fmath-errno
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-02-15 15:50 --- Ok, so with -fmath-errno the middle-end has to assume that the C library will set errno appropriately for all math functions this is specified, even if optional. Right? So we could at most detect at compile-time if there is a macro named math_errhandling and defined to a constant by the library that says it doesn't set errno and in this case clear -fmath-errno? -- 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 |2008-02-15 15:50:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35202
[Bug c/35210] New: gcc incorrectly allows calling function returning "const void"
const void f(void); void g(void) {f();}
This testcase violates the constraint in C99 6.5.2.2p1 ("The expression that
denotes the called function shall have type pointer to function returning void
or returning an object type other than an array type.", so gcc at the very
least must produce a diagnostic when using -pedantic. (BTW, is there any code
that depends on this working?)
--
Summary: gcc incorrectly allows calling function returning "const
void"
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eli dot friedman at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35210
[Bug tree-optimization/35202] [4.1/4.2/4.3 Regression] exp->expf transformation incorrect with -fmath-errno
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-02-15 15:53 --- The code that does this transformation is in convert.c:convert_to_real; auditing of all cases is required. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35202
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #11 from rguenth at gcc dot gnu dot org 2008-02-15 16:29 --- Well "always" is to be taken with a grain of salt. The testcase doesn't look common, but is a huge machine-generated piece of cr*p :P Otherwise this "always" also applies to wrong-code and rejects-valid bugs. If primary/secondary platforms are affected. Also there's a workaround available for this bug, -fno-tree-fre -fno-tree-pre. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug middle-end/35204] [4.3 Regression] crash by too deep recursion in DFS tree-ssa-sccvn.c:1898
--- Comment #10 from steven at gcc dot gnu dot org 2008-02-15 16:20 --- Re. comment #7, sure this can be P1 and block the release. SCC-VN doesn't have to be fixed for the release. This bug can be worked around. Not making a bug P1 because you want a release out the door is not a good readon. And unless I'm mistaken, a ICE-on-valid-code bug in C or C++ is always release-blocking anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35204
[Bug c/34389] -Wconversion produces wrong warning
--- Comment #6 from manu at gcc dot gnu dot org 2008-02-15 16:34 --- Some more findings: build_binary_op receives two parameters of type int: '(int)x' and '0x7fff' then it performs the shorten magic that seems right and produces: arg 1 constant invariant 32767>> which looks good. But just before returning, it converts that to 'int', what results in: arg 0 > arg 1 > which causes problems later. If instead it returned: arg 1 constant invariant>> No warning would be generated! Why bother with the shorten magic if convert is going to override it? Where it is overriding it? The current code converts the constant back and forth between short int and int at least 3 times. Any ideas on how to stop this madness? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34389
[Bug fortran/35150] ICE in expand_expr_addr_expr_1, at expr.c:6728 (regression vs. earlier 4.3)
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2008-02-15 16:21 --- (In reply to comment #6) > That is, the ELSE branch needs to be fixed as well; the fix was only for rank > == 0. OK, here is an updated patch: Index: trans-expr.c === --- trans-expr.c(revision 132257) +++ trans-expr.c(working copy) @@ -2264,6 +2264,13 @@ gfc_conv_array_parameter (se, arg->expr, argss, f); } + /* TODO -- the following two lines shouldn't be necessary, but +they're removed a bug is exposed later in the codepath. +This is workaround was thus introduced, but will have to be +removed; please see PR 35150 for details about the issue. */ + se->expr = convert (pvoid_type_node, se->expr); + se->expr = gfc_evaluate_now (se->expr, &se->pre); + return 0; } else if (sym->intmod_sym_id == ISOCBINDING_FUNLOC) I've started regtesting and will submit it for review afterwards. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-02-14 12:42:39 |2008-02-15 16:21:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35150
[Bug c/34389] -Wconversion produces wrong warning
--- Comment #7 from manu at gcc dot gnu dot org 2008-02-15 16:53 --- So fold_unary is transforming (T)(x & c) into (T)x & (T)c. Which is exactly the opposite transformation that build_binary_op just performed! Weird... So I see two options: * Either teach fold_unary to avoid this particular transformation in this particular case. * Hack conversion_warning to realize that (short)((int)x & c) is the same as (short)(x & c) if x is signed int and c fits in a signed int. Which will be undoing the transformation once more (fourth? fifth time?). And I am not even sure how to do this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34389
[Bug c++/35026] [4.3 regression] ICE with parameter pack in pointer type
--- Comment #2 from dgregor at gcc dot gnu dot org 2008-02-15 17:33 --- Subject: Bug 35026 Author: dgregor Date: Fri Feb 15 17:33:02 2008 New Revision: 132348 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132348 Log: 2008-02-15 Douglas Gregor <[EMAIL PROTECTED]> PR c++/35023 PR c++/35024 PR c++/35026 * pt.c (finish_member_template_decl): If the type in a TYPE_DECL is error_mark_node, return an error early. (find_parameter_packs_r): Pass the pointer set along to recursive calls of cp_walk_subtrees; don't try to manage the pointer set ourselves. (uses_parameter_packs): Pass the pointer set to cp_walk_tree. (make_pack_expansion): Ditto. (check_for_bare_parameter_packs): Ditto. Also, don't bother taking a second pass through the tree with find_parameter_packs_r; that second pass no longer does anything. (push_template_decl_real): If we have an erroneous declaration, set its type to error_mark_node before returning an error. 2008-02-15 Douglas Gregor <[EMAIL PROTECTED]> PR c++/35023 PR c++/35024 PR c++/35026 * g++.dg/cpp0x/vt-35026.C: New. * g++.dg/cpp0x/vt-35023.C: New. * g++.dg/cpp0x/vt-34055.C: Tweak expected error messages. * g++.dg/cpp0x/vt-35024.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-35023.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-35024.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-35026.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/vt-34055.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35026
[Bug c++/35023] [4.3 regression] ICE with parameter pack in variable declaration
--- Comment #2 from dgregor at gcc dot gnu dot org 2008-02-15 17:33 --- Subject: Bug 35023 Author: dgregor Date: Fri Feb 15 17:33:02 2008 New Revision: 132348 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132348 Log: 2008-02-15 Douglas Gregor <[EMAIL PROTECTED]> PR c++/35023 PR c++/35024 PR c++/35026 * pt.c (finish_member_template_decl): If the type in a TYPE_DECL is error_mark_node, return an error early. (find_parameter_packs_r): Pass the pointer set along to recursive calls of cp_walk_subtrees; don't try to manage the pointer set ourselves. (uses_parameter_packs): Pass the pointer set to cp_walk_tree. (make_pack_expansion): Ditto. (check_for_bare_parameter_packs): Ditto. Also, don't bother taking a second pass through the tree with find_parameter_packs_r; that second pass no longer does anything. (push_template_decl_real): If we have an erroneous declaration, set its type to error_mark_node before returning an error. 2008-02-15 Douglas Gregor <[EMAIL PROTECTED]> PR c++/35023 PR c++/35024 PR c++/35026 * g++.dg/cpp0x/vt-35026.C: New. * g++.dg/cpp0x/vt-35023.C: New. * g++.dg/cpp0x/vt-34055.C: Tweak expected error messages. * g++.dg/cpp0x/vt-35024.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-35023.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-35024.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-35026.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/vt-34055.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35023
[Bug c++/35024] [4.3 regression] ICE with parameter pack in nested type
--- Comment #2 from dgregor at gcc dot gnu dot org 2008-02-15 17:33 --- Subject: Bug 35024 Author: dgregor Date: Fri Feb 15 17:33:02 2008 New Revision: 132348 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132348 Log: 2008-02-15 Douglas Gregor <[EMAIL PROTECTED]> PR c++/35023 PR c++/35024 PR c++/35026 * pt.c (finish_member_template_decl): If the type in a TYPE_DECL is error_mark_node, return an error early. (find_parameter_packs_r): Pass the pointer set along to recursive calls of cp_walk_subtrees; don't try to manage the pointer set ourselves. (uses_parameter_packs): Pass the pointer set to cp_walk_tree. (make_pack_expansion): Ditto. (check_for_bare_parameter_packs): Ditto. Also, don't bother taking a second pass through the tree with find_parameter_packs_r; that second pass no longer does anything. (push_template_decl_real): If we have an erroneous declaration, set its type to error_mark_node before returning an error. 2008-02-15 Douglas Gregor <[EMAIL PROTECTED]> PR c++/35023 PR c++/35024 PR c++/35026 * g++.dg/cpp0x/vt-35026.C: New. * g++.dg/cpp0x/vt-35023.C: New. * g++.dg/cpp0x/vt-34055.C: Tweak expected error messages. * g++.dg/cpp0x/vt-35024.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/vt-35023.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-35024.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-35026.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/vt-34055.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35024
[Bug c++/35023] [4.3 regression] ICE with parameter pack in variable declaration
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-02-15 17:34 --- Fixed on mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35023
[Bug c/35210] gcc incorrectly allows calling function returning "const void"
--- Comment #1 from schwab at suse dot de 2008-02-15 17:35 --- 6.7.3p2: The properties associated with qualified types are meaningful only for expressions that are lvalues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35210
[Bug c++/35024] [4.3 regression] ICE with parameter pack in nested type
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-02-15 17:35 --- Fixed on mainline -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35024
[Bug bootstrap/35211] New: Dist tarball is missing (Bison-generated) java/parse-scan.c
Build failed with: begin /tg/freeport/src/gcc/gcc--4.2.3/missing bison -t -o java/parse-scan.c /tg/freeport/src/gcc/gcc--4.2.3/gcc/java/parse-scan.y WARNING: `bison' missing on your system. You should only need it if you modified a `.y' file. You may need the `Bison' package in order for those modifications to take effect. You can get `Bison' from any GNU archive site. /mnt/scratch/build/gcc--4.2.3.build/./prev-gcc/xgcc -B/mnt/scratch/build/gcc--4.2.3.build/./prev-gcc/ -B/opt/tg/alphaev56-dec-osf4.0g/bin/ -c -g -O2 -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 -Wno-error -DHAVE_CONFIG_H -I. -Ijava -I/tg/freeport/src/gcc/gcc--4.2.3/gcc -I/tg/freeport/src/gcc/gcc--4.2.3/gcc/java -I/tg/freeport/src/gcc/gcc--4.2.3/gcc/../include -I/tg/freeport/src/gcc/gcc--4.2.3/gcc/../libcpp/include -I/tg/freeport/src/gcc/gcc--4.2.3/gcc/../libdecnumber -I../libdecnumber java/parse-scan.c -o java/parse-scan.o xgcc: java/parse-scan.c: No such file or directory xgcc: no input files gmake[3]: *** [java/parse-scan.o] Error 1 gmake[3]: Leaving directory `/mnt/scratch/build/gcc--4.2.3.build/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/mnt/scratch/build/gcc--4.2.3.build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/mnt/scratch/build/gcc--4.2.3.build' gmake: *** [bootstrap-lean] Error 2 end $ tar tvjf gcc-4.2.3.tar.bz2 | grep parse-scan -rw-rw-r-- joseph/joseph 31171 2007-08-31 04:27:50 gcc-4.2.3/gcc/java/parse-scan.y $ omgwtf -- Summary: Dist tarball is missing (Bison-generated) java/parse- scan.c Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: skunk at iskunk dot org GCC build triplet: alphaev56-dec-osf4.0g GCC host triplet: alphaev56-dec-osf4.0g GCC target triplet: alphaev56-dec-osf4.0g http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35211
[Bug middle-end/35130] OpenMP: Private variable passed to subroutine
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-15 17:50 --- Fixed on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35130
[Bug c/35210] gcc incorrectly allows calling function returning "const void"
--- Comment #2 from eli dot friedman at gmail dot com 2008-02-15 18:01 --- Yes, but "const void" is still a distinct type from "void". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35210
[Bug c/34389] -Wconversion produces wrong warning
--- Comment #8 from manu at gcc dot gnu dot org 2008-02-15 18:04 ---
This patch fixes this bug but it is an ugly hack. Perhaps such an ugly hack is
the only thing we can do at the moment.
Once bootstrapping + testing finishes, I will submit.
Index: gcc/c-common.c
===
--- gcc/c-common.c (revision 132310)
+++ gcc/c-common.c (working copy)
@@ -1270,65 +1270,98 @@ conversion_warning (tree type, tree expr
"conversion to %qT alters %qT constant value",
type, TREE_TYPE (expr));
}
else /* 'expr' is not a constant. */
{
+ tree expr_type = TREE_TYPE (expr);
+
/* Warn for real types converted to integer types. */
- if (TREE_CODE (TREE_TYPE (expr)) == REAL_TYPE
+ if (TREE_CODE (expr_type) == REAL_TYPE
&& TREE_CODE (type) == INTEGER_TYPE)
give_warning = true;
- else if (TREE_CODE (TREE_TYPE (expr)) == INTEGER_TYPE
+ else if (TREE_CODE (expr_type) == INTEGER_TYPE
&& TREE_CODE (type) == INTEGER_TYPE)
{
/* Don't warn about unsigned char y = 0xff, x = (int) y; */
expr = get_unwidened (expr, 0);
+ expr_type = TREE_TYPE (expr);
+ /* Don't warn for short y; short x = ((int)y & 0xff); */
+ if (TREE_CODE (expr) == BIT_AND_EXPR
+ && TREE_CODE (TREE_OPERAND (expr, 1)) == INTEGER_CST)
+ {
+ int unsigned0, unsigned1;
+ tree arg0, arg1;
+ tree tmp_type;
+ tree op0, op1;
+
+ op0 = convert (expr_type, TREE_OPERAND (expr, 0));
+ op1 = convert (expr_type, TREE_OPERAND (expr, 1));
+
+ arg0 = get_narrower (op0, &unsigned0);
+ arg1 = get_narrower (op1, &unsigned1);
+
+ /* Handle the case that OP0 (or OP1) does not *contain* a
conversion
+but it *requires* conversion to TYPE. */
+ if ((TYPE_PRECISION (TREE_TYPE (op0))
+ == TYPE_PRECISION (TREE_TYPE (arg0)))
+ && TREE_TYPE (op0) != expr_type)
+ unsigned0 = TYPE_UNSIGNED (TREE_TYPE (op0));
+
+ if (TYPE_PRECISION (TREE_TYPE (arg0)) < TYPE_PRECISION
(expr_type)
+ && (tmp_type
+ = c_common_signed_or_unsigned_type (unsigned0,
+ TREE_TYPE (arg0)))
+ && !POINTER_TYPE_P (tmp_type)
+ && int_fits_type_p (arg1, tmp_type))
+ expr_type = tmp_type;
+ }
/* Warn for integer types converted to smaller integer types. */
- if (formal_prec < TYPE_PRECISION (TREE_TYPE (expr)))
+ if (formal_prec < TYPE_PRECISION (expr_type))
give_warning = true;
/* When they are the same width but different signedness,
then the value may change. */
- else if ((formal_prec == TYPE_PRECISION (TREE_TYPE (expr))
- && TYPE_UNSIGNED (TREE_TYPE (expr)) != TYPE_UNSIGNED
(type))
+ else if ((formal_prec == TYPE_PRECISION (expr_type)
+ && TYPE_UNSIGNED (expr_type) != TYPE_UNSIGNED (type))
/* Even when converted to a bigger type, if the type is
unsigned but expr is signed, then negative values
will be changed. */
- || (TYPE_UNSIGNED (type) && !TYPE_UNSIGNED (TREE_TYPE
(expr
+ || (TYPE_UNSIGNED (type) && !TYPE_UNSIGNED (expr_type)))
warning (OPT_Wsign_conversion,
"conversion to %qT from %qT may change the sign of the
result",
-type, TREE_TYPE (expr));
+type, expr_type);
}
/* Warn for integer types converted to real types if and only if
all the range of values of the integer type cannot be
represented by the real type. */
- else if (TREE_CODE (TREE_TYPE (expr)) == INTEGER_TYPE
+ else if (TREE_CODE (expr_type) == INTEGER_TYPE
&& TREE_CODE (type) == REAL_TYPE)
{
- tree type_low_bound = TYPE_MIN_VALUE (TREE_TYPE (expr));
- tree type_high_bound = TYPE_MAX_VALUE (TREE_TYPE (expr));
+ tree type_low_bound = TYPE_MIN_VALUE (expr_type);
+ tree type_high_bound = TYPE_MAX_VALUE (expr_type);
REAL_VALUE_TYPE real_low_bound = real_value_from_int_cst (0,
type_low_bound);
REAL_VALUE_TYPE real_high_bound = real_value_from_int_cst (0,
type_high_bound);
if (!exact_real_truncate (TYPE_MODE (type), &real_low_bound)
|| !exact_real_truncate (TYPE_MODE (type), &real_high_bound))
give_warning = true;
}
/* Warn for real types converted to smaller real types. */
- else if (TREE_CODE (TREE_TYPE (expr)) == REAL_TYPE
+ else if (TREE_CODE (expr_type) == REAL_TYPE
[Bug middle-end/35185] ICE using openmp with g++-4.2
--- Comment #5 from jakub at gcc dot gnu dot org 2008-02-15 18:58 ---
Simplified testcase:
struct S
{
S ();
~S ();
int s;
};
void bar (S);
void
foo ()
{
S s;
#pragma omp parallel shared (s)
bar (s);
}
Works if s is firstprivate or private, or if it doesn't have user defined
destructor.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-02-15 18:58:42
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35185
[Bug c++/35078] ICE with reference in parallel for loop
--- Comment #2 from jakub at gcc dot gnu dot org 2008-02-15 17:57 --- This is invalid code (iteration vars must not have reference-type), so rejects-valid is incorrect keyword. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Keywords|rejects-valid | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35078
[Bug c++/35026] [4.3 regression] ICE with parameter pack in pointer type
--- Comment #3 from dgregor at gcc dot gnu dot org 2008-02-15 17:35 --- Fixed for 4.3 -- dgregor at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35026
[Bug c++/35212] New: g++ omits generating debugging symbols for some local variables
g++ fails to generate debugging symbols for some local variables. Here is the compiler invocation command that produces the bug: [EMAIL PROTECTED]:~/code$ g++ -v -Wall -O0 -g -save-temps -o stagefile stagefile.cc -lm 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 --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-targets=all --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -E -quiet -v -D_GNU_SOURCE stagefile.cc -mtune=generic -Wall -fworking-directory -O0 -fpch-preprocess -o stagefile.ii ignoring nonexistent directory "/usr/local/include/i486-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../i486-linux-gnu/include" ignoring nonexistent directory "/usr/include/i486-linux-gnu" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/4.2 /usr/include/c++/4.2/i486-linux-gnu /usr/include/c++/4.2/backward /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.2.3/include /usr/include End of search list. /usr/lib/gcc/i486-linux-gnu/4.2.3/cc1plus -fpreprocessed stagefile.ii -quiet -dumpbase stagefile.cc -mtune=generic -auxbase stagefile -g -O0 -Wall -version -o stagefile.s GNU C++ version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4) (i486-linux-gnu) compiled by GNU C version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128352 Compiler executable checksum: 3dbb0d64f7247875ecc86216cf2aff16 as -V -Qy -o stagefile.o stagefile.s GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 /usr/lib/gcc/i486-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o stagefile /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.2.3/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3 -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/i486-linux-gnu/4.2.3/../../.. stagefile.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/i486-linux-gnu/4.2.3/crtend.o /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/crtn.o Debugging information for the variable "name_i_can_easily_spot" isn't produced. -- Summary: g++ omits generating debugging symbols for some local variables Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: connerta at appliedbiosystems dot com GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35212
[Bug c++/35212] g++ omits generating debugging symbols for some local variables
--- Comment #1 from connerta at appliedbiosystems dot com 2008-02-15 19:33 --- Created an attachment (id=15158) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15158&action=view) This is the ".ii" file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35212
[Bug c++/35212] g++ omits generating debugging symbols for some local variables
--- Comment #2 from connerta at appliedbiosystems dot com 2008-02-15 19:34 --- Created an attachment (id=15159) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15159&action=view) This is the ".cc" file used as the source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35212
[Bug c++/35212] g++ omits generating debugging symbols for some local variables
--- Comment #3 from connerta at appliedbiosystems dot com 2008-02-15 19:35 --- Created an attachment (id=15160) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15160&action=view) This is a file showing the problem in more detail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35212
[Bug c++/35153] Taking address of result of calling function returning rvalue reference should not compile.
--- Comment #1 from dgregor at gcc dot gnu dot org 2008-02-15 19:55 --- After discussing this with Howard Hinnant, we agree that it is a bug. I'll handle it. -- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-02-15 19:55:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35153
[Bug middle-end/35130] OpenMP: Private variable passed to subroutine
--- Comment #4 from jakub at gcc dot gnu dot org 2008-02-15 17:37 --- Subject: Bug 35130 Author: jakub Date: Fri Feb 15 17:36:43 2008 New Revision: 132349 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132349 Log: PR middle-end/35130 * tree-nested.c (convert_call_expr): Put FRAME.* vars into OMP_CLAUSE_SHARED rather than OMP_CLAUSE_FIRSTPRIVATE clause. * testsuite/libgomp.fortran/pr35130.f90: New test. * testsuite/libgomp.c/pr35130.c: New test. Added: trunk/libgomp/testsuite/libgomp.c/pr35130.c trunk/libgomp/testsuite/libgomp.fortran/pr35130.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/tree-nested.c trunk/libgomp/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35130
